BAI06: Managed IT Changes

BAI06: Managed IT Changes requires you to run a controlled, auditable change management process for production IT, from request through approval, testing, deployment, and post-implementation review. To operationalize it quickly, define change types and approval paths, enforce segregation of duties, standardize testing and rollback, and retain evidence that every material change followed the process ¹.

Key takeaways:

• Define “what is a change” and route it through a consistent workflow with risk-based approvals ².
• Prove operation with artifacts: tickets, approvals, test results, deployment logs, and PIRs mapped to BAI06 ³.
• Treat emergency changes as controlled exceptions with after-the-fact review and documentation ².

BAI06 is a requirement-level expectation for managing IT changes so your environment stays stable, secure, and supportable while still shipping updates. For most CCOs and GRC leads, the hard part is not writing a “change management policy.” The hard part is making sure every team uses the same gates (intake, risk assessment, approval, testing, implementation, documentation) and that you can prove it during an audit without scrambling.

This page translates the bai06: managed it changes requirement into an execution model you can roll out across application, infrastructure, and security changes. It assumes common enterprise tooling (ITSM/ticketing, CI/CD, repo-based infrastructure as code) but does not require any specific product. Your success criterion is straightforward: you can pick any meaningful production change from the last period and produce a complete evidence packet that shows who requested it, who approved it, what testing occurred, how it was deployed, what went wrong (if anything), and what you learned ¹.

Regulatory text

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

Operator interpretation: COBIT is a framework, but BAI06 functions like an examable requirement: you must implement a formal, repeatable change management capability with documented ownership, procedures, and evidence that it operates in practice ². Auditors will treat “we have a policy” as insufficient unless you can produce change records that show consistent execution ³.

Plain-English interpretation (what BAI06 expects)

BAI06 expects that you:

• Know what changed, where, and why (traceability from request to deployment).
• Control who can approve and who can implement (segregation of duties where feasible).
• Assess risk before implementation (impact, security, availability, customer effect).
• Test changes appropriately (including rollback/backout readiness).
• Implement predictably (planned windows, communications, monitoring).
• Learn from changes (post-implementation review when warranted).
• Treat emergencies as exceptions, not a loophole (document and review) ¹.

Who it applies to (entity + operational context)

Entities: Any enterprise IT organization using COBIT 2019 as a governance framework baseline ².

Operational scope (include at minimum):

• Production application changes (code, configuration, feature flags with material impact)
• Infrastructure changes (network, firewall, identity, cloud resources, endpoints)
• Security tooling changes (EDR policies, SIEM rules that affect detection/alerting)
• Data platform changes (schema migrations, permissions, retention settings)
• Third-party service changes under your control (SaaS admin configuration, SSO settings)

Common scoping decision: You do not need to route every low-risk non-production activity through the same rigor. You do need documented change classification so the organization can prove which changes require which gates ².

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

1) Establish ownership and RACI

• Name a Change Manager / Change Enablement owner (could be IT Ops, SRE, or ITSM).
• Define approver roles: service owner, security reviewer (for defined risk triggers), and a change advisory function for higher-risk changes.
• Document who can create, approve, schedule, implement, and close changes ².

Execution tip: If your org is small, separation can be “peer approval” plus independent post-review. Write that explicitly.

2) Define change types and mandatory workflow states

Create a taxonomy that drives approvals and evidence requirements:

• Standard change: pre-approved, low-risk, repeatable (e.g., routine patch class once you have proven controls).
• Normal change: default path; requires documented risk assessment and approvals.
• Emergency change: expedited; requires documented justification and after-the-fact review ².

Minimum workflow states to enforce in your ITSM or equivalent system:

1. Request logged
2. Classification + impacted services recorded
3. Risk assessment completed
4. Approvals captured
5. Implementation plan + rollback documented
6. Testing evidence attached/linked
7. Change implemented (with timestamps and implementer identity)
8. Validation/monitoring check completed
9. Closure with outcomes and links to incidents/problems ³

3) Implement risk-based approvals and security triggers

Define “if/then” triggers so teams don’t guess:

• If change affects authentication/authorization, encryption, logging, network boundaries, or privileged access, require a security review approval.
• If change affects regulated data flows or customer-facing uptime, require business/service owner approval.
• If change is high blast-radius (shared platform), require an additional approver (CAB or platform governance).

Keep the rules short, then enforce them in tooling through required fields and approval gates.

4) Standardize testing and release readiness

For each change type, define minimum testing evidence:

• Unit/integration test results or pipeline run link
• Staging validation notes (where applicable)
• Peer code review evidence for application/infrastructure-as-code changes
• Backout/rollback method validated (documented steps; for high-risk changes, a proof point)

Auditors don’t need your entire CI/CD design. They need proof that “testing happened and was appropriate for risk” ³.

5) Control implementation: scheduling, comms, and monitoring

Operational controls to implement:

• Maintenance windows or deployment scheduling rules for higher-risk services
• Required communication templates (stakeholders, support desk, incident management)
• Monitoring plan: what metrics/logs to watch and for how long after deployment
• Clear “stop/go” criteria and an escalation path if health checks fail

Tie change records to incidents. A repeated pattern of “changes cause outages but no PIR exists” is a predictable audit and operational failure mode.

6) Post-implementation review (PIR) and continual improvement

Define PIR triggers (risk-based):

• Emergency changes
• Changes that cause incidents, rollbacks, customer impact, or security events
• Repeated failed changes in a service area

PIR outputs should be concrete: corrective actions, control updates, runbook changes, monitoring improvements, and follow-up owners ².

7) Map evidence to BAI06 and keep it retrievable

Create an evidence map that tells an auditor exactly where to find proof for each BAI06 expectation:

• Policy/procedure location
• Tool of record (ITSM, Jira, ServiceNow, Git, CI/CD, cloud logs)
• Sample selection method (how you’ll produce a period sample quickly)
• Retention standard (match your internal record retention schedule)

Daydream fit: teams often lose time assembling evidence across ITSM + Git + CI/CD. Daydream becomes useful when you need a single control narrative and evidence checklist mapped to BAI06, with consistent sampling and auditor-ready packets across systems ¹.

Required evidence and artifacts to retain (exam-ready)

Use this as your “evidence packet” checklist:

Governance artifacts

• Change management policy and procedure, with defined scope and exceptions ²
• Change classification definitions and approval matrix
• RACI for change roles and responsibilities

Operational artifacts ²

• Change ticket or record with unique ID
• Risk assessment fields completed (impact, likelihood or qualitative rating, affected services)
• Approval evidence (names/roles, timestamps)
• Testing evidence (links to build/pipeline, test run outputs, peer review link)
• Implementation plan + rollback/backout plan
• Deployment evidence (change window, deploy logs, commit hashes, release notes)
• Validation evidence (monitoring checks, smoke test results)
• Closure notes and linkage to any incident/problem records
• PIR report for triggered cases ³

Common exam/audit questions and hangups

1. “Show me a sample of production changes and the full lifecycle evidence.” Expect sampling across apps, infrastructure, and security changes ³.
2. “How do you prevent unauthorized changes?” Auditors look for access controls plus process controls (approvals, peer review, logging) ².
3. “How do you handle emergency changes?” They will check justification and after-the-fact approvals/PIRs.
4. “How do you know your standard changes are truly low-risk?” You need criteria, and periodic review of the standard-change catalog.
5. “Do third parties make changes in your environment?” You must show oversight: how third-party changes are requested, approved, and evidenced when they affect your production services.

Frequent implementation mistakes (and how to avoid them)

Mistake 1: Policy exists, but engineering ships outside the system

Fix: Make the ticket ID required in CI/CD metadata, deployment tooling, or change calendar entries. If you can’t enforce technically, enforce procedurally with release manager checks.

Mistake 2: “Emergency” becomes the default path

Fix: Define what qualifies as emergency, require justification, and mandate PIR for emergency changes. Trend emergency volume by service and escalate repeated misuse.

Mistake 3: No consistent definition of “change”

Fix: Publish scoping examples (config changes, IAM permission edits, firewall rules, feature toggles with material impact). Align across IT, security, and product.

Mistake 4: Approvals are captured, but approvers have no context

Fix: Require minimum fields: impact summary, affected services, customer impact, test plan, rollback steps. Don’t let the ticket move forward without them.

Mistake 5: Evidence is scattered and expires

Fix: Link artifacts rather than copy/paste, but ensure links are durable and access-controlled. For critical items, attach immutable exports (PDF of PIR, pipeline summary) according to your retention rules.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this page does not list enforcement actions.

Risk-wise, weak change control reliably correlates with outages, security regressions, and audit findings because it breaks traceability and accountability. The compliance exposure usually presents as “control not designed effectively” (missing defined gates) or “control not operating effectively” (changes bypassing the workflow) ¹.

Practical 30/60/90-day execution plan

First 30 days (baseline + stop the bleeding)

• Appoint control owner and publish a one-page change RACI.
• Define change types (standard/normal/emergency) and an approval matrix.
• Pick a system of record for change tickets and require it for production changes.
• Start evidence mapping to BAI06: where each artifact lives and who can produce it ¹.

Days 31–60 (enforce gates + improve evidence quality)

• Implement required fields and approval steps in the ticket workflow.
• Add security review triggers for high-risk change categories.
• Standardize rollback plan requirements and minimum testing evidence by change type.
• Run an internal “mock audit” sampling of recent changes; fix gaps found.

Days 61–90 (prove operation + optimize)

• Establish PIR triggers and a lightweight PIR template; begin tracking actions to closure.
• Formalize a standard-change catalog and review criteria.
• Build recurring reporting: change failure themes, emergency change trends, bypass exceptions.
• Package “audit-ready change packets” for sampling. If you use Daydream, configure a BAI06 control workspace that ties procedure, RACI, and evidence checklists to your systems of record ¹.

Frequently Asked Questions

Do we need a Change Advisory Board (CAB) to meet BAI06?

Not always. You need defined approvals and governance for higher-risk changes; a CAB is one way to do that. If you do not use a CAB, document the alternative approver structure and show it operates consistently ².

How should we treat CI/CD deployments that happen multiple times per day?

Define which deployments qualify as “standard changes” versus “normal changes,” and require traceability from pipeline runs to approvals and testing evidence. Auditors will accept automation if the controls are explicit and evidenced ³.

What counts as “emergency change” in practice?

Emergency changes are for restoring service or addressing an urgent security or stability issue when the normal approval timeline would create unacceptable impact. Require written justification and an after-the-fact review so emergency does not become a bypass path ².

Do configuration changes in SaaS admin consoles fall under BAI06?

Yes if they affect production behavior, security posture, or data handling. Treat them as changes with tickets, approvals, and validation evidence, even if no code is deployed ².

How do we show segregation of duties in a small team?

Use peer review and independent approval where possible, then add after-the-fact review for edge cases. Document the constraint and show compensating controls in the workflow and evidence ².

What evidence do auditors ask for most often?

They usually ask for a sample of recent production changes with end-to-end proof: request, risk/impact, approvals, testing, deployment, validation, and closure. Prepare a repeatable “change packet” format so sampling is fast ³.

Footnotes

1. ISACA COBIT overview; OSA COBIT 2019 objective mapping

2. ISACA COBIT overview

3. OSA COBIT 2019 objective mapping