ISO 27001 Annex A contact with government authorities (A.5.5)

The due-diligence questionnaire asks who you would notify after a breach, and how quickly. Your honest answer is a name that lives in one person's head. ISO 27001 Annex A contact with government authorities, control 5.5, replaces that name with a register, a rule about who speaks and statutory clocks inside the incident plan.

This guide is for security managers, compliance leads and fractional CISOs at UK firms of 25 to 250 people. It covers the register, the policy wording, the templates, what auditors sample and how to automate the upkeep.

What does ISO 27001 Annex A 5.5 require?

ISO 27001 Annex A 5.5 requires you to decide, before an incident, which official bodies you may need to contact, who makes each call, on what trigger and how fast. "Authorities" covers regulators, law enforcement, utilities and emergency services, and the relationship runs both ways, carrying warnings back as well as reports out.

The control is both preventive and corrective. Pre-agreed contacts, thresholds and spokespeople stop the two classic failures: a missed statutory deadline and a free-for-all of unauthorised calls. Once an incident is live, the channel becomes part of the response, for example when you ask the police to act against the source of an attack.

In practice the control lives inside your incident machinery rather than beside it:

• Interested parties. Regulators appear as interested parties under Clause 4.2.
• Notification triggers. They sit in incident planning, which is the scope of Annex A 5.24.
• Continuity contacts. Utility and emergency numbers support your continuity planning.

If your ISMS dates from the 2013 edition, you will know this control as A.6.1.3. The 2022 revision renumbered it to A.5.5 within the Organizational Controls theme.

The effort is modest. At 50 people this is days of work, not weeks, because the register is a section of the incident response plan rather than a standalone framework. It is cheap to build and disproportionately expensive to lack.

Who counts as an authority in ISO 27001 Annex A contact with government authorities?

ISO 27001 contact with government authorities reaches beyond the regulator. It covers supervisors such as the ICO and FCA, the NCSC for incident support, Report Fraud (formerly Action Fraud) for cybercrime reports, and utilities and emergency services your continuity depends on. The NCSC is not a regulator and does not share incident details with regulators without permission.

Most firms of this size land on the same short set:

• Data and sector regulators. The ICO for data protection, plus a supervisor such as the FCA if you are authorised.
• The NCSC. Technical support and triage for cyber incidents.
• Report Fraud. The police route for reporting cybercrime and fraud, which replaced Action Fraud in December 2025.
• Police. Coordination during a live incident and requests to act against an attack source.
• Utilities and emergency services. Only where your continuity genuinely depends on them.

Choose by regime, not by habit. Ask legal which regimes reach you: UK GDPR does whenever you process personal data, an FCA authorisation adds a supervisor, and NIS2 or DORA add their own notice periods where they apply. Each regime you confirm becomes a row.

The NCSC deserves a closer look because teams often assume it is another regulator. The NCSC guidance on incident management and reporting cyber incidents says it will protect your information and will not share it with regulators without first seeking permission. That makes it a safe place to get technical help while you settle your regulatory position, but a report to the NCSC is not a notification to the ICO.

The flow also runs inwards. The same relationships that carry an incident report out bring threat warnings and early sight of rule changes back in, and that is half the value of the control.

Most of this is good practice you already want. You would ring the NCSC or the police in a serious attack anyway, and you would want the power company's number when the office goes dark. The control asks you to write it down once, before you need it.

What goes in a single-page authority contact register?

A single-page register holds one row per authority: why it applies to your firm, a primary and backup channel, a named relationship owner and a deputy, and a review date. Keep it inside the incident plan and name the owner in the Statement of Applicability, so the register survives whoever is on holiday.

Example rows for a 50-person firm regulated by the FCA:

• ICO: breach reports and the annual registration; online reporting with the helpline as backup; owned by the DPO, deputy the security lead.
• FCA: supervisory notifications; the firm's regulatory portal with a named mailbox as backup; owned by the compliance lead, deputy the CEO.
• NCSC and Report Fraud: cyber incident support and cybercrime reports; owned by the security lead, deputy the head of IT.
• Building and utility contacts: power, connectivity and site access; owned by the operations manager, deputy the CEO.

The Statement of Applicability is the index of which Annex A controls you have adopted. Naming who owns authority interactions there gives an auditor one place to start, and gives you one answer when a customer asks who is accountable.

One page is a constraint worth defending. A register that needs a binder never gets opened at 2am. Auditors look for owners, channels and a recent review date, and a single page shows all three at a glance.

The classic pitfall is a register that lives in someone's head. The person who knows who to call is on holiday during your worst week. A deputy on every row and a backup channel mean the next person can act without phoning anyone for a number.

Who is allowed to contact regulators and police during an incident?

Only a short, named list of people should contact regulators or police during an incident: usually the CEO, the security lead, and legal or the DPO. Acceptable use and HR policies should state explicitly that nobody else makes contact, so an engineer's panicked call can't contradict the official account.

The risk is rarely malice. It is a well-meaning engineer who rings the police mid-incident and gives a different story from the one legal is drafting. Firms tend to discover the missing rule only after that call has been made.

Each authorised role brings something different:

• CEO: escalation authority and the final word on the firm's position.
• Security lead: the technical facts, and the judgement on severity.
• Legal or DPO: legal cover and the notify-or-don't-notify call under UK GDPR.

Write the rule where staff will meet it:

• Acceptable use policy: state that only the named roles contact regulators or police about an incident.
• HR policy: carry the same rule, so it reaches every joiner and every contract.
• Incident plan: name the roles and a deputy for each, and tell everyone else to report internally.

Staff should meet the rule at induction and again in annual awareness training, together with the route they use instead: the incident channel or the security lead's phone. A clear internal route does more than the ban, because the engineer who rang the police was trying to help.

How do you build the UK GDPR 72-hour clock into your incident plan?

The UK GDPR requires a reportable personal data breach to reach the ICO without undue delay and within 72 hours of becoming aware of it. That clock belongs inside the incident plan, mapped from severity level to recipient and deadline, because 'notify as required' wording fails the first tabletop.

The ICO guidance on responding to a personal data breach within 72 hours sets the test plainly: report without undue delay if the breach meets the reporting threshold, and within 72 hours. Other regimes are tighter. NIS2 and DORA compress initial notice to a day or less, so if either reaches your firm, the plan needs a shorter first row.

The regulator's first question is never 'what happened?'. It is 'when did you know?'

Record the moment of awareness first in the incident log. The ICO's guidance is explicit that the clock starts when you discover the breach, not when it happened. Every later deadline is measured from that entry, and an auditor reconstructing a real incident will start there.

Build the notification table inside the plan, not in a separate document. Each row answers four questions:

1. Trigger: which severity level, or which kind of data, starts the notification?
2. Recipient: which authority receives it, and through which channel from the register?
3. Deadline: how long after awareness, and who confirms awareness?
4. Sender: which authorised spokesperson sends it, using which template?

A personal data incident graded at the notifiable severity might read: ICO, 72 hours from awareness, sent by the DPO using the personal-data template. One row per authority is enough at this scale.

The pitfall is the line that says "notify relevant authorities" with no thresholds, no names and no deadlines. It reads as comfortable until someone asks who, by when, and on whose decision.

Why should breach notification templates be drafted before an incident?

Pre-drafted notification templates for likely scenarios, such as ransomware, personal-data exposure and supplier compromise, should be reviewed by legal in peacetime and stored alongside the incident plan. Then nobody composes a regulator email from scratch at 2am, when an unguarded admission of liability is easiest to make.

Three templates cover most of what a mid-market firm will face:

• Ransomware: systems encrypted or unavailable, with data impact still unknown.
• Personal-data exposure: the case that feeds the ICO notification clock.
• Supplier compromise: a processor or vendor breach that touches your data.

Peacetime review lets legal strip out speculation about cause and any phrasing that reads as an admission. What remains are blanks for facts only: what happened, when you became aware, and how many people or records are affected. The spokesperson fills the blanks and sends.

Approved templates are also audit evidence. A dated, approved copy shows the notification step was prepared rather than improvised. Keep them with the incident plan, so the spokesperson finds the template in the same place as the checklist, and revisit them after each tabletop.

What do auditors sample for contact with authorities?

Auditors sample the register against the incident plan, the latest tabletop report, current ICO registration evidence, working portal logins and, after a real incident, the notification timeline against the statutory clock. An incident plan silent on notification duties typically grades major; a stale register entry grades minor.

Expect questions along these lines:

• Which authorities apply to your business, and where is that written down?
• Who may contact the regulator during an incident, and how would other staff know it is not them?
• Where do the thresholds and deadlines for your 72-hour breach process live?
• When did you last confirm that these contacts and portal logins still work?
• Can you show your current ICO registration, such as the fee receipt or register extract?

Grading follows certification-body practice rather than the wording of the standard. A threshold-level incident that went unreported sits alongside the silent plan as a major. One stale entry is a minor, but a pattern of them aggregates to major.

A notification pathway that has never been played in a tabletop is a diagram, not a capability.

The strongest exhibit is a tabletop report showing who rang whom, which clock ran and what broke. Run it once a year and refresh the register in the same sitting. If you have had a real notifiable incident, keep the timestamps, the outbound report and the correspondence trail together, because that bundle is what the auditor will sample first.

How do you automate register upkeep and statutory timers?

Hold authority contacts as records with an owner and a review-due date, so overdue reviews page the owner. Let a notifiable-severity incident start the 72-hour timer and assign the checklist to the named spokesperson. Track ICO fees like certificates, and put regulator portal accounts through the identity provider's joiner and leaver cycle.

Each automation turns a memory test into a system property. A versioned register shows who changed which number and when, and the timer starts when the incident is graded rather than when someone remembers. The table shows the pitfall each one inverts.

With these in place, the control runs without heroics. For enterprise due diligence, a register with review dates, a timer and a played tabletop answers the notification question with evidence rather than reassurance.

Frequently asked questions