Teams preparing for an audit often ask what remediation timelines an auditor will accept. The honest answer is that, outside PCI DSS, the auditor will mostly accept the timelines you set. What they will not accept is a policy you did not follow.
That changes the question. The work is not finding the "right" number of days for a critical vulnerability. It is setting severity tiers and windows that fit your environment, writing them down precisely, meeting them, and handling the cases where you cannot.
This article covers what auditors test, what the frameworks say, how to design severity tiers and windows, how to handle exceptions, the evidence to keep, and the mistakes that turn a reasonable program into a finding.
What an auditor is testing
An auditor testing vulnerability management asks three questions:
Do you find vulnerabilities across the in-scope environment? They will look at scanner coverage and scan frequency.
Do you classify them consistently? They will look at how severity is assigned and who can change it.
Do you fix them within the windows your policy states? They will take the population of findings from the period, sample them, and compare detection date with remediation date.
The third question produces most exceptions. A policy that commits to fixing critical findings in seven days, and a sample where several took a month, is a finding regardless of whether a month was reasonable.
What the frameworks say
Only one major framework sets a specific remediation window.
PCI DSS v4.0 Requirement 6.3.1 requires vulnerabilities to be identified from recognized sources and given a risk ranking. Requirement 6.3.3 requires patches for critical vulnerabilities to be installed within one month of release, with others on a timeline set by your own risk assessment. Requirement 11.3.1 requires internal vulnerability scans at least once every three months, with high-risk and critical findings resolved and rescanned, and 11.3.2 requires quarterly external scans by an Approved Scanning Vendor. If you are new to the v4.0 changes, what changed in PCI DSS 4.0 sets them out.
SOC 2 CC7.1 covers detection and monitoring procedures to identify configuration changes that introduce vulnerabilities and susceptibility to newly discovered ones. Timelines are yours to set.
ISO 27001:2022 Annex A 8.8 covers obtaining information about technical vulnerabilities, evaluating exposure, and taking appropriate measures. Timelines are yours to set.
NIST SP 800-53 Rev. 5 RA-5 covers vulnerability monitoring and scanning, and SI-2 covers flaw remediation within organization-defined time periods.
The HIPAA Security Rule does not name vulnerability management, but its risk analysis and risk management requirements make unaddressed known vulnerabilities hard to defend.
For card data environments, our PCI DSS overview is the place to start.
Designing severity tiers
Most scanners report a severity based on the Common Vulnerability Scoring System (CVSS). That score describes the vulnerability in general, not its risk in your environment. Use it as the starting point, then adjust with rules you write down.
Two adjustments do most of the work:
Exposure. A critical finding on an internet-facing service is more urgent than the same finding on an isolated build host. Define what "exposed" means for you: internet-reachable, handles customer data, or in the payment flow.
Known exploitation. A vulnerability listed in CISA's Known Exploited Vulnerabilities catalog, or one with public exploit code, deserves a faster window than its base score suggests.
Write the adjustment rules into the policy, and record who changed a severity and why. A downgrade with no reason attached looks, to an auditor, like a way to avoid a deadline.
Choosing remediation windows
There is no industry standard set of windows. The table below is an example of the shape many policies take, offered as a starting point to adjust rather than as a benchmark.
| Severity after adjustment | Example window |
|---|---|
| Critical | 7 to 15 days |
| High | 30 days |
| Medium | 90 days |
| Low | 180 days, or next scheduled maintenance |
Three decisions matter more than the numbers:
When the clock starts. From first detection by your scanner, from your triage decision, or from the vendor's patch release. PCI DSS measures from release for critical patches. Pick one, state it, and use it consistently.
What "remediated" means. A deployed fix confirmed by a rescan, a configuration change, or a compensating control. A ticket marked done is not remediation.
What is in scope. Operating systems, container images, application dependencies, cloud configuration, and endpoints may each have different scanners and different owners. Say which windows apply to which.
Every finding also needs an owner. Assign ownership by asset or service, not by whoever happens to look at the scanner, so a new finding lands with the team that can fix it on the day it is detected. Findings without an owner age quietly, and they are the ones that turn up past their window in a sample. Where a finding spans several teams, such as a vulnerable base image used across services, name one owner for the fix and let them coordinate.
Set windows you can meet on your worst normal month, not your best. A seven-day critical window that your team hits most of the time will still produce exceptions in a sample.
Exceptions and risk acceptance
Some findings cannot be fixed in the window. The vendor has not released a patch, the fix breaks a dependency, or the system is being retired next quarter. That is normal. What matters is that the exception is a decision, not an accident.
For each exception, record:
The finding and the affected assets
Why it cannot be remediated within the window
The compensating control, such as a firewall rule, a feature flag, or increased monitoring
Who approved the exception, at a level your policy defines
An expiry date, after which the exception is reviewed again
This is risk acceptance in the formal sense, and it should connect to your risk register. Risk treatment options covers how acceptance differs from mitigation and who should sign off on it. An auditor who finds an overdue finding with an approved, unexpired exception generally treats it as the process working.
The evidence to keep
Vulnerability management evidence is mostly system-generated, which makes it strong if you keep it.
- Not done:
The policy, with severity definitions, adjustment rules, and windows
- Not done:
Scanner configuration showing scope and frequency
- Not done:
Scan results for each cycle, dated
- Not done:
The population of findings for the period, with detection date, severity, owner, and remediation date
- Not done:
Rescan results confirming closure
- Not done:
The exception register, with approvals and expiry dates
- Not done:
An aging report showing open findings against their windows
Expect the auditor to sample from the findings population. How auditors sample controls explains how the sample is drawn. The population needs to be complete: findings closed quickly still belong in it.
Mistakes that create findings
Windows tighter than reality. Aspirational SLAs reliably produce exceptions in a sample.
Severity changed without a record. Every change needs a reason and a name.
Partial coverage. Scanning servers but not container images, or production but not the build pipeline that produces it.
Tickets closed without verification. Closure should come from a rescan or the system, not the assignee.
Exceptions without expiry. An exception approved two years ago and never revisited is an unmanaged risk with a signature on it.
How TrustLynce helps
TrustLynce continuous monitoring runs control checks against the systems you connect and routes failures to their owners, so findings that are approaching or past their window are visible while there is still time to act or record an exception.