ISO 27001:2022 Annex A 5.5 Contact with authorities for Tech Startups

ISO 27001 Annex A 5.5 is a security control that mandates maintaining accurate contact details for relevant authorities to ensure rapid incident reporting. It requires organizations to identify and list legal, regulatory, and enforcement bodies for immediate communication. This provides the Business Benefit of minimizing regulatory fines and ensuring compliance with time-critical reporting laws like GDPR.

Picture this: It is 3 AM. Your lead developer just woke you up because your customer database is being auctioned off on the dark web. Panic sets in. You know you need to fix the technical issue, but who else do you need to call? The ICO? The FCA? Your cyber insurance provider?

If you don’t know the answer immediately, you are already failing ISO 27001 Annex A 5.5. For tech startups, this control often feels like overkill. You might think, “We are just a team of 12 people, do we really need a direct line to the FBI?” The short answer is: Yes, but it doesn’t have to be complicated. Forget the expensive SaaS modules; a simple document is your best defence here.

The Business Case: Why This Actually Matters

This isn’t about ticking a box. This is about survival when the clock is ticking on a 72-hour GDPR reporting window.

• Sales Angle: Enterprise clients ask: “Do you have a documented Incident Response Plan that includes statutory reporting?” If you say “We’ll Google it when it happens,” you look incompetent. Having this list pre-prepared proves operational maturity.
• Risk Angle: The “Regulatory Fine” Nightmare. Under GDPR, you have 72 hours to report a breach. Under DORA, it can be as little as 4 hours for an initial classification. If you waste 5 hours finding the right phone number, you are increasing your risk of a massive fine.

The “No-BS” Translation: Decoding the Requirement

The Auditor’s View: “The organisation shall establish and maintain contact with relevant authorities.”

The Startup’s View: Make a list of the “Security Emergency Services.” Just as you have 999/911 for a fire, you need numbers for a Data Breach (ICO), a Financial Hack (FCA), or a Cloud Outage (AWS Support).

For a Founder, this translates to:

• Regulator: Who can fine us? (e.g., ICO, CNIL).
• Enforcement: Who can arrest the hacker? (e.g., Action Fraud).
• Utility: Who keeps the lights/servers on? (e.g., AWS, ISP, Landlord).

DORA, NIS2, and AI Laws

Annex A 5.5 is the trigger point for compliance with modern digital laws.

• DORA (Fintech): DORA requires you to report major ICT-related incidents to the “competent authority” (e.g., the FCA in the UK) within strict timelines. Annex A 5.5 is where you document who that authority is and how to submit the report.
• NIS2: Essential entities must report significant incidents to the CSIRT (Computer Security Incident Response Team). Your Annex A 5.5 list must include the specific CSIRT for your sector (e.g., Energy, Transport, Digital Infrastructure).
• AI Act: If you deploy high-risk AI systems, you may need to report serious incidents to the national supervisory authority or the AI Office. Include these details in your Annex A 5.5 list to ensure you don’t breach AI safety regulations.

Why the ISO 27001 Toolkit Trumps SaaS Platforms

SaaS platforms love to sell you “Incident Management Modules.” But when your systems are down, do you really want your emergency numbers locked inside a cloud platform you can’t access?

Feature	ISO 27001 Toolkit (High Table)	Online SaaS GRC Platform
Access	Offline availability. It’s a Word/PDF doc you can print.	Requires internet and login. Useless during a total outage.
Ownership	You keep the file forever.	If you stop paying, you lose your contact list history.
Simplicity	A simple table. Name, Number, Reason.	Complex workflows to “add an authority” that waste time.
Cost	One-off fee.	Monthly subscription to store 5 phone numbers.

Top 3 Non-Conformities When Using SaaS Platforms

1. The “Login Lockout” Error: The startup experiences a ransomware attack that hits their SSO provider (like Okta/Google). They cannot log in to their GRC SaaS platform to find the number for the ICO. Major Non-Conformity for lack of availability of controls.
2. The “Generic List” Trap: The SaaS tool pre-populates the list with US authorities (FBI, CISA) because it’s a US tool. The UK startup fails to add the ICO or Action Fraud. The auditor spots that the “Relevant Authorities” are not actually relevant.
3. The “Empty Module” Fail: The startup pays for the “Incident” module but never configures the contact details because the UI is confusing. The list is blank during the audit.

Step 1: Identify Your “Relevant Authorities”

The term “authority” is broad. For a tech startup, this list usually encompasses three distinct categories:

1. Legal and Regulatory Bodies

If you handle personal data, you report to the Information Commissioner’s Office (ICO) in the UK. If you are in Fintech, it’s the FCA. If you sell to the NHS, it’s the DSP Toolkit bodies.

2. Law Enforcement

Local police are rarely helpful for cybercrime. List Action Fraud (UK) or your local cyber crime unit. Do not just write “999”.

3. Utility and Emergency Services

If your office is physical, list the Fire Brigade and Landlord security. If you are remote/cloud-native, list AWS/Azure Critical Support contacts.

Step 2: Create the Contact List (The “Red Book”)

You don’t need complex software. A simple, secure document (part of your Incident Response Plan) is sufficient. It should include:

• Authority Name: (e.g., ICO)
• Contact Reason: (e.g., “Report a data breach involving PII within 72 hours”)
• Phone/Email: (Verified contact details)
• Your Account/Reference Number: (Crucial for identifying yourself to them)

The Evidence Locker: What the Auditor Needs to See

To pass the audit, have these artifacts ready:

• The Contact List: A PDF or Word doc version dated within the last 12 months.
• Review Evidence: A calendar entry or meeting minute showing you checked the numbers actually work (e.g., “Annual Red Book Review”).
• Incident Response Plan: Showing when these authorities are contacted.

Common Pitfalls and Auditor Traps

• The “Dead Link” Trap: The auditor clicks the link to the “Breach Reporting Portal” in your document, and it 404s because the regulator changed their website. Check your links!
• The “Who decides?” Gap: The list exists, but nobody knows who has the authority to make the call. Calling the regulator is a legal decision; it should likely be the CEO or DPO, not a junior dev.
• Confusing Annex A 5.5 with 5.6: 5.5 is for Authorities (Police/Regulators). 5.6 is for Special Interest Groups (forums, peer groups). Keep them separate.

Handling Exceptions: The Break Glass Protocol

What if you can’t reach the authority, or the primary contact is unavailable?

• The Emergency: “The ICO portal is down.”
• The Action: Use the backup phone method or email documented in your list.
• The Paper Trail: Log the attempt time and the failure in your Incident Log to prove you tried to meet the 72-hour deadline.

The Process Layer: Standard Operating Procedure (SOP)

Tools: Notion (The List), Slack (Coordination).

1. Trigger: Incident Management Team confirms a reportable breach.
2. Consult: CEO/Legal reviews the “Red Book” (Annex A 5.5 List).
3. Action: Designated officer calls the number or logs into the portal.
4. Log: Record the “Case Reference Number” provided by the authority immediately.
5. Review: Quarterly, a junior admin verifies all URLs and phone numbers on the list are still valid.

Frequently Asked Questions (FAQ)

Conclusion

About the author

Implementing ISO 27001 Annex A 5.5 isn’t about bureaucracy; it’s about resilience. Start by identifying your regulatory landscape, build your list using the ISO 27001 Toolkit templates, and keep it accessible offline. It is a small administrative task that pays off massively when you are staring at a critical incident screen at 3 AM.