When a ransomware attack encrypts your production environment at 2 a.m. and no one on the incident response team knows which regulator to call, every hour of confusion compounds the damage. Missed notification deadlines turn a containable breach into a compliance crisis — and regulators are not sympathetic to organizations that never documented who to contact or how. ISO 27001 5.5 exists to eliminate that gap before an incident forces the question.
What 5.5 Requires
ISO 27001 Annex A 5.5 requires organizations to identify all relevant legal, regulatory, and supervisory authorities and establish formal, documented contact procedures with each one. In practical terms, that means knowing exactly who you need to reach — data protection regulators, law enforcement, national CERTs, sector-specific supervisors — and having a tested process for doing so.
The control goes beyond keeping a phone list. Organizations must define the triggers that require authority contact, map each authority to specific incident types and severity thresholds, and assign clear internal roles for who initiates and approves external communications. These contact procedures must be embedded directly into incident response and business continuity plans, not maintained as a standalone document that collects dust. The supplementary guidance in ISO 27002 expands on these requirements with practical implementation advice.
Regular review is equally important. Regulatory landscapes shift, agencies reorganize, and contact details change. An authority register that is accurate today may be dangerously out of date by the next audit cycle. ISO 27001 5.5 requires organizations to keep this information current and verify it on a defined schedule.
Why 5.5 Matters
Picture a mid-size SaaS company that discovers a data breach affecting customer records across multiple EU jurisdictions. The security team scrambles to contain the technical damage, but when leadership asks “have we notified the regulator?” the answer is silence. No one knows which data protection authority has jurisdiction. No templates exist. No escalation path is documented. By the time legal counsel identifies the right body and drafts a notification, the GDPR’s 72-hour window has closed. The organization now faces a regulatory investigation not just for the breach itself, but for the notification failure.
This is not a hypothetical edge case. According to DLA Piper’s 2025 GDPR survey, cumulative fines have surpassed €7.1 billion — a figure that keeps climbing when organizations miss mandatory notification windows. Delayed reporting erodes trust with regulators, customers, and partners. It also signals to auditors that governance processes are reactive rather than embedded.
Without pre-established communication channels, incident response becomes ad hoc. The people handling the crisis are simultaneously trying to identify the correct authority, locate contact information, draft a notification from scratch, and decide who in the organization is authorized to speak externally. Every one of those tasks should already be answered before the incident occurs.
What Attackers Exploit
Control 5.5 mitigates a specific set of governance failures that widen the blast radius of any security incident:
- No documented authority contacts — incident reporting is delayed while teams scramble to find the right agency
- Unclear escalation paths — the wrong people end up speaking to regulators, creating legal exposure
- Outdated contact details — notification attempts fail because information has not been maintained
- Missing registration with mandatory bodies (e.g., a data protection registrar) — the organization is already in violation before any incident occurs
- No integration with the incident response plan — authority contact is treated as an afterthought rather than a defined step
- Lack of tested communication procedures — panic-driven, ad hoc reporting replaces a structured process
The risk class here is governance and compliance failure. On its own, it may look like a medium-severity control. Combined with an active incident, the severity escalates rapidly.
How to Implement 5.5
For Your Organization
1. Build an authority contact register. List every authority relevant to your organization’s operations: data protection regulators (ICO, CNIL, and equivalents for every jurisdiction you operate in), national law enforcement contacts, CERTs (such as CERT-EU or US-CERT), sector-specific supervisors (financial regulators, health authorities), and critical infrastructure or utility providers where applicable.
2. Define triggers. Map each authority to the incident types and severity thresholds that require contact. A personal data breach involving EU residents triggers GDPR notification to the relevant supervisory authority. A major ICT incident in financial services may trigger DORA reporting. A criminal intrusion requires law enforcement. Be specific — “notify the ICO when a personal data breach is likely to result in a risk to individuals” is actionable. “Contact authorities when appropriate” is not.
3. Assign roles. Designate who is authorized to initiate contact with each authority and who must approve external communications. This typically involves the CISO or security lead, legal counsel, and a senior management sponsor. Document backup personnel for each role.
4. Integrate with incident response. Embed authority notification steps directly into your IR playbooks and business continuity plans. Authority contact should appear as a defined step in the response workflow, not a footnote. Include legal notification timelines: GDPR requires notification within 72 hours of becoming aware of a breach. NIS2 mandates a 24-hour early warning for significant incidents.
5. Document reporting timelines. Capture every legal deadline in the register alongside the corresponding authority. RadarFirst research puts the average discovery-to-notification gap at 29.1 days — well beyond the 72-hour window GDPR demands, underscoring why pre-established contacts and rehearsed processes are essential.
6. Test annually. Run tabletop exercises that include authority notification scenarios. The exercise should test whether the team can identify the correct authority, locate current contact details, and draft a notification within the required timeframe.
7. Review and update. Refresh the register at least annually and after any organizational change (new markets, new jurisdictions, mergers) or regulatory change. Date-stamp every review and record the approver.
Common mistakes to avoid:
- Treating the register as a checkbox exercise — a static spreadsheet that no one maintains
- Forgetting to register with mandatory bodies (e.g., failing to register with the ICO in the UK)
- Assigning authority contact to IT alone without involving legal counsel
- Never testing the contact process until a real incident forces it
- Confusing internal escalation with external regulatory notification
For Your Vendors (Third-Party Assessment)
When assessing vendors against this control, ask direct questions: “Do you maintain a documented authority contact register?” “What is your process for notifying regulators during an incident?” “When was this process last tested?”
Request supporting evidence using a structured vendor risk assessment questionnaire: the vendor’s authority contact register, their incident response plan with notification steps highlighted, proof of regulatory registration (e.g., ICO registration number), and records from tabletop exercises that included authority notification.
Watch for red flags. If a vendor cannot name their relevant data protection authority, has no documented notification timeline, or their incident response plan contains no section on authority contact, the control is not implemented — regardless of what their questionnaire response claims. “We’ll figure it out when it happens” is not an acceptable answer.
Where possible, verify independently. Check public registries such as the ICO’s register of data controllers. For a deeper look at ISO 27001 third-party risk requirements, see our dedicated guide. Ask for evidence from the most recent tabletop exercise, including after-action findings related to authority notification.
Audit Evidence for 5.5
Auditors assessing this control look for documented processes and proof they are actively maintained and tested. If you are preparing for certification, our guide on what to expect from an ISO 27001 audit covers the broader process. The table below lists the key evidence types and what each looks like in practice.
| Evidence Type | Example Artifact |
|---|---|
| Authority contact register | Maintained list of all relevant authorities with contact details, communication methods, and designated internal contacts |
| Regulatory registration records | ICO registration certificate, CNIL declaration receipt, or equivalent for the organization’s jurisdiction |
| Incident response plan | IR playbook with authority notification procedures, escalation paths, and legal notification timelines |
| Communication templates | Pre-approved notification templates for data protection authorities and law enforcement |
| Tabletop exercise records | After-action reports from exercises that included authority notification scenarios |
| Review/update logs | Change log showing annual review of the authority register with dated approvals |
Cross-Framework Mapping
Control 5.5 does not exist in isolation. Organizations that comply with multiple frameworks will find that authority contact requirements appear in slightly different forms across standards. The table below maps each equivalent control, with “Full” indicating the external framework covers essentially the same scope as 5.5, and “Partial” indicating it addresses a subset — typically incident reporting without the proactive relationship-building that ISO 27001 emphasizes.
| Framework | Equivalent Control(s) | Coverage |
|---|---|---|
| NIST 800-53 Rev. 5 | IR-06 (Incident Reporting) | Full |
| SOC 2 (Trust Services Criteria) | CC7.3 (The entity evaluates security events to determine whether they could or have resulted in a failure… and responds) | Partial |
| NIST CSF 2.0 | RS.CO (Response - Communications) | Full |
| CIS Controls v8.1 | Control 17.2 (Establish and Maintain Contact Information for Reporting Security Incidents) | Full |
| DORA (EU) | Art. 19 (Reporting of major ICT-related incidents) | Partial |
Related ISO 27001 Controls
Control 5.5 connects to several other Annex A controls that together form the governance and incident response backbone of an ISMS. Understanding these relationships helps during both implementation and audit preparation — auditors often trace the thread from policy (5.1) through role assignment (5.2) to incident handling (5.24–5.26) to verify the control ecosystem is coherent.
| Control ID | Control Name | Relationship |
|---|---|---|
| 5.1 | Policies for information security | Authority contact requirements should be referenced in the overarching security policy |
| 5.2 | Information security roles and responsibilities | Defines who is authorized to contact authorities on behalf of the organization |
| 5.4 | Management responsibilities | Management must ensure authority contact processes are resourced and maintained |
| 5.6 | Contact with special interest groups | Complements 5.5 by covering ISACs, CERTs, and industry peer groups |
| 5.24 | Information security incident management planning and preparation | Authority notification is a core step in incident response planning |
| 5.25 | Assessment and decision on information security events | Determines when an event crosses the threshold for authority notification |
| 5.26 | Response to information security incidents | Executes the authority contact process during active incidents |
| 6.1 | Screening | Background checks may require law enforcement contacts established under 5.5 |
Frequently Asked Questions
What is ISO 27001 5.5?
ISO 27001 Annex A 5.5 is the control that requires organizations to identify relevant authorities, establish formal communication channels with each one, and integrate authority notification steps into their incident response processes. It covers data protection regulators, law enforcement, CERTs, and any sector-specific supervisory bodies relevant to the organization’s operations.
What happens if 5.5 is not implemented?
Without this control, organizations risk regulatory fines for missed notification deadlines, delayed and disorganized incident response, and loss of stakeholder trust. In practice, this means scrambling to identify the right authority during an active crisis, missing the GDPR 72-hour notification window, and facing audit nonconformities that can block certification.
How do you audit 5.5?
Auditors check for a documented authority contact register, clearly assigned roles for external communication, integration of notification steps into the incident response plan, and evidence that the process has been tested. The key question an auditor will ask is: “If a serious incident happened tomorrow, who would you contact and how quickly could you do it?”
How UpGuard Helps
Monitor your attack surface to catch incidents before they require authority notification.
UpGuard’s Breach Risk product continuously monitors for exposed data and security gaps across your organization and supply chain, helping you detect incidents early and respond before regulatory deadlines pass. Combined with continuous attack surface monitoring, you gain the visibility needed to act before notification deadlines hit.