CISSP Domain 2 Revision: Asset Security

Domain 2 is smaller than Domain 1 in exam weighting, but candidates still underestimate it. It looks straightforward on paper: classify data, handle it properly, manage its lifecycle, retain and dispose of it correctly. The difficulty comes from the detail hiding inside each of those verbs. ISC2 expects you to know not just what a control is called, but when it applies and who is accountable for it.

Here's a walk through the six objectives, aimed at revision rather than a first read.

Identifying and classifying information and assets

Classification is the starting point for almost every other control in this domain. You cannot protect what you haven't identified, and you cannot decide how much protection is proportionate without a classification scheme behind it.

Data classification typically follows a tiered model. Government and military environments use something like Top Secret, Secret, Confidential, Unclassified. Commercial organisations tend to use Confidential, Internal Use, Public, sometimes with a Restricted tier above Confidential for the most sensitive material. The exact labels matter less than understanding the principle: classification should be based on the impact of unauthorised disclosure, not on how important someone feels a document is.

Asset classification runs alongside data classification but covers a wider scope. Hardware, software, and even people can carry a criticality rating. A payment processing server and a print server both sit on the network, but they don't warrant equal protection, and classification is the mechanism that makes that distinction formal rather than assumed.

A point worth holding onto for the exam: classification isn't a one-off exercise. Data can be reclassified as its sensitivity changes, a contract expires, or regulatory status shifts. Static classification schemes tend to drift out of alignment with actual risk within a couple of years.

Establishing handling requirements

Once something is classified, handling requirements translate that classification into practical instruction. This is the layer that tells an employee what they're actually meant to do: how to label a document, how to transmit it, who can access it, how it should be stored, and what happens when it's no longer needed.

The exam likes to test the gap between policy and practice here. A classification scheme with no corresponding handling procedure is close to useless, because staff have no way of translating "Confidential" into a specific action. Handling standards typically map each classification tier to explicit requirements around encryption in transit, physical storage, and permitted disclosure.

Provisioning assets securely

This objective covers how assets are brought into use and tracked once they exist.

Information and asset ownership needs to be assigned, not assumed. The data owner (often a senior business role) carries accountability for classification decisions and access approval. This is distinct from the data custodian, who handles the asset day to day, typically someone in IT operations. Exam questions frequently test this distinction by describing a scenario and asking who is accountable for a decision, rather than who executed it.

Asset inventory needs to cover both tangible assets (servers, laptops, storage media) and intangible assets (software licences, intellectual property, cryptographic keys, even brand reputation in some frameworks). An inventory that only tracks physical hardware misses a growing share of organisational risk, particularly around software licensing compliance and shadow IT.

Asset management is the ongoing discipline of maintaining that inventory accurately: tracking assets through acquisition, deployment, maintenance, and eventual disposal. Without reliable asset management, most other security controls in this domain have nothing solid to attach to.

Managing the data lifecycle

This is the objective with the most granularity, and the one most likely to trip people up on terminology.

Data roles are worth memorising precisely, because they carry different legal weight under privacy law:

• Owner: accountable for the data, sets classification and access rules.
• Controller: under GDPR terminology specifically, the entity that determines the purpose and means of processing.
• Custodian: handles day-to-day technical management on the owner's behalf.
• Processor: processes data on behalf of a controller, under GDPR, with contractual obligations rather than ownership.
• User/subject: the individual using the data, or in privacy terms, the individual the data is about.

Controller and processor are GDPR-specific terms that have become common shorthand across the industry even outside EU contexts, so know them cold.

Data collection should follow the principle of collecting only what's needed for a stated purpose, a concept privacy regulation calls data minimisation. Over-collection creates liability with no corresponding business benefit.

Data location matters because of transborder flow issues covered in Domain 1, but here the emphasis is operational: knowing where data physically resides, which jurisdictions apply, and whether cloud storage locations meet contractual or regulatory requirements.

Data maintenance covers keeping data accurate and usable over time, including quality controls and update procedures.

Data retention requires balancing legal or regulatory minimums against storage cost and risk exposure. Retaining data longer than necessary increases breach impact without adding value, which is a point regulators increasingly test organisations on directly.

Data remanence is one of the more technical concepts in this section. It refers to residual data that remains on storage media after deletion, recoverable through forensic techniques unless properly addressed. This is why "delete" and "destroy" are not the same action, and the exam is fond of testing that gap.

Data destruction needs to match the classification and the media type. Options include:

• Clearing: overwriting data so it can't be recovered through normal means, but potentially recoverable with forensic tools.
• Purging: a more thorough process (degaussing magnetic media, for example) intended to defeat forensic recovery.
• Destruction: physical destruction of the media itself, shredding, incineration, or disintegration, generally the only acceptable method for the most sensitive classifications.

Cryptographic erasure deserves a mention too. Encrypting data and then destroying the encryption key renders the data unrecoverable without physically destroying the media, which is increasingly practical for cloud environments where physical destruction isn't an option.

Asset retention

This objective sits close to data retention but focuses specifically on hardware and software lifecycle rather than the data itself.

End of Life (EOL) refers to a product no longer being manufactured or sold. End of Support (EOS) is the more security-critical milestone: the point at which a vendor stops issuing security patches. Running systems past EOS is one of the most common findings in a security audit, because vulnerabilities discovered afterwards will never be fixed by the vendor.

The exam expects you to understand asset retention as a risk decision, not just an operational inconvenience. Extending the life of unsupported hardware or software might save budget in the short term, but it accumulates unpatched risk that has to be accepted, mitigated through compensating controls, or transferred, echoing the risk response options from Domain 1.

Data security controls and compliance requirements

This final objective ties the domain together by asking how you actually protect data given everything established above.

Data states are a foundational concept and worth being able to name instantly with an appropriate control for each:

• In use: data actively being processed in memory. Protected through techniques like secure enclaves, memory encryption, and application-level access control.
• In transit: data moving across a network. Protected through TLS, VPNs, and other transport encryption.
• At rest: data stored on disk or media. Protected through encryption at rest, access control, and physical security.

Scoping and tailoring describe how an organisation adapts a generic control framework to its actual environment. Scoping narrows a standard down to what's applicable (removing controls that don't apply, cloud-specific controls for an organisation with no cloud footprint, for instance). Tailoring then adjusts the remaining controls to fit organisational context, adding compensating controls where a standard control isn't feasible.

Standards selection follows from that: choosing which framework, or combination of frameworks, best fits the regulatory and business environment. An organisation processing payment card data will lean on PCI DSS as a baseline, then layer ISO 27001 or NIST controls around it for broader coverage.

Data protection methods worth knowing by function:

• Digital Rights Management (DRM): controls how content can be used after distribution, restricting copying, printing, or forwarding regardless of where the file ends up.
• Data Loss Prevention (DLP): monitors data in motion and at rest to detect and block unauthorised transmission, commonly deployed at network egress points and endpoint agents.
• Cloud Access Security Broker (CASB): sits between an organisation and cloud service providers, enforcing policy, visibility, and compliance across cloud usage that IT might not otherwise see.

The exam tends to test these three against each other by scenario. A question about a document leaking after being emailed outside the organisation despite being labelled Confidential points towards DLP. A question about unauthorised sharing of a video file after it's already left the network points towards DRM. A question about unsanctioned use of a cloud storage service by employees points towards CASB.

Where AI now sits in Domain 2

Asset security has picked up a genuinely new category of asset to classify and protect: training datasets, pre-trained models and model weights. These need to sit inside the same classification and handling scheme as any other information asset, and they carry their own version of the integrity concern that runs through Domain 2 generally. Data poisoning, feeding a model manipulated or corrupted training data so its output can be steered without anyone realising, is the AI equivalent of the integrity failures this domain already spends time on, and it needs to be caught before the model is trained on it rather than after.

Privacy also gets an AI-specific edge here. Where AI systems process personal data, technical controls like differential privacy and data masking become part of the toolkit sitting alongside the classification and retention discipline already covered. And because a trained model is often more valuable, and more sensitive, than the raw data that produced it, it's worth treating model weights as high-value intellectual property in their own right, with a collection, storage and destruction lifecycle every bit as deliberate as the one applied to the data itself.

Final thought for revision

Domain 2 rewards precision on terminology more than most other domains. The difference between clearing and purging, between owner and custodian, between EOL and EOS, comes up repeatedly in slightly disguised forms. Build flashcards around these paired terms specifically, because the exam's favourite technique here is presenting two very similar concepts and asking you to pick the correct one for a given scenario.