To respond to a critical CVE in a week, confirm on day one whether you are affected, check whether it is being exploited, mitigate or patch the exposed systems by day three, verify the fix, and use the remaining days to cover stragglers and record what you did. Speed depends on already having an inventory.
Key takeaways
- The first question is "are we affected and exposed?", not "how bad is the score?"
- Exploitation evidence, such as CISA KEV status, should set your urgency more than severity alone.
- A temporary mitigation on day one beats a perfect patch on day six.
- If you sell into the EU, reporting clocks may apply to exploited vulnerabilities in your own products.
What does a one week plan look like?
It is seven short steps. Adjust the days to your risk, but keep the order.
| Day | Goal | Output |
|---|---|---|
| 1 | Find where the component is and whether it is reachable | List of affected systems and owners |
| 1 | Check exploitation status | KEV, EPSS and vendor advisory notes |
| 2 | Decide: patch, upgrade, or mitigate | Named owner and deadline per system |
| 2 to 3 | Apply mitigation or fix to the most exposed systems | Changes deployed |
| 4 | Verify | Rescan results, tests, monitoring |
| 5 to 6 | Cover the rest, including forgotten services | Remaining systems fixed |
| 7 | Record and review | Short write up and process fixes |
Day 1: How do I know if I am affected?
Search your inventory for the component and version. An SBOM per release makes this a query instead of a hunt. If you do not have one yet, our guide on how to create an SBOM step by step is the place to start, and you can get a first inventory of a dependency file at gold.safeguard.sh/scan for free, in the browser, with no login.
Then ask whether the vulnerable code is actually reachable and exposed. A vulnerable library that your code never calls, on an internal service, is a different priority from one on an internet facing endpoint. Safeguard offers reachability analysis for this question.
Day 1: Is it being exploited?
Check exploitation evidence before you rank anything. CISA says its Known Exploited Vulnerabilities catalog is the authoritative source of vulnerabilities exploited in the wild, and that organizations should use it as an input to prioritization. Each entry has a date added and a due date.
EPSS adds a forecast. FIRST describes it as the probability that a published CVE will be exploited in the wild in the next 30 days. It is a likelihood, not a severity rating, so use it alongside the CVSS score and KEV status.
Day 2: Patch, upgrade or mitigate?
Pick the fastest safe option per system:
- Upgrade to the fixed version if it is a small change.
- Mitigate with a vendor workaround, a config change, a WAF rule or by turning off the affected feature, when the fix needs testing.
- Isolate the system from the internet or restrict access while you wait.
- Accept with a date when it is not reachable. Write down who accepted it and when it will be revisited.
Assign one owner and one deadline per system. Shared ownership stalls.
Days 2 and 3: How do I roll out the fix?
Start with the most exposed systems: internet facing first, then anything holding sensitive data. Use your normal pipeline so the change is reviewed and reproducible. Pin the new version in the lockfile so it does not drift back.
Day 4: How do I verify the fix worked?
Rescan and confirm the vulnerable version is gone. Run tests. Check logs for signs of exploitation before the fix, since an attacker may have arrived first. For serious cases, rotate secrets that the system could reach.
Days 5 to 6: What gets missed?
Forgotten services, old container images, staging environments and vendored copies of the library. Search again by component name and by image layers. Check your vendors too: ask whether their products include the affected component.
The demo below shows tracking a vulnerability across systems.
Click through it at your own pace, or open it full screen.
Day 7: What should I record?
Write a half page: what the CVE was, when you learned about it, when you confirmed exposure, when you fixed each system, and what slowed you down. Turn the slowdowns into changes, such as a missing owner list or no SBOM for one product.
Do I have to report it to anyone?
Possibly. Under the EU Cyber Resilience Act, manufacturers must send an early warning within 24 hours of becoming aware of an actively exploited vulnerability in their product, with a notification within 72 hours. Reporting applies from 11 September 2026. See what software companies must do under the CRA, and ask counsel whether your product is in scope.
Frequently asked questions
Is a week realistic for a critical CVE?
For most teams with an inventory, yes. For an actively exploited flaw on an internet facing system, aim for mitigation within a day or two.
Should I patch everything for every critical CVE?
No. Check exposure, exploitation and reachability first, then fix in order of risk. Record anything you choose not to fix.
What is the difference between CVSS, EPSS and KEV?
CVSS rates severity, EPSS estimates the chance of exploitation in the next 30 days, and KEV lists vulnerabilities already exploited in the wild.
What if there is no patch yet?
Mitigate: apply the vendor workaround, restrict access or disable the feature, and monitor for exploitation. See what is a zero day vulnerability.
Who should own the response?
One named person coordinates, and each affected system has one named owner. Shared ownership slows everything.
Sources
- CISA Known Exploited Vulnerabilities catalog
- FIRST: Exploit Prediction Scoring System
- European Commission: Cyber Resilience Act
- Regulation (EU) 2024/2847 on EUR-Lex
- Safeguard Gold dependency scan
Last reviewed: 19 October 2026.
