Domain 5 accounts for 17.3% of the ISC2 Certified in Cybersecurity (CC) outline effective September 1, 2026. It is where many earlier concepts become day-to-day security work: protecting data, monitoring activity, deciding what deserves attention, responding to incidents, maintaining assets, and testing whether safeguards work.
The five objectives cover different stages of the operating lifecycle:
- protect information according to its sensitivity and purpose;
- observe systems and prioritize meaningful security events;
- respond to incidents through a prepared and exercised process;
- keep assets secure through configuration, change, maintenance, and retirement;
- test security so weaknesses are found before attackers exploit them.
1. Domain 5 map
| Objective | Official focus | Useful question |
|---|---|---|
| 5.1 | Data security: classification, labeling, masking, sanitization, symmetric and asymmetric cryptography, hashing, quantum-resistant cryptography | How sensitive is the information, how should it be handled, and what protection fits the data state or lifecycle stage? |
| 5.2 | Security operations: logs, monitoring, triage, prioritization, correlation, threat actors, Cyber Threat Intelligence (CTI), threat frameworks | What happened, how important is it, what other evidence changes the meaning, and what should happen next? |
| 5.3 | Incident Response (IR): incident response plan, data handling, testing, tabletop exercises | Is this an incident, who has authority, what evidence must be preserved, and which response step is appropriate now? |
| 5.4 | Asset protection: lifecycle and end-of-life, configuration management, change management | Is the asset known, supported, securely configured, deliberately changed, and retired without leaving data or access behind? |
| 5.5 | Security testing: blue, purple, and red teams; vulnerability scans; static and dynamic analysis; threat modeling; physical penetration testing | What weakness or control is being tested, how realistic is the test, and what authorization and safety boundaries apply? |
2. Data security begins with knowing what the data requires
Data security decisions depend on sensitivity, business value, legal or contractual requirements, location, lifecycle stage, and the way information is used.
A useful sequence is:
- identify the data;
- classify it;
- label or mark it where appropriate;
- apply handling and access requirements;
- protect it in storage, use, and transit;
- retain it only as required;
- sanitize media or data when the information should no longer remain recoverable.
3. Classification and labeling
Classification assigns a category based on sensitivity, value, or handling requirements.
Labeling communicates that classification or handling requirement to people or systems.
An organization might use labels such as public, internal, confidential, or restricted, but the actual names and rules vary. Focus on the purpose rather than memorizing one organization's categories.
Classification can influence access, encryption, storage, sharing, retention, disposal, sanitization, monitoring, and logging expectations.
A label is useful only when the organization has a process behind it. Marking a file "confidential" does not protect it if access, storage, sharing, and disposal rules do not follow.
4. Masking and sanitization solve different problems
Data masking
Masking hides or substitutes sensitive values so the original information is not exposed to someone who does not need it.
Examples include displaying only part of an account number, substituting realistic but non-sensitive values in a test dataset, or obscuring an identifier in a user interface.
The goal is continued use of the dataset or application without unnecessary exposure of the original sensitive value.
Sanitization
Sanitization removes or makes data inaccessible so it cannot be recovered through means appropriate to the media and risk.
NIST SP 800-88 Rev. 2 describes sanitization techniques such as clear, purge, and destroy, selected according to the media, confidentiality needs, and reuse or disposal decision.
| Concept | Primary purpose | Typical situation |
|---|---|---|
| Masking | Reduce exposure while data remains useful | A support user needs to recognize a customer record without viewing the full sensitive identifier. |
| Sanitization | Prevent recovery when data should no longer remain on the media or storage location | A storage device is being reused, transferred, or retired. |
5. Symmetric, asymmetric, and hashing
| Mechanism | Basic idea | Common security use |
|---|---|---|
| Symmetric cryptography | The same shared secret key is used for encryption and decryption. | Efficient confidentiality for data at rest or in transit when parties can securely share the key. |
| Asymmetric cryptography | A mathematically related public/private key pair supports operations where the two keys have different roles. | Key establishment, digital signatures, identity-related protocols, and other uses where sharing one secret key is not practical. |
| Hashing | A one-way function produces a fixed-size digest from input data. | Integrity checking, password-verification designs, digital-signature workflows, and comparison of data without reversible encryption. |
Hashing is not encryption. Encryption is intended to be reversed by someone with the correct key. A secure hash is designed as a one-way transformation.
6. Quantum-resistant cryptography
The September 2026 CC outline explicitly includes quantum-resistant cryptography.
The concern is that sufficiently capable future quantum computers could undermine some widely used public-key algorithms. Quantum-resistant, or post-quantum, cryptography uses algorithms designed to resist known attacks from both conventional and quantum computers.
NIST finalized its first post-quantum cryptography standards in 2024, including FIPS 203 for a module-lattice-based key-encapsulation mechanism.
At the CC level, focus on the reason for transition: algorithms have lifecycles, organizations need inventory and migration planning, and data requiring long-term confidentiality may need protection before practical quantum attacks exist.
7. Security operations: turn activity into useful decisions
Security operations observe systems, applications, identities, networks, and other assets so meaningful security activity can be recognized and acted on.
Potential data sources include authentication logs, operating-system logs, application logs, firewall and network-device logs, endpoint events, cloud audit logs, vulnerability results, identity changes, and alerts from security tools.
Collecting logs is not the same as monitoring them effectively. The organization needs enough context to know which events matter.
8. Triage, prioritization, and correlation
Triage is the initial process of determining what an event means and what attention it deserves.
Useful questions include whether the alert is credible, which asset or account is involved, how sensitive or critical it is, whether the behavior is expected, whether compromise succeeded, and whether another event changes the interpretation.
Prioritization uses factors such as asset criticality, data sensitivity, scope, detection confidence, known exploitation, account privilege, and business impact.
Correlation connects multiple events or data sources to reveal meaning that a single log entry may not show.
For example, an unusual login followed by a privileged-role change and a large data transfer may tell a more serious story than any one event alone.
More alerts do not automatically mean better security. Effective operations reduce noise enough that meaningful activity can be recognized, prioritized, and investigated.
9. Threat actors, CTI, and threat frameworks
A threat actor is a person, group, organization, or other entity that can cause or contribute to harmful activity.
Cyber Threat Intelligence (CTI) turns information about threats into context that supports decisions. Useful CTI can help identify relevant actors, techniques, exploited vulnerabilities, indicators, behaviors, and defensive priorities.
Threat frameworks provide structured ways to describe adversary behavior.
MITRE ATT&CK is a knowledge base that organizes observed adversary behavior into tactics and techniques. For CC, understand the purpose: it gives defenders a common language for describing behavior, mapping detections, and identifying defensive gaps.
A threat framework is not a list of guaranteed attack steps. It organizes known behavior so teams can reason more consistently.
10. Incident response: prepare before the pressure arrives
An event becomes an incident when it meets the organization's criteria for a cybersecurity incident and requires coordinated response.
NIST SP 800-61 Rev. 3 aligns incident-response recommendations with broader cybersecurity risk management. At the CC level, the important idea is that response should be planned, authorized, coordinated, documented, and improved over time.
An incident-response plan should make roles, escalation paths, communications, decision authority, evidence handling, coordination, recovery, and return-to-normal considerations clearer before an emergency.
The plan is not a script for every possible incident. It provides structure so people can make faster, more consistent decisions.
11. Data and evidence handling during incidents
Incident data can become important for investigation, recovery, reporting, legal obligations, disciplinary actions, or lessons learned.
Useful handling practices include preserving relevant logs and artifacts, recording how evidence was collected, protecting it from unauthorized alteration, restricting access, using approved storage and transfer methods, maintaining useful time synchronization, and documenting significant response actions.
Chain of custody
When evidence may be used in a formal investigation or legal process, chain-of-custody records can document who possessed or handled the evidence, when transfers occurred, and what actions were taken.
The purpose is accountability and confidence in the evidence's integrity.
12. Test the incident-response process before a real incident
Plans should be exercised because gaps are easier to fix before an emergency.
A tabletop exercise walks participants through a simulated scenario and asks them to discuss decisions, communications, responsibilities, and response actions.
Tabletops can expose unclear ownership, outdated contacts, missing escalation criteria, conflicting assumptions, inaccessible documentation, communication gaps, and dependencies no one considered.
A tabletop is not the same as a live technical test. Its strength is exercising decision-making and coordination with limited operational risk.
After an exercise, capture lessons and update the plan rather than treating completion as the goal.
13. Asset protection across the lifecycle
A lifecycle perspective includes acquisition or creation, approved configuration, deployment, operation, maintenance, change, reassignment, and retirement.
Unknown or unsupported assets are difficult to protect because the organization may not know which vulnerabilities, data, accounts, or dependencies they contain.
End-of-life risk
When a vendor or organization no longer supports an asset, security updates may stop. The organization then needs a deliberate decision: replace it, isolate it, reduce exposure, add compensating controls, or accept the documented risk under appropriate authority.
Retirement should also consider account removal, data retention or sanitization, encryption keys and secrets, licenses, cloud resources, monitoring, inventory records, and dependent systems.
14. Configuration and change management
Configuration management establishes and maintains approved settings for systems and services. It can include secure baselines, documented settings, drift detection, privileged-change control, asset information, and exception review.
Change management controls how modifications are requested, evaluated, approved, tested, implemented, documented, and reviewed.
Security matters because a legitimate change can introduce new exposure, incorrect access, outages, broken logging, incompatible controls, or configuration drift.
Patch management fits the lifecycle
Patches and updates are changes. NIST SP 800-40 Rev. 4 treats enterprise patch management as a risk-management activity rather than a purely technical task.
Organizations balance vulnerability urgency, exposure, asset criticality, testing needs, operational impact, and rollback or recovery options.
15. Security testing: find weaknesses and validate controls
Security testing provides evidence about weaknesses, defensive capability, or control effectiveness.
Testing should have authorization, defined scope, rules of engagement, safety constraints, appropriate data handling, and a process for reporting and remediation.
Unauthorized testing can itself be a security or legal problem.
16. Blue, red, and purple teams
| Team | Primary perspective | Useful question |
|---|---|---|
| Blue team | Defensive operations and detection | Can the organization prevent, detect, investigate, and respond to the tested behavior? |
| Red team | Authorized adversary emulation | Can a realistic attacker achieve agreed objectives within the rules of engagement? |
| Purple team | Collaboration between offensive and defensive perspectives | How can both sides share observations quickly to improve controls and detections? |
Purple teaming is not simply a third independent color. Its value comes from collaboration and feedback between offensive and defensive work.
17. Vulnerability scans, analysis, threat modeling, and physical testing
Vulnerability scanning
A vulnerability scanner looks for known weaknesses, missing patches, insecure configurations, exposed services, or other detectable conditions.
A scan can identify candidates for investigation. It does not prove that every finding is exploitable, important, or correctly prioritized.
Static analysis
Static analysis examines code, binaries, configurations, or other artifacts without executing the application in its normal running state.
Dynamic analysis
Dynamic analysis examines a running application or system and observes behavior during execution.
Static and dynamic methods can find different classes of problems, so they are complementary rather than interchangeable.
Threat modeling
Threat modeling is a structured way to identify what needs protection, what could go wrong, where trust boundaries exist, and which mitigations should be considered before or during design.
Physical penetration testing
Authorized physical penetration testing evaluates whether physical security controls can prevent or detect access to facilities, equipment, or restricted areas.
It requires clear rules because real safety, privacy, property, and legal concerns are involved. Physical testing is not permission to improvise outside scope.
18. Common Domain 5 exam traps
Classification and labeling are related but not identical
Classification assigns sensitivity or handling category. Labeling communicates that category or requirement.
Masking is not sanitization
Masking hides sensitive values while data remains useful. Sanitization removes recoverable data when it should no longer remain.
Hashing is not encryption
A hash is a one-way digest. Encryption is designed to be reversed with the proper key.
Quantum-resistant does not mean quantum encryption
The objective is about cryptographic algorithms designed to resist quantum attacks and migration away from vulnerable public-key approaches.
A log is not automatically an alert or incident
Logs are evidence. Monitoring and detection may create alerts. Triage determines meaning and priority. Incident criteria determine when coordinated response begins.
Threat intelligence is not a list of indicators
Useful CTI provides context that supports decisions about threats, behaviors, priorities, and defenses.
A tabletop is not a live penetration test
Tabletops exercise coordination and decisions. Technical testing evaluates systems or controls more directly.
Configuration management is not change management
Configuration management maintains known approved states. Change management governs how modifications are evaluated and introduced.
A vulnerability scan is not a penetration test
Scanning identifies potential weaknesses. Penetration testing attempts to validate exploitable paths within authorized scope.
Red team and purple team have different goals
Red teams emulate adversaries. Purple teaming emphasizes collaboration to improve detection and defense.
19. Rapid review checklist
Before leaving Domain 5, make sure you can explain:
- [ ] Classification versus labeling
- [ ] Masking versus sanitization
- [ ] Symmetric versus asymmetric cryptography
- [ ] Hashing versus encryption
- [ ] Why quantum-resistant cryptography matters
- [ ] Logs, monitoring, triage, prioritization, and correlation
- [ ] Threat actors and Cyber Threat Intelligence (CTI)
- [ ] The purpose of threat frameworks such as MITRE ATT&CK
- [ ] What an incident-response plan establishes
- [ ] Why evidence and incident data need controlled handling
- [ ] What tabletop exercises reveal
- [ ] Asset lifecycle and end-of-life risk
- [ ] Configuration management versus change management
- [ ] Why patching is part of risk and change management
- [ ] Blue, red, and purple team purposes
- [ ] Vulnerability scanning versus penetration testing
- [ ] Static versus dynamic analysis
- [ ] Threat modeling
- [ ] Why physical penetration testing requires explicit authorization and scope
20. Official and primary references
Use the ISC2 outline as the authoritative scope for this domain:
Primary references that add context:
- NIST SP 800-61 Rev. 3: Incident Response Recommendations and Considerations for Cybersecurity Risk Management
- NIST SP 800-88 Rev. 2: Guidelines for Media Sanitization
- NIST SP 800-40 Rev. 4: Guide to Enterprise Patch Management Planning
- NIST SP 800-115: Technical Guide to Information Security Testing and Assessment
- NIST FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism Standard
- MITRE ATT&CK
These sources add depth for incident response, sanitization, maintenance, testing, post-quantum cryptography, and threat analysis. They do not replace the ISC2 exam outline as the coverage checklist.
CertHappens is an independent study resource and is not affiliated with or endorsed by ISC2.