Patch Management process
Scope
The process covers application dependencies, build tooling, browser-delivered libraries, managed platform versions, database extensions, serverless runtimes, operating endpoints used for privileged administration, and supplier security updates.
Operating cycle
| Stage | Requirement |
|---|---|
| Inventory | Record component, owner, supported version, exposure, update channel, and business criticality |
| Monitor | Review provider changelogs, security advisories, dependency notices, exploited-vulnerability catalogues, and end-of-support dates |
| Assess | Determine affected version, exploitability, exposure, breaking-change risk, data impact, and compensating controls |
| Plan | Select the target version, test scope, backup or rollback dependency, maintenance window, owner, and communication |
| Test | Build cleanly and verify authentication, authorization, tenant isolation, critical workflows, migrations, providers, and rollback |
| Deploy | Use controlled release and migration procedures with monitoring and evidence |
| Verify | Confirm version, health, security behavior, error rate, and expected provider interactions |
| Record | Retain decision, dates, evidence, exceptions, and follow-up |
Timing
Critical or known-exploited exposure is contained immediately and patched as soon as safely possible; the initial target is 72 hours. High-risk patches target 14 days, medium 30 days, and low 90 days. Managed-provider emergency updates are reviewed against the provider notice and application impact.
Exceptions
Deferred patches require affected assets, risk, reason, compensating controls, owner, approved expiry, and a retest date. Unsupported components require a replacement plan, not an indefinite exception.
Patch decision record
| Field | Required content |
|---|---|
| Component | Product or package, current version, target version, runtime location, owner, and business criticality |
| Trigger | Security advisory, Snyk result, provider notice, end-of-support date, defect, or scheduled maintenance |
| Exposure | Reachability, affected data and tenants, privileges, known exploitation, and current compensating controls |
| Compatibility | Breaking changes, database or API dependency, browser support, provider contract, and rollback constraint |
| Verification | Clean install, production build, automated checks, authentication, authorization, tenant isolation, critical workflow, provider, and monitoring results |
| Deployment | Approved window, operator, release reference, migration dependency, communication, and observation period |
| Exception | Business reason, interim control, risk owner, approver, expiry, and retest date |
Emergency patch path
An actively exploited or critical exposure enters incident control. The team first contains the attack path, then applies the smallest supportable update or configuration change. Emergency speed does not remove source review, clean build, focused security verification, rollback planning, or post-deployment observation. Deferred broad regression work is recorded with an owner and immediate follow-up date rather than described as completed.
Current-state limitation
This process does not establish an automated inventory, committed dependency lockfile, automated dependency scanning, patch dashboard, endpoint-management tool, or historical compliance record. Those implementation gaps remain part of the secure-development improvement plan.