ISO 27001 A.5.5 - Contact with Authorities

Requirement

“The organization shall establish and maintain contact with relevant authorities.”

Plain-language meaning

The organization must know which external authorities matter for information security and must maintain usable contact paths before an incident, investigation, regulatory request, or emergency happens.

This is not a generic address book. The control expects clear, current, authorized contact arrangements for the authorities that affect security, compliance, continuity, and incident response.

Why this matters

During a serious incident, wasting time asking “who do we call?” is operational failure. A mature ISMS identifies the relevant authorities in advance, assigns liaison responsibility, defines what can be shared, and tests or reviews the contact process.

Relevant authorities may include:

• data protection regulators;
• law enforcement or cybercrime units;
• sector regulators;
• national cybersecurity centers or CERT/CSIRT bodies;
• emergency services;
• telecom, cloud, or critical infrastructure regulators;
• professional licensing or industry oversight bodies;
• contractual or governmental reporting authorities.

Implementation guidance

1. Identify relevant authorities

Create an authority contact register based on legal, regulatory, contractual, operational, and incident-response needs.

The list should be driven by Field of Application, Usage, and Compliance, Risk Assessment, Statement of Applicability, and business continuity planning.

2. Assign liaison responsibility

The organization should define who is authorized to contact authorities and who supports them.

Typical roles:

• primary authority liaison;
• legal counsel;
• data protection officer or privacy lead;
• CISO or security lead;
• incident manager;
• communications lead;
• executive approver.

Do not leave this to ad hoc judgment during a breach. That will fail under pressure.

3. Define contact triggers

For each authority, define when contact is required or appropriate.

4. Control what information is shared

Authority contact does not mean uncontrolled disclosure.

Define:

• who approves external communication;
• what information may be shared;
• what must be withheld or redacted;
• whether legal privilege applies;
• whether non-disclosure agreements are needed;
• required reporting formats;
• recordkeeping requirements.

This connects directly to Information Security Policy, A.5.2 Information Security Roles and Responsibilities, and A.5.4 Management Responsibilities.

5. Maintain and test contact details

Contact details should be reviewed periodically and after relevant changes.

Examples:

• regulator changes portal or notification address;
• liaison officer leaves;
• new jurisdiction becomes in scope;
• new supplier or sector obligation appears;
• incident response plan changes;
• business continuity contacts are updated.

Testing can be simple. For example, confirm portal access, validate emergency numbers, or run a tabletop exercise that includes authority notification.

Audit guidance

Auditors should verify that authority contacts are:

• identified based on actual legal, regulatory, operational, and incident-response needs;
• documented and current;
• assigned to named roles;
• linked to incident response, continuity, compliance, and reporting procedures;
• supported by approval and disclosure rules;
• known by the people expected to use them.

The auditor may test whether a liaison can explain:

• which authorities are relevant;
• when contact is initiated;
• who approves the contact;
• what information may be shared;
• how contact details are maintained;
• where records of authority communication are kept.

Evidence examples

Strong evidence

• Contact register includes authority name, purpose, trigger, owner, backup, contact method, review date, and approval requirements.
• Incident response playbooks include authority notification decision points.
• Legal or compliance mapping explains why each authority is relevant.
• Contact details are reviewed and tested at planned intervals.
• Liaison personnel can explain when and how to contact authorities.
• Actual incident records show timely, authorized, documented communication.
• External disclosures are reviewed by legal, privacy, or authorized management where appropriate.

Weak evidence

• A static list of phone numbers with no owner or review date.
• Generic “call regulator if needed” wording.
• Contact details stored only in one person’s inbox.
• No backup liaison.
• No clear approval path for sharing sensitive information.
• Incident responders do not know who can contact authorities.
• Authority contacts exist but are not connected to legal obligations or incident procedures.

Common failures

Exam traps

• “Authorities” does not only mean police. It can include regulators, CERTs, emergency services, sector bodies, and other official authorities.
• A contact list alone is not enough. The organization needs purpose, ownership, triggers, authorization, and maintenance.
• Contact with authorities is not only incident-driven. Some relationships may be maintained through periodic engagement or preparedness activity.
• This control does not authorize uncontrolled information sharing. Disclosure still needs approval and confidentiality handling.
• Small organizations are not exempt. Their contact set may be smaller, but it still must match their legal and operational context.

Related controls and concepts

• A.5.1 Policies for Information Security
• A.5.2 Information Security Roles and Responsibilities
• A.5.4 Management Responsibilities
• Risk Assessment
• Statement of Applicability
• Internal Audit
• Management Review
• Field of Application, Usage, and Compliance
• Information Security Management System

KB-ready summary

A.5.5 requires the organization to establish and maintain contact with relevant authorities. In practice, this means identifying applicable authorities, assigning liaison roles, defining contact triggers, controlling what information can be shared, keeping contact details current, and embedding authority contact into incident response, continuity, and compliance processes.

Templates and checklists

• Authority Contact Register
• A.5.5 Audit Checklist
• Evidence Request List
• Corrective Action Tracker