Independent thinking. Informed defence.

CISO Times

Intelligence for the people behind the defence.

The CISO Decision Brief

How do we…

How do we write a risk so it's a risk and not an audit finding?

4 decision pointsThe pack behind this answer: Information Security Risk Management

Add to board memo

The short answer

Recommendation
Write each risk as a scenario in four parts: the threat, the weakness it uses, the asset or service it would hurt, and the consequence, under a one-sentence title that names the event and the harm. The finding becomes the weakness, and fixing it becomes a treatment action.
Reasoning
A finding describes a gap; a risk describes what could happen because of it. A gap, a threat, a consequence with no cause or a broad condition cannot be scored or owned as it stands. Naming your own service makes the scenario something an executive can own, score and treat. One scenario has one register entry, so a finding often changes a risk you already hold. Where a part is unknown, the more cautious assumption raises the rating, so the people who can supply the facts have a reason to.
Considerations
  • The 10 working days for reassessment are the defaults in the CISO Times risk management pack. Your own procedure may set different ones.
  • The owner is the executive who would answer for the harm, by role. Not a committee, a department or the security team, unless the harm falls on the security function's own duties.
  • If two executives disagree about ownership, the Head of Information Security refers it to executive management.
  • Where two categories could apply, use the one with the lower appetite.

The decision, step by step

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

  • Start
  • Step
  • Decision
  • Outcome
StartA finding, topic or concern needs to go in the registerDecisionWhat does the draft title actually name?StepMake the gap the weakness, and ask what it lets happenStepSay what the threat would hurt, and howStepFind the cause behind the consequenceStepNarrow the condition to one scenario you can scoreDecisionDoes an existing register entry already cover this scenario?OutcomeUpdate that entry and reassess itStepWrite the four parts, naming your own serviceDecisionIs any of the four parts unknown?StepFill each gap with the more cautious assumptionDecisionIs there one executive who would answer for the harm?StepRefer the ownership question to executive managementStepGive it one category, which sets its appetiteOutcomeScore it, then enter it in your register

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

  1. Start

    A finding, topic or concern needs to go in the register

    It may be an audit finding, a test result, a threat report or a worry raised by a manager. Most arrive written as a gap or a topic: 'no multi-factor sign-in', 'phishing', 'legacy IT'. None of these can be scored or owned as it stands. The work is to turn it into a story about what could happen and what it would cost.

    In the pack

  2. Decision

    What does the draft title actually name?

    A risk title names an event and the harm it causes: 'Ransomware takes online ordering offline for more than 2 days'. Titles that fail name only one piece. A gap ('No multi-factor sign-in on the payments portal'), a threat ('Phishing'), a consequence with no cause ('GDPR non-compliance'), or a condition too broad to score ('Legacy IT').

    In the pack

  3. Step

    Make the gap the weakness, and ask what it lets happen

    An audit finding is usually a weakness. Ask who could use it and what they would hurt. 'No multi-factor sign-in on the payments portal' becomes 'Payments diverted by a fraudster who signs in to the payments portal with a stolen password'. Fixing the gap then becomes a treatment action for that risk.

    In the pack

  4. Step

    Say what the threat would hurt, and how

    A threat on its own says nothing about harm. Name the service it would reach and what would happen. 'Ransomware' is a topic. 'Ransomware takes online ordering offline for more than 2 days' is a risk someone can own, score and treat. 'Phishing' becomes 'Staff account taken over through phishing'.

    In the pack

  5. Step

    Find the cause behind the consequence

    'GDPR non-compliance' is where every data risk ends, so it separates nothing. Ask what would cause it: 'Cloud storage misconfigured and customer files exposed' is one cause, a lost laptop is another. Each cause is its own risk, with its own weakness and owner.

    In the pack

  6. Step

    Narrow the condition to one scenario you can score

    A broad condition such as 'Legacy IT' holds several risks. Pick the event that worries you most and write it: 'Critical weaknesses on internet-facing systems exploited before they are fixed'. If more than one event matters, write each as its own scenario.

    In the pack

  7. Decision

    Does an existing register entry already cover this scenario?

    One scenario has one entry. A new finding often shows that an existing risk is more likely, or that a control counted in its score does not work. Several entries on one service that describe the same event should be merged into one, scored at its worst consequence.

    In the pack

  8. Outcome

    Update that entry and reassess it

    Do not add a second entry. The procedure sends a matching candidate to triggered reassessment: reassess the risks it touches with their owners, within 10 working days in the pack's defaults. Record the finding against the entry, and check whether it removes a control the residual score relied on.

    In the pack

    See also

  9. Step

    Write the four parts, naming your own service

    Threat: who or what causes it. Weakness: the gap it uses. Asset or service: what is hurt. Consequence: what it costs, stops or breaches. Name your own service, system or supplier, because a scenario about a real asset is one someone can own. A scenario library entry is a good starting point where one fits.

    In the pack

  10. Decision

    Is any of the four parts unknown?

    You will often lack a fact: which service a gap reaches, or whether a threat is active against you. Gaps do not stop the scenario being written. They decide which way you lean when you fill it in.

    In the pack

  11. Step

    Fill each gap with the more cautious assumption

    Assume the most important service the scenario could reach. Treat the threat as active. Assume the gap exists. Where the consequence falls between two levels, use the higher. Missing information then raises the rating, so the people who can supply the facts have a reason to.

    In the pack

  12. Decision

    Is there one executive who would answer for the harm?

    The owner is the executive accountable for the service or asset the risk would hurt, by role. Not a committee, a department or the security team. The security function owns a risk only where the harm falls on its own duties, such as reporting an incident to the authority on time.

    In the pack

  13. Step

    Refer the ownership question to executive management

    Where two executives share a service, the one who would answer for the harm owns the risk. If they still disagree, the Head of Information Security refers it to executive management.

    In the pack

  14. Step

    Give it one category, which sets its appetite

    Each risk sits in exactly one category, such as service availability or financial fraud, and the category's appetite level is what the risk will be tested against. If two categories could apply, use the one with the lower appetite.

    In the pack

  15. Outcome

    Score it, then enter it in your register

    The scenario, owner and category are now ready to score: impact and likelihood before and after the controls that work today. The risk then goes into the one register as a new entry with its ratings, band and position. The original finding is recorded as its source, and fixing it is a candidate treatment action.

    In the pack

    See also

Practical checklist

  1. Check what the draft title names, and rewrite a gap, threat, consequence or broad condition as an event and its harm.
  2. Search the register for an entry that covers the same scenario. If one does, update and reassess it instead of adding another.
  3. Write the four parts, naming your own service, system or supplier. Start from a scenario library entry where one fits.
  4. Fill any unknown part with the more cautious assumption, and use the higher level where you are between two.
  5. Name one owner: the executive accountable for the service the risk would hurt.
  6. Give the risk one category, which sets the appetite it is tested against.
  7. Score it before and after working controls, and enter it in the one register with the finding as its source.

Evidence to have ready

  • The register entry with its title, four parts, owner, category, ratings and source finding.
  • The treatment action that fixes the original finding.
  • For a finding matched to an existing entry, the reassessment made with its owner.
  • Any ownership dispute referred to executive management, and its outcome.

Assumptions

  • You keep, or are starting, one risk register that every assessed risk goes into.
  • The timings shown are the defaults in the CISO Times risk management pack. Your own procedure may set different ones.

Not covered here