Control Definition
The organization must establish and keep current its lines of contact with the authorities relevant to its operations — data protection regulators, national CERTs, law enforcement, and sectoral supervisors — including who makes contact, about what, through which channel, and on what timeline.
Control Objective
To make sure security-relevant information flows correctly and on time between the organization and the legal, regulatory, and supervisory authorities it answers to — especially when an incident starts a statutory clock.
What This Really Means
This is one of the shortest controls in Annex A and one of the easiest to fail at the worst possible moment. The real test is not a document — it is 2 a.m. during a ransomware incident: does anyone in the room know which regulator must be told, within what window, through which portal, by whom? A.5.5 exists so those questions get answered while nothing is on fire.
The working artifact is an authorities contact register. For each relevant authority — the data protection authority for personal-data breaches, the national CERT for cyber incidents, the police cybercrime unit for criminal acts, the sectoral regulator for licensed activities — it records what matters fall under that authority, the events that make contact mandatory and the deadline attached, the channel (portal, designated email, hotline) with working account details, and a named owner plus a deputy. Which authorities are "relevant" is not a guess: it falls straight out of your legal and regulatory register (A.5.31), jurisdiction by jurisdiction.
The control covers two distinct modes. Mandatory contact is the obligation side: breach notifications, incident reports, responses to lawful requests — defined triggers, defined deadlines, no discretion. Relationship mode is the quieter half: tracking upcoming regulatory change, consuming advisories, knowing the supervisory contact before you need a favor or a clarification. Organizations that meet their regulator for the first time on their worst day consistently have a harder time of it than those with an established channel.
For auditors, the heart of A.5.5 is the word "maintain." A register written three years ago naming an employee who has since left fails the control even though it exists. Auditors look for a last-verified date on each contact, portal accounts that demonstrably work, notification triggers wired into the incident response plan, and — the strongest evidence — tabletop exercises where the authority-contact step was actually rehearsed and timed.
Why It Matters
Regulatory clocks are short and start on awareness, not on convenience. Several regimes measure notification windows in hours, and the time spent mid-incident working out who reports what to whom is burned directly out of that window. Missing the deadline converts a security incident into a second, separate compliance violation — and regulators are consistently harsher about concealment and lateness than about the breach itself. The notification failure frequently costs more than the intrusion.
The control also covers the quieter failure modes. Without a defined law-enforcement path, evidence gets handled in ways that foreclose prosecution and complicate insurance claims. Without a regulatory relationship, upcoming obligations arrive as surprises instead of plannable change. And when knowledge of "who to call" lives in one veteran's head, it resigns when they do.
Without established and maintained authority contacts, organizations face:
- •Missed statutory deadlines – hours-long reporting windows are consumed by figuring out the recipient, the portal, and the password instead of the report itself
- •Doubled jeopardy – the original incident plus a failure-to-notify violation stacked on top, with the second often carrying the larger penalty and reputational cost
- •Botched law-enforcement engagement – evidence mishandled or filed with the wrong agency, weakening criminal, civil, and insurance outcomes
- •Regulatory blindside – no channel for anticipating rule changes, so new obligations surface late and land as fire drills
- •Single point of failure – the one person who "knows the regulator" leaves, and the relationship, portal credentials, and institutional memory leave with them
Regional Compliance Context
India operates one of the tightest incident-reporting regimes anywhere: CERT-In directions require designated categories of cyber incidents to be reported within 6 hours of noticing — and they reach systems connected to India even where the operator is headquartered elsewhere. The companion 180-day log retention requirement exists partly so you can answer CERT-In's follow-up questions. For personal data, the DPDP Act 2023 makes the Data Protection Board of India the breach-notification destination, with the DPDP Rules notified in 2025 detailing duties to affected data principals and the Board, and full compliance obligations landing 13 May 2027. RBI-regulated entities and SEBI CSCRF-covered intermediaries carry parallel rapid-reporting duties to their sectoral supervisor.
The practical consequence: build the register so one incident maps to all applicable notifications at once — a breach at an Indian fintech can simultaneously trigger CERT-In, RBI, and Data Protection Board clocks, each with different content requirements. In the Gulf, the Saudi PDPL requires notifying the competent authority of qualifying personal-data breaches within 72 hours, and the UAE federal PDPL carries its own regulator-notification duties — multi-jurisdiction operators should track each regime as a separate row, not a footnote.
Implementation Guidance
Derive Your Authority List from Legal Obligations
Start from the legal and regulatory register (A.5.31): every applicable law or regulation implies an authority behind it. Typical rows: the data protection authority in each operating jurisdiction, the national CERT, the police cybercrime unit, sectoral regulators for licensed activities, and licensing or certification bodies. Have legal counsel confirm the list — missing an authority here silently breaks everything downstream.
Build the Authorities Contact Register
One row per authority: scope of matters, mandatory triggers with their deadlines, the channel (portal URL, designated email, hotline) and account details, the named owner and deputy, and a last-verified date. Store it where incident responders can reach it at 2 a.m. — inside the incident response plan or runbook, access-controlled but never buried.
Assign Named Owners and Deputies
Each relationship gets a person, not a team: typically the DPO for the data protection authority, the CISO or SOC lead for the national CERT, legal counsel for law enforcement, the compliance head for the sectoral regulator. Deputies cover absence and departure. The owner maintains the relationship in peacetime and makes or approves contact during incidents.
Wire Notification Triggers into Incident Procedures
Add a decision table to the incident response plan (A.5.24): incident category, the authorities it triggers, the deadline for each, who files, and what the first notification must contain. Pre-draft notification templates matching each authority's required fields, so responders fill in facts instead of composing prose against a statutory clock.
Register on Portals and Verify Channels in Advance
Many regulators accept notifications only through portals or designated addresses, and some require nominated contact persons on file. Create the accounts now, confirm credentials work, store them in the password vault with break-glass access, and re-verify the channel as part of every register review. Discovering a portal needs a registration step during an incident is a self-inflicted deadline failure.
Rehearse the Contact Path in Incident Exercises
Every tabletop exercise should include an authority-notification inject: which regulators does this scenario trigger, by when, and can the team produce the draft notification inside the window? Time it, capture the result in the exercise report, and fix what stalled. Rehearsal is what converts the register from paper into muscle memory — and it is the evidence auditors trust most.
Review the Register on a Schedule and on Triggers
Verify every row at least annually and on trigger events: entering a new market, a regulatory reorganization, an owner's departure, or a new law landing in the legal register. Record the verification date per row. Use the same review to harvest what the authorities are signaling about upcoming requirements, and feed that into the legal register and management review.
Audit Evidence
During your ISO 27001 certification audit, auditors will expect to see the following evidence to demonstrate compliance with A.5.5:
Documentation
- Authorities contact register with per-authority owners, deputies, channels, triggers, deadlines, and last-verified dates
- Incident response plan containing the notification decision table that maps incident categories to authorities and deadlines
- Pre-drafted notification templates aligned to each authority's required content
- Tabletop or incident exercise reports showing the authority-contact step rehearsed and timed
- Records of any actual notifications made — submissions, acknowledgments, and follow-up correspondence
Interviews
- Incident response lead on which authorities a given scenario triggers and within what window — answered from memory, not by searching
- DPO or legal counsel on data protection authority engagement and the defined path for involving law enforcement
- CISO on how the register is kept current and how regulatory horizon-scanning feeds back into the ISMS
Observations
- An on-shift responder locating the contact register and walking the ransomware notification path live
- Demonstration that regulator portal accounts exist and credentials work — a login, not a screenshot from last year
- The most recent exercise report inspected for whether the notification inject was executed inside the statutory window
Practitioner Insights
The audit probe for this control is one question: "When did you last verify this contact?" Registers almost always exist; current ones are rare. The deeper failure I keep finding is classification mismatch — the organization's incident severity scale is built around business impact, while the regulator's reportable list is built around incident type, so events that legally require notification never get flagged in triage. Map your event categories to each authority's reportable list explicitly, or the 6-hour clock expires quietly inside your own queue.
Startups routinely mark this control as barely applicable because "no regulator knows we exist" — and that is exactly backwards. Every India-connected system sits in CERT-In's scope, and anyone handling personal data answers to a data protection authority somewhere. A one-page register with four rows, portal accounts created in advance, and the path walked once a year is proportionate and complete. The painful pattern is teams discovering mid-incident that the reporting portal needed an account registered days earlier — verify the channel, not just the address.
Common Challenges & Solutions
Challenge
Nobody can confidently say which authorities are actually "relevant" to the organization.
Solution
Stop brainstorming and derive: walk the legal register jurisdiction by jurisdiction and list the authority behind each obligation, then have counsel review. When in doubt, include the authority and mark the relationship dormant — an unused row costs nothing, a missing one costs a deadline. Revisit on every market entry.
Challenge
The register exists but rots — named contacts leave, portals change, agencies reorganize.
Solution
Give the register itself an owner and a review cadence: annual verification of every row with a recorded date, plus event-driven checks when an owner departs or a regulator restructures. Make "log in to each portal" part of the verification, and keep credentials in the vault rather than in the owner's browser.
Challenge
Statutory reporting windows are shorter than the organization's internal approval chain.
Solution
Pre-authorize: the incident lead or DPO files within the window without waiting for a full legal sign-off cycle, using pre-approved templates that contain only facts already cleared for disclosure. Decide in advance what goes in the initial notification versus follow-ups — most regimes accept a preliminary report with updates, and a timely incomplete notification beats a perfect late one.
Challenge
One incident triggers multiple regulators across jurisdictions, each with different deadlines and content demands.
Solution
Build a notification matrix per incident category covering every applicable regime, and appoint a single notification coordinator role during major incidents to track each clock separately. Pre-drafted per-authority templates stop the team from rewriting the same facts five ways under pressure. Multi-jurisdiction reviews belong in the annual register check.
Challenge
Leadership resists voluntary engagement with regulators or law enforcement — the "don't poke the bear" instinct.
Solution
Separate duty from discretion in writing: mandatory notifications are non-negotiable and pre-authorized, while voluntary engagement follows a policy agreed with counsel rather than the mood of the day. Build the relationship in peacetime through industry briefings and CERT events — the threshold for a hard phone call drops sharply when it is not the first call.
