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.
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.
Table of contents
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 Annex A 5.5 Contact With Authorities requires a clear process for managing communications with regulatory bodies. Businesses must maintain an up to date registry of relevant authorities within internal document systems to ensure quick responses during security incidents.
ISO/IEC 27001:2022 Annex A 5.5 Contact With Authorities
DO IT YOURSELF ISO27001
Stop Spanking £10,000’s on Consultants and Platforms
ISO 27001 Annex A 5.5 Video Tutorial
In this training video you will learn How to implement ISO 27001 Contact With Authorities (Annex A 5.5) and Pass Your Audit
Implementation Guide
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.
DO IT YOURSELF ISO27001
Stop Spanking £10,000’s on Consultants and Platforms
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 people make
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
Some would argue that ISO 27001 Annex A 5.5 Contact with Authorities is not that important as it is glaringly obvious. You would contact the fire department if you had a fire. You would contact the police if a crime was committed. I am not here to disagree with you. But the standard wants these things documenting so document them.
The purpose of this control is to ensure appropriate flow of information takes place with respect to information security between the organisation and relevant legal, regulatory and supervisory authorities.
Yes. Clearly it is stating the obvious but this has never stopped the standard before and it wont stop it now. They are explicitly required for ISO 27001.
ISO 27001 templates for ISO 27001 Annex A 5.5 are located in the ISO 27001 Toolkit.
ISO 27001 Annex A 5.5 is not hard. It is stating the obvious.
ISO 27001 Annex A 5.5 will take approximately 1 hour to complete if you are starting from nothing and doing it yourself.
The cost of ISO 27001 Annex A 5.5 will depend how you go about it. If you do it yourself it will be free but will take you about 1 hour so the cost is lost opportunity cost as you tie up resource doing something that can easily be downloaded.
Examples of authorities are
Utility companies
Telecoms Companies
The Police
The Fire Department
Data Protection Supervising Bodies
As a rule you follow their prescribed process for contacting them. Anything else would be madness.
Yes.
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.
The best GRC Platform for ISO 27001 Annex A 5.5 is High Table powered by HiComply.
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 |
Stuart Barker
ISO 27001 Ninja
Stuart Barker is a veteran practitioner with over 30 years of experience in systems security and risk management. Holding an MSc in Software and Systems Security, he combines academic rigour with extensive operational experience, including a decade leading Data Governance for General Electric (GE).
As a qualified ISO 27001 Lead Auditor, Stuart possesses distinct insight into the specific evidence standards required by certification bodies. His toolkits represent an auditor-verified methodology designed to minimise operational friction while guaranteeing compliance.
- MSc Security
- ISO 27001 Lead Auditor
- 30+ Years Exp
- Ex-GE Leader