Cyber Regulatory Obligations Tracker

Work it in order: screen for applicability first, then fill the obligations tracker, map your incident-reporting clocks, and finish with a prioritised roadmap for the board. The goal is one mapped view of every obligation — not five parallel silos.

1. Run the applicability screen for each legal entity in the group — sector, jurisdiction, third-party-provider status and whose data you hold.
2. For every regime that may apply, fill a row of the obligations tracker; mark "applies?" as Yes / No / To confirm with counsel.
3. Fold overlapping obligations onto a common control set — tag one control to every obligation it satisfies rather than rebuilding it per regime.
4. Map the incident-reporting clocks so a single incident is pre-routed to every deadline it triggers.
5. Prioritise by nearest deadline, severity of penalty and size of gap, and bring the roadmap to the board.

Applicability is the first and most consequential call. Answer these per legal entity — a regime can reach you even if you are not the obvious target (e.g. a provider to a regulated entity, or a non-EU group serving EU customers).

• Sector — are any entities in a regulated or in-scope sector (financial services for DORA; the expanded "essential"/"important" sector list for NIS2; any sector for the SEC rules if US-listed)?
• Jurisdiction & footprint — where are you established, where do you operate, and do you offer goods/services to or monitor people in the EU (GDPR), or provide in-scope services into the EU (NIS2/DORA extraterritorial reach)?
• Third-party-provider status — are you an ICT third-party provider to regulated financial entities (potentially in DORA scope, including the critical-ICT-third-party oversight regime), even though you are not a bank yourself?
• Data subjects & residents — whose personal data do you hold (EU/UK residents → GDPR; residents of US states with privacy laws such as California → CCPA/CPRA and others; and state breach-notification laws keyed to affected residents)?
• Listing status — are you (or a parent) a US-listed registrant subject to the SEC Form 8-K Item 1.05 and Regulation S-K Item 106 disclosures?

One row per regime. "Key obligations" is where overlap shows up — tag the same underlying control (governance, risk assessment, incident handling, third-party risk) across the rows it satisfies instead of duplicating work. Mark "applies?" honestly; "To confirm" is a legitimate, counsel-bound status.

One incident can trip several regimes at once, each with a different trigger and clock running in parallel. Pre-map them so that on day one you know every deadline — you do not pick the strictest and ignore the rest.

Give the board a decision-grade view, not a control inventory: which regimes apply and why, the near-deadline and high-penalty items first, an owner and status per obligation, the governance duties the board must personally oversee, and the decisions and funding you are asking of them.

Separate what the board must own from what operations run. Board-level: oversight and approval of the cyber risk strategy, accountability for it, and (under NIS2) management-body training. Operational: the detection, patching, testing and notification mechanics the board oversees but does not run.

• Board-level obligations to oversee — strategy approval, accountability, NIS2 management-body training, SEC Item 106 oversight narrative.
• Decisions requested of the board — budget, prioritisation trade-offs, risk acceptance where a deadline cannot be met.
• Watch-items — extraterritorial reach onto non-EU entities, provider-status triggers (DORA), uneven NIS2 transposition, and the fact that NIST or other framework alignment is evidence of diligence, not proof of compliance.