Learn the current CC domains as practical security decisions: core principles, governance, identity and access management, networking and cloud security, and security operations with incident response.
This is an independent study resource authored by Zeph Tech. It is not official ISC2 training, is not affiliated with or endorsed by ISC2, and does not contain recalled, leaked, copied, or live-exam questions.
ISC2 materially refreshed the Certified in Cybersecurity outline in 2026. Zeph Tech keeps exam timing, item policy, passing score, domain weighting, owner links, and the next editorial review date in one maintained registry so changing exam facts are not copied across multiple pages.
Active
Last verified: 2026-09-28
Next review: 2026-10-28
The CC is foundational, but foundational does not mean trivia-only. Strong preparation connects terminology to why a control exists, which risk it reduces, who owns it, what evidence it produces, and what happens when it fails.
For each concept, create a small workplace scenario. Ask who is requesting access, what asset is involved, what risk exists, what control should apply, and how you would know the control worked. That turns definitions into usable judgment.
Preventive, detective, corrective, deterrent, compensating, technical, administrative, and physical controls solve different problems. Do not choose a control because it sounds strong; choose it because it addresses the stated objective.
Logging, identity records, configuration state, network telemetry, incident tickets, backups, and access reviews are evidence. Learn what each source can prove and what remains an inference.
Use practice results to identify the domain and reasoning pattern behind misses. A short targeted review is usually more useful than repeatedly rereading the entire outline.
Start with confidentiality, integrity, and availability, but connect each principle to concrete controls. Encryption can protect confidentiality, hashing can help verify integrity, redundancy can support availability, and access controls can reinforce all three depending on the system. Authentication establishes identity, authorization determines permitted actions, and accounting records activity. Non-repudiation and privacy add additional requirements around evidence, accountability, data use, and protection.
Risk management is not the same as eliminating all risk. Identify assets, threats, vulnerabilities, likelihood, impact, existing controls, and business context. Then choose a treatment such as mitigation, transfer, avoidance, or acceptance when appropriate. A risk decision should have an accountable owner and enough evidence to explain why the organization accepted the residual exposure.
Governance concepts define how security decisions become repeatable. Policies express management direction, standards define mandatory requirements, procedures explain repeatable steps, and guidelines offer recommended practices. Laws, regulations, contractual requirements, frameworks, and internal rules may overlap, but they are not interchangeable. Learn to identify which source creates the obligation and which internal control satisfies it.
Professional conduct matters because security practitioners routinely handle privileged information and consequential decisions. Due care means taking reasonable protective action; due diligence means maintaining the ongoing effort to understand and manage risk. When an exam scenario presents a technically possible shortcut that violates authorization or ethical obligations, permission and professional responsibility remain part of the correct answer.
Governance, risk, and compliance connects security work to organizational priorities. A mature program defines ownership, decision rights, control requirements, exception processes, metrics, and reporting. A dashboard is useful only when its measures influence decisions. Raw counts of alerts or vulnerabilities can be misleading; coverage, aging, recurrence, recovery performance, and unresolved high-impact risk often provide better management signals.
Business continuity and disaster recovery answer related but different questions. Business continuity focuses on sustaining critical business functions during disruption. Disaster recovery focuses on restoring technology and supporting capabilities. Recovery Time Objective describes how quickly a service must be restored, while Recovery Point Objective describes the acceptable data-loss window measured in time. Backups support recovery only when they can actually be restored within the required objective.
Redundancy helps remove single points of failure, but duplicated components can still share one dependency. Two servers using the same unavailable identity provider, DNS service, network path, or storage platform may fail together. When evaluating resilience, trace dependencies rather than simply counting components.
Security awareness is a control program, not a one-time presentation. Effective awareness addresses phishing, social engineering, password and MFA behavior, sensitive data handling, reporting expectations, and organizational culture. Measure outcomes such as reporting behavior, repeat incidents, or completion of targeted remediation rather than treating attendance alone as proof of effectiveness.
Identity lifecycle management follows the account from creation through review and eventual removal. Provision access based on approved need, review it as roles change, and deprovision promptly when the need ends. Orphaned accounts, excessive standing privilege, shared credentials, and stale service identities all expand attack paths because access persists beyond the intended purpose.
Least privilege grants only the permissions needed for the task. Separation of duties prevents one person from controlling every stage of a sensitive process. Role-based access control assigns permissions through roles; attribute-based approaches can incorporate identity, resource, action, and environmental context. The important exam skill is recognizing which model or principle best matches the scenario rather than memorizing acronyms in isolation.
Authentication proves an identity using factors such as something you know, have, or are. Strong MFA uses distinct factor categories. Authorization occurs after authentication and should be enforced by the service that owns the protected resource. Hiding a button in a user interface is not authorization if the backend still accepts an unauthorized request.
Periodic access reviews should test whether privileges still match business need, not merely whether an account exists. High-risk identities deserve stronger controls such as dedicated administrative accounts, just-in-time privilege, stronger authentication, session logging, or approval workflows depending on the environment.
Use networking models to locate the failing or exposed layer. Physical connectivity, local addressing, routing, name resolution, transport, encryption, and application behavior can fail independently. Firewalls enforce traffic policy, segmentation limits reachable paths and blast radius, and VPNs create protected communication channels over untrusted networks. A strong answer identifies what boundary the control protects.
Wireless security adds radio conditions, authentication, encryption, rogue infrastructure, device configuration, and proximity risks. Bluetooth, Wi-Fi, IoT, and industrial systems have different operational constraints, but the same foundational principles still apply: minimize unnecessary exposure, authenticate appropriately, segment where possible, monitor important activity, and maintain supported configurations.
Defense in depth combines independent controls so one failure does not decide the outcome. Zero trust reduces implicit trust by evaluating identity, device or workload context, resource, and policy rather than assuming network location is sufficient. Segmentation is most valuable when it isolates meaningful trust zones instead of simply creating more network complexity.
Cloud security requires understanding shared responsibility. The provider may operate physical infrastructure and portions of the platform while the customer remains responsible for identities, data, permissions, configuration, workloads, and application controls depending on the service model. SaaS, PaaS, and IaaS shift responsibility differently, so identify the layer before deciding who must fix a problem.
Security operations turns controls into observable evidence. Logs should be collected from sources that matter, time should be consistent enough for correlation, access to logs should be protected, and retention should match operational and legal needs. A SIEM can centralize and correlate evidence, but poor source coverage or parsing produces false confidence.
Event triage prioritizes what needs attention. Consider source reliability, asset value, identity context, recurrence, exposure, threat intelligence, and correlated behavior. A single indicator may be suspicious without proving compromise. Analysts should separate observed facts from hypotheses and identify the next evidence source that can reduce uncertainty efficiently.
Incident response typically moves through preparation, detection or analysis, containment, eradication, recovery, and improvement, although real incidents may overlap phases. Containment should reduce attacker capability while considering business impact and evidence needs. Eradication removes the cause or persistence mechanism. Recovery returns systems to trusted operation and verifies that the original threat no longer has access.
Data protection includes classification, labeling, masking, sanitization, encryption, retention, and secure disposal. Asset protection includes inventory, configuration management, lifecycle state, and end-of-life planning. Unsupported systems deserve attention because security fixes, vendor support, and compatibility options become increasingly limited over time.
The revised outline also brings modern technology context into foundational study. Treat AI systems as assets that still require governance, identity, data protection, logging, change control, and secure use. Do not assume an AI-enabled tool replaces human judgment, authorization, or evidence requirements.
Review CIA, AAA, privacy, risk, policies, standards, procedures, due care, and control categories. Build a small risk register for a fictional business and identify one preventive, detective, and corrective control for each material scenario.
Create two users with different roles in a safe lab or training environment and map authentication, authorization, and logging. Draw a simple network with trust zones, then add a cloud service and identify which controls remain the customer's responsibility.
Collect example operating-system or cloud logs from systems you own. Build a short incident timeline, choose a containment step, define what evidence you would preserve, and write how recovery would be verified.
Take original practice questions without notes. Categorize misses as knowledge, terminology, sequencing, or scope errors. Review only the weak categories, then explain the correct decision in your own words before taking a fresh set.
Read qualifiers such as FIRST, NEXT, BEST, and MOST likely before evaluating answers. Identify the asset, risk, control objective, and current phase of the scenario. Several options may improve security generally, while only one addresses the stated problem at the correct time.
Prefer actions that create evidence, preserve reversibility, respect authorization, and solve the actual layer of the problem. If a question asks about access control, do not choose a network control merely because it is strong. If a response scenario is still in analysis, do not jump to a destructive recovery action that erases useful evidence.
Use official ISC2 material as the final authority for exam logistics and objectives. Zeph Tech's maintained registry is designed to expose changes quickly, but the certification owner controls the exam. The strongest preparation combines current objectives, independent explanations, hands-on practice, and repeated scenario reasoning.