Which vulnerability scanning and patching deadline should decide your program
A team subject to more than one regime should let the shortest fixed clock set its patch cadence, because an open timeframe can absorb a slower process but a missed fixed deadline is a clear breach. The fixed clocks in the supplied sources are PCI DSS Requirement 6.3.3, which in v4.0.1 applies the one-month (30-day) installation timeframe to critical patches, the Essential Eight 48-hour window for online services when the vendor rates a flaw critical or a working exploit exists, and NERC CIP-007-6 Part 2.2, which requires evaluating security patches for applicability at least once every 35 calendar days. The open timeframes are NIS2's reasonable time, which sets no day count, and the proposed HIPAA rule's automated vulnerability scans at least every six months. The strictest published clock usually sets the operating cadence, and the choice depends on which regimes apply to your entities, not on which framework is preferable.
Applicability decides which clock governs which asset. Ask whether cardholder data environment systems, bulk electric system assets, Australian government obligations or in-scope EU entities reach your estate, and document the answer for each business unit. The scope boundary also changes the clock. PCI DSS 6.3.3 covers critical patches only, so other patches run on a timeframe the entity sets, and the Essential Eight window applies to online services rather than to every internal host. Confirm each applicability question with the relevant assessor, regulator or counsel, and confirm the versions in force on your assessment date, since the PCI SSC has announced no release date for a new version of the standard.
Turn the clocks into one operating plan. Map each asset to its strictest applicable patch window, then check whether your change process can meet 48 hours for internet-facing services and whether a 35-day evaluation cycle fits your advisory intake. Record scan frequency for each regime separately, because an auditor tests each one against its own text, and a quarterly internal scan that satisfies one requirement may not evidence another. Treat the six-month HIPAA scan as a floor to confirm against your own risk analysis, since the proposed rule also allows more frequent scans. The result is a single program with several documented clocks, each traceable to the regime that sets it.
How each framework sets scan frequency and patch windows
This table compares how seven frameworks set scan frequency and patch timing, who sets the clock, and what proof each expects. Read across a row to see whether a deadline is fixed in days or months, or left to the entity or regulator to define.
| Framework | Scan frequency | Patch window | Who sets the timeframe | Evidence expected |
|---|---|---|---|---|
| PCI DSS v4.0.1 (applies to cardholder data environments and service providers) | External ASV scans and internal scans at least every three months (11.3.1, 11.3.2) | Critical patches within one month; other patches within an entity-defined timeframe (6.3.3) | PCI SSC sets the one-month critical window; the entity sets the rest | ROC or SAQ with AOC; scan reports from an ASV for external scans |
| CIS Controls v8.1 (voluntary, any enterprise) | Automated internal scans of enterprise assets at least quarterly, authenticated and unauthenticated (Safeguard 7.5) | No fixed day count in Safeguard 7.5; patching is handled under other Safeguards | The organization sets its own patch timing against its risk | Scan records and CIS Controls Assessment Specification measures if you map to it; no certificate |
| Essential Eight (Australian government and organizations adopting ASD guidance) | Scanning is handled through the ISM controls for the maturity level in scope | Online-service patches or vendor mitigations within 48 hours when rated critical or a working exploit exists; otherwise within two weeks | ASD sets the windows in the ISM | Maturity assessment against the model for each strategy; there is no ASD certificate |
| NERC CIP-007-6 Part 2.2 (bulk electric system entities) | Not a scan cadence; evaluation of security patches is the requirement | Evaluate applicability of security patches at least every 35 calendar days, then act on the evaluation within the standard's timeframes | The standard sets the 35-day evaluation cycle | Patch source list, evaluation records and dated decisions for audit |
| NIS2 (EU essential and important entities) | No fixed scan frequency in the Directive; scans are a supervisory tool (Article 32) | Reasonable time; no day count in the Directive | Each entity sets a risk-based timeframe; national authorities judge it | Documented risk-based policy, supervisory inspections and security scan results on request |
| CMMC Level 2 and Level 3 (DoD contractors handling CUI) | Periodic activities such as risk assessments and vulnerability scans must recur at intervals no longer than one year under 32 CFR 170.14(d) | Patch timing follows the NIST SP 800-171 requirements the contractor implements | The contractor sets intervals, capped at one year for periodic activities | Assessment by a C3PAO (Level 2) or DCMA DIBCAC (Level 3); affirmation by a senior official |
| HIPAA Security Rule (proposed rule, not final) | Proposed: automated vulnerability scans at least every six months, or more often per risk analysis | No patch day count in the proposed text; confirm against the final rule | HHS would set the scan floor; the entity sets the risk-based rest | Scan records and risk analysis documentation; HHS does not certify compliance |
What changes the deadline you actually have to meet
The same vulnerability can carry different deadlines depending on the regime you answer to, the asset it sits on and who sets the timeframe. Check these drivers in order before you copy any single number into a policy.
Which regime applies
Cardholder data, bulk electric system assets, EU essential or important entity status, DoD contracts and ePHI each bring their own patch or scan rule. A system can fall under more than one regime, and the strictest applicable clock usually governs the shared platform. Confirm scope with the payment brands, your NERC registration, your national competent authority, your contracting officer or your counsel before you pick a window.
Fixed day count or reasonable time
Some frameworks fix a number of days, while others only require application within a reasonable time. NERC CIP-007-6 requires evaluating security patches for applicability at least once every 35 calendar days, but NIS2 sets no patch deadline in days and leaves the measure of reasonable time to the entity and its authority. Write down how you justify your interval so an assessor can test it.
Asset class in scope
Internal enterprise assets, online services and the cardholder data environment often sit under different clocks. The CIS Controls require automated internal scans at least quarterly, while the Essential Eight sets 48-hour windows for online services when a vendor rates a flaw critical or a working exploit exists. Map each asset class to its requirement in your inventory so one ticket does not get the wrong deadline.
Vendor severity and working exploits
Some regimes move the deadline when the vendor rates a flaw critical or when a working exploit is public, not on a fixed calendar. Under the Essential Eight, that trigger shortens the window for online services to 48 hours. Your intake process should record the vendor rating and exploit status on arrival, because the clock may start from that data rather than from the date you opened the ticket.
Entity-set timeframes and the PCI critical window
PCI DSS v4.0.1 limited the one-month installation timeframe in Requirement 6.3.3 to critical vulnerability patches, and other patches now fall within a timeframe the entity determines. The HIPAA six-month scan interval is only proposed in 45 CFR 164.312, so treat it as a planning target until the rule is final. Document the risk analysis that justifies any entity-set window, since an assessor will ask for it.
How the scanning and patching clocks stack in one program
A single program can run several cadences at once, and the clocks rarely collide as long as each one is mapped to a specific control. The quarterly scan cycle is the easiest to share. PCI DSS requires external ASV scans and internal scans at least every three months (11.3.1, 11.3.2), and CIS Safeguard 7.5 requires automated internal scans at least quarterly, covering both authenticated and unauthenticated scans. Scheduling one quarterly run that is authenticated, covers the cardholder data environment and the internal enterprise assets in scope, and produces one exportable result set lets the same evidence answer both assessors. Confirm with your QSA whether the ASV scan must stay a separate engagement, because the internal and external scans have different owners and rules.
Patching runs on a faster clock. PCI DSS v4.0.1 applies the one-month (30-day) installation window to critical vulnerability patches only, so your triage must classify every finding by severity every month at minimum. NERC CIP-007-6 Part 2.2 asks for applicability evaluation at least once every 35 calendar days, which is a different obligation with a different start point. A monthly triage meeting that records the source, date, severity and applicability decision for each advisory can serve both clocks, but only if the bulk electric system and cardholder environments are tagged separately in the inventory. Where an online service is involved, add a separate lane: Essential Eight ML1 expects patches or vendor mitigations for online services within 48 hours when the vendor rates the flaw critical or a working exploit exists. That lane needs its own owner, on-call path and change approval, because a monthly cycle cannot meet it.
What makes one cadence defensible to several auditors is a shared asset inventory and one severity scheme. Each asset needs an owner, a classification, and tags for every regime that touches it, so that a single scan result can be traced to the right PCI, CIP or Essential Eight scope. A common severity model also prevents the same flaw from being rated critical in one report and high in another. Before you commit to a schedule, ask each assessor to confirm in writing which assets and environments fall in scope, how exceptions are documented, and which evidence they will accept from the other regimes. Scope overlap is the assumption most likely to fail at audit time, so confirm it early rather than after the first quarterly run.
How to confirm your own scan and patch cadence
This sequence turns the scan and patch clocks in each applicable regime into a measured baseline for your own estate, so you can see which deadline your current practice would fail first and what to confirm with your assessor or regulator.
List every regime that applies to you
Start with a written list of each framework, regulation or contract that reaches your systems, such as PCI DSS for cardholder environments, CIS Controls for internal policy, Essential Eight for Australian operations, NERC CIP for bulk electric system assets, NIS2 for EU essential or important entities, CMMC for defense supply chain work, or the proposed HIPAA Security Rule if it is finalized. Name the owner who confirmed each one with legal or compliance. The output is a signed list with the applicability basis written beside each entry, so later steps do not rely on memory.
Map each regime to its scan and patch clock
For each regime on the list, record the scan frequency and patch window exactly as the governing text states it, using the supplied figures where they exist. Mark which clocks are fixed (for example quarterly scans under PCI DSS or a 35-day evaluation cycle under CIP-007-6), which are severity-based (for example the 48-hour and two-week windows in the Essential Eight), and which are open-ended (for example the reasonable-time standard in NIS2 or the entity-determined timeframe for non-critical patches under PCI DSS v4.0.1). The output is a single table with one row per regime and one column for the tightest clock that applies to each asset class.
Inventory assets by each regime's scope
Build an asset inventory for each regime, because the scope definitions differ. PCI DSS scopes the cardholder data environment and systems that could affect it, CIS Safeguard 7.5 scopes internal enterprise assets, NERC CIP scopes BES Cyber Systems, and CMMC scopes systems that handle controlled information. Tag each asset with the regimes it falls under and its owner, and record which assets are online services, since the Essential Eight treats those differently. The output is a tagged inventory that shows the assets each clock must cover, with gaps flagged for asset owners to resolve.
Measure time from vendor release to applied patch
Pull patch records from your ticketing, configuration management and deployment tools for a representative period, and calculate for each severity class the elapsed time between the vendor release date and the date the patch was applied in production. Separate online services from endpoints and servers, and record vendor mitigations applied in place of patches. Exclude nothing silently, and note any exceptions with their approvals. The output is a per-severity table of measured elapsed times, with the sample period and data sources written on the page so the figures can be reproduced.
Measure scan coverage and cadence
Check the scanner configuration and scan history for each asset tag, recording the date of each completed authenticated and unauthenticated scan, the scan type (internal, external, or ASV-approved for PCI DSS), and any assets that were skipped or out of scope. Compare the intervals between scans against each regime's frequency. The output is a coverage report showing, per regime, the longest gap between completed scans and the assets missing from that cycle.
Compare measured times against the tightest clock
For each asset class and severity, set the measured elapsed time beside the tightest applicable clock from step two. Where a fixed clock applies, the comparison is direct. Where a clock is open-ended, record your own documented timeframe and check whether it is justified in writing and applied consistently. Flag every case where the measured time exceeds the clock, and every case where a regime requires a process you cannot show in records. The output is a gap register with each entry tied to a regime, an asset group, a measured value and an owner.
Confirm accepted timeframes with the assessor or regulator
Take the gap register and the documented timeframes to your assessor, such as the Qualified Security Assessor for PCI DSS, your CMMC assessor, or the national competent authority for NIS2, and ask them in writing which intervals they accept, how they treat entity-defined timeframes and what evidence they expect to see. For CIS Controls, which the CIS does not present as a regulatory scheme, confirm internally what your customers or contracts require. Record each answer with its date and the name of the person who gave it. The output is a written confirmation per regime that replaces assumptions with accepted positions, and a remediation plan for any gap the reviewer will not accept.
Which timeframe applies to which environment
PCI DSS v4.0.1 is the active version and applies to entities that store, process or transmit cardholder data, or that could affect the security of the cardholder data environment. For scanning, Requirements 11.3.1 and 11.3.2 call for external ASV scans and internal scans at least every three months. For patching, the one-month (30-day) installation timeframe applies to critical vulnerability patches, while other patches fall within a timeframe the entity sets. Proof comes from a Report on Compliance completed by a Qualified Security Assessor, or a Self-Assessment Questionnaire, each closed with an Attestation of Compliance. A certificate is not accepted as validation.
- Scan cadence: quarterly external ASV scans and internal scans, with penetration tests at least every 12 months.
- Critical patches: installed within one month under Requirement 6.3.3 as revised in v4.0.1.
- Other patches: the timeframe is set by your own documented process, so write it down and show evidence you follow it.
- Who decides: the payment brands set which entities must validate and run enforcement, not the PCI SSC.
- Assessor relationship: a QSA may reuse SOC 2 evidence only after independent review.
Confirm with your acquirer or payment brand which validation level and form applies to you, and ask your QSA how they will evaluate your custom patch timeframe.
For the North American bulk electric system, NERC CIP-007-6 Part 2.2 requires evaluating security patches for applicability at least once every 35 calendar days, drawing on identified sources. The evaluation cycle is the fixed clock here, and the standard's patch application obligations follow from that evaluation. Enforcement and audit sit with the regional entity and the regulator rather than a certificate body, so the evidence is the records your auditor reviews during a compliance audit. Keep dated source lists, evaluation records and the reasoning behind each decision.
- Evaluation clock: every 35 calendar days, from the sources you identify.
- Records: dated evaluations, decisions to apply, mitigate or defer, and the reasons.
- Scope: systems in scope for the CIP standards, which often differ from the wider IT estate.
- Vendor sources: list the vendor and advisory feeds you rely on so the evaluation has a traceable input.
- Proof: an audit by the regional entity, not a certificate.
Confirm with your regional entity how it expects evaluation evidence to look, and confirm which assets fall under which impact category before you set the scan and patch schedule.
NIS2 does not set a patch deadline in days. Article 21 expects measures proportionate to risk, and the implementing rule for certain entities provides the detailed expectations, which ENISA's technical guidance discusses. Under the Directive, patches must be applied within a reasonable time. Compliance is not certified. National competent authorities supervise through inspections, security audits, security scans, information requests and administrative fines (Articles 32 to 34). Because the clock is open-ended, your documented justification for each timeframe is the evidence a regulator will test.
- Patch clock: a reasonable time, set by risk and documented, rather than a fixed number of days.
- Scanning: keep scan records that show you meet your own stated frequency.
- Supervision: inspections, audits, scans and information requests from the national authority.
- No certificate: there is no NIS2 certificate to show a customer or regulator.
- Sector rules: DORA applies to financial entities and may set its own ICT expectations on top.
Confirm with your national competent authority how it interprets reasonable time for critical and internet-facing systems, and confirm whether your sector adds rules that tighten the clock.
Under the CMMC Program in 32 CFR Part 170, any interval described as periodic, including risk assessment and vulnerability scanning cycles, is capped at one year. That cap sets the outer limit, but it does not replace your own shorter cadence for scans and patches, which the assessor will compare against your stated practice. Level 2 certification assessments are performed by C3PAOs authorized or accredited by The Cyber AB, and Level 3 assessments are performed by DCMA DIBCAC. The result is a certificate tied to the level you were assessed at, and the affirming official signs the status.
- Outer limit: no periodic scanning or assessment interval may exceed one year.
- Your cadence: set and document a shorter schedule and show that you follow it.
- Level 2 proof: a C3PAO assessment and certificate, with affirmation over time.
- Level 3 proof: a DCMA DIBCAC assessment.
- Flowdown: subcontractors and cloud providers in scope need their own evidence.
Confirm with your C3PAO or DIBCAC which level your contract requires, and ask how they will judge a scan interval you set below the one-year cap.
The HIPAA Security Rule does not set a scan or patch clock in the final rule, and HHS has stated there is no HIPAA certification. A proposed rule would require automated vulnerability scans at least once every six months, or more often according to your risk analysis. That is a proposal, not an obligation, so confirm its status before you rely on it. Your proof is your own documentation of risk analysis and risk management, which an HHS investigation could test. Any third-party certification you hold does not prevent HHS from later finding a violation.
- Current rule: no fixed scan or patch interval in the final Security Rule text.
- Proposed rule: automated scans at least every six months, or more often by risk analysis.
- No certificate: HHS does not endorse or recognize private certifications.
- Your evidence: risk analysis, scan records, and dated patch decisions.
- Contracts: business associate agreements may set stricter clocks than the regulation.
Confirm with your counsel or compliance lead whether the proposed rule has been finalized, and confirm any scan or patch terms your business associates expect in their contracts.
Questions buyers ask about scan and patch deadlines
How much does a scanning and patching program cost to run?
No single figure applies, because cost follows the scope you set: how many assets, how many frameworks, and how many change windows you must meet. The main components are scanning tool licences or subscriptions (recurring), staff time to triage findings and test patches (recurring), a one-time setup of the asset inventory and scan policies, and assessor review when an external auditor or QSA checks the evidence. Quarterly external ASV scans under PCI DSS and monthly critical patch windows drive the most recurring effort. Ask any provider for a written quote that separates one-time setup, recurring operations and any third-party assessment fees, and state which tools the quote includes and which you already own.
Can an internal team run scanning and patching deadlines alone?
Often yes, if the team has an accurate asset inventory, a tested change process and enough capacity to meet the shortest deadline on the list. The hardest part is usually not running the scanner but keeping the cadence: scans on time, findings triaged, patches tested and deployed inside the windows, and evidence kept for each cycle. An internal team should check whether it can meet the 48-hour Essential Eight window for critical online-service patches or the 30-day PCI DSS window for critical patches without pulling staff from other work. If the answer is uncertain, a fixed-scope review of the current process is a lower-risk first step than a full outsourced program.
How long does it take to put a scanning cadence in place?
Duration depends on the size of the environment, the state of the asset inventory and how many frameworks the cadence must satisfy, so no general timeline applies. Ask for a written scope and timeline before work starts, covering the inventory, tool configuration, the first full scan cycle, the change-window agreement and the evidence pack. A reasonable quote states which milestones the client must sign off and which depend on access and approvals the client provides. Be cautious of any timeline that is not tied to a defined scope.
What does the work need from our organization?
Three things decide whether a cadence works: a current asset inventory, change authority and access. The inventory must list the devices, software and online services in scope, because a scan cannot cover assets nobody knows about. Change authority means someone can approve emergency patches inside a 48-hour or 30-day window without a multi-week board cycle. Access means scanner credentials for authenticated scans, administrative rights or agent deployment where the framework expects them, and access to the systems that receive patches. Confirm each of these with your change board and security operations lead before you commit to a deadline.
Does a certificate prove we meet scanning and patching requirements?
No. For PCI DSS, compliance is documented on a Report on Compliance or a Self-Assessment Questionnaire with an Attestation of Compliance, and the PCI Security Standards Council states that certificates are not recognized as validation. The Essential Eight has no ASD certificate at all, because maturity is evidenced by assessing each strategy against the maturity model. HHS states that no HIPAA Security Rule standard requires certification, and it does not endorse private certifications. Use the framework's own evidence type, and ask an assessor or regulator which artifacts they will accept before you start.
How do we reconcile a 35-day NERC cycle with a PCI monthly window?
Run them as separate control objectives with one shared patch pipeline rather than trying to merge the clocks. NERC CIP-007-6 Part 2.2 requires evaluating security patches for applicability at least once every 35 calendar days, while PCI DSS requires critical patches to be installed within one month under v4.0.1. Evaluation and installation are different steps, so a single 35-day evaluation cycle can still feed a monthly critical installation window if your process sets the earlier date. Map each patch to the strictest applicable deadline, record the evaluation date and install date separately, and have your NERC and QSA contacts confirm the approach in writing.
Which deadline should we plan around if several frameworks apply?
Plan around the shortest deadline that applies to each asset, not the average across frameworks. Where critical patches must go in within 48 hours under the Essential Eight, that rule governs online services in scope, while PCI DSS allows one month for critical patches and NIS2 requires only a reasonable time. Where a framework sets no day count, such as NIS2 or the CIS Controls, document how you decided what counts as reasonable and keep that decision under review. Confirm with each regulator or assessor which deadline they will test.
Where teams misread the deadlines
The most frequent misreading is treating PCI DSS as a one-month rule for every patch. Requirement 6.3.3 in PCI DSS v4.0.1 applies the one-month (30-day) installation timeframe to patches for critical vulnerabilities only. Other patches are installed within a timeframe the entity determines, and that timeframe should be written into your patch policy and shown to the assessor. Confirm with your QSA which version your assessment is validated against, because v4.0.1 is the only active version and earlier versions are retired. Also confirm whether the PCI SSC's request for comments on the next iteration has produced a release date before you lock in a policy.
The second misreading is assuming the HIPAA six-month vulnerability scan is already binding. It is not. The six-month scan appears in a proposed rule (proposed 45 CFR 164.312(h)(2)(i)(A)), and the proposed text would also allow more frequent scans based on your risk analysis. Until a final rule is published, the existing Security Rule does not set a scan interval, so teams should record the proposal as a planning assumption and confirm its status with counsel or HHS. Similarly, NIS2 asks for a reasonable time to patch, not a fixed number of days. Treating that phrase as a hidden 30-day or 14-day rule will produce policies that regulators may judge differently from your own documented risk decisions. Ask your national competent authority how it reads reasonable time for your sector.
The last misreading is treating Essential Eight maturity as a certificate. ASD issues no certificate for the Essential Eight. Maturity is shown by assessing each strategy's implementation and effectiveness against the maturity model, and the ML1, ML2 and ML3 profiles in the current ISM release describe what each level expects. If a customer or board asks for proof, present an assessment record for each strategy and confirm the current maturity model release on the ASD Essential Eight page before you plan the next cycle.
How DeployOpen helps plan and implement one scanning and patching cadence
DeployOpen plans and implements self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For vulnerability scanning and patching deadlines, we help you map each framework's scan frequency and patch window onto one cadence that your team can run and evidence.
How we scope
- Inventory which frameworks apply and which scan and patch clocks each one sets for your systems
- Agree in writing which platforms, asset classes and environments the cadence covers
- Define which scan types, patch sources and evidence records each team owns before work starts
How we build
- Configure scheduled scans and patch workflows in your environment to match the agreed cadence
- Set up separate handling for critical patches so the shortest applicable window is met first
- Test the configured schedules and alerts in a non-production environment before they go live
How we hand over
- Document the cadence, owners, escalation paths and the framework clause each step supports
- Deliver runbooks for scan review, patch approval, exceptions and rollback
- Provide evidence templates so your auditors or assessors can trace each scan and patch record
How we support
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing first
- Ongoing support, upgrades and continuous testing are available as a retainer
- Confirm with your assessor or auditor which interval wording they will accept for your framework
Sources and further reading
- PCI DSS v4.0 Self-Assessment Questionnaire D for Service Providers (PCI SSC) ↗
- PCI SSC blog: Just Published: PCI DSS v4.0.1 ↗
- CIS Controls Assessment Specification for Controls v8.1: Safeguard 7.5 ↗
- NERC: CIP-007-6, Cyber Security: System Security Management (standard PDF) ↗
- Essential Eight Maturity Model (November 2023), ASD ↗
- PCI SSC FAQ 1220: compliance certificates ↗
