ISO 27001 Control 5.31: Legal, Statutory, Regulatory and Contractual Requirements

Alan Parker, ISO 27001 Consultant & Internal Auditor,
Helping UK SMEs hit ISO 27001 in 90 days.
B.Sc (Hons) Information Systems · Certified ISO 27001 Lead Auditor · CISMP · ITIL Expert · 30+ years in IT governance and security.
Read full bio →

Introduction

Ask a small business for its legal register and, if one exists, it will usually have one line on it: GDPR. Occasionally the Data Protection Act as well. And that is the register.

GDPR matters, but it is a small part of what control 5.31 is asking for. The control covers every legal, statutory, regulatory and contractual requirement that bears on your information security. Contracts are the part people forget, and they are often where the most specific and enforceable obligations sit. If your terms and conditions promise customers something, that promise is a security requirement, and somebody needs to know about it.

This page covers what the control requires, what a realistic register looks like for a UK SME, and why the contractual side deserves more attention than it gets. There is a free legal and contractual requirements register further down.

What control 5.31 actually asks for

The control requires you to identify, document and keep up to date the legal, statutory, regulatory and contractual requirements relevant to information security, and your approach to meeting them. In practice that means:

• Identifying the requirements. Laws, regulations and contract terms that affect how you protect information, in every jurisdiction you operate in or serve.
• Writing them down. A register that says what each requirement is, why it applies and what it asks of you.
• Assigning ownership. Somebody responsible for each one, and for knowing when it changes.
• Acting on them. Each requirement linked to the controls, processes or reports that meet it.
• Keeping it current. Reviewed when laws change, when you enter a new market, and when you sign a significant contract.

In the 2013 edition this was covered by controls A.18.1.1 and A.18.1.5. It also connects directly to clause 4.2 of the standard, which asks you to identify the requirements of interested parties, and states that these can include legal and regulatory requirements and contractual obligations.

Where 5.31 sits

Control 5.31 is the starting point for the compliance controls. It finds the obligations; the others deal with specific kinds of them. 5.32 covers intellectual property, 5.33 records and 5.34 privacy. The register is where they all begin, and it feeds the rest of the ISMS.

GDPR, and only GDPR

A register with only GDPR on it tells an auditor that nobody really asked the question. Most UK SMEs have obligations from several directions. The table below is a starting point rather than legal advice, and not every line will apply to you, but each one is worth considering.

The point is not to list every law in the country. A register copied from a template, full of laws that have nothing to do with your business, is as unhelpful as one with a single line. The point is to have asked, for each source, whether it applies to you, and to record the answer either way.

The contracts nobody reads twice

Here is the gap I find most often. Organisations sign contracts, agree to customers’ terms and publish their own, and never summarise what they have promised. The commitments sit inside documents filed by sales or finance, and the people who actually have to deliver them have never seen them.

Think about what a typical set of terms or a customer security schedule contains. Availability targets. Support response times. Backup and recovery commitments. Breach notification deadlines. Data location. Encryption. The right to audit. Every one of those is an information security requirement, and availability in particular is one third of what security means.

If your terms promise 99.9% availability, your developers and product owners need to know. It has to be designed for, built in, monitored and reported on. If nobody in the technical team has read the terms, the commitment is being met by luck, if it is being met at all.

So tease the commitments out. For each significant contract, and for your standard terms, list what you have promised that touches security, and make sure it is visible to the people who build and run the service. That applies to promises made to customers individually, in bespoke contracts, and to customers as a group, in your standard terms.

When a contract is enforced

Around 2018 I was contracted to a software company delivering a government contract. The contract set out a number of specific requirements, and the company was failing to meet several of them. Nobody had set out to break the contract. The obligations had simply never been translated into anything the operational teams worked to.

The customer noticed. It formally cited the breaches back to the company, clause by clause, and put it on formal notice. For a while it came very close to losing the contract altogether.

My team and I were brought in to fix it. Much of the work was unglamorous: going through the contract, pulling out every requirement, and making sure each one was being met and, crucially, reported on. Availability was the big one. The service had to be up when the contract said it would be, and the customer had to be able to see that it was. Once the requirements were visible, owned and measured, the relationship recovered.

The lesson applies to any organisation. Public sector contracts are explicit and the customer will enforce them, but private contracts are no different in principle. If you cannot list what you have promised, you cannot show you are meeting it, and sooner or later someone will ask.

Building a register that is actually used

A useful register is short, specific and owned. For each requirement it records:

• The requirement. The law, regulation or contract, named precisely.
• Why it applies. One line. “We employ staff in the UK.” “Clause 12 of the customer’s master services agreement.”
• What it asks of you. In plain language, focused on information security.
• How you meet it. The controls, processes or reports that deliver it.
• Who owns it. A named person, not “IT” or “management”.
• Who needs to know. Especially for contracts: the developers, support team or product owner who have to deliver it.
• When it was last reviewed.

Keep the contractual commitments on their own tab. They change more often than laws, they are specific to customers, and they need to reach a different audience. When a new contract is signed, adding its commitments to the register should be part of the process, the same way sales would add it to the CRM.

Then keep it current. Laws change, you enter new markets, and contracts are renewed on different terms. A quick review every quarter, and an update whenever a significant contract is signed, is enough for most small businesses.

What auditors will look for

In an audit, I would typically work through 5.31.

1. The register. Does it exist, and does it go beyond GDPR? Does it reflect where the business operates and who it serves?
2. The contracts. Pick a significant customer. What does their contract require on security and availability, and where is that captured?
3. The link to delivery. Do the people responsible for meeting a requirement know about it? I may ask a developer what availability the service has to achieve.
4. Evidence it is met. For a contractual commitment like availability, show me the reporting.
5. Ownership and review. Who keeps the register current, and when was it last updated?
6. Clause 4.2. Do the requirements of interested parties in your context documents match the register?

Common issues

• A register with GDPR and nothing else.
• A register copied from a template, listing laws that do not apply and missing ones that do.
• Contractual commitments never summarised, so the technical team has never seen them.
• Availability or response time commitments in the terms that nobody measures.
• Customer security schedules signed by sales without anyone checking they can be met.
• Breach notification deadlines in contracts that differ from the incident procedure.
• Overseas obligations ignored because the company is registered in the UK.
• No owner, no review date, and no record of changes.

The self-check

Five questions. If you cannot answer them today, an auditor will find that out for you.

• Apart from GDPR, which laws on your register affect your information security?
• What availability have you promised customers, and do your developers know?
• Which of your customer contracts contain security schedules, and what do they require?
• If a customer formally cited a contract breach tomorrow, could you show which requirements you are meeting?
• When was the register last updated, and what triggered it?

The second and fourth are the ones to sit with. They are where the real exposure usually is.

A worked example

The details below are typical rather than drawn from a single engagement. This is a composite of a first proper look at 5.31 in a business of this size.

A 25-person SaaS company selling to UK businesses and a handful of public sector bodies. Its legal register listed GDPR and the Data Protection Act 2018. Its standard terms had been written by a lawyer three years earlier. Several larger customers had their own contracts.

What the review found

• The standard terms promised 99.9% monthly availability and four-hour response to critical incidents. The engineering team had never seen them, and nobody measured monthly availability.
• Two public sector contracts required notification of security incidents within 24 hours and annual evidence of a penetration test. Neither requirement was on any internal list.
• One enterprise customer’s contract required all data to stay in the UK. A recently added analytics tool processed data in the US.
• Several applicable laws were missing, including the Computer Misuse Act and employment record keeping requirements, alongside EU GDPR for the company’s European customers.

What changed

• The register was rebuilt with a separate tab for contractual commitments, populated from the standard terms and the ten largest contracts.
• Availability monitoring was set up against the contractual target, with a monthly report shared with the product owner.
• The incident procedure was updated to check contractual notification deadlines, and the annual penetration test was added to the review plan under control 5.35.
• The analytics tool was reconfigured to process data in the UK, and a contract check was added to the process for adopting new tools.
• Adding commitments to the register became part of the contract signing process.

About three days of effort, most of it reading contracts. It found the data residency problem before the customer did, which alone made it worth it.

How control 5.31 links to other clauses and controls

• Clause 4.2, Understanding the needs and expectations of interested parties. Legal, regulatory and contractual requirements are interested party requirements. Your register and your 4.2 analysis should agree.
• Clause 6.1, Actions to address risks and opportunities. Failing a legal or contractual requirement is a risk, and should appear in the risk assessment.
• Control 5.32, Intellectual property rights. Licences and copyright are a category of legal requirement with their own control.
• Control 5.33, Protection of records. Many retention periods come from the laws on your register.
• Control 5.34, Privacy and protection of PII. Privacy laws are identified here and met there.
• Control 5.20, Addressing information security within supplier agreements. The mirror image: what you require of suppliers, often driven by what customers require of you.
• Control 5.30, ICT readiness for business continuity. Availability commitments in contracts set the recovery objectives you have to meet.
• Control 5.26, Response to information security incidents. Contractual notification deadlines belong in the incident procedure.

Frequently asked questions

Sources and further reading

Official legislation, standards and guidance referred to on this page.

• UK GDPR. The UK General Data Protection Regulation, on legislation.gov.uk.
• Data Protection Act 2018. The UK law that sits alongside UK GDPR.
• Data (Use and Access) Act 2025. Amends UK GDPR, the Data Protection Act and PECR, with changes commencing in stages through 2026.
• Privacy and Electronic Communications Regulations 2003 (PECR). Rules on electronic marketing and cookies.
• Computer Misuse Act 1990. The main UK law on unauthorised access to computer systems.
• Network and Information Systems Regulations 2018. Security duties for operators of essential services and some digital service providers.
• Companies Act 2006. Includes company record keeping requirements.
• Copyright, Designs and Patents Act 1988. UK copyright law, relevant to software and content.
• UK GDPR guidance and resources. The ICO’s guidance for organisations.
• ISO/IEC 27001:2022, Information security management systems. The standard itself, published by ISO.

Internal Audit Service

Get an independent view of your ISO 27001 ISMS before you go into an audit.

“Alan from Iseo Blue truly came to our rescue. His support ahead of our internal audit was outstanding, and he helped us get our ISMS 100% ready for the Phase 2 audit.“

– Quartile.

✓ Gain confidence
✓ Audit plan
✓ Independent view
✓ An ISO 27001 requirement

✓ Audit findings report
✓ Recommendations
✓ Review meeting
✓ Fixed price

£2,500

+ VAT where applicable

View DetailsBook a discovery call