Independent thinking. Informed defence.

CISO Times

Intelligence for the people behind the defence.

The CISO Decision Brief

How do we…

How do we find the minimum control set when DORA, NIS2 and ISO 27001 all apply to us?

4 decision pointsThe pack behind this answer: ISO 27001 Implementation & Certification Readiness

Add to board memo

The short answer

Recommendation
Settle which regimes apply and to which services, then build one control set from your risk assessment and legal duties, designing each shared control to the strictest requirement that applies. Count an overlap only after you have checked it against both texts, and keep a separate obligation wherever the regimes differ.
Reasoning
ISO/IEC 27001 is a standard you choose to certify against. NIS2 and DORA are laws with their own obligations, such as incident reporting to an authority, that a certificate does not prove. Certification is evidence that a management system works, not compliance with a law. Controls come from the risk assessment, not from a list (IS-03), and laws may set duties no Annex A control covers. One control run well is cheaper to operate and evidence than three similar ones, but a partial match is not an overlap. The minimum set has no duplicated controls; dropping an obligation is not a way to shrink it.
Considerations
  • The pack does not set the strictest level for you. Deadlines, coverage and test frequency come from the texts of the regimes that apply to you.
  • A mapping in the CISO Times Library is a lead worth following, not proof. Confirm it against both texts, and record your reading and who made it.
  • If which regimes apply, or to which services, is still open, stop and get a written view from your legal or compliance function first.
  • If the ISMS scope leaves out services a regulation covers, the certificate will evidence little of what the regulator asks.

The decision, step by step

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

  • Start
  • Step
  • Decision
  • Outcome
  • Loop back

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

    DORA, NIS2 and ISO 27001 may all apply to us

    ISO/IEC 27001 is a standard you choose to certify against. NIS2 and DORA are laws with their own obligations, such as incident reporting to an authority, which a certificate does not prove. Certification is evidence that a management system is working. It is not compliance with a law. The aim is one set of controls that serves all three without duplication and without gaps.

    In the pack

  2. Step

    List every legal, regulatory and contractual requirement

    Keep one register of the security requirements that laws, regulators and contracts place on you, with an owner for each and how you meet it. Say what each requires of you, not just the name of the law. Include customer contract security schedules, which are often missed. Review it at least every 12 months and whenever a law or major contract changes.

  3. Decision

    Is it settled which regimes apply, and to which services?

    Each regime has its own test of who is covered and which services or functions it reaches. The answer decides everything after it: the scope, the risks and the controls. If any part of this is still open, answer no.

  4. Outcome

    Settle applicability first, with legal counsel

    Do not design a control set around regimes you have assumed. Get a written view, from your legal or compliance function, of which regimes apply, to which entities and to which services. Then come back to this flow.

  5. Step

    Make the ISMS scope cover what the regulations cover

    If the ISMS scope leaves out services a regulation covers, the certificate will evidence little of what the regulator asks. Bring the legal and regulatory requirements into the risk assessment, and check that the scope includes the regulated services.

  6. Step

    Choose controls from risk and from what the law requires

    Controls come from the risk assessment, not from a list. Where a law requires a control, record Legal or regulatory as its reason in the Statement of Applicability. Never exclude a control a law requires. Laws may also set duties that no Annex A control covers, such as reporting deadlines or specific testing; list these too.

    In the pack

  7. Step

    Design each shared control to the strictest requirement

    Where more than one regime asks for the same kind of control, build one control that meets the most demanding version: the shortest deadline, the widest coverage, the most frequent test. One control run well is cheaper to operate and to evidence than three similar ones. The pack does not set these levels for you; they come from the texts of the regimes that apply.

    In the pack

  8. Step

    Look the pair up in the CISO Times Library

    Take each overlap you are relying on, one pair of requirements at a time. The CISO Times Library shows how the two requirements line up, how confident that comparison is, and where they differ. Treat a mapping there as a lead worth following, not as proof: confirm it against the texts. If there is no mapping, the overlap is only your assumption so far.

  9. Step

    Read both texts yourself, with legal counsel if needed

    Compare what each requirement actually asks for: who must act, what, by when, to whom, and what evidence proves it. Record your reading and who made it, so the reasoning can be shown to a supervisor or auditor later.

  10. Decision

    Does your own reading confirm the overlap?

    Confirm it only if every part of one requirement is met by the control you designed for the other. A partial match is not an overlap. If you are unsure, answer no and treat the two as separate.

  11. Decision

    Does either regime add a timing, recipient, scope or test?

    Even a real overlap can hide a difference: a reporting deadline, a named authority to notify, a wider set of systems, a specific form of testing. Laws may set duties the Annex A controls do not cover, and these are the usual place. If not known, answer yes.

    In the pack

  12. Step

    Use one control, and note each requirement it serves

    In your own control list, record the control once, with every requirement it serves and the basis for linking them: the mapping you relied on, or your own reading. That record is how you show a supervisor why one control answers more than one duty.

    In the pack

  13. Step

    Treat it as a separate obligation, with its own control

    Keep the extra duty as its own item: its own owner, its own procedure step or control, and its own evidence. It may be a small addition to an existing control, such as a regulatory reporting step in the incident procedure. What matters is that it is visible and owned.

    In the pack

  14. Decision

    Are there overlaps left to check?

    Work through every overlap you are counting on to keep the set small. Each unchecked one is a place where a regime's requirement may be going unmet without anyone noticing.

  15. Step

    Keep evidence for each regime

    A supervisor and a certification auditor each ask for evidence in their own terms. Keep regulatory findings in the same gap tracker as ISMS gaps, with their own reference, so one list is managed. Keep each month's readiness assessment export, because a supervisor may ask for the assessment and its history.

    In the pack

  16. Outcome

    One control set, with each overlap checked and evidenced

    You now have the smallest set you can defend: shared controls where overlaps are checked, separate obligations where the regimes differ, and evidence for each. Review it with the Statement of Applicability, at least every 12 months, and when a law or the scope changes.

    In the pack

Practical checklist

  1. Keep one register of legal, regulatory and contractual security requirements, saying what each requires, with an owner for each.
  2. Get a written view of which regimes apply, to which entities and to which services.
  3. Check the ISMS scope covers the regulated services, and bring the legal requirements into the risk assessment.
  4. Choose controls from risk and law, recording Legal or regulatory as the reason where a law requires one.
  5. Design each shared control to the most demanding version: shortest deadline, widest coverage, most frequent test.
  6. Check each overlap you rely on against both texts: who acts, what, by when, to whom, and what evidence proves it.
  7. Record a confirmed overlap once with every requirement it serves; keep any extra timing, recipient, scope or test as its own owned item.
  8. Keep evidence for each regime, and review the set with the Statement of Applicability and when a law or the scope changes.

Evidence to have ready

  • The requirements register, with what each law or contract requires, its owner and how you meet it.
  • The written view of which regimes apply, to which entities and to which services.
  • The Statement of Applicability, showing Legal or regulatory as the reason where a law requires a control.
  • Your control list, recording for each shared control every requirement it serves and the basis for linking them.
  • Evidence kept in each regime's own terms, with regulatory findings tracked alongside ISMS gaps under their own reference.

Assumptions

  • You pursue or hold ISO/IEC 27001 certification, and at least one of NIS2 or DORA may apply to you.
  • CISO Times does not state that one framework's requirement is met by another's control. Any link between them has to come from a mapping you can check, or from your own reading of the texts.

Not covered here