ServiceNow Policy and Compliance Management: Security and Access Design

Policy Lifecycle Access Requirements

Policy and Compliance Management handles organizational policies and tracks who has acknowledged or accepted them. Different roles interact with policies at different lifecycle stages. Policy Authors create initial policy drafts. Policy Owners (usually department heads) are accountable for their policies and must approve changes. Compliance Managers oversee the entire policy program and approve new policies before they are published. Employees read policies and provide acknowledgment. Auditors and Compliance Teams review acknowledgment records to verify compliance.

Creating and Approving Policies

Separate policy creation from approval to prevent unauthorized policy changes. Policy Authors can create draft policies and propose revisions to existing policies. The Policy Owner for the affected area reviews the draft and confirms accuracy. Compliance Manager reviews for regulatory implications and consistency with other organizational policies. Only the Compliance Manager can publish a policy (make it active and require employee acknowledgment). This separation ensures multiple eyes review policies before they become binding on the organization. Document approval workflows in ServiceNow so that policies do not get stuck in review. Track how long policies remain in draft status; policies stalled in approval waste effort and can block necessary updates.

Read and Acknowledge Access for Employees

Employees need read-only access to policies that apply to them. Grant access by role, department, or organization so that employees see only policies relevant to their work. For example, employees in the Finance department should see Finance policies, and only Finance policies (not HR or Security policies that do not apply to them). When policies are published, automatically notify affected employees. Track which employees have read and acknowledged each policy. If an employee leaves the organization, their acknowledgment record should remain for audit purposes (they were required to acknowledge and complied at the time), but they should lose access to create or modify future acknowledgments.

Segregation of Duties in Policy Review

Do not let one person write, approve, and audit their own policy. Separate these roles: the Policy Author writes it, the Policy Owner approves it for accuracy, the Compliance Manager approves it for regulatory compliance, and auditors verify that the approval chain was followed correctly. If there is a conflict (for example, Policy Owner and Compliance Manager disagree), escalate to the executive sponsor or Chief Compliance Officer. This structure prevents individuals from hiding policy issues or creating policies that benefit themselves at the organization’s expense.

Managing Policy Versions and Acknowledgment Records

When a policy is updated, the previous version should remain accessible for audit and legal purposes. Employees who acknowledged the old version should re-acknowledge the new version. Track which policy version each employee acknowledged so that if a dispute arises (for example, an employee claims they did not know a requirement), you can show them the version they acknowledged and when. Retain acknowledgment records for years after the policy changes, for as long as the compliance frameworks that apply to you require.

Audit Evidence and Access to Compliance Data

Maintain audit logs showing: when policies were created and by whom, when changes were made and approved, when policies were published and became effective, and when employees acknowledged policies. Internal Audit needs access to acknowledgment records to verify compliance; they do not need access to author policies. Finance does not need access to HR policies. Restrict access to compliance data based on role and the specific policies someone manages or audits. Compliance Managers and Internal Audit need read access to all policies and acknowledgment records for comprehensive oversight.

Handling Policy Exceptions and Waivers

Occasionally, employees or business units need exceptions to policies (for example, a work-from-home policy may have exceptions for certain roles). Create a formal process for policy waivers: request, approval, duration, and re-review. Grant waiver approval authority carefully; usually only the Policy Owner and Compliance Manager can approve waivers. Maintain a waiver log so that audit can see which policies have active exceptions and why. Require waivers to have an expiration date; permanent exceptions defeat the purpose of having policies. Review waivers quarterly to determine if they should be renewed or if the policy itself should be changed to accommodate the exception.

Access During Offboarding

When an employee leaves, remove their ability to create future acknowledgments promptly. Their historical acknowledgment records should remain for compliance verification but should be marked as read-only so they cannot be modified. If a departing employee is a Policy Author or Owner, reassign ownership to an active employee and provide the new owner with context and documentation.

Reviewing who can see acknowledgment data before it is exposed

The acknowledgment records in a policy module are personal data. They show who was asked to read a document, when they responded and sometimes which version they saw. That is useful to an auditor and sensitive for everyone else, so the first access question is not which role can open the module but which role can see a named individual’s record. Answer that question for each population before any roles are configured, because the answer shapes the data model as well as the permissions.

An access matrix to build before go-live

An ordered access review for the policy module

1. Pull the current role list with the members of each role. Mark any role that lets a user both create and approve the same policy family.
2. Check the access control rules on the acknowledgment table separately from the policy table, because the policy table can be locked down while the acknowledgment table inherits a broader default.
3. Test the portal as an ordinary employee, a line manager and a contractor. Confirm each sees only the policies in their scope and no one else’s acknowledgment history.
4. Test a leaver. Confirm the account can no longer acknowledge anything, while historical records remain intact and read-only.
5. Record the results and the person who accepted any residual risk, then schedule the next review against the same checklist.

When a line manager should see acknowledgment status

Managers have a legitimate need to know whether their own team has read a policy that applies to them, because they are often the ones who follow up. They do not need the content of each acknowledgment event, the version history of the policy or the records of people outside their line. A practical design gives the manager a filtered view of completion status for direct reports and nothing else. Where a regulator expects managers to act on non-completion, document that expectation in the policy itself so the access is tied to a stated duty.

Common security gaps in policy programs

Three gaps often appear. The first is an integration account, such as a sync from the HR system, that has write access to every policy and every acknowledgment, which is more than the sync needs to do its job. The second is a reporting export that carries named records into a shared folder for a one-off audit and is then forgotten there. The third is a contractor population given the same portal role as employees even though the policies they must accept differ. Each of these is cheap to fix when found early and awkward to explain to an auditor once it has been running for some time.

Questions that surface during access design

Should auditors be able to edit policies they are testing?

No. Auditors need read access to the text, the version history and the acknowledgment records. If they can change the policy under review, the audit trail stops being independent, and the finding is weakened for everyone.

How long should acknowledgment records be retained?

Retention is a legal and regulatory decision, not a platform default. Agree the period with legal, record it in the retention schedule, and make sure archived records keep their version references so they can still be explained.

Can an employee see who else acknowledged a policy?

Normally no. Showing peers their completion status invites comparison and pressure, and it reveals information about people who may have legitimate reasons to be behind, such as a period of leave.

What is the minimum evidence to show a regulator that access is controlled?

A current role matrix, a dated record of the last access review with its findings, and evidence that the leaver process removed write access on the day of departure. Those three items can answer many of the questions that come up.

Next step

For the general approach to reviewing platform permissions, see the platform access review article, and the security operations consulting page covers how a wider security posture is assessed.

Policy and compliance tables, roles and access names to review

Access design for policy work comes down to separating who can edit a policy, who can approve it and who can only read it. In ServiceNow that separation is enforced by roles and access control rules on the policy tables, so the first job is to list those tables and roles and test them with real users.

These are common out-of-box names. Check them on your own instance, plugin version and release, since scoped application names and role lists can differ.

A policy lifecycle may include states such as Draft, Review, Published and Retired, depending on release and configuration, and some releases add approval states. Map each state to the role allowed to move a record into it, then confirm that no single account holds the roles for both Draft and Published.

Example (hypothetical): create three test users: an author, a department owner and a plain employee. Impersonate each in turn. The author should be able to edit a draft but not publish it, the owner should approve but not edit statements, and the employee should see only published policies for their own department. Any result that differs is an access rule or role assignment to fix before go-live. The wider instance security and access control page covers the wider access model.

Which table stores the access rules I need to change?

Access control rules live in the sys_security_acl table and are normally reached through the Access Control (ACL) module under System Security. Each rule combines an operation, a role requirement, an optional condition and an optional script, so read all four before editing.

Can I test access without a second login?

Yes, impersonate a test user from the user menu and open the policy list as that person. Do not use real employee accounts for this. Keep a small set of named test users per role and reuse them at each release.

How do control records differ from policy records for access?

Policies are written for a wide audience, controls are written for testers. Many teams give employees read access to published policies only, and limit controls to compliance and audit roles. The audit management page covers the audit work that follows control testing.