Vulnerability Remediation Timelines for 12 Security Frameworks
by Brinqa, Research Team//

When a critical vulnerability lands, one of the first questions asked is how long you have to fix it. The truth is, there’s no one answer. Your auditors may have one expectation, customer contracts may have another, and regulators can impose different requirements depending on your industry and where you operate.
Part of the confusion is that individual security frameworks approach remediation timelines differently. Some give you a specific number of days. Others expect you to set your own timelines and demonstrate that you follow them. A few focus on how quickly you need to report an incident or vulnerability rather than how quickly you fix it.
This guide covers 12 common security frameworks and regulations, grouped by who they apply to. Jump to the ones that matter to your organization, or use the comparison table at the end to see all 12 side by side.
Frameworks used across industries
1. NIST SP 800-53 Rev. 5
NIST SP 800-53 is the security control catalog for US federal systems, and many regulated organizations use it as a baseline too. It does not set a specific remediation deadline. Control SI-2 says you must install security updates within a timeframe your organization defines. SI-2(3) adds that you must measure how long remediation takes and set targets for it.
Timeline: you set it. Assessors will look for the targets you set and records showing whether you met them. Our NIST 800-53 vulnerability management guide and NIST SP 800-53r5 checklist cover the related controls.
2. ISO/IEC 27001:2022
ISO 27001 is the international standard for managing information security. Annex A control 8.8 requires organizations to identify technical vulnerabilities, assess their exposure and take appropriate action. It does not prescribe a timeframe.
Timeline: you set it, based on risk. Auditors look for documented timelines and evidence that you follow them, including records of any risks you decided to accept. Our ISO 27001 compliance checklist covers the full control set.
3. CIS Critical Security Controls v8
The CIS Controls are a prioritized list of security practices that many organizations use as a practical starting point. Safeguard 7.2 calls for a documented, risk-based remediation process that is reviewed at least monthly. Safeguard 7.7 calls for detected vulnerabilities to be remediated monthly or more often.
Timeline: monthly or faster, based on your documented remediation process.
4. SOC 2
SOC 2 is an audit, based on the AICPA's Trust Services Criteria, that service providers use to demonstrate how their security controls operate. It doesn't set remediation deadlines.
Timeline: you set it. Auditors evaluate whether vulnerabilities were addressed within the timeframes in your own policy during the audit period. If your policy promises a timeline your team can't meet, that becomes an audit exception.
US federal government and its suppliers
5. CISA BOD 26-04
Binding Operational Directive 26-04 applies to US federal civilian agencies. CISA issued it on 10 June 2026, and it replaces BOD 22-01. The remediation deadline depends on four factors: Is the asset publicly exposed? Is the vulnerability in CISA's Known Exploited Vulnerabilities (KEV) catalog? Can an attacker automate the exploit? Would exploitation give the attacker total control?
Timeline: 3 days for the highest-risk combinations, 14 days for most KEV-listed vulnerabilities, 60 days for lower-risk ones, and the next system upgrade when none of the four apply. Agencies must be working to these timelines within 180 days of the directive's release. Private-sector organizations are not bound by it, but CISA encourages every organization to prioritize KEV-listed vulnerabilities.
6. FedRAMP
FedRAMP covers cloud services sold to US federal agencies. Under the traditional Rev. 5 process, providers must fix high-risk vulnerabilities within 30 days of discovery, moderate within 90 days and low within 180 days. To align with BOD 26-04, new Vulnerability Detection and Response rules become mandatory on 7 December 2026. The new approach replaces fixed severity-based windows with deadlines based on potential impact to agencies, internet reachability and the likelihood of exploitation.
Timeline: 30, 90 and 180 days today, moving to context-based deadlines from 7 December 2026. Providers are also expected to fix KEV-listed vulnerabilities by CISA's due dates.
Payments and healthcare
7. PCI DSS v4.0.1
PCI DSS applies to any organization that stores, processes or transmits payment card data. Requirement 6.3.3 says patches for critical vulnerabilities must be installed within one month of release. Organizations determine what counts as critical, using the risk-ranking process in Requirement 6.3.1. Version 4.0 applied the one-month rule to critical and high-risk patches, and version 4.0.1 narrowed it to critical only, so it is worth checking which wording your internal policy uses.
Timeline: one month for critical patches, and your own timeframes for everything else. Requirement 11.3.1 also calls for internal scans at least every three months, with high-risk and critical findings fixed and rescanned. Our PCI DSS compliance guide for vulnerability management goes into more detail.
8. HIPAA Security Rule
The HIPAA Security Rule applies to US healthcare providers, health plans and the business associates that handle patient data for them. The current rule requires security measures appropriate to the organization's risk, with no fixed patch timeline. A proposed update would require critical patches within 15 days and high-risk patches within 30 days, but it isn't in force yet and its expected date has slipped.
Timeline: no fixed patch deadline today. If the proposed rule is finalized as written, 15 days for critical and 30 days for high. The separate Breach Notification Rule's 60-day deadline stays the same.
European Union
9. GDPR
GDPR applies to any organization that processes the personal data of people in the EU. Article 32 requires security that fits the risk, and names no remediation timeline. Article 33 requires you to tell your supervisory authority about a personal data breach within 72 hours of becoming aware of it.
Timeline: no deadline for fixing vulnerabilities, and 72 hours to report a breach. If a breach traces back to a known, unpatched vulnerability, regulators may examine whether your remediation practices were appropriate to the risk. Our GDPR compliance guide for vulnerability management covers what regulators look for.
10. NIS2
NIS2 applies to essential and important organizations in sectors such as energy, transport, health and digital infrastructure. Article 21 names vulnerability handling as a required security measure, including vulnerabilities in the software supply chain, but sets no remediation deadline. The fixed timelines come from Article 23, which covers significant incidents.
Timeline: for significant incidents, an early warning within 24 hours of becoming aware, a notification within 72 hours, and a final report within one month. National laws that implement NIS2 can add shorter deadlines for some sectors.
11. DORA
The Digital Operational Resilience Act applies to EU financial organizations such as banks, insurers and investment firms, and has applied since 17 January 2025. It requires a framework for managing technology risk, including how you manage vulnerabilities and patches, but sets no patch deadline.
Timeline: for major technology incidents, an initial notification within 4 hours of classifying the incident as major and no later than 24 hours after becoming aware of it, an intermediate report within 72 hours, and a final report within one month.
12. EU Cyber Resilience Act (CRA)
The CRA applies to manufacturers of hardware and software products sold in the EU. Its reporting rules took effect on 11 September 2026. The wider security requirements, including how vulnerabilities are handled, apply from 11 December 2027.
Timeline: when a manufacturer learns that a vulnerability in its product is being actively exploited, it must send an early warning within 24 hours, a notification within 72 hours, and a final report within 14 days of a fix being available. Our CRA vulnerability management compliance guide explains who's in scope.
All 12 frameworks compared
| Framework | Who it applies to | Deadline to fix | Deadline to report |
|---|---|---|---|
NIST SP 800-53 Rev. 5 | US federal systems; widely used elsewhere | You set it | None |
ISO/IEC 27001:2022 | Certified organizations | You set it | None |
CIS Controls v8 | Organizations that adopt them | Monthly or faster | None |
SOC 2 | Service providers | You set it | None |
CISA BOD 26-04 | US federal civilian agencies | 3, 14 or 60 days, or next upgrade | None |
FedRAMP | Cloud services sold to US agencies | 30, 90 or 180 days; context-based from 7 Dec 2026 | None |
PCI DSS v4.0.1 | Anyone handling payment card data | One month for critical patches | None |
HIPAA Security Rule | US healthcare organizations | None today (15 and 30 days proposed) | Breaches: 60 days |
GDPR | Anyone processing EU personal data | None | Breaches: 72 hours |
NIS2 | Essential and important EU organizations | None | Significant incidents: 24 hours, 72 hours, one month |
DORA | EU financial organizations | None | Major incidents: 4 hours after classification (24 hours max), 72 hours, one month |
EU CRA | Makers of products sold in the EU | None yet | Actively exploited vulnerabilities: 24 hours, 72 hours, 14 days after a fix |
Meeting the timelines that apply to you
The requirements vary, but meeting them depends on the same fundamentals: knowing which assets are in scope, avoiding duplicate vulnerability records, identifying the right owner, and keeping a reliable record of when each issue was found and resolved.
Brinqa integrates with more than 300 security and IT tools, bringing findings from the systems you already use into a single view in the Brinqa CyberRisk Graph™. Within the platform’s AI layer, the AI Deduplication Agent merges duplicate findings into one record, and the AI Attribution Agent assigns each exposure an owner. Brinqa keeps the original data from every source behind each merged record, giving teams an audit trail that shows where a finding came from and how it changed over time.
For more on prioritizing by risk, visit risk-based vulnerability management.
Pick deadlines your team can meet
More than half of these frameworks leave the remediation deadline up to you. Once those timelines are written into policy, they become part of what auditors and assessors evaluate, so set deadlines that reflect the risk to your most important assets, make sure your teams can realistically meet them and keep the records needed to demonstrate that they did.
To see how Brinqa connects every vulnerability to an owner and keeps a full record of when it was found and fixed, request a demo.
FAQs
Under PCI DSS v4.0.1 Requirement 6.3.3, patches for critical vulnerabilities must be installed within one month of release. Other patches follow timeframes your organization sets based on its risk ranking.
No. SI-2 requires updates within a time period your organization sets, and SI-2(3) requires you to measure how long fixes take and set targets. You define the timeframe, then maintain evidence showing whether you met it.
BOD 26-04, issued on 10 June 2026. It keeps the Known Exploited Vulnerabilities catalog and sets deadlines of 3, 14 or 60 days, or the next system upgrade, depending on exposure, KEV status, whether the exploit can be automated, and how much control an attacker would gain.
Under the traditional Rev. 5 process: 30 days for high-risk vulnerabilities, 90 days for moderate and 180 days for low. From 7 December 2026, new rules set deadlines based on potential impact, internet reachability and likelihood of exploitation.
Not today. A proposed update to the Security Rule would require critical patches within 15 days and high-risk patches within 30 days, but it hasn't been finalized.
A consistent set of measures can make reporting easier across frameworks: the percentage of vulnerabilities remediated on time, overdue KEV-listed vulnerabilities, average time to fix, and open accepted risks with named owners. Our UVEM KPI and KRI scorecard gives you a starting set.


