---
title: "ISO 27001 Annex A 5.31: legal, statutory and contractual requirements"
canonical: https://www.grcmana.io/vault/iso-27001/annex-a-5-31-legal-statutory-regulatory-and-contractual-requirements
published: 2023-03-29
updated: 2026-10-07
author: "Harry West"
framework: "ISO 27001"
control: "A.5.31 Legal, statutory, regulatory and contractual requirements"
journeyStage: implementation
---

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

## Key takeaways

Annex A 5.31 requires a maintained register of every legal, statutory, regulatory and contractual security obligation, each tied to a named owner and a control. Contracts hold the obligations most likely to fire, so they need their own pass. Structured records and intake triggers keep the register current without heavy overhead.

- **Core requirement** — Identify, document and keep current every legal, statutory, regulatory and contractual obligation touching information security, with how each is met, so policy, risk and supplier decisions draw on it.
- **Register schema** — Five fields per obligation: source, plain-language requirement, named owner, mapped control or policy, and last review date. A spreadsheet or Notion database is enough at SME scale.
- **Where it bites** — Contracts hold the obligations most likely to fire: breach-notification windows, audit rights, security SLAs and data-handling terms in client, supplier and insurance agreements that sales teams sign.
- **Audit grading** — A missing or untouched register grades major. Stale review dates, missed contract obligations or unassigned owners grade minor, and a pattern of minors can aggregate to a major.

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](https://ico.org.uk/for-organisations/advice-for-small-organisations/personal-data-breaches/72-hours-how-to-respond-to-a-personal-data-breach/) 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.

| Pass | Sources | What it surfaces | Evidence left |
| --- | --- | --- | --- |
| 1. Statutes and regulators | UK GDPR, ICO, FCA rules, DORA, NIS2 where applicable | Statutory duties such as breach-reporting deadlines | Register rows citing the legislation, with owners and mapped procedures |
| 2. Contracts | Client, supplier and insurance agreements | Notification windows, audit rights, SLAs, data-handling terms | Sampled contracts with clauses traced to register rows |
| 3. Cross-border | Markets you sell into, hosting locations, data flows | Foreign rules on data transfer, encryption and export | Dated analysis or legal advice per market |

## 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](https://www.fca.org.uk/firms/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](https://www.gov.uk/guidance/uk-strategic-export-controls) 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

### Does A.5.31 apply if we only operate in the UK?

Yes, but the scope is smaller than it sounds: UK GDPR, your sector regime if you are regulated, and your contracts. The legislative list for a UK-domestic services firm usually fits on a page. The contract pass is where the effort goes, and cross-border exposure can still arrive through a supplier that hosts your data abroad.

### How often should the A.5.31 legal register be reviewed, and what does upkeep cost?

Run an annual pass over the whole register, plus event-triggered reviews when you enter a market, launch a product or face a major new regulation. Contract renewals, including insurance renewals, are natural triggers for the rows they touch. Once the first version exists, upkeep for a firm of 50 people is a few hours per quarter.

### Besides the register itself, what evidence do auditors expect for A.5.31?

Expect to show the procedure for identifying new obligations and a sample of contracts with their security clauses marked, not every contract. Privacy artefacts such as impact assessments and notices show data protection law is operational, and the asset inventory should carry regulated-data tags. Internal audit coverage of legal compliance, with findings tracked to closure, and a dated review history or review minutes complete the set.

### Is a legal register mandatory under A.5.31?

The control does not name a register. It asks you to find your security obligations, write them down with how you meet each one, and keep that record current. A register is the simplest form that does all three, and the one an auditor can sample in both directions.