Vulnerability management is the operating discipline of detecting weaknesses, prioritizing them by risk, assigning accountable remediation, validating closure, and reporting residual exposure. In CloudSignals+RiskOps, vulnerability management is not limited to severity scores — it includes asset criticality, exposure, finding age, business impact, treatment status, control implications, evidence, and accountable RiskOps workflows.
Topic course: ~90 min • Certification path: 5–7 hrs 6 modules + capstone Foundational to Intermediate Certification eligible
Who this course is for
Security analysts and vulnerability managers
Cloud security engineers
RiskOps operators
SOC analysts
IT operations leads
MSP security teams
Prerequisites
Basic understanding of vulnerabilities and security findings
Access to Findings, Overview, and RiskOps workspaces
Recommended: Getting Started with RiskOps (foundation course)
What you will be able to do
Explain vulnerability management as a risk-based lifecycle — detect, validate, prioritize, assign, remediate, verify, report.
Interpret CloudSignals findings, failed checks, threat score, and aging views.
Prioritize vulnerabilities using severity, exposure, asset criticality, business impact, and age.
Route remediation through RiskOps projects and SLA policies with evidence requirements.
Document accepted risk and treatment decisions with defensible rationale.
Use Vision to draft remediation guidance and executive vulnerability narratives — with required human review.
Platform areas used in this course: Overview, Findings, Threat Map, RiskOps, Risk Register, Risk Treatments, Projects, Vulnerability Aging, SLA Policies, Reports, Vision. Navigate to Overview in the main navigation to begin.
AI advisory statement: Vision can draft remediation guidance and executive summaries — but all Vision output must be reviewed for accuracy, have evidence references added, and carry the reviewer's attestation before distribution. Vision does not independently verify remediation status.
1
Vulnerability Lifecycle
15 min • Overview • Explain the seven-stage detect-to-verify workflow
The seven stages — and the one most programs skip
CloudSignals+RiskOps supports the full vulnerability lifecycle by combining findings, asset context, risk treatment, project execution, evidence, and reporting. The seven stages are: Detect (scanner evaluates resources against policy controls), Validate (confirm the finding is genuine and not a false positive), Prioritize (rank by risk priority using asset context — not severity alone), Assign (link an owner with accountability), Remediate (implement the fix), Verify (confirm via scan that the fix worked), Report (communicate posture, velocity, and residual risk to stakeholders).
The stage most programs skip or shortcut is Verify. A fix that hasn't been confirmed by a subsequent scan is not a closed vulnerability — it is a treatment in progress. Reporting "remediated" without verification means your posture data reflects intent, not confirmed reality. CloudSignals+RiskOps only closes a finding when a scan run after the fix date returns a passing result for that control on that asset.
In the platform — Orient to the vulnerability lifecycle view
1
Navigate to Overview. Review the top-level metrics: threat score, open findings by severity, findings discovered vs. closed this week. This is your vulnerability lifecycle health dashboard.
2
Note the gap between "findings discovered" and "findings closed." If discovery consistently outpaces closure, your remediation velocity is insufficient — the backlog will grow regardless of how many fixes are implemented.
3
Navigate to Findings. Review the status distribution: Open, In Progress, Remediated (pending verification), Closed, Accepted. Findings in "Remediated (pending verification)" represent fixes that need scan confirmation — these are not closed.
Audit your verification gap: Count findings marked "Remediated" or "In Progress" that haven't had a confirming scan. For each, trigger a manual scan on the affected asset to confirm or reopen.
Review discovery vs. closure velocity: If you're discovering more findings per week than closing, your VM program needs either capacity increase, prioritization discipline, or scope reduction — document which applies.
Define "closed" for your team: Write a one-sentence definition: a finding is closed only when a post-fix scan confirms the control passes on the specific asset. Share this with your team to align expectations.
Knowledge Check
Why is severity alone insufficient for vulnerability prioritization?
Severity scores are calculated automatically and may contain scanner errors that need manual correction before use.
Severity measures technical impact in isolation — it ignores asset criticality, business process exposure, exploitability in the specific environment, data sensitivity, and finding age. A medium finding on a crown-jewel PII system may require faster response than a critical finding on an isolated dev VM.
Severity is only insufficient for legacy systems where CVSS scoring was not designed to apply.
Severity alone is sufficient when combined with SLA policy enforcement — SLAs compensate for the missing business context.
Move on when you've reviewed the lifecycle dashboard and audited your verification gap.
2
Findings Intelligence
25 min • Findings • Analyze failed checks and extract risk signals
Findings are signals — not final risk decisions
Findings represent observed security issues from scans and integrations. A finding in CloudSignals+RiskOps is the result of a failed policy check on a specific resource — but it is a signal, not the complete risk picture. Human review and business context determine how urgent the signal actually is. The same finding on two different assets can represent very different organizational risk.
When evaluating any finding, apply this eight-factor inspection checklist:
Factor
What to determine
Severity
Technical baseline — Critical, High, Medium, Low
Provider, account, region
Which cloud environment? Production, staging, or dev?
Resource identity
What specific resource failed the check?
Check title and rationale
What control failed? Why does this control exist?
Status
Open, In Progress, Accepted, or Muted/Suppressed?
Age
How long has this been open? Is it approaching or past SLA?
Muting or exception state
Is this a known exception? Is the exception still valid?
Related asset and business context
What does this asset support? Who owns it? What data does it handle?
In the platform — Lab 1: Finding Triage
1
Navigate to Findings. Filter to Critical and High severity, status = Open. Select three findings on different assets — ideally across different providers or account environments.
2
For each of the three findings, apply the eight-factor inspection. Open the finding detail and the linked asset detail. Note: asset criticality, data sensitivity, managed entity, and environment tag.
3
Compare severity against asset context across the three findings. Rank them by actual risk priority — the ranking may differ significantly from severity-only ordering.
4
Check any muted or suppressed findings in the queue. Confirm the muting rationale is still valid — muted findings with expired justifications are open vulnerabilities masquerading as managed risk.
5
Record your triage table: finding ID, severity, asset context summary, and risk priority rank. This is your Lab 1 deliverable.
Complete a findings triage for your top Critical/High findings: Apply all eight factors. Produce a priority-ranked list that reflects business context, not severity alone.
Audit muted/suppressed findings: For every suppressed finding, confirm the justification is current and the exception has not expired silently.
Confirm asset linkage for top-10 findings: Every Critical finding should be linked to an owned, classified asset. Unlinked findings cannot be accurately prioritized.
Knowledge Check
What is the difference between vulnerability remediation and vulnerability risk acceptance?
Remediation is done by engineers; risk acceptance is done by executives. The difference is only organizational role, not governance process.
Remediation eliminates the root cause — the vulnerability is fixed and verified by a confirming scan. Risk acceptance formally acknowledges that the residual risk is within policy bounds, with a named approver, justification, and expiry — the vulnerability remains present but is governed. Acceptance is not the same as ignoring a finding.
Remediation and risk acceptance are equivalent — both result in a finding being marked closed in the platform.
Risk acceptance is temporary; remediation is permanent. Once an acceptance expires, the finding automatically becomes Critical regardless of its original severity.
Move on when you've completed the finding triage lab and audited muted findings.
3
Risk-Based Prioritization
25 min • Threat Map, RiskOps • Prioritize beyond severity using ten contextual factors
The ten prioritization factors
Risk-based prioritization moves from "this is a Critical finding" to "this is the finding that poses the most organizational risk right now given our environment." The ten factors that determine actual risk priority in CloudSignals+RiskOps are:
Exploitability — is active exploit code in use in the wild (CISA KEV, threat intel)?
Exposure — is the asset internet-facing, or accessible only from internal networks?
Asset criticality — what is this asset's business criticality designation?
Data sensitivity — what type of data does this asset handle (PII, PHI, financial)?
Business process impact — which revenue-generating or regulated process depends on this asset?
Identity or privilege impact — does this finding grant or escalate privilege if exploited?
Internet exposure — is the vulnerable service directly reachable from the public internet?
Finding age — how long has this been open? Aging increases risk — attackers scan continuously.
Regulatory relevance — is this finding directly tied to a compliance obligation?
Current remediation capacity — does the team have the bandwidth to address this now?
In the platform — Use Threat Map and RiskOps for prioritization
1
Navigate to RiskOps > Risk Register. Review the risk register for your top finding clusters. Confirm that findings with high business process impact appear in the register with linked risk entries.
2
Navigate to Overview > Threat Map. Review the geographic and provider threat distribution. Identify finding clusters with active threat actor association — these require same-day triage regardless of severity rating.
3
Return to Findings. Apply the ten prioritization factors to the findings from your Lab 1 triage. Revise your priority ranking based on factors beyond severity — especially age, exposure, and exploitability context.
4
Identify the one finding that is most dangerous to your organization right now — not necessarily the highest CVSS score. Document your prioritization rationale using the ten factors. This becomes the first item in your Module 4 treatment planning.
Re-rank your top findings using all ten factors: Compare your new ranking to the severity-only ranking from Module 2. Document the findings whose priority changed significantly — these are where severity-only ranking would have misdirected resources.
Check Threat Map for active exploitation context: Any finding associated with actively exploited vulnerabilities needs same-day triage escalation regardless of current severity assignment.
Document your top-priority finding: Write a prioritization rationale paragraph explaining why this specific finding warrants the most urgent treatment — using the ten-factor framework, not just "it's Critical."
Knowledge Check
Why does finding age matter as a prioritization factor in vulnerability management?
Older findings automatically get downgraded in severity because the absence of a breach after a long period proves the risk is lower than initially assessed.
Aging increases risk — attackers scan continuously and finding exposure windows compound over time. A High finding open for 60 days has provided attackers 60 days of opportunity, making it more urgent than a freshly discovered Critical finding in some scenarios. Age also indicates a process failure that needs diagnosing.
Finding age only matters for compliance reporting — it determines whether a finding counts toward the current or previous audit period.
Older findings are less urgent because they represent known, stable risk rather than new, unknown exposure that requires immediate investigation.
Move on when you've re-ranked your findings using all ten factors and documented your top-priority finding rationale.
4
Treatment & Remediation
25 min • Projects, Risk Treatments • Route accountable remediation work
Five treatment options — and when to use each
RiskOps treatment options are not a binary fix-or-ignore decision. Five treatment types exist, each appropriate for different circumstances:
Treatment type
When to use
What to document
Mitigate
Fix the root cause — preferred path for Critical and High findings where a remediation path exists.
In the platform — Lab 2: Risk Treatment Decision + Lab 3 setup
1
Take the top-priority finding from Module 3. Navigate to RiskOps > Risk Treatments. Select the appropriate treatment type using the five-option framework. Document your rationale — which treatment type and why.
2
Create a treatment record. Fill in all required fields — for Mitigate: owner, fix description, target date, verification method, evidence requirement. For Accept: approver, justification, expiry date, conditions. Never leave required fields blank.
3
Navigate to RiskOps > Projects. Create a remediation project linked to the treatment. Add work items with named owners and due dates. Include a verification work item as the final milestone — without it, the project can be marked complete without scan confirmation.
4
Identify the evidence required to verify remediation. Set this in the project's evidence requirement field before work begins — not after completion. For a misconfiguration fix: post-fix scan result + configuration export. For a patch: patch verification scan + system log confirming version.
Create treatment records for all top-priority findings: Every Critical finding from your Module 3 ranking should have a treatment record with all required fields — no blank owner, no open-ended expiry for acceptances.
Define evidence requirements upfront: For every new treatment, specify what proof is required before the finding closes — and enter this before assigning the work, not after asking "how do we verify this?"
Audit existing Accept treatments: Review all accepted risks. Confirm each has a named approver, a specific justification, and a valid expiry date. Open-ended acceptances are not governed risk — they are ignored risk.
Knowledge Check
What evidence is needed to verify that a vulnerability has been successfully remediated and can be closed?
An engineer's attestation in the treatment record confirming the fix was implemented on the target date.
A scan result from a scan run after the fix date confirming the control now passes on the specific affected asset — combined with a configuration export or patch confirmation log showing what specifically changed. Engineer attestation alone is insufficient.
Approval of the treatment record by the governance committee confirms the remediation is complete — scan verification is optional for Low and Medium findings.
The finding closes automatically when the next scheduled scan runs, regardless of whether the fix was implemented correctly.
Move on when treatment records are created for your top-priority findings with evidence requirements defined upfront.
5
Aging & SLA Governance
20 min • Vulnerability Aging, SLA Policies • Manage backlog pressure and deadline enforcement
Aging findings are a leading indicator of process failure
Vulnerability aging is not just a metric — it is a diagnostic signal. When high-severity findings age beyond their SLA window without treatment, it indicates one of three process failures: capacity (the team doesn't have enough people to handle the finding volume), prioritization (the right findings aren't being addressed first), or process (the triage-to-treatment workflow is broken or not followed). Identifying which failure is present tells you what to fix — adding headcount to a prioritization problem will not solve it.
CloudSignals+RiskOps Vulnerability Aging views show which findings have been open beyond their expected SLA window, grouped by severity tier, asset, and team. SLA Policies define the expected resolution timelines and can trigger automatic escalation or playbook activation when a finding ages past the SLA threshold without a treatment decision.
In the platform — Review Vulnerability Aging and SLA Policies
1
Navigate to Findings > Aging (or the Vulnerability Aging view). Review findings grouped by severity tier and age band. Which severity tier has the most SLA breaches?
2
For the severity tier with the most aging findings, diagnose the root cause: capacity, prioritization, or process? Review whether those findings have treatment records (prioritization), whether treatment records are progressing (capacity), or whether findings are being triaged at all (process).
3
Navigate to RiskOps > SLA Policies. Review the policies active for your tenant. What are the SLA windows for Critical, High, Medium, and Low findings? Do your team's current remediation patterns meet these SLAs?
4
Identify the three oldest High findings in your environment. For each: confirm a treatment record exists, confirm the owner has been contacted recently, and confirm the target date is realistic given current capacity. Flag any that need immediate escalation.
Identify your SLA breach pattern: Which severity tier has the most SLA breaches? Determine whether the root cause is capacity, prioritization, or process — and document your diagnosis.
Escalate the three oldest High findings: Contact owners, confirm realistic target dates, and escalate any that are stalled without an active treatment record or recent status update.
Confirm SLA policies match your obligations: Compare your SLA policy windows against any regulatory or contractual requirements your organization has for vulnerability remediation timelines.
Knowledge Check
How can Vision support vulnerability management — and what constraint always applies?
Vision can automatically close verified remediated findings, reducing the need for manual scan confirmation in time-sensitive situations.
Vision can draft remediation guidance, explain vulnerability context, and generate executive summary narratives — but all Vision output must be reviewed by a named human before distribution or use as evidence. Vision does not verify remediation status or independently confirm that fixes worked.
Vision generates legally binding remediation recommendations that engineering teams must implement unless they submit a formal exception.
Vision is only applicable to cloud misconfigurations — it cannot analyze or summarize CVE-based software vulnerabilities.
Move on when you've diagnosed your aging pattern, escalated stalled findings, and confirmed SLA policy alignment.
6
Reporting & Vision
15 min • Reports, Vision • Summarize vulnerability posture for different audiences
Different audiences need different views
Executive vulnerability reporting should avoid raw technical detail overload. It should cover business exposure, open high-risk findings, aging trends, remediation velocity, accepted risk totals, and control implications — framed in language that non-technical stakeholders can interpret and act on. The most important metric in executive reporting is remediation velocity trend: are we getting faster or slower at closing verified vulnerabilities? A declining MTTR is evidence the program is working.
Engineering teams need: findings by team and asset, treatment status, aging findings approaching SLA breach, and verification backlog. Security managers need: MTTR trend by severity tier, pending decisions count, and risk acceptance rate. These are three different report products from the same platform data.
In the platform — Lab 3: Build a vulnerability action plan and executive summary
1
Navigate to Reports > Vulnerability Posture (or Reports > RiskOps Insights). Generate a report covering: findings by severity, MTTR trend, aging findings past SLA, and accepted risk total.
2
Review the MTTR trend for Critical and High findings. Is it improving, stable, or degrading? A degrading MTTR trend requires immediate diagnosis — it means the program is losing ground faster than it is gaining it.
3
Navigate to Vision > Ask Vision. Request an executive vulnerability summary: "Draft an executive summary of our current vulnerability posture including our top business risks, remediation velocity, and three recommended actions."
4
Review the Vision output. Verify all cited metrics against the Reports view. Correct any inaccuracies. Add context about accepted risks and regulatory implications specific to your organization. Add your reviewer attestation and AI disclaimer.
5
Assemble your vulnerability action plan (from Module 4 treatments and Module 5 escalations) and the executive summary into your Lab 3 deliverable package.
Review MTTR trend: Generate the MTTR report. If Critical MTTR exceeds 7 days or High exceeds 30 days, investigate the root cause — is it capacity, process, or approval bottleneck?
Draft and validate a Vision executive summary: Generate, verify against report data, correct inaccuracies, and attest before distributing.
Schedule monthly vulnerability reporting: Add a recurring calendar entry to generate and distribute the posture summary to your security leadership team. Quarterly reporting is insufficient for an active VM program.
Knowledge Check
Which metric is the strongest indicator of executive-level vulnerability management program health?
Total open finding count — a lower count always indicates the program is working effectively.
MTTR (Mean Time to Remediate) trend by severity tier — it measures whether vulnerabilities are being verified-closed within policy-defined timelines, reflecting actual program throughput and effectiveness rather than just activity or discovery volume.
Risk acceptance rate — a high acceptance rate demonstrates mature risk decision-making by the program leadership team.
Scan coverage percentage — 100% coverage ensures no vulnerabilities go undetected, making it the most important program health indicator.
Move on when you've reviewed MTTR trend and produced a validated executive vulnerability summary.
Completing all six modules makes you eligible for the practitioner certification exam.
Exam domain
Weight
Vulnerability lifecycle
15%
Findings analysis
25%
Risk-based prioritization
25%
Treatment and remediation
20%
Reporting and AI-assisted workflows
15%
Capstone practical scenario
A tenant has high-severity findings on test assets, medium-severity findings on critical identity systems, and several findings older than 60 days with no treatment records. Your task:
Prioritize the findings using the ten-factor framework — explain why the order differs from severity-only ranking.
Make treatment decisions for the top three findings with full rationale for each treatment type chosen.
Create a remediation project with milestoned work items, owners, and evidence requirements.
Diagnose the process failure causing 60-day aging on High findings and recommend a specific intervention.
Prepare an executive vulnerability summary using Vision, validate it, and attest it — including AI disclaimer.
Passing criteria: Uses risk context beyond severity — applies all ten factors. Correctly identifies aging as a process indicator, not just a metric. Provides accountable remediation steps with evidence requirements defined upfront. Distinguishes accepted risk (governed) from ignored risk (ungoverned). Produces clear executive language validated with human review and AI disclaimer.
🏅
Course complete!
You've completed Vulnerability Management. Your program now prioritizes by risk, remediates with evidence, and reports velocity — not just activity.
