Managing control objective changes with the new IRM workflow

[Shimoli Gandhi]

Before the Australia (Q1 2026) release, a cascade changes business rule applied edits to control objectives immediately on live records—including in-flight control attestations. Any compliance user could update a control objective with no review process, and those changes instantly affected downstream records. Whether you changed a testing frequency or fixed a typo, every associated control reset to Draft. Teams often deferred updates or created unnecessary duplicates to avoid triggering mass re-attestation.

The Control Objective Workflow addresses this with a staging model, a Major/Minor revision type, and configurable approvals—giving compliance teams control over what changes, when it takes effect, and how it impacts downstream records.

Turn on the control objective workflow when your organization needs governed change management over control objectives with approval workflows and downstream impact management. Watch a short video of the feature.

How the staging model works

There are five workflow states for the Control Objective (see image).

When you edit a published control objective, changes are drafted on a staging record, not the published record. The published record remains active—controls, policy exceptions, and risk statements continue referencing it until you explicitly publish the staging changes. The staging record remains inactive until published, moving through states. The staging record is retained after publishing for audit trail purposes.
 

Option for major or minor changes

When you start editing, you select a revision type: major or minor. This determines what happens to associated controls when you publish.

The control objective workflow states Draft -> Review -> Approved -> Published remains the same for both major and minor changes.

Major change	Minor change
The meaning or intent of the control objective changed substantially	Corrections - spelling, typos, or rewording that does not change functional meaning
Downstream controls reset to Draft → re-attestation required	Controls stay in current state → new values of Control Objective sync, no re-attestation necessary
Examples: • Changing testing frequency from quarterly to monthly • Adding new requirements to the control objective • Modifying the scope of what the control covers • Changing evidence requirements	Examples: • Fixing typos or grammatical errors • Clarifying wording without changing meaning • Updating formatting or structure • Correcting metadata fields

The revision type determination is subjective. It is not enforced by the system. Reviewers can reject a change if the selected type falls outside the edit's scope. You can change the revision type using "Update Revision Type" before publishing.

Things to remember

Policy association constraint - You cannot publish control objective changes if the associated policy is in Published, Retired, or pending-approval state. Move the policy to Draft or Review first.

Effective date - Effective Date is optional. If set in the Approved state, the record auto-publishes on that date. If left blank, the system populates it with the actual publish date when you click Publish.

Configurable review & approval workflow - Use the Approval Configurator to set up approval levels and routing rules that match how your organization governs compliance changes. If no approval rules are configured, the record skips directly from Review to Approved.

Key Implementation Steps

Enable the workflow: Navigate to Policy and Compliance > Administration > Properties and enable "Enable control objective workflow." See product documentation for details.

Configure approval rules: Navigate to Assignment and Approval Configurations > Approval Configurations to create rules for control objective approvals. No out-of-the-box rules are shipped. See product documentation for configuration guidance.

 

Planning your implementation

Governance

• Document what constitutes Major vs Minor for your organization and get stakeholder alignment.
• Establish a review cadence to keep approval roles and levels up to date.

Operations

• Monitor for abandoned staging records—a new edit cannot begin on a control objective until the existing staging record is published or cleared.

Auditing

• Staging records are retained after publishing, providing a complete audit trail of control objective changes over time.

Roles and capabilities

ServiceNow Role	Persona	Capabilities
sn_compliance.admin	Admin	·    Enable workflow property ·    configure approval rules
sn_compliance.user	Compliance User / Control Objective Owner / Owning Group	·    Create new control objectives ·    Edit draft/staging records ·    Request Review, set Effective Date, Publish
sn_compliance.manager	Compliance Manager	·    Edit at any stage regardless of ownership ·    Can perform all workflow actions ·    Can change revision type (major vs minor) before publishing
Configured via Approval Rules (optional)	Approver	·       Approve or reject records in Review state ·       Rejection returns record to Draft

 

Next steps

Do you have any use cases for control objective changes that this workflow doesn't address? Drop them in the comments. Your input helps shape our future product features.

Interested in Rationalizing your Control Library? Review this blog.

[jjcontessa]

Hello @Shimoli Gandhi,

A few follow-up questions for you: 

1. Does the policy constraint apply to "major" and "minor" control objective changes? It would be ideal if the policy did not have to be moved back to draft for minor changes and could be dynamically updated if control objective language is embedded through configuration. This is a constraint many customers face and often significantly slows these updates.

2. Can you confirm this feature has reverse compatibility? We have attempted to upgrade our plugins to version 22.0 to test this in internal development instances and in customer sub-production instances, but we are not seeing them available for upgrade.

[Shimoli Gandhi]

@jjcontessa 

Thank you for the great questions — really appreciate you raising these.

Please see the replies below:

1. The policy constraint highlighted applies to both major and minor changes. That said, I hear your feedback and want to make sure it gets the attention it deserves. If you're able to send me an email with specific customers who are immediately facing this challenge, that will go a long way in helping us build a stronger case to reprioritize updates internally.
2. This feature is backward compatible (n-2). There is a property that needs to be enabled on your end — if you've already done that and are still not seeing it, we'd recommend reviewing the product docs once more to confirm everything is configured correctly. If the issue persists after that, please don't hesitate to send us an email so we can dig into it and get you sorted.

Looking forward to hearing from you!