UnixTime

Research Note

ISO 27001 A.5.31 - Legal, Statutory, Regulatory and Contractual Requirements

  • Updated Jun 17, 2026
  • Read 03 mins read
  • Status reviewed

The organization must know which legal, statutory, regulatory, and contractual information security requirements apply, document them, keep them current, and define how it will...

On this page

Requirement

Requirement lens

Treat this as the control objective. The implementation, evidence, and audit sections explain how to make it operational and provable.

“Legal, statutory, regulatory and contractual requirements relevant to information security and the organization’s approach to meet these requirements shall be identified, documented and kept up to date.”

Plain-language meaning

The organization must know which legal, statutory, regulatory, and contractual information security requirements apply, document them, keep them current, and define how it will meet them.

Why this matters

You cannot comply with obligations you have not identified. Missing legal, regulatory, contractual, jurisdictional, or cryptographic requirements can create certification findings, breach-notification failures, unlawful data handling, contract breaches, fines, or business disruption.

Implementation guidance

Implementer focus

Turn this section into owners, procedures, records, review cadence, and evidence locations. A control is not implemented until it operates repeatedly.

  1. Create a legal, regulatory, statutory, and contractual requirements register for information security obligations.
  2. Assign owners for identifying, reviewing, updating, and coordinating compliance with each requirement.
  3. Map requirements to controls, policies, procedures, evidence, business processes, suppliers, systems, data types, and jurisdictions.
  4. Use appropriate expertise for unfamiliar jurisdictions, online business, cross-border services, regulated sectors, and contractual obligations.
  5. Assess legal and regulatory rules for cryptography, digital signatures, electronic communications, data transfer, retention, monitoring, and breach notification where relevant.
  6. Connect requirement changes to change control so new or changed obligations trigger updates to controls, contracts, policies, and evidence.

Audit guidance

Auditor focus

Look for evidence that the process operates in practice, not just that a document exists.

Auditors should verify that applicable requirements are identified, documented, assigned, reviewed, kept up to date, and traceable to implemented controls. They should test whether requirement changes result in control changes and whether specialist advice is used where needed.

Evidence examples

Evidence quality

Strong evidence links requirement, owner, action, date, review, and outcome. Weak evidence usually proves only intent.

Evidence What it proves
A current requirements register identifies legal, statutory, regulatory, and contractual information security obligations. Supports design, implementation, operation, or review
Each requirement has an owner, review date, jurisdiction or source, applicable scope, control mapping, and evidence location. Supports design, implementation, operation, or review
Requirement change records Supports traceability from changed obligations to changed controls
Cryptography and jurisdiction assessment Shows special legal rules were assessed where relevant
Legal or specialist advice records Shows expert input was used for complex obligations

Strong evidence

  • A current requirements register identifies legal, statutory, regulatory, and contractual information security obligations.
  • Each requirement has an owner, review date, jurisdiction or source, applicable scope, control mapping, and evidence location.
  • Changes in laws, regulations, or contracts are tracked through change control and update affected controls.
  • Cryptography, digital signatures, electronic communication, and cross-border obligations are assessed where relevant.
  • Legal or specialist advice is retained for complex jurisdictions or regulated business activities.
  • Responsible personnel can explain their obligations and evidence.

Weak evidence

  • A generic compliance list exists but is not mapped to controls or evidence.
  • Contracts are stored but information security obligations are not extracted.
  • No owner is responsible for keeping requirements current.
  • Cryptographic legal requirements are assumed rather than assessed.
  • Requirement changes do not trigger policy, control, or evidence updates.
  • International or online business obligations are ignored.

Common failures

Implementation watchouts

These are the fastest ways this topic fails in real ISMS work.

Failure Why it matters
Requirements register is incomplete or stale The organization cannot prove it knows all applicable obligations
Contractual security obligations are not extracted from contracts Operational teams may miss commitments made to customers or suppliers
Legal changes are not tied to change control Controls may remain compliant with old requirements only
Cryptography rules are not assessed by jurisdiction Encryption, digital signature, or communication practices may breach local rules
No owner is assigned for requirement monitoring Compliance becomes reactive and dependent on memory

Exam traps

Exam focus

Read these as distractor patterns. Exams often test scope, timing, ownership, applicability, and evidence quality.

  • A.5.31 is about identifying, documenting, keeping current, and meeting requirements, not just having policies.
  • Requirements include legal, statutory, regulatory, and contractual obligations.
  • Cryptographic controls can have special jurisdiction-specific legal rules.
  • Changes to requirements should be traceable to changes in implemented controls.
  • Specialist expertise may be needed for legal or international requirements.

KB-ready summary

Quick refresher

Use this section for last-day review and for explaining the topic to a control owner.

A.5.31 requires practical compliance governance: obligations must be identified, owned, documented, kept current, mapped to controls, and evidenced. In audit, the useful proof is not a policy statement; it is a maintained register, mapped controls, responsible owners, and sampled records showing the process operates.

Templates and checklists

  • Iso27001
  • Iso27002
  • Annex a
  • Organizational controls
  • Compliance
  • Audit
  • Legal compliance
  • Regulatory compliance
  • Contractual requirements
  • Cryptography

Note Metadata

Aliases: A.5.31, Legal, Statutory, Regulatory and Contractual Requirements

Source: 02 Annex A Organizational Controls/A.5.31 Legal, Statutory, Regulatory and Contractual Requirements.md

Control dependency map

How this control connects to work products

Generated from the static research graph. It shows navigation and evidence dependencies; it is not an audit conclusion.

10

links

Control

ISO 27001 A.5.31 - Legal, Statutory, Regulatory and Contractual Requirements
01

Requirement context

Primary control text, framework notes, or adjacent controls this note points to.

02

Implementation artifacts

Templates and working records that help operate the control.

03

Audit checks

Audit questions, checklists, or review material connected to the control.

04

Risk treatment

Risk records and ISO 27005 material this control mitigates or supports.

Graph-sourced resources

Templates and evidence

Implementer templates

Working artifacts for control owners and operators.

Auditor evidence packs

Evidence collections and audit-facing verification material.

Risk treatment artifacts

Risk records, mappings, and treatment-supporting references.