Find what matters, fix what's exploitable.

Most compliance frameworks that touch cybersecurity include explicit or implied patching requirements. The requirements below reflect the current published standards as of 2024. Organizations subject to multiple frameworks should apply the strictest applicable SLA. Note that these are minimum requirements; a risk-based approach, informed by exploit data as described above, will routinely demand faster remediation than any framework minimum.

• PCI DSS 4.0 (Requirement 6.3): All system components must be protected from known vulnerabilities by installing applicable security patches and updates. Critical patches (as defined by the entity's risk ranking) must be installed within one month of release. High-severity patches must be installed within three months. PCI DSS 4.0, effective as of March 2024, also requires organizations to maintain an inventory of all bespoke and custom software and to have a documented process for addressing vulnerabilities in it, not just vendor-issued patches.
• HIPAA / PHIPA (Technical Safeguard § 164.312(a)(2)(ii)): HIPAA does not specify a numeric patching SLA, but the HHS has issued guidance indicating that "reasonable and appropriate" technical safeguards include patching known vulnerabilities in a timely manner. In enforcement actions and HIPAA breach investigations, OCR has consistently cited unpatched systems as evidence of failure to implement required technical safeguards. Ontario's PHIPA, which governs health information custodians in Ontario, follows a similar reasonableness standard. In practice, thirty days for critical and high, ninety days for medium is the benchmark used by HIPAA-compliant organizations in breach post-mortems.
• ISO/IEC 27001:2022 (Control 8.8): The 2022 revision of ISO 27001 introduced explicit vulnerability management requirements in Control 8.8 (Management of technical vulnerabilities). Organizations must obtain timely information about technical vulnerabilities, evaluate exposure, and take appropriate action. The standard does not prescribe specific SLAs but requires that the organization define its own patching timelines in documented procedures and then follow them consistently. Audit evidence of deviation from documented SLAs, regardless of what those SLAs are, constitutes a nonconformity.
• SOC 2 Type II (CC7.1 – System Monitoring): SOC 2's Common Criteria 7.1 requires that the organization uses detection and monitoring procedures to identify changes to configurations that could create vulnerabilities. SOC 2 auditors evaluate whether vulnerability scanning is continuous, whether findings are tracked to remediation, and whether unresolved findings are risk-accepted with documented rationale. Auditors increasingly request evidence of SLA compliance metrics, the percentage of critical findings closed within the defined SLA over the audit period, as a primary control artifact.
• NIST CSF 2.0 (Respond / RS.MI): The NIST Cybersecurity Framework's Respond function includes mitigation subcategory RS.MI-3: "Newly identified vulnerabilities are mitigated or documented as accepted risks." For organizations using NIST CSF as their primary security framework, common in Canadian public sector and federal contractor contexts, this subcategory requires a documented process for moving vulnerabilities from discovery to remediation or risk acceptance, with defined timelines and approval authority for risk acceptance decisions.
• Cyber insurance (standard Canadian carrier requirements): Most Canadian cyber insurance carriers, including Intact Cyber, Aviva, and Northbridge, now include patching questions in renewal applications. Carriers typically ask whether critical patches are applied within thirty days of release, whether the organization has a documented vulnerability management program, and whether internet-facing systems are scanned at least monthly. Organizations unable to demonstrate thirty-day critical patching cadence face premium loading or coverage limitations on first-party ransomware claims, specifically because unpatched vulnerabilities are the most common initial access vector for ransomware operators targeting Canadian SMBs.

• Forgotten subdomains: Old marketing microsites and development environments still resolving, some running unpatched CMS installs or default credentials.
• Expired or dangling TLS certificates: Including subdomain takeover risk, where an attacker claims a cloud resource behind a DNS record pointing to a deleted asset.
• Shadow SaaS: Applications provisioned by individual employees with no IT involvement, and third-party integrations exposing internal APIs.
• Exposed credentials: Employee credentials from unrelated third-party breaches appearing in public data dumps, weaponizable the moment a password gets reused on a corporate system.