A.5.33 Protection of records: requirements and evidence

What A.5.33 protection of records asks for and why auditors test it

A.5.33 asks the organization to protect the records it must keep from five threats: loss, destruction, falsification, unauthorized access and unauthorized release. For a compliance lead, the practical question is not whether a retention policy exists but whether the organization can show, for each category of record, where it lives, who can touch it, how its integrity is checked and when it is lawfully disposed of. The control carries forward control A.18.1.3, Protection of records, from the 2013 edition of ISO/IEC 27001, so organizations that certified under the older standard will recognize the intent, although the 2022 wording and attributes differ. Auditors test this control because it sits where security, legal and operational obligations meet, and a gap in any one of them shows up quickly in a records sample.

Records are hard to pin down for three reasons. First, they are scattered: contract records sit in a document management system, financial approvals in an ERP, access logs in a SIEM, and backups in a separate backup platform, often with no single register. Second, retention and disposal pull in opposite directions. Legal, regulatory and contractual duties may require a record to be kept for a set period, while data minimization and privacy duties may require it to be deleted once it is no longer needed. Third, the records that matter most for evidence, such as logs and approval trails, are often the ones administrators can alter. An auditor will usually ask for one record type, trace it from creation to disposal, and check the access and change history along the way.

The first decision is to define the records register: the record categories, their owner, the retention period and its legal basis (for which A.5.31 is the link), the storage location and the disposal method. Confirm with legal counsel how each period was set, because an auditor will ask for the source. The second decision is to choose which integrity and access controls apply to each category, for example immutable storage, restricted write permissions or hashing of exported records. Before the assessment, pick two or three record types, trace each one through the register and collect the access, backup verification and disposal evidence for it. Gaps found at that stage are far cheaper to close than gaps an assessor finds.

Which records and systems fall under protection of records scope

A.5.33 applies to every record the organization must keep, wherever it lives. The scoping choices below determine which record types, systems, backups and hosted services the protections must cover, and each one changes the evidence an assessor will ask for.

Record types the law or contracts require

Start with the records you must keep: financial ledgers, tax files, employment records, signed customer contracts and service agreements. Under A.5.31, many retention duties come from statute or contract, so the register of obligations is the input for this scope. Confirm for each record type who owns the retention period, how long it runs, and whether the obligation comes from a regulator, a contract or an internal policy.

Customer and personal data records

Customer records and personal data often sit in several places at once, such as the CRM, support tickets and billing exports. Where they include personally identifiable information, A.5.34 also applies, so retention and deletion rules must match privacy obligations as well as record-keeping duties. Check whether each copy is in scope, because a record kept only for a legal hold is treated differently from one kept for operations.

Security logs and audit trails

Logs from identity systems, administrative actions and security tools are records in their own right, and they are often the first evidence sought after an incident. Decide which log sources are retained as records, where they are stored, and who can alter or delete them. Logging controls under A.8.15 supply the events, while A.5.33 governs whether they stay complete, unaltered and available for the agreed period.

Backups and restore points

Backups hold copies of every record class above, so the protection scope must include them, not only the primary systems. Confirm which backup sets are kept for long-term retention, whether they are encrypted, and whether restore tests verify that the stored data is unmodified. Bareos and restic both maintain catalogs or integrity checks that can serve as evidence, but you must confirm how each one is configured in your environment.

Records held by third-party hosts

Records stored in SaaS platforms, cloud storage or outsourced archives remain the organization's responsibility, even though the provider runs the infrastructure. Under A.5.23 and A.5.20, contracts must define how records are retained, exported, deleted and returned at exit. Ask each provider where copies live, how long they persist after deletion, and what evidence of retention and disposal you can obtain.

Records covered by legal holds

Some records must be preserved beyond their normal retention period because of litigation, investigation or regulatory inquiry. Identify which systems can apply holds, who may place or lift them, and how holds interact with scheduled disposal. Assessors commonly test whether a hold actually stops deletion in every location where the record exists, including backups and hosted copies.

How an assessor tests protection of records

This table walks through how an assessor approaches A.5.33 from document review to hands-on checks of storage and restores, with the evidence each step asks for. Read it as a test plan: the middle rows show what the assessor samples, and the final row lists the gaps that most often turn into nonconformities.

Test step	What the assessor does	Evidence requested
Document review	Reads the records retention schedule, classification rules and disposal procedure to see which record types are covered and who owns them	Approved retention schedule with record categories, owners, retention periods and legal basis, plus the version history
Scope check against obligations	Compares the schedule with the legal, regulatory and contractual requirements the organization has recorded under A.5.31	Register of applicable obligations mapped to specific record categories and their keep periods
Sampling against the schedule	Picks records from several categories and checks whether they exist, are held where the schedule says, and are not kept past their disposal date	Repository listings, system exports or file indexes for the sampled categories, with dates and locations
Access and release controls	Checks who can read, change or delete sampled records and whether access matches the owner's approvals	Access rights reports, approval records and logs showing reads, edits and deletions of protected records
Integrity and falsification	Looks for mechanisms that show a record was not altered, such as versioning, checksums, write-once storage or audit trails	Audit log samples, hash or checksum records, change history and documented exceptions
Storage and backup restore	Observes a live restore of selected records from backup and confirms the restored content matches the original	Restore job records, verification output and a dated note of who performed and checked the restore
Disposal	Verifies that records past retention were destroyed or archived under the procedure, and that destruction left a record of the action	Disposal log, destruction certificates or system deletion reports, and approvals for any legal hold
Common finding: schedule not applied	Schedules exist and are approved, but sampled records are kept indefinitely, held in unapproved locations or missing from the schedule	Gap between the schedule and the sampled records, with no owner follow-up or exception record

How to implement record protection step by step

The sequence below moves from knowing which records exist to proving they can be retained, found, trusted and disposed of on schedule. Each step produces an artifact an assessor can sample against A.5.33 Protection of records.

Inventory records and assign owners
Identify every category of record the organization must keep, including financial, contractual, HR, security log, incident and customer records, and the systems or locations where each lives. Record a named owner for each category, who answers for its accuracy, access decisions and eventual disposal. Finish when the inventory lists each record category, its location, its owner and its business purpose, and the owners have confirmed their entries. This inventory should align with the asset inventory under A.5.9 Inventory of information and other associated assets, so the two do not drift apart.
Set retention and disposal rules with legal input
For each record category, define how long it must be kept and what triggers the start of that period, such as contract end or account closure. Legal, compliance and privacy staff should confirm the periods against statutory, regulatory and contractual requirements, which is the scope of A.5.31 Legal, statutory, regulatory and contractual requirements. Where records contain personal data, the privacy requirements under A.5.34 Privacy and protection of PII also apply. Finish when a approved retention schedule exists, signed by the record owners and legal counsel, with a documented disposal method for each category and a legal hold process for records under investigation or litigation.
Define storage and access controls
Decide where each record category is stored and who may read, change, export or delete it. Apply the access control policy and access rights rules to these stores, so that access follows the owner's decision and is removed when roles change. Protect records at rest and in transit with encryption and separate write-once or restricted storage for records that must not be altered. Finish when each record store has a documented access list tied to its owner, the permissions are configured to match it, and a sample of accounts has been tested to confirm that unauthorized users cannot read or modify the records.
Enable audit logging on record systems
Turn on logging for the systems that hold records so that creation, access, modification, export and deletion events are captured with user, time and object. Send logs to a location that the record administrators cannot silently edit, and confirm retention of the logs themselves matches the retention schedule. This step links the record store to the logging controls in A.8.15 Logging. Finish when a test action on a record appears in the log with the expected detail, and log access is restricted to a defined group.
Add integrity checks and backup verification
Protect records against silent corruption and falsification by recording checksums or hashes for records or their storage units at intake, and by verifying them on a schedule. Back up record stores as part of the backup controls under A.8.13 Information backup, and test restores, not only backup completion. Open-source backup and integrity tools can produce this evidence, for example Bareos for scheduled backup, restore and verify jobs with a catalog of backed-up files, or restic, whose check command with read-data options reads pack files back to confirm stored data is unmodified. Finish when a restore of a sampled record has been performed, the restored file matches its recorded hash, and the verification output is kept as evidence.
Document and run the disposal process
When a record reaches the end of its retention period and no legal hold applies, dispose of it using the method set in the schedule, such as secure deletion for electronic records or certified destruction for physical media. Remove copies from backups according to the backup retention rules, and record what was disposed of, when, by whom and under which schedule entry. Disposal of storage media is also governed by physical controls, so coordinate with the media handling procedures. Finish when a disposal log exists, a sample disposal can be traced from the schedule entry through the log to the confirmed removal, and the owner has signed off each batch.
Review the schedule and test the sequence
At planned intervals and after significant changes to laws, systems or business activities, review the inventory, retention schedule, access lists and disposal logs with the record owners and legal staff. Test a full path for at least one record category, from intake through access review, backup restore and disposal, and record the findings. Feed any gaps into the management system's corrective action process. Finish when the review record shows the schedule and inventory were confirmed or updated, and the test results and follow-up actions are documented. Ask your auditor which sample sizes and evidence periods they expect before the review is scheduled.

Retention schedules and integrity checks that make records defensible

A retention schedule is the document that turns A.5.33 from a principle into a decision the organization can defend. For each record type, it should name the owner, the legal, statutory, regulatory or contractual duty that sets the minimum period (the scope of A.5.31), the point at which retention starts, and the disposal method and approver at the end. Privacy limits cut the other way: where a record holds personal data, A.5.34 and the applicable privacy law may require deletion once the purpose has lapsed, so the schedule must record both the minimum and the maximum. Every retention period should trace back to a named obligation, and every personal data category should carry a documented end date. Confirm the periods with legal counsel and the relevant contracts, since no general period applies across sectors or jurisdictions.

Integrity evidence is what lets an assessor accept that records were not falsified after they were written. Two kinds of artifact do most of the work. The first is verified backups: a backup is only evidence of recoverability if it is tested. Bareos keeps a SQL catalog of backed-up files and can restore from the current backup or one taken before a given date and time, which gives a documented restore history. restic's check command verifies the structure of snapshots, trees and pack files, and with --read-data or --read-data-subset it reads pack files back to confirm the stored data is unmodified. Scheduled, logged restore tests for a sample of record classes are the evidence an auditor will ask to see. The second is tamper-evident logging: Nextcloud's admin_audit app writes event detail to audit.log, and OpenBao's audit devices record every API request and response in JSON with most sensitive values hashed using HMAC-SHA256. Ask the implementation partner to show where these logs are stored, who can alter them, and how their integrity is checked, because a log that the administrator can rewrite is weak evidence.

Before relying on any of this, confirm three things in your own environment: that the retention schedule matches what each system actually keeps, that restore and read-back tests have run recently with results on file, and that disposal, including deletion from backups, is recorded and approved. The NIST crosswalk from SP 800-53 Rev. 5 to ISO/IEC 27001:2022 relates A.5.33 to backup, audit information protection and cryptographic protection controls, which gives a useful checklist of the technical side. Your auditor, not the tooling, decides whether the evidence is sufficient, so agree the sampling approach and evidence list with them early.

Evidence that passes a protection of records review

An assessor testing A.5.33 samples a small set of records and then asks for proof that protection worked over time, not only on the day of the audit. The cards below cover the artifacts that answer those questions and how to keep each one current between certification audits, since the certification cycle includes at least one audit every calendar year.

Retention schedule

The schedule lists each record type the organization must keep, the legal, contractual or business reason for keeping it, the retention period, the owner and the disposal trigger. Assessors check that it matches the obligations recorded under A.5.31 and that the schedule was approved by someone accountable for the records. Review it at least once a year and whenever a new regulation or customer contract adds a keeping duty. Confirm each period with legal counsel rather than copying a figure from a template.

Record inventory

An inventory maps each record series to where it lives, such as a document store, ticketing system, database or backup set, and who can access it. Auditors compare a sample of inventory entries against the systems themselves to find records held outside the schedule. Keep it current by tying new systems to the change process so that no store goes live without an inventory entry.

Access reviews on record stores

Records are only protected if the people able to read, change or delete them are known and justified. Export the access list for each record store, compare it against the roles named in the schedule, and record who approved each grant and removal. Run the review on a fixed cadence and keep the signed output, because assessors often sample these reviews alongside the access rights controls under A.5.18.

Backup and restore test results

A backup is evidence of protection only when a restore has been tested. Keep the job logs, the restore test records showing which records were recovered, the time taken and any failures with their fixes. Bareos keeps a catalog of backed-up files and can restore files from a backup taken before a given date and time, which helps demonstrate point-in-time recovery. Schedule restore tests so that every record class is covered over the cycle.

Integrity verification outputs

Integrity checks show that stored records have not been altered or corrupted. For backup repositories, restic check verifies the structure of snapshots, trees and pack files, and with --read-data or --read-data-subset it reads pack files back to confirm the stored data is unmodified. Keep the command output, the date, the repository identifier and the action taken on any error. Run the read-data check on a schedule and document the subset rotation so the coverage is provable.

Audit log samples

Logs show who touched a record and when, which supports both protection against falsification and the logging control under A.8.15. Nextcloud's admin_audit app writes event details to audit.log in the data directory or to a path set with logfile_audit, and OpenBao audit devices keep JSON records of API requests and responses with most sensitive values hashed. Pull dated samples from each store, confirm that log files are protected from editing, and keep them with the retention period set for the logs themselves.

Disposal certificates

When a record reaches the end of its retention period, the disposal record proves it was removed on schedule and not kept or leaked. Keep the approval, the list of records destroyed, the method used, the date, and for backups the expiry or pruning run that removed them. Confirm with the owner that no legal hold applies before disposal. Between audits, reconcile disposal logs against the schedule each quarter so gaps are found by the organization first.

What meeting A.5.33 costs in money and effort

This table breaks the cost of protecting records into components, showing who is paid for each, whether it is one-time or recurring, and what drives it up or down. No figures are given because none were supplied; use the questions in the final column when requesting quotes. The main takeaway is that most of the recurring cost sits in evidence upkeep and periodic restore testing, not in the tools themselves.

Cost component	Who is paid or who spends effort	One-time or recurring	What drives it and what to ask for in a quote
Backup and archive tooling or licenses	Software vendor or open-source project; self-hosted open-source options such as Bareos (AGPL-3.0-only) and restic (BSD-2-Clause) carry no license fee	Licensing: one-time or annual; open source: none	Commercial licenses scale with data volume or hosts. Ask whether the quote includes support, and whether the product is open source with an optional support contract
Engineering time to build backup, retention and integrity checks	Internal platform team or implementation partner, billed by scope	One-time	Number of record systems, retention rules and storage targets. Ask for the work broken into systems and deliverables, with the integrity checks named
Legal and records management time for the retention schedule	Internal legal, compliance or records staff; outside counsel if needed	One-time, then periodic review	Number of applicable laws, regulations and contracts (linked to A.5.31). Ask who signs off on each retention period and how often it is reviewed
Storage and infrastructure for retained records	Cloud provider, data center or internal infrastructure team	Recurring, usually scaling with volume	Retention length, immutability requirements and copy count. Ask for the storage cost model and the expected growth of retained data
Restore and integrity testing	Internal operations staff or implementation partner	Recurring, at planned intervals	Frequency of restore tests and the share of data read back during checks. Ask what evidence each test produces and who keeps it
Evidence upkeep	Internal compliance or security staff	Recurring	Number of record types, change frequency and log retention. Ask how evidence is stored, indexed and made available to the auditor
Disposal and destruction of records at end of retention	Internal IT, or a certified destruction vendor for physical media	Recurring, per disposal cycle	Volume of expired records and presence of physical media. Ask for destruction certificates and how they are kept
External review and auditor sampling	Independent auditor or certification body, which issues the findings; internal staff prepare samples	Recurring, at each audit cycle	Audit scope, number of record types sampled and the number of sites. Ask the certification body for its audit plan and sampling approach before committing to a scope
Outside implementation support	Implementation partner, paid under a written fixed-scope agreement	One-time, with optional retainers for upgrades and testing	Scope of systems, number of integrations and whether the partner handles only preparation. The partner prepares systems and evidence; it does not issue audit reports or certificates

Who owns record protection and what a partner can prepare

Your organization owns the control. Only you can decide which records the business, regulators and contracts require you to keep, how long each category must be retained, and who is accountable for each record set. An implementation partner can draft a retention schedule for review, but the decisions and the sign-off stay with named owners inside the organization, and the auditor will ask who made them and when.

Retention decisions: Approve the retention schedule by record category, tied to legal, regulatory and contractual requirements (see A.5.31).
Record owners: Name an owner for each record set who answers for its accuracy, access and disposal.
Disposal approval: Require documented approval before any record is destroyed, and keep the destruction log.
Legal holds: Decide when retention rules are suspended for litigation or investigations, and who lifts the hold.
Review cycle: Confirm the schedule still matches obligations each time a law, contract or system changes.

Before any engagement starts, confirm in writing which of these decisions your staff will make and which you will delegate, because an auditor will test the people named in the schedule, not the partner.

An implementation partner prepares the systems and evidence that protect records. This usually means configuring backup, integrity checking, audit logging and access restrictions on the self-hosted platforms that hold records, then documenting how each one works. The partner does not decide what must be retained and does not issue any assessment result. Its deliverables are configurations, runbooks and evidence packs that your team owns after handover.

Backup and restore: Configure backup jobs, catalogs and restore tests, for example with Bareos, so records can be recovered to a defined point in time.
Integrity checks: Schedule repository verification with restic check --read-data-subset and retain the results, so you can show stored data has not been altered.
Audit logging: Enable logs such as Nextcloud's admin_audit app writing to audit.log, and forward them to a location that the record owners cannot edit.
Access restrictions: Implement role-based access and document it against the access rights controls.
Evidence packs: Prepare dated test restores, verification output and configuration exports for the auditor to sample.

Ask the partner to state its roles in writing, to name the artifacts it hands over, and to confirm that it will not sign or attest to any control on your behalf.

Common gaps in record protection and how to close them

Records usually fail A.5.33 not because no one wrote a retention rule, but because the rule, the backup, or the integrity check never runs against the systems where records actually live. The cards below cover the gaps assessors most often find and a practical fix for each, so the organization can show the protection works in operation.

Backups that have never been restored

A backup job reporting success proves little about whether records can be recovered. Auditors look for restore tests that pull a sample of records back from backup and compare them with the source. Schedule restores for each record class, record who ran them and what was compared, and keep the results. With Bareos, the restore and verify jobs and the SQL catalog give a traceable starting point, so confirm each restore test is written down rather than assumed.

Retention rules that nothing enforces

A retention schedule in a policy document does not delete anything. Records keep piling up in file shares, mailboxes and application databases past the period the organization set, which weakens both disposal and protection. Map each schedule entry to the system that holds it, configure the deletion or archive mechanism there, and log each disposal. Confirm which legal and contractual minimums in A.5.31 set the periods, since a shorter internal rule can conflict with them.

Records in unmanaged SaaS and personal devices

Records often sit in chat tools, personal cloud drives, spreadsheets on laptops and vendor portals that the security team never inventoried. These copies fall outside backup, access review and disposal. Start from the asset inventory in A.5.9 and ask each business owner where their records actually go. Bring the high-value stores under managed accounts, restrict personal storage for regulated records, and check that cloud contracts state who can export and delete data under A.5.23.

No integrity evidence for stored records

Protection against falsification needs proof that stored records have not changed without authorization. Many systems keep no hash, signature or audit trail for documents once saved. Where records must be defensible, store checksums or use a repository that verifies its data. restic's check command with the read-data option reads pack files back to confirm stored backup data is unmodified, which gives an assessor a repeatable test. Confirm the check runs on a schedule and that failures generate a ticket.

Access and change history not kept

When a record is altered or released, the organization must be able to show who did it and when. Applications often log reads only at a coarse level, or rotate logs before the retention period ends. Enable audit logging for systems holding regulated records, send it to protected storage, and set the log retention to match the records it describes. Nextcloud's admin_audit app writes to audit.log, and the log path should be checked against the backup scope so the trail survives a failure.

Unrestricted release of sensitive records

Records are released through exports, shared links, email attachments and API keys that outlive the need for them. Unauthorized release is one of the four risks A.5.33 names, so access to bulk export and sharing features should follow the same rules as access to the records. Review who holds export rights, expire external shares, and rotate the secrets that let systems pull records. Where secrets are stored in a vault, OpenBao's audit devices record each API request and response with sensitive values hashed, which supports this review.

Questions buyers ask about A.5.33 cost, effort and outside help

How much effort does protecting records under A.5.33 take?

The effort depends on how many record types the organization must keep, how many systems hold them, and whether retention rules already exist. No supplied figure gives a standard duration, so treat any number a consultant quotes as an estimate tied to a written scope. Most of the work is one-time: listing record types, agreeing retention periods with legal and business owners, and configuring storage, backup and deletion. Recurring effort is smaller but steady: reviewing retention schedules, checking backup restores, and reviewing access to record stores. Ask any provider to break its estimate into these phases and to state which systems and record types are in scope.

What does the organization have to provide before any outside help starts?

The organization owns its records, retention decisions and controls, so it must supply the inputs that only it knows. These include a list of record types and where they live, the legal, statutory, regulatory and contractual retention obligations that apply under A.5.31, named owners for each record class, and access to the systems that hold records. It also needs to decide who approves retention periods and disposal. Without these inputs, an implementation partner can build storage and backup, but it cannot decide what must be kept or for how long.

Can we protect records in-house without an implementation partner?

Yes, an in-house team can do this if it has someone who understands both the record obligations and the systems that store them. Open-source tools can cover parts of the evidence. For example, Bareos keeps a catalog of backed-up files and restores files from a chosen point in time, and restic's check command with read-data options reads pack files back to confirm stored data is unmodified. Nextcloud's admin_audit app writes audit events to a log file, and OpenBao audit devices log API requests with sensitive values hashed. The in-house team should confirm each tool's capabilities against its own environment before relying on it.

What does an implementation partner add to A.5.33 work?

An implementation partner prepares systems and evidence. DeployOpen, for example, plans, implements, configures, hardens and documents self-hosted platforms inside the client's own infrastructure, so backup, logging and access settings can be built and written down in a way an assessor can follow. The partner does not own the retention decisions and does not issue audit reports or certificates. Independent certification bodies do that. Most engagements are fixed-scope, so ask for the scope, deliverables and timeline in writing before work starts.

What recurring costs should we expect after the controls are in place?

Recurring costs are the work that keeps records protected over time. They include running backup jobs and verification, storage capacity, periodic restore tests, reviewing retention schedules when laws or contracts change, and reviewing record access. If a partner supports the platform, ask whether that support is offered as a retainer and what it covers, including upgrades and documentation updates. Certification bodies also charge for surveillance audits, which fall in the three-year cycle under ISO/IEC 17021-1. Ask certification bodies for their fee schedule in writing, since DeployOpen does not publish prices and any figure must come from a quote.

How does the auditor treat records evidence for A.5.33?

An auditor usually samples records and checks that the protection rules were applied in practice. Expect requests for the retention schedule, the disposal approvals, backup and restore test results, integrity check outputs, and access logs for record stores. The auditor will compare these documents with the systems themselves, so a schedule that does not match actual deletion behavior is a finding. Evidence must also show who approved each rule and when it was last reviewed. Ask your certification body which samples it will take and how far back the evidence must go.

What is the biggest cost driver for records protection?

The largest driver is usually the number of record types with different retention and legal requirements, since each type needs its own rule, storage path and disposal method. Other drivers include how many systems hold records, whether backups and archives must be verified, and whether records cross jurisdictions with different retention or privacy rules. A narrow scope covering a few well-understood record types costs far less to evidence than a broad scope across many legacy systems. Ask any provider to price each record class separately so you can see what drives the total.

How DeployOpen prepares protection of records evidence

DeployOpen scopes the work in writing before any system is touched. The scope names which record sets are in play (for example, financial ledgers, HR files, contracts, audit logs and customer data), where each set lives, which self-hosted platforms hold it, and what must be demonstrated for each. DeployOpen then configures and documents those platforms inside the client's own cloud accounts, data centers or air-gapped networks. Typical work covers backup jobs and restore tests, retention and disposal settings, audit logging and integrity checks. Those are the technical building blocks an auditor will ask about under A.5.33, but they are not the control itself.

DeployOpen does not issue audit reports, attestations or certifications. Only an independent auditor or accredited certification body can test the control and issue a conclusion. The organization also owns its controls: it decides its retention periods, its record classification, who may approve disposal and who may release records to third parties. A retention schedule that the legal, finance or compliance owner has not signed off is not evidence of anything, whatever tooling sits behind it. Before work starts, confirm with your auditor which records and retention rules they expect to see, and make sure the written scope reflects those decisions.

Ask any implementation partner for a written list of the evidence each configured platform will produce, who receives it and how often it is reviewed. For records protection, that usually means restore test results, integrity verification output, access and change logs, and disposal records with approvals. Confirm with the platform documentation which settings and log destinations apply to your versions before relying on them, and agree in the scope which party retains the evidence after handover. Retained evidence, reviewed on a schedule the organization owns, is what allows the internal audit and the external assessor to sample the control over time.

A.5.33 Protection of records