Independent thinking. Informed defence.

CISO Times

Intelligence for the people behind the defence.

The CISO Decision Brief

When do we…

When does a policy change need re-approval and fresh acknowledgement?

4 decision pointsThe pack behind this answer: Security Policy Management

Add to board memo

The short answer

Recommendation
Have every new version approved at the policy's usual level, however small the change. Ask for fresh acknowledgement only when the change is material, and treat it as material whenever the owner and information security disagree or are unsure.
Reasoning
Approval is the only independent look at a document, so even a review that changes nothing is approved, as a new minor version. Acknowledgement is different. It confirms people know what they must do, so it is needed again only when that changes: a 'must' statement, the scope, a role, an approval authority, the consequences of not complying, a value people work to, or the tier. A material change raises the major version, so earlier acknowledgements no longer count. Spelling, renamed teams, updated links and clarifications every consulted function agrees change no obligation are not material, and existing acknowledgements stay current.
Considerations
  • The consultation period of at least 10 working days and the 30 calendar days to re-acknowledge after publication are the defaults in the CISO Times policy pack. Your own framework may set different ones.
  • A policy is approved by executive management. The top policy goes to the board or its equivalent: the board, or a board risk committee it has delegated to; the management board in a two-tier structure; executive management where there is no board. Nobody approves a document they own or wrote.
  • A minor version may be approved in writing without a meeting. It needs no consultation and no new acknowledgement.
  • A re-acknowledgement after a material change also counts as that year's annual acknowledgement of the policy.

The decision, step by step

Select any step for the reasoning behind it and where the pack covers it.

  • Start
  • Step
  • Decision
  • Outcome
StartYou plan to change a policyStepPlan approval for any new version, minor or majorDecisionDoes it change a 'must', or what anyone does to comply?DecisionDoes it change scope, roles, approvers or consequences?DecisionDoes it change a value people work to, or the tier?DecisionDo the owner and information security agree it is not material?OutcomeMaterial: consult, approve, re-acknowledgeOutcomeNot material: approve a minor version, no re-acknowledgement

Keyboard: Tab to a step, arrow keys move along the flow, Enter pins its explanation, + and − zoom, 0 fits the diagram, Esc closes. The text version below has the same content.

Where a step quotes a number, it is the default in the CISO Times pack. Your own standard may set a different one.

Read as text

The same flow written out: each step, its reasoning and where the pack covers it. 8 steps.

  1. Start

    You plan to change a policy

    The change may come from a scheduled review, an incident, an audit finding, a new law or a change in how you work. Two questions follow: does it need approval, and must people acknowledge it again. The first answer is always yes. The second depends on whether the change is material.

    In the pack

  2. Step

    Plan approval for any new version, minor or major

    Every new version is approved at its tier's level. For a policy, that means executive management. The top policy goes to the board or its equivalent: the board, or a board risk committee it has delegated this to; in a two-tier structure, the management board; where there is no board, executive management. A minor version may be approved in writing without a meeting. A review that changes nothing is still approved, as a new minor version.

    In the pack

    See also

  3. Decision

    Does it change a 'must', or what anyone does to comply?

    Adding, removing or changing a 'must' statement is material, and so is any change to what people have to do to comply. For example, allowing staff to read work email on their own phones, or adding a rule on putting company information into online AI tools.

    In the pack

  4. Decision

    Does it change scope, roles, approvers or consequences?

    Material if it changes who or what the policy applies to, a role, an approval authority, or the consequences of not complying. A role simply renamed, with no change to what anyone does, is not material.

    In the pack

  5. Decision

    Does it change a value people work to, or the tier?

    Material if it changes a deadline, frequency, threshold, strength or retention period, or moves the document to a different tier. If you find many such values in a policy, they may belong in a standard.

    In the pack

    See also

  6. Decision

    Do the owner and information security agree it is not material?

    What remains should be spelling, grammar, formatting, a renamed team or system, an updated link or contact, or a clarification every consulted function agrees changes no obligation. If the owner and information security disagree, or are unsure, the change is treated as material.

    In the pack

  7. Outcome

    Material: consult, approve, re-acknowledge

    Raise the major version (2.1 to 3.0). Consult the people who must follow it, and legal, HR and data protection where affected, for at least 10 working days in the pack's defaults. Approve it at its tier's level. After publication, everyone in scope acknowledges the new version within 30 calendar days. Earlier acknowledgements no longer count, and this one also counts as the year's annual acknowledgement.

    In the pack

    See also

  8. Outcome

    Not material: approve a minor version, no re-acknowledgement

    Raise the minor version (2.1 to 2.2). No consultation is needed, and existing acknowledgements stay current, because an acknowledgement covers every minor version of the same major version. The approver confirms the classification when approving, and it is recorded in the revision history.

    In the pack

Practical checklist

  1. Plan approval at the policy's tier for the new version, whatever the change.
  2. Check whether the change adds, removes or changes a 'must' statement, or what anyone does to comply.
  3. Check whether it changes the scope, a role, an approval authority or the consequences of not complying.
  4. Check whether it changes a deadline, frequency, threshold, strength or retention period, or the document's tier.
  5. If none applies, confirm the owner and information security both agree the change is not material. If either disagrees or is unsure, treat it as material.
  6. For a material change: raise the major version, consult the people who must follow it, and legal, HR and data protection where affected, approve it, then ask everyone in scope to acknowledge it after publication.
  7. For a change that is not material: raise the minor version, have it approved, and keep the existing acknowledgements.
  8. Have the approver confirm the classification, and record it in the revision history.

Evidence to have ready

  • The dated approval of every version, minor or major, at the right level.
  • The revision history, showing each change's classification as material or not, confirmed by the approver.
  • For a material change, the comment log with each comment and its response, and the acknowledgement records for the new major version.
  • Archived earlier versions, so you can show which version was in force on any date.

Assumptions

  • Your policies carry major.minor version numbers, or you are willing to start.
  • The consultation and acknowledgement windows shown are the defaults in the CISO Times policy pack. Your own framework may set different ones.

Not covered here