ISO 27001 A.8.10: Delete information when its purpose ends

What A.8.10 requires in practice

A.8.10 requires information to be deleted once it is no longer needed. It applies wherever information is held: in systems, on devices and on any other storage media, which includes backups, removable media, shared drives and supplier-held copies.

The control sits on top of a decision about when information stops being needed. That decision draws on legal, contractual and business retention needs. Deletion then has to be carried out in a way that suits the storage type and the sensitivity, and the organisation needs some means to show that it happened. Information subject to a valid hold must not be deleted early.

Outputs include defined retention decisions, a working deletion routine across the relevant locations and evidence that deletion took place. The control does not prescribe a method, a timescale or a tool. Sterling's teams often use a deletion confirmation step as a method, but a particular certificate or log is not stated as mandatory.

Decide when information is no longer required

Start with the purpose of the information and the applicable business, contractual and legal requirements. A project ending does not necessarily mean that every related record can be destroyed. Equally, the possibility that a file might someday be useful is not a sound reason for keeping every copy indefinitely.

Assign an owner for retention decisions and a process for exceptions, including situations where preservation is necessary. This article does not prescribe jurisdiction-specific retention rules. The organisation needs to identify and maintain those obligations within its own context before automating deletion or instructing a supplier.

Follow the information beyond the main folder

Identify relevant copies and storage locations. Exports, temporary working files, older versions and supplier-held data may remain after the main record disappears from a user's screen. Understand which copies are covered by the deletion process, which follow a separate lifecycle and which cannot immediately be removed because of an authorised retention requirement.

Connect deletion with backup arrangements. A recovery copy may have a different lifecycle from live data, so the organisation should understand and document the interaction. Avoid promising instant deletion from every backup unless the actual service and method support that claim.

Why timely deletion matters to the business

Information kept longer than needed is a liability. It enlarges the damage when a breach occurs, adds cost to storage and discovery and can breach privacy obligations or client contracts that required deletion at the end of a service. Customers frequently ask what happens to their data once an engagement closes, and a convincing answer helps retention and renewal. Deleting properly also reduces the volume of material an organisation must protect, search and back up. On the other side, deleting without a decision can destroy records the business or regulators still need, so the control rewards a deliberate approach. Auditors can test it easily by asking for a closed customer account and checking what remains.

How to implement A.8.10

Link a retention decision to a practical deletion step, then check the step worked. Treat backups, supplier copies and old devices as part of the scope, since those are the places deletion most often misses.

1. Agree the retention need for each main information type, drawing on legal, contract and business requirements.
2. Map where each type lives, including copies in backups, exports, shared drives, devices and supplier systems.
3. Define who triggers deletion, for example when a customer account closes or a project ends, and who checks that it was completed.
4. Choose a method suited to the storage type and sensitivity, noting where a system cannot delete selectively.
5. Check for holds before deleting, and record who confirmed there was none.
6. Verify the outcome without creating another sensitive copy, such as by sampling rather than exporting.
7. Review the routine when systems, suppliers or obligations change, and include deletion in the closing steps of customer offboarding.

Evidence an auditor expects for A.8.10

An auditor will want to see that deletion happens as described. Typical evidence includes:

• records showing retention decisions for main information types;
• examples of completed deletion, such as a closed customer account or finished project;
• observation of a system or storage location to confirm that the information is gone;
• records of how copies in backups or supplier systems were handled;
• an interview with the owner of an information set about when and how it is removed.

Checking an actual closed case is far more convincing than reading a retention table. Gaps often appear in secondary locations that nobody considered.

Common nonconformities with A.8.10

Deletion findings usually concern places the routine does not reach.

• Retention rules exist, but closed customer data remains in shared folders or exports.
• No one is responsible for starting deletion, so it never begins.
• Copies held by suppliers or in backups are forgotten when information is deleted from the main system.
• Deletion carried out with no check for legal or contractual holds.
• No evidence that deletion actually took place, so the organisation cannot show a customer or auditor what happened to their information.

Illustrative BPO example: closing a customer account

Illustrative construction example: a shared project device

A hypothetical construction company prepares tablets for transfer from one project to another. The project application is removed, but the team has not checked whether downloaded drawings and photographs remain in local storage. Those files contain commercially sensitive information from the completed project.

The company evaluates the device's storage and approved reset or deletion capabilities before reuse. It verifies an appropriate sample of the result and confirms that required project records remain available in the authorised repository. The example connects information deletion with secure equipment reuse, while keeping the two decisions distinct: needed records are retained properly, and unnecessary local copies are removed appropriately.

Select a method that fits the storage and risk

Deletion methods vary by system and media. A routine application action, a device-supported sanitisation process or another approved method may be appropriate depending on the information and technology. Evaluate what the method actually removes and what recovery remains possible; do not assume that a familiar command has the same effect everywhere.

For supplier services, clarify deletion during normal operation and at termination. Ask what the provider can demonstrate, the locations and copies covered, and relevant limitations. Supplier evidence should relate to the service and information concerned rather than simply repeat a general marketing statement about security.

Verify the outcome without creating another sensitive copy

Useful evidence may identify the authorised decision, information category, affected location, method, completion date, responsible party and verification outcome. This is practical advice rather than a mandated form. Record enough to support accountability without unnecessarily reproducing the sensitive information that the organisation intended to delete.

Test the process using appropriate non-sensitive sample data where possible. Follow a sample from its retention trigger through approval and removal, then check the expected locations and system behaviour. A test should identify its limits: proving that a file is unavailable through the ordinary interface does not establish every possible recovery characteristic of the underlying media.

Frequent failures include automating an unapproved retention period, ignoring exports and accepting a deletion certificate with an unclear scope. Review the control through ISMS evaluation and coordinate access during the retention period with information access restriction. Information that must be retained still needs appropriate protection.