D2 — Asset Security: Classification, Ownership, Data Lifecycle

This domain is short but dense with precisely-defined roles the exam expects you to keep straight — the most common trap is assuming the person who protects data is the same person who decides how sensitive it is.

Three roles, three different jobs

• Data Owner — typically a senior business role (not IT), accountable for the data's value and for deciding its classification level. The owner decides what protection level is required — they don't necessarily implement it themselves.
• Data Custodian — typically IT/technical staff, responsible for implementing the technical controls the classification requires: backups, access controls, encryption. The custodian executes the owner's classification decision; they don't set it.
• Data Steward — focused on data quality, definitions, and proper usage/context (often used in data-governance contexts distinct from security specifically) — ensuring the data means what it's supposed to mean and is used appropriately, a role that sits closer to data governance than to security classification itself.

The trap this sets: a scenario question describing an IT administrator "deciding" a dataset should be classified Confidential is describing the custodian doing the owner's job — technically capable, but structurally wrong, because classification authority and accountability belong to the business owner, not whoever happens to have technical access.

The data lifecycle

Data moves through defined stages, each carrying its own security considerations: create → store → use → share → archive → destroy. Two stages deserve particular attention: share (does the classification and its associated controls travel with the data when it leaves the original system?), and destroy (is disposal verifiable and appropriate to the classification — a topic this lesson covers in depth below, because "delete" and "securely sanitized" are not the same claim).

Media sanitization: Clear, Purge, Destroy

When data must be irrecoverable — because a drive is being reused, retired, or disposed of — the method must match both the classification and the reuse intent:

Worked example: an organization must guarantee highly sensitive data on decommissioned SSDs cannot be recovered, but the drives will be reused internally. Degaussing does nothing to flash memory (it's a magnetic-media-only technique). A single-pass overwrite can't reliably reach SSD cells hidden behind wear-levelling and over-provisioning. Physical shredding would satisfy the sanitization requirement but destroys the drive, failing the "reuse internally" constraint. The correct choice is cryptographic erase (crypto-shredding): if the SSD was self-encrypting, destroying the encryption key instantly renders every cell's contents unrecoverable while the physical drive remains fully usable — the right Purge-tier method for this specific combination of sensitivity and reuse intent.

The CISSP mindset: manager vs technician

An IT administrator, technically capable and with full system access, decides on their own that a new customer analytics dataset should be classified "Internal Use Only" and configures access accordingly.

The technician answer: the classification is reasonable, access controls are correctly configured to match it, and the data is protected — job done.

The manager (CISSP) answer: classification authority belongs to the data owner, not whoever has the technical access to configure it. Even if the administrator's judgment happens to be correct, the process is wrong — accountability for the classification decision needs to sit with someone who understands the data's business value and regulatory exposure, not with whoever is closest to the system. The CISSP-correct fix isn't "double-check the classification is right," it's "route the classification decision to the actual data owner," the same governance-over-technical-correctness pattern from Lesson 1's SQL injection scenario and Lesson 8's own custodian-vs-owner distinction above.