Topics in this domain
- The Security Program: Charter, Scope and Objectives
- Security Team Structure, Roles and Staffing
- Working with Legal, HR, IT, Audit and the Business
- Program Implementation: From Plan to Operating Controls
- Information Asset Identification and Valuation
- Data Classification: Owners, Custodians and Users
- Data Lifecycle: Retention, Archiving and Secure Disposal
- Enterprise Architecture for Security Managers
- Information Security Architecture: Principles and SABSA
- Defence in Depth and Zero Trust
- Cloud Security and Shared Responsibility
- Control Frameworks: NIST SP 800-53, CIS Controls and ISO 27002
- Security Policy Development and Lifecycle
- Security Standards and Baseline Requirements
- Procedures, Guidelines and Acceptable Use
- Policy Enforcement, Exceptions and Review
- Designing Security Metrics: KPIs, KRIs and KCIs
- Collecting, Analysing and Reporting Metrics
- Security Maturity Models and Program Assessment
- Control Types and Categories
- Control Design and Selection Based on Risk and Cost
- Control Testing: Design vs Operating Effectiveness
- Identity and Access Management
- Network and Endpoint Security Controls
- Application Security and the Secure SDLC
- Configuration, Change and Patch Management
- Cryptography for Security Managers
- Security Testing: Scanning, Pen Testing and Tracking Remediation
- Security Awareness Program Design
- Role-Based Security Training
- Phishing Simulations and Social Engineering Defences
- Third-Party Risk Management and Due Diligence
- Vendor Contracts, SLAs and Right to Audit
- Fourth-Party and Supply Chain Risk
- Outsourcing and Managed Security Services
- Security Stakeholder Communication
- Executive Dashboards and Board Reporting
- Continuous Improvement of the Security Program
Configuration, Change and Patch Management
Keeping systems in a known good state
Most systems start secure and then drift: settings change, patches are missed, emergency fixes become permanent. Unpatched systems and misconfigurations are among the most common causes of breaches. Three IT processes keep production in a known, approved state. The security manager doesn’t run them, but depends on them and must make sure security is built in.
Three processes, one goal
| Process | What it does |
|---|---|
| Configuration management | Keeps an inventory of components (often in a CMDB) and their approved secure baselines; detects drift |
| Change management | Ensures changes are requested, assessed (including security impact), approved, tested, implemented and recorded |
| Patch management | Tracks vendor fixes, prioritises them by risk, tests, deploys and verifies them |
Patch management
Patches are prioritised by risk: active exploitation, exposure (internet-facing first), and the criticality of the system. Agreed service levels, for example 7 days for critical patches on internet-facing systems, make expectations clear. Patches are tested before production, but an actively exploited vulnerability can justify the emergency change route.
Security’s role in each
| Process | Security contributes |
|---|---|
| Configuration | Secure baselines; drift monitoring |
| Change | Security impact assessment for significant changes; a seat on the change board |
| Patch | Risk-based prioritisation; patch service levels; managing exceptions |
| All three | Metrics, and escalation when they slip |
Emergency changes and patches may skip prior approval, but they must be documented and reviewed afterwards.
When patching isn’t possible
- Isolate the system with segmentation.
- Add monitoring and virtual patching (IPS, WAF rules).
- Document risk acceptance with an expiry date.
- Plan replacement of end-of-life systems.
Example. A hospital MRI scanner runs an operating system the vendor won’t let customers patch. It’s placed on an isolated network segment with strict rules and monitoring, the clinical director accepts the risk for 12 months, and replacement is added to the capital plan.
How the exam asks about it
| If the question asks… | The answer is usually… |
|---|---|
| Step before deploying a patch to production | Test it |
| How to prioritise patches | By risk: exploitation, exposure and criticality |
| A system can’t be patched | Compensating controls and documented risk acceptance |
| An emergency change was made without approval | Document and review it afterwards |
| Detecting unauthorised configuration change | Compare against the baseline (drift monitoring) |
In short
- Configuration management keeps an inventory of components and their approved secure configurations (baselines), and detects drift.
- Change management makes sure every change is requested, assessed (including for security impact), approved, tested and recorded.
- Patch management tracks vendor fixes, prioritises them by risk, tests and deploys them, and verifies installation.
- Unpatched systems and misconfigurations are among the most common causes of breaches.
- Emergency changes and patches may skip prior approval but must be documented and reviewed afterwards.
- Systems that can't be patched need compensating controls and documented risk acceptance.
Exam traps
- Patching purely by severity score, ignoring exploitation and exposure, is inefficient.
- Applying patches straight to production without testing risks outages.
- Unsupported (end-of-life) systems that no longer get patches need replacement or isolation.
- A change process that security isn't part of can introduce new vulnerabilities unnoticed.
Slides
Click the slide and use the arrow keys. F toggles full screen.
Three processes, one goal
Patch management