Skip to content
PRO-04 Secure configuration management
ASD EssentialsIT.PRO-04.3

ASD Essentials IT.PRO-04.3 Detect and Remediate Configuration Drift Using Scheduled Assessments and Automated Monitoring

What it says

Detect and respond to configuration drift using scheduled technical assessments and, where supported, automated monitoring, based on system criticality and change rate.

Quoted as published. Everything else on this page is written by Control Stack.

What it means

In plain English

Finds and fixes drift from approved settings with scheduled checks and, where supported, automated monitoring, checking critical or fast-changing systems more often.

Over time, settings slip away from the approved standard, such as a firewall rule opened for a test and never closed. This is called drift. To meet this, check each system against its baseline (approved standard settings) on a schedule. Where a system supports it, also use tools that spot changes automatically. Check critical and often-changed systems more often. Fix each unapproved change by a deadline set by its severity, and track it until fixed.

Where this action applies

What's in each domain?

ASD orders the work by domain: apply this action to each ticked domain, phase by phase.

Phase 1
Phase 2
Phase 3

Why it matters

Without drift checks, weakened settings stay that way. An attacker who switches off malware protection or logging, or edits system settings, can work unnoticed. On firewalls, sign-in or admin systems, a single gap can give them wider or admin access.

How to implement

  1. The configuration management lead and system owners should build a drift schedule covering every in-scope system.

    Set how often each is checked from how critical it is and how often it changes.

  2. Platform, network and desktop engineers should turn on automatic monitoring of settings wherever supported, alerting on any difference from the baseline.

    Watch closely for changes to malware protection, logging and key system security settings.

  3. The infrastructure or security operations team should run scheduled checks, such as compliance scans that sign in and read each setting.

    Cover every baseline setting on every in-scope system, and use the results to confirm monitoring still works.

  4. The security lead should write a fix process that rates each drift finding by severity and sets a response time for each level.

    Reverse unapproved changes, and put approved ones into the baseline through the change process.

  5. The service desk should log every drift finding with its system, setting, severity, owner and due date.

    Close it only when a follow-up check, such as a clean re-scan, shows the system matches its baseline.

Keep it running

System owners update the drift schedule when a system's importance or rate of change shifts. Treat a missed check or a silent monitoring tool as a finding: a check that fails quietly looks like a clean result. Investigate unexplained changes to security tools or settings as a possible cyber security incident. Extend coverage in ASD's priority order: internet-facing and sign-in systems first, then critical and admin systems, then business systems and staff devices.

Evidence and audit

  1. Check 1 of 5What an auditor asks for

    Ask for

    Ask for the drift schedule showing each system's importance, change rate and check frequency.

    Look at

    Whether one frequency applies to every system, whatever its importance or how often it changes.

    Good evidence

    Critical and often-changed systems are checked more often than stable ones, as the schedule shows.

  2. Check 2 of 5What an auditor asks for

    Ask for

    Request the asset list and a list of systems covered by monitoring, checks or both.

    Look at

    Whether any drift detection exists, and which systems, such as firewalls or laptops, nothing reaches.

    Good evidence

    Both lists match, with every applicable system under monitoring, scheduled checks or both.

  3. Check 3 of 5What an auditor asks for

    Ask for

    Request recent check records and, where practical, a test change on a non-live system.

    Look at

    Whether checks ran late, or are spot checks that don't compare each setting with the baseline.

    Good evidence

    Checks run on time and find each case of drift, and the test change is caught.

  4. Check 4 of 5What an auditor asks for

    Ask for

    Ask for the drift fix process, including severity ratings and response times.

    Look at

    Whether fixes rely on informal requests, or response times are missing or unrelated to severity.

    Good evidence

    A written process sets response times by severity and names who assesses and fixes drift.

  5. Check 5 of 5What an auditor asks for

    Ask for

    Ask for the drift register, and trace sampled findings from reports through to closure.

    Look at

    Whether findings never got logged, or closed without evidence or past their deadline.

    Good evidence

    Every drift finding closes within its deadline, with evidence such as a clean follow-up scan.

ASD indicators of good practice (8)

The indicators below are quoted as published from ASD's Assessment evidence guide for enterprise IT. These optional indicators help an assessor judge the action in each domain where it applies: if any not effective statement is true, the action is rated not effective; if every applicable fully effective statement is true and no other statement is, it is rated fully effective; otherwise it is rated partially effective. ASD says the indicators "do not replace expert judgement, nor are they intended to serve as a checklist".

Not effective(3)

  • NE-1No mechanism exists to detect configuration drift from approved baselines.
  • NE-2Assessments to detect configuration drift have not been conducted within the review period defined by the organisation.
  • NE-3Assessments do not systematically identify instances of configuration drift for assets.

Partially effective(2)

  • PE-1Drift detection is in place but does not cover all applicable assets.
  • PE-2Drift is detected but the remediation process is informal or response timeframes are not defined.

Fully effective(3)

  • FE-1Automated configuration monitoring or regular technical assessments detect drift across the applicable assets, occurring at a frequency based on system criticality and change rate.
  • FE-2A documented remediation process exists with defined response timeframes aligned to severity.
  • FE-3Drift events are tracked to closure with evidence of remediation.

Mappings

Closest match in ISO/IEC 27001: A.5.36, Review compliance with information security policies, which this control partially meets.

ISO 27001

ISO/IEC 27001: 2 mappings

  • A.5.36Review compliance with information security policiesPartially meets
  • A.8.9Configuration Management for Secure IT SystemsPartially meets
Essential Eight

ASD Essential Eight: 1 mapping

  • E8-AC-ML2.4Annual validation of application control rulesetsPartially overlaps
ASD ISM

ASD Information Security Manual: 2 mappings

  • ISM-1211System Administration Performed Under Change and Configuration Management PlanPartially overlaps
  • ISM-1526System Owners Continuously Monitor Security and Manage Threats, Risks and ControlsPartially overlaps

Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.