About this note
This is the expanded reference version of my original CISSP exam notes. The bullet-point original is preserved in Domain 2 - Asset Security (Original-Stichpunkte) for comparison. Written for readers with several years of hands-on security and networking experience.
Information Life Cycle
Every piece of data moves through a predictable life cycle: acquisition → use → archival → disposal. The reason this trivial-looking sequence opens the domain is that security requirements change at each stage, and most data-protection failures happen at the transitions — data that was carefully protected in production ends up in an unencrypted archive, or an “archived” dataset quietly lives on in a decommissioned server that nobody sanitized. Asset security is largely the discipline of knowing where every dataset is in this cycle and applying stage-appropriate controls, all the way to provable destruction. Classification (below) is what makes that tractable: the label assigned at acquisition drives the handling rules at every subsequent stage.
Data Classification
Classification exists to solve a resource problem: protecting everything at maximum level is unaffordable, and protecting everything at the same middling level over-protects junk while under-protecting crown jewels. A classification scheme sorts data by the damage its disclosure would cause, so that controls (and spend) can be proportionate.
Two parallel vocabularies exist, and the exam expects you to know both:
| Government / Military | Private Sector |
|---|---|
| Top Secret (exceptionally grave damage) | Confidential (grave damage — trade secrets, source code, M&A material) |
| Secret (serious damage) | Private (personal/compartment data — credit card info, HR records; could cause damage) |
| Confidential (some damage) | Sensitive (company-restricted, used only by a subset of employees) |
| Sensitive but unclassified (SBU) | Company confidential (internal use — all employees, not the public) |
| Unclassified | Public |
The mapping between the columns is approximate, not exact — what matters is the logic: each tier is defined by the expected damage from unauthorized disclosure, and each tier carries defined handling requirements (encryption, storage, transmission, destruction).
The structural rule that ties classification to access control: objects have labels, subjects have clearances. The data carries its classification as a label; people (and processes) hold clearances; access is granted when clearance dominates label — plus, in strict environments, need to know. This is exactly the machinery MAC models like Bell-LaPadula (Domain 3) formalize, and it’s why classification without labeling is just a policy document with no enforcement hook.
Practical note from the private-sector trenches: classification schemes fail in two predictable ways — too many tiers (users can’t reliably distinguish five internal levels, so they guess) and no default (unlabeled data ends up implicitly public). Three or four tiers with a sane default of “internal” survives contact with real users far better than a scheme that’s theoretically complete.
The Three States of Data
The same triad from Domain 1’s confidentiality discussion, now from the asset perspective — every dataset is always in exactly one of these states, and each state has its own dominant control:
Data at Rest
Data sitting in storage, not currently being processed — databases, file shares, backups, laptops in checked luggage. The primary control is encryption: full-disk encryption for endpoints (against physical theft), database/volume/object encryption for infrastructure. The subtlety worth remembering: at-rest encryption protects against offline attacks — stolen disks, discarded drives — not against an attacker who compromises a running system where the data is transparently decrypted for authorized processes.
Data in Motion
Data traversing a network — between user and service, between services, between sites. The control is transport encryption: TLS, IPsec, SSH tunnels. The classic architectural failure is encrypting the internet-facing leg and running plaintext on the “trusted” internal network — an assumption that dies the moment anything inside is compromised. Encrypt internal traffic too; the perimeter is not a security boundary for data in motion.
Data in Use
Data being actively processed — in memory, on screen, on the printer tray. This is the hardest state to protect technically, which is why the controls here are largely procedural and physical: clean desk policy, print policies (secure pull printing, no sensitive output left on shared printers), screen locking and privacy filters, and workstation controls. On the technical side, memory protection and — increasingly — confidential computing address the in-memory portion, but for the exam the association is: data in use → administrative/physical controls like clean desk.
Data Handling, Storage, and Retention
These are the administrative controls wrapped around stored data — unglamorous, but they’re what auditors check and what regulations mandate.
Handling: sensitive data should only be handled by trusted, authorized individuals, and every access should be logged so an audit trail exists. Handling rules per classification tier (who may copy, mail, print, or transport which tier, and how) are the operational payoff of the classification scheme.
Storage: the physical and environmental side — media stored in geographically distant locations (a backup in the same building burns in the same fire), climate-controlled conditions (heat and humidity degrade media), and physically secured facilities. Off-site backup storage combines all three requirements.
Retention: data should not be kept beyond its period of usefulness. Every stored record is simultaneously an asset, a liability (it can be breached), and a discovery obligation (it can be subpoenaed). Retention periods are frequently dictated by regulation — tax law, HIPAA, GDPR’s storage-limitation principle — and can pull in both directions: minimum retention for compliance records, maximum retention for personal data. The operational consequence: retention needs an enforced schedule with automated deletion, not a policy PDF. “We keep everything forever because storage is cheap” is a legal strategy, and a bad one.
Data Roles: Ownership, Custody, and Use
The CISSP is precise about who does what with data, and exam questions hinge on the distinctions. The pattern throughout: owners decide, custodians execute, users comply. Accountability sits with owners and cannot be delegated; work can be.
Mission / Business Owner
The senior executive whose business processes the data serves — the level that makes policies and owns the business outcome. They fund the systems and ultimately answer for the risk.
Data / Information Owner
Management-level responsibility for specific datasets. The data owner assigns classification labels, sets requirements like backup frequency, and approves access requests. This is the accountability anchor: when the exam asks who is ultimately responsible for the protection of a dataset, the answer is the data owner — not IT, not the custodian.
Data Custodian
The hands-on role: the technicians who perform day-to-day tasks — backups, restores, patching — following the directions of the data owner. Custodians monitor security, maintain accessibility, and ensure data integrity (the CIA properties in operation). The custodian implements the protection the owner specified; they don’t decide what the protection should be. Classic split: the DBA is custodian of the HR database; the HR director is its owner.
System Owner
Owns the system the data lives on rather than the data itself — typically a data-center or infrastructure manager. The system owner selects and implements the security controls for the platform: hardening, patching regime, host-level protections. One system can host many datasets with different data owners, which is why the roles are separate.
Data Controller and Data Processor
GDPR vocabulary that the CISSP adopted: the controller determines the purposes and means of processing — they create and manage the sensitive data and carry the primary legal responsibility. The processor processes data on behalf of the controller — the outsourced payroll provider is the canonical example. The liability structure matters: outsourcing processing does not outsource accountability; the controller answers for the processor’s failures, which is why processor contracts (DPAs) and vendor assessment exist.
Security Administrator
Responsible for the security infrastructure itself — firewalls, IPS/IDS, and the security tooling. Distinct from custodians (who operate data systems) even though both are technical roles.
Supervisor
Responsible for user behavior and the assets users create, and for keeping the security administrators informed of changes — the role that makes joiner/mover/leaver processes actually work. When someone changes teams and keeps their old access for two years, the failure was here.
End Users
The people who access data to do their jobs. Their obligations: follow policies and instructions, and maintain the awareness level the organization trains them to. Users are accountable for their actions under their identity — which loops back to Domain 1’s accountability chain.
Auditor
The independent verification role: reviews and confirms that security policies are correctly implemented and that all the roles above are actually doing what the documentation claims. Independence is the defining property — an auditor who reports into the function they audit isn’t one.
Memory and Data Remanence
Remanence is the data that remains after an attempted removal — the residue that makes disposal a security problem rather than a housekeeping one. Understanding remanence requires knowing what the media actually is:
- ROM (read-only memory) and its programmable variants — PROM (one-time programmable), EPROM (UV-erasable), EEPROM (electrically erasable), PLD (programmable logic devices). Nominally read-only, but the erasable variants hold data that survives power-off and can persist through naive disposal.
- RAM — volatile memory: SRAM (fast, cache), DRAM (main memory, needs refresh), SDRAM (synchronous DRAM). Volatility is not an absolute guarantee: contents can survive briefly after power-off (the basis of cold-boot attacks), which is why RAM is part of the forensic order of volatility in Domain 7.
- Flash memory — EEPROM-derived, non-volatile: USB sticks, memory cards. The portable form factor makes flash the remanence problem that walks out the door.
- SSDs — architecturally a combination of EEPROM-style flash and a DRAM cache, with a critical disposal property: SSDs cannot be degaussed. They store data in charge states, not magnetic domains, so a magnetic field does nothing. Worse, wear-leveling means the drive’s controller remaps writes across cells — an overwrite pass issued by the OS provably does not reach every physical cell. Sanitizing SSDs means the manufacturer’s secure-erase / crypto-erase functions, or physical destruction. Treating SSDs like magnetic disks in a disposal procedure is a genuine, common, auditable mistake.
Data Destruction
Destruction methods form a hierarchy of assurance. The exam wants the definitions crisp:
Paper: shredding — and specifically cross-cut shredding, because strip-cut output can be (and famously has been) reassembled.
Digital, in ascending order of assurance:
- Delete — removes the directory/filesystem reference only; the data blocks remain and are trivially recoverable. Not a destruction method.
- Format — same as delete plus a new file structure; the underlying data is still recoverable. Also not a destruction method.
- Overwrite — writing zeros or random data over the actual blocks. Effective on magnetic media (a single competent pass is generally sufficient on modern drives, despite folklore about 35 passes); unreliable on SSDs for the wear-leveling reason above.
- Sanitization — removing data to a point where recovery is infeasible for a given level of effort. This is the risk-proportionate concept: sanitization is defined relative to the attacker capability you’re defending against. NIST SP 800-88r1 is the reference for matching method to media and sensitivity.
- Purge — removing data to a point where recovery is not feasible at all, by any known technique. The stronger guarantee, for the higher classifications.
- Degaussing — applying a strong magnetic field to destroy magnetic domains. Effective on HDDs and tape (typically rendering the drive itself unusable, since servo tracks die too); completely ineffective on SSDs and flash.
The governing principle: destruction method must match both the media type and the classification of the data that ever touched it. And “ever touched” is doing real work in that sentence — a drive that briefly held Top Secret data is sanitized to Top Secret requirements regardless of what’s on it now.
Data Security Controls and Frameworks
Four terms describing how generic standards get adapted and formally adopted for a specific system:
- Scoping — determining which portions of a standard apply to your deployment and striking the rest. A control catalog written for every conceivable system contains controls for systems you don’t have; scoping removes the wireless controls from the assessment of a system with no wireless.
- Tailoring — customizing the remaining controls to fit the organization: adjusting parameters, substituting compensating controls where the prescribed one doesn’t fit, aligning with the actual environment. Scoping decides what applies; tailoring decides how it applies.
- Certification — the technical evaluation: verifying that the system’s protection profile is appropriate for the data it stores and that it meets the security requirements set by the data owner. Certification is an assessment, performed by security professionals, producing evidence.
- Accreditation — the management decision: the data owner (or designated authorizing official) reviews the certification and formally accepts the residual risk, authorizing the system to operate. Certification informs; accreditation decides.
The certification/accreditation pair is Domain 1’s risk-acceptance principle made procedural: someone with authority signs their name to the residual risk, in writing, before the system goes live. In current NIST vocabulary (RMF, SP 800-37 r1 / r2) the same pair appears as assessment and authorization — different words, same structure.
Erstellt: 2026-07-08 — ausformulierte Fassung der Original-Stichpunkte, siehe Domain 2 - Asset Security (Original-Stichpunkte)