RoleMath Study Track · free study companion
A free study companion keyed to the officially published exam domains of ISC2 Certified in Cybersecurity (CC) (CC): what each domain covers in plain language, clearly labeled free resources, a guided lab outline for every domain, and interactive self-checks from our own question bank. ISC2 Certified in Cybersecurity (CC) exam outline
A free, source-cited study companion built on ISC2's published Certified in Cybersecurity (CC) exam outline — not official training, not a pass guarantee. Verify the current objectives on the official page before your exam.
Not sure which domain to start with? Take the readiness check on the cert page →
Program blueprint under review
A complete free ISC2 Certified in Cybersecurity program pinned to the current official outline, turning five entry-security domains into ethical defensive artifacts across principles, continuity, access, networks, and operations without depending on a time-limited exam offer or claiming an outcome.
This draft exposes RoleMath’s authored sequence and evidence plan. The current labs are guided outlines, not yet a fully fixture-backed course, and objective-leaf coverage has not passed the gold-standard gate. Completion does not predict an exam result.
Choose an outcome
Choose provisionally. Change routes when the work tells you something new about fit, time, or readiness.
Learners who have selected ISC2 CC and need one complete practice sequence across all five current exam domains.
Completion emphasis: Complete every module and safe lab route, the registered official practice quiz, the integrated control-and-continuity capstone, and a final gap review against the official outline.
Career changers who want reviewable entry-level evidence of security principles, access decisions, network trust, log observation, incident response, and continuity reasoning.
Completion emphasis: Retain a redacted principles/risk record, access matrix, network trust diagram, log observation, continuity objectives, incident runbook, communications, and five-domain crosswalk.
Learners deciding whether defensive security, access administration, network protection, monitoring, incident response, or continuity work fits their interests.
Completion emphasis: Complete the diagnostic plus MFA/principles, account-permission, HTTPS, log, and runbook samples; record which preventive, detective, responsive, and continuity tasks deserve a deeper next experiment.
Start safely
Select ethical, permission-bound, and accessible entry-security practice before the labs; this diagnostic is not an ISC2 prerequisite, endorsement check, or pass prediction.
Ready when: Yes, with all active work limited to owned or explicitly authorized assets.
If not yet: Use the written fictional and observation-only alternatives until ownership and permission are clear.
Ready when: Yes, or you can use the written factor, threat, recovery, and verification alternative.
If not yet: Do not change an account; complete the MFA decision and recovery walkthrough instead.
Ready when: Yes, with read-only steps and no need for unauthorized elevated access.
If not yet: Use sanitized command, permission, certificate, and event transcripts labeled observation-only.
Ready when: Yes, or you will complete the short networking and HTTPS trust bridge first.
If not yet: Review vendor-neutral networking concepts before attempting to interpret network-security evidence.
Ready when: Yes, with fictional capstone values and a minimum-evidence rule.
If not yet: Use only synthetic evidence and complete the redaction checklist before saving screenshots or command output.
Ready when: Yes, or the program will proceed independently of the offer while logistics remain unverified.
If not yet: Use the free RoleMath path and official outline without booking. New enrollment in ISC2's former free course-and-exam program is closed, so budget against current standard ISC2 terms unless you already hold valid legacy access or an unexpired code.
Plan, then adapt
7 weeks 5-7 hours/week
A planning estimate for first-time security learners: give principles, networks/access, operations, continuity/response, and integration separate practice blocks.
5 weeks 7-10 hours/week
A planning estimate that pairs network and access work while preserving dedicated time for log observation, the incident/continuity capstone, and remaining domain gaps.
3 weeks 10-14 hours/week
For learners with prior IT, governance, networking, or support experience; do not compress authorization, evidence redaction, response sequencing, or unfamiliar continuity concepts.
Evidence-gated sequence
Pin the current CC outline, choose a goal and pace, define owned/fictional practice boundaries, and separate program completion from ISC2 booking, membership, or promotion terms.
Build the confidentiality, integrity, availability, authentication, authorization, risk, control, governance, privacy, and professional-conduct vocabulary used by every other domain.
Modules: Security Principles
Connect encrypted network communication and layered controls with identity, least privilege, privileged access, permissions, physical access, and access lifecycle decisions.
Modules: Network Security, Access Controls Concepts
Observe read-only local security events and connect logging, monitoring, data handling, configuration, change, updates, awareness, and physical/environmental controls to routine operations.
Modules: Security Operations
Sequence preparation, detection, analysis, containment, recovery, communication, lessons, business impact, continuity, disaster recovery, and testing without acting on a real workplace incident.
Modules: Business Continuity (BC), Disaster Recovery (DR) & Incident Response Concepts
Integrate principles, access, network defense, operations, incident response, and continuity into one coherent fictional small-organization control workbook and tabletop.
Modules: Security Principles, Business Continuity (BC), Disaster Recovery (DR) & Incident Response Concepts, Access Controls Concepts, Network Security, Security Operations
Before a lab
Show your work
Completing this policy demonstrates ISC2 CC domain coverage and entry defensive practice inside RoleMath; it does not predict a score, confer ISC2 certification or endorsement, or replace current ISC2 terms.
Integrated practice
Build a defensible security baseline for a small fictional community organization, then respond to a lost-device and suspicious-login tabletop while preserving critical services and producing artifacts across all five ISC2 CC domains.
Safety boundary: Keep every organization, account, event, device, control, incident, and continuity decision fictional or based only on owned read-only observations. Never execute response actions on a real work/shared account or device, test another person's access, clear logs, scan/capture networks, run malware, or interact with suspicious content. Follow authorized workplace processes for real concerns.
Finish honestly
Present the workbook as self-directed ISC2 CC entry-security practice. Do not call it professional incident response, continuity planning for a real organization, official ISC2 training, certification, endorsement, or a RoleMath credential.
Objective source checked 2026-07-10. Recheck objectives every 10 days and resources every 90 days.
The official objective domains and their exam weight — titles & weights only, straight from the vendor’s exam objectives. ISC2 Certified in Cybersecurity (CC) exam outline
Our default advice is to study the heaviest-weighted domain first, because the published weights tell you where the exam spends its questions. On CC the heaviest domain and the foundational one happen to be the same — Security Principles (26%) both carries the most questions and teaches the vocabulary the other four domains are written in (the CIA triad, controls, authentication, risk). So no exception is needed here: study strictly by weight — Security Principles first (26%), then Network Security (24%), Access Controls Concepts (22%), Security Operations (18%), and finally Business Continuity, Disaster Recovery, and Incident Response Concepts (10%). Leaving the lightest domain for last is comfortable because it also reads most easily once you already understand what you are protecting and who is allowed to touch it. This is sequencing advice based on the published weights and how the topics depend on each other, not a claim about the science of learning — if a different order fits how you think, use it.
Module 1 of 5 · domain 1 · 26% of the exam
Start here — it is both the heaviest domain and the foundation. It defines the vocabulary (the CIA triad, controls, authentication, risk, ethics) that the other four domains assume you already speak, so studying it first makes everything after it easier to read.
Plain-language explanation in our own words — paraphrased from, and checked against, the official objectives. ISC2 Certified in Cybersecurity (CC) exam outline
This is the vocabulary domain, and it is the largest slice of the CC exam. Before the exam asks you about networks, access, or incidents, it establishes a shared language for talking about security at all: what security is trying to protect, what a control is, how you prove who someone is, and how organizations decide how much risk they can live with. Nearly every question elsewhere on the exam is written in the words this domain teaches, so if a later practice question ever feels like it is in a foreign language, the gap is usually right here. You do not need any background to learn this — it is ideas and plain reasoning, not technology.
The idea everything hangs on is that security has three basic goals, usually called the CIA triad. Confidentiality means only the right people can read something — your medical records should not be visible to strangers. Integrity means nobody has secretly changed it — your bank balance should reflect only real transactions. Availability means it works when you need it — a hospital's systems must be up during an emergency. Almost any safeguard you can name exists to protect one or more of these three, and a surprising share of exam-style questions are really just asking which goal is at stake in a described situation. Getting comfortable naming confidentiality, integrity, or availability from a story is one of the highest-value skills on the whole exam.
Around the goals sits the toolbox: controls. A control is anything you put in place to reduce risk, and they come in a few flavors the exam wants you to tell apart. Some are technical (a password requirement, encryption, an automatic lockout), some are administrative or managerial (a written policy, a background check, a training requirement), and some are physical (a locked door, a badge reader, a security guard). Controls also differ by what they do: some prevent bad things before they happen, some detect them while or after they happen, and some correct or recover afterward. The core skill is placing a real safeguard into that grid — recognizing that a security camera is a physical, detective control, or that a policy requiring strong passwords is an administrative, preventive one.
The domain also introduces the everyday mechanics of trust. Authentication is proving you are who you claim to be, and it draws on three kinds of evidence: something you know (a password), something you have (a phone or a hardware key), and something you are (a fingerprint or face). Combining two different kinds is multi-factor authentication, and it is the single cheapest way to blunt stolen-password attacks — which is exactly why this domain's lab has you turn it on and read how it works. Alongside authentication sit authorization (what you are allowed to do once you have proven who you are) and non-repudiation (being unable to credibly deny you did something, because the system recorded it). These names return in the access-controls domain; here they are introduced as concepts.
Two more strands round the domain out. The first is risk, the organization's native way of deciding what to protect and how hard. The working idea is that a threat (something that could cause harm) meeting a vulnerability (a weakness it can exploit) creates risk, and organizations respond to each risk by reducing it with controls, transferring it (insurance, contracts), avoiding the risky activity, or knowingly accepting it when the fix would cost more than the exposure. The second strand is the professional side: security work touches people's private data and their trust, so ISC2 attaches a code of ethics to the credential, and privacy — handling personal information responsibly and lawfully — is treated as a first-class principle, not an afterthought.
On the job, this domain is the difference between memorizing tools and reasoning about them. When someone proposes a safeguard, the working questions are exactly the ones here: which goal does it protect, what kind of control is it, does it prevent or merely detect, and what are we trusting for it to work? A good way to study is to stop reading and start classifying: pick ten safeguards you have personally met — a door badge, a password, a backup, a locked filing cabinet — and place each one in the goals-and-controls grid out loud, then explain the CIA triad to a friend in plain words. If you can do that without notes, you have what this domain checks for. Read the official CC exam outline for the exact topic list — the wording there is ISC2's own, and this explanation deliberately paraphrases rather than reproduces it.
Make the CIA triad concrete by strengthening confidentiality on an account you own: enable multi-factor authentication (MFA) on a free personal account, sign in with it, and observe how a second factor stops a stolen password from being enough. This is authentication — a Security Principles core idea — experienced rather than just read, and it costs nothing.
A sign-in that now requires two different kinds of proof — your password plus a time-based code from an app on your phone — and a clear understanding that a thief with only your password can no longer get in. You have strengthened confidentiality on a real account and felt why multi-factor authentication is the cheapest strong control in security.
This lab practices the authentication factors and confidentiality (CIA triad) concepts that Domain 1 (Security Principles) of the official ISC2 Certified in Cybersecurity (CC) exam outline covers; see the official exam outline for ISC2's own wording.
Stay safe & legal: Do this only on a personal account you own — never a work, school, or someone else's account, and never on a shared or public computer. Store your backup/recovery codes somewhere safe, since losing your second factor without them can lock you out. Enabling MFA only strengthens your own account; it touches no system you do not own.
2RoleMath-original concept checks for this domain — written by us against cited public sources, never taken from any exam. They confirm understanding; they don’t predict a pass.
Module 2 of 5 · domain 4 · 24% of the exam
Second in our suggested order, and the second-heaviest domain at 24%. Study it right after Security Principles: once you know what confidentiality, integrity, and availability mean, network security is largely the story of protecting those three as data travels between machines.
Plain-language explanation in our own words — paraphrased from, and checked against, the official objectives. ISC2 Certified in Cybersecurity (CC) exam outline
This is the 'how do computers talk, and how do we protect the conversation' domain, and at 24% it is the second-heaviest on the exam. It has a reputation for being the scariest part of CC for career changers, because it introduces the plumbing of networks — but the exam pitches it at recognition, not engineering. You are being asked to know what the main pieces are, what the common threats look like, and which defensive tools address which problem. If you can follow the idea that data travels in labeled packets between addressed machines, you already have the foothold this domain needs.
Start with the basics of how networks move data. Computers find each other using addresses (an IP address identifies a machine on a network, much like a street address), and human-friendly names are turned into those addresses by a lookup system (DNS, the internet's phone book). Data does not travel as one big blob; it is broken into small packets that are labeled, sent, and reassembled at the other end. The exam leans on a couple of layered mental models — a widely taught seven-layer reference model and the four-layer model the internet actually runs on — mostly so you can talk about where a given function or protocol lives. You do not need to memorize every layer's details; you need the vocabulary to say roughly where something happens.
With the plumbing sketched, the domain turns to what goes wrong on networks — the threats. Some aim at availability, like a denial-of-service attack that floods a service with junk traffic until real users cannot get through (and its distributed form, launched from many machines at once). Some aim at confidentiality or integrity by getting in the middle of a conversation — an on-path or 'man-in-the-middle' attacker who secretly relays and can alter traffic between two parties who think they are talking directly. Others ride the network to deliver malware, or exploit weakly secured wireless networks and spoofed addresses. The exam wants you to recognize each threat from a plain description of its effect, and to understand why encryption and authentication blunt the eavesdropping ones.
The largest practical payoff of the domain is the toolbox of defensive devices and designs, learned by purpose. A firewall sits at a boundary and allows or blocks traffic according to rules — the classic chokepoint between a trusted network and an untrusted one. Intrusion detection and prevention systems watch traffic for signs of attack, one raising alerts and the other also blocking. Network segmentation divides a network into zones so a problem in one cannot freely reach the rest, and a demilitarized zone (a buffer segment) isolates anything that must face the public internet from the sensitive internal network. Virtual private networks create an encrypted tunnel so remote users can reach internal resources safely over the open internet. You are matching a described need — 'block unwanted traffic at the edge', 'let staff work securely from home', 'keep the public web server away from the internal database' — to the right piece.
Threaded through the domain is a single unifying idea from Domain 1: confidentiality in transit. Data moving across a network is exposed to anyone positioned to capture it unless it is encrypted, which is why the secure versions of protocols exist — the padlock and 'https' in your browser mean the connection to a website is encrypted so eavesdroppers see only scrambled traffic. The certificates behind that padlock, issued and vouched for through public key infrastructure, are how your browser confirms it is really talking to the site it thinks it is, not an impostor. This is the most tangible network-security concept on the exam, and it is exactly what the lab below has you inspect on a real connection.
Study this domain by grounding every abstract device in a question about your own home network: what is my router's firewall doing, what would segmenting my smart-home gadgets away from my laptop accomplish, why does my banking site show a padlock? The lab has you open a real HTTPS certificate in your browser and read who issued it and what it protects, turning 'encryption in transit' from a phrase into something you have examined. As with every domain on this track, read the official CC exam outline for the authoritative topic list; our explanation paraphrases its scope in our own words rather than reproducing it.
Make encryption in transit and the trust behind the padlock concrete: open the certificate of a real website in your browser, read who issued it and what it protects, and understand why the 'https' padlock means your connection is confidential and the site is who it claims to be. No downloads, no cost — the browser you already have does all of it.
A padlock and 'https' confirming an encrypted connection, a certificate 'issued to' the site you are on and 'issued by' a certificate authority your browser trusts, real expiry dates, and a chain of certificates ending at a trusted root. You have seen confidentiality in transit and the public-key-infrastructure trust that makes it safe to visit a site you have never been to before.
This lab practices the network-security, encryption-in-transit, and public-key-infrastructure concepts that Domain 4 (Network Security) of the official ISC2 Certified in Cybersecurity (CC) exam outline covers; see the official exam outline for ISC2's own wording.
Stay safe & legal: This is a read-only inspection of connections your browser already makes to sites you already visit — the same thing it does on every secure page. Do not point scanning, probing, or interception tools at any network, site, or device you do not own; simply viewing a public site's certificate, as here, is safe and normal.
2RoleMath-original concept checks for this domain — written by us against cited public sources, never taken from any exam. They confirm understanding; they don’t predict a pass.
Module 3 of 5 · domain 3 · 22% of the exam
Third in our suggested order, per its 22% weight. Study it after Security Principles introduces authentication and authorization — this domain takes those ideas and turns them into the day-to-day discipline of deciding who is allowed to touch what.
Plain-language explanation in our own words — paraphrased from, and checked against, the official objectives. ISC2 Certified in Cybersecurity (CC) exam outline
This is the 'who is allowed to do what' domain, and at 22% it is one of the exam's larger slices. Where Security Principles introduced authentication and authorization as ideas, this domain makes them the practical work of controlling access — the single most common place where real security either holds or fails. Most breaches ultimately trace back to someone having access they should not have had, so the exam gives this topic real weight. The reassuring part for a beginner is that the underlying logic is intuitive: it is about locks, keys, and who holds them, translated into both the physical world and the digital one.
The domain frames access control around a simple vocabulary: a subject (a person, program, or process) requests access to an object (a file, a room, a system), and the access control decides whether to allow it. Two related principles govern how those decisions should be made. Least privilege means giving each subject only the access it genuinely needs to do its job and no more, so that a misused or stolen account can do limited damage. Separation (or segregation) of duties means splitting a sensitive task among more than one person so no single individual can both commit and conceal a problem — the reason the person who requests a payment usually is not the same person who approves it. The exam probes whether you can spot when these principles are being followed or violated in a described situation.
Access control shows up in two worlds, and the exam treats both. Physical access controls govern who can enter a space or reach equipment: locked doors, badge readers, security guards, fences, mantraps that let one person through at a time, and visitor sign-in. Logical (technical) access controls govern who can reach systems and data: passwords and multi-factor authentication proving identity, permissions deciding what an identity may do, and automatic lockouts and session timeouts limiting exposure. A recurring exam theme is that the two reinforce each other — strong logical controls do not help if someone can simply walk out with the server, and a locked door does not help if the login is 'password'.
Once a subject has been authenticated, the system has to decide what it may actually do, and the exam expects familiarity with a few named models for making that decision. In discretionary access control, the owner of a resource decides who else may use it — the everyday model where you share a document and pick who can view or edit it. In mandatory access control, access is dictated by system-enforced classifications and clearances rather than owner choice — the stricter model used where data is labeled by sensitivity, as in some government settings. In role-based access control, permissions attach to job roles rather than individuals, so a new hire simply inherits the access their role is defined to have. You are matching a described arrangement to the right model, not implementing any of them.
A special focus is the handling of powerful accounts and the lifecycle of access over time. Privileged accounts — administrators, superusers — can change or destroy far more than an ordinary user, so they warrant extra protection: used sparingly, monitored closely, and never shared. Access is also not a one-time grant but a lifecycle: it is provisioned when someone joins, adjusted when their role changes, and — the step organizations most often botch — promptly removed when they leave or no longer need it. Orphaned accounts that outlive their owner's need are a classic, avoidable weakness, which is exactly what this domain's lab helps you see on your own machine.
Study this domain by making its abstractions concrete on systems you already use. Ask, of any resource: who is the subject, what is the object, what is the least access that gets the job done, and which model is deciding? The lab below has you open your own operating system's user-account and permission tools and read what is actually there — how many accounts exist, which have administrator power, and what a standard user is and is not allowed to do. Seeing least privilege and privileged accounts in your own settings turns the vocabulary into recognition. And read the official CC exam outline for the authoritative topic list; our explanation paraphrases its scope in our own words rather than reproducing it.
Make least privilege and privileged accounts visible where you can actually see them: use your operating system's built-in tools to list the user accounts on your own machine, identify which have administrator power, and observe what a standard account is and is not allowed to do. No downloads, no cost — just the account controls already on your device.
A clear list of the accounts on your computer, an accurate sense of which ones hold administrator (privileged) power, an authorization prompt refusing a standard user a protected action, and file permissions spelled out as who-may-do-what. You have seen least privilege, privileged accounts, and the subject-object-permission model in your own settings rather than in the abstract.
This lab practices the least-privilege, privileged-account, and access-control (subject/object/permission) concepts that Domain 3 (Access Controls Concepts) of the official ISC2 Certified in Cybersecurity (CC) exam outline covers; see the official exam outline for ISC2's own wording.
Stay safe & legal: Only inspect a computer you personally own or are explicitly authorized to administer — never someone else's device or a work machine without permission. This lab is read-and-observe: do not delete accounts, change permissions on system files, or remove access you are unsure about, since a wrong change can lock you out or break the machine. When in doubt, look but do not alter.
2RoleMath-original concept checks for this domain — written by us against cited public sources, never taken from any exam. They confirm understanding; they don’t predict a pass.
Module 4 of 5 · domain 5 · 18% of the exam
Fourth in our suggested order, per its 18% weight. Study it after the foundations, network, and access domains: security operations is largely those concepts turned into daily routines — handling data, watching logs, and keeping configurations and people in good shape.
Plain-language explanation in our own words — paraphrased from, and checked against, the official objectives. ISC2 Certified in Cybersecurity (CC) exam outline
This is the 'keep security running day to day' domain, and at 18% it is a solid middle-weight slice of the exam. Where the earlier domains taught goals, networks, and access, this one covers the ongoing routines that keep an organization protected between incidents: how data is handled and protected, how systems are kept in a known-good state, how activity is watched, and how people are kept security-aware. It is the domain closest to what an entry-level security or IT worker actually does on a normal Tuesday, which makes it both practical and, for a beginner, quite approachable.
The first strand is handling data responsibly across its whole life. Not all data is equally sensitive, so organizations classify it — labeling information by how much protection it needs (public, internal, confidential, and so on) so that everyone knows how to treat each kind. Classification then drives handling rules: how data may be stored, shared, and eventually destroyed. Secure disposal matters more than beginners expect — deleting a file or reformatting a drive often leaves the data recoverable, so genuinely destroying sensitive information (secure wiping, shredding) is its own discipline. The exam wants you to connect a data's sensitivity to the handling and destruction it deserves.
Encryption reappears here as an operational tool, applied to two states of data. Data at rest — sitting on a disk, a laptop, a backup, a phone — is protected by encrypting the storage, so that a lost or stolen device yields only scrambled data. Data in transit — moving across a network — is protected by encrypted connections, the same idea the network domain covered. The operational point is that encryption is not a one-time setting but a routine expectation: full-disk encryption on laptops, encrypted backups, secure protocols by default. You are expected to recognize which state of data a given protection applies to, and why both matter.
The second big strand is watching and maintaining, which comes down to two disciplines. Logging and monitoring means recording what happens on systems — logins, changes, errors, access to sensitive files — and actually reviewing those records so that unusual activity is noticed rather than buried. Logs are how you reconstruct what happened after an incident and how you catch one in progress, which is why 'if it is not logged, it did not happen' is a working truism. Configuration and change management is the partner discipline: keeping systems in a known, secure, documented state and controlling changes to them, because uncontrolled change is one of the most common ways environments quietly break their own security. This domain's lab has you open your own computer's logs to see what 'monitoring' is drawing from.
The domain also covers the human and policy layer that makes the technical controls stick. Security awareness education — teaching people to recognize phishing, handle data properly, use strong authentication, and report problems — matters because the earlier domains showed how often attacks target people rather than machines. And a family of common policies gives everyone the rules of the road: an acceptable use policy (what you may and may not do with organization systems), bring-your-own-device rules, password and privacy policies, and more. The exam treats these documents and training programs as controls in their own right — a policy nobody follows and training nobody absorbs fail exactly the way an unpatched machine fails, just more quietly.
Study this domain by mapping each concept onto habits you can see. What logs does your own computer keep, and what would 'monitoring' them mean? Which of your files would you classify as sensitive, and is your disk encrypted? The lab below opens your operating system's built-in security or event log so that 'logging and monitoring' stops being a phrase and becomes a screen full of real recorded events you can read and interpret. As with every domain on this track, read the official CC exam outline for the authoritative topic list; our explanation paraphrases its scope in our own words rather than reproducing it.
Turn 'logging and monitoring' from a phrase into something you have read with your own eyes: open your operating system's built-in security or event log, find real recorded events such as logins, and understand what a monitoring tool draws from and why logs matter after an incident. No downloads, no cost — the log is already being kept on your machine.
A real, automatically maintained log of events on your own machine — including login/logon records you can match to actions you took, and (if you look) failed attempts. You have seen exactly what 'logging and monitoring' draws from, why logs are the record you reconstruct an incident from, and why the sheer volume pushes organizations toward tools that collect and correlate logs at scale.
This lab practices the logging-and-monitoring concept — and its link to configuration/change management and incident reconstruction — that Domain 5 (Security Operations) of the official ISC2 Certified in Cybersecurity (CC) exam outline covers; see the official exam outline for ISC2's own wording.
Stay safe & legal: Only read the logs on a computer you personally own or are authorized to administer — never someone else's device or a work machine without permission. This lab is read-only: view and interpret the log entries, but do not clear, delete, or alter logs, since on real systems tampering with logs is both a serious security violation and a way to destroy your own troubleshooting record.
2RoleMath-original concept checks for this domain — written by us against cited public sources, never taken from any exam. They confirm understanding; they don’t predict a pass.
Module 5 of 5 · domain 2 · 10% of the exam
Last in our suggested order, per its 10% weight — the lightest domain. It is also the most story-driven and reads most easily once you already know what you are protecting (Domain 1) and how systems connect (Domain 4), which makes it a satisfying place to finish.
Plain-language explanation in our own words — paraphrased from, and checked against, the official objectives. ISC2 Certified in Cybersecurity (CC) exam outline
This is the 'what do we do when something goes wrong' domain, and at 10% it is the lightest slice of the exam — but do not mistake light for unimportant, because it covers the moments that decide whether an organization survives a bad day. It groups three related plans that answer three different questions: how do we keep the essential business running during a disruption (business continuity), how do we get our technology back after a disaster (disaster recovery), and what exact steps do we take when a security incident is happening right now (incident response). For a career changer the good news is that this domain rewards clear thinking and calm process over technical depth — it is mostly about knowing the script.
Start with incident response, because it is the most immediate. An incident is any event that actually harms, or threatens to harm, an organization's systems or data — a malware infection, a stolen laptop, an account someone broke into. Incident response gives that chaos a repeatable script so people do not improvise under pressure: prepare in advance (have a plan, know who to call), detect and analyze what is happening, contain it so it stops spreading, eradicate the cause, recover normal service, and afterward capture the lessons so the same thing is less likely next time. The exam expects you to recognize these phases and their order — for example, that you contain a spreading infection before you try to fully clean it, the same way you would stop a leak before mopping the floor.
Incident response also runs on people and communication, not just steps. Organizations designate a response team with defined roles so that when an alarm sounds, everyone knows who leads, who investigates, and who talks to management, customers, or authorities. Clear escalation — knowing when a small event has become a big one that needs more senior attention — is part of the concept. You are not expected to lead a response as an entry-level professional; you are expected to understand the shape of one and, crucially, to know how to raise the alarm correctly rather than quietly trying to fix a serious problem alone.
Business continuity zooms out from a single incident to the whole organization. Its question is: if something takes out our building, our systems, or our people, how do we keep the truly essential functions going in the meantime? That starts with figuring out which functions are essential in the first place and how long the business could survive without each one — the reasoning behind the exam's interest in prioritizing critical operations. A business continuity plan documents the workarounds and alternate arrangements that let the organization limp forward — running payroll from a backup location, using manual processes temporarily — while the technical recovery happens in parallel. Continuity is about the business staying alive; recovery is about the technology coming back.
Disaster recovery is that technical recovery half, and it centers on getting systems and data restored after a serious disruption. Its foundation is backups — usable, tested copies of data kept somewhere the disaster cannot also destroy, which is why 'off-site' or separate-from-the-original storage matters so much. Two ideas discipline the planning: how much recent data the organization can afford to lose (which drives how often you back up) and how long it can afford to be down (which drives how quickly you must be able to restore). Alternate processing sites — ranging from a fully ready standby location to a bare space you would have to equip — are ranked by how fast they can take over. The recurring exam skill is matching a described need to the right recovery concept.
Study this domain by turning each concept into a short story you narrate in your own words: a ransomware infection walked through the incident-response phases; a flood that forces the continuity plan to keep the business running from home; a failed hard drive that the backup and recovery plan makes survivable. The lab below has you write a real incident-response runbook for a lost laptop — a scenario common enough to be worth having ready, and concrete enough to make the phases stick. As with every domain on this track, read the official CC exam outline for the authoritative topic list; our explanation paraphrases its scope in our own words rather than reproducing it.
Turn the incident-response phases from words into a usable one-page runbook for a concrete, common scenario — a lost or stolen laptop. Writing the steps yourself, in order, is how the prepare-detect-contain-eradicate-recover-learn sequence stops being a list to memorize and becomes a process you understand.
A one-page runbook whose sections mirror the incident-response phases — prepare, detect, contain, eradicate/recover, report, learn — filled with concrete actions you could actually take for a lost laptop. You have converted an abstract process into a tool you would be glad to have, and in doing so learned the phases by building them.
This lab practices the incident-response process and phases — and their link to backups and recovery — that Domain 2 (Business Continuity, Disaster Recovery & Incident Response Concepts) of the official ISC2 Certified in Cybersecurity (CC) exam outline covers; see the official exam outline for ISC2's own wording.
Stay safe & legal: This is a planning exercise about a device you own. If you adapt it for a workplace, follow your employer's real incident-response and reporting process rather than acting alone, and treat the runbook as sensitive — it describes exactly how your accounts and data could be reached. Never test the 'lost laptop' steps against anyone else's device or accounts.
2RoleMath-original concept checks for this domain — written by us against cited public sources, never taken from any exam. They confirm understanding; they don’t predict a pass.
Studying ISC2 Certified in Cybersecurity (CC)builds transferable skills that carry across employers and platforms, not just toward this one exam. Each has a free, source-cited RoleMath primer — what it is, a step-by-step free learning path, clearly labeled free resources, and a safe hands-on exercise:
Work through the modules above, then get a personalized read on where you stand: the readiness check maps your background against these same published domains and suggests what to study first — no score, no pass prediction.
Check your ISC2 Certified in Cybersecurity (CC) readiness →Full ISC2 Certified in Cybersecurity (CC) decision page →
A free, source-cited study companion built on ISC2's published Certified in Cybersecurity (CC) exam outline — not official training, not a pass guarantee. Verify the current objectives on the official page before your exam.
Certification and vendor names are used only to identify the program this independent study companion refers to. RoleMath is not affiliated with, endorsed by, or sponsored by ISC2.