How to Implement ISO 27001:2022 Annex A 5.5: Contact with Authorities

How to Implement ISO 27001 Annex A 5.5

Imagine the worst-case scenario: It is 2 AM on a Saturday. You have just discovered a massive data breach. Ransomware is spreading through your servers, and customer data is leaking. In that moment of panic, do you know exactly who you are legally required to call?

If your answer is “I’d Google it,” you are in trouble.

ISO 27001 Annex A 5.5: Contact with Authorities exists precisely for this moment. It ensures that when an incident occurs—whether it’s a cyber-attack, a break-in, or a regulatory violation—you aren’t wasting precious time looking for phone numbers. You know who to call, why you are calling them, and what you need to say.

What is Annex A 5.5 Asking For?

The requirement is straightforward but often misunderstood. The standard requires you to establish and maintain contact with relevant authorities.

This control is about preparedness. It isn’t just about having a list of names; it’s about understanding your legal and regulatory landscape. It ensures that information flow regarding information security incidents is timely, accurate, and goes to the right people who can actually help (or who need to be informed by law).

Who Counts as an “Authority”?

Many organizations get stuck here because they think “Authority” just means the police. While law enforcement is on the list, the scope is much broader. You need to identify every external body that has a say in your security or operations.

Typically, your list should include:

These are the big ones. If you process personal data, you are answering to a Data Protection Authority (like the ICO in the UK or various bodies in the EU/USA). If you are in finance, you have the FCA or SEC. If you fail to report a breach to these guys within their strict time limits (often 72 hours), you could face massive fines.

2. Law Enforcement

This includes local police for physical security issues (like a break-in at the office) and specialized Cyber Crime units for digital attacks. Don’t rely on the emergency “911” or “999” number for a complex cyber-attack; find the direct line for your regional fraud or cyber division.

3. Utility and Infrastructure Providers

If your internet line is cut or the power goes out, who do you call? Your ISP and electricity providers are “authorities” in the context of keeping your business running. You need their emergency support numbers, not the general sales line.

4. Emergency Services

The Fire Department and Ambulance services fall under this control as well. If your server room catches fire, you need to know the procedure for contacting them immediately.

Step 1: Identify Your Specific Requirements

You can’t build a list until you know who applies to you. Sit down with your legal counsel or compliance team and ask:

  • What jurisdictions do we operate in?
  • What data do we hold (Health? Financial? Personal?) and who regulates it?
  • Who provides our critical infrastructure?

Step 2: Build the Contact Register

Once you have your list, you need to document it. This doesn’t need to be fancy—a secure, accessible document is fine. However, it needs to be more than just a name and a number.

Your register should include:

  • Authority Name: (e.g., Information Commissioner’s Office)
  • Contact Details: (Phone, Email, Online Portal)
  • Reason for Contact: (e.g., “Report a PII breach”)
  • Trigger/Threshold: (e.g., “Only contact if >50 records affected” or “Contact immediately”)

If you are looking for a way to structure this without missing critical details, using a dedicated template is a smart move. Resources like Hightable.io offer comprehensive ISO 27001 toolkits that include “Contact with Authorities” registers, helping you get this documented correctly from day one.

Step 3: Define “When” to Call (The Triggers)

This is where most implementations fail. You do not want your junior night-shift engineer calling the national privacy regulator because they found a low-risk bug. That is a great way to invite an unnecessary audit.

You must define triggers. Your Incident Response Plan should clearly state who has the authority to contact these external bodies. Usually, contacting a regulator or law enforcement should be reserved for the CISO, Legal Counsel, or Senior Management.

Step 4: Maintain the List

The standard requires you to “maintain” contact. This means the list cannot be static. Authorities change their websites, hotlines, and reporting portals all the time.

The Fix: Schedule a 6-month or annual review. Actually click the links. Call the non-emergency numbers to verify they still work. Document that you did this review. This small act is exactly the kind of evidence auditors love to see.

Common Pitfalls to Avoid

Confusing Annex A 5.5 with Annex A 5.6: Annex A 5.5 is about Authorities (people who can fine/arrest/help you). Annex A 5.6 is about Special Interest Groups (forums, security meetups, industry groups). Keep them separate.

Storing the List on the Encrypted Server: If you get hit by ransomware and your only copy of the “Who to Call” list is on the infected drive, you have a problem. Keep an offline copy or a copy in a separate, secure system.

Conclusion

Implementing ISO 27001 Annex A 5.5 is about peace of mind. It ensures that when the adrenaline is pumping during a crisis, you don’t have to think—you just have to act. By identifying your regulators, documenting the contacts, and keeping them fresh, you turn a potential panic into a managed process.

If you want to speed up your implementation, check out the templates at Hightable.io to ensure your contact registers are compliant and audit-ready.

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

Stuart Barker

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