BAI01: Managed Programs and Projects

BAI01 in COBIT 2019 is the expectation that your organization manages programs and projects as controlled delivery vehicles, not as ad hoc “work.” For a Compliance Officer, CCO, or GRC lead, the fastest path is to treat BAI01 as a governance-and-evidence requirement: you must be able to show who is accountable for delivery decisions, how projects are approved and prioritized, how execution is monitored, and how you confirm outcomes at closure.

BAI01 is also where many organizations get stuck in audits because “project management” exists informally in tools and meetings, but the control record is thin. Auditors and regulators (and internal audit) do not need a perfect PMO. They need a consistent lifecycle with stage gates, artifacts that match your risk profile, and proof that exceptions are identified and handled through defined decision rights.

This page gives requirement-level implementation guidance you can put into operation quickly: scope and applicability, step-by-step operating model, the evidence set to retain, common audit questions, and a practical execution plan. COBIT is a framework, not a law, so your job is to implement it in a way that is defensible, testable, and aligned to how your technology changes introduce operational, security, and compliance risk (ISACA COBIT overview; OSA COBIT 2019 objective mapping).

Regulatory text

Framework excerpt (provided): “COBIT 2019 objective BAI01 implementation expectation.” (ISACA COBIT overview; OSA COBIT 2019 objective mapping)

Operator interpretation of the excerpt:
BAI01 expects you to run programs and projects under an intentional governance system. In practice, that means:

• Defined ownership and decision rights for project selection, funding, scope changes, risk acceptance, and go-live decisions.
• A consistent lifecycle (intake → approval → planning → execution → monitoring → closure) with stage gates proportional to risk.
• Documented procedures and evidence that you follow the lifecycle, not merely that it exists on paper. The minimum control objective is to prevent uncontrolled changes, unmanaged scope, and “invisible” risk introduced through poorly governed delivery (ISACA COBIT overview; OSA COBIT 2019 objective mapping).

Plain-English interpretation (what BAI01 requires)

You must be able to answer, with evidence, these questions for any material initiative:

1. Why are we doing this? (business case, expected outcomes/benefits)
2. Who owns it? (sponsor, product/service owner, delivery owner, risk/security partners)
3. How will it be delivered? (plan, milestones, resourcing, dependencies)
4. How are risks and issues controlled? (RAID, change control, stage gates)
5. How do we know it’s done and working? (acceptance, transition, closure, benefits tracking)

For compliance, BAI01 is less about “PM maturity” and more about preventing unmanaged operational risk that can cascade into security incidents, service outages, data handling failures, and control breakdowns.

Who it applies to

Entity scope: Enterprise IT organizations and any function delivering technology change (ISACA COBIT overview; OSA COBIT 2019 objective mapping).

Operational scope (practical):

• Internal IT projects (infrastructure, identity, network, endpoint, migrations)
• Software delivery (product engineering, platform, data, analytics)
• Security programs (IAM modernization, SIEM rollout, segmentation)
• Business-led initiatives with IT impact (ERP/CRM changes, workflow automation)
• Third-party implementations where your organization is still accountable for outcomes (system integrators, SaaS onboarding)

Trigger rule (useful in practice): treat work as “BAI01-governed” when it changes production systems, control design, customer data flows, or critical services, or when it requires cross-team funding/coordination.

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

1) Establish governance ownership and a delivery policy

• Name an executive sponsor role (business) and a delivery owner role (IT/engineering/PMO) for each program/project.
• Publish a short Program & Project Governance Standard: lifecycle stages, required artifacts, approval authorities, and tool-of-record expectations.
• Map governance to existing forums (Architecture Review Board, Change Advisory Board, Security review, Data governance) so decisions have a home.

Practical control move: put the standard under document control with a named owner and review cadence, and map evidence to BAI01 (ISACA COBIT overview; OSA COBIT 2019 objective mapping).

2) Implement an intake and prioritization process

• Create a single intake channel (ticket form, portfolio tool, or GRC workflow).
• Minimum intake fields: objective, impacted systems, data classification, regulatory/contract impact, rough timeline, and owner.
• Run prioritization via a portfolio forum with documented decisions (approve/defer/reject).

Evidence tip: retain the agenda and decision record for the forum. Auditors often accept this as proof of consistent governance when it is repeatable and complete.

3) Define stage gates proportional to risk

Use stage gates so higher-risk work gets more scrutiny without blocking low-risk changes.

A workable gate model:

• Gate A: Initiation approval (charter + sponsor + funding/priority)
• Gate B: Plan approval (scope baseline, schedule, resourcing, dependencies, security/compliance requirements)
• Gate C: Build/execute control (status reporting + RAID + change control)
• Gate D: Go-live readiness (testing, security sign-off as applicable, rollback plan, operational readiness)
• Gate E: Closure (acceptance + lessons learned + benefits plan)

Proportionality rule: small projects can combine gates, but you still need a documented decision and minimum artifacts.

4) Standardize core artifacts (templates are a control)

Minimum templates to create and enforce:

• Project/Program Charter (objective, scope, owners, funding, success criteria)
• Integrated Plan (milestones, dependencies, resourcing)
• RAID Log (risks, assumptions, issues, decisions) with owners and dates
• Status Report (traffic light + narrative + upcoming milestones)
• Change Control Record for scope/schedule/budget changes (approval captured)
• Go-live/Release Readiness Checklist (testing evidence references, cutover steps, rollback)
• Closure Report (delivered scope, acceptance, operational handoff, open risks, benefits tracking)

5) Embed risk, security, and compliance into delivery motions

• Add required checkpoints: data classification validation, third-party impact check, control impact assessment, and security review routing.
• Define a “no-go” list: conditions that require escalation (unmitigated critical risks, missing rollback plan, unresolved high-severity defects, missing sign-offs where required).

What auditors want: proof that control-impacting changes follow a controlled path, and exceptions are documented and approved.

6) Define reporting and escalation paths

• Portfolio-level reporting: top risks, schedule health, dependency hotspots, and delivery capacity constraints.
• Escalation: when a project misses a milestone, hits a risk threshold, or requests scope increases, the route and approver must be clear.

7) Close the loop with transition and benefits realization

BAI01 does not stop at “go-live.”

• Require operational acceptance (runbooks, monitoring, support model, SLO/SLA expectations if applicable).
• Track benefits: confirm the KPI/benefit owner and when you will measure outcomes.

Required evidence and artifacts to retain (audit-ready set)

Maintain a BAI01 evidence binder (folder or GRC record) per program/project for material work:

Evidence item	Purpose	Common owner
Governance standard + lifecycle description	Shows defined process	PMO / IT Governance
Portfolio intake record	Shows controlled initiation	Demand/Portfolio
Charter + approvals	Shows accountability and authorization	Sponsor / Delivery owner
Plan + baseline	Shows disciplined planning	PM/Program manager
RAID log + decisions	Shows active risk/issue control	PM + stakeholders
Stage gate sign-offs	Shows governance operating	Governance chair
Testing and readiness references	Shows go-live control	Engineering/QA/Ops
Change approvals for scope/time/cost	Shows change control	Sponsor/Steering
Closure report + handoff	Shows completion and transition	PM/Ops owner

Control expectation to emphasize: document control ownership, procedures, and evidence mapped to BAI01 (ISACA COBIT overview; OSA COBIT 2019 objective mapping).

Common exam/audit questions and hangups

1. “Show me how projects are approved and prioritized.”
   Hangup: decisions happen in chat or email with no retained record.
2. “How do you know required security/compliance activities occurred?”
   Hangup: security reviews are inconsistent across teams or not tied to stage gates.
3. “How do you manage scope creep and schedule slips?”
   Hangup: no formal change control or sponsor re-approval.
4. “How do you confirm operational readiness?”
   Hangup: go-live without runbooks, monitoring, or support ownership.
5. “Where is your evidence that the process is followed?”
   Hangup: templates exist but no one uses them, or artifacts vary per team.

Frequent implementation mistakes (and how to avoid them)

• Mistake: PMO paperwork with no operating control.
  Fix: test a sample of projects monthly and record pass/fail on required artifacts.
• Mistake: One-size-fits-all gates that teams bypass.
  Fix: define a lightweight track for low-risk work and a full track for material changes.
• Mistake: Governance forums exist but don’t produce decision records.
  Fix: require a decision log as the meeting output.
• Mistake: Treating third-party implementations as “owned by the vendor.”
  Fix: keep internal accountability; require the same stage gates and acceptance criteria.

Enforcement context and risk implications

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

Risk-wise, BAI01 gaps tend to show up as:

• production incidents from poorly coordinated releases,
• security control regressions during migrations,
• untracked third-party delivery risk,
• weak audit trails for why material changes were approved.

For regulated environments, those outcomes can become reportable incidents or drive negative audit opinions. Your defensibility comes from repeatable governance and retained evidence (ISACA COBIT overview; OSA COBIT 2019 objective mapping).

Practical execution plan (30/60/90 days)

First 30 days (stabilize and make it testable)

• Appoint BAI01 control owner and RACI for sponsor, delivery owner, governance chair.
• Publish the lifecycle with stage gates and a minimum artifact list.
• Build templates (charter, RAID, status, gate sign-off, closure).
• Start an evidence folder structure and a simple project register.
• Pilot on a small set of active projects and collect gaps.

Next 60 days (operationalize across teams)

• Stand up (or formalize) a portfolio forum with documented decisions.
• Integrate security/compliance checkpoints into gates and intake routing.
• Add a lightweight internal testing routine: sample projects, verify artifacts, track exceptions.
• Train delivery leads and sponsors on approval expectations and change control.

By 90 days (prove consistent operation)

• Expand to all in-scope work (define “in-scope” criteria and publish it).
• Produce a quarterly portfolio report with risk and delivery health.
• Run a mini internal audit: evidence completeness, gate adherence, exception handling.
• If you use Daydream, centralize artifact collection, ownership, and evidence mapping so BAI01 testing becomes a workflow instead of a document chase.

Frequently Asked Questions

Do I need a formal PMO to satisfy BAI01?

No. You need defined governance, stage gates, and evidence that the process operates consistently. A small organization can meet BAI01 with lightweight templates and documented approvals.

How do we handle agile teams that don’t use traditional project plans?

Keep the governance outcomes the same: clear ownership, prioritized backlog approval, RAID tracking, and go-live readiness. Accept agile artifacts (epics, sprint plans, release checklists) if they map to the required evidence.

What counts as “evidence” for stage gate approvals?

Approved records in a system of record, signed meeting minutes, or a decision log that identifies the approver, date, and decision. Avoid relying on transient chat messages.

How should third-party work fit into BAI01?

Put third-party delivered initiatives through the same intake, gates, and acceptance criteria. The third party can produce artifacts, but your internal owners must approve and retain them.

What’s the minimum artifact set auditors expect to see?

A charter or intake approval, a plan or delivery roadmap, an active RAID log, documented stage gate decisions, and a closure or operational handoff record. The exact format can vary, but the control outcomes must be clear and consistent.

How do we show benefits realization without building a new KPI program?

Capture expected outcomes in the charter and assign an owner. At closure, document the measurement approach and where the metric will be reported (even if it’s in an existing business dashboard).