A.8.10 Information deletion: requirements and evidence

What A.8.10 information deletion asks for, and why it is hard

A.8.10 Information deletion asks the organization to delete information held in information systems, devices and other storage media when that information is no longer required. An auditor or customer who asks how you delete data you no longer need is testing whether you have decided what to keep, for how long, and how you remove it afterward, and whether you can show that removal happened. The control is one of the 11 controls that were new in the 2022 revision of Annex A, so it has no counterpart in the 2013 edition, and organizations that certified under 2013 will meet it for the first time in their 2022 audit.

Retained data widens the impact of a breach and the scope of privacy exposure. Every copy of a customer record that survives past its purpose is one more place an attacker can reach and one more record a regulator may ask you to account for. The control is hard because data rarely sits in one place. It is copied into backups, application and audit logs, test environments, exports, shared drives and SaaS tools that nobody has inventoried. A deletion process that clears the production database can leave the same data in a backup set kept for years or in a log file that is never rotated.

Start by confirming who owns retention decisions and where they are written down, then build a map of every system and provider that holds the data classes in scope. Ask your backup and logging teams how long copies persist and whether deletion reaches them. Check that the tools in your environment can actually remove what your rules say should go. The gap between the retention policy on paper and the data that remains in these copies is usually where an auditor will focus.

Which systems, data and third parties fall under information deletion

A.8.10 applies wherever information is stored, so the first job is an inventory of every place it lives. The cards below separate six areas where the scoping decision changes the deletion work, and each one marks a boundary with a neighboring Annex A control.

Production data stores

Databases, object stores, file shares and application caches are where the deletion rules are usually enforced. Decide which data classes have a defined end of need, who owns each retention period, and whether deletion is a scheduled job, a user-triggered action or a request-driven process. Check that soft-deleted records, indexes and search replicas are removed too, not only the primary row. Information about individuals also touches A.5.34 Privacy and protection of PII.

Endpoints and removable media

Laptops, phones, USB drives and decommissioned disks keep copies of information outside central systems. Decide whether deletion happens at reassignment, at offboarding or only at final disposal, and whether removable media is deleted or physically destroyed. Equipment disposal and reuse is governed by A.7.14 Secure disposal or re-use of equipment, so the two controls must agree on who signs off each wipe.

Backups and archives

Backups hold copies of data that production has already deleted, so they are the hardest scope decision. Decide whether backup copies are in scope for deletion timing, whether they expire on their own retention schedule, and how a restore after a deletion request is handled so deleted data does not return. Confirm this with the owner of the backup policy under A.8.13 Information backup. Bareos keeps a catalog of backed-up files, which helps locate copies for expiry.

Logs and audit trails

Logs record personal data, identifiers and sometimes content, and they are often kept longer than the systems they describe. Decide how long each log class must be kept for security or legal purposes, and whether personal fields are removed or masked before the retention period ends. Keeping logs for investigation can conflict with deletion, so record the justification for each retention period. Nextcloud's admin_audit app writes to a file set with logfile_audit, which shows where such records accumulate.

Test and analytics copies

Copies of production data made for testing, reporting, analytics or machine learning are easy to forget because they sit outside the system of record. Decide who may create them, whether personal data is masked first, and when each copy is deleted after its purpose ends. A.8.33 Test information covers the test side of this boundary, and the copies must appear in the same inventory as production stores.

SaaS and cloud providers

Providers that store or process information for the organization hold copies under their own retention and deletion processes. Ask each provider how deletion is performed, how long deleted data remains in backups, what evidence of deletion they supply, and how deletion is triggered when the contract ends. The contract should state these duties, and the supplier relationship is governed by the supplier controls in the organizational theme.

How an assessor tests information deletion

This table compares what an assessor does, what they ask you to produce and the findings that most often cause trouble for A.8.10. Read it as a checklist: if your retention schedule, deletion records and provider evidence cannot answer the requests in the middle column, expect a finding in the right column.

Test area	Evidence requested	Common findings
Retention schedule against data inventory	Retention schedule, data inventory or map of systems holding personal and business information, and the owner for each data category	Retention rules exist but some data stores appear in the inventory with no rule attached
Retention rules have named owners	Approval record and named owner for each retention rule, with the date it was last reviewed	Rules with no owner, or owners who have left the organization and were never replaced
Sampling records and tracing to deletion	A sample of records past their retention period, traced to a logged deletion event in each system where they reside	Records are removed from the application but copies remain in exports, reports, file shares or logs
Deletion reaches backups and replicas	Backup and replica retention settings, plus a documented method for how deleted data ages out of backups	Deletion stops at the primary database while older backups or read replicas keep the same data indefinitely
Deletion by service providers	Contract clauses, provider deletion procedures and written confirmation of deletion at end of service or on request	No proof of deletion from a cloud, SaaS or outsourced provider, only a verbal assurance
Deletion records exist and are protected	Deletion logs or tickets showing what was removed, when, by whom and under which rule, with restricted access to the logs	Deletion happens but leaves no record, or logs can be edited by the same administrators who ran the deletion
Test data and media disposal	Procedure for removing copies used in testing and for sanitizing storage media before reuse or disposal	Production data copied into test environments is never identified or removed after testing

Implementing information deletion in six steps

This sequence turns A.8.10 from a policy statement into a working deletion process, with each step producing an artifact that an assessor can trace from the retention rule to the deletion record. Work through it in order, because later steps depend on the inventory and retention decisions made earlier.

Inventory data stores and copies
Map every system, database, file share, backup set, log store, SaaS tenant, endpoint and removable medium that holds information, including copies created for testing, analytics and support. The owner of each system confirms what it holds and who the data belongs to. The output is an information inventory that lists each store, its data classes, its business owner and its technical custodian. The step is complete when the system owners have signed off the list and no known store is missing from it.
Set retention periods per data class
Group the inventoried information into data classes, then set a retention period for each class with input from business owners, legal counsel and the data protection lead. Record the legal or contractual basis for each period and the trigger that starts the clock, such as contract end or account closure. The output is a retention schedule approved by management. Ask whether the schedule covers legal holds, because a hold can suspend deletion that would otherwise be due.
Choose deletion methods per media and system type
Decide how each store is deleted, since a delete command, cryptographic erasure, overwriting and physical destruction leave different residues. Match the method to the medium, for example by checking whether encryption keys can be destroyed for a given store or whether a flash device needs a different approach from spinning disks. Confirm with each platform vendor how its deletion actually works, including whether replicas, snapshots and caches are removed. The output is a deletion procedure per system type that names the method, the tool or command, and the verification step.
Build deletion into workflows and provider contracts
Turn the retention schedule into automated or ticketed deletion steps in the systems that hold the data, such as scheduled purge jobs, account closure runbooks and offboarding checklists. Where a service provider or hosting party holds information, write deletion obligations, timelines and certificates of deletion into the contract, and confirm how backups held by that provider are handled. The output is a set of configured jobs, runbooks and contract clauses. Check that each trigger in the retention schedule has a matching workflow that someone owns.
Run and record deletions
Execute deletions through the approved procedure and record each one in a deletion log that captures the store, the data set, the date, the method, the operator or job identifier, and the result of the verification check. Keep the log itself protected and retained for the period an assessor will need to see it. Where logging for the platform is in place, use the platform's audit records to corroborate the entry. The output is a deletion log that shows deletions happened as the schedule required, including the exceptions and holds that delayed them.
Review the schedule and the evidence on a set cycle
Review the retention schedule, the deletion methods and the provider contracts on a defined cycle and after significant changes such as new systems, mergers or changes in law. Sample deletion log entries against the systems to confirm the data is gone and that backups and replicas follow the same rules. Feed findings into the risk register and the management review. The output is a dated review record with the actions raised and their owners. Confirm with your certification body or auditor how often they expect this review to occur for your scope.

Evidence that shows deletion actually happened

A.8.10 is tested through records, not intentions. The six artifacts below connect the rules that say what to delete, the inventory that says where it lives, and the logs and confirmations that show it was removed. Keep each one current between audit cycles so the evidence reflects how deletion works today.

Retention schedule with owners

The retention schedule lists each information category, its retention period, the trigger that starts the clock (for example, contract end or account closure), the deletion method and the named owner. Each entry needs an approval record from the business owner and, where personal data is involved, legal or privacy sign-off. Between audits, review it when products, contracts or regulations change and record the date and approver of every revision.

Data inventory mapped to retention rules

The inventory maps each store, such as databases, file shares, backups, mailboxes and SaaS tenants, to a retention rule and an owner. Assessors use it to test whether a deletion rule covers every place the information actually sits. Reconcile it against the asset register and cloud account lists at least as often as your change process runs, and flag stores that have no rule assigned.

Deletion procedures by method

Write one procedure per deletion method: logical deletion in an application, secure overwrite or cryptographic erasure on storage media, and removal from backups as they expire. Each procedure states the tool or command used, the person authorized to run it, and how success is verified. Confirm with each platform's documentation which deletion methods it supports, since capabilities differ between applications and storage layers.

Deletion logs and tickets

Deletion records should show what was removed, when, by whom, under which retention rule and with what scope. Nextcloud's admin_audit app writes audit events to audit.log in the data directory, or to a path set with logfile_audit, which can support file-level activity records. OpenBao audit devices keep a JSON log of API requests and responses with most sensitive values hashed with HMAC-SHA256. Confirm that each log captures deletion events and that retention of the logs themselves is defined.

Backup catalog and restore checks

Deletion has to reach backups, or retained copies will hold data after its deadline. Bareos keeps a SQL catalog of backed-up files, which lets you query what exists in backup sets and check expired data against the retention rule. restic check verifies the structure of snapshots and pack files and can read data back to confirm integrity, which supports backup governance. It does not by itself prove that expired information was removed, so pair it with catalog queries and expiry records.

Provider deletion confirmations and contract clauses

When a cloud, SaaS or managed service provider holds your information, the contract should require deletion at end of service and a written confirmation with the scope and date. Collect those confirmations and file them against the supplier record. Check that the contract specifies deletion timing, backup treatment and what the provider reports. Ask providers for their deletion attestation process before you rely on it, because the assessor will test your oversight of that supplier.

How deletion works with backups, archives and copies

Deleting information from a production system does not, by itself, satisfy A.8.10 Information deletion. The same data often survives in backups, archives, replicas, analytics extracts and test sets, and an assessor will expect the organization to know where those copies are and how they age out. The practical decision is whether backup retention is aligned with the deletion rule. If production data must be removed after a defined period, the backup policy must either expire copies on a comparable schedule or document why it cannot. Retention periods themselves are a business and legal decision, set in the policy rather than borrowed from a tool's default.

Organizations usually document a small set of options. The first is to align backup retention with the deletion rule so that backup sets containing a record expire within an agreed window. The second is to expire backups on schedule through automated pruning, so that expiry is a routine job with logs rather than a manual task. The third is a restore-then-delete rule: when data is restored for a recovery or investigation, the restored copy is removed once its purpose ends, and the restore is recorded. The fourth is a documented exception for backups that are immutable or cannot be altered without breaking recovery. Such exceptions should name the data, the reason, the compensating control and the date the copy will age out.

Bareos is the place to confirm this in practice. Check the retention settings on the pools and clients, how the catalog records volumes and file entries, and whether pruning removes catalog records and volumes as expected. In restic, confirm how snapshots are forgotten and when restic prune actually reclaims pack files, since forgetting a snapshot does not necessarily remove the data it referenced until pruning runs. The organization must test these behaviors in its own configuration with a known test record, then keep the result as evidence. Vendor defaults and documentation describe intent, not the environment in which the policy will run.

What meeting A.8.10 costs in money and effort

This table breaks down the cost components of meeting A.8.10 Information deletion, who is paid for each one, whether it is one-time or recurring, and what drives it up or down. No prices or durations are stated because the total depends on how much data sprawl the organization has and how many service providers hold its information. Use the table to frame a fixed-scope quote with written deliverables.

Cost component	One-time or recurring	What drives it	How to keep it down
Data inventory and retention schedule work	One-time, then periodic review	Number of systems, repositories, backups and copies holding personal or sensitive information	Start from systems that hold the most sensitive data and extend the inventory in stages
Legal and business input on retention periods	One-time, then on change	Number of applicable laws, contracts and business purposes that set how long data may be kept	Ask legal to record periods per data category once, and reuse the schedule for new systems
Engineering time to build deletion jobs	One-time build, then maintenance	Number of data stores, custom applications and whether deletion must reach backups and derived copies	Prefer deletion built into existing platform features before writing custom scripts
Service provider deletion processes	One-time setup, then per contract review	Number of external providers and whether each contract defines deletion timing and certificates of deletion	Standardize deletion clauses and request deletion evidence in the contract template
Tooling licences	Recurring if commercial	Choice of commercial versus open-source tools for backup, logging and secrets handling	Self-hosted open-source tools such as Bareos, restic, Nextcloud and OpenBao remove licence spend, but not the engineering time to configure and run them
Evidence upkeep	Recurring	How often deletion runs, how many systems produce logs, and how many exceptions need records	Automate job logs and retention reports so evidence is produced by normal operation
External review or testing of deletion	Periodic, optional	Scope of systems tested, whether deletion of backups is verified, and whether a third party tests it	Agree the test scope in writing and limit it to the highest-risk stores at first
Auditor sampling time	Recurring at each audit	Number of samples the auditor selects and how easily records can be retrieved for each sample	Keep deletion records indexed by system and date so samples can be produced quickly

Who owns deletion, who can help, and what the auditor does

Your organization owns the control. Only you can decide how long each category of information is needed, which legal or contractual holds override a deletion date, and who approves an exception. Data owners, usually business leads who understand why a dataset exists, should confirm retention periods for their systems, and the security or compliance function should record those decisions in a retention schedule that auditors can read. Your team also runs the deletion log, the record that shows what was removed, when, by which job or person, and under which rule.

Retention decisions: Data owners set and approve retention periods, with legal input where regulation or contracts apply.
Exception approval: Holds, extended retention and early deletion requests are signed off by a named role, never by the people doing the work.
Deletion log: Someone in your team reviews deletion records on a set cadence and investigates gaps.
Supplier terms: Your contracts should state how cloud and SaaS providers delete data at end of service.
Sign-off: Management reviews the retention schedule and deletion results as part of ISMS review.

Confirm that every system holding customer or employee information appears in the retention schedule with a named owner.

Where deletion programs usually fall short

Most deletion programs fail in the places where copies accumulate outside the system of record: backups, test data, vendor platforms and manual workarounds. The cards below name six recurring gaps under A.8.10 Information deletion and the closing action for each. Work through them against your own inventory of systems and storage media.

Retention rules exist only on paper

A retention schedule in a policy document does not delete anything. Check whether each information category has a retention period that a system actually enforces, such as a scheduled purge job, a lifecycle rule or an application setting. Ask the system owner to show the setting and the last time it ran. Where no technical enforcement exists, record that as a gap with an owner and a date.

Deletion skips backups and replicas

Deleting a record from a production database leaves copies in backup sets, replicas, search indexes and caches. Map every location where a deleted item may persist, then decide how each one expires. Backup retention is the usual blind spot: confirm how long backup sets live, whether an individual record can be removed from them, and what the restore procedure does with data that should have been deleted.

Copies in test and analytics environments

Production data copied into test, staging, analytics or data science environments often outlives the project that created it. Set an expiry date on every copy at the time it is made, and delete it when the test ends. The handling rules for test information sit under A.8.33 Test information, so link the two controls in your procedures and check both during the same review.

SaaS providers without deletion evidence

Data held by a SaaS provider is still your information, and the provider's deletion practice becomes part of your control. Ask each provider in writing how and when it deletes customer data after termination or a retention event, which backups are included, and what certificate or report it can supply as evidence. Record the answers in your supplier file and set a review date for them.

Manual deletions with no record

Ad hoc deletions performed by administrators with a database console or file manager leave no trace that an assessor can test. Route deletion requests through a ticket or a scripted job that logs the requester, the approver, the scope and the completion time. Keep the log protected from the people whose actions it records, and sample it during internal review.

Retention periods never reviewed

Retention periods set when a system launched often no longer match legal, contractual or business needs. Schedule a periodic review of each retention period against current obligations, and record the decision, the reviewer and any change. A review that finds no change is still evidence, provided the reviewer and the date are on record.

Questions buyers ask about A.8.10 information deletion

How much effort does meeting A.8.10 information deletion take?

The effort depends mostly on how many systems, data stores and backups hold information that has a defined end of life, and on how many of those already have a retention rule written down. A control that asks for deletion when information is no longer required cannot be met until the organization knows what it holds, how long each category must be kept, and what triggers deletion. Costs come from three places: the internal time to define retention periods, the engineering work to build or configure deletion in each system, and the work to produce recurring evidence. Ask any partner to break the quote into discovery, rule definition, technical implementation per system and evidence design, so you can see which part scales with your estate. Most of the cost is one-time build work, followed by a smaller recurring cost to run deletion jobs and review their output.

How long does it take to implement information deletion controls?

The timeline is set by the number of information stores that need a deletion method and by how long it takes to agree retention periods with the business and legal owners. Systems that already support configurable retention, such as a database with scheduled purge jobs, move faster than systems where deletion must be scripted or where backups hold copies that cannot be altered without a restore process. Backups deserve early planning because a deleted record may persist in older backup sets until those sets expire, and that expiry rule must be documented and approved. Ask for a schedule that lists each system, its deletion method, the owner who signs off and the date the first deletion evidence will exist, since an assessor will want to see deletion operating over a period, not only configured once.

What does the internal team need to provide for A.8.10?

The internal team owns the decisions, and an outside partner cannot make them on the organization's behalf. Data owners must state what information they hold, why it is kept and when it stops being required. Legal, compliance and privacy staff must confirm statutory retention obligations and any holds that suspend deletion, because deleting information under a legal hold creates its own problem. Engineering staff must give time to configure deletion, test it in non-production environments and confirm which backups and replicas are in scope. Ask who will approve each retention rule and who will review deletion logs, and make those names part of the written scope before work begins.

Can a small team meet A.8.10 without outside help?

A small team can meet A.8.10 on its own if it has a short list of systems, clear data categories and an engineer who can automate deletion and keep records of it. The harder questions are rarely technical. A small company often has no written retention schedule, customer data spread across SaaS tools and no one who knows what backups contain. Those gaps are where outside help saves the most time, because a partner can run discovery and draft the rules for the owners to approve. The organization still has to run the control day to day. Before deciding, list your information stores, check which ones already delete data on a schedule, and estimate how many people can own the review. If the answer is few, a fixed-scope engagement for the build phase may suit you better than a permanent hire.

Can a partner prepare deletion evidence, and what will the auditor still test?

A partner can configure deletion jobs, collect logs and prepare the records an assessor will read, but it cannot issue the audit conclusion. An independent certification body decides whether the control is operating. The evidence usually covers the retention schedule with approval history, deletion job configurations, logs showing deletions ran on schedule, samples of deleted records with their timestamps, handling of backups and the process for suspending deletion under a hold. Open-source tooling can produce much of this. For example, the Bareos Director keeps a SQL catalog of backed-up files and runs backup and archive jobs, and an audit trail in Nextcloud's admin_audit app can record events in audit.log. Confirm with the certification body which samples it will select and how far back it expects records to go.

What should a written quote for A.8.10 work include?

A written quote should state the scope in concrete terms: the named systems, data categories, backup and replica sets, and the environments covered. It should list each deliverable, such as the retention schedule, deletion configurations, test records and evidence pack, and say who approves each one. Ask the provider to separate one-time build work from recurring work such as running reviews and maintaining jobs, and to state what the organization must supply, including owner time, legal input and access to systems. Confirm what is excluded, for example certification fees or the auditor's work, and how changes to scope are priced. DeployOpen works to fixed scopes agreed in writing before work starts, and quotes follow from that written scope.

How DeployOpen prepares information deletion for audit

DeployOpen prepares the systems, retention rules and deletion evidence that support A.8.10 Information deletion, inside the client's own infrastructure. The client keeps ownership of its retention decisions and control statements, while DeployOpen builds and documents the technical mechanisms that carry them out.

How we scope

Agree in writing which systems, storage media and backup repositories fall under the A.8.10 deletion scope.
Confirm with the client which retention periods apply to each data category before any technical work starts.
Record which deletion steps the client performs itself and which service providers perform, with contract references.

How we build

Configure deletion and expiry mechanisms in self-hosted platforms, such as backup retention and audit log retention settings.
Set up audit logging of deletion actions so that deletions leave a reviewable record in the client's environment.
Document the deletion method used for each storage type, including how media is wiped or destroyed when retired.

How we hand over

Deliver a written deletion procedure, retention schedule and configuration record mapped to the agreed scope.
Provide sample deletion logs and restore-test results that the client can show to an independent auditor.
Walk the client's team through the evidence so they can produce it themselves during audit fieldwork.

How we support

Offer ongoing support as a retainer to review retention settings, update deletion evidence and handle platform upgrades.
Run periodic checks that deletion jobs still execute as configured after changes to systems or backups.
Confirm with the client's auditor which evidence format and sampling approach they expect before the audit begins.