Control objective workflow

  • Release version: Australia
  • Updated March 12, 2026
  • 4 minutes to read
    • Summarize
    Summarized using AI
    This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.

    Summary of Control objective workflow

    The control objective workflow introduces a structured review and approval process for changes to control objective records within ServiceNow. This workflow prevents unreviewed updates from immediately impacting downstream objects such as controls, policies, and issues. It ensures that changes are properly vetted before becoming active, thereby maintaining the integrity and reliability of compliance data.

    Show full answer Show less

    Key Features

    • Workflow States: Control objectives move through defined states—Draft, Review, Approved, Published, and Retired—each with specific permissions and editing capabilities. Draft and staging records hold changes until approval, ensuring published records remain active and stable until updates are authorized.
    • Revision Types: Changes are classified as Major or Minor. Major revisions require associated controls to revert to Draft for re-attestation, while Minor revisions update controls without triggering re-attestation, enabling more flexible change management.
    • Role-Based Editing: Editing permissions are restricted to users listed as Owners, members of Owning Groups, or users with the compliance manager role, reinforcing control over who can initiate or approve changes.
    • Workflow Property Control: The Enable control objective workflow property toggles the workflow functionality on or off, affecting editing methods, state transitions, and publishing rules to fit organizational needs.
    • Effective Date Management: The Effective Date field allows optional scheduling of when a control objective becomes active, providing automated publishing capabilities.
    • Integration with Policies: Control objectives must be in Approved or Published state before policy approval requests, and changes cannot be published if associated policies are in restrictive states, ensuring alignment between objectives and policies.
    • UI and Workspace Support: Workflow actions are available in the workspace interface with guidance directing users for full functionality, while classic UI supports basic editing with workflow actions limited to workspace.

    Key Outcomes

    • Prevents unreviewed and potentially disruptive changes to control objectives from immediately affecting compliance and governance processes.
    • Maintains stability of published control objectives while allowing safe drafting and review of changes.
    • Enhances accountability and control by restricting editing and approval capabilities to designated roles and groups.
    • Facilitates clear and auditable change management with defined revision types and workflow states.
    • Ensures synchronization and compliance integrity between control objectives and related policies.
    • Improves user experience by providing workflow actions in a dedicated workspace, supporting more efficient review and approval processes.

    The control objective workflow introduces a review and approval process for changes to control objective records, preventing unreviewed updates from immediately affecting downstream objects such as controls.

    Why the workflow exists

    Before the control objective workflow, any user with the compliance user role could directly update a control objective record without a review process. Because control objectives are referenced by controls, policies, issues, and other objects, unreviewed changes would immediately affect all downstream records.

    When you revise a published control objective, a working draft record is created to hold draft changes. The published record remains active and available to downstream processes until you explicitly publish the approved staging changes. The staging record is linked to the current version record and is always inactive, regardless of its workflow state.

    For example, a control objective might require monthly sprinkler testing. If a compliance author wants to change the interval to two months, the existing published record continues to drive exception management and attestation while the proposed change goes through review and approval in the staging record. If the change is not approved, the published record is unaffected.

    Control objective workflow states

    When the workflow property is enabled, a control objective moves through the following states:

    Draft
    The initial state for a new or revised control objective. The record is inactive. Users listed in the Owner field, members of groups listed in the Owning Group field, and users with the compliance manager role can edit the record and perform workflow actions.
    Review
    Triggered when the owner selects Request Review. Approvals are generated based on configured dynamic approval rules. If no approval rules apply, the control objective moves directly to Approved. The record is read-only during review.
    Approved
    The control objective has passed all required approvals. The record is read-only except for the Effective Date field. The control objective is not yet active.
    Published
    The control objective is active. The active flag is set to true. Core content fields (name, description, supplemental guidance, category, classification, and type) are locked. Metadata fields such as attestation settings and issue grouping rule, and ownership fields, remain editable without requiring a staging record.
    Retired
    The control objective is inactive. The active flag is set to false. Retirement is triggered by selecting the Retire button or by setting the active flag to false directly.

    Revision types

    When you initiate a change on a published control objective, you must select a revision type. The revision type determines how associated controls are affected when the change is published.

    Major
    Use for substantive changes to the meaning or intent of the control objective. When a major revision is published, all associated controls move back to Draft, requiring control owners to review the changes and re-attest.
    Minor
    Use for corrections such as spelling fixes, typo corrections, or rewording that does not change the functional meaning of the control objective. When a minor revision is published, associated controls remain in their current states. Updated field values are applied to controls without triggering re-attestation.

    The categorization of a change as major or minor is subjective and is not enforced by field-level restrictions. Reviewers can reject a staging record if the revision type does not match the scope of the changes made. You can change the revision type at any point before publishing by selecting Update Revision Type on the staging record.

    Behavior with the workflow property enabled and disabled

    The control objective workflow is controlled by the Enable control objective workflow property. The following table summarizes how behavior differs based on the property setting.

    Table 1. Control objective behavior: workflow property disabled vs. enabled
    Behavior area Property disabled Property enabled
    Who can edit a control objective Any user with the compliance user role Users in the Owner field, members of groups in the Owning Group field, and users with the compliance manager role
    Editing a published record Direct edits to the control objective record Edits are made on a staging record; the published record is not changed until staging changes are approved and published
    State field Present but no workflow transitions. New records default to Draft; active records show Published; inactive records show Retired Full workflow transitions: Draft → Review → Approved → Published → Retired
    Workflow actions Not available Available in workspace based on current state and user role (Request Review, Publish, Retire, and others)
    Owner and Owning Group fields Not present on the form At least one of these fields is required
    Effective Date field Not available Optional; automatically publishes the control objective on the specified date; populated with the actual publish date when left blank
    Impact on controls when a change is published All associated controls move to Draft immediately on save Major revision: associated controls move to Draft. Minor revision: associated controls remain in their current states; updated field values are applied without triggering re-attestation
    Control objective activation on policy publish All associated control objectives are automatically activated when a policy is published All associated control objectives must be in Approved or Published state before a policy can request approval. Approved control objectives are automatically published when the associated policy is published

    Similarly, changes to a control objective cannot be published if an associated policy is in Published, Retired, or pending-approval state. To publish control objective changes, the associated policy must be in Draft or Review state.
    Classic UI support Full edit and related-list access Edit and related-list access preserved; workflow actions available in workspace only. An info message on the form directs users to open the record in workspace to perform additional actions