ISO 27001 Annex A 5.31: legal, statutory and contractual requirements

The enterprise security questionnaire asks how you track your legal and contractual obligations. Your honest answer is a sentence, not a document, and the deal is waiting. This guide covers ISO 27001 Annex A 5.31 for compliance managers, CISOs and operations heads at UK regulated firms and B2B vendors selling into them.

You will leave with the register schema, a three-pass method to populate it, the audit questions to expect and an automated way to keep it current.

What does ISO 27001:2022 Annex A 5.31 legal, statutory, regulatory and contractual requirements require?

ISO 27001:2022 Annex A 5.31 requires you to identify, document and keep current every legal, statutory, regulatory and contractual obligation that touches information security, together with how you meet each one. Those obligations then feed policy, control design, risk assessment, classification and supplier requirements. The register is the means, not the point.

The control draws on three kinds of source, and a register that covers only one is incomplete:

• Legislation, such as UK GDPR, plus DORA or NIS2 where they apply.
• Regulator expectations, such as the FCA rules for authorised firms.
• Contract promises buried in client, supplier and insurance agreements.

Each downstream use is concrete. Policy wording cites the obligation, risk assessment weighs the penalty, classification labels the regulated data, and supplier contracts pass the duty on.

For an FCA-regulated firm, being unable to show how obligations are tracked is a governance finding waiting to happen. For a B2B vendor serving regulated clients, the exposure is signed breach-notification windows, audit rights and security SLAs scattered across contracts. Penalties run from UK GDPR fines to breach-of-contract claims, and enterprise procurement asks "how do you track your regulatory obligations?" early in diligence.

"We keep on top of the law" is not a control. It is the absence of one.

The 2022 revision also changed the structure. Under ISO 27001 2022 control 5.31, the 2013 requirements 18.1.1 (applicable legislation) and 18.1.5 (regulation of cryptographic controls) merged into one control, which is why cryptography law now sits here and not in the cryptography section.

How does ISO 27001 Annex A 5.31 differ from clause 4.2, A.5.32 and A.5.34?

Clause 4.2 identifies your interested parties and what they broadly expect at ISMS level. Annex A 5.31 captures the specific, citable obligations those parties impose and how you meet each one. Controls 5.32 (intellectual property) and 5.34 (privacy) handle their slices in depth; 5.20 carries the supplier-contract end. Auditors read them together.

Treat clause 4.2 as the map of who can impose obligations and 5.31 as the ledger of what they have actually imposed. For the three dedicated controls, the register row stays at pointer level. IP licensing and privacy impact assessments belong in their own controls.

Auditors testing ISO 27001 A.5.31 read clause 4.2 and the register side by side. If your interested-parties analysis says enterprise clients expect prompt breach notification and no contract row reflects it, the contradiction is visible in minutes. Consistent documents are how you evidence compliance with legal and contractual requirements without extra effort.

What should a legal and regulatory register contain?

A workable register for a 50-person firm holds five fields per obligation: the source, what it obliges you to do, a named owner, the control or policy that meets it, and the date it was last reviewed. A structured spreadsheet or Notion database is enough at this scale; the shape matters more than the tool.

Each row answers five questions:

• Source: the statute, regulator rule or contract clause, cited precisely enough to find again.
• Requirement: what it obliges you to do, in one plain sentence.
• Owner: one named person, not a team.
• Mapped control or policy: the control, policy or procedure that delivers it.
• Last review date: when someone last confirmed the row is still true.

A worked row shows the standard. Source: the UK GDPR breach-reporting rule. Requirement: notify the ICO of a notifiable breach within 72 hours. Owner: the head of compliance. Mapped to: the incident response procedure. Last reviewed: a dated entry, not a blank.

For Annex A 5.31 ISO 27001:2022, the review date is the field that proves the register is alive. It is usually the first thing an auditor asks about, and a blank one says the row was copied in once and never confirmed.

A row with no owner and no mapped control gives the auditor nothing to follow when they ask "so how do you meet this?" The answer then depends on whoever happens to be in the room.

A register that maps to no control is a reading list, not evidence.

How do you build the register in three passes?

Work in three passes. First, the laws and regulators that apply to your business and jurisdictions, starting with UK GDPR and the ICO. Second, your client, supplier and insurance contracts. Third, anything cross-border: where you sell, host or move data. Each pass finds obligations the previous one cannot see, and a focused week produces a credible first register.

Each pass has a different source and a different yield:

1. Statutes and regulators. UK GDPR and the ICO apply to almost every firm. Add sector regimes such as FCA rules, DORA and NIS2 where they apply. The ICO 72-hour personal data breach reporting guidance is a good first row: a notifiable breach must reach the ICO without undue delay and within 72 hours of becoming aware of it.
2. Contracts. Go through client, supplier and insurance agreements for security commitments. The next section covers this pass in detail.
3. Cross-border. List where you sell, host and move data, then check the rules on each side of each border.

Build the first register early. Risk assessment, information classification and supplier work all draw on it, so a late register means rework in three places. The contract pass takes the most effort, which is why the table below shows what each pass leaves behind for the auditor.

How do you manage ISO 27001 contractual requirements hidden in client and supplier contracts?

Treat every client, supplier and insurance contract as a source of security obligations: breach-notification windows, audit rights, security SLAs and data-handling terms. Pull each commitment into the register with an owner and a mapped control. Regulated firms cannot delegate accountability to providers, so supplier terms must be tracked too.

The commitments rarely sit in your policy folder. They live in master services agreements, security schedules, data processing addenda and insurance policy wordings, signed by people who were closing a deal.

The obligations most likely to fire are the ones your sales team signed.

Work through the agreements in order:

1. Collect every active client, supplier and insurance agreement into one place.
2. Extract each security commitment as its own row, quoting the clause reference.
3. Assign an owner and map the row to the control that delivers it.
4. Compare the clocks. Where a client asks for notice faster than the 72-hour statutory window, build the incident procedure to the shorter one.

Supplier contracts matter in both directions. The FCA expectations on outsourcing and operational resilience state that a firm is responsible and accountable for its regulatory duties and cannot delegate any part of that to a third party. A supplier's security terms therefore sit in your register as your obligations, with the supplier as the delivery route.

Where a clause cannot be met, such as a 24-hour window your on-call cover cannot support, the register shows it early enough to renegotiate at renewal. The contract pass finds these surprises in a calm week, with time to build to them, rather than in the middle of a dispute.

Do cryptography laws and export controls apply to your firm?

Usually only when you expand. Export restrictions, national limits on encryption use, lawful-access regimes and e-signature validity vary by country, and exporting controlled dual-use items, including cryptography, without a licence is a criminal offence in the UK. Give cryptography law a register line item and trigger legal advice on new markets or cross-border product shipments.

The UK strategic export controls statutory framework is the starting point for checking whether a product, library or technical document is controlled. A UK-domestic services firm will usually record "no current exposure", with the review date and the trigger that reopens the question.

Those triggers are specific:

• A new market, especially one with its own encryption or lawful-access rules.
• A product release that ships cryptographic features to customers abroad.
• Hosting or support infrastructure moving to another jurisdiction.
• Reliance on electronic signatures in a country whose validity rules differ.

A dated "no exposure" row takes minutes to write. Cryptography law left unrecorded tends to surface in the middle of a cross-border deal, when the answer is needed in days and legal advice takes longer. Once you have taken that advice, file it in the register as evidence of the analysis.

Who owns each obligation, and how do assets show which rules apply?

Give each domain of obligation (data protection, sector regulation, client contracts) a named owner, and tag the asset inventory with compliance metadata so systems holding personal or financial data are easy to find. Ownership answers who acts; tagging answers where the obligation lands. Together they connect the register to controls.

A workable split for a 50-person firm:

• Data protection: the person who runs UK GDPR duties and ICO contact.
• Sector regulation: the compliance lead covering FCA, DORA or NIS2 duties.
• Client contracts: the commercial or operations lead who signs and renews agreements.

Tagging does the connecting work. Add fields such as "personal data", "financial data" or "client-regulated" to the asset inventory, and a regulated system becomes visible at a glance. Those tags decide where stronger measures such as tighter access reviews and encryption land, and they feed the risk assessment.

Without owners, the register is collectively assumed and individually ignored, and everyone expects someone else to watch the regulatory horizon. Without tags, nobody can say which systems the obligations actually touch, so effort spreads thin or misses the system that matters. An auditor asking "how do you know which systems hold regulated data?" needs a query result, not a recollection.

What will an auditor ask about your legal register?

Auditors ask to see the register, when it was last reviewed and what changed, then trace one obligation forward to its control and one contract backward to the register. They cross-check clause 4.2. A missing or untouched register grades major; stale dates, missed contractual obligations or unassigned owners grade minor, aggregating to major as a pattern.

Expect questions close to these:

• "Show me your legal register. When was it last reviewed, and what changed?"
• "Pick this client contract. Where are its security commitments tracked, and who owns them?"
• "How would a new regulation reach this register? Walk me through the last one that did."
• "Who owns data protection obligations? Who owns FCA requirements? Show me the assignments."
• "How do you know which systems hold regulated data?"
• "You entered a new market last year. What did that trigger here?"

The sampling runs both ways. Forward, the auditor picks a register entry and follows it to the policy and control that satisfy it. Backward, they take a client contract and check that its notification window or audit clause appears in the register. For ISO 27001 5.31, a single broken thread in either direction is enough to open a finding.

The reason for the split is reach. Certification bodies grade a missing or abandoned register as major because much of the management system claims to rest on requirements nobody has listed. A stale date or an unassigned owner is a lapse in one row, which is why it stays minor until it forms a pattern.

The classic failure is the register built for Stage 1 and never opened again. It is discovered fossilised at the first surveillance audit, with every date unchanged since certification.

How can you automate the legal register with GRC engineering?

Hold obligations as structured records linked to owners, controls and evidence, so "which obligations lack a mapped control" becomes a query. Wire contract intake to the register at signature, let regulatory watchlist hits (ICO, FCA, EU) open review tasks, and feed regulated-data tags into risk assessment. The register then stays current by design, with owners reserved for judgement.

The unmapped-control query is the strongest single check. Run it before an audit and it returns the rows an auditor would find anyway: obligations with no control, no owner or an overdue review. Review-due dates drive owner reminders, so upkeep stops depending on memory.

Contract intake changes who finds the obligations. When the signature step extracts notification windows and audit rights, the deal closes and the register updates in the same motion. The ICO and FCA publish free alerts, and that is enough to start: each hit opens a review task for the named owner, who decides whether a control must change.

Tags can also do the matching. When a new system is tagged "personal data" in the asset inventory, the register's data-protection rows, and their owner, apply to it without anyone having to remember.

The next enterprise questionnaire asks how you track your obligations, and the answer becomes a screen share instead of a sentence.

Owning the register and watching the regulatory horizon is standing work for our Fractional CISO service. Keeping reviews running and evidence connected is what managed compliance carries, and building the engineered register described here is the work of our GRC engineering service.

Frequently asked questions