In this guide you will learn how to implement ISO 27001 Annex A 5.5 Contact with Authorities and pass your audit from ISO 27001 Lead Auditor Stuart Barker – author of the ultimate ISO 27001 Toolkit.
ISO 27001 Annex A 5.5 Contact with Authorities is an ISO 27001 control that requires an organisation to establish and maintain contact with authorities that are relevant to them.
Table of contents
- Purpose & Definition
- FREE ISO 27001 Annex A 5.5 Training Video
- ISO 27001 Annex A 5.5 Requirements and Guidance
- How to implement ISO 27001 Annex A 5.5
- How to audit ISO 27001 Annex A 5.5
- What an auditor looks for
- Top 3 Mistakes and How to Fix Them
- ISO 27001 Annex A 5.5 FAQ
- Further Reading
- ISO 27001 Controls and Attribute Values
Purpose & Definition
The purpose of ISO 27001 Annex A 5.5 is to ensure the appropriate flow of information takes place with respect to information security between the organisation and relevant legal, regulatory and supervisory authorities.
ISO 27001 defines ISO 27001 Annex A 5.5 as
The organisation should establish and maintain contact with relevant authorities.
ISO 27001 Annex A 5.5 Contact with Authorities
White Label
ISO 27001 for Consultants
Custom-brandable ISO 27001 documentation for consultants. Easily rebrand, reduce project time, and deliver professional, high-value security systems. Focus on delivery, not drafting.
FREE ISO 27001 Annex A 5.5 Training Video
In this free training video you will learn How to implement ISO 27001 Contact With Authorities (Annex A 5.5) and Pass Your Audit
ISO 27001 Annex A 5.5 Requirements and Guidance
You are going to have to ensure that:
- you identify and document what authorities apply to you
- in what circumstances you would contact them
- how information security incidents should be reported if relevant
- understand what expectations these authorities have, if any
- include relevant contact steps in your incident management processes
- include relevant contact steps in your business continuity plan and disaster recovery processes
People often scratch their heads at this one but an easy win is the contact with your data protection regulator that is likely mandated in law. In addition you can consider the likes of utility companies for power and water, health and safety if relevant, fire departments for business continuity and incident management, perhaps your telecoms provider for routing if lines go down.
How to identify the authorities you need to contact
You are going to identify the authorities that you might need to make contact with. If you are in a regulated industry that may be relatively straightforward as there may be regulatory bodies that you might need to make contact with.
If you’re within the European union and GDPR applies to you then you may need to register with your local data protection authority, for example in the UK you have to register with the Information Commissioner’s Office.
The next on the list, is going to be things like the support utilities such as water and power. These are usually things that you’ve identified as part of your Business Continuity management process or you’ve identified as part of your Incident Management process.
Finally, you’ve law enforcement agencies.
How to contact authorities
When it comes to how you’re going to contact them you’re just going to follow whatever process they’ve got. To document that you record their contact process.
It is unlikely for the majority of organisations that you have a special one to one relationship where you have your own bespoke process but in terms of the requirement of the standard you’re going to identify those authorities that you need to make contact with and how you contact them.
How to document contact with authorities
You’re going to list out the authorities that you may need to contact and record their contact details. You may record that how you contact them is via the processes that they have in place. This will be available to your incident management process and part of that process.
Examples of authorities to contact
Examples of authorities that you may need to contact
How to implement ISO 27001 Annex A 5.5
1. Formalise the Authority Contact Register
Compile a comprehensive, restricted-access register of all relevant regulatory, supervisory, and emergency authorities. This action results in a single source of truth that prevents critical delays during an active security incident.
- Identify and document contact details for law enforcement, cyber security agencies (e.g., the NCSC in the UK), data protection regulators (e.g., the ICO), and sector-specific supervisory bodies.
- Include primary and secondary contact methods, such as dedicated portal URLs, emergency telephone numbers, and specific email routing addresses.
- Store this register within your controlled Document Management System and restrict view access to the incident response team.
2. Assign Communication Roles and IAM Permissions
Delegate explicit authority to specific individuals who are legally permitted to communicate with external agencies. This action results in a highly controlled chain of command, eliminating the risk of conflicting or unauthorised disclosures.
- Update role descriptions to explicitly state who holds the accountability for regulatory reporting (typically the CISO, Legal Counsel, or Data Protection Officer).
- Configure Identity and Access Management (IAM) roles to ensure only these authorised personnel have access to external regulatory reporting portals.
- Implement Multi-Factor Authentication (MFA) on all accounts used to access supervisory reporting platforms.
3. Document Specific Regulatory Trigger Thresholds
Define the exact technical and operational conditions that mandate a report to the authorities. This action results in a clinical, objective decision-making process during the chaos of a breach.
- Map out reporting timelines required by law, such as the 72-hour notification window under GDPR or strict reporting SLAs under NIS2 and DORA.
- Document specific severity thresholds (e.g., volume of records compromised, type of data exfiltrated) that automatically trigger an escalation to law enforcement.
- Create a clear flowchart within your Rules of Engagement (ROE) document so incident handlers know exactly when to wake up the executive team.
4. Establish Secure Outbound Communication Channels
Provision encrypted communication pathways for transmitting sensitive breach data to regulators. This action results in the secure transit of evidence and protects against secondary data interception.
- Enforce TLS 1.2 or higher for all email communications directed to authority domains.
- Implement PGP encryption or secure file transfer protocols (SFTP) when submitting evidentiary logs or forensic data to law enforcement.
- Test these secure channels proactively to ensure firewalls or data loss prevention (DLP) tools do not block outbound compliance reports.
5. Integrate Authority Contacts into the Incident Response Plan
Embed the notification workflow directly into your operational incident playbooks. This action results in a cohesive response strategy where regulatory communication is treated as a primary containment and recovery step.
- Insert mandatory regulatory assessment checkpoints into the detection and analysis phases of your Incident Response Plan.
- Link the Authority Contact Register directly to the communication phase of the incident runbooks.
- Ensure the business continuity plan accounts for regulatory reporting even if primary internal networks are offline.
6. Implement a Centralised Evidence Logging System
Deploy a secure system to log all correspondence, timestamps, and files shared with authorities. This action results in an immutable audit trail that proves your organisation complied with mandatory reporting windows.
- Utilise a secure ticketing system or GRC platform to record the exact time an incident was discovered versus the exact time the authority was notified.
- Log all inbound requests for information from regulators and track the internal SLA for providing the requested evidence.
- Ensure these logs are backed up and protected against tampering to maintain forensic integrity.
7. Draft Standardised Regulatory Disclosure Templates
Pre-write and legally approve notification templates for the most common types of security breaches. This action results in rapid, legally sound communication that prevents accidental admissions of liability.
- Draft specific templates for ransomware attacks, accidental data disclosures, and third-party supply chain breaches.
- Ensure templates include placeholder fields for the nature of the breach, mitigation steps taken, and the internal point of contact.
- Have all templates pre-approved by external legal counsel to expedite the release process during a critical event.
8. Restrict Unauthorised Staff Disclosures
Update HR and security policies to explicitly forbid general employees from speaking to regulators or the press about security incidents. This action results in tight operational security and unified corporate messaging.
- Update the Acceptable Use Policy to outline the disciplinary consequences of unauthorised contact with external authorities.
- Train front-line staff, particularly the service desk and reception, on how to politely deflect and internally route unexpected inquiries from law enforcement.
- Include media and regulatory communication restrictions in the standard employee onboarding programme.
9. Execute Incident Simulation Tabletop Exercises
Run simulated breach scenarios that specifically test the regulatory notification workflow. This action results in muscle memory for the executive team and validates that the contact procedures actually work.
- Inject a scenario into your annual tabletop exercise where a regulator must be notified within a tight SLA.
- Test the designated contact person on their ability to locate the Authority Contact Register and articulate the reporting thresholds.
- Document the outcome of the exercise and raise corrective actions for any delays or confusion observed during the drill.
10. Audit and Update the Authority Register Annually
Schedule a recurring management review of all regulatory contacts and reporting obligations. This action results in sustained compliance and ensures you are never relying on dead telephone numbers or deprecated web portals.
- Assign a specific calendar date for the ISMS Manager to verify the accuracy of all regulatory contact information.
- Review the legal landscape to determine if new compliance regimes (e.g., regional privacy laws) require adding new authorities to the register.
- Present the updated register to the management review board and retain the meeting minutes as your final piece of audit evidence.
Check Your Work?
You built it yourself. Maybe with AI. But will it pass the audit?
Don’t gamble – let an ISO 27001 Lead Auditor check your work.
Summary: For Annex A 5.5, the auditor wants to see that you have a formal list of relevant authorities and proof of registration (like a Data Protection Certificate). The High Table ISO 27001 Toolkit provides the governance framework to satisfy this requirement immediately. It is the most direct, cost-effective way to achieve compliance using permanent documentation that you own and control.
How to audit ISO 27001 Annex A 5.5
1. Audit the Authority Contact Register for Currency
Inspect the master Authority Contact Register to ensure it is accurate and contains current technical entry points. This action results in verification that the organisation has a reliable single source of truth for emergency escalations.
- Verify that the register includes specific contacts for law enforcement, data protection regulators, and relevant sectoral bodies.
- Check that contact details include emergency “out of hours” numbers and specific regulatory portal URLs.
- Cross-reference the last update date against the annual review requirement to ensure the data is not deprecated.
2. Verify Authorised Communication Roles via IAM
Review the Identity and Access Management (IAM) permissions for regulatory reporting portals. This action results in confirmation that only specific, senior personnel have the technical ability to make legal disclosures.
- Inspect IAM logs to ensure access to reporting tools is restricted to the CISO, Legal Counsel, or designated DPO.
- Confirm that Multi-Factor Authentication (MFA) is active on all accounts with the authority to transmit data to external agencies.
- Review the organisational chart to ensure clear lines of accountability for authority liaison.
3. Inspect Documented Reporting Thresholds
Audit the organisation’s “Rules of Engagement” or Incident Response Plan for defined reporting triggers. This action results in proof that decision-making is objective and aligned with statutory timelines.
- Examine the documentation for explicit thresholds, such as a “72-hour notification window” for personal data breaches.
- Verify that the organisation has mapped NIS2 or DORA specific reporting requirements if applicable to their sector.
- Check for a clear “Severity Matrix” that dictates when an incident must be escalated to law enforcement.
4. Test Secure Communication Transmissions
Validate the technical security of the pathways used to share evidence with authorities. This action results in evidence that sensitive breach data is protected from interception during transit.
- Verify that outbound emails to regulators enforce TLS 1.2 or higher.
- Confirm that the organisation has the capability to use SFTP or PGP encryption for forensic log transfers.
- Check that Data Loss Prevention (DLP) rules do not inadvertently block legitimate outbound regulatory reports.
5. Audit Incident Response Plan Integration
Verify that authority contact workflows are embedded within the primary Incident Response Plan (IRP). This action results in confirmation that regulatory reporting is not an afterthought but a core containment step.
- Inspect the detection and analysis phases of the IRP for mandatory regulatory assessment checkpoints.
- Ensure the IRP explicitly links to the Authority Contact Register.
- Verify that the Business Continuity Plan includes manual “failover” contact methods if primary digital portals are unavailable.
6. Examine the Centralised Evidence Log
Inspect the centralised log of all correspondence with external authorities. This action results in a verifiable audit trail of the organisation’s compliance with mandatory notification windows.
- Review a sample of previous notifications (or simulated ones) for accurate timestamps and receipt confirmations.
- Confirm that all inbound requests for information from authorities are tracked against an internal response SLA.
- Check the integrity of the logging system to ensure it is protected from unauthorised modification or deletion.
7. Review Standardised Disclosure Templates
Inspect the pre-approved regulatory disclosure templates for technical accuracy and legal sign-off. This action results in assurance that the organisation can communicate rapidly without increasing legal liability.
- Confirm that templates exist for different scenarios, such as ransomware, data exfiltration, or supply chain failure.
- Verify that templates include placeholders for critical data points required by regulators.
- Check for evidence of formal legal or board-level approval of these templates.
8. Validate Policy Restrictions on Unauthorised Disclosures
Review the Acceptable Use Policy (AUP) and HR contracts for clauses regarding external communications. This action results in confirmation that staff are legally and procedurally barred from making unauthorised disclosures.
- Verify that the AUP explicitly forbids general employees from contacting regulators or law enforcement on behalf of the company.
- Check that disciplinary procedures are clearly linked to unauthorised security disclosures.
- Interview a sample of service desk staff to confirm they know how to route an unexpected call from the authorities.
9. Audit Tabletop Exercise Evidence
Inspect the results of the most recent Incident Response tabletop exercise. This action results in proof that the authority contact process has been tested under simulated pressure.
- Review the “Post-Exercise Report” specifically for findings related to regulatory communication.
- Verify that “Designated Contact Persons” participated in the drill and successfully located the Authority Register.
- Check that any gaps identified in the drill have been logged in the Corrective Action Plan.
10. Verify Annual Management Review of Contact Details
Inspect the minutes of the Management Review Board regarding regulatory obligations. This action results in proof of sustained governance and executive oversight of the control.
- Confirm that the Authority Contact Register was formally reviewed within the last 12 months.
- Verify that management has assessed the impact of any new legislation (e.g. the UK Data Act 2025) on their contact requirements.
- Check for authorised budget allocation for maintaining technical reporting tools and staff training.
What an auditor looks for
The audit is going to check a number of areas for compliance with ISO 27001 Annex A 5.5 Contact with Authorities. Lets go through them:
1. That you have a list of authorities you would contact
What this means is that you need to show that you have a list of authorities that you have considered and are in scope for you.
2. That you have a process to contact them
The process may be straightforward. Many authorities have pre defined ways in which you contact them. Just write them down.
3. That you have contacted authorities
There is not an expectation that you have contacted everyone on your list. It just wont be relevant. But some of those contacts will be mandated in law or regulation, and for those, you should have evidence the contact took place. A simple example would be registering with the data protection supervisory body.
Top 3 Mistakes and How to Fix Them
In my experience, the top 3 mistakes people make for ISO 27001 Annex A 5.5 Contact with Authorities are:
1. You didn’t register with the Data Protection registrar
Often a legal requirement, make sure you have registered as a data controller or data processor, which ever applies, with the relevant bodies. They will check.
2. You don’t have a list of relevant authorities
You thought it was obvious so didn’t write it down. Wrong. Write it down to show you considered it.
3. Your document and version control is wrong
Keeping your document version control up to date, making sure that version numbers match where used, having a review evidenced in the last 12 months, having documents that have no comments in are all good practices.
ISO 27001 Annex A 5.5 FAQ
The specific authorities required depend on your industry and location, but typically include law enforcement, data protection regulators, and sector-specific oversight bodies.
Law enforcement agencies (e.g., Action Fraud or the National Cyber Security Centre in the UK).
Data protection authorities (e.g., the Information Commissioner’s Office – ICO).
Regulatory bodies (e.g., the Financial Conduct Authority – FCA).
Emergency services and local government resilience forums.
No, you only need to contact authorities when an incident meets specific legal, regulatory, or contractual thresholds defined in your incident response plan.
Mandatory for personal data breaches that risk individuals’ rights (GDPR).
Required if the incident involves criminal activity or cyber-extortion.
Necessary if specific service level agreements (SLAs) with government bodies are breached.
Consult your internal risk assessment to determine the appropriate escalation path.
The primary difference is that Annex A 5.5 focuses on legal and regulatory authorities, while Annex A 5.6 focuses on peer groups, security forums, and special interest groups.
Annex A 5.5 is for compliance, reporting, and official oversight.
Annex A 5.6 is for knowledge sharing, best practices, and threat intelligence.
Authorities (5.5) have the power to penalise; Special Interest Groups (5.6) are for collaborative support.
Further Reading
- How to Implement ISO 27001:2022 Annex A 5.5: Contact with Authorities
- How to Audit ISO 27001:2022 Annex A 5.5: Contact with Authorities
- ISO 27001:2022 Annex A 5.5 for Small Business: Your Emergency Contact List
- ISO 27001:2022 Annex A 5.5 for AI Companies: Navigating the Regulatory Web
- ISO 27001:2022 Annex A 5.5 for Tech Startups: Who You Gonna Call?
ISO 27001 Controls and Attribute Values
| Control type | Information security properties | Cybersecurity concepts | Operational capabilities | Security domains |
|---|---|---|---|---|
| Preventive | Confidentiality | Identify | Governance | Defence |
| Corrective | Integrity | Protect | Resilience | |
| Availability | Respond | |||
| Recover |
About the author
