Start your lesson
Study the required lesson for each block, then take its short check. Guided exercises are optional. Required case practice within the blocks counts toward the readiness checklist, not lesson completion.
Your notesPrivate to you
Block 1 of 6Vulnerability-management cycle · Assessment coverage denominator · Remediation service-level target · Vulnerability exception
Practice savedNext · 15 min
Vulnerability-management cycle · Assessment coverage denominator · Remediation service-level target · Vulnerability exception
Practice savedNo provider lesson is assigned to this block. Study the ITForMe lesson below, then take the required check.
Required ITForMe lesson
Concept notes
Vulnerability-management cycle
Repeats scope, discovery, assessment, prioritization, treatment, verification, and reporting rather than ending when a scanner produces findings.
Assessment coverage denominator
Counts the complete in-scope asset population so remediation percentages do not hide systems that were never successfully assessed.
Remediation service-level target
Sets an expected treatment time based on priority while preserving escalation and exception handling for operational constraints.
Vulnerability exception
Documents affected scope, reason, owner, compensating controls, approval, and expiry when treatment is deferred.
Required block check · Block 1
Required for course progress · Pass with 3 of 4 correct
Block 2 of 6Risk acceptance · Preventive control · Detective control · Corrective control
Practice saved15 min
Risk acceptance · Preventive control · Detective control · Corrective control
Practice savedNo provider lesson is assigned to this block. Study the ITForMe lesson below, then take the required check.
Required ITForMe lesson
Concept notes
Risk acceptance
Records an authorized owner's informed decision to retain defined residual risk for a bounded scope and duration.
Preventive control
Blocks or limits an unwanted action before it succeeds, reducing the likelihood of the protected event.
Detective control
Reveals an event or condition so responders can investigate and act, without necessarily preventing its occurrence.
Corrective control
Restores service or removes a cause after an adverse condition occurs, reducing duration or impact.
Required block check · Block 2
Required for course progress · Pass with 3 of 4 correct
Block 3 of 6Build a vulnerability-management control cycle
Practice saved8 min
Build a vulnerability-management control cycle
Practice savedNo provider lesson is assigned to this block. Study the ITForMe lesson below, then take the required check.
Required ITForMe lesson
Build a vulnerability-management control cycle
By the end, you can
- Analyze supplied evidence for vulnerability-program denominator.
- Analyze supplied evidence for time-bounded vulnerability exception.
Vulnerability management is a cycle: maintain scope and ownership, discover, assess, prioritize, treat, verify, and report. Asset inventory quality sets the denominator. A 98% remediation rate can conceal unknown or unscanned assets if the program counts only findings that entered the tool.
Service-level targets should reflect priority and operational constraints, with an exception process that records owner, reason, compensating controls, expiry, and approval. An exception is not deletion; the risk and due date remain visible for review.
Worked example
A dashboard reports 96% critical findings closed, but 140 cloud instances were created and 37 never entered the scan scope.
- Inventory: 1,000 active instances
- Scanner scope: 963 instances
- Critical findings: 120 total, 115 closed; the owner asks to defer the 5 open findings
The closure metric describes known findings but omits 3.7% of assets. Coverage must be repaired before calling the program 96% effective.
Enroll the 37 instances, scan them, and report asset coverage separately from finding remediation.
Reasoning self-check
A dashboard reports 96% critical findings closed, but 140 cloud instances were created and 37 never entered the scan scope.
- Inventory: 1,000 active instances
- Scanner scope: 963 instances
- Critical findings: 120 total, 115 closed; the owner asks to defer the 5 open findings
- Record a timestamped fact table from the supplied evidence.
- Test the two most plausible explanations against every observation.
- Choose a bounded defensive action and state the result that would confirm it worked.
Compare your reasoning
Expected answers
- Enroll the 37 instances, scan them, and report asset coverage separately from finding remediation.
- The conclusion cites at least two supplied observations and names one remaining uncertainty.
If you got stuck
- If the evidence conflicts, preserve both records and check clock, scope, and collection gaps before deciding.
- If no conclusion is supportable, request one specific log, capture, inventory fact, or controlled retest.
Compare your reasoning with the revealed answers if helpful. The block check below is required for course progress.
Required block check · Block 3
Required for course progress · Pass with 2 of 2 correct
Block 4 of 6Use controls and risk acceptance honestly
Practice saved18 min
Use controls and risk acceptance honestly
Practice savedNo provider lesson is assigned to this block. Study the ITForMe lesson below, then take the required check.
Required ITForMe lesson
Use controls and risk acceptance honestly
By the end, you can
- Analyze supplied evidence for control effect classification.
- Analyze supplied evidence for risk-acceptance authority.
Controls can reduce likelihood, impact, or both. Preventive controls block or limit activity; detective controls reveal it; corrective controls restore or remove the cause. A detective alert does not prevent exploitation, and a backup does not reduce initial compromise likelihood, though both can reduce consequences or response time.
Risk acceptance requires an authorized owner who understands residual risk and duration. Analysts provide evidence and options; they do not silently accept risk by lowering severity or closing a ticket. Reassess when exposure, threat activity, asset role, or compensating controls change.
Worked example
A legacy reporting server cannot be upgraded for 60 days. It is moved behind an allowlist, monitored, and backed up nightly.
- Allowlist: only two reporting clients can connect
- Alerts: process and network detections enabled
- Backup: nightly, restore tested; business owner approval expires in 60 days
The combined controls reduce exposure and recovery impact but do not remove the vulnerable software. Residual risk remains accepted only through the documented expiry.
Keep the finding open under the approved exception, verify each control, and upgrade before the 60-day expiry or seek a new decision.
Reasoning self-check
A legacy reporting server cannot be upgraded for 60 days. It is moved behind an allowlist, monitored, and backed up nightly.
- Allowlist: only two reporting clients can connect
- Alerts: process and network detections enabled
- Backup: nightly, restore tested; business owner approval expires in 60 days
- Record a timestamped fact table from the supplied evidence.
- Test the two most plausible explanations against every observation.
- Choose a bounded defensive action and state the result that would confirm it worked.
Compare your reasoning
Expected answers
- Keep the finding open under the approved exception, verify each control, and upgrade before the 60-day expiry or seek a new decision.
- The conclusion cites at least two supplied observations and names one remaining uncertainty.
If you got stuck
- If the evidence conflicts, preserve both records and check clock, scope, and collection gaps before deciding.
- If no conclusion is supportable, request one specific log, capture, inventory fact, or controlled retest.
Compare your reasoning with the revealed answers if helpful. The block check below is required for course progress.
Work through the scenario
Use the case evidence to complete the tasks, then check objectives.
Guided: Repair a scan-coverage denominator
A dashboard claims strong remediation while active cloud instances are missing from scope.
- Program analystactor
- Inventory and scanner metricscontrol
- Cloud estateresource
- analystinterpretsevidence
- evidencedescribesasset
Objectives
- Interpret the supplied evidence without overclaimingpending
- Choose the bounded evidence-supported actionpending
- Select evidence that verifies security and operational outcomepending
Evidence 1
Inventory: 1,000 active instances.
Evidence 2
Scanner: 963 distinct active instances assessed.
Evidence 3
Findings: 115 of 120 critical findings closed.
Fictional, disposable SOC evidence. No production system or external service is contacted.
Report an issue with this exercise
Required case practice
Required for the readiness checklist · Pass at 100%
Review an expiring exception
A legacy reporting server has a 60-day risk exception with multiple compensating controls.
- Risk analystactor
- Exception and control evidencecontrol
- Legacy serverresource
- analystinterpretsevidence
- evidencedescribesasset
Objectives
- Interpret the supplied evidence without overclaimingpending
- Choose the bounded evidence-supported actionpending
- Select evidence that verifies security and operational outcomepending
Evidence 1
Allowlist restricts access to two clients.
Evidence 2
Process and network monitoring is enabled; nightly restore was tested.
Evidence 3
Business-owner approval expires in five days; upgrade work is incomplete.
Fictional, disposable SOC evidence. No production system or external service is contacted.
Report an issue with this exercise
Required block check · Block 4
Required for course progress · Pass with 2 of 2 correct
Block 5 of 6Classify controls and risk decisions
Practice saved9 min
Classify controls and risk decisions
Practice savedNo provider lesson is assigned to this block. Study the ITForMe lesson below, then take the required check.
Required ITForMe lesson
Classify controls and risk decisions
By the end, you can
- Explain and apply control type and function.
- Explain and apply risk state and strategy.
- Explain and apply policy and slo.
A badge reader is physical in implementation and preventative in intended function; a policy is administrative; an IDS is technical and detective. One control can serve multiple functions, but claims need observed effect. Responsive controls limit ongoing harm and corrective controls restore or remove cause after an event.
Inherent risk is assessed before selected controls; residual risk remains after them; appetite guides how much risk the organization is willing to pursue or retain. Acceptance needs an authorized owner. Transfer shifts defined consequences but cannot transfer all operational impact. Avoidance ends the risky activity; mitigation reduces likelihood or impact. An SLO is a measurable target, not a risk strategy by itself.
Worked example
A supplier outage is insured, monitored by an IDS, and governed by a four-hour recovery SLO, but the service has no alternate path.
- Insurance covers part of financial loss
- IDS alerts but does not restore service
- Owner accepts two-hour outage; observed recovery is six hours
Some cost is transferred, detection exists, residual operational risk remains, and actual performance misses both appetite and SLO.
Escalate the residual availability risk to the authorized owner and choose mitigation or avoidance rather than calling insurance complete transfer.
Reasoning self-check
A policy, badge reader, IDS, isolation runbook, rebuild, and insurance all address a supplier outage scenario.
- Before controls: outage exceeds appetite
- Insurance transfers only defined financial loss
- After monitoring and recovery control: six-hour residual outage exceeds two-hour acceptance
- Build a short evidence table that separates observations, supported conclusions, and remaining unknowns.
- Choose the authorized action that tests the leading conclusion with the least operational impact.
- Compare your decision and reopen condition with the expected results before continuing.
Compare your reasoning
Expected answers
- Classify control implementation and function separately, distinguish inherent from residual risk, and record authorized accept/transfer/avoid/mitigate choices against appetite and SLO governance.
- Reopen the decision if control performance or outage duration changes, or if the accepting authority and exception expire.
If you got stuck
- If the answer depends on a product name alone, return to the actual evidence it produced.
- If no option can be falsified, name the missing record before choosing.
Compare your reasoning with the revealed answers if helpful. The block check below is required for course progress.
Required block check · Block 5
Required for course progress · Pass with 3 of 3 correct
Block 6 of 6Use application and supply-chain evidence
Practice saved7 min
Use application and supply-chain evidence
Practice savedNo provider lesson is assigned to this block. Study the ITForMe lesson below, then take the required check.
Required ITForMe lesson
Use application and supply-chain evidence
By the end, you can
- Explain and apply application-assurance evidence.
- Explain and apply third-party component risk.
SAST examines code without exercising the deployed application; DAST sends requests to a running target and sees exposed behavior; neither guarantees complete coverage. OWASP SAMM evaluates organizational software-assurance practices. Tool results need route, build, configuration, and validation before they become product risk decisions.
SCA identifies open-source or third-party components and known issues. An SBOM inventories components and dependency relationships; it does not prove a vulnerable function is reachable or a component is running. Reconcile supplier advisory, artifact digest, dependency scope, deployment, exposure, and compensating controls.
Worked example
SCA finds a vulnerable library in a build dependency, SAST finds no call, DAST cannot reach the feature, and the supplier SBOM lists it in the shipped image.
- Dependency scope: build-time only
- Runtime image inspection: library absent
- Supplier advisory: only runtime parser affected
The evidence supports documenting and monitoring the dependency but not a current exploitable runtime finding for this image.
Preserve the SBOM/SCA evidence, verify future builds exclude the component, and keep a regression check for the affected parser path.
Reasoning self-check
A supplier lists a vulnerable library, static analysis finds one reference, dynamic testing cannot reach it, and the runtime digest lacks it.
- SBOM: library declared as runtime dependency
- SCA/SAST: CVE match and source reference
- Artifact/DAST: component absent and route unreachable from tested role
- Build a short evidence table that separates observations, supported conclusions, and remaining unknowns.
- Choose the authorized action that tests the leading conclusion with the least operational impact.
- Compare your decision and reopen condition with the expected results before continuing.
Compare your reasoning
Expected answers
- Keep SBOM, SCA, SAST, DAST, runtime, and supplier evidence distinct; log the inventory discrepancy and avoid claiming execution or exploitability.
- Reopen exploitability if a shipped artifact contains the component or another authenticated role reaches the affected function.
If you got stuck
- If the answer depends on a product name alone, return to the actual evidence it produced.
- If no option can be falsified, name the missing record before choosing.
Compare your reasoning with the revealed answers if helpful. The block check below is required for course progress.
Required block check · Block 6
Required for course progress · Pass with 2 of 2 correct
Review this lesson
Use only this lesson's worked example and key concepts for a quick self-check.
- Restate the worked example in your own words.
- Name the lesson concepts that explain the result.
- Explain why the closest alternative does not fit.
Check the whole objective
This unlocks objective 2.4 for recall. The latest checkpoint needs 70% or higher; a lower result puts the lesson back near the front of your timeline.