Data doesn’t just exist — it moves. It’s created, labeled, stored, accessed, copied, shared, forgotten, found by someone who shouldn’t have it, and eventually (if you’re lucky) destroyed. Every phase of that journey introduces new risks, and most organizations only think about security at one or two of those phases. The rest is a blind spot — and blind spots are where breaches live.

The TLDR

The data lifecycle has seven phases: create, classify, store, use, share, archive, and destroy. Each phase requires different security controls. Data at rest needs encryption. Data in transit needs protected channels. Data in use is the hardest to protect — it’s decrypted and exposed in memory. Most organizations handle creation fine, skip classification entirely, store everything forever, share it carelessly, never archive properly, and never destroy anything. Data Loss Prevention (DLP) is meant to watch the whole lifecycle. Retention policies and legal holds add legal complexity. If you’re not thinking about data from birth to death, you’re only protecting part of the problem.

The Reality

Most organizations are data hoarders. They create data constantly, store it indefinitely, and destroy it never. Storage is cheap, so the default is “keep everything” — until a lawsuit hits and they discover they’ve been retaining emails from 2009 that are now discoverable evidence. Or until a breach exposes a database of customer records that should have been purged three years ago but nobody had a retention policy.

The Marriott breach (disclosed in 2018, ongoing since 2014) exposed 500 million guest records — partly because the compromised Starwood reservation system contained historical data going back years that had never been purged. Data that should have been at the “destroy” phase was still sitting at “store,” unmonitored and unencrypted. Four years of unauthorized access. Half a billion records. That’s what happens when data outlives its purpose without anyone noticing.

How It Works

Phase 1: Create

Data is born. Someone types a document, fills out a form, runs a transaction, takes a photo, writes code. At the moment of creation, the data has no label, no classification, and no handling rules. This is the most dangerous moment in the lifecycle, because freshly created data is unprotected by default.

Security at this phase means: establish data creation standards. Define what metadata gets attached at creation. Ensure systems that generate data apply default classifications. If a customer fills out a form with their Social Security number, the system receiving that input should immediately recognize it as sensitive data — not wait for a human to notice.

Phase 2: Classify

This is where data gets its label — Public, Internal, Confidential, Restricted (or whatever your scheme uses). Classification determines everything that follows: how it’s stored, who can access it, how it’s transmitted, and when it gets destroyed.

NIST SP 800-60 provides guidance on mapping data types to security categories. The critical failure here is skipping this phase entirely. Unclassified data defaults to whatever controls happen to be in place — which is usually the controls designed for the least sensitive data you have.

Phase 3: Store

Data at rest. Sitting on a disk, in a database, in a cloud bucket. The security requirements here are well-understood even if they’re poorly implemented: encryption at rest (AES-256), access controls (least privilege), integrity monitoring (detect unauthorized changes), and backup (the 3-2-1 rule — three copies, two different media, one offsite).

The cloud has made storage trivially easy and security surprisingly hard. Misconfigured S3 buckets have been responsible for some of the most embarrassing data exposures of the last decade. Capital One (2019), Twitch (2021), and countless smaller organizations have learned that “stored in the cloud” and “secured in the cloud” are two very different things.

Phase 4: Use

Data in use is data being processed — read, modified, analyzed, displayed on someone’s screen. This is the hardest phase to protect because the data must be decrypted to be useful. It lives in memory, in CPU registers, in application state. Technologies like confidential computing and secure enclaves (Intel SGX, AMD SEV) attempt to protect data in use, but they’re not universally deployed and have their own vulnerability histories.

The practical risk: someone with legitimate access viewing sensitive data on a screen in a coffee shop. An application loading a full database record into memory when it only needs one field. Data in use is where insider threats and application vulnerabilities do their damage.

Phase 5: Share

Data in transit. Moving between systems, between people, between organizations. TLS protects data on the wire. VPNs create encrypted tunnels. But the real risk at this phase isn’t interception — it’s oversharing. Sending a spreadsheet with full customer records when the recipient only needs aggregate numbers. Granting a vendor access to an entire database when they need three fields. Forwarding an email chain that includes a confidential attachment three layers deep.

DLP tools are designed to catch this — monitoring email, web uploads, USB transfers, and cloud sharing for sensitive data patterns. MITRE ATT&CK T1048 (Exfiltration Over Alternative Protocol) documents how adversaries bypass standard channels to move data out. But even without malicious intent, careless sharing is the most common way data ends up where it shouldn’t be.

Phase 6: Archive

Archival is storage with a purpose: you’re keeping the data because you have to (legal requirement, regulatory mandate, business need), but you don’t need active access. Archived data should be encrypted, access-restricted, and stored in a way that ensures integrity over time. The key difference from regular storage: archived data has an explicit retention period and a defined destruction date.

Legal holds override retention policies. When litigation is anticipated or underway, relevant data must be preserved regardless of normal retention schedules. Destroying data under legal hold is spoliation — it can result in sanctions, adverse inference instructions, or criminal obstruction charges. This is where IT and legal must coordinate, and where they frequently don’t.

Phase 7: Destroy

The end of the line. Data that has outlived its retention period must be securely destroyed — not deleted, destroyed. NIST SP 800-88 Rev. 1 defines three methods: clearing (overwriting with non-sensitive data), purging (degaussing, cryptographic erasure), and physical destruction (shredding, incineration, disintegration).

GDPR Article 17 — the right to erasure — adds a regulatory dimension. Data subjects can request deletion, and organizations must comply within defined timeframes. If your architecture can’t selectively delete individual records, you have a GDPR problem that no amount of policy writing will fix.

Data States: At Rest, In Transit, In Use

These three states cut across the lifecycle phases and define the technical controls required:

Every security architecture should address all three states. Most only address the first two.

How It Gets Exploited

The Retention Black Hole

Keep everything forever, and every breach becomes worse. The usual suspects don’t just steal current data — they grab historical records, archived databases, old backups. If you retained seven years of customer records when you only needed two, those extra five years of data are now a liability you volunteered for.

Uncontrolled Sharing

Data shared with a vendor doesn’t stop existing when the contract ends. Data emailed to a personal account lives there forever. Data exported to a spreadsheet can be copied, forwarded, and uploaded without restriction. Once data leaves your controlled environment, your lifecycle management ends and hope begins. That’s not a security strategy.

Destruction Theater

“We deleted it” usually means “we removed the file system pointer.” The data is still on the disk, recoverable with freely available tools. On SSDs, wear leveling means overwriting isn’t guaranteed to reach every copy of the data. In the cloud, you’re trusting your provider to actually destroy data on shared infrastructure. Without verification, destruction is an assumption.

What You Can Do

Map your data flows. Diagram where data is created, where it moves, where it’s stored, and where it’s supposed to die. You’ll find flows you didn’t know existed — guaranteed.

Implement retention policies. Define how long each data type is kept. Enforce automated deletion. Don’t rely on humans to remember to delete data — they won’t. CISA’s data governance guidance reinforces that retention policies are a fundamental security control.

Deploy DLP. Monitor data at all three states. Start with the most sensitive classifications and expand. DLP isn’t perfect, but it’s better than hoping nobody copies a customer database to a USB drive.

Encrypt at every state. At rest: AES-256. In transit: TLS 1.3. In use: minimize exposure, limit what’s loaded into memory, use tokenization where possible.

Coordinate with legal on holds. Build the process before you need it. When litigation hits, you don’t have time to figure out what “preserve relevant data” means across a thousand systems.

Verify destruction. Don’t trust “delete.” Use certified tools, get certificates of destruction for physical media, and verify cloud provider deletion processes contractually.

Sources & Further Reading