Configuration changes: what the auditor reads in them
A feature flag or a parameter change can alter what a financial system does without a code change. When these go through a separate console, they often carry no ticket and no approval on the export.
How the checker recognises them
Read from the title: config, feature flag, setting, parameter, toggle, threshold, rate and the like.
Findings they raise most often
- No ticket reference: Where are the request, the reason and the impact assessment for this change?
- No independent approval: Who approved this change before it reached production, and where is that approval recorded by someone other than the author?
The clauses that speak to them
3 clausesCOBIT BAI10.03 Maintain and control configuration itemsThe clause text
An up-to-date repository of configuration items is maintained by populating all configuration changes: all changes to CIs are regularly identified, proposed changes are reviewed against the baseline for completeness and accuracy, configuration details are updated for approved changes, and changes to baselines are created, reviewed and formally agreed whenever needed.
Where it usually falls short: Repository that describes the environment as it was months ago
Source: COBIT 2019
SOC 2 CC7.1 Detection and monitoring procedures for security events are in placeNamed, not quoted: the criteria text is not held in full here.
Where it usually falls short: Configuration monitored at build only, so drift introduced afterwards is never detected; Scanning performed quarterly against an environment that changes daily
Source: SOC 2 (Trust Services Criteria)
ISO 27001 8.9 Configuration managementThe clause text
Establish, document, implement, monitor and review secure configurations for hardware, software, services and networks.
Where it usually falls short: Outdated baselines; Missing change approvals
Source: ISO/IEC 27001:2022