Security patches for internet-facing services and devices (websites, remote access, firewalls, email gateways) are applied within the timeframes in the requirement

Patches, updates or other vendor mitigations for vulnerabilities in online services are applied within two weeks of release when vulnerabilities are assessed as non-critical by vendors and no working exploits exist. Required at Maturity Levels One, Two and Three of the Patch applications mitigation strategy (Appendices A, B and C); ISM control ISM-1690 in ASD's Essential Eight to ISM mapping (December 2023).

The requirement's own words: within two weeks of release

evidence an assessor asks for Patch records for non-critical online service vulnerabilities showing application within two weeks of release; Exception register entries for any late items with compensating controls

Patches, updates or other vendor mitigations for vulnerabilities in online services are applied within 48 hours of release when vulnerabilities are assessed as critical by vendors or when working exploits exist. Required at Maturity Levels One, Two and Three of the Patch applications mitigation strategy (Appendices A, B and C); ISM control ISM-1876 in ASD's Essential Eight to ISM mapping (December 2023).

The requirement's own words: within 48 hours of release

evidence an assessor asks for Patch records for online services with vendor release date, severity or exploit status, and applied date; Vulnerability ticket showing critical items closed within 48 hours

Patches, updates or other vendor mitigations for vulnerabilities in operating systems of internet-facing servers and internet-facing network devices are applied within two weeks of release when vulnerabilities are assessed as non-critical by vendors and no working exploits exist. Required at Maturity Levels One, Two and Three of the Patch operating systems mitigation strategy (Appendices A, B and C); ISM control ISM-1694 in ASD's Essential Eight to ISM mapping (December 2023).

The requirement's own words: within two weeks of release

evidence an assessor asks for Records of non-critical internet-facing operating system patches applied within two weeks; Exceptions with compensating controls for devices awaiting vendor fixes

Patches, updates or other vendor mitigations for vulnerabilities in operating systems of internet-facing servers and internet-facing network devices are applied within 48 hours of release when vulnerabilities are assessed as critical by vendors or when working exploits exist. Required at Maturity Levels One, Two and Three of the Patch operating systems mitigation strategy (Appendices A, B and C); ISM control ISM-1877 in ASD's Essential Eight to ISM mapping (December 2023).

The requirement's own words: within 48 hours of release

evidence an assessor asks for Patch records for internet-facing server and network device operating systems with release date, criticality or exploit status and applied date; Emergency change records showing 48-hour application

All system components must be shielded from known vulnerabilities by applying relevant security patches or updates such that: patches or updates addressing critical vulnerabilities, as ranked under Requirement 6.3.1, must go in within one month of their release; and every other relevant security patch or update is installed within a suitable time frame set by the entity's own assessment of how critical the risk is to its environment, using the Requirement 6.3.1 ranking process. It applies to all entities and all system components. Customized approach objective: exploitation of a known vulnerability cannot be used to compromise system components.

The requirement's own words: within one month of their release

evidence an assessor asks for Patch management procedure stating the one-month deadline for critical patches and time frames for others; Patch compliance reports per system component showing install dates against vendor release dates; Risk-based rationale or targeted risk analysis for non-critical patch time frames; Exception register for patches that could not be applied, with compensating measures; Sample of critical advisories traced to installation evidence

Keep operating systems on enterprise assets updated by automated patch management, running at least once a month.

The requirement's own words: at least once a month

evidence an assessor asks for OS patch management tool configuration with automated monthly deployment; OS patch compliance reports per asset; Patch management standard defining monthly OS patch cycles and emergency patch windows; Deployment rings or maintenance window settings in the patching tool covering workstations and servers; Monthly OS patch deployment reports showing success rate and failed devices remediated

Keep applications on enterprise assets updated by automated patch management, running at least once a month.

The requirement's own words: at least once a month

evidence an assessor asks for Application patch management configuration with automated monthly deployment; Application patch compliance reports; Patch standard covering third-party applications, not only operating system updates; Third-party patching tool catalogue showing which applications are auto-updated; Monthly application version compliance report for browsers, runtimes, PDF readers and office suites

Fix vulnerabilities found in software, using processes and tools in line with the remediation process, at least once a month.

The requirement's own words: at least once a month

evidence an assessor asks for Vulnerability remediation tracker showing monthly closure per the remediation process; Rescan results verifying fixes; Remediation tickets linked to scanner findings with severity, owner and due date; Monthly remediation metrics showing overdue vulnerabilities by severity and asset owner; Closed ticket sample with before and after scan evidence for each fix

Vulnerabilities in assets are identified, validated, and recorded. Control from NIST Cybersecurity Framework 2.0 framework, domain: ID - Identify.

evidence an assessor asks for Vulnerability scanning coverage report; Vulnerability triage workflow with severity SLAs; Validated findings with proof and remediation status; Asset coverage exceptions register; Trend analysis on vulnerability backlog

Software is maintained, replaced, and removed commensurate with risk. Control from NIST Cybersecurity Framework 2.0 framework, domain: PR - Protect.

evidence an assessor asks for Software lifecycle policy with end of support tracking; Patch management cadence and exception register; End of life replacement plan; Software risk assessments for unsupported tools; Software retirement records

All system components must be shielded from known vulnerabilities by applying relevant security patches or updates such that: patches or updates addressing critical vulnerabilities, as ranked under Requirement 6.3.1, must go in within one month of their release; and every other relevant security patch or update is installed within a suitable time frame set by the entity's own assessment of how critical the risk is to its environment, using the Requirement 6.3.1 ranking process. It applies to all entities and all system components. Customized approach objective: exploitation of a known vulnerability cannot be used to compromise system components.

The requirement's own words: within one month of their release

evidence an assessor asks for Patch management procedure stating the one-month deadline for critical patches and time frames for others; Patch compliance reports per system component showing install dates against vendor release dates; Risk-based rationale or targeted risk analysis for non-critical patch time frames; Exception register for patches that could not be applied, with compensating measures; Sample of critical advisories traced to installation evidence

Conduct penetration testing at least annually by qualified internal or external party, automated scans of information systems and manual reviews of systems not covered by scans, document and report material issues, prioritize and remediate. Class A must use external experts at least every three years.

evidence an assessor asks for Annual penetration test report from qualified party; Automated vulnerability scan schedule and outputs; Manual review records for non-scannable systems; Remediation tickets with SLAs and closure evidence; Risk-based prioritization methodology; Class A external expert engagement letter (triennial); Monitoring of publicly disclosed vulnerabilities and CISA KEV tracking

All high or critical security updates (CVSS 7.0+ or vendor critical/high rating) must be applied within 14 days of release.

The requirement's own words: within 14 days of release

evidence an assessor asks for patch compliance dashboard from the patch or vulnerability management tool; 14-day SLA report; exception register

Firmware on routers, firewalls and other in-scope network devices must be kept current. Firmware is treated as software for update purposes.

evidence an assessor asks for network device firmware report; vendor advisory subscription; firmware change tickets

All system components must be shielded from known vulnerabilities by applying relevant security patches or updates such that: patches or updates addressing critical vulnerabilities, as ranked under Requirement 6.3.1, must go in within one month of their release; and every other relevant security patch or update is installed within a suitable time frame set by the entity's own assessment of how critical the risk is to its environment, using the Requirement 6.3.1 ranking process. It applies to all entities and all system components. Customized approach objective: exploitation of a known vulnerability cannot be used to compromise system components.

The requirement's own words: within one month of their release

evidence an assessor asks for Patch management procedure stating the one-month deadline for critical patches and time frames for others; Patch compliance reports per system component showing install dates against vendor release dates; Risk-based rationale or targeted risk analysis for non-critical patch time frames; Exception register for patches that could not be applied, with compensating measures; Sample of critical advisories traced to installation evidence

The organization is to gather information about technical vulnerabilities in the information systems it uses, assess how exposed it is, and take suitable action. Purpose (stated in ISO/IEC 27002:2022): prevents exploitation of technical vulnerabilities. As an Annex A reference control, it is compared with the controls determined in risk treatment (6.1.3 c) and recorded in the Statement of Applicability as included or excluded, with the justification and implementation status (6.1.3 d); implementation guidance is ISO/IEC 27002:2022 8.8.

evidence an assessor asks for Statement of Applicability entry for control A.8.8, showing inclusion or justified exclusion, implementation status and the risks it treats; A software asset inventory with vendor, product, version, deployment location and responsible owner; Defined vulnerability management roles and a list of monitored vulnerability information sources; Authenticated scan results and penetration test reports by authorized testers, with verification scans after patching; Remediation timelines by severity with measured performance, and risk records weighing the vulnerability against update risk