Troubleshooting ServiceNow Policy and Compliance Management: A Practical Guide

This guide works through Policy and Compliance Management problems by symptom. For each one it gives where to look in the platform, the likely causes and the fixes, starting with policies that do not reach their audience and users who cannot acknowledge them.

Policy Distribution Is Incomplete or Delayed

Symptom: A policy is published but some teams do not see it in their portal, or it takes days to appear after publication. Users report that they never received notification that a new policy exists.

Where to look: Check the policy record for target audience scope. Policies in PCM are distributed to users or groups via a targeting rule: by department, by role, by location or by explicit assignment. If the targeting rule does not include a team, they will not see the policy. If notification is enabled, check the notification rule: does it fire for all policy states or only after a specific approval state?

Likely causes: The target audience was set too narrowly (e.g., only a specific department when the policy applies company-wide). The notification rule is configured to fire only after approval, but the policy remains in draft. Batch jobs that distribute policies run on a schedule (e.g., nightly); a policy published at 5 PM may not be visible until the next morning.

Fixes: Widen the target audience scope to include all affected users. Publish the policy before expecting notifications; do not expect notifications for draft policies. If instant visibility is needed, configure the system to run distribution jobs on demand rather than on a schedule. Test with a pilot audience before expanding to everyone.

Users Cannot Acknowledge Policies

Symptom: Users click the acknowledge button on a policy but the acknowledgment does not register. The system shows no evidence that they acknowledged the policy, even though they received it.

Where to look: Check the policy acknowledgment workflow in PCM. Acknowledgment requires a workflow that listens for the acknowledge action and records it. If the workflow does not exist or is inactive, the button might be visible but non-functional. Also check permissions: does the user’s role have permission to submit acknowledgments?

Likely causes: The acknowledgment workflow is not activated or is misconfigured. The user’s role is missing the “acknowledge policy” permission. The policy itself is set to read-only or does not allow acknowledgment. Database corruption or a recent system update broke the acknowledgment process.

Fixes: Verify the acknowledgment workflow is active and correct. Grant the needed permission to user roles that should acknowledge policies. Test acknowledgment with a known-good policy in a test environment. If the problem persists, check the system logs for errors during acknowledgment submission.

Compliance Reports Show Incorrect Data

Symptom: A report shows that all policies have been acknowledged by all users, which is clearly untrue. Or the report shows users who left the organisation as still due for acknowledgment.

Where to look: Check the data in the policy acknowledgment table (usually a record of every acknowledgment event). Compare it with the user table and policy table. If acknowledgment records exist for users who no longer exist, or if old acknowledgments are still counted as current, the data has drifted.

Likely causes: The reporting query is incorrect (e.g., it counts all acknowledgments, not just the most recent one per user-policy pair). User records were deleted but their acknowledgment records were not. Policies were deleted and their acknowledgment history was lost. The acknowledgment table grew very large and queries are slow or timing out.

Fixes: Review the report query and correct it to count only the latest acknowledgment per user and policy. Archive old policies instead of deleting them, preserving their acknowledgment history. Delete orphaned acknowledgment records for users no longer in the system. If performance is an issue, partition the acknowledgment table or archive old data to a data warehouse.

Policy Changes Are Not Tracked or Versioned

Symptom: A policy was updated, but there is no record of what changed, who changed it or when. The system shows only the current version.

Where to look: Check the policy record for a change log or version history feature. ServiceNow policies can include audit fields (created date, modified date, modified by) but some systems do not track detailed change history. Check whether the policy module is configured to use the audit log table.

Likely causes: Policy auditing is not enabled in the system configuration. The policy module does not track historical versions. Changes were made in a way that bypassed the audit log (e.g., via API with audit disabled). The audit log was purged to save space.

Fixes: Enable audit logging for policy records if your instance supports it. Configure the system to create a new version each time a policy is published, preserving the previous version. Train users to use the policy workflow (draft-publish-retire) rather than editing a live policy. If audit data was purged, restore from a backup if possible. For the future, retain audit records for at least the compliance period required by your regulations.

Acknowledgment Deadlines Pass Without Escalation

Symptom: A policy has an acknowledgment deadline (e.g., all staff must acknowledge by end of month), but the system does not remind non-compliant users or escalate to managers.

Where to look: Check the policy workflow and notification rules. Escalation typically requires a scheduled job that runs before the deadline and sends reminders to users who have not yet acknowledged. If no job is configured, no reminders are sent.

Likely causes: The escalation rule was not created. The scheduled job is disabled or failing. The notification rule has no recipients specified (e.g., the manager field is empty on the user record). The job runs but notifications are not sent because the users are inactive or deleted.

Fixes: Create a scheduled job that runs ahead of the deadline, at a lead time agreed with the policy owner, identifies users who have not acknowledged, and sends them a reminder. Create a second job that runs at the deadline and escalates non-compliant users to managers or compliance. Test with a small pilot group before applying company-wide.

Policies Are Not Linked to Compliance Obligations

Symptom: The compliance department needs to report on which policies satisfy which regulatory requirements, but the system has no way to make that connection. Auditors ask “which policies cover GDPR?” and the answer is a manual search or guess.

Where to look: Check the policy records for a field linking policies to compliance requirements or regulations. This link might be a related record, a multi-select field, or a separate compliance mapping table. If the field does not exist, it needs to be created.

Likely causes: The policy template does not include a compliance mapping field. Policies were created without being linked to compliance requirements. The compliance requirements themselves are not defined as records in the system.

Fixes: Add a field to policy records that links to a compliance requirement or regulation. Create records for each compliance requirement (GDPR, HIPAA, SOX, etc.). As policies are created or updated, populate this field. Use this linking in reports to answer questions like “which users must acknowledge which policies to satisfy this requirement?”

Policy Portal Is Slow or Not Indexing

Symptom: The policy portal page takes 30 seconds to load. Search for policies returns no results even though policies exist.

Where to look: Check the policy query performance and search indexing. Large policy tables with complex targeting rules can be slow. If search is not indexed, every query does a full table scan.

Likely causes: The policy table has grown very large (thousands of policies). Search is not indexed or indexes are stale. The targeting rules are complex and require computation for every query. The portal is running an inefficient query.

Fixes: Archive old, retired policies to reduce the active table size. Create database indexes on commonly searched fields (title, policy number, target audience). Simplify targeting rules if possible or pre-compute targeting at index time rather than at query time. Move policy search to a dedicated search service if performance does not improve.

Triaging a policy module problem before changing any configuration

When a policy complaint reaches the compliance team, the instinct is to open the configuration and start changing things. That habit can turn a single missing acknowledgment into a week of altered rules and a report nobody can explain. Start by sorting the complaint into one of three groups: a distribution problem, a recording problem or a reporting problem. Each group has a different owner and a different first check, and much misdiagnosis happens when a reporting symptom is treated as a configuration fault. Where a complaint turns on who can see a record, the security and access design page is the next stop.

Matching the symptom to the first check

An ordered approach when the cause is unclear

1. Write down the exact symptom, who reported it and the time it was first seen. Vague reports cannot be tested.
2. Reproduce it with a test account in the same group as the reporter. If you cannot reproduce it, the cause is probably in the data rather than the code.
3. Check the record, not the report. The report is a view of the data, so a fault in the view can look like a fault in the data.
4. Only then open the configuration, and alter a single setting per attempt, logging each change against the ticket.
5. Confirm the fix with the original reporter and with one additional user from a different group.

When to stop and escalate instead

Some faults should not be fixed by the compliance team at all. If acknowledgment records are missing for a period, stop changing the module and preserve what is left, because a repair that overwrites history can damage the evidence. Similarly, if a policy was published to the wrong audience, the notification has already gone out and the correction needs a communication decision as well as a configuration one. Escalate to the platform owner and the policy owner together, and record the decision before any data is altered.

Questions people ask when a problem recurs

Why does the same problem come back after it was fixed?

Often because the fix addressed the symptom in one group and the cause sits in a shared rule, such as a targeting definition that other policies also rely on. Trace the rule to every policy that uses it before calling the problem closed.

Should we copy the production configuration into a test instance to investigate?

Only with personal data removed or pseudonymized, and only if the test environment is restricted to the same people who may view the production records. Copying named acknowledgment records into a wider sandbox creates a new exposure.

Who should log a policy module incident?

Anyone who sees the symptom should be able to, but the compliance administrator should own the record. A single owner keeps the timeline coherent when several people report the same fault.

Next step

For the set-up choices that prevent many of these faults, the testing and acceptance checklist covers checks that can be run before go-live.