ISO 27001 Control A.5.5: Contact with Authorities

The worst moment to find out who you should notify about a data breach, a fire or a ransomware attack is during one. People are stressed, time is short, and the phone number you need is on a laptop that is now encrypted. A.5.5 asks you to do the unglamorous preparation in advance: know which authorities matter to your organization, know when you must or should contact them, and keep that knowledge current. It is the fifth of 37 organizational controls in Annex A.

Authorities are not only the police. Depending on your business they include data protection regulators, sector supervisors, national cyber security or CERT bodies, emergency services, tax and customs authorities, and the bodies that oversee your licences. The control is short, but handled well it saves hours when it counts.

What the control requires

Annex A control 5.5 of ISO 27001:2022 states that the organization shall establish and maintain contact with relevant authorities.

The key elements:

Establish - decide who the relevant authorities are for your organization and set up the means of reaching them before you need them
Maintain - keep contact details, procedures and any relationships current as people, laws and your own business change
Relevant authorities - those with a role in your legal obligations, your sector, your location and the incidents you could face

A.5.5 is a preventive and corrective control in ISO/IEC 27002:2022. It helps you prevent avoidable delays and reduces the damage when something has already gone wrong. Annex A states the control; ISO 27002 gives guidance, including that organizations should specify when and by whom authorities are contacted, how identified information security incidents are reported in a timely manner, and how information is exchanged with authorities. Please note that which authorities are relevant, and what reporting duties apply, depends on your jurisdiction and sector, so confirm specifics with qualified legal advice.

How to implement contact with authorities

Work out who is relevant

Start with a simple list, built from three questions. Who regulates us? Who must we tell if something goes wrong? Who could help us if something goes wrong? Your answers will vary, but the usual candidates are:

Data protection authority - for personal data breaches where notification applies, which we discuss only at a general level here because duties differ between countries
Sector regulators and supervisors - for example in finance, health, telecommunications or critical infrastructure, where incident reporting rules are often explicit
National cyber security centre or CERT - for advice, threat information and, in some regimes, mandatory reports
Law enforcement - for fraud, extortion, theft of equipment and similar crimes
Emergency services - fire, police and medical, relevant to the physical side of security
Utilities and infrastructure providers - power, water, telecommunications, whose outages can affect your operations

If you operate in several countries, repeat the exercise for each. The inputs for the list come from your understanding of context and obligations, covered in clause 4.1, Understanding the organization and its context, and clause 4.2, Understanding the needs and expectations of interested parties. Regulators are interested parties whose requirements you must understand.

Decide when, who and how

A list of names is not a procedure. For each authority record who in your organization is permitted to contact them, under what circumstances, and through which channel. Typical decisions include:

Who decides that an incident is serious enough to report, and by when
Who prepares the information the authority will ask for
Who speaks to the authority, so that communication is consistent and approved
What is said publicly, and how that matches what is told to the authority

Put the answers in a short contact register: authority, purpose, contact details, internal owner, deputy, triggers and any reference numbers or portals. Keep a copy offline or somewhere that does not depend on your own systems being up. This register becomes a core input to your incident procedures, and it is strongly connected to the way you handle information security event reporting inside the organization.

Build relationships, not just entries

Where it makes sense, make contact before an incident. Introduce yourself to your local cyber security contact, attend sector briefings, and learn how the reporting portal works. For physical risks, talk to your local fire service or building management about evacuation and access arrangements. A relationship does not mean favours; it means you know how things work and they know who you are. This is especially valuable in smaller organizations, where a short call to the right person can change how an incident unfolds.

Keep it current

Contact details change, authorities reorganize and reporting rules are updated. Assign an owner and a review cycle, for example twice a year, and trigger a review after any major incident, new market entry or change in regulation. Include a test: call or message a sample of the contacts to confirm they still work. Record the check, because the date on your register is a simple piece of evidence.

Remember that your communication with authorities sits alongside other communication obligations. The clause on communication asks you to decide what to communicate, when, with whom and how, and authorities are one audience in that plan.

One more habit is worth building: rehearse the call. A short tabletop exercise, where the team walks through a made-up breach or outage and fills in what they would tell the authority, quickly shows which facts are hard to obtain. Do you know how many records are affected? Can you tell when the problem began? Who has the logs? Discovering these gaps in a calm meeting room is far cheaper than discovering them in the middle of an incident, and the exercise record doubles as audit evidence.

A.5.1 connection. Policies for information security should make clear that incidents are reported to authorities where required.

A.5.2 connection. Information security roles and responsibilities names who is allowed to speak for the organization.

A.5.4 connection. Management responsibilities includes making sure staff know to escalate rather than improvise.

A.6.8 connection. Information security event reporting is the internal path that leads to an external report.

A.7.5 connection. Protecting against physical and environmental threats covers events where emergency services become the first call.

Clause 7.4 connection. Communication requires a plan for who communicates what, to whom, and when, including external bodies.

Forward reference. Incident management planning, assessment of events and response to incidents, together with legal and contractual requirements and privacy, build directly on the contacts established here; we cover them later in the Annex A series.

What auditors check

A list of relevant authorities. Auditors ask who you have identified and why, and compare it with your sector and locations. Missing the obvious regulator is a quick finding.

Defined triggers and owners. They look for a documented answer to when and by whom authorities are contacted, and ask staff whether they know it.

Working contact details. A register with dead numbers or departed employees as contacts suggests the control is not maintained.

Link to incident procedures. Auditors check that your incident process includes the step of deciding whether to notify, with a record of the decision.

Evidence of use or testing. Past contact, exercises or periodic verification of the details show the control is alive.

Consistency. What staff say, what the register says and what the incident plan says should match.

Common mistakes to avoid

Looking up the details during the crisis. Preparation is the whole point; the register should exist before it is needed.

One person holds the numbers. If the only owner is on holiday, nobody can act. Name a deputy.

Too narrow a view of authorities. Many organizations think of the police and forget their data protection authority, sector regulator or emergency services.

Unclear authority to speak. Staff who contact a regulator without approval can create inconsistent messages and legal exposure.

Stale information. A register last reviewed three years ago is a liability.

Assuming the law is the same everywhere. Reporting duties vary by country and sector. Take advice rather than guess.

How 27kay can help

We help organizations turn this control into a one-page register and a short procedure that people can actually find in an emergency. As part of ISO 27001 implementation, we identify which authorities and obligations apply to you, connect them to your incident process, and prepare the evidence for your audit. For the full picture, see our ISO 27001 knowledge hub.

If a serious incident started this afternoon, would your team know who to call first, and who is allowed to make that call? Get in touch - we will help you be ready before it matters.