ISO 27001 Annex A 5.33: protection of records without the bloat

The auditor asks you to retrieve a three-year-old client record. The archive is encrypted, the administrator who set it up has left, and the file server still holds ten-year-old CVs. That is the gap ISO 27001 Annex A 5.33 exists to close, and it closes with settings you probably already pay for.

This guide is for security and compliance leads at UK firms of 25 to 250 people. It covers what the control requires, how to build a one-page retention schedule, how to enforce it in Microsoft 365, Google Workspace and AWS, and which questions auditors ask.

What does 5.33 protection of records require under ISO 27001?

ISO 27001 Annex A 5.33 requires you to identify which information counts as a business record and protect it against loss, tampering and unauthorised access for as long as law or contract demands. You keep it retrievable in usable form, then destroy it properly afterwards. It covers finance, HR and client records, not only ISMS documents.

The test for protection of records ISO 27001 auditors apply is practical. Would you ever need to produce this information for a regulator, a court, an auditor or a client? If so, it is a record, and it earns a line in your retention schedule.

We read the control through four attributes that a record must keep for its whole life:

• Authenticity: the record is what it claims to be, created by the person or system it names.
• Integrity: nobody has altered it since, and you can show that.
• Reliability: it captures the transaction or decision accurately as it happened.
• Usability: you can find it, open it and read it when someone asks.

A document and a record are different things. A policy is a document: you revise it, and only the current version matters. A signed contract or a deletion log is a record: its value is that it has not changed. Clause 7.5 governs the ISMS's own documents and records, while A.5.33 reaches every business record, including the finance, HR and client files the ISMS never created.

The control sits beside two others. A.5.31 supplies the laws and contracts that set your retention periods, and A.8.24 keeps encrypted archives decryptable across their whole lifespan.

Why is keeping too much as risky as keeping too little?

Keeping too little leaves you unable to answer HMRC, defend an employment claim or reconstruct an incident. Keeping too much personal data breaches the UK GDPR storage limitation principle. Data held without a remaining purpose is a complaint waiting to happen, and it widens the damage of any breach.

Under-retention fails in specific places. HMRC can ask for tax records long after the return was filed. An employment claim turns on what the personnel file says. After an incident, missing logs mean you cannot reconstruct what happened or tell customers what was touched.

Over-retention fails differently. The ICO storage limitation guidance makes the point plainly: even personal data collected fairly and lawfully cannot be kept for longer than you actually need it. A stale customer database also enlarges the blast radius of a breach, because every record kept "just in case" leaves with the rest.

For firms selling into enterprises, retention questions now appear in procurement due diligence. "Indefinitely, on the file server" is an answer that loses deals.

The usual pitfalls invert each other. With no schedule, teams keep everything "to be safe", which is the unsafe option under UK GDPR. Then an audit looms, and someone runs an over-zealous clean-up that deletes material still under statutory retention or an active legal hold.

How do you implement ISO 27001 Annex A 5.33 with a one-page retention schedule?

List each record type (financial, contractual, personnel, client transaction, system logs) and record the retention period, the legal or business driver, where it lives and how it is destroyed. Take periods from your A.5.31 legal register, then fold the handling rules into your existing classification policy instead of writing a records programme.

Group records into a handful of categories rather than listing every document. The National Archives retention guidance frames it well: keep information only as long as business, legal or historical purposes require, and apply one policy to everything you hold. It also suggests three broad groupings: short-term (up to two years), medium-term (up to eight years) and long-term. Fewer categories mean fewer arguments and fewer places for enforcement to drift.

The location column does the real work. It tells whoever configures retention which system to touch, and it exposes record types scattered across personal drives, shared mailboxes and SaaS exports. Those are the places where over-retention hides.

How long should records be kept? There is no universal answer, because periods come from your legal register and your contracts. These common UK anchors give you something to test your own numbers against:

• Financial and tax records: around six to seven years.
• Personnel files: the length of employment plus six years.
• System logs: commonly a year.
• CCTV: around 30 days, absent an incident.

Treat those as starting points, not defaults. Check your sector's rules and your customer contracts, and write the driver beside each period so you can defend it to an auditor. A period with no stated driver is a guess.

Fold the handling rules into your A.5.12 classification and handling policy. At this scale one document carrying both is fine, and the classification tier then drives the protection each record type receives. A standalone records policy gives you a second document to maintain and a second thing to drift.

A retention schedule that no system enforces is a wish list, not a control.

Budget a few days of focused work, once the legal register and classification scheme exist to hang the schedule on. The privacy overlap means it pairs naturally with A.5.34.

How do you keep protected records readable for seven years or more?

Restrict record repositories to the roles that need them, require MFA, encrypt in transit and at rest, and store long-lived records in durable formats such as PDF/A and CSV. Treat encryption keys as part of retention under A.8.24, so an archive stays decryptable after the administrator who created it leaves.

Protect the stores, not each file. Put the access review for each repository on a calendar and keep its outcome, because the review record is audit evidence in its own right. Include records in your backup regime, and run a restore that brings one back readable.

Choose boring formats. PDF/A and CSV will open in ten years, while a proprietary export from a retired SaaS tool may not. Keep the metadata with the record as well: who created it, when, and in what context. That context makes a record provable rather than just a file, and a migration that strips it quietly destroys the evidential value.

Keys deserve their own line in the schedule. A.8.24 covers the key lifecycle, and for archives it comes down to four habits:

• Name a role, not a person, as key custodian, and put key handover on the leaver checklist.
• Keep a second copy of archive keys in a separately controlled vault with break-glass access.
• Retain retired keys for as long as any data they encrypted is still inside its retention period.
• Test decryption as part of the restore test, not only the restore itself.

An encrypted archive nobody can decrypt is a deletion that nobody approved.

How do you enforce retention in Microsoft 365, Google Workspace and AWS?

Encode the schedule as running configuration. Lifecycle and retention policies delete records when their period ends, and object-lock or WORM storage stops silent rewriting. A legal-hold flag pauses deletion for disputed datasets, and a regular drift scan flags data older than its scheduled period. The configuration itself becomes your evidence.

Lifecycle rules are the enforcement layer. Cloud storage lifecycle policies, email retention rules and SaaS retention settings turn the schedule from a document into running configuration. Deletion happens because the platform does it, and an export of that configuration shows the auditor exactly what ran. The table below maps each mechanism to the three platforms most UK SMEs run, and features vary by licence tier, so check yours.

Use immutability where integrity is the point. The NCSC Principle 13 audit information guidance says customers should be confident that audit information cannot be deleted by the customer or the cloud provider during a defined retention period. It is written for audit logs, but the same design suits financial and other integrity-critical records, because "has this been tampered with" becomes answerable by design.

Treat legal hold as a workflow, not an email. A hold flag set from your ticketing system pauses lifecycle deletion for named datasets. That closes the gap between the solicitor's letter and the platform's scheduled job. The ticket, the flag and the release date become your override evidence.

Run a drift scan on a schedule. It should look for:

• Personal data older than its scheduled period, such as CVs of unsuccessful candidates.
• Logs held beyond their stated period.
• Record types with no lifecycle rule at all, which is retention on paper but not on the file server.

Run routinely, the scan turns over-retention from an annual audit surprise into an ordinary alert.

A 50-person firm doesn't need a records-management platform. It needs a schedule and the retention settings it already pays for.

What audit evidence does ISO 27001 Annex A protection of records need?

Auditors expect five evidence sets. Three are the retention schedule with its review history, the policy carrying handling and disposal rules, and access configuration with periodic review records. The other two are disposal logs and destruction certificates, including legal-hold overrides, and key arrangements with a restore test that brings an archived record back readable.

Most of this set is what the automation already leaves behind. The list shows where each item comes from:

1. Schedule and review history. Version history in your document system, with dated review entries and a note of what changed and why.
2. Policy. The classification and handling policy, carrying the rules for records storage and disposal.
3. Access configuration and reviews. Role assignments for the main record stores, plus the dated outcome of each access review.
4. Disposal and hold evidence. Platform deletion logs for digital records, certificates from your shredding or media-disposal supplier for paper and hardware, and proof that a held dataset survived a scheduled deletion run.
5. Keys and restore test. Who holds archive keys, where the second copy lives, and a dated restore of an archived record opened in readable form.

Paper and digital records both belong in this set. Paper files need the same schedule line, a lockable store and a certificate when they are shredded. A missing certificate for shredded paper is as visible as a missing deletion log.

Generate this evidence continuously rather than assembling it the week before the audit. Platform exports of lifecycle configuration and deletion logs, taken on a regular cadence, mean the sample is a retrieval exercise, not a reconstruction.

What will an auditor ask about Annex A 5.33, and how is it graded?

Expect five questions: where retention periods come from, who can access and alter a record type, whether a three-year-old record can be retrieved live, whether end-of-retention disposal actually happens, and who holds archive keys. Statutory retention breaches typically grade major; a missing schedule, access review or destruction certificate typically grades minor.

Each question has a short answer you can show rather than describe:

1. Where do the periods come from? Open the schedule and show the driver column, tied to the A.5.31 legal register.
2. Who can access and alter this record type? Show the role assignment, the last access review and the immutability or audit setting.
3. Can you retrieve a three-year-old record now? Do it live, and open it in a readable form.
4. Does disposal actually happen? Show a deletion log entry for something that passed its period.
5. Who holds the keys? Name the custodian role, show the second copy and walk through the leaver process.

Sampling works by tracing. The auditor picks a record type from the schedule and follows it: where it is stored, who has access, whether anything past its period still exists, and whether disposal left a trail. Retrieval gets tested live surprisingly often, and a five-minute wait that turns into "we'll send it later" is noted.

Grading is certification-body practice, not a clause of the standard, and it varies by auditor. Typically, breaching statutory retention, or missing records that the ISMS's own operation depends on, is the breakdown case and grades major. A missing retention schedule, personal data kept past any purpose, an unreviewed access list or a missing destruction certificate grades minor. Minors add up to a major when they form a pattern.

A team that has built the automation answers all five by showing configuration rather than describing intent. The schedule line, the lifecycle rule, the deletion log and the restore test form the same chain the auditor traces, so the sample becomes a walk through your own system.

Frequently asked questions