Policy Lifecycle Management in IRM: Closing the gap on a single, governed policy workflow

Mary Hain · 3 hours ago

Every organization has policies — but most live scattered across SharePoint folders, email threads, and drives, with no version control, no proof that anyone read them, and no clear connection to the controls they're supposed to enforce.

Policy Lifecycle Management on ServiceNow closes that gap. It turns policy authoring, approval, publishing, and versioning into a single governed workflow on the same platform as your controls, risks, and evidence — with employee acknowledgment built in and compliance scores that roll up automatically. Watch the <recording link> in the <playlist link> on YouTube to explore the full capability end-to-end.

Policy Lifecycle Management (PLM) is the capability within GRC: Policy & Compliance Management that governs how organizational policies are authored, approved, published, versioned, and retired — all on the Now Platform. It provides one authoritative source of truth for every policy, a governed workflow from first draft to retirement, and a direct traceability path from policy commitment to the control objectives and controls that prove compliance.

The scope of this Speed Learning is the core policy lifecycle: author → approve → publish → version. Three components form the structural backbone: Policies (organizational commitments that define expected behavior), Control Objectives (actionable, measurable compliance targets that sit between policy and control), and Controls (the activities, tests, and evidence that prove an objective is met). Related capabilities — acknowledgment campaigns, policy exceptions, evidence requests, issue management, and GRC case management — each have their own dedicated Speed Learning.

Seven policy type classifications (Policy, Procedure, Standard, Plan, Checklist, Framework, Template) let compliance teams organize their library by document role.

Two UI paths — Classic UI and the Compliance Workspace — give different personas access to the same lifecycle, with Workspace offering a cleaner, task-focused experience for compliance managers and analysts.

Watch the Policy Lifecycle Management video in the Policy Management playlist on YouTube to explore the full capabilities.

How it Works

Authoring a policy

Authors start in the Policy & Compliance register. Every new policy opens in Draft state. Key fields set at creation define how the policy flows through the rest of the lifecycle.

Three methods bring policy content in without manual retyping:

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

Hierarchy, grouping, and control mapping

Policies are organized in a parent-child hierarchy (e.g., an Information Security Policy parent with Access Control Procedure and Data Classification Standard children) and by type/category (e.g., Security Policies, Privacy Procedures). Plan the taxonomy before building — hierarchy and grouping are how enterprise-scale libraries stay navigable and reportable.

Every policy should be mapped to at least one Control Objective. Without that mapping, there is no compliance score rollup, no exception defaults, and no entity-policy linkage. Control objectives flow in two directions: top-down from authority documents (ISO 27001, NIST, SOC 2) via citations, or bottom-up created directly from a policy.

The lifecycle — states, roles, and what moves between them

The manual policy lifecycle runs five states, each with defined actors:

Draft: Author or owner creates the policy, sets type, owner, and Valid To date, adds or creates control objectives, and names reviewers and approvers.
Review: Reviewers (owner, owning group, and assigned reviewers) validate control objectives, entities, controls, and citations. They can return the policy to Draft if gaps are found. The owner clicks Request Approval to advance.
Awaiting Approval: Approvers act in the Approvals task page. If no approver is assigned, the system auto-publishes. An approved policy advances to Published; a rejected policy returns to Review.
Published: The policy is active and controls are under test. A Knowledge Base article is auto-generated. The Valid To timer runs in the background.
Retired: Admin or Manager retires the policy. The KB article is removed. Control objectives go inactive; controls associated with manually created control objectives are retired.

Approvals — standard vs dynamic

Standard approvals assign approvers manually on the policy record — simple and direct, no conditional logic.

Dynamic approvals, powered by the GRC Approval Configurator, apply rule-based routing based on policy type, category, or functional domain, support multi-level sequential approvals, and run parallel approver groups. For enterprise deployments with complex approval matrices, dynamic approvals are the recommended path.

Publishing, KB auto-generation, and employee discovery

When a policy reaches the Published state, ServiceNow automatically creates a Knowledge Base article in the GRC knowledge base, styled by the configured article template. Employees discover policies through KB search, global platform search, and the Employee Center — where they can view, acknowledge, or request an exception in context, without leaving the tools they already use. Run the Pull the knowledge base articles related to policies scheduled job to surface published policies in the Employee Center.

Versioning — Major, Minor, and the audit trail

Every published policy version is immutable. To change a published policy, raise a new revision. Major revisions signal a substantive change to policy intent — associated control objectives should be treated as Major, which returns linked controls to Draft for re-validation. Minor revisions, such as corrections or rewording, trigger no re-validation. Revision type is reviewer judgment, not field-enforced — reviewers can reject a mismatched type. The Policy Versions tab and the KB article version history provide the full immutable audit trail.

Policy validity and the valid to date

A published policy does not stay published indefinitely. When the Valid To date is reached, a configurable grace-period timer fires. The policy auto-returns to Review if reviewers are assigned, or to Draft if none are. Re-publishing retires the previous KB article and creates a new version. Field practice often configures the timer to fire before expiry to avoid a coverage gap — validate the exact behavior in your release and instance.

Compliance score rollup

Scores propagate upward: a control's pass or fail from testing or attestation rolls up to its control objective as a percentage, then to the entity and policy level. Two calculation modes are governed by the entity hierarchy-based scoring property: FALSE (default) — entity score equals the average of its direct controls only; TRUE — entity score equals the average of downstream entity scores plus direct controls. Exempt controls and controls under exception are excluded from the denominator. Pick the mode deliberately — the two modes can report very different numbers for the same program.

Why it matters

Policy programs fail in predictable ways when they run outside a governed platform. Three problems repeat across every organization that manages policies in documents and email:

Policy sprawl and version confusion. Multiple copies of the same policy circulate across SharePoint, email, and shared drives with no single authoritative version. Employees are reading outdated documents, and no one can prove which version was in force during a given period. PLM enforces one source of truth — every published version is immutable, version-stamped, and traceable to its approver and date.
Policy without controls is a statement, not a program. A policy that exists in a document but is not mapped to control objectives cannot generate a compliance score, cannot scope testing to the right entities, and cannot feed exception workflows. PLM treats the control objective mapping as foundational — without it, the downstream governance machinery has nothing to attach to. Policy exception is covered in a separate speed learning.
No proof of acknowledgment. Regulators and auditors ask for evidence that employees read and accepted the policy, not a list of who received an email. Acknowledgment campaigns, run through Employee Center, track every response individually and produce an auditable record of who acknowledged, when, and under which policy version. Policy acknowledgment is covered in a separate speed learning.

The platform advantage is integration. PLM does not operate in isolation — compliance scores, issues, evidence requests, and exceptions all connect back to the published policy on the same platform. When a control fails a test, the noncompliance is directly linked to the policy that governs it. When an auditor asks for the evidence behind a compliance status, it is on the same record, not in a separate system. That integration is what turns a policy document into a continuously governed, measurable program.

FAQ: Policy Lifecycle Management

Lifecycle & States

What happens when a policy's Valid To date is reached? 30 days after the Valid To date (configurable via the sn_compliance.policy_expiry_to_review_timer property), the policy auto-transitions to Review if reviewers are assigned, or back to Draft if none are. Until the timer fires, the policy stays Published. Field practice often sets the timer to fire before expiry to avoid a coverage gap — validate exact behavior in your instance.

Can I edit a published policy without going through the full review and approval cycle? No. Published policies are read-only. To make any change, click Edit Policy — the policy moves to Draft, then proceeds through the full Review and Approval cycle. Validate thoroughly before publishing to avoid unnecessary re-cycles.

If I move a published policy back to Draft, what happens to the KB article and controls? The KB article stays published — employees continue to see the current version while the edit cycle is underway. Controls remain in their current state (Monitor, Attest, etc.) unless policy mappings change or a Major revision triggers re-validation. Re-publishing updates the KB article with a new version.

What happens to the KB article when I retire a policy? Retiring the policy removes the KB article from publication. Control objectives go inactive. Controls associated with manually created control objectives are retired. Controls tied to authority-document-sourced control objectives are not affected.

Authoring & 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. There is no functional difference between them — type is a required field used for organizational and semantic grouping within your governance taxonomy. Choose the type that reflects the document's role in your compliance program.

How do policy parent-child relationships work? Do children inherit controls from parents? Policy hierarchy is organizational only. Children do not auto-inherit controls from their parent policy. The parent field groups related policies (for example, an Information Security Policy parent with Password Policy and Access Control Procedure children). Use hierarchy for taxonomy and navigation — controls and control objectives do the compliance scoping.

Should I always relate control objectives to policies? Yes. Mapping a policy to at least one control objective is foundational. Without it, you lose: unified governance packages, compliance score rollup to the policy, exception defaults, controls appearing in the published KB article, and entity-policy linkage. A policy with no control objective mapping is a document, not an enforced commitment.

Approvals & Roles

What role do I need to author and approve policies? Authors need sn_compliance.user or higher. The minimum role to click Request Approval is sn_compliance.user; Compliance Manager (sn_compliance.manager) is the typical approver in practice. If you are using GRC Feature Roles instead of application roles, the Policy User (sn_compliance.policy_user) role creates policies, and Policy Manager (sn_compliance.policy_manager) handles the full lifecycle, including approval rule configuration.

What is the difference between Select Approvers and Use Approval Rule? Select Approvers manually adds named approvers directly to the policy record — simple and direct, but does not scale. Use Approval Rule applies dynamic, rule-based routing via the GRC Approval Configurator, where conditions on policy type, category, owner, or functional domain automatically determine who must approve. For organizations with complex or multi-level approval requirements, rule-based approvals are the recommended approach.

Versioning & History

When should I use a major versus a minor revision? Major revision signals a substantive change to policy intent. When the associated control objective revision is also treated as Major, linked controls return to Draft for revalidation, triggering a full retest cycle downstream. Minor revision covers corrections or rewording only; no re-validation is triggered. Revision type is a reviewer judgment call, not enforced by the system, but reviewers can reject a mismatched type.

How does policy history work, and what gets tracked? Policy history captures each published cycle: policy name, version number, reason for change, owner, approvers, reviewers, Valid To date, attached document, and approval date. Access via the Policy History related list on the policy record. The history is immutable — retiring or deleting a policy does not remove its version history. The KB article version history mirrors it for employee-facing audit traceability.

Scoping & Compliance Score

Are policies organization-wide, or can I scope them to specific entities? Policies are organization-wide once published. Scoping happens at the Control Objective and Control level — publish the policy globally, then map specific control objectives to specific entities for enforcement. Controls do the scoping, not policies. For simple single-entity programs, policy-level scoping may be sufficient; for multi-entity governance, control-objective-level scoping is the recommended pattern.

How does the compliance score reach the policy level, and which calculation mode should I choose? Scores propagate upward: control pass/fail → control objective percentage → entity score → policy level. Two modes are available via the entity hierarchy-based scoring property. FALSE (default): entity score is the average of its direct controls only. TRUE: entity score averages downstream entity scores together with direct controls — useful for hierarchical entity structures like regional subsidiaries. Choose deliberately; the two modes can produce significantly different scores for the same program.

Some useful resources

Visit the ServiceNow product documentation or join the conversation on the ServiceNow GRC Community.