About this edition & how to use the guide
How the companion is controlled, how to study with it, and what the guide does and does not claim.
About this edition
Edition 2026.1 is built specifically for the ISC2 Certified in Cybersecurity (CC) examination outline effective 1 September 2026. It is a comprehensive certification companion: more detailed than a revision sheet, but intentionally shorter and more exam-directed than a full textbook. The goal is to build accurate mental models, practical security reasoning and a path from first principles toward professional practice.
| Field | Value |
|---|---|
| Guide | CC Study Guide — Free Community Edition |
| Series | Cyber Master Series — Certification Study Series |
| Edition | 2026.1 |
| Target outline | ISC2 CC Certification Exam Outline — effective 1 September 2026 (v01/2026) |
| Last reviewed | 18 August 2026 |
| Author | Taher Amine ELHOUARI |
| Public web edition | Publication page · Interactive edition |
| Public PDF | Edition 2026.1 — Final author-approved release |
| License | CC BY-NC 4.0 unless a release states otherwise |
This guide targets the new CC outline effective 1 September 2026. If you take the CC exam before that date, use the currently active outline and do not assume the 2026 domain weights apply yet.
Source hierarchy
- The ISC2 CC Certification Exam Outline effective 1 September 2026 determines domain names, weights, objective numbering and required scope.
- ISC2 certification, examination and official update pages are used for current exam format, availability, prerequisite and transition information.
- NIST, ISO/IEC and other primary technical sources are used only to clarify supporting concepts; they do not replace ISC2 wording or expand the exam into another certification curriculum.
- Examples, memory aids, scenarios and study strategy are independently authored. No recalled live exam questions, dumps or NDA-protected content are used.
Every official objective is covered. Supporting material is explicitly labeled when it goes beyond the outline and is included only when it improves understanding or helps distinguish commonly confused concepts.
How to use this guide
| Phase | What to do |
|---|---|
| 1 — Map | Read the Exam Overview and objective map. Note the five domains and the 1 September 2026 effective date. |
| 2 — Learn | Study domain-by-domain. Focus on relationships rather than isolated vocabulary. |
| 3 — Apply | Use scenario lenses. Identify the actor, authority, asset/data, risk and appropriate control or process. |
| 4 — Review | Use the Quick Reference section and memory anchors during final-week reinforcement. |
| 5 — Validate | Check the current ISC2 outline and exam policies again shortly before the exam. |
This guide is free for independent study. Taher Amine ELHOUARI also provides paid cybersecurity fundamentals training, workshops, mentoring and tailored learning programs for individuals, teams and organizations. For structured support, visit TaherAmine.org or email contact@taheramine.org.
1. Exam Overview & 2026 Changes
The refreshed exam model, domain weights, transition date and the structural changes you need to understand.
The 2026 outline keeps five domains but reorganizes them around modern entry-level practice, with greater emphasis on governance, identity lifecycle, cloud security, threat intelligence, incident response and security testing. Foundational AI concepts are integrated across all five domains; AI is treated here as a cross-domain thread rather than a separate numbered objective.
| Exam attribute | CC 2026 information |
|---|---|
| Exam model | Computerized Adaptive Testing (CAT) |
| Administration time | 2 hours |
| Items | 100–125 |
| Item types | Multiple choice and advanced item types |
| Passing grade | 700 out of 1000 points |
| Exam availability | English, Simplified Chinese, Japanese, German, Spanish |
| Testing center | Pearson VUE Testing Center |
| Experience | No specific prerequisites; basic IT knowledge is recommended. No cybersecurity work experience or formal degree is required. |
ISC2 does not allow candidates to skip an item and return later. Read carefully, make the best-supported choice and move on. Do not infer pass/fail status from how difficult an item feels.
2026 domain weights
| Domain | Weight | Core emphasis |
|---|---|---|
| 1. Security Principles | 24% | Cybersecurity concepts, risk, governance, controls and professional/ethical conduct. |
| 2. Security Governance | 17.3% | GRC, redundancy, awareness/culture and measurement/reporting. |
| 3. Identity and Access Management (IAM) Concepts | 20% | Identity lifecycle, least privilege, separation of duties and access-control models. |
| 4. Networking and Cloud Security Concepts | 21.3% | Network concepts, segmentation, Zero Trust, cloud characteristics/models and shared security. |
| 5. Security Operations and Incident Response | 17.3% | Data security, operations, threat intelligence, incident response, assets and testing. |
What changed from the previous outline
| Previous outline | 2026 outline | What changed |
|---|---|---|
| Security Principles — 26% | Security Principles — 24% | Updated terminology, AAA, broader governance concepts, due care and due diligence. |
| BC/DR & Incident Response — 10% | Security Governance — 17.3% | GRC, security culture, metrics/KRIs and reporting become a dedicated governance domain; BC/DR remain under redundancy. |
| Access Controls — 22% | IAM Concepts — 20% | Identity lifecycle, provisioning/review/deprovisioning and IAM tools/frameworks are explicit. |
| Network Security — 24% | Networking & Cloud Security — 21.3% | Dedicated cloud security coverage, Zero Trust, modern segmentation, wireless and embedded systems. |
| Security Operations — 18% | Security Operations & Incident Response — 17.3% | Threat actors, CTI, threat frameworks, IR, asset lifecycle and security testing expand the operations focus. |
Foundational AI concepts are integrated throughout the refreshed CC body of knowledge. Use AI examples as contextual reinforcement: secure AI data and identities, recognize AI-assisted detection, understand governance/ethical implications, isolate sensitive AI environments, and avoid leaking protected information into unapproved AI services.
Security Principles
Objectives 1.1–1.5: security concepts, risk, governance, controls and professional/ethical conduct.
Domain 1 establishes the language used everywhere else. The exam can ask you to identify the security objective, recognize the risk, distinguish governance from controls and select conduct that respects authorization and professional responsibility.
1.1 Understand cybersecurity concepts
| Concept | Plain-language meaning | Simple example |
|---|---|---|
| Confidentiality | Prevent unauthorized disclosure. | Sensitive payroll data is visible only to approved roles. |
| Integrity | Protect accuracy and completeness against unauthorized change. | A software package is checked before installation to detect tampering. |
| Availability | Ensure authorized users can access systems/data when needed. | Redundant services and tested recovery reduce outage impact. |
| Authentication | Verify the claimed identity. | MFA confirms a user with more than one factor. |
| Authorization | Decide what an authenticated identity is allowed to do. | A user can view invoices but cannot approve payments. |
| Accounting | Record relevant activity so actions can be traced and reviewed. | Administrative changes are logged with identity, time and result. |
| Non-repudiation | Support evidence that an actor performed an action and cannot credibly deny it. | A digital signature can support origin/integrity evidence when key custody is trustworthy. |
| Privacy | Handle personal information according to applicable rights, expectations and requirements. | Collect only needed personal data and restrict its use/retention. |
Confidentiality matters when prompts or datasets contain sensitive information; integrity matters when training/retrieval data or model behavior can be manipulated; availability matters when AI becomes a business dependency.
1.2 Understand risk management concepts
| Term | Remember |
|---|---|
| Asset | Something of value that needs protection. |
| Threat | A circumstance or actor that could cause harm. |
| Vulnerability | A weakness that could be exploited or contribute to failure. |
| Likelihood | How plausible/frequent the event is in the stated context. |
| Impact | The consequence if the event occurs. |
| Inherent risk | Risk before considering selected controls. |
| Residual risk | Risk remaining after controls are considered. |
| Risk appetite | The amount/type of risk an organization is willing to pursue or retain in pursuit of objectives. |
| Risk tolerance | Acceptable variation or threshold around a specific risk/objective. |
| Treatment | Meaning | Example |
|---|---|---|
| Mitigate / reduce | Apply controls to reduce likelihood and/or impact. | MFA and least privilege reduce account-compromise exposure. |
| Avoid | Stop the activity that creates the unacceptable risk. | Do not launch a service if required controls cannot be met. |
| Transfer / share | Shift or share defined financial/operational consequences through another party or mechanism. | Insurance or contractual risk allocation. |
| Accept | Make an authorized decision to retain the risk. | A low-impact residual risk is documented within risk appetite. |
A vulnerability is not automatically a high risk. Exposure, asset value, threat context, existing controls and business impact matter.
1.3 Understand governance concepts
| Instrument | Purpose | Question it answers |
|---|---|---|
| Regulation / law | Creates externally enforceable obligations. | What must the organization obey? |
| Framework / guideline | Organizes recommended practices or a structured approach. | How can we structure security work? |
| Policy | States management intent and mandatory organizational direction. | What does management require? |
| Standard | Defines specific mandatory internal requirements or approved methods. | What minimum must be met? |
| Procedure | Explains the steps used to perform a task consistently. | How do I perform this activity? |
Policies state direction. Standards define mandatory detail. Procedures describe the steps. Frameworks/guidelines organize practices. Laws/regulations impose external obligations.
1.4 Understand cybersecurity controls
| Control type | Examples | What changes |
|---|---|---|
| Technical | MFA, firewall, encryption, endpoint protection, logging. | Technology enforces or monitors a security requirement. |
| Administrative | Policy, training, risk assessment, access review, vendor process. | People/process/governance shape behavior and decisions. |
| Physical | Locks, guards, barriers, cameras, environmental safeguards. | Physical access and environmental risk are constrained. |
| Functional lens | Meaning | Example |
|---|---|---|
| Preventive | Reduce the chance an unwanted event succeeds. | Least privilege; strong authentication. |
| Detective | Identify suspicious or policy-violating activity. | Monitoring and alerting. |
| Corrective | Fix or limit impact after a problem is discovered. | Remove malware; restore secure configuration. |
| Recovery | Restore service/data/capability after disruption. | Validated restore from protected backup. |
Do not expect one control to solve the whole problem. Sensitive access may combine identity proofing, MFA, least privilege, segmentation, logging and review.
1.5 Maintain professional and ethical conduct
| Concept | Meaning |
|---|---|
| Professional code of conduct | Expected professional behavior, accountability and responsible use of authority. |
| Due care | Taking reasonable protective action expected under the circumstances. |
| Due diligence | Sustained investigation, verification and monitoring before and after decisions. |
| Authorization | Do not exceed approved scope simply because you technically can. |
| Competence | Recognize limits, validate assumptions and seek qualified help when needed. |
The 2026 CC outline explicitly names the ISC2 Code of Ethics, due care and due diligence. The Code of Ethics remains a certification requirement.
Domain 1 review
- CIA = confidentiality, integrity, availability.
- AAA = authentication, authorization, accounting.
- Risk is a lifecycle; controls reduce risk but residual risk remains.
- Governance instruments operate at different levels: law/regulation, framework/guideline, policy, standard, procedure.
- Controls can be technical, administrative or physical.
- Due care is responsible action; due diligence is sustained investigation and verification.
Security Governance
Objectives 2.1–2.4: GRC, resilience, awareness, culture, measurement and reporting.
Security Governance connects management direction, risk decisions, compliance evidence, resilience, culture and measurement. The goal is repeatable decision-making and accountability rather than paperwork for its own sake.
2.1 Plan Governance, Risk and Compliance (GRC)
| GRC element | Primary question | Evidence/result |
|---|---|---|
| Governance | Who sets direction, owns decisions and is accountable? | Policies, objectives, roles, approvals and oversight. |
| Risk | What uncertainty can affect objectives and how should it be treated? | Risk register, assessment, treatment decision and residual-risk acceptance. |
| Compliance | Which obligations/requirements apply and can we demonstrate adherence? | Control mapping, evidence, assessments, remediation tracking. |
Frameworks provide structure for governance, risk and compliance activities. GRC tools can support risk registers, requirement/control mapping, evidence, exceptions and remediation workflows. They support accountable decision-making; they do not replace ownership or judgment.
A checklist can be complete while real risk remains. Compliance is evidence that defined requirements were addressed; security decisions still depend on threats, architecture, scope and effectiveness.
2.2 Understand redundancy
| Concept | Primary goal | Common confusion |
|---|---|---|
| Redundancy | Provide alternate components/paths so a failure does not stop the service. | More than one component is not useful if both share the same failure point. |
| Business Continuity (BC) | Maintain critical business capability during disruption. | BC is broader than technology recovery. |
| Disaster Recovery (DR) | Restore technology/services after major disruption. | DR is not the same as routine high availability. |
| Backup | Maintain recoverable copies of data/configuration. | A backup is not recovery until restoration is tested and timely. |
RTO (target time to restore) and RPO (target maximum tolerable data loss measured in time) are useful foundational concepts for understanding why recovery design and backup frequency differ.
2.3 Understand security awareness
| Threat / behavior | What to recognize | Good response |
|---|---|---|
| Phishing | Deceptive messages that pressure the user to click, disclose or act. | Pause, verify through a trusted channel and report using the approved process. |
| Smishing / vishing | Phishing through SMS or voice. | Independently verify sensitive requests. |
| Pretexting / impersonation | A believable story is used to obtain access or information. | Confirm identity/authority through an independent channel. |
| Password protection | Weak/reused credentials increase compromise impact. | Use unique credentials, approved password management and MFA where required. |
| Tailgating | Someone follows an authorized person into a restricted area. | Follow physical access policy; challenge/report according to procedure. |
Generative AI can make phishing, impersonation and synthetic media more convincing. Verify high-impact requests through trusted, independent channels.
2.4 Measure cybersecurity effectiveness
| Measure | What it tells you | Example |
|---|---|---|
| Key metric | Performance/state of an important security activity. | Percentage of critical systems with MFA enforced. |
| KRI | Signal that risk exposure may be increasing or approaching a threshold. | Number of unsupported internet-facing assets. |
| Dashboard | Visual summary for frequent monitoring. | Current exposure, incidents, overdue actions and trends. |
| Scorecard | Structured view of performance against defined criteria. | Control-area status by target/owner. |
| Report | Context-rich communication for a specific audience/decision. | Quarterly risk and control report to leadership. |
| Weak metric | Why it is weak | Better direction |
|---|---|---|
| Number of alerts | More alerts may mean better visibility or more noise. | High-severity alerts investigated within defined target and with outcome. |
| Training completed | Completion does not prove behavior changed. | Reporting rate, simulation trend and observed behavior over time. |
| 100% compliant | May hide scope, exceptions or ineffective controls. | Compliance status plus residual risk, exceptions, evidence quality and actions. |
Domain 2 review
- Governance sets direction and accountability; risk prioritizes uncertainty; compliance demonstrates obligations/evidence.
- Redundancy, BC, DR and backup solve different problems.
- Security awareness includes culture, leadership, social engineering recognition and safe behavior.
- Metrics and KRIs should be defined, contextual and connected to decisions.
Identity and Access Management (IAM) Concepts
Objectives 3.1–3.2: identity lifecycle, frameworks/tools, least privilege, separation of duties and access models.
Identity is a security boundary: access should exist only for a defined purpose, owner and period, and it should change as people, roles or services change.
3.1 Understand identity life cycle management
| Lifecycle activity | What should happen | Common risk if weak |
|---|---|---|
| Role definition | Define responsibilities and the access needed to perform them. | Overbroad roles and unclear ownership. |
| Provision | Create identity and grant approved initial access. | Default/excess permissions or shared accounts. |
| Review | Confirm access is still required and appropriate. | Dormant, stale or excessive access remains. |
| Role change | Adjust access when duties, location, project or risk changes. | Old privileges remain after a move/change. |
| Deprovision | Disable/remove access promptly when no longer needed. | Former users/services retain usable access. |
IAM frameworks and tools support identity lifecycle governance, provisioning, access review and deprovisioning. Common tool categories include directories/identity providers, IAM/IGA platforms, privileged-access management and lifecycle automation. For CC, understand their purpose rather than memorizing vendors.
Identity types to recognize
| Identity type | Example | Security emphasis |
|---|---|---|
| Human user | Employee, contractor. | MFA, lifecycle, role, access review, behavior. |
| Privileged identity | Administrator, root, security operator. | Stronger MFA, limited standing privilege, separate accounts and monitoring. |
| Service / machine identity | Application account, API client, workload identity. | Ownership, rotation, least privilege and lifecycle; avoid shared hard-coded secrets. |
| Shared account | Generic/team login. | Avoid where possible because accountability and lifecycle become weak. |
MFA combines independent factors such as something you know, something you have and something you are. Two passwords are still the same factor category; strong authentication does not replace authorization.
Bots, automated agents and AI services are identities too. They need an owner, provisioning, scoped permissions, review and deprovisioning just like other service identities.
3.2 Understand logical access controls
| Principle | Meaning | Example |
|---|---|---|
| Least privilege | Grant only the access needed for the task and time. | Help-desk staff can reset passwords but cannot modify payroll. |
| Need-to-know | Limit access to information required for the assigned purpose. | Project data is limited to approved participants. |
| Separation of Duties | Split incompatible or high-risk tasks across people/processes. | One person creates a vendor; another approves payment. |
| Default deny | Access is denied unless explicitly permitted. | A new role starts with no sensitive access until approved. |
| Access model | Decision basis | Memory cue |
|---|---|---|
| DAC — Discretionary Access Control | Resource owner/authorized owner decides access. | OWNER decides. |
| MAC — Mandatory Access Control | Centrally enforced labels/classification and policy. | LABELS decide. |
| RBAC — Role-Based Access Control | Permissions are assigned to roles; users receive roles. | ROLE decides. |
| ABAC — Attribute-Based Access Control (supporting context) | Attributes and policy conditions such as user, resource, device, action or context. | ATTRIBUTES decide. |
Access decision sequence
- Identify the identity and how it was authenticated.
- Identify the resource/action being requested.
- Apply the relevant policy/model and role/attributes.
- Enforce least privilege and separation of duties where required.
- Log or review high-impact access according to policy.
Authentication proves identity; it does not determine authorization. Least privilege does not mean “no privilege.” Separation of duties is not another name for least privilege. Deprovisioning is a security control, not an HR-only task.
Domain 3 review
- Know the lifecycle: define role, provision, review/change, deprovision.
- Review access periodically; remove stale, dormant and orphaned access.
- PoLP limits permissions; SoD separates conflicting duties.
- Recognize DAC, MAC and RBAC; understand ABAC as supporting context.
- Automated/service identities need the same ownership and lifecycle discipline as human identities.
Networking and Cloud Security Concepts
Objectives 4.1–4.3: network models, architecture, Zero Trust, cloud models and shared responsibility.
Domain 4 combines classic networking fundamentals with modern segmentation, Zero Trust and explicit cloud security. The exam expects you to recognize layers, common service behavior, security boundaries and shared responsibility.
4.1 Understand network security
| OSI layer | Purpose orientation | Examples |
|---|---|---|
| 7 Application | User/application services. | HTTP/HTTPS, DNS, application protocols. |
| 6 Presentation | Representation, encoding and cryptographic formatting concepts. | Data formatting/translation, encoding, encryption-related functions. |
| 5 Session | Establish/manage application sessions conceptually. | Session/dialog management. |
| 4 Transport | End-to-end delivery between hosts. | TCP, UDP. |
| 3 Network | Logical addressing and routing. | IP, routers. |
| 2 Data Link | Local network frames and media access. | Ethernet, MAC addresses, switches. |
| 1 Physical | Bits/signals on physical/wireless media. | Copper, fiber, radio. |
Use the four-layer TCP/IP model as a complementary lens: Application → Transport → Internet → Link/Network Access. OSI layers 5–7 broadly map into TCP/IP Application, while OSI layers 1–2 broadly map into Link/Network Access.
| Concept | Remember |
|---|---|
| TCP | Connection-oriented transport with sequencing/reliability mechanisms. |
| UDP | Connectionless transport with lower overhead; reliability is not built in the same way. |
| IPv4 | 32-bit addressing; NAT is common but not a security boundary by itself. |
| IPv6 | 128-bit addressing; organizations still need filtering, monitoring and secure configuration. |
| VPN | Creates a protected logical path across an untrusted/intermediate network; authorization still matters. |
| Firewall | Enforces network/application traffic policy according to its capabilities and rules. |
| Wi-Fi | Wireless access requires strong authentication/encryption and controlled configuration. |
| Bluetooth | Short-range wireless; pairing, discoverability and device hygiene matter. |
| ICS / embedded / IoT | Operational constraints, long lifecycles and safety/availability can change security priorities. |
Common ports — know the service, not only the number
| Port | Typical service | Security note |
|---|---|---|
| 22 | SSH | Secure remote administration; protect privileged access. |
| 53 | DNS | Name resolution; secure configuration and monitoring matter. |
| 80 | HTTP | Unencrypted web traffic unless protected by another mechanism. |
| 443 | HTTPS | HTTP over TLS; validate certificate/trust and application security too. |
| 3389 | RDP | Remote desktop; restrict exposure and require strong identity controls. |
Port numbers help identify common services, but security decisions should not assume a port guarantees the actual application or that encrypted traffic is automatically safe.
4.2 Understand network security architecture
| Architecture concept | Purpose | Important distinction |
|---|---|---|
| Firewall zone | Group systems with similar trust/security requirements and control traffic between zones. | A zone is only useful when traffic policy is enforced. |
| VLAN | Logical Layer 2 segmentation/broadcast separation. | A VLAN alone is not a complete security boundary. |
| Micro-segmentation | Fine-grained policy between workloads/services. | Useful for reducing lateral movement; enforcement may use identity/context as well as network attributes. |
| Defense in depth | Use multiple complementary controls across identity, network, application, data and monitoring. | No single layer is assumed perfect. |
| Zero Trust | Do not grant implicit trust because an identity/device is inside. | ZT is an architecture/principle set, not a single product. |
NIST SP 800-207 describes Zero Trust as an approach focused on protecting resources and removing implicit trust based on network location. Context may change, so access can be re-evaluated; “inside the network” is not a permanent trust decision.
4.3 Understand cloud security
| Cloud characteristic | Meaning |
|---|---|
| On-demand self-service | Users can provision capabilities without requiring human interaction for each request. |
| Broad network access | Capabilities are available over networks through standard mechanisms. |
| Resource pooling | Provider resources serve multiple consumers and are dynamically assigned. |
| Rapid elasticity | Capabilities can scale outward/inward quickly, often appearing effectively unlimited to the consumer. |
| Measured service | Usage can be metered, monitored and reported. |
| Service model | Customer generally focuses more on | Provider generally operates more of |
|---|---|---|
| IaaS | Guest OS, applications, data, identities, workload/network configuration. | Physical infrastructure and virtualization layer. |
| PaaS | Application code, data, identities, service configuration. | Runtime/platform and underlying infrastructure. |
| SaaS | Data, users/identities, tenant configuration and lawful use. | Application stack and underlying platform/infrastructure. |
| Deployment model | Basic idea |
|---|---|
| Public cloud | Cloud infrastructure available for open use by the general public/market through a provider. |
| Private cloud | Cloud infrastructure provisioned for exclusive use by one organization. |
| Community cloud | Cloud infrastructure provisioned for exclusive use by a specific community with shared concerns. |
| Hybrid cloud | Two or more distinct cloud infrastructures remain unique but are bound together for portability/interoperability. |
The exact boundary varies by provider/service. The customer typically retains responsibility for its data, identities, configuration choices and legal obligations, while the provider operates the layers included in the service. Always verify actual contract/service documentation.
A VLAN alone is not a complete security boundary. A VPN protects a path but does not automatically authorize every resource. Zero Trust is not a product. Private cloud is not automatically more secure than public cloud. Shared responsibility changes by service and contract.
Domain 4 review
- Know the purpose of OSI/TCP-IP models without memorizing implementation trivia.
- Understand TCP vs UDP, IP basics, VPNs, firewalls, wireless and embedded/ICS/IoT concerns.
- Segmentation reduces lateral movement and blast radius; defense in depth layers controls.
- Zero Trust removes implicit trust based on network location.
- Know NIST’s five cloud characteristics, IaaS/PaaS/SaaS and the four deployment models.
- Shared responsibility means responsibility shifts — it never disappears.
Security Operations and Incident Response
Objectives 5.1–5.5: data security, operations, CTI, incident response, assets and security testing.
Domain 5 links data protection, telemetry, triage, threat intelligence, incident response, asset lifecycle and security testing. The exam rewards disciplined operations: evidence, prioritization, authorization and repeatable process.
5.1 Understand data security
| Technique | Primary purpose | Key distinction |
|---|---|---|
| Classification | Assign sensitivity/handling category. | Classification should drive controls. |
| Labeling | Mark/associate the classification with data. | A label is useful only if people/systems act on it. |
| Masking | Obscure sensitive values for lower-trust use. | May preserve format while reducing exposure. |
| Sanitization | Make access to data infeasible according to the selected method and expected effort. | Deletion alone may not meet sanitization needs. |
| Symmetric encryption | Confidentiality using the same secret key for encryption/decryption. | Fast for bulk data; key sharing/protection matters. |
| Asymmetric encryption | Uses a public/private key pair for cryptographic operations. | Common for key establishment/signature-related workflows; slower than bulk symmetric encryption. |
| Hashing | One-way digest for integrity or verifier use. | Hashing is not encryption and does not provide confidentiality by itself. |
Quantum-resistant cryptography — foundational view
At CC level, understand the reason rather than memorizing algorithms: sufficiently capable quantum computers would threaten important widely used public-key cryptography, so organizations need crypto-agility, inventory and migration planning. NIST has standardized post-quantum mechanisms such as ML-KEM for key establishment and ML-DSA / SLH-DSA for digital signatures.
Key-establishment mechanisms and digital signatures are not bulk-data encryption. Hashing is one-way. A digital signature can support integrity/origin evidence but does not make the signed data confidential.
5.2 Understand security operations
| Term | Meaning |
|---|---|
| Telemetry / log | Recorded observations from systems, identities, networks, applications or security tools. |
| Event | An observable occurrence in a system or network. |
| Alert | A rule/analytic/tool indicates an event or pattern may require attention. |
| Triage | Initial evaluation to validate, prioritize, enrich and route the signal. |
| Incident | A security event/situation that requires coordinated response under the organization’s criteria. |
| Correlation | Connect related events/signals to improve context and understanding. |
Threat actors and motivations
| Actor type | Typical motivation/context |
|---|---|
| Cybercriminal | Financial gain, fraud, extortion or resale of access/data. |
| Nation-state / state-aligned | Strategic, geopolitical, espionage or disruptive objectives. |
| Insider | Malicious intent, negligence or misuse of legitimate access. |
| Hacktivist | Ideological/political/social cause and publicity. |
| Competitor / industrial espionage | Commercial advantage or theft of intellectual property. |
| Opportunistic attacker / script user | Easy targets, experimentation, reputation or curiosity. |
Cyber threat intelligence (CTI)
CTI is analyzed information about threats that helps decisions. Good intelligence is relevant to the organization and communicates context, confidence and implications — not just a list of indicators. Frameworks such as MITRE ATT&CK help teams describe adversary behavior consistently; CC candidates do not need to memorize the entire knowledge base.
Modern monitoring tools may use AI to correlate telemetry or reduce alert fatigue. Treat automated output as a prioritization aid: preserve source evidence, validate high-impact conclusions and retain human oversight for consequential actions.
5.3 Understand Incident Response (IR)
| Activity | What should happen |
|---|---|
| Prepare | Define plan, roles, contacts, logging/evidence requirements, escalation and containment options. |
| Detect / report | Identify and validate suspicious activity and route it according to the plan. |
| Assess / decide | Determine scope, priority, impact, authority and next actions. |
| Respond | Contain/eradicate as authorized while preserving evidence and business considerations. |
| Recover / improve | Restore services safely, monitor for recurrence and update controls/playbooks from lessons learned. |
NIST SP 800-61 Rev. 3 (2025) integrates incident response into broader cybersecurity risk management and CSF 2.0. ISO/IEC 27035-1:2023 provides general incident-management principles and process covering preparation, detection/reporting, assessment, response and lessons learned. For CC, use these as mental models; follow the ISC2 objective wording first.
Exercises
| Exercise | Purpose |
|---|---|
| Tabletop | Discussion-based walkthrough of a scenario, roles, decisions and communications. |
| Technical / functional test | Hands-on validation of tools, procedures, evidence collection, containment or recovery elements. |
| Full-scale exercise | Broader realistic simulation involving multiple functions and operational dependencies. |
During a suspected incident, preserve what is needed to understand scope and cause. Containment is important, but destructive cleanup before evidence is secured can make the investigation harder. Follow authorization and the incident-response plan.
5.4 Understand asset protection
| Lifecycle activity | Security action |
|---|---|
| Acquire / onboard | Record asset, owner, purpose, classification and required baseline. |
| Configure / deploy | Apply approved configuration, access, logging and protection. |
| Operate / maintain | Patch/update, monitor, review access and manage change. |
| Change / transfer | Update ownership, configuration, dependencies and records. |
| End of life / end of support | Plan replacement, isolate/compensate if temporarily retained, remove unsupported dependencies. |
| Retire / dispose | Remove access, sanitize data/media as appropriate and update inventory. |
Configuration vs change management
| Configuration management | Change management |
|---|---|
| Maintains known/approved state, baselines and relationships. | Evaluates and controls proposed changes through review, authorization, validation and rollback planning. |
| Answers: “What should this asset look like now?” | Answers: “How do we safely move from current state to a new state?” |
End-of-life software/device risk grows because patches, vendor support or compatible controls may no longer exist. Treatment may require upgrade, replace, isolate, restrict or retire.
5.5 Understand security testing
| Testing concept | Primary purpose |
|---|---|
| Blue team | Defend, monitor, detect, investigate and respond. |
| Red team | Authorized adversary simulation against agreed objectives/scope. |
| Purple team | Collaborative improvement between offensive and defensive perspectives. |
| Vulnerability scanning | Identify known or suspected weaknesses, usually at scale. |
| Static analysis (SAST) | Analyze code/binaries without executing the application. |
| Dynamic analysis (DAST) | Test a running application externally. |
| Threat modeling | Reason about assets, trust boundaries, threats and mitigations before/while designing. |
| Physical/social testing | Authorized testing of physical/human controls, including phishing, tailgating or impersonation scenarios. |
| Vulnerability scan | Penetration test |
|---|---|
| Broad automated identification of potential weaknesses. | Authorized attempt to validate exploitability/attack paths within scope. |
| Good for frequent coverage and inventory-driven hygiene. | Good for deeper scenario validation; point-in-time and scope-limited. |
Security testing without permission can be unsafe or unlawful. Scope, rules of engagement, evidence handling and communication are part of the professional test process.
Event ≠ alert ≠ incident. Hashing ≠ encryption. Vulnerability scanning ≠ penetration testing. Backup ≠ evidence. Red-team activity requires authorization. Unsupported assets may require replacement or isolation rather than a nonexistent patch.
Domain 5 review
- Classification/labeling should drive data handling; masking, encryption, hashing and sanitization have different goals.
- Know symmetric vs asymmetric cryptography and why quantum-resistant migration matters at a foundational level.
- Security operations use logging, correlation, context and triage to decide what matters.
- Threat actors differ in motivation; CTI and frameworks help organize context.
- IR should be prepared, exercised, evidence-aware and governed by authorization.
- Asset lifecycle, EOL, configuration and change management are security controls.
- Know blue/red/purple, vulnerability scanning, SAST/DAST, threat modeling and physical/social testing distinctions.
7. Quick Reference
High-value distinctions compressed into memory anchors for final review.
Foundation
| Concept | Remember | Common confusion |
|---|---|---|
| Confidentiality | Only authorized access/disclosure. | Not the same as privacy. |
| Integrity | Accurate, complete, authorized change only. | Encryption alone does not guarantee integrity. |
| Availability | Reliable access when needed. | Redundancy helps but recovery still matters. |
| Authentication | Who are you? | Not authorization. |
| Authorization | What may you do? | Requires identity/context/policy. |
| Accounting | What did you do? | Supports traceability/accountability. |
Risk & governance
| Concept | Memory anchor |
|---|---|
| Risk lifecycle | Identify → assess → treat → monitor. |
| Risk treatment | Mitigate, avoid, transfer/share, accept. |
| Policy | Management direction. |
| Standard | Specific mandatory internal requirement. |
| Procedure | How to perform the task. |
| Due care | Take reasonable responsible action. |
| Due diligence | Investigate/verify/monitor over time. |
Governance & resilience
| Concept | Remember |
|---|---|
| GRC | Governance directs; risk prioritizes; compliance demonstrates. |
| Redundancy | Alternate components/paths reduce single-point failure. |
| BC | Keep critical business capability functioning. |
| DR | Restore technology/capability after major disruption. |
| Backup | Recoverable copy; restore must be tested. |
| KRI | Indicator that risk exposure may be increasing/approaching threshold. |
IAM
| Concept | Remember |
|---|---|
| Identity lifecycle | Define role → provision → review/change → deprovision. |
| Least privilege | Only required permissions for task/time. |
| SoD | Separate conflicting/high-risk duties. |
| DAC | Owner/authorized owner decides. |
| MAC | Mandatory labels/policy. |
| RBAC | Role/job function. |
| ABAC (supporting) | Attributes/context + policy. |
Networking & cloud
| Concept | Remember |
|---|---|
| TCP | Connection-oriented transport; reliability mechanisms. |
| UDP | Connectionless; lower overhead, no equivalent built-in delivery assurance. |
| VPN | Protected logical path across an untrusted network; still needs authorization. |
| Segmentation | Limit paths and reduce lateral movement/blast radius. |
| Zero Trust | No implicit trust based only on network location. |
| Cloud characteristics | On-demand, broad access, resource pooling, rapid elasticity, measured service. |
| Service models | IaaS, PaaS, SaaS. |
| Deployment models | Public, private, community, hybrid. |
| Shared security | Responsibility shifts by service/provider but does not disappear. |
Data & operations
| Concept | Remember |
|---|---|
| Masking | Obscure values to reduce exposure. |
| Sanitization | Make recovery infeasible using an appropriate method. |
| Symmetric crypto | Same secret key for encrypt/decrypt. |
| Asymmetric crypto | Public/private key pair. |
| Hashing | One-way digest; not encryption. |
| Event → alert → incident | Observation → signal needing attention → situation requiring response. |
| CTI | Analyzed threat information that supports decisions. |
| IR | Prepare, detect/report, assess, respond, recover/improve as a memory model. |
| Asset lifecycle | Inventory → baseline → change/monitor → retire/dispose. |
Testing
| Concept | Remember |
|---|---|
| Blue | Defend/detect/respond. |
| Red | Authorized adversary simulation. |
| Purple | Red + blue collaboration for improvement. |
| Vulnerability scan | Broad identification of potential weaknesses. |
| Penetration test | Validate exploitability/attack paths within scope. |
| SAST | Analyze code without running it. |
| DAST | Test a running application externally. |
| Threat modeling | Reason about assets, trust boundaries, threats and mitigations before/while designing. |
8. Exam Strategy
A decision-oriented approach to scenario questions, CAT pacing and final-week preparation.
The CC exam validates foundational judgment. Strong answers usually respect role, authorization, policy, least privilege, evidence and appropriate escalation. Avoid “hero mode” — an entry-level practitioner should not take actions outside assigned authority simply because they seem technically effective.
Who are you in the scenario: user, junior analyst, administrator, manager, auditor or business owner? Do not choose an action that exceeds the role’s authority.
Do not solve a larger problem than the scenario presents. Identify whether it asks for a principle, control, process, first action or best long-term treatment.
When ownership, policy, change control or incident handling matters, prefer the answer that follows the authorized process and preserves evidence.
Grant only the access needed. Do not solve a permissions issue by giving broader rights.
Contain safely, but do not erase the data/logs needed to understand what happened unless the response plan explicitly requires the action.
Authentication ≠ authorization. Event ≠ incident. BC ≠ DR. Hashing ≠ encryption. Scan ≠ penetration test.
Words like always and never can be traps unless the requirement is truly absolute. Context matters.
CC tests concepts. Know why a control works and what problem it solves; do not over-focus on one vendor interface.
CAT time management
- You cannot skip an item and return later. Make the best-supported decision before moving on.
- You have 2 hours for 100–125 items. Maintain a steady pace without rushing simple questions or spending too long on one item.
- Read all answer choices and eliminate options that violate authorization, policy, least privilege or the stated objective.
- Check ISC2.org shortly before exam day for current exam policies and operational details.
Final-week sequence
- Re-read the official 2026 objective list and confirm you can explain every numbered objective without notes.
- Use the Quick Reference tables to identify weak distinctions.
- Review the memory anchors: foundation, risk, GRC, resilience, IAM, network/Zero Trust, cloud responsibility, data toolkit, operations, IR, assets and testing.
- Revisit only weak sections rather than rereading the whole guide linearly.
- Verify current ISC2 scheduling and exam-day policies.
9. Sources & Further Study
Official certification sources and authoritative supporting references.
The official ISC2 CC exam outline determines scope. The references below validate current exam facts or provide authoritative supporting context. Always verify current editions/status before operational use.
- ISC2 — CC Certification Exam Outline effective 1 September 2026
- ISC2 — Inside the Updated ISC2 Certified in Cybersecurity Exam
- ISC2 — CC Certification / Exam Information
- ISC2 — Frequently Asked Questions
- ISC2 — Code of Ethics
- NIST SP 800-145 — The NIST Definition of Cloud Computing
- NIST SP 800-207 — Zero Trust Architecture
- 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 FIPS 203 / 204 / 205 — ML-KEM · ML-DSA · SLH-DSA
- ISO/IEC 27035-1:2023 — Information security incident management — Part 1
- MITRE ATT&CK — attack.mitre.org
- CIS Controls — cisecurity.org/controls
The official ISC2 outline determines what candidates must cover. NIST/ISO/CIS/MITRE references provide supporting context; they do not silently change the CC objective wording or turn this guide into another certification body’s curriculum.
10. About Taher Amine ELHOUARI
Professional background, contributions, community leadership, training support and ways to connect.
Taher Amine ELHOUARI is a cybersecurity executive, independent vCISO, senior advisor, accredited auditor, certified trainer, practitioner and international speaker whose work spans cybersecurity governance, GRC, audit and assurance, cloud security, SOC/CSIRT operations, incident response, cyber resilience, risk management, technical security and professional capacity building. For this CC edition, that experience is translated into entry-level foundations: clear mental models, practical security reasoning and a path from first principles toward professional practice.
| Selected profile | Details |
|---|---|
| Certifications & credentials | 300+ professional certifications, certificates and credentials across cybersecurity, audit, GRC, cloud, risk, resilience, offensive security, project management and related disciplines. |
| Training | PECB Certified GOLD Trainer — ID GT20395871; authorized to deliver more than 70 PECB programs. |
| Professional contribution | Global Advisory Board Member — EC-Council C|CISO and C|PENT; former Subject Matter Expert / contributor with ISC2 and Hack The Box; current SME and contributor with AfricaCERT. |
| Community leadership | Founding leadership with OWASP Algiers, CSA Algeria, and CAS Algeria (Conformity Assessment Society). |
| International contribution | International speaker; served on the Program Committee of a FIRST event conducted in collaboration with AfricaCERT. |
| Technical competition | Multiple-time Top 10 finisher in international CTF competitions. |
| Selected credentials | DBA, MBA, MSc, PMP, CISSP, CCISO, SecurityX, Certified Cybersecurity MASTER, CMSA, ISO/IEC 27001:2022 MASTER, ISO 22301:2019 MASTER, CCSK, CCZT, TAISE, OOSE, eCPPTv2, eCTHPv2, among others. |
Connect
Website: www.TaherAmine.org
LinkedIn: linkedin.com/in/MrTaherAmine
Email: contact@taheramine.org
GitHub: cyber-master-series-certification-guides
Preparing for ISC2 CC on your own is completely possible with disciplined study. If you want a structured path, live explanation, team training or tailored support, paid cybersecurity fundamentals training, workshops, mentoring and customized learning programs are available for individuals, teams and organizations.
License & legal notice
© 2026 Taher Amine ELHOUARI. Original content in this guide is released under Creative Commons Attribution-NonCommercial 4.0 International (CC BY-NC 4.0), unless a specific element or release states otherwise. Certification names, marks, standards and third-party references belong to their respective owners. CC and ISC2 are registered marks of ISC2, Inc. This guide is independently authored and is not affiliated with, sponsored by, approved by, or endorsed by ISC2.
If this guide helps you, share the official project link, bookmark TaherAmine.org, and star/watch the GitHub repository for future releases. Corrections and improvement suggestions are welcome through the project contribution channels.