Patch Management Policy¶
Classification: Internal
Document status: Effective
Version: 1.0
Owner: Management / Security Owner
Review cycle: Annual; interim revision upon material change to platforms, customer SLAs, or criticality definitions
Document control¶
| Role | Name |
|---|---|
| Prepared by | Management / Security Owner (Cloudnaut) |
| Reviewed by | Nidhi Jain (third-party reviewer) |
| Approved by | Sandeep AC |
Revision history¶
| Version | Date | Summary | Reviewed by | Approved by |
|---|---|---|---|---|
| 0.9 | 2021-03-14 | Draft for third-party review prior to first effective release. | Nidhi Jain (third party) | — |
| 1.0 | 2021-06-18 | Initial effective release. | Nidhi Jain (third party) | Sandeep AC |
| 1.0 | 2024-03-11 | Scheduled annual review; clarifications and cross-references (retained at version 1.0). | Nidhi Jain (third party) | Sandeep AC |
Purpose¶
This policy defines operating system and security patch management for endpoints used for company and customer work.
Scope¶
This policy applies to Linux and Windows endpoints that access company or customer systems, repositories, or data.
Policy¶
Non-emergency operating system patches are reviewed and applied on at least a monthly cadence. Critical security patches are assessed without undue delay and remediated within seven calendar days where technically feasible and compatible with customer change windows.
Process¶
- Personnel monitor vendor security advisories and operating system update channels for their platform.
- Standard patches are applied in the monthly maintenance window or sooner when risk and stability allow.
- Critical patches receive priority scheduling within the seven-day target.
- When a patch cannot be applied in the target window due to compatibility, vendor delay, or customer-imposed freeze, the reason and compensating controls are documented and approved by management.
- Endpoints that remain materially non-compliant may be denied customer access until remediated.
Monitoring and evidence¶
Patch posture is monitored and demonstrated using platform-native sources rather than a single mandatory enterprise MDM product:
- Linux: distribution update tooling and history (for example
dnf history,zypper history,/var/log/apt/history.log, or equivalent) plus running kernel and installed package versions against vendor advisories relevant to the role. - Windows: Windows Update View update history, Update history in Settings, or
Get-WindowsUpdateLog/ reliability records as appropriate for the review.
Personnel reconcile these sources at least monthly (aligned with the monthly patch cadence) and without undue delay when critical issues appear. Where a future central endpoint-management product is introduced, this section is updated to name it; until then, compliance exports, screenshots, or written attestation from the above sources satisfy customer and audit evidence requests.
Records¶
Typical evidence includes OS update history, package manager logs, Windows Update reporting, command-line or UI exports from the monitoring sources in this policy, endpoint compliance exports where available, or equivalent attestation suitable for audit or customer review.
