BAI10: Managed Configuration

The bai10: managed configuration requirement is a control objective you meet by running configuration management as an operational discipline, not a one-time documentation exercise. Auditors and risk committees look for three things: (1) you know what you have (systems, services, apps, network devices, cloud resources, endpoints), (2) you control how it changes, and (3) you can restore it when something breaks.

BAI10 sits in COBIT 2019’s Build, Acquire and Implement domain and is commonly used to structure IT governance expectations across regulated environments, even when COBIT itself is not the “regulation.” Your challenge as a Compliance Officer, CCO, or GRC lead is to convert the objective into a defensible set of controls that engineering teams can execute: configuration baselines, change approvals, automated drift detection, and evidence capture that survives tool changes.

This page focuses on rapid operationalization: what scope to set, what procedures to require, what artifacts to retain, and what examiners typically challenge. References are limited to publicly provided framework sources ¹.

Regulatory text

Excerpt (provided): “COBIT 2019 objective BAI10 implementation expectation.” ¹

Operator interpretation: You must implement configuration management controls that keep configurations defined, controlled, and traceable across their lifecycle. Practically, that means:

• You maintain an authoritative inventory of configuration items (CIs) and their relationships.
• You define approved configuration baselines for in-scope assets/services.
• You prevent or detect unauthorized configuration changes.
• You can demonstrate configuration status, history, and restoration capability with retained evidence ¹.

Plain-English interpretation (what BAI10 expects)

BAI10 expects you to treat configuration as a controlled asset:

• Known state: You can state “this is how production is configured” for critical systems and services.
• Controlled change: Every meaningful change is approved, implemented through a controlled path, and recorded.
• Detectable drift: If production deviates from the baseline, you detect it and respond.
• Recoverability: You can roll back or rebuild from known-good configuration sources ¹.

This is not limited to servers. It includes network and security devices, cloud services, application settings, identity configurations, and “configuration as code” repositories where configuration becomes deployable artifacts.

Who it applies to

Entity types: Enterprise IT organizations using COBIT 2019 as a governance framework, and organizations mapped to COBIT objectives for audit and assurance purposes ¹.

Operational contexts where BAI10 becomes exam-relevant:

• Regulated businesses where audit expects formal IT controls (financial services, healthcare, critical infrastructure, public sector).
• Any environment with frequent change (CI/CD, cloud infrastructure, container platforms).
• Outsourced or hybrid operations where third parties administer systems; you still need configuration accountability and evidence.

Key internal stakeholders you will need:

• IT operations / platform engineering (owns CMDB/inventory, patch/config tools)
• Security engineering (baseline hardening and drift monitoring)
• Change management / ITSM owner (ticketing, approvals)
• Application owners and SREs (service-level configurations, deployment pipelines)
• Third-party managers (managed service provider access and change evidence)

What you actually need to do (step-by-step)

Use this sequence to operationalize quickly, then expand scope.

1) Define scope and “configuration items” (CIs)

1. Pick your initial scope: start with production systems that support critical business services and regulated data flows.
2. Define CI categories: servers, network devices, security appliances, databases, cloud resources, identity/config in IAM, and key application configurations.
3. Assign CI ownership: every CI class needs an accountable owner and an operational custodian.
4. Set required CI attributes: at minimum, identifier, environment, owner, location/account/subscription, criticality, and configuration source of truth.

Deliverable: CI taxonomy + in-scope asset list mapped to service criticality ¹.

2) Establish configuration baselines

1. Baseline definition: document the “approved state” for each CI class (OS build standards, network device settings, cloud guardrails, logging settings, encryption defaults, IAM constraints).
2. Baseline authority: approve baselines through your governance path (Change Advisory Board, security architecture review, or equivalent).
3. Baseline storage: keep baselines version-controlled and access-controlled (for example, in a controlled repository or configuration management tool).
4. Exception handling: define how deviations are requested, risk-accepted, time-bounded, and reviewed.

Deliverable: baseline standards + exception register tied to risk acceptance/ownership ¹.

3) Integrate configuration management with change management

1. Ticket linkage: require that configuration changes reference a change ticket (or equivalent tracked change record).
2. Approval rules: define which changes need peer review, security approval, or CAB approval based on CI criticality.
3. Testing expectations: require evidence of testing appropriate to the change type (e.g., non-prod validation, automated tests, staged rollout notes).
4. Rollback plan: require a rollback/backout method for changes impacting critical services.
5. Emergency change path: define what “emergency” means, who can approve, and how you do post-implementation review.

Deliverable: change procedure updates + sample change records demonstrating approvals and rollback planning ¹.

4) Implement drift detection and reconciliation

1. Choose detection methods: agent-based configuration monitoring, cloud config rules, network config backups/diffs, IaC drift detection, or endpoint management reporting.
2. Set alert thresholds: define what is “critical drift” versus “expected variance,” and route to the right on-call/team queue.
3. Reconcile inventory: run a periodic reconciliation between your inventory/CMDB and actual discovered assets.
4. Measure outcomes: track drift incidents, time to remediate, and repeat offenders (teams, tools, CI classes).

Deliverable: drift reports, remediation tickets, and reconciliation results that show ongoing operation ¹.

5) Lock down access and ensure traceability

1. Access control: restrict who can change production configuration, and require authenticated, logged access paths.
2. Segregation of duties (practical): avoid single-person “develop-approve-deploy” for high-risk configuration changes.
3. Logging: ensure configuration changes are logged and retained in a way that supports investigations.

Deliverable: access reviews for privileged groups, system logs or change logs showing traceability ¹.

6) Prove recoverability

1. Configuration backups: ensure device configs, critical system settings, and IaC repos are backed up and protected.
2. Restoration tests: test restoration from baseline/config backup as part of incident response exercises or operational runbooks.
3. Document rebuild paths: for key platforms, maintain “rebuild from scratch” runbooks that reference baselines.

Deliverable: restoration test evidence + runbooks mapped to critical services ¹.

Required evidence and artifacts to retain

Keep evidence that demonstrates both design (you wrote it) and operation (you did it).

Evidence type	What to retain	What it proves
Policy/standard	Configuration management policy; baseline standards; exception process	Control design and governance 1
Inventory / CMDB	CI list, ownership, criticality, relationships	You know what you manage 1
Baseline artifacts	Versioned baseline configs, templates, golden images, IaC modules	Approved “known-good” state 1
Change records	Tickets with approvals, implementation notes, testing proof, rollback plans	Controlled change and accountability 1
Drift detection	Alerts, reports, diffs, remediation tickets	Ongoing monitoring and response 1
Reconciliation outputs	CMDB vs discovery results, remediation actions	Inventory accuracy and lifecycle control 1
Access governance	Privileged access lists, access reviews, break-glass logs	Only authorized parties can change configs 1
Restore testing	Evidence of restore exercises and outcomes	You can recover known-good configurations 1

Practical note: Daydream is often used here as the system of record to map BAI10 to owned controls, assign evidence owners, and keep an audit-ready evidence trail across tooling changes.

Common exam/audit questions and hangups

Expect these themes:

• “Show me your source of truth.” If the CMDB is stale, you will get follow-up testing on asset completeness.
• “How do you prevent unauthorized changes?” Auditors will sample admin access, change approvals, and evidence that changes were logged.
• “How do you know baselines are followed?” They will ask for drift detection outputs and how quickly you remediate.
• “Do third parties make changes?” If yes, they will expect contractual/operational controls: ticketing, approval, and evidence delivery from the third party.
• “Show me an exception.” Weak exception governance is a frequent finding: missing owner sign-off, no expiry, no compensating controls.

Frequent implementation mistakes and how to avoid them

1. CMDB as a spreadsheet snapshot. Fix: implement discovery + reconciliation, and define who closes gaps.
2. Baselines without enforcement. Fix: connect baselines to drift detection and remediation workflows.
3. Change tickets that don’t match reality. Fix: require technical artifacts (diffs, pipeline logs, config commit references) to be attached or linked.
4. Emergency change path becomes the default. Fix: set clear criteria and require post-implementation review with documented approval.
5. Ignoring “configuration” in SaaS and IAM. Fix: treat identity policies, conditional access, logging settings, and SaaS admin configuration as CIs with baselines.

Enforcement context and risk implications

No public enforcement cases were provided in the available source catalog for COBIT BAI10. Treat BAI10 as an assurance expectation: weak configuration management typically manifests as outages, security incidents, audit findings, and delayed incident response because teams cannot prove what changed or restore known-good states ¹.

Practical 30/60/90-day execution plan

Use phases rather than calendar-day promises; adjust to your change velocity and tooling maturity.

First 30 days (stabilize and define)

• Set scope: critical production services and their supporting infrastructure.
• Publish a configuration management policy and RACI for CI ownership.
• Define CI classes and required attributes; stand up an initial authoritative inventory.
• Approve a minimum baseline set (logging, access, encryption defaults where applicable) and an exception workflow.

Next 60 days (connect to operations)

• Integrate change tickets with configuration changes (required fields, approvals, rollback notes).
• Implement drift detection for the highest-risk CI classes (cloud guardrails, IAM policies, network configs, critical server baselines).
• Run your first reconciliation between discovery and CMDB; open remediation tasks.

By 90 days (evidence-ready and repeatable)

• Produce an audit packet: sample change records, drift events with remediation, baseline approvals, exception reviews, and access reviews.
• Expand CI coverage to additional platforms and SaaS configurations.
• Add restore testing evidence tied to critical services and document rebuild runbooks.

Frequently Asked Questions

What counts as a “configuration item” for BAI10?

Any component whose settings affect security, availability, or compliance can be a CI: infrastructure, cloud resources, IAM policies, network devices, and critical application settings ¹.

Do we need a CMDB to satisfy BAI10?

You need an authoritative inventory with ownership, status, and traceability. A formal CMDB helps, but the requirement is the control outcome: complete and maintained configuration records ¹.

How do we handle configuration changes made by a third party?

Require changes to flow through your change control (or a contractually defined equivalent), with approval evidence, implementation logs, and post-change verification delivered back to you for retention ¹.

Is “infrastructure as code” enough on its own?

IaC is a strong control when it is the enforced path to production and you also monitor for drift. If engineers can still hotfix production outside IaC, you need detective controls and remediation workflows ¹.

What evidence is most persuasive in an audit?

Auditors respond well to traceable chains: baseline approval → change ticket approval → implementation artifact (commit/pipeline log) → post-change validation → drift monitoring output ¹.

How should we document exceptions without creating a paperwork trap?

Keep exceptions simple but strict: owner, scope, business justification, compensating controls, and a defined review point. Then show periodic review evidence and closure actions ¹.

Footnotes

1. ISACA COBIT overview; OSA COBIT 2019 objective mapping