Auditing ISO 27001 Annex A 5.5 is often treated as a “tick-box” exercise, which is exactly where organizations, and auditors, go wrong. On the surface, it seems simple: does the company have a list of phone numbers? But a good audit goes deeper. It asks: If the building is on fire or the server is compromised, does this list actually work?
As an auditor, your goal isn’t just to see a document. It is to verify preparedness. You are checking if the organization has established and maintained contact with the people who have the legal power to help them (or fine them). Here is how to audit this control effectively.
Table of contents
The Core Requirement: What Are You Testing?
The control requires the organization to “establish and maintain contact with relevant authorities.” When auditing this, you need to break it down into three evidence buckets:
- Identification: Have they listed the right authorities?
- Accessibility: Is the information available when systems are down?
- Maintenance: Is the information current?
Step 1: Reviewing the “Contact List” (The Evidence)
Start by asking for the list. This is usually found in the Incident Response Plan or a standalone “Annex A 5.5 Register.”
The “So What?” Test:
Look at the entries. If you see “Police: 911” and nothing else, that is a finding. In a corporate context, calling emergency services is rarely the right first step for a cyber incident. You are looking for:
- Specific Regulatory Bodies: (e.g., ICO, GDPR authorities, HIPAA regulators).
- Cyber Crime Units: (e.g., Action Fraud, FBI Cyber Division).
- Utilities: (ISPs, Power, Water—crucial for business continuity).
If the organization is using a generic template without customizing it to their region or industry, mark it as an observation. For comprehensive examples of what a compliant register looks like, the templates at Hightable.io are a good benchmark to compare against.
Step 2: Testing the “Maintenance” (The Currency Check)
The standard says “maintain.” This is the easiest way to catch a non-conformity.
The Auditor’s Move: Pick a random entry on the list. Ask the auditee: “When was the last time you checked if this phone number is active?”
Regulators change their reporting portals. Cyber crime hotlines change numbers. If the list hasn’t been reviewed in 12 months, it’s likely out of date. Look for a “Last Reviewed” date on the document or a calendar entry proving a periodic check.
Step 3: Interviewing on “Triggers” (The Process Check)
Having a number is useless if nobody knows when to call it. During your interviews with the CISO or Incident Managers, ask specifically about reporting thresholds.
Ask: “Who has the authority to contact the Data Privacy Regulator?”
Good Answer: “Only the Legal Counsel or CISO, and only after we have confirmed a breach of PII affecting more than X users.”
Bad Answer: “I guess anyone can call if they see something wrong.”
Unauthorized contact with authorities can be damaging. You want to see that the organization has a defined protocol for who talks to the police or regulators.
Step 4: Availability During Crisis
Where is this list stored? If the answer is “On the file server,” ask: “What if the file server is ransomware-encrypted?”
A robust implementation will have an offline copy or an alternative cloud-hosted copy available to the Incident Response Team. If the contact details for the authorities are inaccessible during the very emergency they are needed for, the control is not effective.
Common Non-Conformities to Watch For
1. Missing Industry-Specific Regulators
A Fintech company listing the police but forgetting the Financial Conduct Authority (FCA). This shows a lack of understanding of their legal context.
2. Confusion with Annex A 5.6
Finding “OWASP Forum” or “Local Security Meetup” on the Annex A 5.5 list. Those belong in Annex A 5.6 (Special Interest Groups). Authorities imply a legal or statutory relationship.
3. Dead Links
The URL for the regulatory reporting portal leads to a 404 error. This is definitive proof that the “maintain” part of the control has failed.
DO IT YOURSELF
STOP SPANKING £10,000s on CONSULTANTS and ISMS ONLINE PLATFORMS
Conclusion
Auditing ISO 27001 Annex A 5.5 is about verifying the organization’s lifeline to the outside world. You are ensuring that in a worst-case scenario, they are not isolated. By checking for specificity, currency, and accessibility, you ensure the control is actually adding value.
For auditors or implementers looking to standardize this process, Hightable.io provides toolkits that structure these requirements clearly, making the audit trail easy to follow and defend.
About the author
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, Stuart combines academic rigor with extensive operational experience. His background includes over a decade leading Data Governance for General Electric (GE) across Europe, as well as founding and exiting a successful cyber security consultancy.
As a qualified ISO 27001 Lead Auditor and Lead Implementer, Stuart possesses distinct insight into the specific evidence standards required by certification bodies. He has successfully guided hundreds of organizations – from high-growth technology startups to enterprise financial institutions – through the audit lifecycle.
His toolkits represents the distillation of that field experience into a standardised framework. They move beyond theoretical compliance, providing a pragmatic, auditor-verified methodology designed to satisfy ISO/IEC 27001:2022 while minimising operational friction.
