Legal, statutory, regulatory and contractual requirements
The organization is to identify, record and keep current the legal, statutory, regulatory and contractual duties that bear on information security, together with how it intends to meet them.
What the requirement asks
The organization is to identify, record and keep current the legal, statutory, regulatory and contractual duties that bear on information security, together with how it intends to meet them. Purpose: comply with the legal, regulatory and contractual obligations that concern information security. Guidance: external requirements are to be considered when writing security policies and procedures, when designing, implementing or changing controls, when classifying information and assets to set internal or supplier requirements, in risk assessment and treatment, in defining security processes, roles and responsibilities, and in setting contractual requirements for suppliers and the scope of what they supply. On legislation and regulation, the organization should identify all laws and regulations relevant to its security for its type of business; account for every relevant country where it operates, where products and services it uses come from, or where information crosses borders; review the list regularly to catch changes and new laws; and define and record the processes and individual responsibilities for meeting them. Cryptography often carries specific legal rules, so consider restrictions on importing or exporting hardware and software that perform, or are designed to have added, cryptographic functions; restrictions on using cryptography; mandatory or discretionary access by national authorities to encrypted information; and whether digital signatures, seals and certificates are legally valid; legal advice is recommended, especially when encrypted information or tools move across borders. Contractual security requirements include those in client contracts, supplier contracts (5.20) and insurance contracts. In the ISMS the control is compared with the controls determined in risk treatment and recorded in the Statement of Applicability as included or excluded, with the reason and the implementation status.
What the guidance adds
Legal and contractual requirements need a register with an owner. The guidance asks for the source, the obligation, the control that meets it and the review date.
Status of the guidance. The guidance lens for 5.31 reads the draft, which is at stage 40.00 and is not published, against the published ISO/IEC 27001:2022 requirement above. It is our reading, not a quotation, and it is not a requirement.
What good looks like
Put the control in the Statement of Applicability with an owner, a status and the risk it treats. Then keep A register of applicable laws, regulations and contractual obligations for information security, with the countries covered, the approach to meeting each and a named responsible owner and one live sample together.
Evidence an assessor asks for
- Legal and regulatory registerA register of applicable laws, regulations and contractual obligations for information security, with the countries covered, the approach to meeting each and a named responsible owner
- Legal and regulatory registerRecords of periodic review of the register and of new or changed legislation identified
- Legal and regulatory registerEvidence that the register informed policies, control design, classification, risk assessment and supplier requirements
- Legal and regulatory registerAn assessment of cryptography import, export, usage and lawful access rules for each relevant jurisdiction, with legal advice where encryption crosses borders
- Legal and regulatory registerClient, supplier and insurance contracts with their security obligations extracted and tracked
- Legal and regulatory registerDocumented processes and individual responsibilities for meeting each requirement
The question an assessor will ask
An assessor will ask for A register of applicable laws, regulations and contractual obligations for information security, with the countries covered, the approach to meeting each and a named responsible owner, then trace it to the system it protects. For A.5.31 the test is whether that record ties to a live sample, not whether the control is named in a policy.
Common gaps
- The register lists laws but not how the organization meets each one or who is responsible
- Obligations in client contracts and insurance policies are not captured
- Foreign jurisdictions reached through cloud hosting or data transfer are overlooked
- Cryptography export or usage restrictions are not considered when deploying encryption internationally
Before the next audit
Before the next audit, check one live sample for this gap: the register lists laws but not how the organization meets each one or who is responsible.