Skip to main content

Patch management

Every patch that touches production goes through the same risk-based path: identify, evaluate, prioritise, test, approve under four-eyes, roll out, and document. Critical fixes move fast, low-risk work rides the regular release cycle, and everything is auditable.

Priority classes and time-to-remediation​

Critical
Vulnerabilities that pose an immediate, significant risk to confidentiality, integrity or availability, or are being actively exploited.
Immediately
High
High-risk vulnerabilities where abuse is likely or a significant operational impact is possible.
Within 24 hours
Medium
Relevant but not immediate risk, or functional updates with security relevance.
Within 2 days
Low
Low security relevance or purely functional or technical improvements without elevated risk.
Within 3 days (or regular cycle)

What is in scope​

Operating systems, container and runtime components (Docker, Kubernetes where administered), applications (in-house and standard software), third-party libraries and dependencies, databases, cloud and infrastructure components under our administrative control, and security components (firewalls, endpoint security, IAM/SSO, monitoring, security tooling).

For fully managed services (SaaS, managed databases, cloud platform services, hosting base infrastructure) the underlying platform patching sits with the provider under the shared responsibility model. Our own scope in those cases still covers customer-managed configurations and workloads, updates to our own applications and deployments, evaluation of provider security advisories, and risk assessment plus tracking of relevant security updates.

The seven principles​

✓
Risk-based approach
Patches are prioritised by criticality and potential impact on confidentiality, integrity, availability and data protection.
✓
Timely rollout
Security-relevant updates are shipped within their priority window.
✓
Test before production
Every change is technically verified before it lands in production.
✓
Traceability
Patch actions are documented, and their execution is logged in an auditable way.
✓
Environment separation
Development, test and production stay separated. Nothing rides through untested.
✓
Four-eyes principle
Production patches are reviewed and approved by technical leadership under four-eyes.
✓
Rollback capability
Every production patch has a documented path back to a suitable prior stable state.

Deadline misses and compensating controls​

If a patch cannot ship inside its window, technical leadership decides after team discussion how to proceed and documents the reason and any compensating controls in the associated pull request or technical documentation. Typical compensating controls: configuration hardening, disabling non-essential functionality, tightened access restrictions, additional monitoring, or organisational constraints until the patch lands.

Evidence​

  • Patch-related artefacts and records are retained for at least one year.
  • Documentation includes affected component, source of the patch, priority, evaluation date, rollout date, responsible roles, test results, and any deviations or compensating controls.
  • Manual test evidence lives in the pull request. Automated test evidence lives in the Azure DevOps pipelines.