ISO 27001 Annex A 5.5 requires an organization to establish and maintain appropriate contact with relevant authorities.

The purpose is to ensure that when a security incident, legal issue, regulatory matter, cyberattack, data breach, or other security-related situation requires external reporting or assistance, the organization knows:

Which authority to contact
When to contact them
Who is authorized to contact them
What information needs to be provided
How the communication should be documented

This control is particularly important for organizations operating in regulated industries or handling sensitive information.

Simple explanation

A.5.5 means your organization should know which authorities may need to be contacted for security, legal, regulatory, or cyber incidents—and have a defined process for contacting them.

It is not enough to say, “If something serious happens, we will contact the authorities.”

The organization should identify the relevant authorities and define the process in advance.

What does A.5.5 require?

The organization should determine the authorities that may be relevant to its information security activities and maintain appropriate contact arrangements.

Depending on the organization’s location, industry, customers, data, and legal obligations, authorities may include:

Situation	Potential Authority / External Body
Cybercrime	Cybercrime / law-enforcement authority
Data breach	Applicable data protection or regulatory authority
Financial-sector incident	Relevant financial regulator
Payment-card incident	Applicable payment-card ecosystem / authority
Criminal activity	Police / law enforcement
National cyber incident	Applicable national cybersecurity authority
Telecom-related incident	Telecommunications regulator
Industry-specific incident	Relevant sector regulator
Legal investigation	Law-enforcement / judicial authority
Employee criminal/security matter	Police or other applicable authority

The exact authorities depend on the organization’s jurisdiction, industry, legal requirements, contracts, and type of incident.

Why is A.5.5 important?

During a security incident, organizations can lose valuable time trying to determine:

Who should be contacted?
Is reporting mandatory?
What is the reporting deadline?
Who has authority to make the report?
What information can be shared?
Who should communicate with law enforcement?
Should the customer be informed first?
What evidence must be preserved?

A predefined process reduces confusion and helps prevent inappropriate or delayed communication.

For startups, this becomes especially important when the company starts serving customers in multiple countries.

Activities required to implement A.5.5

An organization can implement this control through the following activities.

1. Identify relevant authorities

Create a list of authorities relevant to the organization’s:

Country of operation
Customer locations
Industry
Regulatory environment
Data types
Contractual obligations
Technology environment

For example, a fintech company may need a different authority matrix from a SaaS company.

2. Determine when authorities must be contacted

Define situations that may require external notification or assistance.

Examples include:

Significant cybersecurity incident
Suspected cybercrime
Ransomware attack
Major data breach
Unauthorized access
Theft of information
Fraud
Regulatory violation
Legal order
Serious security incident affecting customers
Incident involving critical infrastructure
Incident requiring law-enforcement assistance

The organization should also identify applicable mandatory reporting requirements and deadlines.

3. Define responsibility

Clearly identify who can communicate with authorities.

For example:

Activity	Responsible Role
Identify incident	SOC / IT / Security Team
Escalate major incident	Incident Manager
Determine reporting requirement	Compliance / Legal
Approve external communication	Management / Authorized Officer
Contact authority	Authorized Security / Legal Representative
Preserve evidence	Security / IT
Maintain communication records	Incident Manager / Compliance

This prevents unauthorized employees from communicating sensitive information externally.

4. Maintain authority contact information

Maintain a controlled contact register containing relevant information such as:

Authority name
Jurisdiction
Purpose
Website / reporting portal
Contact number
Email address
Emergency contact
Reporting mechanism
Applicable reporting requirements
Internal owner
Last verification date

The register should be reviewed periodically.

5. Define escalation procedures

Your incident response procedure should explain when an incident must be escalated.

Example:

Security Incident Detected

↓

Initial Assessment

↓

Determine Severity

↓

Determine Legal / Regulatory Requirement

↓

Consult Legal / Compliance

↓

Management Approval, where required

↓

Notify Relevant Authority

↓

Preserve Evidence

↓

Document Communication

↓

Track Follow-up Actions

6. Establish communication protocols

The organization should define what information may be shared with authorities.

Depending on the incident, information may include:

Incident date and time
Systems affected
Nature of incident
Type of information involved
Number of affected records/users
Known indicators of compromise
Actions already taken
Evidence available
Contact details of the authorized representative
Current incident status

Information should be shared through approved and secure communication channels.

7. Maintain records of communication

Evidence should be retained for communications with authorities.

For example:

Incident notification
Reporting acknowledgment
Emails
Case/reference number
Official correspondence
Meeting records
Follow-up communication
Regulatory submissions
Closure communication

These records may become important during audits, investigations, legal proceedings, or customer assurance activities.

What events trigger action under A.5.5?

Organizations should identify events that may require contacting an authority.

Trigger Event	Possible Action
Major cyberattack	Assess law-enforcement/cyber authority notification
Suspected cybercrime	Escalate to legal/security and relevant authority
Personal-data breach	Assess applicable data-protection reporting obligation
Ransomware	Assess law-enforcement/cybersecurity reporting
Financial fraud	Assess relevant regulatory/law-enforcement notification
Regulatory violation	Notify applicable regulator where required
Customer contractual requirement	Follow contractual notification process
Government/legal order	Escalate to Legal and management
Critical infrastructure incident	Follow applicable regulatory requirements
Major security incident	Assess whether external notification is required

Important: Not every security incident automatically requires contacting an authority. The organization should assess the applicable legal, regulatory, contractual, and business requirements.

Example – SaaS Startup

Consider a SaaS startup based in India that provides its platform to customers in the US and Europe.

The company experiences a suspected unauthorized access incident involving a production database.

Without A.5.5

The team discovers the incident and starts investigating.

Nobody knows:

Whether an authority must be contacted
Who should make the decision
Which authority applies
What reporting deadline applies
Who is authorized to communicate externally

This can create unnecessary delays and inconsistent communication.

With A.5.5

The company has an Authority & Regulatory Contact Register and an incident-response procedure.

The incident team:

Detects the incident.
Classifies its severity.
Escalates it to the incident manager.
Determines what data and customers may be affected.
Involves Legal/Compliance.
Determines applicable notification requirements.
Contacts the relevant authority where required.
Records the notification and reference number.
Tracks follow-up communication.
Preserves relevant evidence.

This demonstrates that the organization has established a practical process for dealing with authorities.

Startup-Focused Quick Summary

Do startups really need A.5.5?

Yes, but A.5.5 does not mean a startup needs a large legal or compliance department.

A startup should simply know:

Who do we contact? → When do we contact them? → Who contacts them? → What do we report? → How do we record it?

For a small startup, a simple Authority & Regulatory Contact Register can be enough to establish the foundation of this control.

Minimum startup implementation

A startup can start with:

Identify relevant authorities.
Identify applicable reporting requirements.
Assign an internal owner.
Maintain contact information.
Add authority escalation to the Incident Response Plan.
Define who can communicate externally.
Maintain evidence of notifications and correspondence.
Review the contact list periodically.

Simple rule

Small team ≠ no process.

You do not need a dedicated compliance department to implement A.5.5.

You need a clear, documented and maintained process for contacting the right authorities when required.

Example Authority Contact Register

Authority	Jurisdiction	Purpose	When to Contact	Internal Owner	Contact / Portal	Last Verified
Cybersecurity Authority	Country	Cyber incidents	Major cyber incident	Security Lead	Official portal	Date
Law Enforcement	Country	Cybercrime / criminal activity	Suspected crime	Legal / Management	Official contact	Date
Data Protection Authority	Applicable jurisdiction	Personal-data incidents	Reportable breach	Privacy / Legal	Official portal	Date
Industry Regulator	Applicable industry	Regulatory incidents	Regulated event	Compliance	Official contact	Date

The register should be customized to the organization’s actual jurisdictions and regulatory obligations.

A.5.5 Audit Evidence

An auditor may look for evidence such as:

Policies and procedures

Information Security Policy
Incident Management Procedure
Incident Response Plan
Regulatory Compliance Procedure
Data Breach Response Procedure

Authority information

Authority Contact Register
Regulatory Contact List
Emergency Contact List
Reporting Portal Information

Incident evidence

Incident notification
Regulatory submission
Authority correspondence
Incident ticket
Case/reference number
Escalation record
Communication approval
Follow-up correspondence

Review evidence

Periodic verification of contact details
Review records
Updated authority register
Incident response testing

A.5.5 Audit Checklist

Audit Question	Evidence
Have relevant authorities been identified?	Authority Register
Are applicable jurisdictions documented?	Regulatory/Legal Register
Are reporting requirements identified?	Compliance Register
Are authority contact details maintained?	Contact Register
Is there an incident escalation process?	Incident Response Procedure
Is responsibility for external communication defined?	Roles & Responsibilities
Is Legal/Compliance involved where appropriate?	Incident Records
Are authority communications documented?	Communication Records
Are contact details periodically reviewed?	Review Evidence
Has the process been tested where appropriate?	Exercise/Test Records

Common Mistakes

1. Keeping only a list of police numbers

A simple emergency contact list is not enough.

The organization should understand which authority applies to which type of incident.

2. Not considering multiple countries

A SaaS company serving customers internationally may have obligations beyond its country of incorporation.

3. No ownership

A company may have a list of regulators but nobody responsible for determining whether notification is required.

4. No reporting criteria

“Contact authorities for serious incidents” is too vague.

Define how severity, legal requirements, contractual obligations, and data involved are assessed.

5. Outdated contact information

Authority portals, contact details, and reporting procedures can change.

The organization should periodically verify them.

6. Employees contacting authorities without authorization

Incident communications can contain sensitive information.

The organization should clearly define who is authorized to communicate externally.

7. No evidence

The organization may have a procedure but cannot demonstrate that it has actually maintained or tested the process.

Practical Implementation Model

A simple implementation model for A.5.5 is:

Identify Authorities

↓

Identify Applicable Requirements

↓

Define Reporting Triggers

↓

Assign Responsibility

↓

Maintain Contact Register

↓

Integrate with Incident Response

↓

Assess Incident

↓

Notify Authority When Required

↓

Record Communication

↓

Track Follow-up

↓

Periodically Review

Policy vs. Management Process vs. Evidence

It is useful to distinguish these three elements.

Element	Meaning	Example
Policy	What the organization requires	Security incidents must be escalated according to applicable legal/regulatory requirements
Process	How the organization performs it	Incident escalation and authority notification procedure
Evidence	Proof that it happens	Authority register, notification, acknowledgment, review record

A document alone does not demonstrate effective implementation.

The organization should be able to show that the process is maintained and can be used when required.

Useful Resources

Related ISO 27001 controls

A.5.5 works closely with other controls, particularly:

A.5.1 – Policies for information security
A.5.2 – Information security roles and responsibilities
A.5.3 – Segregation of duties
A.5.4 – Management responsibilities
A.5.24 – Information security incident management planning and preparation
A.5.25 – Assessment and decision on information security events
A.5.26 – Response to information security incidents
A.5.27 – Learning from information security incidents
A.5.28 – Collection of evidence

Final Takeaway

ISO 27001 Annex A 5.5 is about being prepared to communicate with the right authorities when an information security situation requires it.

A practical organization should be able to answer five questions:

Who do we contact?
When do we contact them?
Who is authorized to contact them?
What information do we provide?
How do we record the communication?

For startups, the implementation can be simple. Start with an Authority & Regulatory Contact Register, integrate it with the Incident Response Plan, assign ownership, and periodically verify the information.

A.5.5 = Identify → Define → Assign → Contact → Document → Review.

ISO/IEC 27001