Patch and configuration evidence your auditor can follow

Configuration baselines

A baseline is the approved state of a system, application or network device: what the settings should be, who approved them and when. When a system moves away from its baseline, that is configuration drift, and auditors will ask how you found it and what you did about it.

Most teams start from a published hardening benchmark, such as the CIS Benchmarks, adjust it for their own systems and keep it in version control or their configuration management tool. Attach the approved baseline and its sign-off as evidence on the control it supports in Certifyi, so the auditor testing A.8.9 finds it there.

• A version history, so you can show what the approved settings were on any date
• Sign-off by an authorised approver before a baseline takes effect
• An owner for each system, recorded in your asset inventory
• A regular comparison of live settings with the baseline, and a record of what it found

From advisory to verified fix

Auditors expect each patch to move through identification, assessment, testing, deployment and verification, and they pick a sample to check that it did. Identification is where Certifyi helps directly: the assets in your inventory are matched against the NVD, and each match is linked to the affected asset and recorded as a risk with an owner.

The rest of the lifecycle runs in the tools your team deploys with. What the auditor needs from it is who acted at each stage, when, the outcome and the rollback procedure. Attach that record as evidence on the control it supports, such as ISO 27001 A.8.8, and the tamper-evident activity log shows who added it and when.

Recording configuration drift

When a review, a scan or a change record shows a setting that differs from the approved baseline, write down what was expected, what was found and where. Auditors care less about whether drift happened than about whether you noticed it and what you did next.

If the drift means a control is failing, create a Jira ticket from the failing control for the team that owns the system. They either bring the system back to its baseline or, if the change was intended, update the baseline through change management, and the outcome goes on the control as evidence.

Rollback written before the change goes live

A good patch or configuration change record includes a rollback procedure: how to undo the change if it goes wrong. Write it before the change is approved, while there is still time to think it through, rather than improvising once something has broken.

Auditors testing change management often ask for rollback evidence. Keep it on the change record next to the implementation and the approval, and attach that record to the control it supports, so you do not have to collect it separately.

Configuration items live in the asset register

Configuration management starts with knowing what you run. Each configuration item should be an entry in your asset inventory with an owner, a classification and a lifecycle status, so every baseline and every patch belongs to a named system.

In Certifyi the asset inventory sits beside your controls and risk register, and assets are checked against the NVD, so a known vulnerability on a configuration item shows up as a risk with an owner.

Which frameworks ask for this

Most security frameworks ask for configuration and patch management, and these are the controls auditors usually test. In Australia, the Essential Eight makes patching applications and patching operating systems two of its eight strategies, with timeframes that tighten as the maturity level rises, and expects missing patches to be found through an asset inventory and vulnerability scanning. Teams usually evidence all of these the same way: the approved baseline, a sample of patch records with their approvals and rollback steps, and a record of how drift was found and resolved.