A.5.5 Contact with authorities: requirements and evidence

What A.5.5 contact with authorities asks for in plain terms

An auditor or customer who asks how your organization reaches regulators and police wants to see a named list of contacts, a clear trigger for when someone calls them, and proof that the list is kept current. A.5.5 Contact with authorities asks the organization to establish and maintain contact with relevant authorities so that information security matters flow to the right bodies at the right time, for example when an incident has to be reported. It is one of the 37 organizational controls in clause 5 of ISO/IEC 27001:2022 Annex A, and it carries forward the 2013 control A.6.1.3 of the same name. The control is short, but the organization still has to decide which authorities matter to it, who holds each relationship, and what happens when a report is due.

The control is hard in practice for three reasons. Contact details go stale when regulators change their reporting portals, named officers leave, or a supervisory body is reorganized. No single person often owns the list, so it sits in a former employee's inbox. And the reporting duties themselves sit in other regimes, such as sector rules, data protection law or contracts with customers, each with its own deadline and format. The practical check is to ask for the register of authorities, the owner and review date for each entry, and the incident playbook step that says who calls whom, within what time window. Confirm the specific deadlines with your own legal counsel, because they vary by sector and jurisdiction.

Evidence for A.5.5 is thin on its own and sits across other controls. The register of authorities supports it directly, but the proof that it works comes from the incident management planning and response controls (A.5.24 and A.5.26), the legal and regulatory requirements inventory (A.5.31), and any past notifications and their records. Related controls such as A.5.6 on special interest groups cover the informal channels for threat information. An assessor will often trace one real or simulated incident through these records to check that the contact list was used and the reporting path worked. Plan a tabletop exercise that includes a regulator notification step so you can show that evidence.

Which authorities, teams and reporting duties fall in scope

A.5.5 is only as good as the list behind it. The scope of authority contacts depends on where the organization operates, which sector it serves, how its group is structured and what its customer contracts require. The cards below cover the decisions that change the work, so the contact register reflects real reporting duties rather than a generic list.

Regulators and supervisory bodies by jurisdiction

Start with the regulators that supervise the organization's licensed or regulated activities in each country where it operates. A single sector often brings several supervisors, and each may expect a different contact route or notification channel. Check each entity's registration or licence conditions, then record the supervisor, the contact role and the statutory basis for reaching out. Illustrative example: a payments business licensed in two countries may hold two separate supervisory relationships with their own contact lists.

National CERTs and computer security teams

Many jurisdictions designate a national computer security incident response team that receives reports, issues alerts or coordinates incidents across sectors. Whether reporting to these teams is mandatory, voluntary or only expected depends on the sector and the country, so confirm it with counsel and the sector regulator. Record the reporting portal, the accepted report format and the contact role that can submit, and test that the route works before an incident forces its use.

Law enforcement and cybercrime units

Law enforcement contacts matter when an incident involves fraud, extortion, theft of data or an external attacker. Decide in advance who can open a case with police or a cybercrime unit, and under what conditions, since legal counsel usually approves those contacts. The register should name the unit or liaison route, not only a general number, and should note which evidence handling steps from A.5.28 must be followed before the contact is made.

Business units that hold reporting duties

Reporting obligations often sit with specific functions, such as the regulated business line, the data protection office, legal, or the operator of a critical service, rather than with the security team alone. Map each reporting duty to a named owner and a deputy, and record which business units can trigger a notification. This matters because the first report is often delayed while a team works out who has the authority to send it.

Group entities, subsidiaries and processors

Reporting duties may apply to each legal entity separately, even when a group runs one security programme. A subsidiary can be a regulated entity in its own right, and a processor may have to inform the controller or client instead of the authority. Confirm which entity is the reporting party for each jurisdiction, whether a parent can file on behalf of subsidiaries, and how processors pass information upstream without delay.

Customer contracts and notification routes

Customer agreements can add notification routes that go beyond statutory duties, including named contacts, shorter timelines and specific content for each notice. Review the incident notification and audit clauses of each material contract, since A.5.20 and A.5.31 both depend on them. Keep a matrix that shows which contract requires notice, to whom, within what window and in which format, so the contact register and the incident plan match what was promised.

How an assessor tests the contact list and reporting routes

This table walks through the checks an assessor usually runs on A.5.5, from the contact register through to past reportable events. Read each row as a test the assessor performs, the evidence they ask for, and the gap that most often causes a finding.

Assessor check	What the assessor does	Evidence requested	Common finding
Contact register exists	Asks for the list of relevant authorities, such as regulators, supervisory bodies, national CERTs and law enforcement contacts, and confirms it is written down rather than held in memory.	Authority contact register with organization name, purpose, channel and reason each authority is relevant.	No register exists, or contacts are only in an individual's email or phone.
Currency and ownership	Checks each entry has a named owner and a last-reviewed date, and compares entries against current regulator and sector guidance.	Register version history, owner assignments and review records.	Contacts have left the organization, mailboxes are unmonitored, or no review date is recorded.
Reachability sampling	Selects a sample of entries and checks that the listed channel (mailbox, portal account, hotline) is active and monitored, sometimes by a test message or a walkthrough.	Screenshots or confirmation of portal accounts, shared mailbox settings, on-call routing.	Shared mailboxes with no monitoring, expired portal logins, or phone numbers that route nowhere out of hours.
Contact establishment	Asks whether the organization has actually made contact with each relevant authority, not only listed it, and how that relationship is kept current.	Dated correspondence, registration confirmations, notes from introductory or periodic contact.	Listed authorities with no record of contact ever being established.
Link to incident response plan	Traces each authority in the register to the incident response plan and the decision points that trigger contact.	Incident response plan sections naming when and whom to notify, cross-referenced to the register.	Plan refers to reporting in general terms, with no named authority or trigger.
Link to A.5.24 and A.5.26 records	Checks that contact lists and reporting routes are part of incident preparation (A.5.24) and that response records (A.5.26) show notifications were made.	Contact lists in preparation material, training records, incident tickets showing authority notifications.	Contact lists in the plan are out of date or missing from exercise and training material.
Reporting duties in law and contract	Compares reporting duties identified in applicable law and contracts (A.5.31) with the routes actually in the process.	Legal and contractual obligations register, mapped to notification steps and timelines the organization must meet.	Reporting duty identified in a regulation or contract but absent from the incident process.
Past reportable events	Reviews a sample of past incidents and events that met the reporting threshold to confirm they went to the right authority, on time, through the right channel.	Incident records, submitted reports, timestamps and approvals for each notification.	Event met the threshold but no report exists, or it was sent to the wrong body or late.
Use of the register in exercises	Asks whether the routes were tested in tabletop or live exercises and whether gaps found were fixed.	Exercise plans, after-action reports and corrective action records.	Exercises never include the authority notification step.

Steps to build and maintain the authority contact register

This sequence turns A.5.5 from a line in the policy into a working register: who the organization must contact, through which channel, for which incidents, and how the list is kept current. Each step produces an artifact an auditor can sample and a responder can use under pressure.

Identify applicable authorities from legal obligations
Start from the legal, statutory, regulatory and contractual requirements register maintained under A.5.31, and list every authority that the organization must or may contact about information security. Typical sources include data protection regulators, sector supervisors, national computer emergency response teams, law enforcement units and customer contracts that name a notification recipient. Confirm each entry against the current text of the obligation with legal counsel, because regulator names and reporting routes change. The output is a scoped authority list with the legal basis cited next to each entry.
Assign a named owner for the register
Give the register one accountable owner, typically a security or compliance lead, with a named deputy who can act when the owner is unavailable. The owner decides who may contact an authority on the organization's behalf, and the deputy keeps the list usable during leave or staff changes. Record the ownership decision in the information security roles documentation so that an auditor can trace who maintains the contacts. The output is a signed-off ownership record that names both people.
Record contacts, channels and escalation paths
For each authority, record the contact point role (not only a personal name), the approved channel such as a secure portal, email address or telephone line, the language and format the authority expects, and the escalation path if the first contact does not respond. Store the register in a location that survives an outage of the primary corporate systems, and keep an offline copy available to the incident team. Ask each authority which contact details it wants on file, because some require registration before they accept reports. The output is a contact register with a verified channel for every entry.
Map each authority to incident types and clocks
Build a routing matrix that links each authority to the incident categories it must hear about, the decision criteria from the event assessment process under A.5.25, and the reporting deadlines set by the governing obligation. Read those deadlines from the source text rather than from memory, and record the trigger that starts each clock. Where one incident must go to several authorities, state the order and who sends each notice. The output is a routing matrix that the incident response plan under A.5.24 and A.5.26 can reference directly.
Rehearse one notification in a tabletop exercise
Run a tabletop exercise based on a plausible scenario, such as a reportable breach affecting customer data, and require the team to produce a draft notification to one authority using only the register and routing matrix. Time how long it takes to locate the right contact, confirm the channel works and identify the required content. Note gaps, such as missing contacts, unclear triggers or approvals that stall the notice, and assign fixes with owners. The output is a dated exercise record with findings and corrective actions, which is among the evidence an assessor is likely to ask to see.
Set a review cadence and change triggers
Agree a review interval for the register and write it into the procedure, and add change triggers that force an earlier review, including a new regulation, a change in regulator, a new customer contract with notification terms, a reorganization or a missed contact during an exercise or real event. At each review, verify that every channel still responds, every contact role is still staffed and the routing matrix matches the current legal text. Keep dated versions of the register so that the history of changes can be shown. The output is a review log with signed entries, which closes the maintenance loop for A.5.5.

How contact with authorities connects to incident reporting duties

A.5.5 is the relationship layer that sits beneath reporting obligations. Its job is to make sure the organization already knows who the relevant authorities are, how to reach them and who is allowed to speak for the organization before an incident forces the question. The control does not itself set a reporting deadline or define what must be reported. Those duties come from other regimes, and the NIST crosswalk from SP 800-53 Rev. 5 to ISO/IEC 27001:2022 relates A.5.5 to IR-6 Incident Reporting as a reference point for teams mapping the two. Treat that relationship as a starting pointer, not as proof that one control satisfies the other.

Two activities need to be kept apart. Establishing contact is ongoing and happens before any incident: maintaining a current register of regulators, supervisory bodies, national computer security incident response teams and law enforcement contacts, confirming the named points of contact, and agreeing with legal counsel which roles may file a report. A specific report is event-driven: it is triggered when an assessed event meets a reporting threshold under a particular regime. An auditor testing A.5.5 will usually look for the register, its review dates and evidence that contacts were tested or updated, while the report itself is evidence that belongs to the incident records under A.5.25 and A.5.26.

Regimes such as DORA, NIS2 and GDPR each carry their own reporting timelines, stages and recipients, and the team must confirm these directly against the legal text and any national implementing rules that apply to its entity, rather than relying on summaries. Confirm which authority receives each type of notification, what information is required at each stage, and whether a sector regulator also expects a copy. Then record the answers in the contact register and in the incident response playbook, so that the people on call know which clock is running when an event is declared.

Evidence that passes an A.5.5 audit

An auditor testing A.5.5 Contact with authorities usually asks two questions: does the organization know which authorities to contact and when, and does its record show that it did. The cards below cover the register, the routing rules, the relationship records, the incident tickets, the exercises and the periodic sign-off that together answer both questions.

Authority contact register

A register listing each relevant authority (regulators, supervisory bodies, sector CERTs and law enforcement contacts), with the named owner, the contact route, the purpose of the relationship and the date it was last verified. Auditors check that the entries match the authorities that actually apply to the organization's sector and locations. Confirm with legal counsel which regulators apply, since that list drives everything else. Review each entry on a fixed schedule so that stale phone numbers and mailboxes are caught between audits.

Reporting routing matrix

A matrix that maps each incident type, such as personal data breach, service outage, fraud or suspected ransomware, to the authority or authorities that must be notified, the deadline that applies, and the role responsible for the decision. The matrix turns A.5.5 from a contact list into a working procedure. Check that it agrees with the incident response plan under A.5.24 and A.5.26 and with the statutory deadlines identified under A.5.31.

Relationship and introduction records

Records showing that contact was actually established: introductory meetings, registration confirmations with a supervisory body, portal account approvals and correspondence confirming the reporting channel works. Auditors often accept a dated email or meeting note more readily than a statement that contact exists. Keep these with the register entry they support, so that a change of named owner also shows a handover and a fresh introduction.

Incident tickets with notification decisions

For each incident that met a notification threshold, the ticket should record the decision, who made it, the time the clock started, the time the notice was sent and the reference the authority returned. Tickets for incidents judged not notifiable should show the reasoning too. Auditors sample these tickets against the incident log to test whether decisions were made on time and recorded. Case management platforms such as DFIR-IRIS can hold the timeline, evidence and audit trail in one record.

Notification exercise records

Records from tabletop or live exercises in which the team practised notifying an authority, including the scenario, the participants, the draft notice, the time taken to reach the correct contact and the gaps found. An exercise that never reaches the authority channel proves less than one that does. Schedule exercises at a planned interval and after changes to staff, reporting portals or the regulatory list, and record the corrective actions with owners and due dates.

Register sign-off at review

A dated review of the register and routing matrix, signed by the accountable manager, confirming that each contact is still valid, each owner is still in post and the authority list still reflects the organization's obligations. The sign-off should cite the changes made, such as a new regulator or a replaced owner. Include the review in the management review inputs so that top management sees whether reporting relationships are kept current.

What meeting A.5.5 costs in money and effort

This table breaks down the cost components of keeping an authorities contact register and running it under A.5.5, showing who does each piece, whether it is one-time or recurring, and what drives it up or down. No prices are given because none were supplied, so use the right-hand column to write your quote requests.

Cost component	Who is paid or who does the work	One-time or recurring	What drives it, and what to ask for in a quote
Building the authorities register	Internal staff, usually compliance or security, with IT and legal input	One-time, then updated	Number of regulators, supervisory bodies and law enforcement contacts. Ask a partner to quote the register build as a fixed scope with named deliverables.
Legal review of which authorities apply	External counsel or the in-house legal team	One-time, then on change	Number of jurisdictions, sectors and contracts that create notification duties. Ask counsel to state the scope of advice, the jurisdictions covered and whether the output is a written memo.
Keeping contacts current	Named register owner, with HR and facilities for personnel changes	Recurring	Staff turnover, changes in regulator personnel and reporting portals. Ask for a stated review frequency and a named owner in the procedure.
Reporting route and template setup	Internal incident response lead, sometimes with an implementation partner	One-time, then reviewed	Number of reporting routes per authority and format requirements. Ask for the routes to be tested against each authority's current intake channel.
Exercises and tabletop time	Incident response team, legal, communications and management	Recurring, usually annual or after major change	Number of scenarios and reporting deadlines exercised. Ask a partner to quote exercise facilitation separately from the exercise write-up.
Case records tooling	Licensed vendor platform, or self-hosted open-source case management run by the organization or its partner	Recurring licence or hosting, plus one-time setup	Commercial licence seat counts versus self-hosted infrastructure and admin time. Ask for the full cost of hosting, backup and upgrades, not only the licence line.
Auditor sampling time	Independent auditor, within the wider ISMS audit	Recurring, per audit cycle	Depth of evidence requested, such as contact lists, dated correspondence and exercise records. Keep these ready so sampling does not extend audit days.

Who owns the authority relationships and who helps

Your organization owns the relationships with regulators, supervisory bodies and law enforcement. Named people hold the contacts, decide whether a matter must be reported, and sign and submit every report, because the legal duty and the accountability sit with the organization itself. Ownership should be written down, not assumed, and it should survive staff changes.

Register ownership: A named role owns the register of authorities, keeps entries current and records when each contact was last verified.
Named contacts: Designated people are the only ones who speak to an authority, with deputies for absence and out-of-hours cover.
Reporting decisions: Your legal, compliance or security leadership decides whether an event triggers a notification duty and records the reasoning.
Submitted reports: Your staff prepare, approve and file the actual reports and keep copies with the incident record.
Periodic testing: Your team runs or observes routing exercises and acts on what they reveal.

Check that each contact role has a named person, a deputy and a documented decision owner, and that someone outside the security function can confirm the legal obligations that apply to you.

Where organizations fall short on authority contacts

Most gaps under A.5.5 Contact with authorities are not missing contacts but contacts nobody owns, cannot reach, or cannot connect to a decision. The cards below pair each gap with the action that closes it, so an assessor sees a maintained, tested and linked process rather than a list that was written once.

Contacts recorded by a departed employee

The authority contact list often lives in the head or inbox of whoever set it up. When that person leaves, the organization may hold numbers and addresses that nobody remembers to update. Check that every entry has a named role rather than a personal name, and that a handover step covers the list whenever the holder of a role changes. Ask whether the register shows when each entry was last verified.

No owner for the list

A.5.5 asks the organization to establish and maintain contact with relevant authorities, and maintenance needs someone accountable. Without a named owner, reviews slip and entries drift out of date. Assign the register to a specific role, record that role in the information security roles documentation, and confirm the owner reviews the list on a fixed schedule set by management.

Reporting duties missing from the register

Regulators and supervisors may require notification through contracts, sector rules or national law, and those duties are often recorded in legal or procurement files instead of the authority register. Map each reporting obligation to the authority that receives it, the trigger, and the deadline. Check the register against the legal, statutory, regulatory and contractual requirements inventory so that no duty sits outside it.

No test of reachability

A contact that has never been tried may fail when it matters most: a mailbox unmonitored, a portal login expired, or a phone line that no longer routes. Schedule periodic reachability checks that use the same channels a real report would use, and record the result, date and tester. Auditors look for evidence that the route works, not only that it appears on a list.

Contacts held only on personal phones

Numbers saved on individual devices disappear with the device and are unavailable during an incident if that person is traveling, ill or unreachable. Keep the authoritative register in a controlled, access-restricted location that several people can reach, and make sure the incident response plan under A.5.24 points to that location. Personal copies can exist as convenience, but they should never be the only source.

Incident records not linked to notification decisions

An incident can be closed without anyone recording whether an authority needed to hear about it, which leaves the notification decision undocumented. Add a field in each incident record that states whether a report was required, to whom, by when, and who decided. Tie this to the event assessment and response steps under A.5.25 and A.5.26 so the decision is visible in the case file.

Questions buyers ask about A.5.5 cost, effort and outside help

How long does it take to build the authority contacts register, and what drives the time?

The time depends on how many authorities the organization must reach, how many of its own people already know the relevant contacts, and whether the register already exists in some form. Building it is mostly desk work: identifying each regulator, supervisory body, national computer emergency response team and law enforcement unit that applies to the business, confirming the reporting channel and the named role for each, and recording the conditions under which contact is required. Organizations with several jurisdictions, sector regulators and contractual notification duties need more time because each source must be checked against current legal and contractual obligations. Ask any partner to state the number of authorities, jurisdictions and sector rules in writing before quoting effort.

Can a small team run authority contacts on its own?

Yes, a small team can usually maintain the register itself, provided one named person owns it and a second person can act in their absence. The work is light once the register is built: confirm contact details, check that reporting routes still work, and update the register when laws, regulators or internal roles change. The harder part is knowing which obligations apply, which is a legal question. A small team should not rely on memory or on a generic list. It should ask counsel to confirm the applicable duties in writing and then keep the register aligned with that advice.

What does an implementation partner do for A.5.5, and what should counsel handle?

An implementation partner prepares the working parts of the control: the register structure, the link between each authority and the incident management process, the reporting templates, the drills that test whether the routes work, and the records that show the register was reviewed. Counsel decides which reporting duties apply, what triggers them, and what must be said in a notification. The organization owns both the decisions and the register. Partners do not give legal advice, and a partner should be asked to confirm, in the written scope, which items it prepares and which items the organization or its counsel must approve.

Will an auditor check the authority contacts directly?

An auditor will usually test A.5.5 by asking to see the register, how it is kept current, and evidence that the contacts have been used or tested when required. The auditor normally samples the register against the organization's stated obligations and may ask for records of past reporting, communications with a regulator, or a walkthrough of how a contact would be made during an incident. Auditors do not contact authorities on the organization's behalf. Confirm the expected evidence with the certification body before the audit, since its sampling approach determines what is requested.

What work must the organization own, even when it hires outside help?

The organization owns its regulatory relationships, the decision to contact an authority, the content of any report, and the accountability for meeting its duties. Outside help can draft procedures, configure tooling and prepare evidence, but the people named in the register must be the organization's own staff, and they must be reachable during an incident. Ownership also covers keeping the register current after reorganizations, changes in regulators and new products or markets. Any written scope should state these responsibilities clearly so that no one assumes a partner or auditor holds them.

How often should the authority contacts register be reviewed?

Review the register on a fixed schedule set by the organization, and also after any trigger that changes who must be contacted or how. Common triggers include a change in regulated status, a new market or product, a change in the named contact roles, a new incident reporting rule, and a failed or slow contact during a test or real event. Record each review with the date, the reviewer and the changes made, because that record is the evidence most auditors ask for. The schedule itself is an internal decision, and the organization should document it in its own procedure rather than adopt a figure from a template.

How DeployOpen prepares A.5.5 evidence

DeployOpen works on A.5.5 Contact with authorities as part of the wider organizational controls the organization owns. We prepare the systems, records and documented routes that show authority contacts are established, kept current and linked to incident reporting, while the organization keeps the contacts and decisions. Independent auditors and certification bodies assess the result and issue any report or certificate.

How we scope

Confirm which regulators, supervisory bodies and law enforcement contacts apply to your sector, jurisdiction and contracts
Agree in writing which incident reporting duties feed into A.5.5 and which systems hold the contact records
Define who owns each contact, who may make reports and who must be told, before work starts
Fix deliverables, exclusions and timelines in the written scope, since most engagements are fixed-scope

How we build

Set up a maintained contact register with named owners, roles, backup contacts and review dates
Connect the register to incident management procedures so reporting routes match the contacts listed
Configure case tracking and evidence logging so that reports to authorities can be traced to incident records
Test the reporting route with a documented tabletop exercise, recording who was contacted and when

How we hand over

Deliver the contact register, reporting procedure and review records in a form your auditor can sample
Document the decision points for when the organization reaches out, and who approves each report
Provide a handover walkthrough so your staff can maintain the register and run the route without us
Confirm with your certification body or auditor which evidence formats they expect before final handover

How we support

Offer ongoing support as a retainer for register reviews, contact changes and reporting route tests
Update the register and procedures when regulators, supervisory bodies or legal requirements change
Support internal or external audit preparation by walking reviewers through the evidence trail
Keep the organization in control of its contacts, reports and any decisions made with authorities