How quickly should vulnerabilities be fixed?

This is a map of clocks, not YOUR deadline

Audience: a CISO, eng leader, or compliance owner who needs to answer 'how fast do we have to fix this' for an auditor, a customer security questionnaire, or their own board. This page is not legal advice. It does not determine which text below binds YOUR organization, and reading it does not start a remediation clock. Whether BOD 26-04, PCI DSS, or something else applies to you is a fact question your counsel or QSA answers, not a question this page answers for you.

The three kinds of text below are not interchangeable. A binding operational directive is a compulsory federal order that applies to a defined set of agencies. A framework requirement like PCI DSS Requirement 6.3.3 is a contractual/industry-standard obligation that binds organizations that accept payment cards, enforced through the card networks and acquiring banks, not by statute. NIST SP 800-40r4 and ISO/IEC 27001:2022 A.8.8 are guidance and a certifiable management-system control, respectively — neither states a specific day-count. Most organizations outside those specific binds are left to set and defend their own risk-based windows, which is the subject of the remediation-SLAs guide on this site.

• The exploitability-vs-severity guide on this site is the signal-definitions page this timeline section assumes. The what-is-KEV guide on this site is the CISA KEV catalog explainer. The remediation-SLAs guide on this site is where 'set your own defensible window' is worked through in detail. The prove-remediation guide on this site covers evidencing that a fix actually landed inside whatever window applied.
• The vulnerability management pillar on this site is not published yet; naming it here is not a link.

Legal requirement vs framework guidance vs industry norm

This table separates who is actually bound by each text from who merely treats it as a strong reference point. Last verified 10 September 2026. Not legal advice.

CISA BOD 26-04: the current FCEB directive, not BOD 22-01

CISA issued Binding Operational Directive 26-04, 'Prioritizing Security Updates Based on Risk,' on 10 June 2026. Its own text states plainly: 'This Directive supersedes and hereby revokes BOD 19-02: Vulnerability Remediation Requirements for Internet-Accessible Systems (April 29, 2019), and BOD 22-01: Reducing the Significant Risk of Known Exploited Vulnerabilities (Nov. 3, 2021).' Anything still citing BOD 22-01's flat remediation-due-date model as the current federal directive, as of last verification, is describing a revoked instrument, not the current one. This page does not treat BOD 22-01 as current law.

BOD 26-04 replaces a KEV-only due-date model with a risk-tiered one built on four decision variables, stated directly in CISA's published text: (1) Asset Exposure — is the vulnerable asset publicly exposed; (2) KEV Status — is the CVE on CISA's Known Exploited Vulnerabilities catalog; (3) Exploit Automation — can an adversary automate all steps needed to exploit it; (4) Technical Impact — does successful exploitation give an adversary partial control or total control of the asset. CISA states that Table 1: Remediation Timelines, which maps combinations of those four variables to specific deadlines, is 'informed by the SSVC system' (Stakeholder-Specific Vulnerability Categorization).

Table 1: what CISA publishes, and what this page does not invent

CISA's directive text states the shape of Table 1 without embedding it as extractable text on the page — CISA's own page notes 'Table 1 is equivalent to the following figure,' i.e., it ships as a graphic in Appendix A, not as inline statute language this page can quote cell by cell from a primary source. This page does not invent day-counts for that table. Anyone applying BOD 26-04 should read Table 1 directly from CISA's published directive or Implementation Guidance, not from a secondary summary, including this one.

Independently, several named third-party technical analyses of the directive (including CERT/CC's own SSVC decision-model documentation, and vendor write-ups from Datadog and Tenable) describe the same general shape and converge on matching values: a small number of tiers running from 'fix on next scheduled system upgrade' (when none of the four risk criteria are met) up to 'three days, with mandatory forensic triage' (when a CVE is on KEV and grants total control of the asset). CISA's own text confirms the outer bounds of that shape directly: Phase III requires agencies to 'remediate each vulnerability as quickly as possible and no later than the timelines set forth in Table 1,' within 180 days of the directive's issuance, and 'fix on system upgrade' is CISA's own defined term for the deferral tier meaning 'the vulnerability should be remediated the next time the vulnerable asset receives a scheduled major upgrade or rebuild.' This page presents that shape as reported by those named analyses, not as a direct transcription of Table 1's cells, and it does not apply any specific day-count to YOUR asset.

CISA's own text also states when the clock starts: 'The timelines defined in Table 1 begin when either (1) CISA adds the vulnerability to the KEV Catalog, or (2) pursuant to BOD 23-01, the agency enumerates or identifies the vulnerability on an asset and updates the Continuous Diagnostics and Mitigation (CDM) Program Agency and Federal Dashboard. Whichever event occurs first starts the remediation timeline.' Timelines are also stated as dynamic: removing a system from the internet can push a deadline back by changing the Asset Exposure answer to 'No,' while a later KEV addition for a vulnerability not previously listed shortens the timeline going forward.

• Phase I (effective immediately from 10 June 2026): update vulnerability management policies, monitor the KEV catalog, automate CDM reporting or report bi-weekly, continue Cyber Hygiene scanning, and quarterly attest publicly exposed IPs and domains.
• Phase II (within 60 days of issuance): update vulnerability management processes to remediate based on the full CVE database plus the KEV catalog, not KEV alone.
• Phase III (within 180 days of issuance): remediate per Table 1's timelines, continuously tag internet-reachable assets, and report status to CISA every 7 days if not fully automated via CDM.
• This page does not run YOUR asset through Table 1 and does not start a Phase I, II, or III clock.

PCI DSS v4.0.1: honest text, not a round number

PCI DSS v4.0.1 (published June 2024) is a maintenance release that reverted Requirement 6.3.3 to language closer to PCI DSS v3.2.1: only critical vulnerabilities carry the standard's 30-day patch-installation clock. The v4.0 draft language extending that same one-month clock to 'high-security' patches was removed. Requirement 6.3.3, as currently published, requires that critical or high-security patches/updates — 'identified according to the risk ranking process at Requirement 6.3.1' — be installed within one month of release, and that all other applicable security patches/updates be installed within an appropriate timeframe the entity itself determines and documents, based on its own assessment of the criticality of the risk the patch addresses. This page does not invent a 90-day figure for 'high' severity; the standard, as revised, does not set one.

Requirement 11.3 covers vulnerabilities found by internal and external scanning rather than vendor-published patches: Requirement 11.3.1 requires resolving vulnerabilities ranked 'critical or high-risk' (per the entity's own Requirement 6.3.1 risk-ranking process), with a defined rescan-until-clean cycle, and Requirement 11.3.1.1 requires addressing all other, lower-ranked vulnerabilities per the entity's own targeted risk analysis and documented remediation policy. PCI DSS does not hand down a universal day-count for either 'high' patches under 6.3.3 or lower-ranked scan findings under 11.3 — it hands the entity a documented, risk-based process it must build, follow, and be able to show an assessor.

NIST SP 800-40r4 and ISO/IEC 27001:2022 A.8.8: process, not a clock

NIST SP 800-40 Revision 4, 'Guide to Enterprise Patch Management Planning: Preventive Maintenance for Technology' (published April 2022), recommends that leadership, business/mission owners, and security teams jointly build an enterprise patching strategy that is risk-tiered rather than uniform. It is planning guidance, not a directive, and it does not itself mandate a specific number of days for any severity tier — it is commonly used as the methodology behind an organization's own SLA tiers, which the remediation-SLAs guide on this site covers.

ISO/IEC 27001:2022 Annex A control 8.8, Management of technical vulnerabilities, states: information about technical vulnerabilities of information systems in use shall be obtained, the organization's exposure to such vulnerabilities shall be evaluated, and appropriate measures shall be taken. That control is deliberately technology- and timeline-neutral — it does not name a scanner, a CVE feed, or a day-count. What an ISO 27001 auditor checks is whether the organization has a running, evidenced process: how it learns about new vulnerabilities, how it evaluates exposure, and how it decides and records a remediation action (patch, compensating control, or documented risk acceptance) for each one.

What to do now

This page does not determine which of the above applies to YOUR organization or set YOUR remediation windows. Walk this with the person who owns your security program and, where a contractual or legal question is genuinely live, with counsel or your QSA.

• Confirm whether your organization is an FCEB agency (BOD 26-04 applies directly), a federal contractor whose contract incorporates it, or neither. This page does not run that test.
• If you accept payment cards, confirm your current PCI DSS attestation level and whether your assessor treats any patch class as critical beyond what Requirement 6.3.1's own risk-ranking process names. Do not assume a 90-day figure for 'high' severity exists in the current standard.
• If neither BOD 26-04 nor PCI DSS applies, you are in the majority: build your own risk-based SLA tiers using NIST SP 800-40r4 as planning guidance and ISO/IEC 27001:2022 A.8.8 as the audit lens, and document them. The remediation-SLAs guide on this site is the template for that step.
• Do not cite BOD 22-01's flat 14-day KEV due-date model as current federal policy; CISA revoked it on 10 June 2026 when BOD 26-04 issued.
• Do not quote a specific PCI DSS day-count for 'high' severity patches without checking the currently published Requirement 6.3.3 text; v4.0.1 removed that language.

Where this shows up in ShipReady Metrics

Signed-in app → Security → Findings tracks each finding's age against a remediation SLA tier the organization configures for itself — it does not apply BOD 26-04's Table 1, PCI DSS's requirements, or any other regulatory clock automatically, because none of those texts apply universally. This product does not patch anything and does not decide which legal or contractual regime binds your organization. A named human on the team sets the SLA tiers and owns the remediation decision.

This page does not document a public product demo path.

Primary sources (last verified 10 September 2026)

CISA's published web text of Binding Operational Directive 26-04, 'Prioritizing Security Updates Based on Risk' (issued 10 June 2026, superseding and revoking BOD 19-02 and BOD 22-01), including its Background, Scope, Phase I-III requirements, and Appendix A description of Table 1: Remediation Timelines. PCI Security Standards Council, PCI DSS v4.0.1 (June 2024), Requirements 6.3.1, 6.3.3, 11.3.1, 11.3.1.1, and 12.3.1, and the Council's own summary of changes from v4.0 to v4.0.1. NIST Special Publication 800-40 Revision 4 (April 2022). ISO/IEC 27001:2022 Annex A, control 8.8. Third-party technical analyses of BOD 26-04's Table 1 shape and values (CERT/CC's SSVC decision-model documentation for BOD 26-04, and vendor write-ups) are cited as secondary sources, not as a substitute for CISA's own Table 1 graphic. Not legal advice. These are not a complete list of every applicable regime (state breach laws, sector-specific rules, and individual customer contracts can each layer on additional obligations this page does not cover).

The exploitability-vs-severity guide, the what-is-KEV guide, the remediation-SLAs guide, and the prove-remediation guide on this site are the closest related pages.

Frequently asked questions