What is ISO 27001 Annex A 5.31?
ISO 27001 Annex A 5.31 requires an organization to identify, document, and keep up to date the legal, statutory, regulatory, and contractual requirements that are relevant to information security.
In simple terms:
The organization should know which laws, regulations, contracts, and other obligations apply to its information, systems, services, customers, employees, and business operations.
These requirements can come from:
- Laws
- Government regulations
- Regulatory authorities
- Industry requirements
- Customer contracts
- Supplier contracts
- Service agreements
- Data processing agreements
- Licensing requirements
- Insurance requirements
- Security commitments
- Confidentiality agreements
The organization should also understand how these requirements affect its information security controls.
Why is A.5.31 Important?
Organizations do not operate only according to their internal policies.
They may have external obligations imposed by:
- Government
- Regulators
- Customers
- Business partners
- Industry bodies
- Contracts
- Licensing authorities
For example, a SaaS company may have a customer contract requiring:
- MFA
- Encryption
- Security assessments
- Annual penetration testing
- Incident notification
- Data retention requirements
- Audit rights
Even if these requirements are not directly imposed by law, they can still become obligations for the company because they are contractually agreed.
Simple Principle
“Know what you are legally and contractually required to protect, and make sure those requirements are reflected in your security program.”
What Types of Requirements Should an Organization Identify?
A.5.31 covers four broad categories.
1. Legal Requirements
Requirements established through applicable laws.
Examples may include:
- Data protection and privacy laws
- Cybersecurity laws
- Employment-related requirements
- Intellectual property laws
- Electronic transaction laws
- Records and retention requirements
2. Statutory Requirements
Statutory requirements are obligations established through legislation or statutory authorities.
Depending on the organization’s location and activities, these may relate to:
- Corporate records
- Employment
- Data handling
- Financial reporting
- Electronic records
- Sector-specific obligations
3. Regulatory Requirements
These arise from regulators or regulatory frameworks applicable to the organization.
Examples can include requirements from:
- Financial regulators
- Banking regulators
- Healthcare regulators
- Telecommunications regulators
- Securities regulators
- Data protection authorities
A fintech company may have very different regulatory requirements from a software development company.
4. Contractual Requirements
These are obligations agreed with another party.
Examples:
- Customer security requirements
- Data Processing Agreements
- Master Service Agreements
- Service Level Agreements
- Confidentiality agreements
- Supplier contracts
- Security addendums
- Customer audit requirements
Important
A contractual requirement can be highly important even when it is not a statutory requirement.
Simple Example
Imagine a SaaS startup has a US enterprise customer.
The customer contract states that the startup must:
- Maintain an information security program
- Use MFA
- Conduct annual penetration testing
- Notify the customer of certain security incidents
- Protect customer information
- Restrict access to customer data
- Provide security assessment evidence
These requirements become part of the startup’s information security obligations.
The startup should not simply keep the contract in a legal folder.
It should identify the security requirements and determine:
Contract
↓
Security Requirement
↓
Responsible Owner
↓
Control
↓
Evidence
For example:
Customer contract requires MFA
↓
MFA implemented
↓
IT/Security owner
↓
Identity management control
↓
MFA configuration and access review evidence
What Does A.5.31 Require?
The organization should establish a process to:
- Identify applicable requirements
- Determine which requirements apply to the organization
- Document the requirements
- Assign ownership
- Translate requirements into security obligations
- Implement appropriate controls
- Monitor changes
- Review compliance
- Retain evidence
The requirements should be kept up to date.
A legal or contractual obligation can change.
Therefore, a one-time compliance exercise is not enough.
Activities Required to Implement A.5.31
1. Determine the Organization’s Scope
Before identifying requirements, understand:
- Countries where the organization operates
- Countries where customers are located
- Types of customers
- Industries served
- Types of data processed
- Services provided
- Cloud infrastructure
- Employees and contractors
- Critical suppliers
- Regulatory exposure
For example, a startup serving financial institutions may have additional contractual and regulatory obligations compared with a startup serving small businesses.
2. Identify Applicable Laws and Regulations
Create a list of potentially applicable requirements.
Depending on the organization’s circumstances, this may include:
- Privacy laws
- Cybersecurity requirements
- Data retention obligations
- Employment requirements
- Intellectual property requirements
- Electronic records requirements
- Industry-specific regulations
The organization should determine applicability rather than simply copying a generic list from the internet.
3. Identify Customer Contract Requirements
Contracts should be reviewed for security obligations.
Look for terms involving:
- Security controls
- Privacy
- Data protection
- Encryption
- Access control
- Incident notification
- Breach notification
- Audit rights
- Penetration testing
- Security certifications
- Business continuity
- Data location
- Data retention
- Data deletion
- Subprocessors
- Vulnerability management
4. Identify Supplier and Partner Requirements
Third-party contracts can also contain security requirements.
Examples:
- Cloud providers
- Payment processors
- Managed service providers
- Data processors
- Security providers
- Software vendors
The organization should understand obligations that apply to information shared with these parties.
5. Create a Legal and Compliance Register
A practical organization should maintain a central register.
Example:
| Requirement | Type | Applicable To | Requirement | Owner | Review Frequency |
|---|---|---|---|---|---|
| Applicable privacy law | Legal | Customer data | Protect personal data | Privacy/Compliance | Annual |
| Customer security clause | Contractual | Customer environment | MFA required | IT/Security | Contract review |
| Data retention requirement | Legal/Regulatory | Records | Retain defined records | Compliance | Annual |
| Penetration testing clause | Contractual | SaaS platform | Annual testing | Security | Annual |
| Supplier security requirement | Contractual | Third parties | Security assessment | Procurement | Annual |
6. Translate Requirements Into Controls
Identifying a requirement is not enough.
The organization should determine:
“What control or process ensures that we meet this requirement?”
Example:
| Requirement | Security Obligation | Control |
|---|---|---|
| Customer requires MFA | MFA for privileged users | Identity & access controls |
| Customer requires annual VAPT | Annual security testing | Vulnerability management |
| Privacy requirement | Protect personal information | Privacy controls |
| Contract requires incident notification | Notify within agreed timeframe | Incident management |
| Contract requires backup | Maintain recoverable data | Backup and recovery |
| Customer requires audit evidence | Provide evidence | Compliance management |
7. Assign Ownership
Every important requirement should have an accountable owner.
Possible owners:
- Legal
- Compliance
- CISO
- Security
- IT
- HR
- Finance
- Procurement
- Product
- Business owner
For example:
Customer incident notification requirement
Owner → CISO/Security
Supporting team → Legal
Evidence → Incident management records
8. Monitor Changes
Requirements can change because of:
- New legislation
- Regulatory updates
- New customers
- New contracts
- New countries
- New services
- New data types
- Business expansion
- Changes to existing contracts
A startup entering a new country should reassess its legal and regulatory obligations.
9. Review Contracts Before Signing
One of the most important startup practices is to involve security and compliance early.
Before signing an enterprise customer contract, check:
- Security commitments
- Certification requirements
- Audit rights
- Incident notification periods
- Data processing obligations
- Data location
- Encryption requirements
- Penetration testing
- Business continuity
- Insurance requirements
- Subprocessor requirements
Simple Principle
Do not promise security controls in a contract that the organization cannot actually operate.
A sales team should not promise “24-hour incident notification” if the organization has no process capable of meeting that commitment.
Startup Example
Consider a SaaS startup selling software to US enterprises.
The startup initially has:
- 20 employees
- Cloud-hosted SaaS platform
- Customer personal data
- Enterprise customers
- Several third-party SaaS providers
During contract reviews, it identifies requirements for:
- MFA
- Encryption
- Annual penetration testing
- Incident notification
- Security assessments
- Data deletion
- Business continuity
The startup creates a Legal, Regulatory & Contractual Requirements Register.
It then maps each obligation to an owner and control.
Example Flow
Customer Contract
↓
Security Requirement Identified
↓
Requirement Added to Register
↓
Owner Assigned
↓
Control Implemented
↓
Evidence Collected
↓
Requirement Reviewed Periodically
This makes the contractual obligation part of the organization’s ISMS rather than leaving it only in the sales or legal department.
Startup-Focused Quick Summary
A startup does not need a massive legal department to implement A.5.31.
It needs a structured method for knowing what obligations apply to the business.
At minimum:
1. Identify
What laws, regulations and contracts apply?
2. Document
Record them in a central register.
3. Assign
Give each important requirement an owner.
4. Map
Connect each requirement to security controls.
5. Monitor
Track changes.
6. Review
Periodically verify that requirements are still applicable and being met.
Simple Model
Identify → Document → Assign → Implement → Monitor → Review
Example Legal, Regulatory & Contractual Requirements Register
| ID | Requirement | Source | Type | Applicability | Security Requirement | Owner | Evidence |
|---|---|---|---|---|---|---|---|
| LR-001 | Privacy requirement | Applicable law | Legal | Customer PII | Protect personal data | Privacy Lead | Privacy records |
| LR-002 | MFA | Customer contract | Contractual | Customer environment | MFA for users | IT | MFA report |
| LR-003 | Annual VAPT | Customer contract | Contractual | Production platform | Annual testing | Security | VAPT report |
| LR-004 | Incident notification | Customer contract | Contractual | Security incidents | Notify within agreed period | CISO | Incident records |
| LR-005 | Data retention | Applicable requirement | Legal/Regulatory | Business records | Defined retention | Compliance | Retention register |
| LR-006 | Security assessment | Customer agreement | Contractual | Enterprise customers | Respond to assessments | Compliance | Completed questionnaire |
How to Determine Whether a Requirement Applies
A common mistake is to assume that every law or regulation listed online automatically applies.
Instead, ask:
Organization
- Where is the company established?
- Where does it operate?
- Where are employees located?
Customers
- Where are customers located?
- What industries do they operate in?
- Are they regulated entities?
Data
- What information does the organization process?
- Is personal data involved?
- Is financial information involved?
- Is health information involved?
- Is confidential customer information involved?
Services
- What does the organization provide?
- Does it provide regulated services?
- Does it process information on behalf of customers?
Contracts
- What security commitments have been accepted?
- Are there customer-specific requirements?
Suppliers
- Are third parties processing customer information?
- Are there contractual security requirements?
Audit Evidence for A.5.31
An auditor may request:
Registers
- Legal and Regulatory Requirements Register
- Contractual Requirements Register
- Compliance Obligations Register
Legal/Regulatory
- Applicable laws list
- Regulatory requirements
- Compliance assessments
- Legal review records
- Regulatory update monitoring
Contracts
- Customer contracts
- Security addendums
- Data Processing Agreements
- Supplier agreements
- Security requirements
Mapping
- Requirement-to-control mapping
- Compliance matrix
- Contractual obligation mapping
Review
- Periodic review records
- Compliance review meetings
- Legal updates
- Contract review records
- Corrective actions
A.5.31 Audit Checklist
| Audit Question | Evidence |
|---|---|
| Has the organization identified applicable legal requirements? | Legal register |
| Have regulatory requirements been identified? | Regulatory register |
| Have contractual security obligations been identified? | Contract register |
| Are requirements documented? | Compliance register |
| Is ownership assigned? | Responsibility matrix |
| Are requirements mapped to controls? | Compliance matrix |
| Are customer contracts reviewed for security obligations? | Contract review records |
| Are supplier obligations considered? | Supplier register |
| Are requirements periodically reviewed? | Review records |
| Is there a process for identifying regulatory changes? | Regulatory monitoring |
| Are new contracts assessed for security requirements? | Contract review evidence |
| Are compliance gaps tracked? | Corrective action register |
| Is evidence maintained? | Compliance evidence |
Common Mistakes
1. Keeping a Generic List of Laws
A list of 50 laws does not demonstrate that the organization understands which ones actually apply.
The organization should document applicability and rationale.
2. Focusing Only on Laws
A.5.31 also includes:
- Regulatory requirements
- Statutory requirements
- Contractual requirements
A startup may have more immediate security obligations through customer contracts than through a specific cybersecurity law.
3. Legal Team Owns Everything
Legal may identify the obligation, but implementation often belongs to:
- IT
- Security
- HR
- Compliance
- Product
- Procurement
A legal requirement must ultimately be translated into operational controls.
4. Ignoring Customer Contracts
Enterprise customers frequently impose security requirements through contracts and security addendums.
These should be included in the ISMS.
5. No Contract Review Before Signing
A sales team may agree to requirements that the organization cannot currently meet.
This can create:
- Compliance gaps
- Contract breaches
- Customer disputes
- Additional costs
- Security commitments that cannot be operationalized
6. No Monitoring for Changes
A register created once and never updated quickly becomes unreliable.
7. No Evidence
It is not enough to say:
“We comply with the requirement.”
The organization should be able to demonstrate how compliance is achieved.
Practical Startup Implementation Model
A startup can implement A.5.31 using a lightweight process.
Step 1 – Identify
Identify countries, industries, customers, data types and services.
Step 2 – Determine Applicability
Determine which legal, statutory, regulatory and contractual requirements actually apply.
Step 3 – Document
Create a central requirements register.
Step 4 – Assign
Assign an owner for each significant obligation.
Step 5 – Map
Map requirements to policies, processes and controls.
Step 6 – Implement
Implement the required security measures.
Step 7 – Monitor
Track changes to laws, regulations and contracts.
Step 8 – Review
Periodically verify that obligations remain applicable and are being addressed.
Simple Model
Scope → Identify → Determine Applicability → Document → Map → Implement → Monitor → Review
Policy vs. Process vs. Evidence
| Type | Example |
|---|---|
| Policy | Legal, Regulatory & Contractual Compliance Policy |
| Process | Legal & Regulatory Monitoring Procedure |
| Process | Customer Contract Security Review Procedure |
| Process | Compliance Assessment Procedure |
| Document | Legal & Regulatory Requirements Register |
| Document | Contractual Requirements Register |
| Document | Requirement-to-Control Matrix |
| Evidence | Contract review |
| Evidence | Legal review |
| Evidence | Compliance assessment |
| Evidence | Regulatory update review |
| Evidence | Corrective action record |
Remember
Policy = What we commit to
Process = How we manage it
Register = What requirements apply
Evidence = How we demonstrate it
Relationship With Other ISO 27001 Controls
A.5.31 connects with several other controls.
| Control | Relationship |
|---|---|
| A.5.1 Policies for Information Security | Security policies should reflect relevant obligations |
| A.5.19–A.5.22 Supplier Controls | Supplier contracts may contain security requirements |
| A.5.23 Cloud Services | Cloud agreements and legal requirements may create obligations |
| A.5.24–A.5.28 Incident Management | Laws and contracts may establish incident handling and evidence requirements |
| A.5.29–A.5.30 Business Continuity | Contracts and regulations may establish continuity requirements |
| A.5.32 Intellectual Property Rights | Supports protection of intellectual property obligations |
| A.5.33 Protection of Records | Supports legal and contractual record-retention obligations |
| A.5.34 Privacy and Protection of PII | Connects legal privacy obligations with operational controls |
| A.5.35 Independent Review | Reviews can assess whether applicable requirements are addressed |
| A.5.36 Compliance with Policies, Rules and Standards | Verifies compliance with established requirements |
Useful Documents for A.5.31
- Legal & Regulatory Requirements Register – [Insert Draft Document Link]
- Contractual Security Requirements Register – [Insert Draft Document Link]
- Requirement-to-Control Mapping Matrix – [Insert Draft Document Link]
- Customer Contract Security Review Checklist – [Insert Draft Document Link]
- Regulatory Monitoring Procedure – [Insert Draft Document Link]
- Compliance Obligations Assessment Template – [Insert Draft Document Link]
- Legal & Regulatory Compliance Checklist – [Insert Draft Document Link]
Questions an Auditor May Ask
About Applicability
- How do you identify laws and regulations applicable to your organization?
- How do you determine whether a specific requirement applies?
- Who is responsible for monitoring changes?
About Contracts
- How do you identify security requirements in customer contracts?
- Show me an example of a customer security requirement.
- How was that requirement translated into an operational control?
About Monitoring
- How do you know when applicable requirements change?
- How frequently do you review the requirements register?
About Implementation
- Show me a requirement and the control used to address it.
- Who owns the requirement?
- What evidence demonstrates compliance?
About New Customers
- What happens when a new enterprise customer imposes additional security requirements?
- Does your sales or legal process involve security/compliance review?
Startup-Focused Final Takeaway
ISO 27001 Annex A 5.31 is fundamentally about knowing your obligations.
A company cannot effectively manage information security compliance if it does not know:
- Which laws apply
- Which regulations apply
- Which statutory requirements apply
- What customers require
- What suppliers require
- What security commitments the organization has made
For a startup, the practical process is:
Identify the obligation
↓
Determine whether it applies
↓
Document it
↓
Assign an owner
↓
Map it to a control
↓
Implement the control
↓
Collect evidence
↓
Monitor for changes
↓
Review periodically
The practical auditor question is:
“How does your organization identify the legal, regulatory, statutory, and contractual information-security requirements that apply to your business, and how do you ensure those requirements are actually addressed?”
That is the practical objective of ISO 27001 Annex A 5.31 – Identification of Legal, Statutory, Regulatory and Contractual Requirements.