Data Policies for Security in ServiceNow – Complete Guide for CAD Exam
Why Data Policies for Security Matter
Data integrity and security are foundational pillars of any enterprise platform. In ServiceNow, Data Policies serve as a critical mechanism to ensure that data entering the system meets defined standards — not just from the form interface, but from all entry points, including web services, import sets, and direct API calls. When applied for security purposes, Data Policies go beyond simple UI-level validation and enforce rules at the server level, protecting the platform from incomplete, inaccurate, or unauthorized data regardless of how records are created or modified.
Without Data Policies, a malicious actor or a poorly configured integration could bypass client-side UI Policies and inject invalid or incomplete data directly into your tables. This makes Data Policies an essential layer in your defense-in-depth security strategy.
What Are Data Policies?
A Data Policy in ServiceNow is a server-side rule that enforces data consistency by making fields mandatory, read-only, or both — regardless of how data enters the system. Data Policies are defined in the System Policy > Data Policies module.
Key characteristics of Data Policies:
• They enforce rules on the server side, meaning they apply to all data entry methods — forms, web services, import sets, list edits, and more.
• They can be configured to apply only to specific conditions (similar to how UI Policies use conditions).
• They can optionally apply to the form interface as well, essentially acting as a UI Policy equivalent that also covers server-side enforcement.
• They operate on a per-table basis and can be inherited by extended tables.
Data Policies vs. UI Policies
Understanding the distinction between Data Policies and UI Policies is critical for the exam:
• UI Policies run on the client side (in the browser). They control the form's appearance and behavior — making fields mandatory, read-only, or visible. However, they do not enforce rules when data arrives via integrations, APIs, or import sets.
• Data Policies run on the server side. They enforce mandatory and read-only constraints regardless of how data enters the system. They do not control field visibility (since there is no UI context on the server).
If you check the "Use as UI Policy on client" checkbox on a Data Policy, it will also generate an equivalent UI Policy, giving you both client-side and server-side enforcement from a single configuration.
How Data Policies Work
1. Navigate to System Policy > Data Policies.
2. Create a new Data Policy by clicking "New."
3. Define the table the policy applies to (e.g., Incident, Change Request).
4. Set conditions — these determine when the policy is active. For example, you might enforce stricter rules only when Priority is Critical.
5. Add Data Policy Rules — for each field you want to control, specify whether it should be mandatory, read-only, or both.
6. Optionally enable "Apply to import sets" — this ensures that data coming through import sets is also validated.
7. Optionally enable "Use as UI Policy on client" — this creates a parallel client-side enforcement so users see the same restrictions on the form.
When a record is saved (from any source), the Data Policy engine evaluates the conditions and enforces the rules. If a mandatory field is empty, the save operation is rejected and an error is returned.
Data Policies for Security – Specific Use Cases
• Preventing incomplete records from integrations: External systems pushing data via REST or SOAP APIs must comply with Data Policy rules, ensuring critical security fields (e.g., assignment group, category) are always populated.
• Enforcing read-only fields: Certain fields (e.g., approval status, risk assessment) can be made read-only through Data Policies to prevent tampering from any data source.
• Protecting data quality during imports: When the "Apply to import sets" option is enabled, even bulk data loads must meet your data standards.
• Consistent enforcement across access methods: Unlike UI Policies alone, Data Policies ensure that rules are consistently applied whether a user is on the form, using a mobile app, or a system is integrating via API.
Key Configuration Options
• Active: Enables or disables the Data Policy.
• Apply to import sets: When checked, the policy applies to records created or updated through import sets.
• Use as UI Policy on client: When checked, a corresponding UI Policy is automatically generated to enforce the same rules on the client side (form).
• Inherit: When checked, the policy applies to tables that extend the specified table.
• Reverse if false: When checked, the policy reverses its actions (e.g., removes mandatory status) when the condition evaluates to false.
• Conditions: Defines when the policy is active based on field values on the record.
• Data Policy Rules: Related list where you define which fields are mandatory and/or read-only.
Important Limitations
• Data Policies cannot set field visibility (show/hide). This is exclusively a UI Policy or client script capability, as visibility is a client-side concept.
• Data Policies do not apply to import sets by default — you must explicitly check the "Apply to import sets" checkbox.
• If "Use as UI Policy on client" is enabled, changes to the Data Policy automatically update the generated UI Policy. You should not manually edit the generated UI Policy.
Exam Tips: Answering Questions on Data Policies for Security
1. Know the key difference between UI Policies and Data Policies: The most common exam question compares these two. Remember: UI Policies = client side only; Data Policies = server side (and optionally client side). If a question asks how to enforce mandatory fields for data coming from web services or integrations, the answer is Data Policy.
2. Remember that Data Policies cannot control visibility: If a question asks about hiding a field, the answer is never a Data Policy. Only UI Policies and Client Scripts can show/hide fields.
3. "Apply to import sets" is not on by default: Exam questions may test whether Data Policies automatically apply to import sets. The answer is no — you must explicitly enable this option.
4. "Use as UI Policy on client" creates a UI Policy automatically: If a question asks how to enforce the same mandatory/read-only rules on both the form and the server, the answer is to use a Data Policy with the "Use as UI Policy on client" option checked.
5. Focus on the security angle: When a question mentions preventing data bypass, protecting data integrity from external sources, or enforcing rules across all access methods, think Data Policies.
6. Reverse if false behavior: Understand that "Reverse if false" means the policy actions are undone when the condition is no longer met. This is similar to how UI Policies work.
7. Inheritance: Data Policies can apply to child tables when the Inherit option is enabled. This is useful for enforcing organization-wide standards on base tables like Task.
8. Watch for trick answers: If an option mentions using a Business Rule to enforce mandatory fields, remember that while technically possible, a Data Policy is the declarative, no-code, best-practice approach recommended by ServiceNow for making fields mandatory or read-only across all access points.
9. Scenario-based questions: If the scenario describes an integration that is creating incident records without required fields, and a UI Policy already exists but is not working for the integration, the solution is a Data Policy — because UI Policies do not run for server-side operations like web service calls.
10. Remember the module path: Data Policies are found under System Policy > Data Policies. Knowing the navigation can help confirm your answer in scenario questions.
Summary
Data Policies are a powerful, declarative mechanism in ServiceNow that enforce data integrity and security at the server level. They complement UI Policies by ensuring that mandatory and read-only rules are respected regardless of the data entry method. For the CAD exam, focus on understanding when to use Data Policies vs. UI Policies, their limitations (no visibility control), their optional settings (import sets, UI Policy generation), and their role in a comprehensive security strategy.