1. Purpose
The Authority & Regulatory Contact Register records the external authorities, regulators, law-enforcement agencies, emergency services, and other relevant external organizations that the organization may need to contact in relation to information security, privacy, cybersecurity incidents, legal requirements, or regulatory matters.
The register helps ensure that the organization knows who to contact, when to contact them, how to contact them, and who is responsible for making the contact.
2. When Is an Authority Contact Required?
An authority or regulatory contact may be required when:
- A cybersecurity incident has legal or regulatory reporting requirements.
- Personal data or sensitive information is compromised.
- A regulatory notification is required.
- Law enforcement requests information.
- A security incident involves fraud or criminal activity.
- A major service or infrastructure incident requires external notification.
- A contractual requirement requires notification to a regulator or authority.
- A business operates in a regulated industry.
- A customer contract requires notification to a specific authority.
- Legal counsel determines that external notification is necessary.
The organization should determine applicable notification requirements based on its business activities, geography, customers, data processed, contracts, and applicable laws and regulations.
3. Authority & Regulatory Contact Register
| ID | Authority / Organization | Type | Jurisdiction | Relevant Area | When to Contact | Contact Method | Contact Details | Internal Owner | Backup Owner | Last Verified | Status |
|---|---|---|---|---|---|---|---|---|---|---|---|
| ARC-001 | [Authority Name] | Regulator | [Country/State] | Data Privacy | Personal data breach / regulatory requirement | Email / Portal / Phone | [Details] | Compliance Lead | Legal | [Date] | Active |
| ARC-002 | [Authority Name] | Cybersecurity Authority | [Jurisdiction] | Cybersecurity Incident | Reportable cyber incident | Portal / Email | [Details] | CISO / Security Lead | IT Manager | [Date] | Active |
| ARC-003 | [Authority Name] | Law Enforcement | [Jurisdiction] | Cybercrime / Fraud | Suspected criminal activity | Phone / Portal | [Details] | Legal | Security Lead | [Date] | Active |
| ARC-004 | [Authority Name] | Industry Regulator | [Jurisdiction] | Industry Regulation | Regulatory incident | Portal / Email | [Details] | Compliance | Legal | [Date] | Active |
| ARC-005 | [Authority Name] | Emergency Service | [Location] | Physical Security | Emergency / physical incident | Phone | [Details] | Administration | Security | [Date] | Active |
Important: Do not populate this register with generic authority names copied from another organization. Contacts should be selected based on the organization’s actual legal, regulatory, contractual, geographic, and business requirements.
4. Recommended Register Fields
Authority / Organization
Name of the regulator, government authority, law-enforcement agency, emergency service, or other relevant external organization.
Type
Examples:
- Data Protection Authority
- Cybersecurity Authority
- Industry Regulator
- Law Enforcement
- Emergency Services
- Government Authority
- Contractual / Customer Authority
- Certification / Accreditation Body
Jurisdiction
Record the applicable country, state, territory, or regulatory jurisdiction.
Relevant Area
Examples:
- Data protection
- Cybersecurity
- Financial services
- Payments
- Employment
- Telecommunications
- Healthcare
- Information security
- Cybercrime
When to Contact
Clearly define the circumstances that may require communication.
Example:
Notify the applicable authority when a personal data breach meets the organization’s legal reporting criteria.
Contact Method
Record available communication channels:
- Official regulatory portal
- Telephone
- Emergency number
- Secure reporting channel
- Online notification form
Contact Details
Record the official contact information.
Where possible, maintain the official website/portal and current reporting mechanism rather than relying only on an individual employee’s contact details.
Internal Owner
Identify the person or function responsible for coordinating communication.
Examples:
- Compliance Manager
- Legal
- CISO
- Security Manager
- Privacy Officer
Backup Owner
Identify an alternate person who can perform the activity if the primary owner is unavailable.
Last Verified
Record the date on which the contact information and reporting mechanism were last checked.
Status
Suggested values:
- Active
- Under Review
- Not Applicable
- Retired
5. Example – SaaS Startup
Consider a SaaS company operating from India and serving customers in the United States and Europe.
Its register may contain categories such as:
| Situation | Potential External Contact | Internal Owner |
|---|---|---|
| Personal data breach | Applicable data protection authority | Privacy/Compliance |
| Cybersecurity incident | Applicable national or sector cybersecurity authority | Security Lead |
| Suspected cybercrime | Law enforcement / cybercrime authority | Legal/Security |
| Customer contractual notification | Customer-designated contact | Account/Compliance |
| Payment security incident | Applicable payment/financial authority, where relevant | Compliance |
| Physical emergency | Local emergency services | Administration |
| Regulatory inquiry | Relevant regulator | Legal/Compliance |
The actual authorities should be determined based on the organization’s legal entity, locations, services, customers, data processing activities, and applicable regulations.
6. Authority Contact Procedure
The organization should establish a simple process:
Incident / Regulatory Event
↓
Identify Applicable Requirement
↓
Determine Whether Notification Is Required
↓
Escalate to Legal / Compliance / Security
↓
Identify Relevant Authority
↓
Prepare Required Information
↓
Obtain Required Internal Approval
↓
Submit Notification Through Official Channel
↓
Record Submission / Reference Number
↓
Track Follow-up
↓
Close and Retain Evidence
7. Information to Record for Regulatory Notifications
Where applicable, maintain records of:
- Date and time of incident
- Date and time discovered
- Nature of the incident
- Systems or information affected
- Categories of information involved
- Potential impact
- Number or type of affected individuals/customers
- Actions taken to contain the incident
- Corrective actions
- Notification date
- Authority contacted
- Person who made the notification
- Submission/reference number
- Authority response
- Follow-up actions
The exact information required depends on the applicable law or regulatory requirement.
8. Contact Verification
Contact information should not be added once and forgotten.
The organization should periodically verify:
- Authority name
- Official website
- Reporting portal
- Email address
- Telephone number
- Emergency contact details
- Notification procedure
- Applicable reporting requirements
- Internal owner
- Backup owner
A simple verification record can be maintained:
| Authority | Last Verified | Verified By | Changes Identified | Next Review |
|---|---|---|---|---|
| [Authority] | 30-Sep-2026 | Compliance Lead | No change | 30-Sep-2027 |
The review frequency should be defined by the organization and may also be triggered by changes in laws, regulations, business operations, or regulatory relationships.
9. Authority Contact During Security Incidents
The Authority & Regulatory Contact Register should be linked to the organization’s Incident Management Process.
For a significant incident:
Detect → Assess → Contain → Determine Notification Requirement → Notify Authority if Required → Recover → Record → Learn
The incident response team should not automatically contact every authority whenever an incident occurs.
Instead, the organization should determine:
- What happened?
- What information was affected?
- Which jurisdictions are involved?
- Which legal or contractual requirements apply?
- Is notification mandatory?
- What is the applicable deadline?
- Who is authorized to communicate externally?
10. Roles and Responsibilities
| Role | Responsibility |
|---|---|
| Top Management | Provide authority and resources for regulatory communication |
| Legal / Compliance | Determine applicable legal and regulatory obligations |
| Security Lead / CISO | Provide technical incident information |
| Privacy Lead | Assess privacy/data-protection notification requirements |
| IT / Engineering | Provide technical evidence and incident details |
| HR | Coordinate employee-related regulatory matters where applicable |
| Internal Audit | Verify that the register and process are maintained |
| Employees | Escalate incidents and regulatory communications to the designated owner |
11. Evidence for ISO 27001 Audit
An auditor may look for evidence that the organization has identified and maintained appropriate external contacts.
Possible evidence includes:
- Authority & Regulatory Contact Register
- Applicable Laws & Regulations Register
- Regulatory notification procedure
- Incident response procedure
- Regulatory reporting records
- Communication with authorities
- Notification/reference numbers
- Contact verification records
- Legal/compliance review records
- Incident records
- Management review records
Simply having a list of telephone numbers is not sufficient evidence that the organization understands its regulatory obligations.
The organization should be able to demonstrate that relevant external authorities have been identified and that there is a defined process for contacting them when required.
12. Authority Register vs Legal & Regulatory Register
These two registers serve different purposes.
| Register | Primary Purpose |
|---|---|
| Legal & Regulatory Requirements Register | Identifies laws, regulations, contractual obligations, and requirements applicable to the organization |
| Authority & Regulatory Contact Register | Identifies the external authorities and communication channels to use when contact or notification is required |
They can be maintained separately or combined where appropriate.
13. Startup-Friendly Approach
A small startup does not need a huge regulatory database.
Start with the authorities relevant to:
- Where the company operates
- Where customers are located
- Types of data processed
- Industry in which the company operates
- Services provided
- Contractual obligations
- Applicable cybersecurity/privacy requirements
For example, a 20-person SaaS startup might initially maintain 10–15 relevant external contacts rather than hundreds of unrelated authorities.
The objective is not to create a large register.
The objective is:
When a significant security or regulatory event occurs, the organization should know who needs to be contacted, why, how, and who is responsible.
14. Quick Startup Checklist
- Identify applicable regulators and authorities
- Identify relevant jurisdictions
- Identify cybersecurity reporting authorities
- Identify privacy/data-protection authorities
- Identify relevant industry regulators
- Identify law-enforcement contacts
- Record official reporting channels
- Assign internal owners
- Assign backup owners
- Define notification triggers
- Link the register to incident response
- Verify contact information periodically
- Maintain evidence of regulatory communications
- Review the register when business or regulatory requirements change
Final Principle
An effective Authority & Regulatory Contact Register is not simply a directory.
It connects:
Regulatory Requirement → Trigger/Event → Authority → Notification Process → Responsible Person → Evidence → Follow-up
For an ISO 27001 ISMS, the goal is to ensure that the organization can respond to regulatory and security events in a timely, controlled, and documented manner.