Independent thinking. Informed defence.

CISO Times

Intelligence for the people behind the defence.

The CISO Decision Brief

When do we…

When does a deviation from policy need a formal exception?

5 decision pointsThe pack behind this answer: Security Exception, Waiver & Segregation of Duties

Add to board memo

The short answer

Recommendation
Request a formal exception whenever a written security requirement is not met, or will not be met by the date it applies. Request it before the breach where you can see it coming, and soon after discovery where you cannot. Never use one for a legal duty, or for a requirement that should not apply at all.
Reasoning
An exception releases you, for a limited time, from a rule you wrote. Making it formal keeps every departure known, decided by the right person, time-limited and closed with evidence. Approval never runs backwards, so time out of compliance before it is reported as a breach. A risk that no rule addresses is a risk treatment decision instead. The law and duties to customers or regulators cannot be waived internally. The standard allows no permanent waivers, so a requirement that should never apply to a case is changed through policy review.
Considerations
  • The 5 working days for a gap found after the fact is the default in the CISO Times exception pack. Your own standard may set a different period.
  • A legal, regulatory or contractual duty that cannot be met goes to your compliance or legal escalation route, which may lead to notifying a regulator. Where you are unsure whether a legal duty applies, get advice first.
  • An emergency action during an incident is recorded under your incident procedure. It needs an exception only if it must continue after the incident is closed.
  • Keep your list of non-negotiable controls short. A supplier failing a security clause in your contract with it is different, and can be excepted.

The decision, step by step

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

  • Start
  • Step
  • Decision
  • Outcome
StartSomething does not meet a security requirementDecisionIs the rule in one of your security policies, standards or baselines?OutcomeTreat it as a risk decision in your risk registerDecisionIs it an emergency action taken during a live incident?OutcomeRecord it in the incident; request an exception if it staysDecisionWill the requirement be met by the date it applies?OutcomeNo exception needed: meet it on timeDecisionIs it a legal duty, or a control your standard never excepts?OutcomeIt cannot be excepted: meet it, or escalate as complianceDecisionShould the requirement never apply to this case?OutcomeChange the requirement or its scope through policy reviewOutcomeRequest a formal exception now

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

  1. Start

    Something does not meet a security requirement

    It may be a missed patch deadline, a system that cannot enforce a setting, a supplier falling short of a contract clause, or one person holding duties that should be split. Many organisations already allow these informally, by an email from a manager or a note in a ticket. The pack's standard does not forbid those decisions. It makes them visible, time-limited and decided by the right person.

    In the pack

  2. Decision

    Is the rule in one of your security policies, standards or baselines?

    An exception releases you from a rule you wrote: a requirement in an information security policy, standard, procedure or baseline, including the security clauses you place on suppliers. A risk that no rule addresses is a different decision. It belongs in your risk method as a treatment choice, and may end in a risk acceptance.

    In the pack

  3. Outcome

    Treat it as a risk decision in your risk register

    Every rule is met, or no rule covers the situation, so there is nothing to except. Assess the risk in your risk register. If the owner wants to keep it, that is a risk acceptance, with its own approvers by band and its own review dates.

    In the pack

    See also

  4. Decision

    Is it an emergency action taken during a live incident?

    Responders sometimes set a control aside to contain an incident. Record that action under your incident procedure. The exception route applies only if the deviation has to stay in place after the incident is closed.

    In the pack

  5. Outcome

    Record it in the incident; request an exception if it stays

    Record the action in the incident record, under your incident procedure. If the deviation has to continue after the incident is closed, raise an exception request like any other. It takes effect only from its approval date, never earlier.

    In the pack

  6. Decision

    Will the requirement be met by the date it applies?

    Ask as soon as you know about the gap. A fix that will land before the deadline needs no exception. If the fix depends on something you do not control, such as a vendor release, a budget or a migration, judge honestly whether it will land in time. If you cannot tell, treat the answer as no.

    In the pack

  7. Outcome

    No exception needed: meet it on time

    Track the fix to its date through your normal change or remediation process. If the date starts to slip, come back to this question before the deadline passes. An exception approved after the breach cannot cover the time already spent out of compliance.

    In the pack

  8. Decision

    Is it a legal duty, or a control your standard never excepts?

    Some things can never be excepted: a legal or regulatory obligation, a contractual obligation to a customer or regulator, the exception standard itself, and a short list of controls you treat as non-negotiable, such as multi-factor sign-in for remote administrators. A supplier failing a security clause in your contract with it is different, and can be excepted. If you are not sure whether a legal duty applies, take the cautious branch.

    In the pack

  9. Outcome

    It cannot be excepted: meet it, or escalate as compliance

    An internal exception cannot waive the law or a duty owed to a customer or regulator. Take it to your compliance or legal escalation route, which may lead to notifying a regulator. Your register can still hold a line for it, marked as a compliance issue, so it is not lost. A non-negotiable control must simply be met. Where you were unsure whether a legal duty applies, get advice first.

    In the pack

  10. Decision

    Should the requirement never apply to this case?

    Some gaps are not temporary. The rule may not fit systems like this one, or the risk it guards against may be absent. The pack's standard allows no permanent waivers and no exception without an end date. Where a requirement should never apply, the fix is to the requirement.

    In the pack

  11. Outcome

    Change the requirement or its scope through policy review

    Propose the change to the owner of the policy or standard and take it through your normal review and approval. Until the revision is approved, the rule applies. If the gap is open now, request a time-limited exception to cover it while the change is decided. The approved revision, with its effective date, is then the evidence that closes that exception.

    In the pack

  12. Outcome

    Request a formal exception now

    Use your exception form: the requirement not met, the systems named one by one, the reason, the compensating controls, the remediation plan and an end date. A blanket request is refused. Request it before the breach where you can foresee it. Where you found the gap after the fact, the pack's default is within 5 working days of discovery. Time out of compliance before approval is reported as a breach.

    In the pack

    See also

Practical checklist

  1. Check the gap is against a requirement in your security policies, standards, procedures or baselines. If no rule covers it, assess it in your risk register.
  2. Record an emergency action under your incident procedure, and request an exception only if it stays after the incident closes.
  3. Decide whether the requirement will be met by its date. If a dependency makes that uncertain, treat the answer as no.
  4. Stop if it is a legal duty, a contractual duty to a customer or regulator, or a non-negotiable control, and escalate it as a compliance issue.
  5. Where the requirement should never apply to this case, propose a change through policy review, and cover the open gap with a time-limited exception meanwhile.
  6. Otherwise request an exception naming the rule, each system, the reason, the compensating controls, the remediation plan and an end date.

Evidence to have ready

  • The exception request, dated before the breach or within your reporting period of discovery, naming the rule and every system affected.
  • For a case that cannot be excepted, the refusal and its reason, and the compliance escalation record.
  • For a rule change, the approved revision of the policy or standard, with its effective date.
  • The record of any time out of compliance before approval, reported as a breach.

Assumptions

  • Your organisation has written security policies or standards. An exception is a release from a rule you have written down.
  • The 5 working days for reporting a gap found after the fact is the default in the CISO Times exception pack. Your own standard may set a different period.

Not covered here