How Quality Clouds Differentiates between Code and Data

If you’re responsible for managing or safeguarding your ServiceNow environment, this article is for you.

This article provides detailed clarity on how Quality Clouds explicitly differentiates between code (scripts, metadata, configurations) and sensitive transactional data within ServiceNow. It further emphasizes that Quality Clouds accesses only certain configuration element types, ensuring no sensitive transactional information is ever analyzed or stored.

You’ll find this article especially relevant if you are:

• ServiceNow Platform Owners

• Security & Compliance Teams

• Developers & Architects

• IT Governance Stakeholders

 Ready to uncover hidden risks in your ServiceNow instance?
Talk to a platform security expert at Quality Clouds and get a free analysis of your org’s third-party connections, OAuth access points, and governance blind spots.
Request Your Free Assessment Now

Background: The Customer Concern

Customers frequently ask:
“How does Quality Clouds differentiate between code and data? If Quality Clouds doesn’t analyze or store sensitive data, why does it access tables that potentially store such data?”
This article directly addresses this concern.

Code vs. Data – Definitions

What Quality Clouds Accesses (Code & Metadata Only)

✅Quality Clouds analyzes exclusively:

• Scripts and their logic: e.g., Business Rules, Script Includes, Client Scripts

• UI definitions: UI Actions, UI Policies

• Security definitions: ACL configurations (metadata only)

• System properties & schema metadata

• Integration configurations: REST APIs definitions (no payload data)

• Workflow & Transform map definitions: (metadata only, no transactional records)

What Quality Clouds Does NOT Access (Sensitive Data)

❌ Quality Clouds explicitly avoids:

• User-submitted data or transactional records

• Personal Identifiable Information (PII) beyond limited administrative user info explicitly provided.

• Password hashes, user-generated content, or sensitive business data

• Transactional content from tables like sys_user, sc_cat_item_producer, or any record-level business data.

  
  

Specific Configuration Element Types Scanned

Quality Clouds limits its scanning to very specific configuration elements in ServiceNow. This selective approach explicitly helps prevent accidental exposure to transactional or sensitive data.

Only these configuration types are accessed and analyzed:

• Access Control Lists (ACLs) – Metadata only

• Angular Providers

• Business Rules

• Catalog Client Scripts

• Client Scripts

• Portal Widgets (Client and Server Scripts)

• Data Sources (metadata definitions only, no data payloads)

• Inactivity Monitors (configurations only)

• Notification Email Scripts (script logic only)

• Plugins (metadata only)

• Script Includes

• System Properties

• Transform Maps & Transform Scripts (definitions only)

• UI Actions & UI Policies

• User Preference definitions (no personal preference content accessed)

• Scripted REST API Definitions (configurations only, no payload)

  
  Important: The above list explicitly excludes tables or fields known to store sensitive transactional data or user-submitted records.

Ready to Take Control of Your Platform Governance?

Discover how Quality Clouds helps you stay ahead of compliance, automate platform security checks, and eliminate risks before they escalate.

Learn More

How Limiting Configuration Element Types Helps Differentiate Code from Data

By scanning only selected configuration element types, Quality Clouds ensures:

• Explicit Control: Clearly defined scanning boundaries prevent unintended access to sensitive data.

• In-Memory Analysis Only: Code and metadata are analyzed temporarily and never persisted.

• Complete Separation: Transactional data remains fully outside the scope of Quality Clouds’ scans.

  
  

How Quality Clouds Differentiates Code from Data

Quality Clouds explicitly distinguishes code (metadata) from data (content) through the following approach:

1. Metadata-only Queries

• Quality Clouds leverages queries explicitly targeting metadata structures, such as:

• Column names, table definitions

• Script logic and syntax

• Configuration attributes (settings, properties, flags)

• It does not perform queries that access transactional content, user records, or any sensitive data stored within records themselves.

2. Tables and Fields Selection

• Quality Clouds selects only fields that define configurations, scripts, metadata, and structure.

• It explicitly excludes fields that may store transactional or sensitive information, such as:

  • User-submitted form data (from catalog items)

  • Personal user details (names, addresses, passwords, etc.)

  • Transactional logs containing sensitive or personal content

3. No Data Persistence

• Quality Clouds’ scans are conducted using real-time API calls that read configuration and script metadata.

• The scanned information remains entirely within the customer’s instance boundary. Quality Clouds does not export, store, or retain any sensitive data.

Additional Security Assurance Measures

Quality Clouds employs several additional robust security controls:

• AES-256 Encryption of minimal personal data at rest.

• Secure HTTPS/TLS (1.2 and above) for all data in transit.

• Annual external vulnerability and penetration testing.

• ISO 27001:2022 Certification confirming adherence to rigorous information security management standards.

• Regular security and compliance audits, including SOC 2 Type II reporting.

• Additional control is provided by a QC non-admin role with tightly scoped ACLs that restrict access solely to the documented tables.

  
  

Detailed Access Justification by Table Category:

1. UI Policies and Catalog Definitions

Tables:

• catalog_script_client, catalog_ui_policy, catalog_ui_policy_action, sc_cat_item, sc_category, sc_cat_item_producer, item_option_new, item_option_new_set, sys_ui_policy, sys_ui_action, sys_ui_script, sys_ui_element, sys_ui_section, sys_ui_form_section, sys_ui_style

Reason for Access:

• To verify adherence to UI best practices (e.g., client-side scripting, performance best practices).

• Checks for redundant or inefficient UI logic impacting performance.

• Evaluates catalog item definitions to identify problematic configurations, not user-entered data.

What QC looks at:
✅ Form metadata, UI scripting logic, configuration definitions
❌ User-entered catalog item submissions, personal user data, transactional records

2. Script & Code Definitions

Tables:

• sys_script, sys_script_client, sys_script_email, sys_script_include, syscript_pattern, sys_transform_map, sys_transform_script, sysevent_script_action, catalog_script_client, sp_widget, sp_angular_provider

Reason for Access:

• Analysis of code quality, security vulnerabilities, and technical debt in scripts.

• Detection of potential performance bottlenecks or insecure scripting practices.

What QC looks at:
✅ Script/code logic, metadata, structural patterns
❌ Transactional data, actual business records or user-generated data

3. Security & Access Control Definitions

Tables:

• sys_security_acl, sys_group_has_role, sys_user_role, sys_user_has_role, sys_scope

Reason for Access:

• Auditing security rules and ACLs, checking for improper role definitions, overly permissive access, or configuration risks.

• Ensuring strict adherence to security best practices.

What QC looks at:
✅ Role definitions, ACL configurations, scope definitions
❌ Sensitive user credentials, passwords, or personal user information

4. System Configuration & Integration Definitions

Tables:

• sys_properties, sys_rest_message, sys_soap_message, sys_data_source, sys_dictionary, sys_dictionary_override, sys_package, sys_db_object, sys_data_policy2

Reason for Access:

• Reviewing configurations for vulnerabilities or misconfigurations, which could impact security or compliance.

• Evaluating metadata structures for system optimization.

What QC looks at:
✅ Configuration settings, schema definitions, integration logic
❌ Actual data within integrations (API payloads, credentials), transactional or production data

5. Workflow and Update Management

Tables:

• wf_workflow, wf_workflow_version, sys_update_set, sys_update_xml, sys_upgrade_history

Reason for Access:

• Checking update-set hygiene, best practices for upgrade readiness, and workflow efficiency.

• Identifying technical debt or issues in workflow definitions.

What QC looks at:
✅ Workflow definitions, version history, and structural metadata
❌ Actual workflow execution transactional data or business details 

6. User Definitions (Limited Metadata Access Only)

Tables:

• sys_user, sys_user_preference

Reason for Access:

• Ensuring that user-related scripts or configurations adhere to privacy best practices (e.g., preventing exposure of PII or credentials).

What QC looks at:
✅ Schema and structure only, metadata for configuration security (e.g., checking scripting references to user records)
❌ Actual sensitive user personal data (e.g., passwords, emails, phone numbers)

FAQs: Common Customer Queries

Q: Can Quality Clouds accidentally access sensitive data?
A: No. QC scans explicitly target metadata and code definitions via the REST API.QC’s infrastructure prevents access to sensitive or transactional data.

Q: Does Quality Clouds retain any source code or transactional data after scans?
A: No. Source code is analyzed temporarily in-memory and never persisted. Only aggregate quality metrics are retained.

Q: What personal data is collected?
A: Limited to the user’s name and email address provided by the customer explicitly for portal access, encrypted at rest with AES-256.

Summary: How Quality Clouds Differentiates Code from Data

Quality Clouds differentiates clearly between code (metadata) and data (content):

• Code (scripts, configurations, metadata): ✅ Scanned to identify best practices, performance issues, security vulnerabilities.

• Data (transactional, sensitive content): ❌ Never scanned, accessed, or stored.

  
  Quality Clouds’ approach—scanning only specific configuration element types at the metadata level—explicitly ensures that sensitive transactional data is never accessed or processed. This method guarantees a secure, compliant, and trusted scanning process.

Our robust security infrastructure further reinforces data privacy and compliance commitments.