Independent thinking. Informed defence.

CISO Times

Intelligence for the people behind the defence.

The CISO Decision Brief

When do we…

When do we retire a policy rather than update it?

4 decision pointsThe pack behind this answer: Security Policy Management

Add to board memo

The short answer

Recommendation
Update a policy while the need it covers still exists and no other document covers it. Retire it when that need has ended, or when another document has superseded or absorbed it, and say first where any requirement that still applies will live.
Reasoning
Retirement is one of four outcomes a review can reach, and it should be decided on purpose: a document left to drift is still in force. The register allows one document per need, so when two cover the same ground one is kept and the other retired. Requirements still needed move into the surviving document before the old one is withdrawn, so none falls between the two. A requirement that does not fit one system, team or supplier calls for an exception, which never changes the document, so it is no reason to retire the policy.
Considerations
  • The 20 working days for the retirement decision and 3 months to correct references in other documents are the defaults in the CISO Times policy pack. Your own standard may set different ones.
  • If you are unsure whether the need still exists, treat it as still there. Retiring a document people still rely on leaves a gap nobody sees.
  • A policy's retirement is approved by executive management; the top policy's by the board, a board risk committee it delegates to, the management board in a two-tier structure, or executive management where there is no board. Nobody approves retiring a document they own or wrote.
  • Adding a 'must' statement to the surviving document is a material change to it: a new major version, consulted on, approved and acknowledged again.

The decision, step by step

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

  • Start
  • Step
  • Decision
  • Outcome
StartA policy no longer seems to fitDecisionIs the problem one requirement that doesn't fit one case?OutcomeHandle it as an exception; the policy staysDecisionDoes the need the policy covers still exist?DecisionDoes another document on the register cover the same need?StepMove any requirement still needed into the surviving documentDecisionDoes the update change what anyone must do?OutcomeUpdate it: a new major version, consulted and re-acknowledgedOutcomeUpdate it: a new minor version, approved in writingStepSay where each requirement that still applies now livesStepHave the tier's approver approve the retirement in writingStepWithdraw it everywhere, archive it, mark it RetiredOutcomeRetired, with references corrected and people told

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. 13 steps.

  1. Start

    A policy no longer seems to fit

    The question usually comes up at a scheduled review, after a trigger such as a new system or a change in the organisation, or when two documents turn out to cover the same ground. Retirement is one of four outcomes a review can reach, alongside no change, a minor change and a material change. Decide it on purpose: a document left to drift is still in force.

    In the pack

  2. Decision

    Is the problem one requirement that doesn't fit one case?

    A system, team or supplier that cannot meet a single requirement needs an exception: to a numbered requirement, for a named scope and a fixed time. An exception never changes the document. If the requirement should never apply to that case, change the document through review instead.

    In the pack

  3. Outcome

    Handle it as an exception; the policy stays

    Deviations from any security document go through your security exception process, never by informal agreement. The policy stays as it is. Exceptions granted against a document are an input to its next review: they are a sign that a requirement may be wrong or unworkable.

    In the pack

    See also

  4. Decision

    Does the need the policy covers still exist?

    Ask whether the activity, system or risk the policy governs is still there. A policy for a service you have shut down has no need left. If you are unsure, treat the need as still there: retiring a document people still rely on leaves a gap nobody sees.

    In the pack

  5. Decision

    Does another document on the register cover the same need?

    The register allows one document per need. If two documents cover the same ground, keep one and retire the other as superseded or merged. Check the register, not the shared drives: a document that is not on the register is not in force.

    In the pack

  6. Step

    Move any requirement still needed into the surviving document

    Adding a 'must' statement to the surviving document is a material change to it: a new major version, consulted on, approved at its tier and acknowledged again. Do this before the old document is withdrawn, so no requirement falls between the two.

    In the pack

  7. Decision

    Does the update change what anyone must do?

    The need is still there and nothing else covers it, so update the policy. A change is material if it adds, removes or changes a 'must' statement; changes the scope, a role, an approval authority or the consequences; changes a value people work to; or moves the document to another tier. If the owner and information security disagree, it is material.

    In the pack

  8. Outcome

    Update it: a new major version, consulted and re-acknowledged

    Prepare the next major version and take it through drafting, consultation of at least 10 working days, approval at its tier and publication. Everyone in scope acknowledges it within 30 calendar days of publication. Acknowledgements of the old major version do not count for the new one.

    In the pack

    See also

  9. Outcome

    Update it: a new minor version, approved in writing

    Prepare the next minor version, recording 'Reviewed — no change' where nothing changed. It still needs approval at its tier, which may be given in writing without a meeting. There is no consultation and no new acknowledgement. The next review date runs from the new approval date.

    In the pack

  10. Step

    Say where each requirement that still applies now lives

    The owner proposes retirement with the reason: superseded, merged into another document, or no longer needed. The proposal says where any requirement that still applies now lives. Anything that still depends on the document is pointed elsewhere first.

    In the pack

  11. Step

    Have the tier's approver approve the retirement in writing

    The approver for the document's tier approves the retirement in writing and dated, in the pack's default within 20 working days. For a policy that is executive management. For the top policy it is 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. Nobody approves the retirement of a document they own or wrote.

    In the pack

    See also

  12. Step

    Withdraw it everywhere, archive it, mark it Retired

    Withdraw it from the policy library and every other place it was put, such as shared drives, onboarding packs and supplier portals. Archive it with its approval record, set its status to Retired on the register and remove it from acknowledgement cycles. Its ID is never reused.

    In the pack

  13. Outcome

    Retired, with references corrected and people told

    Update references to it in other documents as minor changes, in the pack's default within 3 months, and tell the people it applied to. Archived versions are kept so you can show which version was in force on any date.

    In the pack

Practical checklist

  1. If the problem is one requirement that does not fit one case, raise an exception through your exception process and keep the policy.
  2. Check whether the activity, system or risk the policy governs still exists.
  3. Check the register for another document covering the same need.
  4. If the need remains and nothing else covers it, update the policy: a major version if the change is material, otherwise a minor version.
  5. If another document covers the need, move any requirement still needed into it before the old one is withdrawn.
  6. Have the owner propose retirement with the reason and where each remaining requirement now lives, and point anything that depends on the document elsewhere.
  7. Get the tier approver's written, dated decision, then withdraw the document everywhere it was put, archive it with its approval record, mark it Retired and remove it from acknowledgement cycles.
  8. Correct references to it in other documents as minor changes, and tell the people it applied to.

Evidence to have ready

  • The retirement proposal, with its reason and where each remaining requirement now lives.
  • The approver's dated retirement decision.
  • The register entry marked Retired, and the archived versions with their approval records.
  • The corrected cross-references in other documents.

Assumptions

  • You keep a register of security documents with a tier and one owner for each.
  • Timings shown are the defaults in the CISO Times policy governance pack. Your own standard may set different ones.

Not covered here