Most compliance failures don’t start with a cyberattack. They start with a legal register that hasn’t been updated since the last audit cycle, a data localization law that nobody flagged before the organization expanded into a new market, or a contractual security clause that never made it into the vendor agreement. Control 5.31 exists because the gap between what you think you’re compliant with and what you’re actually compliant with is where regulators, auditors, and opposing counsel find their leverage. Effective compliance monitoring is what separates organizations that pass audits from those that get caught off guard.
What 5.31 requires
ISO/IEC 27001:2022 control 5.31 requires your organization to identify, document, and continuously maintain a register of every legal, statutory, regulatory, and contractual requirement that applies to your information security program. This isn’t a one-time exercise. You need to build a living inventory that maps each obligation to the specific business areas it affects, assign clear ownership for monitoring changes, and review the register at planned intervals so it stays current as your regulatory landscape evolves.
The scope is broader than most teams initially expect. Beyond privacy laws and industry regulations, 5.31 covers contractual obligations you’ve made to customers and partners, regulatory requirements specific to the jurisdictions where you operate or store data, and cryptographic controls that may be subject to import/export restrictions. You need to evaluate every encryption technology you deploy against the legal frameworks of the countries where you use it. That means your legal register isn’t just a compliance artifact; it’s an operational document that informs technical decisions about how and where you deploy security controls.
Ownership is critical. The control expects you to assign named individuals or roles responsible for tracking regulatory changes in each domain, whether that’s privacy law, financial regulation, sector-specific mandates, or cross-border data transfer rules. These owners are accountable for triggering updates to the register when new legislation passes, existing regulations change, or contractual terms shift. The register then feeds directly into your Information Security Management System (ISMS), ensuring that policy updates, control adjustments, and cybersecurity risk assessments reflect your actual legal obligations rather than assumptions made during the last certification cycle.
Why 5.31 matters
An organization expanding into Southeast Asia signs new hosting agreements and begins processing customer data in-region. Twelve months later, a regulator opens a formal investigation. The issue isn’t a breach. It’s that the organization never identified a local data localization statute requiring certain categories of personal data to remain within national borders. The legal register listed General Data Protection Regulation (GDPR) and a handful of US state laws but nothing for the new jurisdiction. The result is a regulatory enforcement action, an emergency data migration, and a board-level conversation about how the compliance team missed a statutory requirement that was publicly available the entire time.
This kind of failure is increasingly expensive. The DLA Piper GDPR Fines and Data Breach Survey reports that cumulative GDPR fines since 2018 now exceed EUR 7.1 billion, with approximately EUR 1.2 billion issued in 2025 alone. These numbers reflect a regulatory environment that’s accelerating, not stabilizing, and they don’t account for the operational cost of remediation, legal fees, or reputational damage.
What attackers exploit
Threat actors and regulators both find the same weaknesses. The most common failure modes around 5.31 include:
- Outdated legal register missing new privacy laws: Jurisdictions add and amend data protection statutes regularly, and a register that isn’t reviewed on a defined cadence will fall behind.
- No assigned ownership for monitoring regulatory changes: Without clear accountability, regulatory monitoring becomes everyone’s responsibility and therefore nobody’s.
- Contractual security clauses not flowed down to subcontractors: Your obligations extend to the third parties processing data on your behalf, and contractual requirements that stop at your organizational boundary create gaps.
- Encryption deployed without checking export controls: Cryptographic technologies are subject to import and export restrictions in many jurisdictions, and deploying them without legal review can trigger sanctions violations.
- No review cadence set after initial register creation: A register built during certification and never revisited is a compliance snapshot, not a compliance program.
- Gap between stated compliance posture and actual controls: Claiming compliance with a regulation you haven’t mapped to specific ISMS controls is a finding waiting to happen.
How to implement 5.31
For your organization (first-party)
1. Inventory your jurisdictions and identify applicable laws. Start by mapping every jurisdiction where your organization operates, stores data, or serves customers. For each jurisdiction, identify the relevant legal and regulatory requirements: GDPR and third-party risk obligations for EU operations, Health Insurance Portability and Accountability Act (HIPAA) for US healthcare data, Payment Card Industry Data Security Standard (PCI DSS) for cardholder data, Sarbanes-Oxley Act (SOX) for financial reporting controls, and any local or sector-specific statutes. Don’t limit this to privacy law. Include telecommunications regulations, financial services mandates, employment law requirements for HR data, and any cross-border data transfer restrictions.
2. Create a legal register with structured fields. Build a centralized register, whether in a spreadsheet, a Governance, Risk, and Compliance (GRC) tool, or a dedicated compliance platform. Each entry should include the requirement name, its source document or statute, the business area it affects, the assigned owner, the next scheduled review date, and current compliance status. This structure ensures the register is auditable and actionable rather than a flat list of law names.
3. Assign named owners per category. Each category of legal requirement needs a designated owner responsible for monitoring changes and triggering register updates. Privacy regulations might sit with the Data Protection Officer (DPO), financial regulations with the compliance team, and contractual obligations with legal or procurement. Ownership should be documented in the register itself.
4. Establish a review cadence. Set a minimum annual review cycle for the full register, with triggered reviews whenever your organization enters a new market, signs a significant new contract, or becomes aware of legislative changes. Document the review methodology so auditors can verify that reviews are substantive, not perfunctory.
5. Map requirements to ISMS controls. Each legal or regulatory requirement in the register should trace to the specific ISMS policies and controls that address it. This mapping is what transforms a legal register from a compliance document into an operational tool. When a regulation changes, you can immediately identify which controls need updating.
6. Address cryptographic requirements separately. Cryptographic controls deserve their own section in the register because they intersect with encryption export controls, national security statutes, and sector-specific encryption mandates. Document every encryption technology you use, the jurisdictions where you deploy it, and the legal basis for its use in each location.
7. Document your methodology. Record how you identify applicable requirements, how frequently you review the register, who approves changes, and how updates propagate into policy and control changes. This documentation is audit evidence in its own right.
Common mistakes:
- Register built during certification and never updated afterward
- Laws listed in the register without tracing to specific ISMS controls
- Ignoring contractual obligations and focusing only on statutory requirements
- Treating the legal register as a legal-team-only responsibility with no security team input
- Missing cryptographic export restrictions when deploying encryption internationally
For your vendors (third-party assessment)
When assessing vendors against 5.31, your security questionnaires should ask whether the vendor maintains a legal and regulatory register, how frequently it’s reviewed, and who owns the monitoring process. Request evidence: a redacted copy of the register structure, recent review meeting minutes, or a compliance calendar showing scheduled reviews.
Red flags in vendor responses include vague claims of “full compliance” without referencing specific regulations, inability to name the person responsible for regulatory monitoring, no documented review cadence, and registers that list only one or two broadly applicable laws without jurisdiction-specific detail. Vendors operating across multiple countries should demonstrate awareness of local data protection and privacy statutes, not just GDPR.
Verification beyond self-attestation matters. Request Service Organization Control (SOC) 2 Type II reports or ISO 27001 compliance certificates and check whether the scope covers the services they provide to you. Ask for evidence that contractual security obligations flow down to their own subprocessors. A structured vendor risk assessment template can standardize this evaluation across your supply chain.
Audit evidence for 5.31
| Evidence Type | Example Artifact |
|---|---|
| Legal and regulatory register | Spreadsheet or GRC tool listing all applicable laws with owners, review dates, and status |
| Compliance review records | Meeting minutes showing periodic review of the register with documented decisions |
| Cryptographic controls inventory | Encryption technologies mapped to the regulations and jurisdictions governing their use |
| Supplier contracts | Agreements containing security clauses, Data Processing Agreements (DPAs), and compliance obligations |
| Policy mapping matrix | Document linking each legal requirement to the ISMS policy or control that addresses it |
| Change management records | Register updates triggered by new legislation, regulatory amendments, or contractual changes |
| Training records | Attendance logs for compliance awareness training covering legal and regulatory obligations |
Cross-framework mapping
Control 5.31 aligns with requirements across multiple governance and compliance frameworks. Organizations managing multi-framework programs can use this mapping to reduce duplicate effort when addressing National Institute of Standards and Technology (NIST) SP 800-53 Rev. 5, NIST Cybersecurity Framework, and other standards alongside ISO 27001.
| Framework | Equivalent Control(s) | Coverage |
|---|---|---|
| NIST 800-53 | AC-01, AT-01, AU-01, CA-01, CM-01, CP-01, IA-01, IR-01, MP-01, PE-01, PL-01, PM-01, PS-01, RA-01, SA-01, SC-01, SI-01, SR-01 | Full |
| SOC 2 | CC2.2, CC2.3 | Full |
| NIST Cybersecurity Framework (CSF) 2.0 | GV.OC-03 | Full |
| Center for Internet Security (CIS) Controls v8.1 | 15.1 | Partial |
| Digital Operational Resilience Act (DORA) | Article 5 | Partial |
| CPS 230, Australian Prudential Regulation Authority (APRA) | Paragraph 14 | Partial |
Related ISO 27001 controls
| Control ID | Control Name | Relationship |
|---|---|---|
| 5.32 | Intellectual property rights | Extends legal compliance to IP and software licensing |
| 5.33 | Protection of records | Covers retention and destruction obligations identified in the legal register |
| 5.34 | Privacy and protection of PII | Privacy-specific legal requirements such as GDPR and California Consumer Privacy Act (CCPA) |
| 5.20 | Addressing information security in supplier agreements | Contractual requirements flow to third parties through supplier agreements |
| 5.1 | Policies for information security | Top-level policies must reflect the legal obligations documented in the register |
| 5.2 | Information security roles and responsibilities | Assigns ownership for compliance monitoring and regulatory change management |
| 5.8 | Information security in project management | New projects must consider legal requirements as part of risk assessment |
| 8.24 | Use of cryptography | Technical crypto controls whose legal basis is documented in the 5.31 register |
Frequently asked questions
What is ISO 27001 5.31?
ISO 27001 5.31 is the control that requires organizations to identify, document, and maintain all legal, statutory, regulatory, and contractual requirements relevant to their information security program. It ensures your ISMS reflects your actual compliance obligations rather than assumptions.
What happens if 5.31 is not implemented?
Organizations without a maintained legal register face regulatory fines, failed certification audits, contract breaches with customers who require demonstrated compliance, and potential voidance of cyber insurance policies that assume regulatory adherence. The financial and operational impact compounds when violations span multiple jurisdictions.
How do you audit 5.31?
Auditors verify that a legal register exists, is complete across all operating jurisdictions, has named owners for each requirement category, includes evidence of periodic review, and traces each obligation to specific ISMS controls. They look for documented review cadence, change management records showing the register responds to new legislation, and evidence that cryptographic controls have been evaluated against applicable export restrictions.
How UpGuard helps
Maintaining compliance with legal and regulatory requirements across your organization and vendor ecosystem requires continuous visibility into your security posture and the posture of the third parties you depend on.
- Vendor Risk: Assess and monitor vendor compliance posture through automated security questionnaires, continuous monitoring, and centralized evidence collection that keeps your third-party compliance documentation audit-ready.
- Breach Risk: Continuously monitor your external attack surface to identify exposures that could put you out of compliance with regulatory requirements, providing the visibility needed to maintain alignment between your stated compliance posture and your actual controls.
Start a free trial to see how UpGuard helps you track compliance across your organization and vendor ecosystem.