Annex A 5.31: Legal, Statutory, Regulatory and Contractual Requirements

Annex a 5.31: legal, statutory, regulatory and contractual requirements requirement means you must identify every legal, regulatory, and contract obligation that affects your ISMS, translate them into actionable controls, assign owners, and keep evidence that you monitor changes and stay compliant. Operationalize it by maintaining a requirements register, mapping obligations to policies and controls, and reviewing it on a defined cadence. ¹

Key takeaways:

• Build and maintain a single “requirements register” that covers laws, regulations, and contract clauses that touch information security.
• Map each obligation to specific controls, owners, and evidence so an auditor can trace requirements to operations.
• Prove the process runs: change monitoring, review cadence, and updates to policies, procedures, and contracts.

Annex A 5.31 is one of the controls auditors use to test whether your ISMS is grounded in real-world obligations rather than aspirational policies. If you cannot show how you identify applicable legal, statutory, regulatory, and contractual requirements, you will struggle to defend why your controls are designed the way they are, and you will have gaps when obligations change.

For a CCO, GRC lead, or compliance officer, the goal is simple: create a repeatable mechanism to (1) determine what applies, (2) translate obligations into internal requirements, (3) assign accountability, and (4) retain evidence that the mechanism operates. Annex A 5.31 does not require you to reproduce legal text in your ISMS; it requires you to manage it as an input to your security program and to keep it current. ¹

A practical way to think about this control: it is a “compliance-to-control traceability” requirement. Auditors will look for a requirements inventory, mapping to controls, and proof of monitoring and updates. If you can produce those on request, you are most of the way to passing 5.31.

Regulatory text

Control focus (public summary): ISO/IEC 27001:2022 Annex A control 5.31 implementation expectation (Legal, Statutory, Regulatory and Contractual Requirements). ¹

Operator interpretation of the text: You must:

1. identify information security obligations that apply to your organization (laws, regulations, and contracts),
2. document them in a managed form,
3. ensure the ISMS and its controls reflect those obligations, and
4. keep the set of obligations current as requirements change. ¹

What an auditor is really testing: They will try to trace from an external obligation (for example, a customer contract clause or a regulatory expectation) to an internal requirement, to an implemented control, to evidence that the control operates.

Plain-English interpretation (what “good” looks like)

Annex A 5.31 expects a living system, not a one-time spreadsheet. “Good” looks like:

• A single source of truth for obligations that impact information security and privacy, including customer and supplier contracts.
• Each obligation translated into an internal requirement statement your teams can execute.
• Clear ownership: Legal/Compliance confirms applicability; Security/GRC maps to controls; Procurement manages contract flow-down; system owners run the controls.
• A predictable method to detect change (new laws, updated contracts, changed service scope) and update the ISMS accordingly. ¹

Who it applies to (entity and operational context)

This applies to any organization operating an ISMS under ISO/IEC 27001, including service organizations that handle customer data, run SaaS platforms, provide managed services, or process data on behalf of others. ²

Operationally, it applies across:

• Legal & Compliance: determining applicable obligations and interpreting them.
• Information Security / GRC: converting obligations into controls and tracking evidence.
• Procurement / Vendor Management: ensuring contractual requirements are captured, negotiated, and flowed down to third parties where required.
• Sales / Deal Desk: ensuring customer security terms are reviewed and implemented.
• Engineering / IT / Operations: implementing controls (logging, access, retention, encryption, incident response).
• HR: workforce obligations that are contractual or statutory (confidentiality terms, acceptable use). ²

What you actually need to do (step-by-step)

1) Define the scope boundary and obligation sources

Create a short list of sources you will monitor for obligations that affect the ISMS:

• Jurisdictions where you operate and where data subjects/customers reside
• Contract repositories (customer MSAs, DPAs, SLAs, security addenda)
• Regulatory commitments you claim in marketing or security questionnaires (be careful: voluntary commitments become contractual fast)
• Third-party flow-down clauses (your suppliers may impose obligations on you that must be met operationally) ²

Deliverable: Obligation source inventory (one page) tied to your ISMS scope statement.

2) Build a requirements register (the core artifact)

Create a register that can be filtered and sorted. Minimum fields:

• Obligation type (legal / regulatory / contractual)
• Obligation name (plain language)
• Applicability rationale (why it applies)
• In-scope systems/processes
• Control mapping (Annex A, internal controls, SOC 2, NIST CSF, etc.)
• Owner (role, not a person)
• Evidence expected (what proves compliance)
• Review trigger (contract signed, law updated, new region, new product line)
• Status (implemented / in progress / not applicable with justification) ¹

Practical tip: Keep the register “audit-first.” If a line item cannot be evidenced, it is not complete.

3) Translate each obligation into internal requirements

For each register entry, write a requirement statement that an operator can implement, for example:

• “Access to production systems requires approved authorization and is reviewed.”
• “Security incidents are recorded, triaged, and escalated per procedure.”
• “Data retention and deletion follow documented schedules and customer contracts.”

Avoid copying legal text verbatim. Your internal requirement should be testable.

4) Map obligations to policies, procedures, and technical controls

Create traceability:

• Obligation → internal requirement → policy/procedure → technical/operational control → evidence

If you already maintain a Statement of Applicability (SoA), cross-reference the requirements register to relevant controls so an auditor can navigate both directions. ²

5) Operationalize change management for obligations

Define how you detect and process change:

• Contract change intake: Deal desk/procurement routes security and privacy addenda for review before signature; executed terms are logged into the register.
• Regulatory change intake: Legal/Compliance tracks changes and opens internal change items with impact analysis.
• Business change intake: New products, regions, data types, and subprocessors trigger a register review.

Make the workflow explicit: who is notified, who assesses impact, and how updates land in controls and evidence capture. ²

6) Prove it runs: recurring review + evidence capture

Auditors commonly fail teams here. You need two things:

• Evidence that the register is reviewed on a defined cadence and upon triggers.
• Evidence that changes result in updates (policy revisions, control changes, contract template updates, training updates).

Daydream (or any GRC system) becomes useful when it turns this into a managed workflow: requirement intake, mapping, tasks, and recurring evidence collection tied to each obligation and control. Keep the tooling story simple: show traceability and timestamps.

Required evidence and artifacts to retain

Keep artifacts that show both design (what you planned) and operation (what you did):

Core documents

• Requirements register (versioned; change history)
• ISMS scope statement cross-referenced to obligation sources
• Mapping table: obligations ↔ internal requirements ↔ controls (Annex A and internal)
• Statement of Applicability cross-references (if maintained) ²

Operational evidence

• Examples of reviewed contracts with security/privacy clauses and the resulting register entries
• Legal/regulatory change log entries and resulting impact assessments
• Meeting notes or approvals showing periodic review and decisions
• Tickets/changes showing policy updates, control implementation work, and completion evidence
• Training updates when obligations require new behavior

Third-party evidence (where obligations flow down)

• Contract templates or addenda clauses for subprocessors
• Third-party due diligence checks mapped to contractual obligations
• Records showing third-party obligations are communicated and monitored

Common exam/audit questions and hangups

Auditors tend to ask:

• “Show me how you determine which laws/regulations apply to your ISMS scope.” (expect a method, not a claim)
• “Pick one customer contract clause and trace it to implemented controls and evidence.”
• “How do you keep this current when a contract renews or a law changes?”
• “Who owns the register and who approves applicability determinations?”
• “Show me an example where a new obligation caused you to change a control or policy.” ¹

Hangups that slow audits:

• No clear applicability rationale (lots of entries, little justification)
• Mapping exists but evidence is missing or not retained
• Contractual requirements live in email threads, not a managed register
• “We rely on Legal” without a mechanism to turn legal interpretation into operational controls

Frequent implementation mistakes (and how to avoid them)

1. Mistake: Treating 5.31 as a one-time legal memo.
   Fix: Make it a managed register with owners, triggers, and evidence.

2. Mistake: Only tracking laws/regulations, ignoring contracts.
   Fix: Add contract intake from deal desk and procurement, and track customer security addenda as first-class obligations. This is where many service organizations get surprised.

3. Mistake: No control mapping, just a list of requirements.
   Fix: For every obligation, map to at least one control and one evidence item. If you cannot, the obligation is not operationalized.

4. Mistake: Over-scoping and losing credibility.
   Fix: Tie applicability to the ISMS scope and data flows. Record “not applicable” with rationale when appropriate.

5. Mistake: No proof of maintenance.
   Fix: Keep change logs, version history, and examples of updates. Missing implementation evidence is a known risk factor for 5.31. ¹

Enforcement context and risk implications (practical, non-speculative)

ISO 27001 is a certifiable standard, not a regulator. The direct consequence of weak 5.31 implementation is audit nonconformities, certification delays, surveillance audit findings, and customer trust impacts when you cannot demonstrate contractual compliance. Secondary risk is operational: missed obligations often show up as security incidents, breach notification failures, or contract disputes. Keep your claims precise: focus on audit and contractual exposure rather than citing penalties not provided in your source set. ²

Practical execution plan (30/60/90-day)

Day 30: Establish the mechanism

• Assign an owner for the requirements register (role-based) and document the workflow for intake and updates.
• Draft the register structure and populate it with the highest-impact contractual obligations (top customers) and core jurisdictions in scope.
• Create a simple traceability format obligation → internal requirement → control → evidence.
• Identify missing evidence for mapped controls and open remediation work items. ²

Day 60: Prove traceability and start recurring operations

• Complete mapping for all register items to controls and evidence.
• Run a tabletop “audit trace” on one law/regulatory obligation and one customer contract clause, and fix gaps.
• Implement change triggers: contract signature/renewal, new region, new product, new third party, major legal updates.
• Establish recurring review ceremonies and capture minutes/approvals as evidence. ²

Day 90: Make it durable and assessor-ready

• Produce an assessor-ready package: current register export, change history, mapping view, and a small evidence set for sampled obligations.
• Integrate third-party management: flow-down obligations into third-party contracts and diligence checklists where required.
• Automate reminders and evidence collection in your GRC workflow (Daydream fits well when you want requirement-to-control mapping plus recurring evidence capture tied to 5.31). ¹

Frequently Asked Questions

Do we need to list every law in every country we sell into?

List what applies to your ISMS scope and the data and services you actually provide. Keep an applicability rationale so you can defend why something is in or out.

Are customer contracts really part of Annex A 5.31?

Yes. The control explicitly covers contractual requirements, and auditors commonly test a sample contract clause traced to controls and evidence. ³

What evidence is most persuasive to an ISO auditor?

A current requirements register with version history, clear control mapping, and proof of maintenance (change log, review approvals, and examples of updates that resulted in control changes).

Who should own the requirements register: Legal or Security?

Security/GRC usually owns the register operation and evidence, while Legal owns legal interpretation and applicability decisions. Write this split into your workflow so nothing falls between teams.

How do we handle conflicting obligations between two customer contracts?

Treat it as a requirements conflict and resolve it through contracting or service scoping. Document the decision, update templates, and record compensating controls where needed.

What if we use Daydream (or another GRC tool) and still have contracts in email?

Fix the intake path first. A tool helps after executed terms reliably land in a repository and generate a register entry, owner assignment, and evidence expectations.

Footnotes

1. ISO/IEC 27001 overview; ISMS.online Annex A control index

2. ISO/IEC 27001 overview

3. ISMS.online Annex A control index