ServiceNow Data Policy Explained

What a Data Policy Is

A data policy is a rule that restricts access to fields in specific records based on conditions you define. Data policies allow you to control who can read or modify particular fields in a table, independent of whether users have general access to the table. A policy might specify that only managers can see employee salary fields, or that incident descriptions cannot be modified after an incident is resolved. Policies provide granular access control that goes beyond role-based permissions.

Data policies are applied at the field level within records, making them more fine-grained than table-level permissions. You can make a field read-only on a record, or mandatory, when the record meets a condition. You can allow updates to certain fields while making others read-only. This granularity supports data governance and privacy requirements.

Where Data Policies Live in ServiceNow

Data policies are defined in the Data Policies application within ServiceNow’s administration area. The table that stores policy definitions is called sys_data_policy. Each policy includes a name, a description, the table it applies to, the fields it controls, conditions that trigger the policy, and the access rules it enforces.

When you create a data policy, you specify which table it applies to, which fields it controls, and what access restrictions it imposes. Conditions define when the policy is active. For example, a policy might say that the salary field in the employee table is read-only when the record has been archived. Another policy might say that only human resources staff can modify certain employment fields.

The data policy engine evaluates policies every time a user accesses a field. If an applicable policy exists, the system enforces the restrictions the policy specifies. The user sees a message indicating that the field is restricted, rather than simply failing silently.

A Worked Example: Incident Resolution Policy

Suppose your organisation wants to prevent users from modifying incident descriptions after an incident has been resolved. This prevents the historical record from being altered after the incident is closed. You would create a data policy that specifies: table equals incident, field equals description, condition is state equals resolved, and access rule is read-only.

When an incident is being worked on, users can edit the description freely. Once the incident is marked resolved, the system applies the policy and the description becomes read-only. Users can still view the description, but they receive an error if they try to modify it. If a user needs to correct the description after resolution, they must re-open the incident or request an exception.

Another policy might specify that only the incident’s assigned person or their manager can modify the short description. This prevents other users from changing how the incident is described. Multiple policies can apply to the same field, and the most restrictive policy takes precedence.

Common Misunderstandings About Data Policies

A frequent misunderstanding is thinking that data policies are the same as table-level access controls. Table-level permissions determine whether a user can see a table at all. Data policies restrict access to specific fields within records a user has access to. A user might have access to the incident table but be restricted from viewing or modifying certain incident fields.

Another confusion is assuming that data policies affect how data is stored. Policies control access to data; they do not determine how data is stored or validated. Data validation rules, if-then logic, and data formats are separate from data policies.

Some organisations incorrectly assume that data policies can be written to reference external data sources or perform complex calculations. Policies operate based on the data in the record and simple conditions. Complex logic typically requires workflow or automation.

Implementing Data Policies for Governance

Data policies support organisational governance by making access rules explicit and auditable. When a user cannot modify a field, the system logs that the policy prevented the action. Over time, audit logs provide evidence of how policies are being enforced.

Policies can be conditional, meaning they apply only under specific circumstances. This flexibility allows you to create nuanced access rules that respond to record state and other factors. A field might be required during creation but read-only after the record is submitted. Another field might be visible only to certain teams depending on the record’s assignment.

Performance implications apply to data policies. Evaluating many policies on each field access can impact response time if policies are complex or numerous. Most organisations maintain reasonable numbers of policies and avoid policies with complex conditions that require expensive lookups.

Picking the right tool before restricting a field

A request to hide or lock a field often arrives as a request for a data policy, but a data policy is only one of three mechanisms that can change what a user sees or edits. An access control rule decides whether a user can read or write a field at all, and it is evaluated on the server. A UI policy changes how a form presents a field, such as making it mandatory or read-only in the browser, and it does not stop a user who reaches the record through a list, an API or an import. The data policy sits between them: it enforces field restrictions on the record itself and applies to the data the user touches, whatever screen they used. Choosing the wrong one produces a field that looks locked on the form and remains editable through a list, which is a common complaint after go-live.

Mechanism	Where it is enforced	Good use	Gap to watch
Access control rule	Server, for every read or write path	Hiding a field from a whole role group	Heavy use across many fields makes diagnosis slow
UI policy	Browser form only	Guiding a user through a form, such as showing a field when a choice is made	Gives no protection against lists, imports or integrations
Data policy	Record level, with conditions on the record’s own values	Making a field read-only once a record reaches a given state	Conditions must be simple, and the policy must be tested through every write path

Testing a policy before it reaches a shared instance

Data policies are easiest to get wrong when they are tested only from the form that the author uses. Test from at least three paths: the record form, a list with inline editing turned on, and a background script or import that writes the same field. Run each test as a user from the role the policy is meant to affect, and as a user who should be unaffected, and record what happens in each case. A policy that blocks the form but lets an import overwrite the value has not restricted the field; it has only changed the screen.

1. Write the restriction as a sentence that names the table, the field, the condition and the group affected. If the sentence needs a second condition, reconsider whether the policy is the right mechanism.
2. Create the policy in a sub-production instance and set its condition against a record in a known state.
3. Test the form, the list, the import set and any scheduled job that writes the field, recording the outcome for each path.
4. Check the audit trail for the blocked attempts, so you can show that the restriction was enforced and not merely displayed.
5. Promote the policy with a change record that names the business owner who asked for the restriction.

When a restriction breaks an integration

An integration account that writes to a restricted field is a situation that often causes a sudden outage after a policy goes live. The integration often runs under a service identity that the policy did not anticipate, and its failures appear in the integration log rather than on any form, so the support desk sees a vague error about a data problem. Before enabling a policy on a table that integrations write, list every identity that writes to it, and decide with the owner whether the identity should be exempt, whether the integration should be changed to write through an approved path, or whether the restriction is worth the disruption. Do not add exemptions quietly. An unexplained exemption is one of the first things an auditor asks about.

Conditions that stay readable

A policy condition that compares the record with three other tables and a calculated value is difficult to read, slow to evaluate and almost impossible to explain to a reviewer. Keep conditions to the record’s own fields where possible. If the restriction truly depends on another table, consider a flag set by a workflow when the other condition changes, so the policy reads a simple value. That design takes longer to build, but the person who inherits the policy in two years can still understand it.

Questions a governance review should ask

• Which identities write this field today, including integrations, scheduled jobs and imports?
• Does the restriction stop the write, or only hide the field on one screen?
• Who can change the condition, and is that change logged for review?
• If the policy is removed tomorrow, does any other control depend on it?

Why a data policy is sometimes the wrong answer

Data policies are not a substitute for classifying data or deciding who should own it. If the real problem is that too many people hold a broad role, fixing the role model often removes the need for many field policies. Similarly, a restriction that is needed only during a short project is better handled by a temporary access change with an end date than by a policy that someone must remember to remove. Use the policy when the restriction is durable, field-specific and tied to the state of the record.

Frequently asked questions about data policies

Why can a user still see a value that the policy hides on the form?

The field may be visible through a report, a related list, a web service or a view that the policy does not cover. Trace the path the user took. The answer is often a read path that the policy was never written to govern, and the fix is either a wider control or a clear statement to the business that the value is visible elsewhere.

Can a data policy protect a field from the administrator who created it?

Administrators with broad platform rights can change or remove policies. A data policy is a control for everyday users, not a guarantee against a privileged person. Pair it with change control on the policy records and with audit review of who edits them.

What happens when two policies apply to the same field?

The more restrictive outcome generally applies. Document the intended combined behavior, because a policy written later can quietly make an earlier one irrelevant, and the people who wrote the earlier one may not know it has changed.

Should we record why each policy exists?

Yes. Store the business reason in the policy description and link the change record. For classification, see the data classification workflows article. A policy without a stated reason is more likely to be deleted during a clean-up and then requested again six months later.

Next step

If a restriction has been requested but nobody has traced its write paths, do that mapping first.