Patch Management Compliance: Building a Patching Process Auditors Accept

Short answer: Patch management compliance means you can show an auditor a written policy, a complete inventory of what you patch, risk-based deadlines by severity, records that patches were tested and deployed on time, and documented exceptions with compensating controls. Most frameworks do not set one universal deadline, so your own SLAs, and your evidence of meeting them, carry the weight.

Related guides:

• How to write a vulnerability management policy
• How often should you run vulnerability scans?
• Open source software risks and how to manage them

Key takeaways

• Auditors generally care less about whether you are "fully patched" than about whether you follow your own documented process, and whether every late patch has an approved exception.
• Scope is wider than operating systems. Include endpoints, cloud machine images, container base images and third-party libraries in your code.
• Set patching SLAs by severity and exposure. PCI DSS is one of the few frameworks with a fixed number: critical patches within one month of release.
• Treat exploitation in the wild as an accelerator. CISA's Known Exploited Vulnerabilities (KEV) catalog is a practical signal, even though CISA's directives bind only federal agencies.
• HIPAA does not name a patching deadline today. OCR ties patching to your risk analysis and risk management, and a Security Rule update proposed in January 2025 includes a patch management standard; check HHS for its current status.

---

What does patch management compliance actually mean?

It means your patching is defined, repeatable and provable, not that every system is on the latest version every day.

NIST SP 800-40 Rev. 4, published in April 2022, describes enterprise patch management as identifying, prioritizing, acquiring, installing and verifying patches, updates and upgrades across an organization. It frames patching as preventive maintenance, a normal cost of running technology rather than an emergency activity.

An auditor looks for what any recurring control needs: a policy with scope, owners, deadlines and an exception path; an inventory; a trigger such as vendor advisories, scanner findings or dependency alerts; a workflow to prioritize, test, approve and deploy; verification that the patch landed; and records kept for the audit period.

Patching is the remediation half of vulnerability management: scanning finds the problem, patching fixes it. If you have not defined how you discover and rank vulnerabilities, start with your vulnerability management policy.

What belongs in scope for patching?

Everything that runs code you did not write and could expose sensitive data, which for most SaaS and HealthTech companies is more than the server fleet.

Asset type	Typical patch source	Common gap
Servers and virtual machines	OS vendor updates, configuration management	Long-lived "pet" servers that miss the automated cycle
Employee laptops and desktops	OS and browser auto-update, MDM	Deferred restarts, so updates download but never install
Cloud machine images	Rebuilt golden images	Old images still used by autoscaling groups
Containers	Updated base images, rebuilt and redeployed	Patching a running container instead of rebuilding the image
Third-party libraries and open-source packages	Dependency updates in your repositories	No owner, so alerts pile up unread
Network appliances and firmware	Vendor firmware releases	Not in the asset inventory at all
Managed and SaaS services	The provider	Assuming the provider patches what is actually your responsibility

Two areas deserve extra attention.

Third-party software patching in code. Your application inherits every vulnerability in its open-source dependencies. Updating a library is a code change, so it should flow through the same pull request, review and test pipeline as any other change. Knowing what you depend on is the precondition; our comparison of SBOM vs SCA covers how teams build that list.

Shared responsibility. For managed services, the provider patches the underlying system, but you still own runtimes, images, libraries and configuration. Record that split in your policy.

How fast do you need to patch?

Fast enough to match the risk, and exactly as fast as your policy says. Most frameworks leave the number to you, so pick SLAs you can actually meet and then meet them.

Here is an example starting point. These numbers are an illustrative SecureSlate recommendation, not an industry standard or a regulatory mandate, so adjust them to your risk assessment and contractual commitments:

Severity and context	Example SLA	Notes
Known to be exploited, internet-facing	72 hours to 7 days	Also check whether the fix needs emergency change approval
Critical	14 to 30 days	30 days aligns with the PCI DSS critical-patch timeframe
High	30 days	Shorten for systems that store PHI or cardholder data
Medium	60 to 90 days	Often bundled into the regular patch cycle
Low	Next scheduled maintenance	Document the decision rather than ignoring it

Where real numbers come from primary sources:

• PCI DSS v4.x. The PCI Security Standards Council's FAQ on vulnerability risk rankings confirms that Requirement 6.3.3 requires critical vulnerabilities to be resolved within one month of release. The Council's announcement of PCI DSS v4.0.1 explains that v4.0.1 reverted to the v3.2.1 wording, so the 30-day window applies only to critical vulnerabilities; the retired v4.0 text had also included high-security patches. Other security patches must be installed within appropriate time frames based on the entity's own risk assessment, with lower-ranked items handled according to a targeted risk analysis.
• US federal agencies. CISA's binding operational directives set patching deadlines for federal civilian agencies, not private companies. CISA's Known Exploited Vulnerabilities catalog is still a useful prioritization signal for anyone: a vulnerability that attackers are already using deserves your shortest SLA.

Define when the clock starts (vendor release or first detection; PCI's wording runs from release, so slow detection eats into your window) and measure SLA attainment monthly. A monthly report showing which critical patches met the SLA, with an approved exception for each one that did not, is better evidence than a claim that everything is always patched.

How do you test patches without breaking production?

Test in proportion to risk, deploy in waves, and keep a tested way back.

The HHS Office for Civil Rights June 2018 cybersecurity newsletter on software patches describes a cycle of evaluating, testing on an isolated system where possible, approving, deploying and then verifying. That cycle works well beyond healthcare:

1. Classify the change. Routine OS updates on standard images can follow a pre-approved standard change. Database engine upgrades or major library versions need a normal change review.
2. Test where it matters. Run your automated test suite for dependency bumps. Use a staging environment or a canary group for infrastructure patches.
3. Roll out in rings. Start with a small group of internal laptops or one availability zone, watch error rates, then widen.
4. Keep rollback ready. For containers and images, rollback is redeploying the previous version. For in-place patches, take a snapshot first and confirm you know how to restore it.
5. Verify. Rescan or query the version after deployment. A scan showing the fixed version beats a closed ticket.

Emergency patches can skip steps, but still need a record of who approved, why, and a review afterwards.

What if a patch cannot be applied on time?

Record a time-bound exception, apply compensating controls, and get it approved by someone accountable for the risk.

Exceptions are normal: a fix may not exist yet, a device vendor may restrict updates, or a patch may break a critical integration. The problem is the silent exception, such as a months-old critical finding with no explanation.

A good exception record includes:

• The vulnerability, affected assets and severity
• Why the patch cannot be applied within the SLA
• Compensating controls, such as restricting network access, disabling the vulnerable service, adding a web application firewall rule or increasing monitoring
• A risk owner who approved it, and an expiry date for review

The OCR newsletter above recognizes compensating measures, such as disabling a vulnerable service or restricting network access, when a patch is unavailable or unsafe to apply.

How do SOC 2, ISO 27001, HIPAA and PCI DSS treat patching?

Each of these four frameworks expects timely, risk-based patching, but of the four only PCI DSS sets a fixed number for critical patches.

Framework	How patching shows up	Fixed deadline?
SOC 2	The AICPA Trust Services Criteria include CC7.1, on detecting susceptibility to newly discovered vulnerabilities, and CC8.1, on authorizing, testing, approving and implementing changes to infrastructure and software	No. Your auditor tests your stated SLAs
ISO 27001:2022	Annex A control 8.8, Management of technical vulnerabilities, with remediation routed through change management in 8.32, as explained by certification body DQS	No. Set by your risk treatment
HIPAA Security Rule	OCR links unpatched software to the required risk analysis and risk management, and to evaluation after changes (OCR newsletter)	No, under the current rule
PCI DSS v4.x	Requirement 6.3.3 (PCI SSC FAQ)	Critical: within one month of release

SOC 2 patch management in practice: auditors sample patches or vulnerabilities from the audit period and check that each was handled according to your policy, through your change process.

HIPAA patch management may change. HHS published a proposed rule to strengthen the HIPAA Security Rule in the Federal Register on January 6, 2025, and it includes a proposed patch management standard. Check HHS for its current status, and until a final rule applies, build to your risk analysis.

What evidence will an auditor ask for?

Expect requests for your policy, your inventory, and samples proving the process ran throughout the audit period.

• Approved patch management policy with scope, SLAs by severity, roles and exception process
• Asset and software inventory, including cloud images, containers and repositories
• Patch and vulnerability reports from several points in the period, not only the week before the audit
• Change tickets or pull requests for sampled patches, showing testing and approval
• SLA metrics: on-time percentage by severity, plus a list of overdue items
• Exception register with compensating controls, approvers and expiry dates
• Endpoint compliance evidence showing laptops are on supported, updated OS versions
• Post-deployment verification, such as rescans or version queries
• Records of end-of-life software and the plan to replace it

For a SOC 2 Type 2 report, one clean scan on audit day does not prove months of operation, so collect evidence continuously.

How SecureSlate helps

SecureSlate helps SMB and HealthTech teams run patching as a control with evidence behind it, alongside the rest of their SOC 2, ISO 27001, HIPAA and PCI DSS programs:

• Multi-framework control mapping links one patch management control to SOC 2, ISO 27001, HIPAA and PCI DSS, so you document it once. Custom controls let you encode your own SLAs.
• Agentless read-only cloud integrations give visibility into the cloud accounts in scope, and the device agent covers employee laptops.
• Code security and secrets detection keeps your repositories, where third-party dependencies live, inside the same program.
• Risk management records patch exceptions with owners, compensating controls and review dates.
• Vendor risk management tracks providers that patch the managed services you rely on.
• Audit management organizes policies, reports and samples for your auditor.

SecureSlate does not deploy patches itself. Your patching and MDM tools apply updates, and SecureSlate tracks the control and its evidence.

Start your free SecureSlate trial

FAQ

Is there a required patching timeline for SOC 2?

No. The Trust Services Criteria do not set a number of days. Your auditor tests whether you meet the SLAs in your own policy, so choose deadlines you can consistently hit.

Does HIPAA require patching within a specific number of days?

Not under the current Security Rule. OCR expects patching to be handled through your risk analysis and risk management. The rule proposed in January 2025 includes a patch management standard; check HHS for its current status.

Do open-source dependencies count as patch management?

Yes. A vulnerable library in your application is third-party software you must update. Treat dependency updates as changes that go through review and testing, with SLAs by severity.

Disclaimer (legal note)

This article is for general information only and is not legal, regulatory or professional advice. Requirements vary by framework, industry and jurisdiction. Consult qualified advisors for your specific obligations.