Patch

Applies to. 6.3.3 applies to all system components in scope, not only servers: network devices, virtual machines, point-of-sale terminals, hypervisors and the software on them. Patches for vulnerabilities the entity has ranked critical under its 6.3.1 process must be installed within one month of release; other security patches follow a timeframe the entity sets from its own assessment of the risk. 6.3.2 supports this by requiring an inventory of bespoke and custom software and its third-party components, so that patches for embedded libraries are not missed.

Example. A vendor publishes a fix for a remote code execution flaw in a web server package. The entity's 6.3.1 process ranks it critical because the package fronts its payment application. The one-month clock starts on the vendor's release date, not on the day the entity noticed the advisory, so the patch has to be tested and deployed to production within that window, and the change record under 6.5.1 shows when it went in.

Limits. A patch is not a workaround: 6.3.3 asks for applicable security patches or updates to be installed, and mitigations such as disabling a feature may reduce the risk in the meantime but do not close the requirement on their own. The one-month deadline applies only to vulnerabilities ranked critical; the standard sets no number of days for the rest and expects the entity to justify its own timeframe. Patches do not cover flaws in the entity's own code, which are corrected through the 6.2.3 review and the 6.5.1 change process rather than by waiting for a vendor release. Unsupported software has no patches to install, which does not make its vulnerabilities go away.