---
{
  "title": "Data Destruction",
  "summary": "Data destruction intentionally damages stored information so legitimate work cannot continue.",
  "topic": "grc",
  "level": "Intermediate",
  "updated": "2026-10-12",
  "published": "2026-10-04",
  "units": [
    3
  ],
  "aliases": [
    "T1485"
  ],
  "sources": [
    {
      "title": "MITRE ATT&CK T1485: Data Destruction",
      "url": "https://attack.mitre.org/techniques/T1485"
    }
  ],
  "editorialVersion": 2
}
---

## What it means

Data destruction intentionally damages stored information so legitimate work cannot continue. The recoverability of data depends on method, storage, and independent backups.


## An investigation example

A suspicious process deletes or overwrites business files across several accessible locations.

## Evidence to examine

Review affected paths, process identity, destructive operations, storage versions, and independent recovery copies.

## A common analytical pitfall

Deletion counts alone do not establish irrecoverability; assess actual storage and recovery options.

## Response considerations

Contain destructive activity, preserve evidence where feasible, and restore from validated independent copies under the recovery plan.


## Loss of usable information is the objective

Data destruction damages or removes information so legitimate work cannot continue. It may affect individual files, application records, or broader storage content. The impact depends on what is changed and whether trustworthy recovery material exists. Do not assume every incident with missing files has the same mechanism or recovery prospects.

Accidental deletion, software defects, synchronization errors, and authorized disposal can resemble malicious destruction. Establish the affected scope, first observed time, responsible process or identity, and surrounding activity. Preserve relevant records before routine cleanup or restoration overwrites them. Business recovery and evidence preservation may need to proceed together under a coordinated plan.

## A fictional missing-record incident

An academy's administrative application suddenly loses a group of records. Database audit events indicate an unusual bulk operation from an account normally used for reporting. The team compares the operation with scheduled maintenance and change approvals, then assesses whether other datasets were affected. A visible error in the interface alone would not establish that the underlying records were destroyed.

Recovery might use backups, transaction logs, or another trustworthy source, depending on the system. Validate restored information with the relevant application owner and address the compromised access or faulty process before normal operation resumes. Restoring data without correcting the cause can lead to repeated loss.

## Work through the evidence question

Create a fictional incident in which files disappear after a maintenance window. List evidence that would distinguish approved cleanup, an accidental job, and unauthorized destruction. State which records should be preserved first and who decides on restoration priorities. Avoid practicing destructive operations on real systems; a prepared dataset and written scenario can teach the reasoning safely.

Scope the investigation around both missing information and processes that still appear normal. A destructive operation may affect a selected dataset while leaving unrelated functions running. Business owners can help identify subtle losses that a general infrastructure health check would not reveal.

## Related concepts

- [[business-continuity]]
- [[disaster-recovery]]
- [[incident-response]]
- [[disk-wipe]]
- [[valid-accounts]]
- [[os-credential-dumping]]
- [[remote-services]]