ISO 27001 Contact with Authorities | Annex A 5.5 | The Lead Auditor’s Implementation and Audit Guide

/ By

ISO 27001 Annex A 5.5 Contact with Authorities is a security control that requires organisations to establish secure communication pipelines with regulators and law enforcement. The primary implementation requirement involves documenting an authority contact register, ensuring the business benefit of rapid, compliant, and legally sound incident reporting.

In this guide, I will show you exactly how to implement ISO 27001 Annex A 5.5 and ensure you pass your audit. You will get a complete walkthrough of the control, practical implementation examples, and access to the ISO 27001 templates and toolkit that make compliance easy.

I am Stuart Barker, an ISO 27001 Lead Auditor with over 30 years of experience conducting hundreds of audits. I will cut through the jargon to show you exactly what changed in the 2022 update and provide you with plain-English advice to get you certified.

Key Takeaways: ISO 27001 Annex A 5.5 Contact with Authorities

ISO 27001 Annex A 5.5 requires organizations to establish and maintain contact with relevant authorities to ensure the appropriate flow of information regarding security incidents, regulatory requirements, and legal obligations. While it may seem like “stating the obvious,” this control is a foundational part of governance. It ensures that when a crisis hits, like a major data breach or a physical fire, your team knows exactly who to call, how to report the issue, and what the legal timelines for notification are.

Core requirements for compliance include:

  • Identification of Authorities: You must list all regulatory, legal, and supervisory bodies relevant to your business. This includes data protection regulators (like the ICO in the UK), law enforcement, and utility providers.
  • Defined Reporting Processes: You must document how and when these authorities should be contacted. For example, GDPR requires notifying the regulator within 72 hours of a personal data breach.
  • Incident Response Integration: Your contact list must be accessible to your incident management and business continuity teams so they can act immediately during an event.
  • Regulatory Registration: You must prove that you have registered with mandatory authorities. A common audit failure is forgetting to register as a data controller with your local data protection registrar.
  • Continuous Maintenance: The contact list must be reviewed and updated at least annually to ensure the details (phone numbers, web portals, names) remain accurate.

Audit Focus: Auditors will look for “The Emergency Dial”:

  1. The List: “Show me your documented list of relevant authorities. Why have you included (or excluded) the local cybercrime unit?”
  2. Legal Registration: “Show me your current registration certificate with the Information Commissioner’s Office (or local equivalent).”
  3. Process Awareness: “If you suffered a ransomware attack at 2 AM on a Sunday, how does your incident responder find the contact details for your cyber insurance and law enforcement?”

Authority Contact Matrix (Audit Prep):

Authority Type Example Entity Critical Reason to Contact
Data Privacy ICO (UK) / DPC (IE). Mandatory Personal Data Breach Reporting (GDPR).
Law Enforcement Local Police / Cyber Unit. Theft of hardware, Fraud, or Ransomware attacks.
Utilities ISP / Power Provider. Connectivity or power outages affecting “Availability.”
Emergency Fire / Health & Safety. Physical facility incidents (e.g., Server Room fire).
Financial FCA / SEC / SEC. Compliance or regulatory breaches (if applicable).

Table of contents

Stop Guessing. Start Passing.

AI-generated policies are generic and fail audits. Our Lead-Auditor templates have a 100% success rate. Don’t risk your certification on a prompt

Get the Auditor-Proven Toolkit.
Fay Barker - High Table - ISO27001 Director

What is ISO 27001 Annex A 5.5?

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.

ISO 27001 contact with authorities is the requirement that organisations need to maintain contact with relevant authorities regarding security incidents, complaints, and vulnerabilities.

ISO 27001 Annex A 5.5 Purpose

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 Definition

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

What Changed in ISO 27001:2022 Annex A 5.5?

The 2022 update introduced a structural reorganisation that shifted how we categorise this control. In the 2013 version, Contact with Authorities was listed as Annex A 6.1.3. In the 2022 version, it has been streamlined into the newly created Organisational controls theme as Annex A 5.5.

Feature ISO 27001:2013 (Old Standard) ISO 27001:2022 (Current Standard)
Control Number Annex A 6.1.3: Contact with authorities Annex A 5.5: Contact with authorities (Renumbered and relocated).
Categorisation Housed under the “Organization of information security” domain. Housed under the consolidated Theme 5: “Organisational controls”.
Context and Application Often treated as a standalone administrative task or a static list of phone numbers. Integrated with modern cybersecurity attributes (Governance, Preventive). It now acts as a critical, active pipeline for incident response and mandatory regulatory reporting (such as GDPR or NIS2).

Watch the ISO 27001 Annex A 5.5 Tutorial

In the video ISO 27001 Annex A 5.5 Contact With Authorities Explained I show you how to implement it and how to pass the audit.

ISO 27001 Annex A 5.5 Podcast

In this episode: Lead Auditor Stuart Barker and team do a deep dive into the ISO 27001 Annex A 5.5 Contact With Authorities. The podcast explores what it is, why it is important and the path to compliance.

ISO 27001 Annex A 5.5 Implementation 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

  • Data protection regulator
  • Industry Regulatory Bodies
  • Government Agencies
  • Law Enforcement Agencies
  • Power Companies
  • Telecoms Companies
  • Utility Companies
  • Emergency Services

How to implement ISO 27001 Annex A 5.5

Implementing ISO 27001 Annex A 5.5 requires absolute precision. When an information security incident occurs, fumbling around to find the correct regulatory contact or allowing an unauthorised employee to speak to law enforcement is a critical failure. This control mandates that your organisation has pre-defined, secure, and highly controlled communication pathways with relevant authorities. As a Lead Auditor, I expect to see a documented, tested framework that proves your leadership team knows exactly who to call, when to call them, and how to record the interaction securely. Here is the exact 10-step technical process to operationalise this control and satisfy your auditor.

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.

I’ve sat in the Auditor’s chair for 20 years. These are the exact tools I use to guarantee a pass.

Get the Auditor-Proven Toolkit.
Stuart Barker - High Table - ISO27001 Director

Contact List Example Table

Type Authority Name Reason to Contact ISO 27001:2022 Control
Data Privacy ICO (UK) / DPC (IE) Data Breach (GDPR Reporting). Annex A 5.5 / 5.34
Law Enforcement Local Police / Cyber Crime Unit Theft, Fraud, Ransomware. Annex A 5.5
Utilities Power / Water Provider Service Outage (Business Continuity). Annex A 5.5 / 5.30
Emergency Fire Service Physical site fire. Annex A 5.5 / 7.1
Financial FCA / SEC Compliance breach (if regulated). Annex A 5.5 / 5.36

How to comply

To comply with ISO 27001 Annex A 5.5 you are going to implement the ‘how’ to the ‘what’ the control is expecting. In short measure you are going to

  • List the relevant authorities and document your who, how and when you will contact authorities

How to audit ISO 27001 Annex A 5.5

Auditing ISO 27001 Annex A 5.5 is about verifying that your organisation is not just “aware” of authorities, but has a functional, tested, and legally sound pipeline for communication. As a Lead Auditor, I am looking for the “Evidence of Readiness.” I want to see that if a breach happens at 2:00 AM, your team isn’t searching Google for the regulator’s phone number. This audit guide focuses on the action-oriented verification steps required to prove that your contact with authorities is controlled, authorised, and compliant with global statutory obligations. Here is my 10-step technical audit protocol for 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.

How to pass the ISO 27001 Annex A 5.5 audit

To pass an audit of ISO 27001 Annex A 5.5 Contact with Authorities you are going to make sure have listed and document the authorities that you contact and show evidence that you contacted them.

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 ISO 27001 Annex A 5.5 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.

Applicability of ISO 27001 Annex A 5.5 across different business models.

Business Type Applicability & Interpretation Examples of Control
Small Businesses

Emergency Contacts & Regulators. You don’t need a complex legal team. Compliance means having a simple “Emergency Contact List” that includes your data protection regulator (ICO) and non-emergency police numbers.

• ICO Registration: Ensuring you have paid your data protection fee and have the ICO helpline saved for breach reporting.
• Utility Contacts: Knowing who to call if your office internet (ISP) or power goes down, as this affects “Availability.”
Tech Startups

Breach Reporting (72 Hours). Startups handling user data must know exactly who to call when a breach happens to meet the 72-hour GDPR window. Panic leads to fines; preparation leads to compliance.

• Incident Playbook: A pre-written script for contacting the regulator (e.g., “We have detected a breach…”) integrated into your Incident Response Plan.
• Cyber Insurance: Keeping your insurer’s emergency hotline in your contact list, as they often provide legal counsel during a breach.
AI Companies

AI Safety & Emerging Regulation. As AI regulation tightens (e.g., EU AI Act), you must maintain contact with new oversight bodies regarding model safety and high-risk classifications.

• AI Safety Institute: Registering or maintaining contact with national AI safety bodies (UK/US) if developing frontier models.
• Copyright & IP Bodies: Maintaining contacts for Intellectual Property offices if your model training involves complex copyright licensing disputes.
Applicability of ISO 27001 Annex A 5.5 across different business models.

Fast Track ISO 27001 Annex A 5.5 Compliance with the ISO 27001 Toolkit

For ISO 27001 Annex A 5.5 (Contact with authorities), the requirement is to establish and maintain contact with relevant authorities, such as law enforcement, regulators, and utility companies. This ensures that in the event of an incident, the right information flows to the right legal and supervisory bodies.

Compliance Factor SaaS Compliance Platforms High Table ISO 27001 Toolkit Audit Evidence Example
Policy Ownership Rents access to your legal response plan; if you cancel the subscription, your documented regulatory history and contact logs vanish. Permanent Assets: Fully editable Word/Excel Authority Contact Lists and Incident Management templates you own forever. A localized “Contact with Authorities List” stored on your secure drive containing ICO registration and local police details.
Operational Utility Attempts to “automate” contact management via dashboards that cannot verify regulator registration or identify local police jurisdictions. Governance-First: Provides a “Contact List Example Table” to formalize your existing escalation and emergency relationships. A “Data Protection Certificate” or regulatory registration number integrated into your formal compliance documentation.
Cost Efficiency Charges a “Regulatory Tax” based on integrated frameworks or contacts, creating perpetual overhead for static legal information. One-Off Fee: A single payment covers your authority governance whether you track 5 regulatory bodies or 50. Allocating budget to actual security improvements or legal counsel rather than monthly “dashboard” subscription fees.
Strategic Freedom Mandates rigid reporting formats that often fail to align with lean office setups or specialized industry environments. 100% Agnostic: Procedures adapt to your operating style—from dedicated legal teams to simple internal escalation lists. The ability to evolve your legal communication strategy and regulatory footprint without reconfiguring a rigid SaaS module.

The Tools We Use.

100% Audit Success. Zero AI Guesswork.

Get the Auditor-Proven Toolkit.
Stuart and Fay High Table

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.

As a Lead Auditor, I look for the “Reporting Pipeline” when verifying this control. Annex A 5.5 is the operational bridge between your internal incident response and your external legal obligations. If you fail to maintain these contacts, you do not just fail an ISO audit: you risk massive fines under regimes like NIS2 or GDPR.

The following table maps these requirements to ensure your Information Security Management System (ISMS) satisfies the most stringent global standards.

Exhaustive Mapping Table: ISO 27001 Annex A 5.5 vs Global Regulations
Framework / Regulation Relevant Section How it Maps to ISO 27001 Annex A 5.5
GDPR (EU & UK) Article 33 (Notification of a personal data breach) Direct mapping: Annex A 5.5 provides the pre-defined contact process required to notify the Supervisory Authority (e.g. the ICO or DPC) within the mandatory 72-hour window.
EU NIS2 Directive Article 23 (Reporting obligations) Mandates that “essential” and “important” entities notify the CSIRT or relevant authority of significant incidents. A.5.5 ensures the organisation has the authorised contact points ready to meet the 24-hour early warning and 72-hour incident notification deadlines.
EU DORA (Financial Sector) Article 19 (Reporting of major ICT-related incidents) Requires financial entities to report major ICT incidents to competent authorities. Annex A 5.5 acts as the governance framework to ensure the specific regulatory portals and contact persons are identified and tested.
UK Data (Use and Access) Act 2025 Accountability Framework While reducing “red tape,” it maintains strict breach reporting thresholds. A.5.5 ensures that despite simplified governance, the organisation remains capable of rapid regulatory disclosure for significant data risks.
Cyber Security and Resilience Bill (UK) Mandatory Reporting for MSPs Expected to expand reporting requirements to a wider range of digital services, particularly Managed Service Providers. A.5.5 provides the mechanism for these providers to maintain live contact channels with the UK government.
NIST SP 800-53 (Rev. 5) IR-6 (Incident Reporting) NIST IR-6 requires organisations to report incidents to designated authorities. Annex A 5.5 is the organisational control that satisfies this by formalising who those authorities are and who is authorised to speak to them.
SOC2 (AICPA Trust Principles) CC7.3 (Incident Response) Requires communication with “external parties” during an incident. A.5.5 provides the specific, audited list of authorities (law enforcement, regulators) required to satisfy the “Communication” criteria of the trust principle.
CIRCIA (USA) 72-Hour Reporting Requirement Mandates critical infrastructure owners to report “covered cyber incidents” to CISA within 72 hours. A.5.5 is the audited process that ensures CISA contact details are in the incident response plan and are current.
EU AI Act Article 62 (Reporting of serious incidents) Providers of high-risk AI systems must report serious incidents to market surveillance authorities. A.5.5 is mapped here to ensure AI-specific regulators are included in the Authority Contact Register.
ISO/IEC 42001 (AI Management) Clause 10.2 (Non-conformity and corrective action) AI management systems require specific reporting to regulatory bodies when models behave outside of safe parameters. Annex A 5.5 provides the organisational structure for this reporting.
HIPAA (USA) 45 CFR § 164.404 (Breach Notification) Requires covered entities to notify the Secretary of HHS of breaches of unsecured PHI. A.5.5 ensures the specific federal reporting pathways are established and ready for use.
California Data Laws (CCPA/CPRA) Civil Code § 1798.82 Requires businesses to disclose security breaches to affected residents and the California Attorney General. Annex A 5.5 ensures the legal counsel has the correct AG reporting links documented and ready.
EU Product Liability Directive (PLD) Strict Liability for Software Extends liability to software producers for cybersecurity flaws. A.5.5 is critical here: management must maintain contact with market authorities to manage potential product recalls or systemic vulnerability disclosures.
ECCF (European Cybersecurity Certification Framework) Harmonised Security Labels Requires manufacturers to maintain communication with certification bodies. A.5.5 provides the audit trail of these interactions to maintain “Basic,” “Substantial,” or “High” security labels.
PCI DSS v4.0 Requirement 12.10 (Incident Response) Requires a plan to be in place for “notifying payment brands and acquirers” in the event of a cardholder data breach. Annex A 5.5 is the primary control used to manage these external financial authority relationships.

The Over-Reporting Dilemma (When NOT to Contact Authorities)

Most guides tell you to build a contact list, but they fail to warn you about the dangers of over-reporting. Contacting a regulator too early, or for a non-qualifying event, can trigger unnecessary audits and legal headaches. You must clearly define the threshold of a “material incident”. For example, a blocked firewall port scan is an information security event, not an incident, and it does not require police notification. As a rule, external Legal Counsel must usually be consulted before you trigger the formal Authority Contact pipeline to ensure you are not creating liability where none exists.

Multi-Jurisdictional Mapping (The Global Reporting Problem)

If a SaaS company has its headquarters in the United States, its servers in Germany, and its customers in the United Kingdom, who do they call when a breach happens? Searchers actively look for solutions to this specific nightmare. To solve this, you must identify your “Lead Supervisory Authority”. Documenting your primary jurisdiction answers the complex question of GDPR cross-border breach reporting and ISO 27001 international authority contact. Establishing this upfront prevents your incident response team from wasting critical hours debating which international regulator to notify first.

ISO 27001 Annex A 5.5 RACI Matrix

You must assign communication roles explicitly. If the wrong person contacts the regulator, the company is liable. Here is a simple text-based RACI matrix mapping out exactly who holds the authority for this control.

Task Responsible Accountable Consulted Informed
Triggering a GDPR 72-Hour Breach Notice CISO Legal / DPO External Counsel CEO / Board
Updating the Contact Register ISMS Manager CISO IT Department None

Key Performance Indicators (KPIs) and Metrics

Auditors want to know how you measure the effectiveness of this control. Here is a list of quantifiable metrics that prove Annex A 5.5 is being maintained effectively:

  • Register Verification Rate: Target 100 percent of authority contact details verified via test calls or emails every 12 months.
  • Mean Time to Notify (MTTN): Tracking the time elapsed between incident confirmation and authority notification during Tabletop Exercises. This must remain under 72 hours.
  • Unauthorised Disclosure Incidents: A target of zero instances where general staff bypassed protocol to speak to the press or regulators.

The Cost of Failure (Lead Auditor Case Studies)

Theory is good, but fear of failure drives compliance. You need to show your board what happens when Annex A 5.5 is ignored. Here are two anonymised real-world scenarios:

  • Scenario A (The 72-Hour Miss): A company wastes 48 hours figuring out who to call at the Information Commissioner’s Office. As a result, they miss the statutory GDPR reporting window and turn a minor, manageable incident into a massive regulatory fine.
  • Scenario B (The Rogue IT Admin): A junior analyst panics during a ransomware attack and tweets at the local police cyber unit. This accidentally discloses sensitive corporate liabilities to the public before the board is even aware an incident has occurred.

Secure Out-of-Band Tooling Recommendations

If your company is hit by severe ransomware, your Microsoft 365 or Google Workspace email might be completely locked down. How do you contact the authorities if your network is dead? You need secure, out-of-band communication tools. I highly recommend provisioning secondary, off-network communication methods. This includes deploying encrypted messaging applications like Signal, retaining physical emergency mobile phones, or establishing segregated cloud tenancies to ensure you can still email the regulator when your primary domain is compromised.

A 30-Day Implementation Roadmap

You have been told what to do, but you need to sequence it into a manageable timeline. Here is a four-week sprint plan to operationalise Annex A 5.5:

  • Week 1: Identify all legal and regulatory obligations and draft the initial Contact Register.
  • Week 2: Draft the standardised disclosure templates and submit them to Legal for formal sign-off.
  • Week 3: Update the Incident Response Plan to include the regulatory reporting thresholds and specific trigger points.
  • Week 4: Run a one-hour tabletop exercise simulating a breach to test the authority contact workflow in real time.

Before you pick up the phone to the regulator, you must understand the legal trap of early disclosure. When an organisation contacts law enforcement or a data protection regulator before engaging external legal counsel, they risk waiving “Legal Privilege” (often referred to as Attorney-Client Privilege in the US) on their internal forensic investigations. If privilege is waived, your internal communications, draft incident reports, and root cause analyses can become legally discoverable in future lawsuits or regulatory fines.

Your Incident Response Plan must include a legal buffer. The very first call during a major, material data breach should almost always be to your external legal counsel or breach coach. They will then direct and carefully filter the communication with authorities to protect the company’s liability while still satisfying mandatory reporting windows.

Traffic Light Protocol (TLP)

When you escalate a severe incident to national cyber agencies, such as the National Cyber Security Centre (NCSC) in the UK or CISA in the US, information is rarely sent via a standard, unclassified email. Highly mature organisations use the Traffic Light Protocol (TLP) to classify the sensitivity of the breach data they are handing over to the government.

Tagging your outbound regulatory communications with TLP:RED, TLP:AMBER, TLP:GREEN, or TLP:CLEAR dictates exactly how the receiving authority is permitted to share your threat intelligence or breach data. Embedding TLP classifications into your standardised regulatory disclosure templates proves extreme technical competence and guarantees you will impress any Lead Auditor.

The Ransomware Sanctions Trap (OFAC and OFSI)

If your organisation is hit by ransomware, contacting authorities is not just about reporting a data breach; it is a strict legal requirement to ensure the attacker is not on a government sanctions list. Before any ransom negotiation occurs, your incident response team must contact bodies like the Office of Financial Sanctions Implementation (OFSI) in the UK or the Office of Foreign Assets Control (OFAC) in the US.

Paying a sanctioned entity is a federal and criminal offence. Documenting these specific financial crime authorities in your Annex A 5.5 register proves that your ISMS is mature. This control is not just an administrative checklist, it is the exact governance framework that keeps your executive team out of prison.

The SEC 4-Day Rule (Form 8-K) for Public Companies

For publicly traded companies or those in their supply chain, the US Securities and Exchange Commission (SEC) has enacted brutal rules requiring the disclosure of “material” cybersecurity incidents within four business days via Form 8-K. If you fall under this jurisdiction, your Annex A 5.5 contact register must interface directly with your Investor Relations team and the Chief Financial Officer.

The CISO cannot manage this alone. You must map out exactly who holds the authority to determine “materiality” and trigger the SEC notification. Failing to align your ISO 27001 reporting thresholds with these SEC deadlines will result in catastrophic financial penalties and shareholder lawsuits.

The “Safe Harbour” Effect (Cooperation as a Financial Shield)

Companies are often terrified of contacting regulators because they assume it guarantees a massive fine. In reality, proactive and highly documented contact acts as a financial shield. Regulators like the Information Commissioner’s Office look for “proactive cooperation” when determining penalty tiers.

If you can prove that you followed a slick, well-rehearsed Annex A 5.5 process to notify them the moment you confirmed a breach, it acts as a massive mitigating factor during their investigation. Demonstrating this level of operational maturity can potentially save your company millions of pounds in punitive damages.

API-Driven Regulatory Reporting (The Future of Annex A 5.5)

The days of emailing a static PDF to a regulator are coming to an end. Modern regulatory frameworks and government agencies are moving towards automated API reporting. Highly mature ISMS environments are now integrating their Governance, Risk, and Compliance (GRC) platforms directly with regulatory APIs.

This technical integration allows them to automate breach notifications the second a critical severity threshold is crossed in their incident management system. If you want to future-proof your ISMS for the compliance landscape of 2027 and beyond, you should be exploring how to automate your authority contact pipeline rather than relying on manual emails.

ISO 27001 Annex A 5.5 FAQ

What is ISO 27001 Annex A 5.5?

ISO 27001 Annex A 5.5 is an organisational control that requires an organisation to establish and maintain appropriate contacts with relevant legal, regulatory, and supervisory authorities.

  • Ensures the organisation knows exactly who to contact during a security incident.
  • Mandates that contact procedures are formalised and kept up to date.
  • Facilitates compliance with statutory requirements for breach reporting.
  • Supports proactive situational awareness of the legal and regulatory landscape.

Which authorities should be included in the contact list?

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.

Is it mandatory to contact authorities for every incident?

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.

What is the difference between Annex A 5.5 and 5.6?

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.

How do you evidence Annex A 5.5 compliance for an auditor?

Auditors look for a documented list of contacts and verifiable evidence that these contacts are reviewed and tested as part of your incident response procedures.

  • A formal “Authorities Contact List” included within your ISMS documentation.
  • Evidence of periodic reviews (usually annual) to ensure contact details are accurate.
  • Logs or minutes from incident response tabletop exercises involving authority notification.
  • Documentation of any actual correspondence or reporting made to authorities.

When must you notify the ICO under ISO 27001?

Under ISO 27001 and the UK GDPR, you must notify the ICO within 72 hours of becoming aware of a personal data breach that is likely to result in a risk to individuals.

  • Notification is required if the breach leads to accidental or unlawful destruction, loss, or disclosure of PII.
  • Reporting is mandatory if the data breach involves sensitive “special category” data.
  • Initial notification can be made even if the full extent of the breach is not yet known.

Further Reading

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

Stuart Barker
🎓 MSc Security 🛡️ Lead Auditor ⚡ 30+ Years Exp 🏢 Ex-GE Leader

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 rigor 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.

Shopping Basket
Scroll to Top