Data Security Reference Guide
CISSP Domain 2: Asset Security · 7 topics · Concepts, real-world examples, and controls
Classification assigns a sensitivity label to data or an asset based on its value, the harm disclosure or loss would cause, and any regulatory obligations attached to it. Every downstream control decision — access, storage, retention, destruction — is derived from this label. Without it, controls are applied blindly: too weak for high-value data, prohibitively expensive for low-value data.
Classification criteria
Value — how critical is this data to operations or competitive position? A pharma company’s drug trial data is far more valuable than its cafeteria menu.
Sensitivity — what is the potential harm if disclosed? A customer’s name is low-sensitivity; their HIV diagnosis is high-sensitivity.
Criticality — would loss or unavailability disrupt core operations? A hospital’s patient record system is critical; the HR intranet is not.
Legal obligation — does regulation mandate specific handling regardless of internal judgment? HIPAA classifies all PHI; GDPR applies to any EU subject’s personal data.
🌐 Real-world example
In 2019, Capital One suffered a breach of over 100 million customer records. The data — SSNs, bank account numbers, credit scores — was all in one cloud bucket with the same access controls, because it had never been classified by sensitivity. Had the most sensitive fields been classified separately and encrypted with distinct keys, the blast radius would have been a fraction of the actual damage.
Information and asset handling requirements
A classification label has no operational value without a handling procedure attached. “Confidential” means nothing unless teams know: can it be emailed? Printed? Stored in a personal cloud account? The handling procedure translates abstract sensitivity into specific, enforceable behavior for every person who touches the data.
Storage
Where can this data live? Encryption at rest, access restrictions, physical controls per classification tier.
Transmission
Encrypted channels, authorized recipients only, labeling on outbound data.
Labeling
Visual markings or metadata so every handler recognizes the classification on sight.
Disposal
Destruction method matched to classification level and media type.
🌐 Real-world example
In 2017, a major UK defense contractor was fined after an employee emailed unencrypted personnel files — including passport scans — to a personal Gmail account to work from home. The classification policy existed. The handling procedure for “Confidential data leaving the network” did not. The employee wasn’t malicious; they just didn’t know what was and wasn’t permitted. A handling matrix with a clear rule for that scenario would have prevented it.
Building a handling matrix
A handling matrix maps classification levels (rows) against handling scenarios (columns: storage location, email, printing, external sharing, disposal). Each cell contains an unambiguous rule. If a team member has to interpret or guess, the matrix is incomplete.
External obligations (GDPR Art. 32, HIPAA §164.312, PCI-DSS Req. 3) set the minimum floor — internal policy must meet or exceed them. Build the external floor first, then layer internal requirements on top.
Provisioning information and assets securely
Secure provisioning means assets enter the environment with ownership assigned, classification documented, inventory recorded, and controls in place — before they accumulate operational exposure. An unprovisioned asset is an unmanaged asset, which is an unprotected asset.
Tangible assets
Servers, endpoints, storage media, network hardware, removable drives, printed documents with classified content.
Intangible assets
Software licenses, source code, databases, trade secrets, brand identity, API keys, cloud service subscriptions.
🌐 Real-world example — shadow IT
The 2020 SolarWinds breach revealed that many affected organizations had no complete inventory of the software running in their environments. When investigators asked “which systems have SolarWinds Orion installed?”, many organizations could not answer. Discovery took weeks — weeks during which the attacker remained active. An up-to-date CMDB would have reduced that window to hours.
Data roles
Five distinct roles carry specific, non-overlapping accountability for data assets. Role confusion is one of the primary causes of accountability gaps in security incidents — most commonly when IT assumes classification responsibilities that belong to the business.
Select a role below to see its full definition and real-world example.
Data owner
A business role, not a technology role. Typically the department head or business unit leader who creates or relies on the data. The owner determines classification level, defines authorized uses, approves access requests, and bears ultimate accountability if controls are inadequate. Ownership cannot be delegated to IT — the owner must understand the business value and risk profile of the data.
Key distinction
The owner decides. The custodian implements. If the same person does both, there is no independent check on whether controls are appropriate.
Real-world example
At a hospital, the Chief Medical Officer is the data owner of patient records. They set the policy: who can access which data, under what circumstances, for how long. The IT department (custodian) builds the access controls and maintains the EHR system — but they do not decide what “appropriate access” means. When a nurse accesses a VIP patient’s records out of curiosity, the violation is measured against the owner’s policy, not IT’s configuration.
Data controller
A GDPR-specific designation. The legal entity that determines the purposes and means of processing personal data. If your organization decides why and how customer data is collected and used, your organization is the controller. The controller bears primary legal responsibility for GDPR compliance, even when processing is outsourced to third parties.
Key distinction
The controller decides why and how data is processed. The processor carries it out under instruction. A clear Data Processing Agreement (DPA) between them is legally required under GDPR.
Real-world example
Spotify collects user listening behavior and decides to use it for personalized recommendations and ad targeting. Spotify is the controller. When they pass that data to an ad tech vendor for campaign optimization, that vendor becomes a processor. If the vendor misuses the data, Spotify remains liable to users — because Spotify is the controller who authorized the processing.
Data custodian
An IT or operations function that implements and maintains technical and administrative controls on behalf of the data owner. Custodians manage system availability, integrity, and confidentiality — but they do not set policy or make classification decisions. A custodian who unilaterally reclassifies data or approves their own access requests is operating outside their role.
Key distinction
Custodians hold the keys but do not own the house. They implement what the owner decides, verify that controls are functioning, and escalate when they cannot implement a required control.
Real-world example
A database administrator at a financial firm is the custodian of the trading database. When the CFO (owner) says “grant the risk analytics team read access to position data,” the DBA implements that decision — they do not override it because they think it is too broad. If the DBA disagrees, they escalate; they do not act unilaterally.
Data processor
Processes personal data on behalf of the controller, under contract and under instruction. The processor does not independently decide what to do with the data — they perform a specific, defined service. Under GDPR, the processor’s obligations are defined in a DPA and include security measures, sub-processor controls, breach notification, and data return or deletion on contract end.
Key distinction
If a processor starts deciding what to do with data beyond their contractual mandate, they become a controller for that processing — with full controller liability. This is how unexpected GDPR violations occur in vendor relationships.
Real-world example
A UK retailer uses a third-party payroll firm to process employee salary data. When the payroll firm’s systems were breached in the 2021 Kronos ransomware attack, the retailers remained responsible to their employees. The retailers had to notify their own employees, conduct impact assessments, and answer to regulators — because they were the controllers who chose that processor.
User / Subject
The individual who accesses and uses data within the permissions granted by the owner. Subject to least privilege — access should be the minimum necessary for the user’s role and should be revoked when no longer needed. In GDPR context, “data subject” refers to the individual whose personal data is being processed — a distinct meaning from “user” that is frequently confused in policy documents.
Key distinction
Users access data; they do not own or manage it. Orphaned accounts — active credentials for former employees — are a persistently exploited attack vector.
Real-world example
The 2022 Uber breach began when an attacker obtained the credentials of a contractor. The contractor’s account still had broad access because off-boarding controls were incomplete. The failure was in user lifecycle management: access was not revoked when it should have been.
Data lifecycle management
Data has a defined beginning and end. Risk is not uniformly distributed — the highest-risk moments are at the edges: collection (before controls are applied) and destruction (after attention fades). A program that only protects data in active use addresses roughly 60% of the actual risk surface.
Select a phase to expand its definition and real-world example.
Phase 1
Collection
Phase 2
Location
Phase 3
Maintenance
Phase 4
Retention
Phase 5
Remanence
Phase 6
Destruction
Collection
The point at which data enters the environment. The primary principle is data minimization: collect only what is genuinely necessary for a stated purpose. Every field collected is a field that can be breached, subpoenaed, or misused. Purpose limitation — collecting data only for a specified, explicit purpose — is both a GDPR Article 5 requirement and a sound security principle.
🌐 Real-world example
In 2018, Facebook’s Cambridge Analytica scandal was fundamentally a collection failure. Facebook allowed third-party apps to collect not just the app user’s data, but the data of all their friends — far beyond what any legitimate purpose required. Excess collection created excess exposure. GDPR’s data minimization requirement directly addresses this pattern.
Data states
Data exists in one of three states at any point in time. Each has a distinct threat profile and control set. Coverage must be explicit across all three — adversaries will find the unprotected state and work there.
Data at rest
Stored on disk, database, tape, backup, or cloud volume. Static and persistent. If media leaves the controlled environment, is the data readable without credentials?
Primary controls
AES-256 RBAC Key management Physical controlsGap: encrypting the primary database but not backup tapes or S3 exports.
🌐 Example
The Equifax breach (2019): a database containing 147M records was unencrypted at rest. Attackers exploited an unpatched Apache Struts vulnerability and read the data directly — no encryption to bypass.
Data in transit
Moving over a network — public internet, internal LAN, or between cloud services. Intercept-able at multiple points. Internal traffic is not safe by default.
Primary controls
TLS 1.2+ VPN S/MIME Cert managementGap: unencrypted server-to-server traffic on flat internal networks.
🌐 Example
Target breach (2013): attackers intercepted unencrypted payment card data flowing between POS terminals and the internal payment processor. In-transit encryption on the internal network would have rendered the data useless.
Data in use
Being actively processed in memory or by an application. Must typically be decrypted to be processed — so standard encryption does not protect it here. The hardest state to secure.
Primary controls
App access controls Memory protection Confidential computing Data minimizationEmerging: Intel TDX, AMD SEV — process data inside encrypted memory enclaves.
🌐 Example
Spectre/Meltdown (2018): CPU vulnerabilities allowed attackers to read data from other processes’ memory while in use — bypassing all at-rest and in-transit controls entirely. The canonical in-use attack.
Data security controls and compliance frameworks
Scoping and tailoring
Security frameworks are designed to be adapted, not applied wholesale. Scoping identifies which controls apply to your environment — controls addressing non-existent threats can be excluded. Tailoring modifies in-scope controls to fit your operational context while maintaining the required security posture. Both decisions must be formally documented — an undocumented deviation is a gap, not a tailoring decision.
🌐 Real-world example
A fintech startup processing payments must comply with PCI-DSS. As a 12-person company using cloud infrastructure, many physical security controls (visitor logs, CCTV, secure server rooms) are out of scope — that’s scoping. They then specify that MFA must use hardware tokens for admins and TOTP for all other staff — that’s tailoring. Both decisions are documented in their System Security Plan.
Framework selection
Select your context to see the appropriate framework.
Data protection tools — DLP, DRM, CASB
Three technologies form the core of operational data protection. They solve distinct problems and operate at different points in the data flow — they are complementary, not interchangeable.
Data Loss Prevention
Monitors data movement across endpoints, email, and network egress. Detects sensitive data attempting to leave in policy-violating ways. Blocks or alerts.
Solves: preventing exfiltration. Last line of defense when upstream controls fail.
Example: An employee tries to email a file containing 500 credit card numbers to a personal Gmail account. The DLP policy detects the PAN pattern, blocks the email, and alerts the security team — before the data leaves the network.
Digital Rights Management
Enforces usage rights on content after it has been shared — including with authorized recipients. Controls forwarding, printing, copying, and time-limited access.
Solves: controlling what recipients do with data they legitimately have. DLP stops data leaving; DRM follows it after it leaves.
Example: A law firm sends a confidential settlement document to opposing counsel as a DRM-protected PDF. The file can be viewed for 30 days but cannot be printed, forwarded, or copied. Even if the recipient’s email is compromised, the document is unusable beyond that window.
Cloud Access Security Broker
Sits between users and cloud services. Provides visibility into cloud app usage, enforces data security policies across SaaS platforms, detects shadow IT.
Solves: governing data in cloud environments the organization does not directly control.
Example: A CASB detects that 40 employees are using personal Dropbox accounts to share work files. The CASB blocks the uploads, logs the activity, and triggers a policy notification. Without the CASB, this data movement would be completely invisible.
Destruction methods reference
| Media | Recommended method | Why deletion fails | Real example |
|---|---|---|---|
| HDD | Overwrite (NIST 800-88) Degauss Physical shred | Delete removes the filesystem pointer. Data stays on platters until overwritten. | Morgan Stanley (2022): unwiped HDDs sold at auction exposed 15M customer records. $35M SEC fine. |
| SSD / Flash | Cryptographic erasure Physical destruction | Wear-leveling reserves cells overwrite tools can’t reach. Degaussing has no effect on flash. | Common forensic finding: “wiped” SSDs from laptop replacements still contain recoverable company data. |
| Cloud storage | Cryptographic erasure Vendor-certified deletion | “Deleted” volumes persist in provider infrastructure for days or weeks before physical overwrite. | AWS/Azure standard: encrypt at ingestion, destroy the key on deletion — the certified destruction equivalent. |
| Paper | Cross-cut shred (DIN P-4+) Incineration | Strip shredding is reconstructable. Recycling bins are not secure disposal. | UK NHS trust fined (2010): patient records found in a public recycling bin — strip-shredded but reassembled by a journalist. |
| Optical | Disintegration / shred Incineration | No reliable software erasure. Physical destruction is the only option. | Government standard: witnessed physical destruction of classified optical media with certificates of destruction retained for audit. |
The data security chain
Every gap in this chain is a place where a breach, compliance failure, or incident investigation will reveal something was assumed rather than decided.
Classify data and assets
Assign sensitivity labels based on value, harm, and legal obligation. Owner decides, not IT.
Define handling requirements
Specify storage, transmission, labeling, and disposal rules for each classification level.
Provision and inventory assets
Register every asset before operational use — tangible and intangible. Shadow IT = unknown risk.
Assign roles and accountability
Owner decides. Custodian implements. Processor acts under contract. User accesses under least privilege.
Manage the full lifecycle
Minimize at collection. Control location. Maintain access. Enforce retention. Address remanence.
Apply state-specific controls
At rest: encrypt. In transit: TLS/VPN. In use: access controls and memory protection.
Deploy DLP · DRM · CASB
Layer the tools: CASB governs cloud, DLP blocks exfiltration, DRM follows shared content.
By profession, a CloudSecurity Consultant; by passion, a storyteller. Through SunExplains, I explain security in simple, relatable terms — connecting technology, trust, and everyday life.
Leave a Reply