Policy Lifecycle Management in IRM: One Governed Workflow

Mary Hain · ‎06-29-2026

Every organization has policies, but many are scattered across SharePoint folders, email threads, and shared drives. The result is weak version control, limited evidence of employee acknowledgment, and no clear link to the controls those policies are intended to enforce.

Policy Lifecycle Management on ServiceNow closes this gap by bringing policy authoring, approval, publishing, and versioning into one governed workflow. Because the workflow runs on the same platform as controls, risks, and evidence, employee acknowledgments and compliance score rollups are built in.

Within GRC: Policy & Compliance Management, Policy Lifecycle Management (PLM) governs how policies are authored, approved, published, versioned, and retired on the Now Platform. It provides a single source of truth, a controlled workflow from draft through retirement, and direct traceability from policy commitments to the control objectives and controls that demonstrate compliance.

This Speed Learning focuses on the core policy lifecycle: author → approve → publish → version. Its structural backbone consists of three components:

Policies: Organizational commitments that define expected behavior.
Control Objectives: Actionable, measurable compliance targets that connect policies to controls.
Controls: Activities, tests, and evidence that demonstrate whether an objective is met.

Seven policy types — Policy, Procedure, Standard, Plan, Checklist, Framework, and Template — help compliance teams organize the library by document purpose. Users can manage the same lifecycle through either the Classic UI or the Compliance Workspace; Workspace provides a cleaner, task-focused experience for compliance managers and analysts. Related capabilities, including acknowledgment campaigns, policy exceptions, evidence requests, issue management, and GRC case management, are covered in separate Speed Learnings.

Watch the Policy Lifecycle Management video in the Policy Management playlist on YouTube for an end-to-end walkthrough.

How it works

Author a Policy

Authors begin in the Policy & Compliance register. Every new policy opens in Draft, and the fields completed at creation determine how it moves through the lifecycle.

Policy content can be added in three ways:

Manual entry: Type or paste content directly into the policy text field.
Word document upload: Attach a .docx file, and the system extracts and populates its text. Available from Xanadu.
Cloud document connection: Link a live OneDrive, SharePoint, or Google Drive document for real-time collaborative authoring and redlining. This option is covered in a separate Speed Learning.

Organize Policies and Map Controls

Organize policies by parent-child hierarchy and by type or category. For example, an Information Security Policy can serve as the parent for an Access Control Procedure and a Data Classification Standard. Plan the taxonomy before building the library so it remains easy to navigate and report on at enterprise scale.

Map every policy to at least one Control Objective. Without this connection, the policy cannot receive compliance score rollups, provide exception defaults, link to entities, or display its controls in the published Knowledge Base article. Control objectives can originate top-down from authority documents such as ISO 27001, NIST, or SOC 2 through citations, or bottom-up from the policy itself.

Move Through the Policy Lifecycle

The manual lifecycle includes five states, each with defined responsibilities:

Draft: The author or owner creates the policy, assigns its type, owner, and Valid To date, links or creates control objectives, and identifies reviewers and approvers.
Review: Reviewers (owner, owning group, and assigned to) validate control objectives, entities, controls, and citations. Reviewers can return the policy to Draft when they identify gaps. The owner selects Request Approval to advance it.
Awaiting Approval: Approvers act from the Approvals task page. If no approver is assigned, the system publishes automatically. Approval moves the policy to Published; rejection returns it to Review.
Published: The policy becomes active, controls are tested, and a Knowledge Base article is generated automatically. The Valid To timer runs in the background.
Retired: An administrator or manager retires the policy. The Knowledge Base article is removed, control objectives become inactive, and controls tied to manually created control objectives are retired.

Choose an Approval Model

Select Approvers: Assign named approvers directly on the policy record. This option is simple and direct but does not support conditional routing.

Use Approval Rule: Route approvals by policy type, category, or functional domain through the GRC Approval Configurator. It supports sequential approval levels and parallel approver groups, making it the preferred option for complex enterprise approval matrices.

Publish and Enable Employee Discovery

When a policy reaches Published, ServiceNow automatically creates a Knowledge Base article in the GRC knowledge base using the configured article template. Employees can find policies through Knowledge Base search, global platform search, and Employee Center, where they can view, acknowledge, or request an exception without leaving their usual tools. To surface published policies in Employee Center, run the Pull the knowledge base articles related to policies scheduled job.

Manage Versions and Audit History

Published policy versions are immutable. To make a change, create a new revision. Use a major revision for a substantive change in policy intent; when associated control objectives are also treated as major, linked controls return to Draft for revalidation. Use a minor revision for corrections or wording changes that do not require revalidation. Because the system does not enforce revision type, reviewers must confirm that the selected type is appropriate. The Policy Versions tab and Knowledge Base article history provide the complete audit trail.

Manage Policy Validity

A published policy does not remain active indefinitely. When its Valid To date is reached, a configurable grace-period timer starts. The policy then returns to Review when reviewers are assigned, or to Draft when none are assigned. Republish the policy to retire the previous Knowledge Base article and create a new version. Many organizations configure the timer to run before expiration to avoid a coverage gap; confirm the exact behavior for your release and instance.

Roll Up Compliance Scores

Scores roll upward from control test or attestation results to the control objective, entity, and policy levels. The entity hierarchy-based scoring property determines the calculation method:

FALSE (default): the entity score is the average of its direct controls only.
TRUE: the entity score averages downstream entity scores together with direct controls.

Exempt controls and controls under exception are excluded from the denominator. Choose the mode deliberately, because the same program can produce significantly different results under each method.

Why it matters

When policies are managed outside a governed platform, three recurring problems undermine the program.

Policy sprawl and version confusion: Multiple copies circulate across SharePoint, email, and shared drives, leaving employees unsure which version is current and auditors unable to confirm what was in force at a given time. PLM establishes one authoritative source, with immutable, version-stamped publications traceable to approvers and dates.
Policies disconnected from controls: A policy that is not mapped to control objectives cannot generate a compliance score, scope testing to the right entities, or support exception workflows. PLM makes this mapping foundational so downstream governance processes have a clear anchor. Policy exceptions are covered in a separate Speed Learning.
No proof of acknowledgment: Auditors need evidence that employees read and accepted a specific policy version — not merely that an email was sent. Acknowledgment campaigns in Employee Center track each response and create an auditable record of who acknowledged, when, and under which version. Policy acknowledgment is covered in a separate Speed Learning.

The platform advantage is integration. Compliance scores, issues, evidence requests, and exceptions all connect to the published policy on the same platform. A failed control test links directly to the governing policy, and supporting evidence remains on the same record for audit review. This connection transforms a policy document into a continuously governed, measurable program.

FAQ: Policy Lifecycle Management

Lifecycle and States

What happens when a policy's Valid To date is reached?

By default, 30 days after the Valid To date — or according to the value of the sn_compliance.policy_expiry_to_review_timer property — the policy moves to Review when reviewers are assigned, or to Draft when none are assigned. It remains Published until the timer runs. Many organizations schedule the transition before expiration to avoid a coverage gap; confirm the exact behavior in your instance.

Can I edit a published policy without completing the full review and approval cycle?

No. Published policies are read-only. Select Edit Policy to move the policy to Draft, make the change, and complete the Review and Approval cycle again. Validate the content thoroughly before publishing to avoid unnecessary rework.

What happens to the Knowledge Base article and controls when a published policy returns to Draft?

The current Knowledge Base article remains published while the new revision is being edited. Controls remain in their existing states unless policy mappings change or a major revision requires revalidation. Republishing creates an updated Knowledge Base article version.

What happens to the Knowledge Base article when I retire a policy?

Retiring the policy removes its Knowledge Base article from publication and makes its control objectives inactive. Controls tied to manually created control objectives are retired; controls tied to authority-document-sourced control objectives are unaffected.

Authoring and Structure

What is the difference between Policy, Procedure, Standard, and the other types?

ServiceNow provides seven classification types: Policy, Procedure, Standard, Plan, Checklist, Framework, and Template. These types do not change system behavior; the required field supports semantic and organizational grouping within your governance taxonomy. Choose the type that best reflects the document's role in your compliance program.

How do parent-child policy relationships work?

Policy hierarchy is organizational only — child policies do not inherit controls from a parent. Use the parent field to group related documents, such as an Information Security Policy with Password Policy and Access Control Procedure children. Use control objectives and controls, rather than hierarchy, to define compliance scope.

Should every policy be related to a control objective?

Yes — it's foundational, for the same reasons covered above (score rollups, exception defaults, entity links). The piece not covered there: a policy's controls only display in its published Knowledge Base article once that mapping exists.

Approvals and Roles

Which roles are required to author and approve policies?

Authors need sn_compliance.user or a higher role. The same role is the minimum required to select Request Approval, although sn_compliance.manager is the typical approver role. When using GRC Feature Roles, sn_compliance.policy_user can create policies, while sn_compliance.policy_manager manages the full lifecycle and configures approval rules.

Select Approvers or Use Approval Rule — which should I use?

Select Approvers is simple but doesn't scale. Use Approval Rule is the better choice once you have more than a handful of policies, since conditions such as policy type, category, or functional domain determine who must approve — recommended for complex or multi-level approval requirements.

Versioning and History

How does policy history work, and what is tracked?

Policy history records each published cycle, including the policy name, version number, reason for change, owner, approvers, reviewers, Valid To date, attached document, and approval date. Access it from the Policy History related list on the policy record. The history is immutable and remains available even if the policy is retired or deleted. Knowledge Base article history provides parallel, employee-facing traceability.

Scoping and Compliance Scores

Are policies organization-wide, or can they be scoped to specific entities?

Published policies are organization-wide. Scoping occurs at the Control Objective and Control levels: publish the policy globally, then map specific control objectives to the entities where they apply. Policy-level scoping may be sufficient for simple, single-entity programs; control-objective-level scoping is the recommended pattern for multi-entity governance.

Which compliance-score calculation mode should I choose?

The scoring mechanics are the same ones covered above — scores roll from controls to control objectives, entities, and policies. Choose TRUE specifically for hierarchical entity structures, such as regional subsidiaries, where child-entity performance should count toward the parent's score; otherwise FALSE (the default) is usually the right call.

Some useful resources

Visit the ServiceNow product documentation or join the conversation on the ServiceNow GRC Community to discuss Policy Lifecycle Management with other ServiceNow practitioners.