CISSP Domain 2: Asset Security

Domain 2 accounts for 10 percent of the current CISSP exam outline. Its central question is simple to state and difficult to answer well: what does the organization have, why does it matter, who is accountable for it, and what must happen to it throughout its useful life?

Asset Security is not limited to files stored on servers. Assets include information, devices, software, services, accounts, certificates, intellectual property, cloud resources, backups, logs, models, facilities, and business processes. Some are tangible. Others exist only as rights, records, configurations, relationships, or knowledge.

A good answer connects business value and potential harm to specific handling requirements. A classification label without an owner, inventory, retention rule, or enforceable control is decoration rather than protection.

1. Domain 2 map

The official outline divides Asset Security into six objectives:

These objectives form one lifecycle. Classification drives handling. Handling depends on ownership and location. Retention affects storage, backup, legal discovery, cost, and exposure. Destruction must address every copy, including replicas and third-party holdings. Controls must follow the asset wherever it goes.

2. Use the right decision order

CISSP questions often present a control before the organization has established the requirement. Encryption, Data Loss Prevention, or a Cloud Access Security Broker may be useful, but a product is not the first answer when the asset, owner, classification, or obligation is still unknown.

A practical sequence is:

1. Identify the asset and business purpose. Determine what the asset is, how it supports the organization, and which process depends on it.
2. Assign accountable ownership. An owner approves classification, use, access, retention, and risk decisions. Technical teams usually implement those decisions.
3. Determine value and potential impact. Consider confidentiality, integrity, availability, privacy, safety, legal duties, intellectual property, financial harm, and mission effect.
4. Classify and label when appropriate. Apply the organization's approved scheme and document the basis for the decision.
5. Define handling requirements. State who may access the asset and how it may be stored, transmitted, copied, shared, transported, and disposed.
6. Record location and dependencies. Include backups, logs, replicas, endpoints, cloud regions, suppliers, software services, and derived data.
7. Select and tailor controls. Match controls to the asset, data state, threat, obligation, and operating environment.
8. Set retention and disposal rules. Reconcile business value with legal, regulatory, contractual, privacy, and evidentiary requirements.
9. Monitor changes and verify outcomes. Reclassify when sensitivity changes, review ownership and access, validate sanitization, and update inventory after migration, retirement, or transfer.

If a scenario says the data owner has already approved the classification and handling standard, do not restart the process. Look for the next missing action. If no owner or inventory exists, deploying a control may only hide the governance gap.

3. Identify and classify information and assets

Classification groups assets according to value, sensitivity, criticality, obligations, or the harm that could result from compromise. It helps the organization apply stronger controls where they are justified and avoid wasting the same effort on everything.

Information classification and asset classification

Information classification focuses on the content and the consequences of unauthorized disclosure, alteration, loss, misuse, or unavailability. Examples include customer records, source code, financial forecasts, legal strategy, credentials, research data, and operational logs.

Asset classification can include the broader resource that stores, processes, transports, or supports information. A server, laptop, industrial controller, software service, certificate authority, building, backup system, or machine-learning model may be classified according to business criticality, the information it handles, replacement difficulty, safety impact, or operational dependency.

The classifications influence each other, but they are not identical. A low-cost device can process highly sensitive information. An empty replacement server may contain no sensitive data but still be critical to availability because the business depends on its role.

Base classification on impact

A classification decision should consider more than secrecy:

• Confidentiality: What harm could follow from unauthorized disclosure?
• Integrity: What harm could follow from unauthorized or incorrect modification?
• Availability: What harm could follow if the asset becomes unavailable or unreliable?
• Privacy: Could processing create problems for individuals even without a traditional breach?
• Legal and contractual duties: Which laws, regulations, licenses, agreements, or industry rules apply?
• Business value and criticality: How does the asset support revenue, safety, trust, mission, or essential operations?
• Replacement and recovery: Can the asset be recreated, restored, purchased, or substituted within the required time?
• Aggregation and inference: Could several low-sensitivity items reveal sensitive information when combined?

Organizations use different labels. A private company might use Public, Internal, Confidential, and Restricted. A government may use statutory categories. The labels themselves are less important than consistent criteria and enforceable handling rules.

Do not assume that the highest confidentiality label automatically means the highest availability requirement. Public emergency instructions may require little confidentiality but very high integrity and availability. A confidential archive may tolerate several hours of downtime while a public safety system cannot.

Ownership, labeling, and reclassification

The data or asset owner is normally responsible for approving the classification because the owner understands business value, obligations, and acceptable use. Security and privacy specialists advise. Custodians apply labels and controls. Users follow the handling rules.

Classification is not permanent by default. Information may become less sensitive after public release, contract completion, patent filing, declassification, or expiration of a business event. It may become more sensitive after aggregation, enrichment, a merger, a legal hold, or a change in threat conditions.

A mature process defines:

• Who may classify and reclassify
• Which criteria support each level
• How labels appear in digital and physical forms
• How inherited or derived information is treated
• When classifications are reviewed
• Who approves downgrading or declassification
• How exceptions are documented

4. Establish handling requirements

Handling requirements translate a classification into actions. They should be specific enough that users, administrators, suppliers, and automated systems can follow them.

A handling standard may address:

A label should travel with the asset when practical, but a label alone cannot enforce behavior. Controls may include metadata tags, access policies, encryption keys, storage rules, transport procedures, contract clauses, and monitoring.

Minimize unnecessary data

Collecting or copying information creates continuing responsibilities. Before acquiring data, ask whether the organization needs it, whether a less sensitive form would work, how long it will remain useful, and whether it can be aggregated, masked, tokenized, or anonymized.

Data minimization reduces breach impact, privacy risk, discovery burden, storage cost, and the number of systems that need controls. It also makes destruction more achievable because fewer copies exist.

5. Provision information and assets securely

Provisioning begins before an asset enters service. The organization should approve the need, assign ownership, record the asset, establish configuration and handling requirements, and define how it will be transferred or retired.

Information and asset ownership

Ownership means accountability, not necessarily possession or daily administration. An owner typically decides or approves:

• Classification and criticality
• Authorized uses and users
• Access criteria
• Retention and disposal
• Recovery requirements
• Risk acceptance and exceptions
• Periodic review

The owner may delegate tasks, but accountability remains. A storage administrator can maintain a database without having authority to decide that every employee should read it.

Maintain a useful inventory

An inventory should include enough context to support decisions. A list of serial numbers is not sufficient for cloud services, information, software, or business dependencies.

Useful fields may include:

• Asset identifier and description
• Owner and custodian
• Classification and criticality
• Physical or logical location
• Business service and dependencies
• Data types processed
• Approved users or roles
• Supplier and contract
• Configuration or baseline reference
• Support status and renewal date
• Recovery objective and backup arrangement
• Retention and disposal requirement
• Last review and current lifecycle state

Include tangible and intangible assets. Common omissions include cloud subscriptions, unmanaged software-as-a-service accounts, service accounts, certificates, encryption keys, source repositories, domain names, data sets, application programming interfaces, models, algorithms, licenses, documentation, and institutional knowledge.

Discovery tools can help find assets, but automated discovery does not assign ownership or explain business value. Inventory quality depends on reconciliation with procurement, finance, identity, configuration management, cloud management, contracts, and operational records.

Control shadow assets and transfers

A business unit may create a cloud service with a credit card, copy data into a collaboration platform, or deploy an application outside the standard process. Blocking every experiment may be unrealistic, but unknown assets create unmanaged risk.

Provide an approval path that is usable, discover activity through technical and financial records, and bring legitimate services into inventory and governance. When ownership changes, transfer access, records, keys, contracts, recovery duties, and risk decisions rather than changing only a name in a database.

6. Understand data roles

The official outline names owners, controllers, custodians, processors, users, and data subjects. Terminology varies among laws and organizations, so focus on authority and responsibility.

One organization can hold several roles. A service provider may process customer data for a client and act as controller for its own employee records. Contracts should state roles, instructions, permitted use, security requirements, incident duties, return or destruction, audit rights, and subprocessor conditions.

7. Manage the data lifecycle

Data moves through collection, use, maintenance, sharing, retention, and destruction. It may be transformed, replicated, combined, summarized, or used to create new assets. Lifecycle management must follow those changes.

Collection

Before collection, identify purpose, authority, minimum necessary fields, source, expected quality, classification, owner, retention, and notice or consent requirements. Collecting data first and deciding how to govern it later creates avoidable exposure.

Validate provenance and integrity when decisions depend on the data. An authorized source can still provide incomplete, outdated, or corrupted information.

Location

Location includes more than the primary database. Data may exist in:

• User devices and browser caches
• Backups and snapshots
• Logs and monitoring systems
• Search indexes and analytics platforms
• Development and test environments
• Email, chat, and collaboration tools
• Cloud regions and content delivery networks
• Supplier systems and subprocessors
• Exports, reports, printouts, and removable media
• Derived data, embeddings, models, and aggregated records

Location can affect law, contract, latency, resilience, access, incident response, and destruction. Data residency describes where data is stored or processed. Data sovereignty concerns the legal authority that may apply because of that location or other jurisdictional connections.

Maintenance

Maintenance preserves accuracy, completeness, availability, and usefulness. It includes validation, correction, reconciliation, version control, metadata, integrity checks, backup testing, access review, and removal of obsolete copies.

Poor maintenance can turn an apparently protected data set into a source of bad decisions. Integrity requires both protection from unauthorized changes and processes for correcting authorized errors.

Derived and transformed data

Masking, aggregation, pseudonymization, tokenization, analytics, and model training can create new assets. Do not assume a transformed output is automatically harmless. It may still permit reidentification, reveal proprietary patterns, inherit restrictions, or support sensitive inferences.

Classify the result according to its own content and risk, while preserving lineage to the source. Lineage helps explain origin, transformations, quality, ownership, and downstream obligations.

8. Ensure appropriate asset retention

Retention balances legitimate need against cost and exposure. Keeping everything forever is not a neutral choice. It increases breach impact, privacy risk, legal discovery, storage cost, recovery complexity, and the number of copies that must eventually be destroyed.

A retention schedule should reconcile:

• Law and regulation
• Contractual commitments
• Litigation holds and investigation needs
• Records-management requirements
• Business and operational value
• Tax, audit, safety, and warranty needs
• Privacy principles and promises
• Backup and disaster-recovery design
• Technical ability to locate and delete copies

A legal hold temporarily overrides ordinary destruction for relevant information. The organization should preserve what falls within the hold, suspend conflicting deletion, document custody, and resume the approved schedule when authorized.

Retention is not the same as backup

A retention policy determines how long information should remain available for a purpose or obligation. A backup supports recovery after loss or corruption. Treating backup media as an indefinite archive makes retrieval, access control, legal response, and deletion difficult.

Backup design should reflect retention requirements, but the two processes have different goals. A record may require long-term preservation in an archive with controlled format and metadata while short-term operational backups rotate more frequently.

End of life and end of support

End of Life (EOL) generally means a product or asset has reached the end of its planned lifecycle or commercial availability. In practical terms, the product is no longer sold.

End of Support (EOS) means the provider no longer supplies official patches, updates, or technical help. If replacement parts are still available, they may become harder to find and more expensive.

The exact vendor terminology varies. Focus on the risk: unsupported assets may retain known vulnerabilities, incompatible dependencies, unavailable parts, expired licenses, or staff knowledge that is disappearing.

The appropriate response may be replacement, migration, isolation, compensating controls, reduced functionality, contract extension, or documented risk acceptance. Inventory should identify approaching dates early enough for funding, testing, data transfer, and secure disposal.

9. Address data remanence and destruction

Data remanence means deleted data can still remain on a storage device and may be recoverable. Deleting a file, formatting a drive, or removing a directory entry does not always erase the underlying information.

Sanitization should make access to the target data infeasible for the required level of effort. The method depends on media type, sensitivity, reuse plan, threat, available assurance, and organizational standard.

Clear, purge, and destroy

Cryptographic erase can be effective when strong encryption protected all target data and the relevant keys can be reliably sanitized. It fails when unencrypted copies exist, keys remain recoverable, encryption was implemented incorrectly, or the organization cannot prove which data and keys were covered.

Modern environments complicate sanitization. Data may reside in cloud storage, solid-state media, snapshots, deduplicated systems, replicas, shared infrastructure, or provider-managed backups. Contracts and architecture should address deletion and return before data is placed there.

Verify and document destruction

A sound sanitization program defines approved methods, authorized tools or providers, validation, records, exceptions, and custody. Evidence may include asset identifiers, method, date, responsible party, result, and certificate of destruction.

Do not confuse completion with effectiveness. Verification confirms that the expected process occurred. Validation assesses whether the result meets the required sanitization outcome. Highly sensitive assets may require independent checks or witnessed destruction.

10. Determine data security controls and compliance requirements

Controls should follow the asset across data states and locations. A solution that protects storage but exposes data during processing or transfer leaves a gap.

Data states

Encryption is important, but it does not establish authorized use, correct classification, accurate data, suitable retention, or secure deletion. Keys, identities, applications, endpoints, and administrators can still expose encrypted data.

Protection methods in the outline

Digital Rights Management (DRM) attaches usage restrictions to protected content, such as limits on viewing, copying, printing, forwarding, or expiration. It can support policy enforcement after distribution, but it depends on compatible clients, identity, keys, and trust in the enforcement environment.

Data Loss Prevention (DLP) identifies and monitors sensitive content and can block, warn, quarantine, encrypt, or record actions involving data at endpoints, across networks, or in repositories. DLP needs accurate classification, tuned rules, exception handling, and response processes. A flood of false positives can cause users to bypass the control or analysts to ignore alerts.

A Cloud Access Security Broker (CASB) helps an organization see and control how people use cloud services. Depending on how it is connected, it can enforce access rules, protect data, detect threats, and support compliance.

CASBs can work through proxies, application programming interfaces, or controls built into the cloud provider. The connection method affects what the CASB can see and block.

Other methods include access control, encryption, tokenization, masking, rights management, secure enclaves, database activity monitoring, information flow controls, integrity validation, backups, and physical safeguards.

Scope, tailor, and select standards

Do not apply a control catalog mechanically. Determine scope first:

• Which information and assets are included?
• Which systems, locations, suppliers, and lifecycle phases are included?
• Which legal, contractual, privacy, and industry requirements apply?
• Which threats and impacts matter?
• Which inherited controls already exist?
• Which exceptions or alternative implementations are justified?

Tailoring adjusts a baseline to the organization's risk, environment, and obligations. It may add controls, strengthen parameters, remove inapplicable controls with justification, or use compensating controls. The result should remain traceable to the requirement and approved by the proper authority.

A standard or framework can provide structure, but it cannot decide business ownership, classification, retention, or acceptable residual risk for the organization.

11. Protect artificial intelligence assets

The current ISC2 guidance integrates artificial intelligence throughout the CISSP domains. In Domain 2, treat AI data and models as assets with their own classification, ownership, lineage, lifecycle, and destruction requirements.

Relevant assets may include:

• Training, validation, and test data
• Labels, prompts, system instructions, and evaluation sets
• Pretrained and fine-tuned models
• Model weights and checkpoints
• Embeddings and vector databases
• Retrieval sources and knowledge bases
• Feature stores and transformation pipelines
• Outputs, feedback, telemetry, and audit logs
• Application programming interface keys, service accounts, and deployment configurations

Training data integrity affects model behavior. Poisoned, mislabeled, outdated, or unauthorized data can produce harmful results even when the model infrastructure is secure. Record provenance, approved use, transformations, quality checks, access, and version history.

Models and weights may contain intellectual property, encode sensitive patterns, or expose information about training data. Classify them according to value and risk rather than assuming they are ordinary software files. Restrict export, copying, and third-party reuse.

Privacy controls may include purpose limitation, minimization, masking, tokenization, access restrictions, deletion workflows, and techniques such as differential privacy where appropriate. A provider promise that data is not used for training does not eliminate the need to understand logs, retention, subprocessors, geographic location, security, and deletion.

AI assets also create derived-data questions. An embedding, summary, or model output may remain sensitive even when it no longer resembles the source record. Evaluate the result instead of assuming transformation removed the obligation.

12. Common CISSP exam traps

Letting the custodian make the business decision

Administrators implement controls, but owners normally approve classification, access, retention, and risk. Escalate an unresolved business decision to the accountable owner rather than allowing the most technical person to decide by convenience.

Choosing a control before identifying the asset

A DLP system cannot compensate for unknown data, missing ownership, or undefined handling rules. Identify and classify first unless the scenario says those steps are complete.

Treating classification as a confidentiality-only exercise

Integrity and availability may drive the highest impact. Consider privacy, safety, mission, and legal consequences as well.

Assuming encryption completes protection

Encryption does not correct excessive access, bad retention, compromised endpoints, weak keys, inaccurate data, or authorized misuse. Match controls to the full lifecycle and data state.

Confusing retention with backup

Retention defines how long information should exist for a purpose or obligation. Backup supports recovery. Long-term records may need an archive, not an untouched pile of operational backups.

Confusing deletion with sanitization

A delete command may only remove a reference. Choose an approved sanitization method based on media, sensitivity, reuse, and assurance, then verify the outcome.

Inventorying only hardware

Cloud services, accounts, certificates, data sets, source code, licenses, models, application programming interfaces, and business knowledge can be critical assets even without a serial number.

Assuming outsourcing transfers accountability

A processor or service provider performs work, but the organization may retain ownership, controller duties, contractual obligations, and responsibility for oversight.

Ignoring end-of-support risk

A functioning asset can still be unacceptable when patches, parts, expertise, or vendor support are no longer available. Plan migration before the deadline becomes an emergency.

13. Domain 2 review checklist

You should be able to explain or apply each of the following:

• Distinguish information classification from broader asset classification.
• Classify according to potential impact across confidentiality, integrity, availability, privacy, safety, obligations, and business value.
• Explain why aggregation and inference can increase sensitivity.
• Assign classification decisions to the owner and implementation duties to custodians and other supporting roles.
• Translate a label into requirements for creation, access, storage, transfer, copying, sharing, transport, retention, and disposal.
• Build an inventory that includes tangible and intangible assets, ownership, location, dependencies, support status, and lifecycle state.
• Compare data owner, controller, custodian, processor, user, and data subject.
• Follow data through collection, location, maintenance, transformation, retention, remanence, and destruction.
• Distinguish retention schedules, legal holds, archives, and backups.
• Explain the operational risk of End of Life and End of Support.
• Compare clear, purge, destroy, and cryptographic erase at a decision level.
• Explain why sanitization must cover cloud copies, snapshots, backups, replicas, and third-party holdings.
• Protect data in use, in transit, and at rest.
• Compare Digital Rights Management, Data Loss Prevention, and Cloud Access Security Broker capabilities.
• Scope and tailor controls according to assets, obligations, risk, and environment.
• Treat training data, models, weights, embeddings, prompts, outputs, and AI logs as governed assets.
• Choose the correct next action based on what the scenario has already completed.

14. Official references

Use these primary sources to confirm scope and study the underlying practices:

• ISC2 CISSP Certification Exam Outline
• NIST FIPS 199: Standards for Security Categorization of Federal Information and Information Systems
• NIST SP 800-60 Volume 1 Revision 1: Guide for Mapping Types of Information and Information Systems to Security Categories
• NIST SP 800-53 Revision 5: Security and Privacy Controls for Information Systems and Organizations
• NIST SP 800-88 Revision 2: Guidelines for Media Sanitization
• NIST SP 1800-28: Data Confidentiality, Identifying and Protecting Assets Against Data Breaches
• NIST Privacy Framework
• NIST Artificial Intelligence Risk Management Framework

Exam objectives and organizational requirements can change. Use the current ISC2 outline for exam scope and the versions of laws, standards, contracts, and policies that apply to your environment.