RoleMath Study Track for ISC2 SSCP (Systems Security Certified Practitioner) (SSCP)
A free study companion keyed to the officially published exam domains of ISC2 SSCP (Systems Security Certified Practitioner) (SSCP): 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 SSCP Certification Exam Outline
A free, source-cited study companion built on ISC2's published SSCP certification exam outline — not official training, not a pass guarantee. SSCP is a defensive security-practitioner credential that assumes about a year of hands-on experience, and every lab here runs only on your own local VM to build defensive and identification skills — never against a real, third-party, or employer system. Verify the current outline on the official page before your exam.
A complete free ISC2 SSCP program pinned to the currently published exam outline and sequenced the way a practitioner builds understanding — concepts and access control first, then network and cryptography, then risk monitoring and incident response, and finally systems and application security with an integrated defensive capstone — with every hands-on lab bounded to a defensive drill on your OWN Ubuntu/Debian VM in VirtualBox (snapshot first, revert after, never a real or third-party system), and an explicit recheck of the official outline before any exam scheduling. This is not entry-level: SSCP assumes about a year of hands-on security work, so the diagnostic and goal paths reflect a practitioner audience, and completion is not certification, the required work experience, or a job.
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.
Modules
7
Labs
7
Concept checks
14
Resource mix
2 official / 2 community
Choose an outcome
Three routes through the same evidence
Choose provisionally. Change routes when the work tells you something new about fit, time, or readiness.
Certification-focused
Practitioners with roughly Security+-level knowledge, Linux command-line comfort, and ideally the ISC2-required work experience who want one current, dependency-ordered SSCP sequence across all seven domains, with every defensive lab run only on their own VM and a recheck of the official outline before scheduling.
Completion emphasis: Complete every module in the practitioner study order, run each defensive lab only on a VM you own (snapshot taken and reverted), correct every missed check, finish the integrated defensive capstone on your own VM, and diff the current outline before booking the exam — never inferring a score from coverage, and understanding that the exam has a separate one-year experience requirement.
Required phases: Security concepts, governance, and access controls, Network and communications security, then cryptography, Risk identification and monitoring, then incident response and recovery, Systems and application security, then the integrated defensive capstone
Practitioner skills first
Career changers or IT staff with some prior security exposure who want reviewable evidence that they can write a security policy, enforce least privilege, configure monitoring, run an incident-response runbook, apply cryptography and host hardening, and reason across the CIA triad on systems they own, whether or not they sit the exam soon.
Completion emphasis: Retain a labeled, redacted defensive artifact per domain — a security policy and threat table, a least-privilege configuration, a firewall and TLS/PKI record, an audit-and-risk-register capture, an incident-response runbook and execution log, and a hardening checklist — all produced only on a VM you own, plus the integrated capstone report and a snapshot-revert record proving nothing was left in place.
Required phases: Security concepts, governance, and access controls, Network and communications security, then cryptography, Risk identification and monitoring, then incident response and recovery, Systems and application security, then the integrated defensive capstone
Career-fit sprint
Learners deciding whether defensive security-practitioner work — the governance, access control, monitoring, and incident-response discipline the SSCP covers — is a direction worth deeper investment before committing to the full SSCP grind, given that it is not an entry-level certification and carries a one-year experience requirement.
Completion emphasis: Complete the diagnostic, the foundations-and-access phase, and the network-and-crypto phase with their defensive labs on your own VM, then choose a next security experiment or a full SSCP commitment rather than inferring job readiness, the required experience, or a pass from partial coverage.
Required phases: Security concepts, governance, and access controls, Network and communications security, then cryptography
Start safely
Prerequisite diagnostic
Confirm you meet the not-entry-level bar and can build and use a safe self-owned VM before the SSCP labs; this diagnostic is not an ISC2 prerequisite, a cost promise, or an exam prediction, and the SSCP is a practitioner credential that assumes roughly a year of hands-on security experience plus Security+-level knowledge.
Do you already have roughly Security+-level security knowledge — the CIA triad, access-control models, common controls, and basic networking and cryptography vocabulary — since the SSCP is practitioner-oriented and does not re-teach the fundamentals from zero?
Ready when: Yes, or you will review Security+-level fundamentals alongside the early domains rather than learning the baseline and the SSCP scope at once.
If not yet: Spend time on Security+-level fundamentals (or that track) first, because the SSCP builds on that baseline and its questions assume you already reason in these terms.
Are you comfortable working in a Linux command line — navigating the filesystem, running commands as a normal and a sudo user, editing text, and reading tool output — since nearly every SSCP lab here is a defensive drill on an Ubuntu/Debian VM?
Ready when: Yes, or you will use each lab's documented commands while you build CLI comfort in parallel and treat the fixture as a guided walkthrough.
If not yet: Practice basic Linux CLI (a free Linux fundamentals resource or the Linux+ track) before the access-control lab, because every later defensive lab assumes it.
Can you run an Ubuntu/Debian VM you own in VirtualBox — snapshot it, work inside it, and revert it — on your own hardware, so every defensive lab stays bounded to a system you own?
Ready when: Yes, with enough RAM and disk for one VM and the ability to take and revert snapshots, so every lab runs on your own VM only.
If not yet: Install VirtualBox and build a snapshotted Ubuntu/Debian VM first, or use the documentation-and-simulated route for any lab you cannot run locally, because no lab here targets any system you do not own.
Do you understand that the SSCP requires one year of cumulative paid work experience in at least one of the seven domains (a relevant degree can substitute for up to one year), and that passing without it makes you an Associate of ISC2 with two years to earn the experience?
Ready when: Yes, and you know whether you already hold the experience or will pursue the Associate-of-ISC2 path, and you understand this program builds knowledge and defensive skills but does not itself provide the required work experience.
If not yet: Read the official ISC2 experience and Associate-of-ISC2 requirements before planning your exam, because the credential is granted on experience plus the exam, not on completing any study program.
Have you chosen a pace whose weekly hours you can realistically protect across roughly 60 to 130 total hours depending on your prior security experience — fewer if you already hold Security+ and work in the field, more if you are still building the baseline?
Ready when: Yes, with a pace selected and the objective recheck, the defensive lab safety steps, and the capstone left uncompressed.
If not yet: Pick the steady pace and build foundations first if you do not yet hold Security+-level knowledge; never compress the snapshot, revert, and own-VM-only steps to save time.
Plan, then adapt
Pace options
Steady
12 weeks 6-8 hours/week
A planning estimate of roughly 60-80 hours for a learner who already holds Security+-level knowledge and has hands-on security experience: one phase at a time in the practitioner study order, every defensive lab run only on a VM you own with a snapshot taken and reverted, plus the integrated capstone and an outline recheck before scheduling. A learner without a Security+-level baseline should budget closer to 100-130 hours and build foundations first.
Standard
10 weeks 8-10 hours/week
A planning estimate for practitioners with some hands-on security exposure that pairs the ISC2-cited domain study with one retained, redacted defensive artifact per domain and preserves the integrated capstone, the missed-check corrections, and an outline-diff block before any exam logistics. Budget more time if you are still building the underlying baseline.
Intensive
8 weeks 12-14 hours/week
Roughly 90-110 hours compressed for an experienced learner who already works in security and holds Security+-level knowledge; do not compress the snapshot-and-revert discipline, the own-VM-only boundary, the incident-response runbook rehearsal, or the systems-hardening drill. A learner without the baseline should not attempt this pace and should build foundations first.
Evidence-gated sequence
Program roadmap
1
Security concepts, governance, and access controls
Build the conceptual and access-control frame the whole SSCP assumes: the CIA triad, policy and governance hierarchy, ethics, and risk vocabulary (Domain 1, 16%), then the access-control models, IAM lifecycle, AAA, least privilege, and zero trust (Domain 2, 15%) — made concrete by a documentation-and-integrity drill and a least-privilege configuration on a VM you own, snapshotted and reverted.
Complete the Domain 1 documentation lab on your own snapshotted VM: build a CIA-mapped asset-and-threat table, draft a one-page information security policy, run a sha256 integrity-baseline drill, and tie the policy to an ISC2 ethics canon, then revert the snapshot.
Complete the Domain 2 least-privilege lab on your own VM: create local test users and a group, enforce group-restricted and owner-only permissions, configure a narrowly scoped sudo rule, verify both the allow and the deny case, then run the teardown and revert the snapshot.
Complete the security-baseline, Linux-CLI, own-VM, experience-and-Associate, and study-time diagnostics, choose a pace you can protect, and be able to state the CIA triad, the DAC/MAC/RBAC/ABAC distinction, and why least privilege limits the blast radius of a compromised account.
Attempt every authored Security Concepts and Access Controls check and correct each miss against its cited source before moving to network and cryptography.
2
Network and communications security, then cryptography
Learn how traffic moves and is secured, then how the cryptography embedded everywhere actually works: network attacks, segmentation, secure protocols, and host firewalling (Domain 6, 16%), then symmetric and asymmetric cryptography, hashing, TLS, and PKI (Domain 5, 9%) — made concrete by configuring a host firewall and inspecting your own VM's traffic, and by hashing, encrypting, and building a small certificate chain on a VM you own.
Complete the Domain 6 network-security lab only on your own snapshotted VM: configure a host firewall (for example ufw or nftables) with a default-deny stance and explicit allow rules, and capture only your own VM's loopback or local traffic with tcpdump to see secure-versus-cleartext behavior, then revert the snapshot.
Complete the Domain 5 cryptography lab on your own VM: hash a file and demonstrate integrity, perform symmetric and asymmetric encryption and decryption with openssl, and build and verify a small self-signed certificate chain to make TLS and PKI concrete, retaining the outputs as evidence.
Retain a firewall-and-traffic record and a cryptography record, both produced only on a VM you own, and be able to explain how confidentiality, integrity, and authentication map to the specific controls you configured.
Attempt every authored Network and Communications Security and Cryptography check and correct each miss against its cited source, tracing why each secure protocol or key type is used where it is.
3
Risk identification and monitoring, then incident response and recovery
Work the operational pair: identify and treat risk, configure monitoring, and turn log data into signal (Domain 3, 15%), then run the disciplined detect-contain-recover incident lifecycle (Domain 4, 14%) — made concrete by configuring auditd, analyzing the events, and building a risk register on your own VM, then authoring and executing an incident-response runbook against a self-owned test scenario, snapshotted and reverted.
Complete the Domain 3 monitoring lab on your own snapshotted VM: configure an auditd watch on a sensitive file, trigger and analyze read and attribute events with ausearch and aureport, review failed authentications, and build a small risk register with likelihood, impact, and residual risk, then remove the watch and revert.
Complete the Domain 4 incident-response lab on your own VM: author a scenario-specific runbook, execute it against a controlled self-owned test event through the detect, contain, eradicate, and recover phases, preserve evidence before altering the system, and record a lessons-learned note, then revert the snapshot.
Retain an audit-and-risk-register capture and an incident-response runbook plus its execution log, both produced only on a VM you own, and be able to draw the event-versus-incident line and explain evidence-handling and chain-of-custody basics.
Attempt every authored Risk Identification, Monitoring and Analysis and Incident Response and Recovery check and correct each miss against its cited source, tracing why each monitoring signal or response phase matters.
4
Systems and application security, then the integrated defensive capstone
Close with the broadest, most technical domain and then integrate everything: endpoint and host hardening, malware defense, secure configuration, and cloud and application security (Domain 7, 15%), made concrete by a hardening drill on your own VM — then run the integrated defensive capstone that spans all seven domains on a single VM you own and produces a reviewable evidence packet, snapshotted and reverted.
Complete the Domain 7 systems-security lab on your own snapshotted VM: apply a hardening checklist — disable unneeded services, tighten configuration, verify file integrity, and review host defenses — record before-and-after evidence, then revert the snapshot.
Complete the integrated defensive capstone on a single VM you own, spanning security governance, access controls, network security, cryptography, risk monitoring, incident response, and systems hardening, and produce the capstone evidence packet with a snapshot-revert confirmation.
Retain a hardening checklist and the capstone report, both produced only on a VM you own, and crosswalk every artifact to the seven SSCP domain IDs.
Diff the current ISC2 SSCP exam outline, record remaining gaps, and choose a continue, practice, defer, Associate-of-ISC2, or exam-scheduling next decision rather than inferring a pass from coverage.
Before a lab
Environment, access, and safety
Required and optional setup
Required
A browser plus text, spreadsheet, and diagram tools for the ISC2-cited exam outline, the ISC2 Code of Ethics, and for recording each defensive lab's artifacts, findings, and snapshot-revert confirmation
An Ubuntu/Debian VM you own in VirtualBox on your own hardware, snapshotted before each lab and reverted after — every SSCP lab here is a defensive or documentation drill scoped to this self-owned VM, and no lab targets any system you do not own
The free, preinstalled Linux tooling the labs use — a text editor, sha256sum, useradd/groupadd/chmod/chown/visudo, ufw or nftables, tcpdump, openssl, and auditd (auditctl/ausearch/aureport) — used only on your own VM, never against a real, third-party, or network target
A snapshot-and-revert ledger recording, for each lab, that the work stayed on your own VM, no real or third-party system was touched, and the VM was reverted to its pre-lab snapshot
Optional
A second Ubuntu/Debian VM you own on a VirtualBox Host-Only network to practice segmentation and monitoring between two of your own machines rather than describing it only
The ISC2 Code of Ethics and a chosen security framework reference (NIST or ISO 27001 overview) open in a browser as a shared vocabulary for governance and risk artifacts
A free ISC2-authored Coursera SSCP audit or a reputable free walkthrough as an alternate explanation after the official ISC2 outline (verify it is free and current before relying on it)
Accounts and accessibility routes
Accounts
The core VirtualBox route requires no account and no payment: Ubuntu/Debian and every tool the labs use are free, and each defensive lab runs offline or loopback-only on a VM you own.
The optional ISC2-authored Coursera SSCP course can be audited free (verify the free-audit label before relying on it, since paid certificate tiers exist), and ISC2's free SSCP quiz and flashcards may require a free ISC2 web account.
No lab requires a paid subscription, a cloud account, or a card; if any optional resource ever moves a needed exercise behind a paywall, rely on the official outline and the self-owned VM labs instead.
Equivalent routes
When running local VMs is impractical for account, device, memory, motor, or visual reasons, complete each lab as a documentation-and-simulated walkthrough: study the objective, read the fixture's documented commands, and record a written expected-state walkthrough labeled simulated, reaching the same defensive understanding and the same template evidence with no local setup.
Every lab is command-line and text driven, so the whole program is keyboard-operable with plain-text tool output a screen reader can read; the threat-model, policy, risk-register, runbook, and hardening templates are plain Markdown with labeled headings and fields, and no step requires pointer-only interaction.
In low-bandwidth conditions run the local VM labs, which generate no internet traffic beyond a one-time package install, and record every artifact in a local document; the only online references — the ISC2 outline and Code of Ethics — are lightweight text pages.
Safety baseline
Run every command, drill, and configuration ONLY on the Ubuntu/Debian VM you own in VirtualBox — never a real, third-party, employer, school, corporate, cloud, or internet system; these are defensive and identification exercises only, never offensive ones.
Snapshot your own VM before every lab and revert to that snapshot after finishing, so no test account, permission change, firewall rule, audit watch, or hardening change persists.
Never scan, attack, connect to, or capture traffic from any system other than your own VM; run tcpdump only on your own VM's own interfaces (loopback or a Host-Only adapter to a second VM you own), and never point any tool at a real network, router, or organization.
Use fictional or self-owned data in every worksheet, policy, risk register, and runbook — never enter a real organization's data, credentials, or personal information — and delete any local practice files after recording them.
This program builds defensive knowledge and skills only; it grants no authorization to configure, monitor, or test any system you do not own, and unauthorized access to a computer is a crime (e.g. 18 U.S.C. Sec. 1030 in the US).
Show your work
Module evidence and missed-check protocol
Module exit evidence
A labeled, redacted defensive artifact per domain tied to its module: a CIA threat table and one-page security policy; a least-privilege configuration record; a firewall-and-traffic record; a cryptography record with a small certificate chain; an audit-and-risk-register capture; an incident-response runbook and execution log; or a systems-hardening checklist with before-and-after evidence — each produced only on a VM you own.
A plain-language explanation of the concept, which CIA property or control it serves, the tool and command used, the authorization boundary it stayed inside (your own VM only), what a defender should do in response, and the condition that would change the finding.
All authored checks for the domain attempted, with each miss corrected against its cited source and re-applied to a fresh scenario, plus a recorded snapshot-and-revert confirmation for every lab, since SSCP questions are experience-based and hands-on evidence matters more than recall.
After a missed check
Identify whether the question tests security concepts and governance, access controls, risk identification and monitoring, incident response and recovery, cryptography, network and communications security, or systems and application security before reviewing the answer.
Write why the distractor was plausible and which principle — the CIA property at stake, the access-control model, the risk-treatment choice, the incident-response phase, the cryptographic property, the network control, or the hardening step — distinguishes the correct answer, framing it as what a practitioner would do rather than a definition.
Change one scenario detail — the asset, the access-control model, the environment, the incident phase, or the trust boundary — and explain whether the correct answer changes.
Completing this policy demonstrates current-outline SSCP coverage and hands-on defensive practice inside RoleMath on a VM you own; because SSCP questions are experience-based, that hands-on evidence is meaningful, but it does not predict an exam score, satisfy ISC2's separate one-year work-experience requirement, establish professional security experience, confer any authorization to configure or test systems you do not own, or serve as a RoleMath credential.
Integrated practice
Integrated defensive scenario on a VM you own, with a redacted evidence packet
Run a complete, integrated defensive exercise on a single Ubuntu/Debian VM you own on an isolated host — set access controls and monitoring, respond to a simulated local incident, and apply cryptography, host firewalling, and hardening — then write a redacted evidence packet and revert the VM, integrating all seven SSCP domains into one reviewable artifact.
Workflow
Snapshot the Ubuntu/Debian VM you own, confirm the whole exercise stays on this self-owned VM (offline or loopback-only, or Host-Only to a second VM you also own), and write a one-page security policy and CIA-mapped threat table framing what you are protecting and why (Domain 1).
Set access controls on the VM: create local test users and a group, enforce group-restricted and owner-only permissions, and configure a narrowly scoped sudo rule, verifying both the allow and the deny case (Domain 2).
Apply cryptography: hash a sensitive file to establish an integrity baseline, encrypt and decrypt it with openssl, and build and verify a small self-signed certificate chain to make TLS and PKI concrete (Domain 5).
Harden the network surface: configure a host firewall with a default-deny stance and explicit allow rules, and capture only your own VM's loopback or local traffic with tcpdump to confirm secure-versus-cleartext behavior (Domain 6).
Configure monitoring and build a risk register: set an auditd watch on a sensitive file, trigger and analyze events with ausearch and aureport, review failed authentications, and record likelihood, impact, current control, and residual risk for each entry (Domain 3).
Respond to a simulated local incident: author a scenario-specific runbook, then execute the detect-contain-eradicate-recover cycle against a controlled self-owned test event — preserving evidence before altering the system and maintaining a chain-of-custody note (Domain 4).
Harden the host and application surface: apply a hardening checklist — disable unneeded services, tighten configuration, verify file integrity against the earlier baseline, and review host defenses — recording before-and-after evidence (Domain 7).
Write a redacted evidence packet — an executive summary, the per-domain artifacts, the incident timeline and lessons learned, and a hardening summary — using fictional or self-owned details and redacting anything that should not be shared, then record a lessons-learned note tying the exercise back to the CIA triad.
Run the cleanup checklist: remove the test users, firewall rules, audit watch, and practice files, delete any harvested material after documenting it, and revert the VM to its pre-lab snapshot, then verify nothing persists and crosswalk every artifact to the seven SSCP domain IDs, diff the current outline, flag any uncovered topics as explicit gaps, and record the next SSCP or exam-scheduling decision.
Retained artifacts
A one-page security policy and a CIA-mapped asset-and-threat table framing the exercise, bounded to your own VM
An access-control record: local users and a group, group-restricted and owner-only permissions, and a scoped sudo rule with both the allow and deny case verified
A cryptography-and-network record: an integrity hash baseline, openssl encryption/decryption output, a verified small certificate chain, a default-deny firewall configuration, and a loopback-only traffic capture
A monitoring-and-risk record: an auditd analysis with ausearch/aureport output, a failed-authentication review, and a risk register with likelihood, impact, and residual risk
An incident-response record: a scenario runbook, an execution log through detect-contain-eradicate-recover, an evidence-preservation and chain-of-custody note, and a lessons-learned entry
The redacted integrated evidence packet (executive summary, per-domain artifacts, hardening summary), a snapshot-revert confirmation, and a seven-domain crosswalk with an outline diff
Review checklist
Governance, access controls, cryptography, network security, monitoring, incident response, and hardening describe one consistent defensive exercise run entirely on a single Ubuntu/Debian VM the learner owns.
The VM was snapshotted before the exercise, every step stayed on the self-owned VM, tcpdump captured only the learner's own VM traffic, and no tool was ever pointed at a real, third-party, network, or internet target.
Each per-domain artifact is present and concrete — a policy and threat table, a verified least-privilege configuration, working cryptography and a certificate chain, a default-deny firewall, an audit analysis and risk register, an executed incident runbook, and a before-and-after hardening record.
The incident-response section preserved evidence before altering the system, maintained a chain-of-custody note, and closed with a lessons-learned entry, staying within the simulated self-owned scenario.
Cleanup removed the test users, firewall rules, audit watch, and practice files, deleted harvested material after documenting it, and reverted the VM to its pre-lab snapshot with nothing left behind.
The evidence packet uses fictional or self-owned details, redacts anything that should not be shared, and publishes no real target, credential, or organization data.
The current ISC2 SSCP exam outline was rechecked and any changed domain, weight, or format invalidates the affected mapping or review.
All seven current SSCP domains map to at least one artifact; uncovered topics remain explicit gaps rather than implied completion.
The packet does not claim exam success, official ISC2 approval or training beyond linked sources, satisfaction of the one-year experience requirement, any authorization to test systems the learner does not own, professional security experience, or a RoleMath credential.
Safety boundary: Run the entire capstone ONLY on an Ubuntu/Debian VM you own in VirtualBox (snapshot it first) — never a real, third-party, employer, school, corporate, cloud, or internet target; capture traffic only on your own VM's interfaces, use fictional or self-owned data everywhere, keep every technique defensive, preserve then delete any evidence you gather, and revert the VM to its pre-lab snapshot when finished. This program grants no authorization to configure, monitor, or test any system you do not own, and unauthorized access is a crime (e.g. 18 U.S.C. Sec. 1030).
Finish honestly
Completion, portfolio, and maintenance
Completion evidence
All seven current SSCP domain modules have been covered and checked against the official ISC2 SSCP exam outline, including a recheck of the current outline before any exam scheduling.
Every domain lab has been run only on an Ubuntu/Debian VM the learner owns — or completed as a documented-and-simulated walkthrough — with the VM snapshotted and reverted, no real or third-party system touched, and its redacted defensive artifact retained.
Every authored knowledge check has been attempted and each miss has a cited correction plus a fresh scenario.
The official ISC2 outline and any free ISC2-authored or community resources have been used within their current free-access terms, with any community walkthrough reconciled to the official outline.
The integrated defensive capstone passes its consistency, own-VM boundary, evidence-handling, cleanup, redaction, and seven-domain coverage review, with nothing left on the VM.
The learner has recorded remaining objective gaps and a next SSCP, Associate-of-ISC2, or exam-scheduling decision; completion is not represented as an exam result, a credential, the separate one-year work-experience requirement, authorization to test systems the learner does not own, job readiness, or professional security experience.
Portfolio candidates
A security-governance record: a one-page information security policy and a CIA-mapped threat table, with an integrity-baseline hash, bounded to a self-owned VM
An access-control record: a least-privilege configuration with group-restricted and owner-only permissions and a scoped sudo rule, both allow and deny cases verified
A network-and-cryptography record: a default-deny host firewall, a loopback-only traffic capture, openssl encryption/decryption output, and a verified small certificate chain
A monitoring-and-risk record: an auditd analysis with ausearch/aureport output and a risk register with likelihood, impact, and residual risk
An incident-response record: a scenario runbook, an execution log through the detect-contain-eradicate-recover cycle, an evidence-preservation note, and a lessons-learned entry
The integrated capstone redacted evidence packet with a snapshot-revert confirmation and a seven-domain crosswalk
Present the packet as self-directed SSCP defensive practitioner practice done only on a VM you own. Do not call it real-world security operations, ISC2 approval, the required one-year work experience, authorization to configure or test any system you do not own, professional security experience, or a RoleMath credential, and never publish real targets, credentials, or organization data.
Freshness controls
Objective source checked 2026-07-10. Recheck objectives every 30 days and resources every 90 days.
Stop and re-verify when
ISC2 revises the SSCP exam outline, domain set, domain names or weights, exam code, CAT format, passing score, experience or Associate-of-ISC2 terms, recertification or CPE requirements, or fees.
A tool the labs use (VirtualBox, Ubuntu/Debian, sudo/visudo, ufw or nftables, tcpdump, openssl, or auditd and its ausearch/aureport tools) changes availability, behavior, command syntax, or free-access terms.
An optional resource (the ISC2-authored Coursera SSCP audit, the ISC2 free quiz or flashcards, or a cited community walkthrough) changes URL, access, its free tier, or its currency.
A lab can no longer be run entirely on a self-owned VM within the free tier, or its snapshot-and-revert, own-VM-only, loopback-only-capture, or fictional-data guarantees no longer hold.
A security-concepts, access-control, risk-and-monitoring, incident-response, cryptography, network-security, or systems-security concept materially changes in the outline, or a domain is added, removed, or reweighted.
Any module, lab, check, phase, capstone step, account instruction, safety guardrail, or outline diff fails technical, source, defensive-security-domain, practitioner-level, safety, authorization, privacy, accessibility, currency, or claims review.
Skills measured
The official objective domains and their exam weight — titles & weights only, straight from the vendor’s exam objectives. ISC2 SSCP Certification Exam Outline
For SSCP we deliberately depart from the published numbering, because a practitioner-oriented exam rewards building understanding in layers rather than domain order. ISC2 weights the seven domains as Security Concepts and Practices 16%, Access Controls 15%, Risk Identification, Monitoring and Analysis 15%, Incident Response and Recovery 14%, Cryptography 9%, Network and Communications Security 16%, and Systems and Application Security 15%, so five of the seven cluster tightly between 14% and 16% and the whole exam is broad rather than lopsided. We open with Security Concepts and Practices (Domain 1, 16%) because it is the conceptual frame — the CIA triad, policy and governance, ethics, and the vocabulary of access control — that every other domain assumes; nothing downstream makes sense without it. Access Controls (Domain 2, 15%) comes next because identity, authentication, authorization, and least privilege are the daily bread of a security practitioner and reappear inside every later domain. Then we jump to Network and Communications Security (Domain 6, 16%), one of the two heaviest domains, because understanding how traffic moves, how it is secured, and where it is attacked gives you the context you need for both cryptography and systems security. Cryptography (Domain 5, 9%) is the lightest domain by weight but it is embedded everywhere — in access controls, in secure protocols, in incident evidence handling — so we place it right after networking, where TLS and PKI have just become concrete. With those foundations set, Risk Identification, Monitoring and Analysis (Domain 3, 15%) and Incident Response and Recovery (Domain 4, 14%) follow naturally as the operational pair: you monitor and assess risk, then you respond when monitoring surfaces an incident. We close with Systems and Application Security (Domain 7, 15%), the broadest and most technical domain, because hardening, malware defense, endpoint and cloud security lean on everything before it. A crucial note on how to study: SSCP questions are experience-based — they ask what you would do as a practitioner facing a situation, not whether you can recite a definition — so hands-on practice on your own VM matters more than memorization, and this order is built to give each lab the context it needs. This is sequencing advice based on the published weights and the exam's practitioner framing, not a claim about the science of learning; if a different order fits how you think, use it.
Study this first. At 16% it is tied for the heaviest domain, and it is the conceptual frame — the CIA triad, policy and governance, ethics, and the vocabulary of access control — that every other domain assumes. Nothing downstream makes sense without it.
What this domain actually covers
Plain-language explanation in our own words — paraphrased from, and checked against, the official objectives. ISC2 SSCP Certification Exam Outline
This is the 'what security actually means, and how an organization governs it' domain, and ISC2 weights it at 16% of the exam — tied with Network and Communications Security for the heaviest slice. Security Concepts and Practices is the conceptual foundation of the whole SSCP: it establishes the vocabulary, the guiding principles, and the professional obligations that every later domain builds on. We insist you study it first, because access controls, monitoring, incident response, cryptography, and systems hardening are all instruments for achieving the goals this domain defines. If you cannot articulate what you are protecting and why, the rest of the certification is a toolbox with no plan.
The CIA triad is the heart of the domain — confidentiality, integrity, and availability, the three properties every security control ultimately serves. Confidentiality keeps information away from those not authorized to see it; integrity ensures data is accurate and has not been tampered with; availability ensures systems and data are there when legitimate users need them. A capable practitioner reasons fluidly across all three: encryption protects confidentiality, hashing and change control protect integrity, and redundancy and backups protect availability. The exam expects you to map a scenario to the property at risk and to the control that restores it, rather than reciting the definitions in isolation. Related concepts — non-repudiation, authentication, authorization, accountability, and privacy — extend this core and recur throughout the outline.
Governance and the policy hierarchy give security its structure inside an organization. Policies state high-level intent and management's direction; standards make policy measurable and mandatory; procedures give the step-by-step how; and guidelines offer recommended, non-mandatory practice. A security practitioner has to know how these documents relate and where a given rule belongs, because a control without a governing policy is arbitrary and a policy with no procedure is unenforceable. Underlying all of it are the concepts of least privilege and separation of duties — grant only the access a role needs, and split sensitive tasks so no single person can abuse them. Security frameworks such as NIST and ISO 27001 provide reference structures that organize these controls into a coherent, auditable program.
Ethics is not an afterthought in this domain — it is examinable and enforceable. ISC2 members agree to the ISC2 Code of Ethics, whose canons commit them to protect society and the infrastructure, act honorably and legally, provide diligent and competent service, and advance and protect the profession. The exam can present ethical dilemmas and ask which action the code requires, and violating the code can cost a member their certification. A practitioner internalizes that the credential carries a duty of care: you are trusted with access to sensitive systems, and the ethics canons are the promise that goes with that trust. Study the canons well enough to reason with them, not merely to name them.
Risk basics and security awareness round out the domain and connect it to the operational domains later in the outline. At this stage you learn the vocabulary of risk — threats, vulnerabilities, likelihood, impact, and the difference between a risk you accept, mitigate, transfer, or avoid — which Domain 3 then deepens into a full monitoring and analysis discipline. Security awareness is the recognition that people are part of the control surface: training, phishing resistance, and a security-conscious culture are as much a defense as any firewall. The recurring theme is that security is a management and governance problem first and a technical problem second, and that a practitioner serves the organization's goals, defined here, with the tools taught everywhere else.
Study this domain by producing the artifacts a governance program is made of, because SSCP is practitioner-oriented and rewards judgment over recall. The lab below is a documentation exercise on your own VM: using the CIA-threat-model-and-policy fixture, you build a short asset-and-threat table mapped to the CIA triad, draft a one-page information security policy, and run a small file-integrity baseline drill with sha256 to make the integrity property concrete. As always, read the official SSCP exam outline for ISC2's authoritative topic list; this explanation paraphrases its scope in our own words rather than reproducing it.
Learn it free
Official · Official exam outline
ISC2 SSCP Certification Exam OutlineThe exam's own topic list for this domain — read its Security Concepts and Practices section directly rather than relying on any summary, including ours. (captured 2026-07-10)
Official · Free official practice quiz
ISC2 free SSCP practice quizA free, official ISC2 quiz that samples across the SSCP domains, including the core security concepts this domain covers — a low-friction way to test your baseline understanding (verify the free label before relying on it). (captured 2026-07-10)
Sscp Security Concepts Lab
Map assets and threats to the CIA triad and draft a one-page information security policy Record a sha256 integrity baseline and demonstrate that a one-character change alters the hash
Free tools
VirtualBox on your own hardware
Ubuntu/Debian VM you own
Linux terminal and a text editor
Steps
Snapshot your own Ubuntu/Debian VM, then open the cia-threat-model-and-policy.md fixture and read its top note confirming every field is for a fictional or your-own small environment and every command runs on your own VM.
Fill in the asset-and-threat table: for each asset, name a plausible threat, the CIA property it impacts, and a mitigating control, then draft the one-page information security policy with all its sections.
Save the policy to a file on your own VM, set restrictive permissions, record its sha256 baseline, then change one word and re-run sha256sum to observe the hash change completely.
Open the ISC2 Code of Ethics and note in your policy which ethics canon most directly supports your incident-reporting and data-handling rules, then save the finished worksheet as evidence.
What you should see
Confirm the worksheet contains a CIA-mapped threat table, a complete one-page policy, a recorded sha256 baseline whose hash changes after a one-character edit, and a reference to at least one ISC2 ethics canon.
Practice evidence maps to exam_domain_isc2_sscp_systems_security_certified_practitioner_01
Stay safe & legal: Every field and command in this lab is for a fictional or your-own small environment and runs only on the Ubuntu/Debian VM you own; never enter a real organization's data or run any command against a real, third-party, employer, school, or corporate system. This is a defensive documentation exercise only. Account required: no; payment required: no; maximum designed cost: $0.
Check yourself
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 7 · domain 2 · 15% of the exam
Access Controls
Study this second, right after the concepts. At 15% it is a middle-weight domain, and identity, authentication, authorization, and least privilege are the daily bread of a security practitioner — they reappear inside every later domain, so mastering them early pays off everywhere.
What this domain actually covers
Plain-language explanation in our own words — paraphrased from, and checked against, the official objectives. ISC2 SSCP Certification Exam Outline
This is the 'who can do what, and how you prove it' domain, and ISC2 weights it at 15% of the exam. Access Controls is where the abstract goals of Domain 1 — confidentiality and least privilege — become concrete mechanisms. It is arguably the most operationally important domain for a working security practitioner, because controlling access is the single most common and most consequential job in day-to-day security. We study it second, right after the concepts, because the vocabulary and models here reappear inside monitoring, incident response, network security, and systems security; a shaky grasp of access control weakens every domain that follows.
The subject-object model is the mental frame the whole domain rests on. A subject is an active entity — a user, a process, a service — that requests access; an object is a passive resource — a file, a database, a device — being accessed. Access control is the discipline of deciding which subjects may perform which actions on which objects, and enforcing that decision. Everything else in the domain is a way of expressing or enforcing that relationship, and the exam expects you to reason in these terms: identify the subject, the object, the requested action, and the rule that permits or denies it.
The access-control models are the heart of the domain, and you need to distinguish them cleanly. Discretionary access control (DAC) lets the owner of a resource decide who else may access it — flexible but only as disciplined as the owner. Mandatory access control (MAC) enforces access based on labels and clearances set centrally, so users cannot override policy — rigid but strong, common in high-security environments. Role-based access control (RBAC) grants permissions to roles and assigns users to roles, which scales cleanly in organizations. Attribute-based access control (ABAC) makes decisions from attributes of the subject, object, action, and context, enabling fine-grained, dynamic policy. The exam routinely presents a scenario and asks which model fits, so know the trade-offs, not just the acronyms.
Identity and access management (IAM) is the lifecycle that surrounds those models: provisioning an identity when someone joins, managing it as their role changes, and de-provisioning it when they leave — the last of which is a frequent real-world failure that leaves dangerous orphaned accounts. Within IAM the exam emphasizes the AAA trio: authentication (proving you are who you claim, ideally with multi-factor authentication combining something you know, have, and are), authorization (granting exactly the access the authenticated identity should have), and accountability (logging actions to a specific identity so behavior can be audited). Multi-factor authentication in particular is a recurring, examinable control, because it defeats the single most common attack — stolen or guessed passwords.
Least privilege and modern trust architectures tie the domain to current practice. Least privilege — grant only the minimum access a subject needs, for only as long as it needs it — is the principle that limits the blast radius of any compromised account, and separation of duties reinforces it by splitting sensitive tasks. Zero trust extends these ideas into an architectural stance: never trust implicitly based on network location, always verify explicitly, and assume breach — every request is authenticated and authorized as if it came from an untrusted network. A practitioner should recognize zero trust as the direction the industry has moved and be able to connect it back to least privilege and continuous verification. This is exactly the discipline the lab below makes concrete on your own VM.
Study this domain by implementing access control by hand, because SSCP rewards the practitioner who has actually configured it. The lab below uses the DAC least-privilege fixture on your own Ubuntu/Debian VM: you create local users and a group, set group-restricted and owner-only file permissions, and configure a narrowly scoped sudo rule to see least privilege enforced — then tear it all down. As always, read the official SSCP exam outline for ISC2's authoritative topic list; this explanation paraphrases its scope in our own words rather than reproducing it.
Learn it free
Official · Official exam outline
ISC2 SSCP Certification Exam OutlineThe authoritative topic list for this domain's access-control coverage — read it directly rather than relying on any summary, including ours. (captured 2026-07-10)
Official · Free official flashcards
ISC2 free SSCP flashcardsFree, official ISC2 flashcards that drill the access-control vocabulary and models this domain tests (note: the flashcards may still show Domain 1's old name, since ISC2 renamed it in 2024 - the current outline is authoritative). (captured 2026-07-10)
Sscp Access Controls Lab
Create local users and groups and enforce least privilege with discretionary file permissions Configure a narrowly scoped sudo rule and verify that broader access is denied
Free tools
VirtualBox on your own hardware
Ubuntu/Debian VM you own
Linux terminal
Steps
Snapshot your own VM, then run the fixture's user and group provisioning to create two local users and a group and add one user to the group.
Create a group-restricted shared directory (770) owned by root:secteam and an owner-only file (600), then verify that a non-member is denied and even group members cannot read the owner-only file.
Configure a narrowly scoped sudo rule via visudo that lets alice run exactly one command as root, then verify her sudo scope and that a broader command is denied.
Run the fixture's teardown to delete the users and group, remove the directory, and remove the sudo rule, then revert your VM to its snapshot.
What you should see
Confirm the captures show a group member allowed and a non-member denied on the 770 directory, an owner-only 600 file protected, a scoped sudo rule permitting exactly one command, and a completed teardown.
Practice evidence maps to exam_domain_isc2_sscp_systems_security_certified_practitioner_02
Stay safe & legal: Every user, group, permission, and sudo change in this lab is local to the Ubuntu/Debian VM you own; never create accounts, change permissions, or edit sudoers on a shared, corporate, employer, school, or third-party system. This is a defensive configuration exercise on your own VM only. Account required: no; payment required: no; maximum designed cost: $0.
Check yourself
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 7 · domain 6 · 16% of the exam
Network and Communications Security
Study this third, after access controls. At 16% it is tied for the heaviest domain, and understanding how traffic moves, how it is secured, and where it is attacked gives you the context you need for both cryptography and systems security - so it earns an early slot despite its technical depth.
What this domain actually covers
Plain-language explanation in our own words — paraphrased from, and checked against, the official objectives. ISC2 SSCP Certification Exam Outline
This is the 'how data moves safely across networks, and how attackers try to intercept or disrupt it' domain, and ISC2 weights it at 16% of the exam — tied with Security Concepts and Practices for the heaviest slice. Network and Communications Security is one of the most technical domains and one of the most important for a defensive practitioner, because so much of security is fundamentally about controlling and monitoring traffic. We deliberately study it third, ahead of its published position, because understanding how networks work and how they are secured gives essential context for cryptography (TLS lives here) and for systems security (endpoints sit on networks). A solid grasp of this domain makes several others click into place.
The networking models provide the shared frame. The OSI seven-layer model and the TCP/IP model describe how data is encapsulated and moved from an application on one host to an application on another, and security professionals use the layers as a common language — an attack or a control can be described by the layer it operates at. You are expected to know the layers, what happens at each, and the core protocols (IP, TCP, UDP, DNS, HTTP/HTTPS) well enough to reason about where a security issue or a defense belongs. This is not deep networking engineering, but it is the vocabulary the rest of the domain depends on, and the exam assumes you are fluent in it.
Secure protocols and the defensive perimeter are the domain's protective core. The practitioner's job is to prefer secure protocols over their insecure predecessors — HTTPS over HTTP, SSH over Telnet, SFTP over FTP — because the secure variants add encryption and authentication that the originals lack. Around the traffic sit the classic controls: firewalls that filter traffic against a rule set (and the least-privilege stance of denying inbound by default and allowing only what is needed), intrusion detection and prevention systems (IDS/IPS) that watch for and can block malicious patterns, and network segmentation with VLANs that limits how far an attacker can move once inside. The exam expects you to match a control to a defensive goal and to recognize the least-privilege posture the lab below configures with a host firewall.
Remote access, VPNs, and wireless security extend the perimeter to distributed and mobile users. A virtual private network (VPN) creates an encrypted tunnel so that traffic crossing an untrusted network is protected, and secure remote-access and telework practices matter more than ever as work decentralizes — the exam explicitly cares about securing remote and telework connections. Wireless security is its own concern: Wi-Fi authentication and encryption standards (with WPA3 the current strong choice and older WEP/WPA thoroughly broken) determine whether a wireless network is a safe extension of the LAN or an open door. A practitioner recognizes the secure options, the deprecated ones, and the risks each mitigates.
Network attacks and their defenses close the domain, and here the SSCP's defensive framing is important. You are expected to recognize common attacks — denial of service and distributed denial of service, on-path (man-in-the-middle) interception, spoofing, and DNS-based attacks — and, crucially, to know the defenses: segmentation, filtering, monitoring, secure protocols, and rate limiting. The recognition is defensive: you learn how these attacks work so you can detect and prevent them, never so you would launch them. The lab below reflects this exactly — you configure a host firewall for a least-privilege inbound stance and use tcpdump to observe traffic on your own VM to understand what normal and secure communication looks like, a purely defensive, identification-focused skill.
Study this domain by configuring a defensive control and observing traffic on your own VM, because seeing the packets makes the models real. The lab below uses the firewall-tcpdump fixture on your own Ubuntu/Debian VM: you configure the ufw host firewall to deny inbound by default and allow only what you need, run a local loopback TCP session, and capture the handshake with tcpdump — strictly on your own VM's own interfaces. As always, read the official SSCP exam outline for ISC2's authoritative topic list; this explanation paraphrases its scope in our own words rather than reproducing it.
Learn it free
Official · Official exam outline
ISC2 SSCP Certification Exam OutlineThe authoritative topic list for this domain's network and communications security coverage — worth reading in full given its 16% weight, tied for the heaviest on the exam. (captured 2026-07-10)
Official · Official ISC2 course content (free audit)
ISC2 SSCP training program on Coursera (free audit)ISC2's own SSCP course content, auditable for free, with dedicated coverage of the network-security material (the certificate and graded work are paid, and audit access to individual courses varies - verify what is free before relying on it). (captured 2026-07-10)
Sscp Network Security Lab
Configure a host firewall for a deny-inbound-by-default least-privilege stance Capture a local loopback TCP handshake with tcpdump and identify the three-way handshake
Free tools
VirtualBox on your own hardware
Ubuntu/Debian VM you own
Linux terminal with ufw and tcpdump
Steps
Snapshot your own VM, allow SSH first if you manage the VM remotely, then set the firewall to deny inbound by default and allow outgoing, enable it, and verify the status.
Run a local loopback TCP session with netcat (a listener and a client both on 127.0.0.1) so there is traffic to observe entirely within your own VM.
Capture the loopback handshake with tcpdump while the netcat session runs, and identify the TCP three-way handshake in the output.
Run the fixture's teardown to remove any added allow rules and disable ufw if desired, then revert your VM to its snapshot.
What you should see
Confirm the ufw status shows a deny-inbound-by-default stance with only explicit allows, and the tcpdump capture shows a loopback TCP three-way handshake with SYN, SYN-ACK, and ACK identified, all on the learner's own VM.
Practice evidence maps to exam_domain_isc2_sscp_systems_security_certified_practitioner_06
Stay safe & legal: Configure the firewall and run tcpdump only on the Ubuntu/Debian VM you own and its own interfaces; never run tcpdump on a shared, corporate, employer, or school interface without explicit authorization, and never scan or capture traffic from hosts you do not own. This is defensive network configuration and observation on your own VM only. Account required: no; payment required: no; maximum designed cost: $0.
Check yourself
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 7 · domain 5 · 9% of the exam
Cryptography
Study this fourth, right after networking. At 9% it is the lightest domain by weight, but cryptography is embedded everywhere - in access controls, secure protocols, and evidence handling - so placing it just after networking, where TLS and PKI have become concrete, makes it stick.
What this domain actually covers
Plain-language explanation in our own words — paraphrased from, and checked against, the official objectives. ISC2 SSCP Certification Exam Outline
This is the 'how we make data secret, prove it is unaltered, and trust who sent it' domain, and ISC2 weights it at 9% of the exam — the lightest domain by weight. But weight is misleading here: cryptography is woven through nearly every other domain, so a practitioner who understands it well finds access controls, network security, and evidence handling all easier. We deliberately study it fourth, right after Network and Communications Security, because that domain makes TLS, certificates, and secure protocols concrete, and cryptography is far easier to absorb once you have seen where it is actually used. The goal at the SSCP level is solid working understanding, not mathematical depth.
The symmetric-versus-asymmetric distinction is the foundation, and you must hold it cleanly. Symmetric cryptography uses one shared secret key for both encryption and decryption — fast and ideal for bulk data (AES is the modern standard), but it raises the hard problem of distributing the key securely. Asymmetric cryptography uses a mathematically linked key pair — a public key anyone can hold and a private key kept secret — so someone can encrypt to your public key knowing only your private key can decrypt, and you can sign with your private key so anyone can verify with your public key. Asymmetric is slower, so in practice the two are combined: asymmetric cryptography securely exchanges a symmetric session key, which then encrypts the actual traffic. Recognizing that hybrid pattern is exactly what TLS does, and the exam expects you to know it.
Hashing and integrity are a separate pillar and a frequent source of confusion the exam probes. A cryptographic hash is a one-way function that turns any input into a fixed-length digest; it is not encryption because it cannot be reversed. Its value is integrity: the same input always yields the same hash, and any change — even a single character — produces a completely different digest (the avalanche effect), so comparing hashes detects tampering or corruption. SHA-256 is the current workhorse; older functions like MD5 and SHA-1 are broken for security use and should be recognized as such. Message authentication codes and password hashing (with salting) build on hashing to protect integrity and stored credentials. The lab makes the avalanche effect tangible by changing one character and watching the hash transform.
Public key infrastructure (PKI) and digital signatures are how asymmetric cryptography scales into real-world trust. A digital certificate binds a public key to an identity, and a certificate authority (CA) that both parties trust vouches for that binding by signing the certificate — which is how your browser trusts a website's public key without ever having met it. A digital signature combines hashing and asymmetric cryptography: you hash a message and encrypt the hash with your private key, so anyone can verify with your public key that the message is both unaltered (integrity) and genuinely from you (authenticity and non-repudiation). The exam expects you to understand certificates, CAs, the chain of trust, and what a signature actually proves, because PKI underpins TLS, code signing, and secure email.
Key management, secure protocols, and awareness of attacks close the domain and connect it to operations. Cryptography is only as strong as the protection of its keys, so key generation, storage, rotation, and destruction are examinable — a leaked private key voids every guarantee. TLS is the protocol that ties it all together for network communication, using asymmetric key exchange to establish a symmetric session and certificates to authenticate the server. Finally, a practitioner should be aware, at a recognition level, of crypto weaknesses and attacks — using deprecated algorithms, weak keys, poor randomness, or misconfigured protocols — without needing to execute them, because the SSCP is a defensive credential. The lab below lets you exercise all of these hands-on with free tooling on your own VM.
Study this domain by using cryptography with your own hands, because doing it once makes the abstractions concrete. The lab below uses the crypto-openssl-gpg fixture on your own Ubuntu/Debian VM: you symmetrically encrypt and decrypt a file with AES, watch a hash change completely after a one-character edit, generate an RSA key pair, use GPG to encrypt, decrypt, sign, and verify, and inspect a real public TLS certificate read-only (a normal browser-like fetch). As always, read the official SSCP exam outline for ISC2's authoritative topic list; this explanation paraphrases its scope in our own words rather than reproducing it.
Learn it free
Official · Official exam outline
ISC2 SSCP Certification Exam OutlineThe authoritative topic list for this domain's cryptography coverage — read it directly rather than relying on any summary, including ours. (captured 2026-07-10)
Official · Official ISC2 course content (free audit)
ISC2 SSCP training program on Coursera (free audit)ISC2's own SSCP course content, auditable for free, with a dedicated treatment of the cryptography material (the certificate and graded work are paid, and audit access to individual courses varies - verify what is free before relying on it). (captured 2026-07-10)
Sscp Cryptography Lab
Encrypt and decrypt with symmetric AES and generate an asymmetric RSA key pair Demonstrate hashing integrity, sign and verify with GPG, and inspect a real TLS certificate
Free tools
VirtualBox on your own hardware
Ubuntu/Debian VM you own
Linux terminal with openssl and gpg
Steps
Snapshot your own VM, then symmetrically encrypt a small file with AES-256-CBC and decrypt it, confirming the decrypted output matches the original.
Record the file's sha256 digest, change one character and re-hash to observe the avalanche effect, then generate an RSA private key and derive its public key.
Generate a throwaway GPG test key, encrypt and decrypt a file, then sign and verify it to produce a 'Good signature'.
Inspect a real public TLS certificate read-only (subject, issuer, validity dates) exactly as a browser would, then run the teardown and revert your VM to its snapshot.
What you should see
Confirm the captures show a matching AES decrypt, a sha256 digest that changes after a one-character edit, a generated RSA key pair, a verified GPG signature, and a read-only inspection of a public TLS certificate's subject, issuer, and dates.
Practice evidence maps to exam_domain_isc2_sscp_systems_security_certified_practitioner_05
Stay safe & legal: All cryptographic operations run locally on the Ubuntu/Debian VM you own, and the single network call is a read-only fetch of a public site's TLS certificate exactly as a browser performs; never point the certificate inspection at a private, internal, or third-party host you do not own, and never use these tools to attack any system. This is a defensive, hands-on crypto exercise only. Account required: no; payment required: no; maximum designed cost: $0.
Check yourself
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 7 · domain 3 · 15% of the exam
Risk Identification, Monitoring and Analysis
Study this fifth, after networking and cryptography have given you context. At 15% it is a middle-weight domain, and it pairs with incident response as the operational core: you monitor and assess risk, then respond when monitoring surfaces a real incident.
What this domain actually covers
Plain-language explanation in our own words — paraphrased from, and checked against, the official objectives. ISC2 SSCP Certification Exam Outline
This is the 'find the risk, watch for it, and make sense of what you see' domain, and ISC2 weights it at 15% of the exam. Risk Identification, Monitoring and Analysis is where the risk vocabulary introduced in Domain 1 becomes a working operational discipline, and it forms the first half of the operational pair with Incident Response and Recovery. A security practitioner spends much of their time here: identifying what could go wrong, quantifying how bad and how likely it is, watching the environment for signs of trouble, and turning a flood of log data into meaningful signal. We study it after the conceptual, access-control, network, and crypto foundations are in place, because monitoring makes far more sense once you understand what normal traffic, identities, and secure protocols look like.
Risk management is the domain's backbone, and the exam expects the full lifecycle. You identify risks (the assets, the threats, the vulnerabilities that connect them), assess them (estimating likelihood and impact to derive a risk level), and treat them — choosing to mitigate with controls, transfer with insurance or contracts, avoid by not doing the risky thing, or formally accept the residual risk. A risk register is the practical artifact that captures all of this: each risk with its description, likelihood, impact, current control, residual risk, and owner. The exam rewards the judgment to prioritize — you cannot fix everything, so you address the highest likelihood-times-impact risks first, and you document the acceptances so they are conscious decisions rather than oversights.
Security assessment and testing feed the risk picture with evidence. Vulnerability assessment scans systems for known weaknesses and missing patches; security control testing verifies that the controls you rely on actually work; and periodic review confirms that configurations have not drifted. The practitioner's role is not usually to run offensive tests but to interpret assessment output, validate which findings are real, and fold them into the risk register with an honest severity. The recurring theme, shared with the whole certification, is that a scanner or a report is a starting point, not a verdict — human analysis turns raw findings into a defensible, prioritized understanding of risk.
Monitoring and log analysis are the domain's most hands-on skills and the ones the lab targets. Systems, applications, and network devices generate logs continuously, and a practitioner configures what to capture, aggregates it, and analyzes it for signs of compromise or misuse. Security information and event management (SIEM) concepts describe how logs from many sources are centralized and correlated so a pattern invisible in any single log becomes visible across them. Continuous monitoring is the stance that this happens all the time, not once a quarter — the environment is watched constantly so deviations surface quickly. On a single VM, the Linux audit framework (auditd) is a concrete, free way to practice exactly this: define what to watch, generate events, and analyze the results.
A distinction the exam probes is event versus incident, and it maps directly to the next domain. An event is any observable occurrence — a login, a file access, a failed authentication — and the vast majority of events are entirely normal. An incident is an event, or a correlated set of events, that indicates a security policy has been or is about to be violated. The analyst's job in this domain is precisely to draw that line: to tune monitoring so it surfaces the events that matter, to recognize when a cluster of events crosses into incident territory, and to hand a well-evidenced incident to the response process. Getting this distinction right is what keeps a team from drowning in noise or missing a real breach.
Study this domain by configuring monitoring and analyzing real events on your own VM, because that is the practitioner skill the exam models. The lab below uses the auditd monitoring fixture: on your own Ubuntu/Debian VM you install auditd, set a watch on a sensitive file, trigger read and attribute-change events, analyze them with ausearch and aureport, review failed authentications, and build a small risk register from what you find. As always, read the official SSCP exam outline for ISC2's authoritative topic list; this explanation paraphrases its scope in our own words rather than reproducing it.
Learn it free
Official · Official exam outline
ISC2 SSCP Certification Exam OutlineThe authoritative topic list for this domain's risk, monitoring, and analysis coverage — read it directly rather than relying on any summary, including ours. (captured 2026-07-10)
Official · Official ISC2 course content (free audit)
ISC2 SSCP training program on Coursera (free audit)ISC2's own SSCP course content, auditable for free, with strong coverage of the risk and monitoring material (the certificate and graded work are paid, and audit access to individual courses varies - verify what is free before relying on it). (captured 2026-07-10)
Sscp Monitoring Lab
Configure an audit watch and analyze the resulting events with ausearch and aureport Build a small risk register with likelihood, impact, and residual risk from what you observe
Free tools
VirtualBox on your own hardware
Ubuntu/Debian VM you own
Linux terminal with auditd installed
Steps
Snapshot your own VM, then install and enable auditd and confirm the service is running.
Set a keyed audit watch on a sensitive file for write, attribute, and read access, then trigger read and attribute-change events on your own VM.
Analyze the captured events with ausearch and aureport, and review failed authentications and error-level messages, distinguishing normal events from ones that might indicate an incident.
Build a small risk register from what you observed, recording likelihood, impact, risk level, current control, residual risk, and owner for each entry, then remove the audit watch and revert your VM to its snapshot.
What you should see
Confirm the captures show a keyed audit watch, analyzed read and attribute events, a failed-authentication review, and a risk register recording likelihood, impact, and residual risk for each entry.
Practice evidence maps to exam_domain_isc2_sscp_systems_security_certified_practitioner_03
Stay safe & legal: All auditing and log analysis in this lab is of the Ubuntu/Debian VM you own and its own files only; never configure auditing on, or analyze logs from, a shared, corporate, employer, school, or third-party system, and never scan any network. This is defensive monitoring on your own VM only. Account required: no; payment required: no; maximum designed cost: $0.
Check yourself
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 6 of 7 · domain 4 · 14% of the exam
Incident Response and Recovery
Study this sixth, right after risk and monitoring. At 14% it is the lightest of the operational domains, and it is the natural partner to monitoring: when analysis surfaces a real incident, this domain is the disciplined detect-contain-recover cycle that follows.
What this domain actually covers
Plain-language explanation in our own words — paraphrased from, and checked against, the official objectives. ISC2 SSCP Certification Exam Outline
This is the 'something has gone wrong — now handle it calmly and correctly' domain, and ISC2 weights it at 14% of the exam. Incident Response and Recovery is the operational partner to Risk Identification, Monitoring and Analysis: monitoring surfaces the incident, and this domain is the disciplined, repeatable process for responding to it and restoring normal operations afterward. We study it right after monitoring because the two are a continuous loop in practice — you cannot respond to what you do not detect, and every incident feeds lessons back into your monitoring and risk posture. The exam is practitioner-oriented here in particular, favoring questions about what you would actually do at each phase over abstract definitions.
The incident response lifecycle is the domain's spine, and you should be able to walk it fluently. A common formulation runs preparation, detection and analysis, containment, eradication, recovery, and post-incident lessons learned. Preparation is the work done before anything happens — tools, runbooks, contacts, and evidence checklists ready to go. Detection and analysis is recognizing that an incident is underway and understanding its scope. Containment stops the bleeding — isolating an affected account or host so the damage does not spread. Eradication removes the root cause. Recovery restores systems to normal, verified operation. And lessons learned closes the loop by improving defenses. The exam rewards knowing not just the phases but the order and the goal of each.
Incident response runbooks are how a team turns that lifecycle into consistent action under pressure. A runbook is a pre-written, scenario-specific procedure — for a brute-force attempt, a malware detection, a lost device — that tells the responder exactly what to check, what to capture, and what to do at each phase, so decisions made calmly in advance replace panicked improvisation during an incident. Writing and rehearsing runbooks is a core practitioner skill, and it is precisely what the lab below has you do: author a runbook and then execute it against a controlled, self-owned test scenario. A rehearsed runbook is the difference between a contained incident and a chaotic one.
Evidence handling and forensic basics are woven through the response, because how you handle an incident can matter as much legally as technically. The practitioner-level expectation is not deep forensic expertise but sound fundamentals: preserve evidence before you alter the system, maintain a chain of custody so it is clear who handled what and when, capture logs and artifacts in a defensible way, and avoid contaminating evidence you might later need. Even a simple act — copying relevant log lines to a preserved file before you lock an account — reflects this discipline. The exam probes whether you would preserve first and act second when both are possible.
Business continuity and disaster recovery extend the domain from a single incident to keeping the organization running through disruption. Business continuity planning (BCP) is how the business keeps operating during and after a disruptive event; disaster recovery planning (DRP) is the IT-focused subset that restores systems and data. Two metrics are examinable and often confused: the recovery time objective (RTO) is how quickly a system must be back online, and the recovery point objective (RPO) is how much data loss, measured in time, is tolerable — which drives how often you back up. Backup and restore practice is the concrete foundation of all of it: a backup you have never tested restoring is a hope, not a control. A practitioner understands that recovery is planned, measured, and rehearsed, not improvised.
Study this domain by writing a runbook and rehearsing the full detect-contain-recover cycle against a controlled, self-owned scenario, because rehearsal is the examinable practitioner skill. The lab below uses the incident-response-runbook fixture on your own Ubuntu/Debian VM: you simulate failed logins against a LOCAL test account you create, author a runbook across the lifecycle phases, then detect the failures in logs, contain by locking the account while preserving evidence, recover by unlocking it, and record lessons learned. As always, read the official SSCP exam outline for ISC2's authoritative topic list; this explanation paraphrases its scope in our own words rather than reproducing it.
Learn it free
Official · Official exam outline
ISC2 SSCP Certification Exam OutlineThe authoritative topic list for this domain's incident-response and recovery coverage — read it directly rather than relying on any summary, including ours. (captured 2026-07-10)
Vetted independent · Free community study group
CertMike free SSCP study group (Mike Chapple)A free, community-run SSCP study group and resource set from a well-known security author, useful for reinforcing the incident-response and broader domains (community-produced - verify it is free and current before relying on it). (captured 2026-07-10)
Sscp Incident Response Lab
Author an incident-response runbook spanning preparation through lessons learned Rehearse detect-contain-recover on a local test account while preserving evidence first
Free tools
VirtualBox on your own hardware
Ubuntu/Debian VM you own
Linux terminal and a text editor
Steps
Snapshot your own VM, create a local test account, and fill in the runbook's preparation phase (tools, escalation contact, evidence checklist).
Deliberately fail several logins against the local test account to generate events, then detect them with lastb and by searching the journal for failures, and record the detection threshold in the runbook.
Preserve the relevant journal lines to an evidence file FIRST, then lock the account and confirm the lock; preserve, then act.
Note the root cause, unlock the account to recover, write the five-line lessons-learned entry, then run the teardown and revert your VM to its snapshot.
What you should see
Confirm the runbook covers all lifecycle phases, failed logins were detected in the logs, evidence was captured before the account was locked, the account was locked and then unlocked, and a lessons-learned entry was written.
Practice evidence maps to exam_domain_isc2_sscp_systems_security_certified_practitioner_04
Stay safe & legal: The brute-force simulation targets only a local test account you create on the Ubuntu/Debian VM you own; never simulate an attack against, lock, or read logs from a remote, real, third-party, employer, or school system. This is a defensive, self-contained rehearsal on your own VM only. Account required: no; payment required: no; maximum designed cost: $0.
Check yourself
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 7 of 7 · domain 7 · 15% of the exam
Systems and Application Security
Study this last. At 15% it is a middle-weight domain, but it is the broadest and most technical, and hardening, malware defense, endpoint, and cloud security all lean on everything before it - so it naturally closes the sequence as the domain that synthesizes the rest.
What this domain actually covers
Plain-language explanation in our own words — paraphrased from, and checked against, the official objectives. ISC2 SSCP Certification Exam Outline
This is the 'harden the systems, defend the endpoints, and secure the software and data' domain, and ISC2 weights it at 15% of the exam. Systems and Application Security is the broadest and most technical domain in the outline, pulling together threads from every domain before it — access controls harden the endpoint, cryptography protects the data, monitoring watches the host, and incident response cleans up when defenses fail. We deliberately study it last because it synthesizes the rest: hardening a system well requires understanding what you are protecting it against and with, and that understanding comes from the six domains that precede it. It is also the domain closest to the daily work of many security practitioners, which makes the hands-on habits it teaches especially durable.
Malicious software and endpoint defense are the domain's front line. A practitioner should recognize the families of malware — viruses, worms, trojans, ransomware, rootkits, spyware, and the fileless and living-off-the-land techniques that evade signature detection — and understand the layered defenses against them: anti-malware and endpoint detection and response (EDR) tooling, application allowlisting, and user awareness. Endpoint security is about making each device a defensible position: knowing what runs on it, limiting what can run, keeping it patched, and detecting when something abnormal happens. The exam expects recognition of the threats and the defensive controls, framed as a defender who reduces the attack surface and detects compromise, never as an attacker.
System hardening and secure configuration are the domain's core practical skill and the focus of the lab. Hardening is the systematic reduction of a system's attack surface: disabling unneeded services and accounts, closing unused ports, applying secure configuration baselines, and — the single highest-value action — patch management to close known vulnerabilities before they are exploited. Secure baselines (from sources like CIS Benchmarks) turn hardening from guesswork into a checklist. The recurring practitioner discipline is inventory, then reduce, then patch, then verify: you cannot secure what you do not know is running, so hardening begins with knowing your system, which is exactly the workflow the lab walks through on your own VM.
Virtualization, cloud, mobile, and IoT extend systems security to the environments where modern computing actually lives. Virtualization and cloud introduce shared-responsibility considerations — the provider secures the infrastructure while you secure your configuration, identities, and data — plus concerns like isolation between tenants and secure management of cloud resources. Mobile and IoT devices expand the attack surface with often-weaker default security, so mobile device management, segmentation, and disabling unnecessary features matter. A practitioner recognizes that each platform has its own security model and its own common weaknesses, and that the principles from earlier domains — least privilege, patching, monitoring, encryption — apply across all of them even as the specifics change.
Secure software concepts and data security close the domain. At the SSCP level you are expected to recognize secure software development ideas — input validation, secure defaults, and the value of catching flaws early — and common application weaknesses, without being a developer. Data security ties back to the CIA triad from Domain 1: classifying data by sensitivity, protecting it with encryption at rest and in transit, controlling access to it, and handling its full lifecycle including secure disposal. The through-line of the entire domain, and arguably the entire certification, is defense in depth: no single control is sufficient, so you layer hardening, endpoint defense, secure configuration, encryption, and monitoring so that when one control fails, others still stand. The lab below builds exactly this mindset by hardening a VM you own.
Study this domain by hardening a system with your own hands, because the inventory-reduce-patch-verify habit is the durable skill it teaches. The lab below uses the Linux hardening fixture on your own Ubuntu/Debian VM: you inventory running services and open ports, disable services you do not need, apply patches, hunt for world-writable files in /etc, establish a file-integrity baseline, and review the SSH configuration against best practice — all on your own VM, snapshot first so you can restore anything you disable. As always, read the official SSCP exam outline for ISC2's authoritative topic list; this explanation paraphrases its scope in our own words rather than reproducing it.
Learn it free
Official · Official exam outline
ISC2 SSCP Certification Exam OutlineThe authoritative topic list for this domain's systems and application security coverage — read it directly rather than relying on any summary, including ours. (captured 2026-07-10)
Official · Official ISC2 course content (free audit)
ISC2 SSCP training program on Coursera (free audit)ISC2's own SSCP course content, auditable for free, covering the broad systems and application security material (the certificate and graded work are paid, and audit access to individual courses varies - verify what is free before relying on it). (captured 2026-07-10)
Sscp Systems Security Lab
Inventory running services and open ports and reduce a VM's attack surface Patch, check for world-writable files, baseline file integrity, and review SSH configuration
Free tools
VirtualBox on your own hardware
Ubuntu/Debian VM you own
Linux terminal with systemctl, ss, and apt
Steps
Snapshot your own VM (essential, so you can restore anything you disable), then inventory the attack surface by listing running services and open ports.
Disable a service the VM does not need and re-check open ports to compare, then patch the system to close known vulnerabilities.
Hunt for world-writable files in /etc and establish a file-integrity baseline by recording sha256 sums of key files.
Review the SSH configuration against best practice, note what you would change, then run the teardown and revert your VM to its snapshot if you want to undo the changes.
What you should see
Confirm the evidence shows a before/after service and port inventory with a reduced attack surface, a completed patch run, a world-writable /etc check, a recorded file-integrity baseline, and an SSH-configuration review against best practice.
Practice evidence maps to exam_domain_isc2_sscp_systems_security_certified_practitioner_07
Stay safe & legal: All hardening actions are performed on the Ubuntu/Debian VM you own and its own filesystem and configuration; never disable services, patch, or change configuration on a shared, corporate, employer, school, or third-party system, and never harden a machine you do not own. This is defensive system hardening on your own VM only. Account required: no; payment required: no; maximum designed cost: $0.
Check yourself
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.
Skills you’ll build
Studying ISC2 SSCP (Systems Security Certified Practitioner)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.
Exam registration fee: Approximately $599 USD (Americas). Verify the current price on the official ISC2 pricing page - widely-repeated $249 figures are outdated. Official ISC2 SSCP exam outline
Experience requirement: One year of cumulative paid work experience in at least one of the seven domains (a relevant degree can substitute for up to one year). Candidates who pass without the experience become an Associate of ISC2 and have two years to earn it. Official ISC2 SSCP exam outline
Version currency: Domain 1 was renamed to 'Security Concepts and Practices' effective 2024-09-15 (weights unchanged). Verify the current outline on the official page before studying. Official ISC2 SSCP exam outline
Ongoing requirements: Three-year cycle, 60 CPE credits, and an annual maintenance fee (about $135/year). Official ISC2 SSCP exam outline
A free, source-cited study companion built on ISC2's published SSCP certification exam outline — not official training, not a pass guarantee. SSCP is a defensive security-practitioner credential that assumes about a year of hands-on experience, and every lab here runs only on your own local VM to build defensive and identification skills — never against a real, third-party, or employer system. Verify the current outline 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.