Control Definition
Every legal, statutory, regulatory, and contractual requirement relevant to information security — together with the organization's approach to satisfying each one — must be identified, documented, and kept up to date.
Control Objective
To keep the organization compliant with every external obligation that touches information security, whether it comes from legislation, a regulator, or a signed contract.
What This Really Means
Think of this control as the border crossing between your ISMS and the outside world. Almost everything else in Annex A is about rules you set for yourself; A.5.31 is about rules other people set for you — parliaments, regulators, and the customers whose contracts you signed. The standard artifact here is the legal register (sometimes called a compliance obligations register): one table that answers, for every external requirement, what it is, where it comes from, who owns it, and which of your controls satisfies it.
The requirements arrive from four directions. Statutory: laws passed by legislatures — data protection acts, cybercrime statutes, records retention laws. Regulatory: rules issued by the bodies that supervise your sector — central banks, securities regulators, telecom and health authorities. Contractual: the security schedules, data processing agreements, and certification commitments buried in customer and partner contracts — PCI DSS, for instance, reaches most organizations through card-scheme and acquirer contracts, not legislation. And all of it multiplies by jurisdiction: every country where you are incorporated, operate, store data, or serve customers can add entries.
In practice the control asks for three disciplines. First, identification: a deliberate exercise — legal counsel plus the CISO plus whoever owns customer contracts — to enumerate the obligations rather than assume someone knows them. Second, mapping: each obligation traced to the policies, controls, and evidence that meet it, so a gap is visible as a gap. Third, currency: a named owner and a review cadence, because the register is wrong the moment a new market opens, a new law passes, or sales signs a contract with a novel security clause. One classic blind spot deserves naming: cryptography. Several countries restrict the import, export, or use of cryptographic tools, and some can compel disclosure of keys or plaintext — organizations routinely ship strong encryption into new markets without ever checking.
Auditors treat the register itself as the heart of the control. Expect them to ask for it early in Stage 1, check its owner and last review date, and then pull one thread: pick a single obligation — say a customer's 24-hour breach notification clause — and trace it to the procedure and evidence that satisfies it. A register that exists but was last reviewed two years ago, or that lists statutes without saying how each one is met, fails that pull.
Why It Matters
Certification does not exempt you from law, and law does not wait for your ISMS to mature. Obligations you have not identified are still binding — regulators do not accept ignorance, courts do not accept it, and enterprise customers write security expectations into contracts precisely so they can enforce them. The most expensive way to discover a requirement is during an incident, when a notification clock you did not know existed is already running.
There is also a quieter benefit: the legal register keeps the rest of the ISMS honest. Retention periods in your records schedule, breach timelines in your incident plan, residency constraints in your cloud architecture, algorithm choices in your cryptography standard — all of these should trace back to register entries rather than folklore.
Organizations that neglect this control face:
- •Regulatory penalties – data protection and sector regulators levy substantial fines, and a missed statutory breach-notification deadline becomes a second violation stacked on top of the first
- •Contract breach at scale – one unidentified security clause in a master services agreement can hand a major customer termination rights, indemnity claims, or audit leverage
- •Cryptography blind spots – import, export, and key-disclosure laws differ sharply by country; deploying strong encryption into a restricted market without checking is a classic, expensive miss
- •Incident-time chaos – breach-reporting windows can be as short as a few hours in some jurisdictions, and discovering them mid-incident guarantees a missed deadline
- •A finding that spreads – A.5.31 feeds the Statement of Applicability, the risk assessment, and several neighboring controls, so a stale or missing register casts doubt far beyond one control
Regional Compliance Context
India. The register of an India-connected organization typically carries at least four families of entries: the DPDP Act 2023 (DPDP Rules notified in 2025, with full compliance obligations landing by 13 May 2027), the CERT-In directions (six-hour reporting of designated incidents and 180-day log retention for systems connected to India), RBI master directions for banks and regulated financial entities, and SEBI CSCRF for market intermediaries. Each carries its own clock — the DPDP phase-in in particular deserves a register entry with milestone dates rather than a single row.
Gulf. Organizations operating in or serving the GCC add Saudi Arabia's PDPL and the UAE federal PDPL, alongside sector regulators and free-zone regimes that maintain their own data protection rules. The pattern is the same everywhere: one register, a jurisdiction column, and an owner who is actually told when the business enters a new market.
Implementation Guidance
Map Your Legal Landscape by Jurisdiction
List every jurisdiction that can impose obligations on you: where you are incorporated, where you operate, where data is stored, and where your customers and data subjects sit. For each one, work with legal counsel to enumerate the security-relevant laws and the sector regulators that apply. Run this as a workshop with a defined output — a first-cut register — not as an open-ended research project.
Extract Security Obligations from Contracts
Review master services agreements, data processing agreements, security schedules, and any certification commitments sales has signed up to. Log each discrete obligation — breach-notification windows, audit rights, data residency limits, required certifications — as its own register entry. Then make contract review at signature a standing trigger so new obligations flow into the register automatically.
Build a Single Legal and Regulatory Register
One table: requirement, source and citation, jurisdiction, owner, the controls and documents that satisfy it, evidence location, and last review date. A spreadsheet or a GRC platform both work; what matters is that the register is singular, current, and owned — not scattered across legal memos and tribal knowledge.
Map Every Entry to Controls and Evidence
Trace each obligation to the Annex A controls, policies, and procedures that meet it. Where the trace ends in nothing, you have found a real gap — feed it into risk treatment instead of quietly rewording the register. This mapping also supplies the justification for several Statement of Applicability inclusions.
Sweep the Classic Blind Spots
Before anything ships into a new country, check cryptography import/export restrictions and key- or plaintext-disclosure powers. Also confirm statutory records retention minimums (feeding A.5.33), employee-monitoring limits, and cross-border data transfer rules. These are the entries organizations consistently discover late and at the worst time.
Assign Ownership and a Review Cadence
Name an owner — typically compliance or legal for identifying requirements, the CISO for mapping them to controls. Review the register at least annually and on defined triggers: new market entry, new legislation or rules, a new contract template, a merger or acquisition. Subscribe to regulator circulars or counsel briefings so the triggers actually reach the owner.
Wire the Register into the ISMS Lifecycle
Register changes should flow into the risk assessment, the SoA, internal audit scope, and management review inputs. When a new obligation arrives, the visible chain — register entry, risk entry, control change, evidence — is exactly the trail a certification auditor wants to follow. Record triggered reviews even when the conclusion is "no change".
Audit Evidence
During your ISO 27001 certification audit, auditors will expect to see the following evidence to demonstrate compliance with A.5.31:
Documentation
- Legal, regulatory, and contractual requirements register with sources, owners, and review dates
- Mapping from each register entry to the controls, policies, and evidence that satisfy it
- Contract review records showing security clauses extracted from customer and supplier agreements
- Register version history or meeting minutes evidencing periodic reviews and updates
- Procedure defining how new or changed requirements are identified and who acts on them
Interviews
- Compliance or legal owner on how new laws and regulations are detected and entered into the register
- CISO on how legal requirements feed the risk assessment, SoA justifications, and control design
- Sales operations or contract manager on how customer security obligations are captured at deal time
Observations
- Live walkthrough of the register, tracing one obligation end-to-end to its control and evidence
- Register change log or version history demonstrating that reviews happen on the stated cadence
- The update mechanism in action — regulator subscriptions, counsel briefings, or GRC feeds reaching the owner
Practitioner Insights
Auditors rarely challenge whether a legal register exists — they challenge whether it is alive. The two questions I rely on are "when did this last change?" and "show me the entry for the newest market you entered." A register that predates your expansion into a new country, or that still reflects a contract template sales retired a year ago, tells me identification was a one-time project rather than an operating process. Then I pick one obligation and trace it to evidence; that single trace decides the finding more often than the register itself does.
Smaller organizations consistently over-invest in statutes and under-invest in contracts. They will list every act of parliament they can find, yet nobody has actually read the security schedule in their three largest customer agreements — which are the obligations most likely to be enforced, because the counterparty is paying attention. Start the register from your top ten contracts, extract every security clause into discrete entries, and only then widen out to legislation. It is faster, and it is the half auditors usually find missing.
Common Challenges & Solutions
Challenge
Nobody owns the register, so it was built once for certification and has not been touched since.
Solution
Split ownership explicitly: legal or compliance owns identification of new requirements, the CISO owns mapping them to controls, and a quarterly 30-minute sync keeps the halves aligned. Put the review on the compliance calendar with the same weight as the internal audit. An unowned register is the single most common A.5.31 finding.
Challenge
The register lists law names but not what they require, proving awareness without proving compliance.
Solution
Break each law into discrete obligations — a breach-notification duty, a retention minimum, a security-measures clause — each as its own row with its own control mapping. "DPDP Act 2023" is not an entry; "notify the regulator of personal data breaches" is. Granular rows are what make gap analysis and audit tracing possible.
Challenge
Contractual security obligations are scattered across dozens of customer agreements nobody has systematically read.
Solution
Run a one-time extraction across active master agreements, prioritized by revenue, pulling every security, privacy, audit, and notification clause into the register. Then fix the pipeline: add a security-clause checklist to contract review so every new agreement is extracted at signature, and store the obligations in a field your contract management or CRM system can report on.
Challenge
Cryptography import/export and key-disclosure restrictions get missed entirely when expanding into new countries.
Solution
Add a legal-register check to your market-entry and deployment checklists: before infrastructure or products ship into a new country, confirm crypto import/export rules, lawful-access and key-disclosure powers, and data localization requirements. A one-page counsel memo per new jurisdiction is cheap insurance against rearchitecting your product later.
Challenge
The register goes stale between annual reviews because laws and rules arrive on their own schedule.
Solution
Pair the annual deep review with event-driven triggers: subscriptions to regulator circulars, periodic counsel briefings, and an internal rule that market entry, new products, and new contract templates each open a register review. Record every triggered review, even when the conclusion is "no change" — the trail itself is the evidence.
