ISO 27001 Legal and Regulatory Register: A Country-by-Country Method

A country list of information-security laws becomes stale quickly and can mislead an organisation whose obligations depend on sector, legal entity, data subjects, customers and processing activity. A stronger ISO 27001 approach is to maintain a traceable obligations register that explains why each requirement applies and how compliance is demonstrated.

ISO/IEC 27001 expects organisations to identify relevant legal, statutory, regulatory and contractual requirements and reflect them in the ISMS. It does not require one universal register format, and certification does not itself prove compliance with every law. Legal interpretation should be confirmed by qualified counsel where consequences or applicability are uncertain.

The method below turns jurisdiction research into an auditable management process rather than a static collection of links.

Start with the organisation, not the law

The same law can apply differently to two organisations in the same country. Before researching obligations, build an applicability profile.

Record:

• legal entities and branches;
• countries where each entity is established;
• countries where staff, contractors and infrastructure operate;
• locations of customers and other affected individuals;
• products and services offered;
• regulated sectors and licences;
• categories of information processed;
• cross-border transfers and remote access;
• key suppliers and subprocessors; and
• important contracts and public-sector commitments.

The ISMS scope is an essential input, but do not assume obligations stop at the certification boundary. A law may apply to a legal entity or processing activity that is wider than the certified scope. Conversely, not every corporate obligation belongs in the ISMS register. Record the relationship explicitly.

The guide to interested parties and their requirements provides a useful starting point for linking regulators, customers, employees and other parties to the ISMS.

Build a jurisdiction matrix

Create one row for each meaningful connection between an activity and a jurisdiction. Avoid a single “country” field that hides why the country matters.

Dimension	Example question
Establishment	Is the organisation or a branch legally established there?
Service market	Are goods or services offered to people or organisations there?
Individuals	Does the organisation process information about people located there?
Infrastructure	Are systems, facilities, archives or recovery services located there?
Workforce	Do employees or contractors work there?
Transfer	Does information enter, leave or become remotely accessible from there?
Sector	Is a local licence or sector regulator involved?
Contract	Has a customer imposed local legal or regulatory obligations?

This matrix is a research map, not a legal conclusion. It tells legal and compliance specialists where to investigate.

Use authoritative sources and preserve provenance

For each jurisdiction, prefer the official legislation portal, regulator, supervisory authority or government gazette. Secondary summaries can help discover an issue, but the register should point to the authoritative source used for the decision.

For example, the official EUR-Lex text of the General Data Protection Regulation is a primary source for the EU regulation. It does not answer every applicability question on its own, and local laws or regulator guidance may also matter.

Record source metadata:

• official title and citation;
• issuing authority;
• authoritative URL;
• version, effective date and date checked;
• relevant provisions or regulator guidance;
• person who assessed applicability; and
• counsel opinion or decision record where used.

Do not copy whole laws into the register. State the operational obligation in your own controlled language and retain a precise reference to its source.

Separate requirement discovery from applicability

A sound register distinguishes three questions:

1. What does the source require?
2. Why does it apply to this organisation and activity?
3. How is the obligation fulfilled and evidenced?

An entry might be discovered during research but assessed as not applicable. Retaining the reason can prevent the same debate from recurring. Use statuses such as applicable, not applicable, under review and superseded. “Not applicable” needs an owner, rationale and review trigger.

Applicability factors can include legal establishment, offering of services, monitoring, information type, scale, sector, licence, critical-service status and contract terms. Avoid assuming that server location alone decides jurisdiction.

Structure each obligation as a controlable record

A useful register entry includes:

Field	Purpose
Requirement ID	Stable reference for traceability
Jurisdiction and authority	Source of the obligation
Citation	Exact law, regulation, licence or contract reference
Applicability rationale	Why the organisation is in or out of scope
Operational requirement	Plain-language action or constraint
Information and process scope	Data, systems, entities and activities affected
Accountable owner	Person responsible for compliance
Supporting controls	Policies, procedures, technical or physical measures
Evidence	Records that demonstrate operation
Frequency or deadline	Ongoing cadence or event-based timing
Change trigger	Events requiring reassessment
Last and next review	Governance dates
Status and residual issue	Current position and open risk

Keep one obligation per decision where possible. A single row that says “comply with privacy law” cannot be mapped to controls or tested.

Connect obligations to ISO 27001 risk and controls

Legal compliance is not a separate spreadsheet exercise. Feed obligations into the ISMS:

• add affected information and processes to risk assessment;
• select or adjust controls through risk treatment;
• reflect applicable controls and rationale in the Statement of Applicability;
• update policies, procedures and supplier terms;
• define competence and awareness needs;
• establish monitoring and records;
• include relevant requirements in internal audits; and
• escalate significant noncompliance through corrective action and management review.

The ISO 27001 and GDPR gaps article illustrates why a management system can support legal compliance without replacing legal analysis.

Include contracts and regulator commitments

Customer security schedules, data-processing terms, licence conditions and regulator undertakings may create obligations as important as legislation. Capture them with the same discipline.

For contracts, record:

• agreement and clause reference;
• covered service or customer;
• notification and cooperation duties;
• security measures or certification commitments;
• audit and evidence rights;
• retention or deletion terms;
• renewal and termination dates; and
• owner for changes.

Watch for conflicts. A contract may promise a response time the incident process cannot meet, or require data residency inconsistent with current architecture. The register should expose the gap before an incident or customer audit does.

Define evidence that proves operation

Policy text is implementation evidence, not complete compliance evidence. Match evidence to the obligation.

Examples include:

• regulator registrations or filings;
• completed privacy or security assessments;
• approved transfer decisions;
• access and deletion records;
• incident assessments and notifications;
• training and competence results;
• supplier due-diligence records;
• configuration and monitoring reports;
• retained approvals; and
• legal review or applicability decisions.

Evidence should identify the period, population, owner and result. Where legal privilege may apply, agree with counsel how the register and supporting material will be stored and disclosed.

Operate a change-detection process

A legal register decays unless change has an owner. Use several signals:

• subscriptions from relevant regulators and official gazettes;
• legal counsel updates;
• trade or sector body alerts;
• product and market expansion reviews;
• procurement and contract review;
• architecture and data-flow changes;
• mergers, acquisitions and new legal entities; and
• incidents or enforcement developments.

Assign an owner to triage alerts. The owner should determine whether a change affects applicability, controls, training, contracts, evidence or risk acceptance. Record the assessment even when no action is required.

Review frequency should reflect exposure. A highly regulated, multi-country service may need continuous monitoring and formal quarterly review. A stable, single-jurisdiction organisation may use a different cadence. The decision should be risk-based and documented.

Audit the register through samples

Do not audit only whether the register exists. Select obligations based on risk and variety—for example, one privacy obligation, one sector rule, one customer commitment and one cross-border issue.

For each sample, test:

1. Is the authoritative source current?
2. Is the applicability rationale supported?
3. Has the requirement been translated into a clear operational duty?
4. Is an accountable owner assigned?
5. Do mapped controls address the duty?
6. Does operating evidence cover the period and population?
7. Were changes assessed and actions closed?
8. Are known gaps risk-managed and escalated?

Pass, partial and fail examples

Pass: A current regulator requirement is mapped to the affected service, control owner, operating procedure and period-specific evidence. A recent regulatory update was assessed and the resulting change was completed.

Partial: The law is correctly identified and controls appear suitable, but the applicability rationale is undocumented and the latest review cannot be demonstrated.

Fail: The register is an undated list of web links, important jurisdictions are missing, and owners cannot show how requirements are implemented or monitored.

Avoid common failure modes

• Treating certification as proof of legal compliance.
• Copying an internet country list without applicability analysis.
• Omitting contractual and licence obligations.
• Recording whole laws instead of testable duties.
• Assigning every item to the security manager.
• Failing to connect obligations to risk treatment and controls.
• Keeping no evidence of legal change review.
• Deleting not-applicable decisions and repeating the research later.
• Assuming cloud-provider compliance transfers accountability to the customer.

The cloud shared-responsibility guide can help clarify obligations distributed across a service provider and customer.

Ownership that works

Legal counsel interprets difficult legal questions. Compliance coordinates the register. Process and control owners implement requirements. Procurement manages contractual entry points. Privacy, HR, technology and business teams supply domain knowledge and evidence. The ISMS manager maintains traceability. Internal audit independently tests the process.

In a small organisation, one person may perform several roles, but the decisions should still be reviewable and approved at the right level.

Keep the register useful

A strong register lets management answer: which obligations apply, why, who owns them, which controls fulfil them, what evidence exists, what changed and where exposure remains.

Use the ISO 27001 clause explainer to relate the register to the management system, and the readiness checker to test whether obligations are reflected in evidence and internal audit.