How do we make sure we can notify a regulator before an incident happens?

Start

No incident yet: could we report on time tonight?

Reporting clocks run through nights, weekends and public holidays, and the first deadline can be hours away. A report fails at that point for reasons fixed in advance: nobody can sign in to the portal, the approver has no deputy, or the facts sit on a system the incident has taken down. The readiness checklist names eighteen checks, six of them blocking.

• Then: Approve the applicability profile

Step

Approve the applicability profile

The profile records, before any incident, whether NIS2, DORA and the GDPR can apply, in which role, which authority receives each report and through which channel, and any shorter clock or extra report national law sets. In the pack it is approved by executive management, reviewed at least once a year and whenever your status, services or authorities change. This check is blocking.

• Then: Record each authority's channel and out-of-hours contact

Step

Record each authority's channel and out-of-hours contact

For every authority in the profile, record the channel or portal, the address and the telephone number (a blocking check), the out-of-hours contact, and the language and any form it requires. Ring the out-of-hours number: a number on a website is not a tested contact. Where an authority publishes none, ask it, and record its answer or that it has none.

• Then: Name a signatory and a deputy for every channel

Step

Name a signatory and a deputy for every channel

A signatory is a person named in writing in advance, with the authority to submit reports in the organisation's name. Every channel needs a primary and a deputy. A small team still needs a deputy per channel: one person may own several checks, but not be the only way in. This check is blocking.

• Then: Test every signatory's sign-in, at least every 12 months

Step

Test every signatory's sign-in, at least every 12 months

Test access by signing in to the portal, not by confirming that an account exists, and record the date. The pack's default is at least every 12 months, ideally at an awkward hour. Sign-in must not depend on one person's device. In the pack's example the deputy for the NIS2 portal had no account, which made the whole result Not ready. This check is blocking.

• Then: Give the decider and every approver a reachable deputy

Step

Give the decider and every approver a reachable deputy

The executive incident lead decides whether to report, and the approver your incident response plan names for each template approves the report. Each needs a named deputy reachable out of hours (blocking). Agree Legal's out-of-hours contact and the review time limit too; external counsel on a retainer can cover nights and weekends.

• Then: Prefill the report and notice templates

Step

Prefill the report and notice templates

Keep the NIS2 and personal data breach templates current, with the entity's details already filled in, so the drafter writes only the incident's facts. Have the templates for notices to customers and individuals approved in advance, as the incident response plan names.

• Then: Make the fact base and log reachable in an outage

Step

Make the fact base and log reachable in an outage

Every report is drafted from one fact base and recorded in one log. Set both up in advance somewhere you can reach when the main systems are down, for example an out-of-band incident site, and prove it by opening them from a spare device. This check is blocking.

• Then: Put the notification clause in supplier contracts

Step

Put the notification clause in supplier contracts

A supplier that holds your data or runs your services must tell you of its incidents early enough for your own reports: within 24 hours in the pack's default clause. You screen its notice as your own incident, so a slow notice delays every report you owe. Check the clause is in each such contract.

• Then: Do we process personal data for another controller?

Decision

Do we process personal data for another controller?

Where you act as a processor, you notify the controller, not the authority, within 24 hours of awareness in the pack's default, or sooner where the contract says so. If you are not sure whether any contract makes you a processor, treat it as yes until the profile says otherwise.

• Yes, or not known: Record each controller's breach contact and notice period
• No: Does a third party submit DORA reports for us?

Step

Record each controller's breach contact and notice period

For each controller, record the breach contact its contract names and the notice period it sets. The Data Protection Officer notifies the controller; the controller decides whether to notify its authority and the people affected.

• Then: Does a third party submit DORA reports for us?

Decision

Does a third party submit DORA reports for us?

A financial entity may outsource its DORA reporting, and stays fully responsible for every report and its timing. If DORA cannot apply to you, the answer is no and the check is Not applicable, with the reason from the profile.

• Yes: Confirm the reporting contract and the third party's access
• No, or DORA does not apply: Rehearse a reporting decision and a report in an exercise

Step

Confirm the reporting contract and the third party's access

The contract names the third party as reporter, sets the times it must meet and gives it your fact base and log as its only sources. Tell the authority of the arrangement before the first notification. The decision to report and the approval stay with your own people; the third party submits and logs.

• Then: Rehearse a reporting decision and a report in an exercise

Step

Rehearse a reporting decision and a report in an exercise

Within the last 12 months, an exercise should have made people take a reportability decision and produce a report, for example a NIS2 early warning inject in a tabletop. In the pack's example, a tabletop that never rehearsed a report left this check Partly ready. Check too that the log holds every decision and report since the last check.

• Then: Rate each check on its evidence

Step

Rate each check on its evidence

For each check, look at the evidence and choose Ready, Partly ready, Not ready or Not applicable. Not ready includes a check with no evidence. The Head of Information Security gathers the answers and signs off the result, and the executive incident lead accepts it.

• Then: Is any blocking check Not ready?

Decision

Is any blocking check Not ready?

Six checks are blocking: the approved profile, the authorities and channels, named signatories with deputies, tested access, deputies for the decider and approvers, and a fact base and log reachable in an outage. Without any one of them a report cannot be made on time, whatever else is in place. A check with no evidence counts as Not ready.

• Yes, or no evidence: Not ready: fix the blocking check first, then re-check
• No: Is any check short of Ready?

Decision

Is any check short of Ready?

Partly ready means some of it is met, or met for some authorities or channels but not all. A blocking check that is only Partly ready gives Ready with gaps, and it is the next thing to fix.

• Yes, or not checked: Ready with gaps: one action, owner and date per gap
• No: Ready: check again within 6 months, or at once on a change

Outcome

Not ready: fix the blocking check first, then re-check

Give the blocking gap one owner and a due date in your own action list, ahead of everything else, and re-check as soon as it is fixed. Until then, a report due tonight could be missed.

Outcome

Ready with gaps: one action, owner and date per gap

Every check that is Partly ready or Not ready gets an action with one owner and a due date, blocking checks first. Report the readiness measure to executive management with the other headline measures every quarter. Run the full check again within 6 months in the pack's default, and at once when an authority, channel, signatory or the profile changes.

Outcome

Ready: check again within 6 months, or at once on a change

Every check is Ready or Not applicable. Keep the signed-off result with the profile and the log. Readiness decays as people leave and portals change, so run the full check again within 6 months in the pack's default, and at once when an authority, channel, signatory or the profile changes.