CySA+ Runbook 07 — Vulnerability Triage and Remediation Prioritization

Runbook Information

Item	Details
Runbook	07
Runbook Name	Vulnerability Triage and Remediation Prioritization
Track	CompTIA CySA+
Difficulty	Intermediate–Advanced
Primary Role	Cybersecurity Analyst / Vulnerability Analyst / SOC Analyst
Purpose	Validate vulnerability findings and prioritize remediation according to technical and business risk
Primary Systems	Vulnerability Scanner, SIEM, EDR, CMDB, Asset Inventory, Threat Intelligence, Patch Management
Primary Data Sources	Scanner Results, CVE Records, CVSS, EPSS, Asset Data, Exposure Data, Threat Intelligence
Output	False Positive / Accepted Risk / Mitigation / Remediation / Emergency Remediation
Related Labs	Lab 14, Lab 15, Lab 16, Lab 20

Operational Principle: Vulnerability severity alone does not determine remediation priority. Effective vulnerability management combines technical severity, exploitation likelihood, active threat activity, asset importance, exposure, and existing security controls.

1. Purpose

This runbook provides a repeatable workflow for converting vulnerability scanner findings into actionable remediation priorities.

The analyst must determine:

What vulnerability was detected?
      ↓
Is the finding valid?
      ↓
Which CVE applies?
      ↓
How severe is it?
      ↓
How likely is exploitation?
      ↓
Is exploitation occurring?
      ↓
Is a public exploit available?
      ↓
Which asset is affected?
      ↓
Is the asset internet-facing?
      ↓
How important is the asset?
      ↓
What controls already exist?
      ↓
What is the real organizational risk?
      ↓
How quickly should it be remediated?
      ↓
Was remediation successful?

2. When to Use This Runbook

Use this runbook for:

• vulnerability scanner findings

• newly disclosed CVEs

• critical vulnerability notifications

• internet-facing vulnerabilities

• actively exploited vulnerabilities

• emergency patching decisions

• vulnerability backlog prioritization

• penetration-test findings

• configuration vulnerabilities

• software vulnerabilities

• operating-system vulnerabilities

• cloud workload vulnerabilities

• vulnerability exceptions

• remediation validation

• vulnerability SLA tracking

3. Vulnerability Lifecycle

Discovery
   ↓
Validation
   ↓
Enrichment
   ↓
Risk Assessment
   ↓
Prioritization
   ↓
Assignment
   ↓
Remediation
   ↓
Validation
   ↓
Closure

4. Vulnerability Prioritization Model

Do not use:

CVSS
  ↓
Priority

Use:

CVSS
  +
EPSS
  +
Exploit Availability
  +
Active Exploitation
  +
Asset Criticality
  +
Exposure
  +
Business Impact
  +
Compensating Controls
  ↓
Risk-Based Priority

5. Step 1 — Record the Finding

Capture:

Finding ID:

Scanner:

Detection Time:

Asset:

IP Address:

Hostname:

Operating System:

Application:

Port:

Protocol:

Plugin / Rule ID:

Finding Name:

CVE:

CVSS:

Scanner Severity:

Preserve the original scanner evidence.

6. Step 2 — Identify the Affected Asset

Record:

Hostname:

IP:

Asset Owner:

Business Unit:

Environment:

Operating System:

Application:

Asset Type:

Asset Criticality:

Data Classification:

Internet Facing:
Yes / No / Unknown

7. Step 3 — Determine Asset Criticality

Classify:

Low

Medium

High

Critical

Consider:

• business function

• sensitive data

• privileged access

• production dependency

• customer impact

• regulatory requirements

• availability requirements

A vulnerability on a critical identity server should not necessarily receive the same treatment as the same vulnerability on an isolated test workstation.

8. Step 4 — Validate the Finding

Determine whether the vulnerability actually applies.

Check:

Software Installed?

Affected Version?

Affected Configuration?

Service Running?

Port Accessible?

Patch Installed?

Vendor Conditions Met?

Classify:

Confirmed

Likely

False Positive

Unable to Validate

9. Step 5 — Identify the CVE

Record:

CVE:

Vendor:

Product:

Affected Versions:

Fixed Version:

Published Date:

Last Updated:

A scanner plugin may reference multiple CVEs.

Evaluate each relevant vulnerability.

10. Step 6 — Understand the Vulnerability

Determine the vulnerability type.

Examples:

Remote Code Execution

Privilege Escalation

Authentication Bypass

Information Disclosure

SQL Injection

Cross-Site Scripting

Path Traversal

Command Injection

Denial of Service

Security Misconfiguration

11. Step 7 — Determine Attack Preconditions

Ask:

Is authentication required?

Is local access required?

Is network access required?

Is user interaction required?

Are specific configurations required?

Does exploitation require privileges?

Preconditions significantly affect practical risk.

12. Step 8 — Review CVSS

Record:

CVSS Version:

Base Score:

Severity:

Vector:

Example:

CVSS:
9.8

Severity:
Critical

But remember:

CVSS measures technical severity. It does not tell you whether attackers are likely to exploit the vulnerability in your environment.

13. Step 9 — Interpret the CVSS Vector

Review factors such as:

Attack Vector

Attack Complexity

Privileges Required

User Interaction

Scope

Confidentiality Impact

Integrity Impact

Availability Impact

Use the vector to understand why the score is high or low.

14. Step 10 — Review EPSS

Record:

EPSS Score:

EPSS Percentile:

Date Checked:

EPSS estimates the probability that a vulnerability will be exploited in the wild within its prediction window.

Use EPSS as one prioritization input rather than a standalone verdict.

15. Step 11 — Compare CVSS and EPSS

You may encounter:

High CVSS
+
Low EPSS

or:

Medium CVSS
+
High EPSS

These findings may require different remediation priorities.

Example:

CVE	CVSS	EPSS	Initial Assessment
CVE-A	9.8	Low	Severe but currently lower exploitation likelihood
CVE-B	7.5	High	Lower severity but higher exploitation likelihood

Do not prioritize solely by CVSS.

16. Step 12 — Check Active Exploitation

Determine whether credible evidence indicates exploitation in the wild.

Record:

Active Exploitation:

Confirmed / Reported / Not Identified / Unknown

Source:

Date:

Active exploitation should substantially increase remediation urgency.

17. Step 13 — Check Known Exploited Vulnerability Status

Determine whether the vulnerability appears in authoritative known-exploitation tracking used by your organization.

Record:

Known Exploited:

Yes / No

Required Action:

Due Date:

Treat confirmed active exploitation as a major risk factor.

18. Step 14 — Check Exploit Availability

Determine whether:

Proof of Concept Exists

Reliable Exploit Exists

Exploit Framework Support Exists

Weaponized Exploitation Reported

Classify:

None Identified

PoC Available

Functional Exploit

Weaponized / Active Exploitation

19. Step 15 — Distinguish PoC from Active Exploitation

Do not treat:

Public PoC

as equivalent to:

Active Exploitation

A proof-of-concept demonstrates feasibility.

Active exploitation indicates actual threat activity.

20. Step 16 — Review Threat Intelligence

Search approved sources for:

CVE

Product

Vendor

Malware Association

Ransomware Association

Threat Actor Activity

Campaign Activity

Record:

Threat Activity:

Associated Malware:

Associated Campaign:

Observed Targets:

Confidence:

21. Step 17 — Determine Internet Exposure

Classify:

Internet Facing

Externally Reachable Through Controlled Access

Internal Only

Isolated

Unknown

Internet exposure can substantially increase exploitation opportunity.

22. Step 18 — Validate Exposure

Do not rely only on CMDB labels.

Confirm using:

Firewall Configuration

Cloud Security Groups

Load Balancer Configuration

External Asset Inventory

Network Architecture

Scanner Perspective

23. Step 19 — Determine Network Reachability

Ask:

Which systems can reach the vulnerable service?

Can user networks reach it?

Can guest networks reach it?

Can compromised endpoints reach it?

Is segmentation enforced?

Internal vulnerabilities may still present significant lateral-movement risk.

24. Step 20 — Determine Authentication Exposure

Ask:

Does exploitation require authentication?

Which identities can authenticate?

Is MFA required?

Are privileged credentials required?

Can anonymous users access the service?

25. Step 21 — Determine Data Sensitivity

Record whether the system processes:

Public Data

Internal Data

Confidential Data

Credentials

Financial Data

Customer Data

Security Data

Regulated Data

26. Step 22 — Determine Business Impact

Ask:

What happens if this asset is compromised?

Could business operations stop?

Could sensitive data be exposed?

Could attacker privileges increase?

Could the asset provide lateral movement?

Could customers be affected?

27. Step 23 — Review Compensating Controls

Identify controls such as:

Firewall

WAF

Network Segmentation

MFA

EDR

Application Allowlisting

IPS

Restricted Administrative Access

Zero Trust Controls

Record:

Control:

Coverage:

Effectiveness:

Evidence:

28. Step 24 — Do Not Assume Controls Eliminate Risk

A compensating control may:

Reduce Risk

but rarely means:

Vulnerability No Longer Exists

Document residual risk.

29. Step 25 — Check for Existing Exploitation Evidence

Search internal telemetry for:

Exploit Signatures

Suspicious Requests

Unexpected Processes

Malware Alerts

Authentication Anomalies

Connections to Known Infrastructure

If exploitation is suspected:

Vulnerability Management
        ↓
Incident Investigation

The issue is no longer only a patch-management problem.

30. Step 26 — Determine Vulnerability Scope

Identify:

Total Affected Assets:

Production Assets:

Internet-Facing Assets:

Critical Assets:

Cloud Assets:

User Endpoints:

Servers:

31. Step 27 — Group Duplicate Findings

One vulnerability may affect hundreds of assets.

Group using:

CVE

Product

Version

Business Service

Asset Owner

Environment

This makes remediation easier to coordinate.

32. Step 28 — Identify High-Risk Combinations

Prioritize combinations such as:

Critical Asset
+
Internet Facing
+
Active Exploitation

or:

Remote Code Execution
+
No Authentication
+
Public Exploit

or:

Identity Infrastructure
+
Privilege Escalation
+
High EPSS

33. Step 29 — Calculate Risk-Based Priority

Use organizational scoring where available.

A conceptual model is:

Technical Severity
        +
Exploit Likelihood
        +
Threat Activity
        +
Exposure
        +
Asset Criticality
        +
Business Impact
        -
Compensating Controls
        ↓
Remediation Priority

34. Step 30 — Assign Priority

Use:

P1 — Emergency

P2 — High

P3 — Medium

P4 — Routine

35. P1 — Emergency

Typical indicators:

Active Exploitation

Critical Internet-Facing Asset

Known Weaponized RCE

Critical Identity Infrastructure

Ransomware-Associated Vulnerability

Confirmed Internal Exploitation

Response may require immediate mitigation or emergency patching.

36. P2 — High

Typical indicators:

High/Critical Technical Severity

Public Exploit

High EPSS

Important Production Asset

Significant Network Exposure

Remediate rapidly according to organizational SLA.

37. P3 — Medium

Typical indicators:

Moderate Exploitability

Internal Exposure

Limited Business Impact

Strong Compensating Controls

Schedule normal remediation.

38. P4 — Routine

Typical indicators:

Low Exploitability

Low-Criticality Asset

Strong Isolation

Minimal Impact

Track through normal vulnerability-management processes.

39. Step 31 — Create the Priority Record

Finding:

CVE:

CVSS:

EPSS:

Active Exploitation:

Exploit Available:

Internet Facing:

Asset Criticality:

Business Impact:

Compensating Controls:

Priority:

Rationale:

The rationale is critical.

40. Step 32 — Select Remediation Strategy

Possible strategies:

Patch

Upgrade

Configuration Change

Disable Service

Remove Software

Restrict Network Access

Apply Vendor Workaround

Deploy Compensating Control

Accept Risk

41. Step 33 — Prefer Vendor Remediation

Where practical, prioritize:

Vendor Patch

Supported Upgrade

Official Mitigation

over undocumented workarounds.

42. Step 34 — Review Patch Availability

Record:

Patch Available:

Patch ID:

Fixed Version:

Release Date:

Restart Required:

Known Issues:

43. Step 35 — Determine Operational Impact

Before deployment, assess:

Application Compatibility

Downtime

Restart Requirements

Dependencies

High-Availability Impact

Business Schedule

Security urgency must be balanced with safe implementation.

44. Step 36 — Determine Emergency Mitigation

When immediate patching is impossible, consider:

Restrict Internet Access

Disable Vulnerable Feature

Block Exploit Pattern

Apply WAF Rule

Apply IPS Rule

Segment Asset

Restrict Authentication

Increase Monitoring

Document that mitigation is temporary unless it permanently resolves the risk.

45. Step 37 — Assign Remediation Owner

Record:

Owner:

Team:

Business Owner:

Assigned Date:

Target Date:

Priority:

SLA:

A vulnerability without an owner is unlikely to be remediated reliably.

46. Step 38 — Track SLA

Track:

Detection Date

Assignment Date

Target Date

Remediation Date

Validation Date

Closure Date

Identify overdue vulnerabilities.

47. Step 39 — Handle Remediation Exceptions

If remediation cannot be completed within SLA, require documented exception handling.

Capture:

Reason:

Business Justification:

Risk:

Compensating Controls:

Risk Owner:

Approval:

Expiration Date:

Review Date:

48. Step 40 — Avoid Permanent Exceptions

Exceptions should have:

Owner

Expiration

Review Date

Residual Risk

Compensating Controls

An exception should not become a forgotten vulnerability.

49. Step 41 — Implement Remediation

Depending on the approved action:

Patch

Upgrade

Reconfigure

Disable

Remove

Restrict

Mitigate

Document the exact change.

50. Step 42 — Validate Remediation

Never close a vulnerability solely because a patch ticket says:

Completed

Verify technically.

51. Step 43 — Rescan the Asset

Run an approved vulnerability rescan.

Record:

Rescan Date:

Scanner:

Finding Present:
Yes / No

Result:

52. Step 44 — Validate Version

Where appropriate, confirm:

Installed Version

Patch Level

Configuration

Service State

53. Step 45 — Validate Compensating Controls

If mitigation was used, verify that it actually prevents or reduces exploitation.

Check:

Firewall Rule Active?

WAF Rule Active?

IPS Rule Active?

Service Restricted?

Network Segmentation Effective?

54. Step 46 — Check for Regression

Ensure remediation did not:

Break Application

Disable Security Controls

Expose New Service

Create Availability Problem

Introduce Unsupported Configuration

55. Step 47 — Determine Closure Status

Use:

Remediated

Mitigated

Risk Accepted

False Positive

Duplicate

Superseded

Open

56. Step 48 — Close with Evidence

Closure evidence may include:

Clean Rescan

Patch Verification

Version Verification

Configuration Evidence

Control Validation

Approved Risk Acceptance

57. Step 49 — Monitor for Reappearance

A vulnerability may return because of:

New Server Deployment

Old Image

Rollback

Configuration Drift

Missed Asset

Software Reinstallation

Monitor recurring findings.

58. Step 50 — Identify Systemic Root Cause

For repeated findings, ask:

Why does this vulnerability keep returning?

Is the base image outdated?

Is patch automation failing?

Is asset inventory incomplete?

Are systems unsupported?

Is configuration management failing?

59. Step 51 — Track Vulnerability Aging

Measure:

0–30 Days

31–60 Days

61–90 Days

90+ Days

Prioritize aging high-risk findings.

60. Step 52 — Track Remediation Performance

Useful metrics include:

Open Vulnerabilities

Critical Vulnerabilities

Known Exploited Vulnerabilities

Internet-Facing Critical Findings

Mean Time to Remediate

SLA Compliance

Reopened Findings

Accepted Risks

61. Step 53 — Avoid Vanity Metrics

A simple count such as:

10,000 Vulnerabilities

provides limited context.

A better view is:

12 Actively Exploited Vulnerabilities
on Critical Internet-Facing Systems

Risk context matters more than raw count.

62. Step 54 — Build a Vulnerability Dashboard

Track:

Metric	Value
Total Open	<count>
Critical	<count>
High	<count>
Known Exploited	<count>
Internet-Facing Critical	<count>
SLA Breaches	<count>
Accepted Risks	<count>
Average Remediation Time	<days>

63. Step 55 — Escalation Criteria

Escalate when:

Active Exploitation Identified

Critical Internet-Facing Vulnerability

Known Exploited Vulnerability on Critical Asset

Public Exploit + High-Value Asset

Ransomware-Associated Vulnerability

Domain / Identity Infrastructure Affected

Remediation SLA Significantly Breached

Compensating Controls Ineffective

Evidence of Successful Exploitation

If successful exploitation is identified, escalate into incident response.

64. Vulnerability Escalation Template

Finding ID:

CVE:

Vulnerability:

Affected Asset:

Asset Owner:

Asset Criticality:

Internet Facing:

CVSS:

EPSS:

Known Exploited:

Exploit Availability:

Active Exploitation:

Threat Intelligence:

Business Impact:

Compensating Controls:

Residual Risk:

Priority:

Recommended Remediation:

Temporary Mitigation:

Target Date:

Escalated To:

65. Example P1 Vulnerability

Finding:
VULN-2026-091

CVE:
<CVE-ID>

Asset:
Public-facing production application server

Asset Criticality:
Critical

CVSS:
Critical

EPSS:
High

Exploit Availability:
Public exploit available

Active Exploitation:
Reported

Exposure:
Internet facing

Compensating Controls:
Limited

Priority:
P1 — Emergency

Recommendation:
Apply vendor remediation immediately.

Temporary Mitigation:
Restrict unnecessary external access and deploy
validated network/application protections until
patching is complete.

Validation:
Rescan after remediation and verify installed version.

66. Example P3 Vulnerability

Finding:
VULN-2026-144

Asset:
Internal development workstation

Asset Criticality:
Low

Exposure:
Internal only

CVSS:
High

EPSS:
Low

Known Exploited:
No

Exploit Availability:
No reliable exploit identified.

Compensating Controls:
Endpoint protection and network segmentation.

Priority:
P3 — Medium

Recommendation:
Remediate through standard patch cycle.

Rationale:
Technical severity is elevated, but practical
exposure and exploitation likelihood are lower.

67. Example False Positive

Finding:
VULN-2026-211

Scanner:
Authenticated scanner

Finding:
Outdated application version

Validation:
Installed package version manually verified.

Patch:
Vendor security fix is present through a
backported package update.

Assessment:
Scanner version logic did not account for
vendor backporting.

Classification:
False Positive

Evidence:
Package version and vendor advisory recorded.

Disposition:
Close as false positive.

68. Vulnerability Decision Matrix

Condition	Priority Direction
Active exploitation	Increase significantly
Known exploited vulnerability	Increase
Internet facing	Increase
Critical asset	Increase
Public reliable exploit	Increase
High EPSS	Increase
Remote unauthenticated exploitation	Increase
Strong segmentation	May reduce
Effective compensating control	May reduce
Low-value isolated asset	May reduce
False positive confirmed	Close

69. Rapid Vulnerability Triage Checklist

□ Finding preserved

□ Asset identified

□ Asset owner identified

□ Asset criticality determined

□ Finding validated

□ CVE identified

□ Affected version verified

□ CVSS reviewed

□ CVSS vector reviewed

□ EPSS reviewed

□ Known exploitation checked

□ Exploit availability checked

□ Threat intelligence reviewed

□ Internet exposure determined

□ Network reachability assessed

□ Authentication requirements assessed

□ Data sensitivity reviewed

□ Business impact assessed

□ Compensating controls reviewed

□ Existing exploitation evidence searched

□ Scope determined

□ Risk priority assigned

□ Priority rationale documented

□ Remediation identified

□ Owner assigned

□ SLA established

□ Temporary mitigation considered

□ Exception documented if necessary

□ Remediation completed

□ Rescan performed

□ Technical validation completed

□ Closure evidence recorded

70. Vulnerability Investigation Template

# Vulnerability Triage Record

## Finding Information

Finding ID:

Scanner:

Detection Date:

Finding:

CVE:

## Asset

Hostname:

IP:

Owner:

Environment:

Criticality:

Internet Facing:

Data Classification:

## Validation

Finding Confirmed:

Affected Version:

Evidence:

## Technical Severity

CVSS:

Vector:

Vulnerability Type:

Attack Preconditions:

## Exploitability

EPSS:

Exploit Available:

Known Exploited:

Active Exploitation:

## Threat Intelligence

Document relevant intelligence.

## Exposure

Internet Exposure:

Network Reachability:

Authentication Requirements:

## Business Context

Business Function:

Potential Impact:

## Compensating Controls

Document existing controls.

## Internal Exploitation Evidence

Document findings.

## Risk Assessment

Technical Severity:

Exploit Likelihood:

Threat Activity:

Asset Criticality:

Exposure:

Business Impact:

Residual Risk:

## Priority

P1 / P2 / P3 / P4

Rationale:

## Remediation

Recommended Action:

Patch / Version:

Temporary Mitigation:

Owner:

Target Date:

SLA:

## Exception

Required:
Yes / No

Justification:

Risk Owner:

Expiration:

## Validation

Rescan Date:

Result:

Version Verified:

Control Verified:

## Closure

Status:

Closure Date:

Evidence:

## Final Analyst Assessment

Summarize the finding and remediation decision.

71. Runbook Validation Checklist

Finding

• Original scanner evidence preserved

• Asset identified

• Asset owner identified

• Finding validated

• False positive considered

• CVE identified

Technical Risk

• CVSS reviewed

• CVSS vector understood

• Attack prerequisites identified

• Vulnerability impact understood

Exploitability

• EPSS reviewed

• Public exploit availability checked

• Active exploitation checked

• Known-exploited status checked

• Threat intelligence reviewed

Business Context

• Asset criticality determined

• Internet exposure validated

• Network reachability assessed

• Data sensitivity reviewed

• Business impact assessed

• Compensating controls reviewed

Prioritization

• Scope established

• Risk priority assigned

• Priority rationale documented

• SLA established

• Remediation owner assigned

Remediation

• Vendor remediation identified

• Patch availability reviewed

• Operational impact considered

• Temporary mitigation identified where required

• Exception process followed where necessary

Validation

• Remediation implemented

• Asset rescanned

• Version/configuration validated

• Compensating controls validated

• Regression checked

• Closure evidence recorded

72. Common Analyst Mistakes

Avoid:

Prioritizing only by CVSS

Ignoring EPSS

Ignoring active exploitation

Ignoring asset criticality

Ignoring internet exposure

Ignoring exploit prerequisites

Treating every public PoC as active exploitation

Assuming internal systems are low risk

Ignoring lateral-movement potential

Assuming compensating controls eliminate vulnerability

Closing findings because a patch ticket says complete

Failing to rescan

Allowing exceptions without expiration

Ignoring recurring vulnerabilities

Tracking only vulnerability counts

Failing to investigate evidence of exploitation

73. Key CySA+ Concepts

Severity vs Risk

Severity
≠
Organizational Risk

CVSS vs EPSS

CVSS
=
How Severe Could Exploitation Be?

EPSS
=
How Likely Is Exploitation?

They answer different questions.

Vulnerability vs Incident

Vulnerability
      +
Evidence of Exploitation
      ↓
Potential Security Incident

At that point, activate the appropriate investigation runbook.

Patch vs Remediation

Patch

is one remediation option.

Others include:

Upgrade

Reconfigure

Disable

Remove

Segment

Mitigate

Remediation vs Closure

Change Implemented
≠
Vulnerability Closed

Closure requires validation.

74. Runbook Summary

A weak vulnerability-management process looks like:

Scanner
   ↓
CVSS
   ↓
Patch
   ↓
Close

A mature risk-based workflow looks like:

Scanner Finding
      ↓
Validate
      ↓
CVE
      ↓
CVSS
      ↓
EPSS
      ↓
Exploit Availability
      ↓
Active Exploitation
      ↓
Threat Intelligence
      ↓
Asset Criticality
      ↓
Exposure
      ↓
Compensating Controls
      ↓
Risk-Based Priority
      ↓
Remediation / Mitigation
      ↓
Rescan
      ↓
Validate
      ↓
Close

The key operational lesson is:

The most severe vulnerability is not always the vulnerability that should be fixed first. Prioritization should focus on the vulnerabilities most likely to be exploited and capable of causing meaningful damage to the organization.

CySA+ Runbooks Complete

You have now completed the CySA+ operational runbook series:

Runbook 01 — SOC Alert Triage and Escalation

Runbook 02 — Suspicious Authentication Investigation

Runbook 03 — Phishing Email Investigation and Response

Runbook 04 — Malware and Endpoint Compromise Investigation

Runbook 05 — Network Security Alert Investigation

Runbook 06 — Ransomware Incident Response

Runbook 07 — Vulnerability Triage and Remediation Prioritization

Together, these runbooks create an operational workflow:

Alert
  ↓
Triage
  ↓
Identity Investigation
  ↓
Phishing Investigation
  ↓
Endpoint Investigation
  ↓
Network Investigation
  ↓
Incident Response
  ↓
Vulnerability Management

What’s Next?

With the CySA+ Labs and Runbooks complete, the next step is to use them together in scenario-based investigations.

The learner should be able to move from:

Security Alert
      ↓
Collect Evidence
      ↓
Analyze Logs
      ↓
Correlate Events
      ↓
Enrich IOCs
      ↓
Determine Scope
      ↓
Assess Impact
      ↓
Prioritize Response
      ↓
Contain / Remediate
      ↓
Document
      ↓
Escalate

This brings together the skills developed across the CySA+ labs into the working mindset expected from a Cybersecurity Analyst / SOC Analyst.

➡️ CySA+ Labs & Runbooks Complete