Independent thinking. Informed defence.

CISO Times

Intelligence for the people behind the defence.

The CISO Decision Brief

How do we…

How do we test a control once and use the result for several frameworks?

5 decision pointsThe pack behind this answer: Security Control Assurance

Add to board memo

The short answer

Recommendation
Decide yourself which requirements you rely on each control for, read each in its own words, and make sure the control's test checks what every one of them asks. Then test once, on the cycle the control's risk rating sets, and report in counts.
Reasoning
Testing the same control separately for each requirement set wastes effort and produces results that can disagree. One test supports every requirement you rely on the control for, as long as the attributes tested include what each requirement needs (rule CA-17). Which requirement a control is relied on for is your own record; the pack does not pair them for you. A test shows that one control operated in one period. It is never presented as an audit or a statement of compliance (rule CA-18).
Considerations
  • Not every requirement set applies to you. Where you are not sure whether a law applies, treat it as applying and confirm with counsel.
  • If the control does not do or record what a requirement asks, testing it harder will not help. Rely on another control, or add one.
  • How often a control is tested follows from its risk rating, not from how many requirement sets rely on it.
  • Results are counts with every deficiency named, never a share of compliance with any framework (rule CA-19).

The decision, step by step

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

  • Start
  • Step
  • Decision
  • Outcome
StartA control is relied on for more than one requirement setStepDecide which requirements you rely on the control forDecisionDoes that requirement set apply to you?OutcomeLeave that set blank; no reliance to recordStepRead what each requirement asks, in its own wordsStepRecord the reliance on both sides of your workbookDecisionDo the tested attributes include what each requirement needs?DecisionCan the control's own record show what is missing?StepAdd the attribute to the control's testOutcomeRely on another control, or add one, for that requirementStepTest once, on the cycle the control's risk rating setsDecisionWill an audit or review rely on this test?StepHave the test final at least 6 weeks before it startsDecisionIs the result being asked to stand as an audit or compliance?OutcomeOffer the results as input; a test is not that auditOutcomeReport in counts, naming every deficiency

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

  1. Start

    A control is relied on for more than one requirement set

    Organisations often rely on the same control for several requirement sets at once: a certification, a law, a customer contract. Testing it separately for each wastes effort and produces results that can disagree. One test can serve them all if it is designed for all of them.

    In the pack

  2. Step

    Decide which requirements you rely on the control for

    This is your judgement, made against each requirement's own text. The pack does not say which control meets which requirement, and no list in it pairs them for you. A document's own framework references show that it helps with a requirement's work, never that using it meets the requirement. Check your choices with your auditor or counsel where you rely on them.

    In the pack

  3. Decision

    Does that requirement set apply to you?

    Not every set does. DORA binds financial entities only. NIS2 applies to the entities in its scope, and its Implementing Regulation only to the digital providers it names. ISO/IEC 27001 and NIST CSF apply where you use them or a customer asks for them. If you are not sure, treat the set as applying and confirm with counsel.

    In the pack

    See also

  4. Outcome

    Leave that set blank; no reliance to record

    Leave the set's columns blank and ignore its counts. Keep testing the control on its own cycle for the risk it addresses, even if no requirement relies on it. Come back to the set if your scope changes.

    In the pack

  5. Step

    Read what each requirement asks, in its own words

    Work from each publisher's own words and numbering. The workbook quotes the NIS2 points and the NIST CSF subcategories, gives the ISO/IEC 27001 Annex A controls by number and title only, and the DORA articles by heading only, so read the standard or the Regulation itself for those. Note what each requirement asks a record to show.

    In the pack

  6. Step

    Record the reliance on both sides of your workbook

    In your copy, enter the requirements you rely on beside the control, using each set's own numbering, and enter the control against each requirement on that set's sheet. Use a separate column for a contract clause or a customer review. The workbook does not check that the two sides agree, so compare them when you review it.

    In the pack

  7. Decision

    Do the tested attributes include what each requirement needs?

    An attribute is one thing the tester checks on every sampled occurrence. If one requirement asks that the record show who approved, and another asks for the date, both are attributes of the same test. Compare each requirement you entered with the control's attributes. If you are not sure, answer no.

    In the pack

  8. Decision

    Can the control's own record show what is missing?

    An attribute can only be tested if the record the control leaves can show it. If it can, the attribute belongs in this test. If the control does not do or record what the requirement asks, testing it harder will not help.

    In the pack

  9. Step

    Add the attribute to the control's test

    Add it to the control's attributes, so every future workpaper for the control checks it on every sampled occurrence. The evidence for it must meet the same standard as the rest of the test.

    In the pack

  10. Outcome

    Rely on another control, or add one, for that requirement

    Remove the requirement from this control's entry. Rely on another control you already test, or write a new one as who does what, how often and the record it leaves, and add it to your inventory. A requirement with no control entered may be one you do not rely on, one you rely on another way, or a gap: decide which, and record why.

    In the pack

  11. Step

    Test once, on the cycle the control's risk rating sets

    One test, on one workpaper, tests every attribute on every sampled occurrence. How often it is tested follows from the control's risk rating, not from how many requirement sets rely on it. The tester owns and performs none of the controls tested.

    In the pack

    See also

  12. Decision

    Will an audit or review rely on this test?

    Before an audit, a supervisory review or a customer review, use your workbook to list the controls it relies on. If you do not know whether the auditor or reviewer will look at this control, treat it as relied on.

    In the pack

  13. Step

    Have the test final at least 6 weeks before it starts

    Final means the reviewer has signed the workpaper. Finishing at least 6 weeks before, the pack's default, leaves time to fix a deficiency, or at least to agree its plan, before the auditor asks.

    In the pack

    See also

  14. Decision

    Is the result being asked to stand as an audit or compliance?

    A control test is evidence that one control operated in one period. It is not an internal audit, a certification audit, a maturity assessment or a statement of compliance. Watch for a request to present it as one, such as a slide headed as compliance with a framework. If you are not sure how it will be used, ask.

    In the pack

  15. Outcome

    Offer the results as input; a test is not that audit

    Offer the workpapers as your own monitoring records. An audit programme can use them to choose what to audit and can re-perform a sample; whether an auditor relies on them is the auditor's decision. Where a law asks for its own audit or independent review, confirm with counsel what it must include.

    In the pack

    See also

  16. Outcome

    Report in counts, naming every deficiency

    Report results as counts, such as how many controls were tested and how many worked, with every deficiency named. Give no overall score, no weighting and no figure presented as a share of compliance with any framework. A share hides which control failed, and claims more than any test can show.

    In the pack

Practical checklist

  1. Decide which requirements you rely on each control for, against each requirement's own text.
  2. Record the reliance on both sides of your workbook, and compare the two sides when you review it.
  3. Compare each requirement with the control's attributes, and add any attribute the control's record can show.
  4. Move a requirement the control cannot meet to another control, or write a new one.
  5. Test once, on one workpaper, covering every attribute on every sampled occurrence.
  6. Have relied-on tests final at least 6 weeks before an audit or review starts.
  7. Offer the results as input to an audit, never as the audit itself.

Evidence to have ready

  • Your record of which requirements each control is relied on for, in each set's own numbering.
  • The control's attributes, showing what each relied-on requirement needs.
  • The single workpaper for each test, signed by the reviewer.
  • The report in counts, with every deficiency named.

Assumptions

  • Each control you rely on is written as who does what, how often and the record it leaves, and sits in your control inventory with an owner and a risk rating.
  • You know which requirement sets apply to you, such as NIS2, DORA, ISO/IEC 27001, NIST CSF or a customer contract, and have confirmed the legal ones with counsel.
  • You can read each requirement's own text, including a licensed copy of any standard you rely on, because the judgement about what it asks is yours.

Not covered here