Implementing ISO 27001 Annex A 5.5 (Contact with Authorities) is a mandatory information security control that requires organisations to establish and maintain a validated register of relevant legal, regulatory, and specialist emergency contacts. This Primary Implementation Requirement ensures rapid, authorised communication during cyber incidents, delivering the Business Benefit of minimised regulatory penalties, operational continuity, and effective crisis management.
ISO 27001 Annex A 5.5 Contact with Authorities Implementation Checklist
Use this implementation checklist to achieve compliance with ISO 27001 Annex A 5.5. This guide prioritises practical, operational readiness over theoretical documentation, ensuring you can effectively communicate with regulators and emergency services during a crisis.
1. Identify Your Legal and Regulatory Bodies
Control Requirement: The organisation must identify relevant legal, statutory, regulatory, and contractual authorities.
Required Implementation Step: Create a list of specific regulators for your sector (e.g., ICO for data, FCA for finance) including their mandatory reporting deadlines (e.g., 72 hours).
Minimum Requirement: You must list at least your primary data protection regulator (e.g., the ICO in the UK) with their breach reporting URL.
2. Identify Specialist Law Enforcement Contacts
Control Requirement: The organisation must maintain contact with law enforcement authorities.
Required Implementation Step: Research and document the direct phone number or reporting portal for your regional Cyber Crime Unit or Fraud Squad.
Minimum Requirement: Do not just list “999” or “911”. You must have the non-emergency contact for reporting cyber incidents.
3. Identify Critical Infrastructure Providers
Control Requirement: The organisation must maintain contact with utility and service providers relevant to information security.
Required Implementation Step: Document emergency support numbers for your ISP, electricity provider, and primary cloud host (e.g., AWS/Azure critical support line).
Minimum Requirement: A support ticket URL for your internet service provider and the emergency outage number for your office power grid.
4. Identify Emergency Services
Control Requirement: The organisation must have a process for contacting emergency services regarding physical security.
Required Implementation Step: Document the specific protocol for contacting Fire and Police services in the event of physical breaches or disasters at your physical locations.
Minimum Requirement: Clear instructions on physical facility noticeboards and in the register for contacting emergency services.
5. Create a Centralised Contact Register
Control Requirement: Contact information must be documented and maintained.
Required Implementation Step: Consolidate all identified contacts into a dedicated “Authorities Contact Register” document containing Name, Role, Phone, Email, and Website.
Minimum Requirement: A single spreadsheet or document labelled “Annex A 5.5 Authorities Register” containing all identified contacts.
6. Define Specific Notification Triggers
Control Requirement: The organisation must know when to contact authorities.
Required Implementation Step: Add a “Trigger” column to your register defining the specific scenario that necessitates contact (e.g., “Confirmed Ransomware,” “Data Loss > 50 records”).
Minimum Requirement: A clear statement linking “Personal Data Breach” to the Data Protection Authority contact.
7. Assign Authority-Specific Roles
Control Requirement: The organisation must specify who is authorised to report incidents.
Required Implementation Step: Explicitly name the job roles (e.g., CISO, DPO, Head of Legal) authorized to initiate contact with regulators to prevent miscommunication.
Minimum Requirement: The register must state “Owner: [Job Title]” next to each authority to prevent unauthorized staff from calling regulators.
8. Secure an Offline Copy of the Register
Control Requirement: Information must be available when needed.
Required Implementation Step: Store a physical hard copy or an offline digital copy (e.g., on a secure USB or separate device) of the contact register.
Minimum Requirement: One printed copy of the register stored in the secure physical location or with the Incident Management Team.
9. Verify Contact Details via Direct Testing
Control Requirement: Contact information must be kept up to date.
Required Implementation Step: Perform a “call tree” test where you actually dial non-emergency numbers and visit reporting URLs to confirm they are active.
Minimum Requirement: A log entry proving you checked the URLs and phone numbers within the last 12 months.
10. Schedule Bi-Annual Maintenance Reviews
Control Requirement: The organisation must review the contacts regularly.
Required Implementation Step: specific calendar invite for the Information Security Manager to review and update the register every 6 months.
Minimum Requirement: An annual review date recorded on the document itself.
ISO 27001 Annex A 5.5 SaaS / GRC Platform Implementation Failure Checklist
| Control Requirement | The “Checkbox Compliance” Trap | The Reality Check |
|---|---|---|
| Access to Contact Info | Storing the contact list exclusively inside the GRC SaaS platform or Intranet. | If you are hit by ransomware or your network goes down, you cannot access the list to call for help. |
| Relevant Authorities | Pre-filled lists provided by the tool that include generic “Police” or irrelevant foreign regulators. | Auditors will fail you if you list the FBI but operate solely in the UK. You need your specific local jurisdiction contacts. |
| Maintenance | The tool shows a “Last Reviewed” date that was auto-updated by clicking a button. | Unless you actually dialed the numbers, the review is fake. Regulators change portals and numbers frequently. |
| Authorisation | Any user with “Admin” access to the dashboard can see and potentially use the contact details. | Junior IT staff calling the ICO about a minor bug can trigger unnecessary full-scale audits. Access must be role-restricted. |
| Context / Triggers | A flat address book list with just names and numbers. | Without “Triggers” (e.g., “Only call if X happens”), staff won’t know why or when to use the contact, rendering the list useless in a panic. |
| Evidence of Testing | A screenshot of the populated list is presented as evidence. | Real evidence is a log of the test call or a screenshot of the reporting portal taken during the review, not just the list itself. |
| Cyber Specificity | Listing “999” or “911” as the primary contact for cyber incidents. | Emergency dispatchers cannot help with a SQL injection. You fail if you don’t have the direct line to the fraud/cyber unit. |
DO IT YOURSELF ISO 27001
STOP SPANKING £10,000s on CONSULTANTS and ISMS ONLINE PLATFORMS
About the author
