BAI11: Managed IT Projects

The bai11: managed it projects requirement expects you to run IT projects under a consistent, documented project management method with defined ownership, governance, controls, and retained evidence that projects deliver approved scope, schedule, budget, quality, and risk outcomes. Operationalize it by standardizing project intake, planning, delivery controls, and closeout artifacts, then mapping evidence to BAI11 for audit readiness. ¹

Key takeaways:

• Standardize one project delivery method and require it for all in-scope IT projects, including third-party-led work. ²
• Build an evidence spine: intake → approvals → plans → delivery controls → testing/acceptance → closeout. ³
• Make governance real with decision rights, stage gates, and documented exceptions tied to risk. ²

BAI11 sits in the “Build, Acquire and Implement” domain of COBIT 2019 and focuses on controlling how IT projects are selected, executed, and closed. For a Compliance Officer, CCO, or GRC lead, the fastest path to implement BAI11 is to treat it as an “audit-able project operating model” requirement. Auditors and regulators rarely want your preferred methodology; they want proof that your organization consistently governs project risk and delivery outcomes across teams, technologies, and third parties.

Most BAI11 gaps are not technical. They are operational: inconsistent project classification, undocumented approvals, weak change control, missing testing evidence, unclear accountability, and no reliable record of what was delivered versus what was approved. BAI11 also intersects directly with third-party risk management because system integrators, SaaS implementers, and contractors often run critical work without the same internal discipline unless you enforce it.

This page translates COBIT’s BAI11 expectation into a requirement-level playbook: who it applies to, what to implement, what evidence to retain, and how to answer exam questions without scrambling. Framework references are based on COBIT guidance sources. ¹

Regulatory text

Excerpt (provided): “COBIT 2019 objective BAI11 implementation expectation.” ²

Operator interpretation: You must be able to show that IT projects are managed under a defined approach with governance, planning, monitoring, and control activities that are executed consistently and leave traceable evidence from initiation through closure. Your “requirement” deliverable is not a single policy; it is a repeatable lifecycle plus proof it was followed. ¹

What an operator must do:

• Define project management ownership and decision rights (who approves, who escalates, who accepts). ²
• Require documented project artifacts at key points (intake, plan, execution, acceptance, closeout). ³
• Maintain evidence that risks, changes, dependencies, and quality controls were actively managed. ²

Plain-English interpretation (what BAI11 is “really asking”)

BAI11 is asking for two things you can prove on demand:

1. A standard way to run IT projects (your org’s project “rules of the road”), used consistently across teams.
2. A complete audit trail showing that each in-scope project followed those rules or had documented, approved exceptions.

If you can pull a sample of completed projects and show consistent artifacts, approvals, and control execution, you are functionally meeting the requirement.

Who it applies to

Entities: Any enterprise IT organization using COBIT as a governance framework, including regulated organizations that map COBIT to their control environment. ²

Operational context (in scope):

• Internal IT projects: infrastructure, identity, network changes, endpoint programs, ERP/CRM implementations, cloud migrations.
• Security projects: SIEM deployment, PAM rollout, segmentation initiatives (often high-risk even if “just IT”).
• Product/engineering delivery where IT controls and production changes are involved (depending on your governance model).
• Third-party executed projects: system integrators, managed service providers, implementation partners, contractors.

Out of scope (only if you define it):

• Routine operational changes handled under change management (but be careful; large “changes” often behave like projects).
• Small work items below a defined materiality threshold, if you document criteria and still maintain basic controls.

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

1) Define what counts as a “project” and what is “in-scope”

Create a project classification standard:

• Criteria: spend, duration, production impact, data sensitivity, customer impact, regulatory impact, third-party involvement.
• Tiers: e.g., Standard / High-risk / Strategic (names don’t matter; consistency does).

Deliverable: a one-page classification matrix, owned by IT governance with GRC review.

2) Assign governance and decision rights

Minimum roles to document:

• Executive sponsor (accountable for outcomes and funding)
• Project owner / PM (accountable for delivery management)
• Product/system owner (accepts the solution into operations)
• Risk/compliance reviewer (advises, sets required controls)
• Change authority (CAB or equivalent for production impacts)

Deliverable: RACI plus a short “approval authority” table (who can approve scope changes, timeline extensions, and go-live).

3) Standardize the project lifecycle and stage gates

Define required stage gates with entry/exit criteria. Keep it lightweight but enforceable:

• Intake/Initiation: business case, high-level scope, initial risk screen, resourcing.
• Planning: project plan, milestones, budget, RAID log (risks/actions/issues/decisions), security & compliance requirements list.
• Build/Execute: change control for scope/timeline/budget; status reporting; dependency management; third-party oversight.
• Test/Validate: test plan/results; security testing where applicable; data migration validation.
• Go-live/Transition: cutover plan; backout plan; operational readiness; approvals.
• Closeout: acceptance sign-off; post-implementation review; lessons learned; benefits tracking approach.

Deliverable: lifecycle SOP with required artifacts per gate.

4) Put delivery controls where projects fail in practice

Controls to implement and evidence:

• Scope control: baseline requirements; log and approve scope changes.
• Schedule and budget monitoring: status reports with variance and remediation actions.
• Risk management: RAID log with owners and due dates; escalation rules.
• Quality management: testing evidence and defined acceptance criteria.
• Security-by-design: security requirements captured early; validation before go-live.
• Third-party controls: SOW aligned to your lifecycle artifacts; vendor deliverables mapped to your gates; acceptance criteria in contract exhibits.

This is where Daydream can help without adding bureaucracy: use a single control map that ties each artifact to BAI11 so project teams upload once and GRC can sample evidence quickly.

5) Implement a “documented exception” mechanism

Projects will deviate. Your requirement is to ensure deviations are:

• Explicit (what requirement is not met)
• Justified (why)
• Risk-assessed (what risk is introduced)
• Approved (who accepted the risk)
• Time-bounded (when it expires or how it will be remediated)

Deliverable: exception template plus an exception register.

6) Build an audit sampling pack (your “fast proof” kit)

Pick a representative sample across:

• High-risk vs standard projects
• Different IT towers (apps, infra, security)
• Third-party involvement vs internal-only

For each sampled project, assemble the minimum evidence set listed below. This becomes your repeatable audit response pattern.

Required evidence and artifacts to retain (practical checklist)

Keep artifacts in a system of record (PPM tool, ticketing system, GRC repository). The key is integrity and retrievability.

Governance

• Project intake record and classification result
• Sponsor approval / funding approval
• RACI / role assignments

Planning

• Project charter or initiation document
• Project plan / milestone plan
• Budget estimate and approval (if applicable)
• RAID log (initial and updated)
• Requirements trace (high level is acceptable for smaller projects)

Execution and control

• Status reports (cadence based on risk tier)
• Change requests with approvals (scope/schedule/budget)
• Decision log (key decisions and approvers)
• Third-party SOW, deliverables list, and acceptance criteria (if used)

Testing and acceptance

• Test plan and test results summary
• UAT sign-off or business acceptance
• Security validation evidence appropriate to the change (document what was required and what was done)

Go-live and closeout

• Cutover plan and backout plan
• Go-live approval
• Operational readiness checklist (training, monitoring, support handoff)
• Closeout report and lessons learned
• Post-implementation review actions

Common exam/audit questions and hangups (and how to answer)

Auditor question	What they are testing	Strong answer pattern
“Show me how you ensure projects are consistently managed.”	Existence and adoption of a standard method	Provide lifecycle SOP + 2–3 project examples showing stage gates met
“How do you control scope changes?”	Change discipline	Show baseline scope + change log + approvals + updated plan
“How do you manage project risk?”	Active risk management	Show RAID log with owners, aging, escalation evidence
“How do third parties follow your process?”	Control extension to suppliers	Show SOW clauses, deliverable mapping to gates, and acceptance sign-offs
“Who signs off production release?”	Decision rights	Provide go-live approval record and CAB tie-in where applicable

Hangups that trigger findings:

• “We do Agile, so we don’t have charters.” Fine, but you still need equivalent evidence (intake, approvals, backlog governance, acceptance).
• “The PM left and files are on their laptop.” That is a records management failure; fix the system of record.

Frequent implementation mistakes and how to avoid them

1. Treating BAI11 as a policy-only control.
   Fix: implement an artifact checklist and enforce it with stage gates.

2. No defined project population.
   Fix: publish classification criteria and reconcile it to your portfolio tool or intake channel.

3. Third parties run projects “their way.”
   Fix: contractually require your minimum artifacts and approvals; include them as deliverables tied to payment milestones.

4. Testing evidence is informal.
   Fix: require a test summary and explicit acceptance criteria even for infrastructure projects.

5. Exceptions are verbal.
   Fix: require written exceptions with risk acceptance.

Risk implications (why this matters in real operations)

Weak project controls translate into predictable operational failures: unapproved scope growth, rushed go-lives, security requirements discovered late, and outages with no accountable decision trail. In regulated environments, those failures become audit issues because you cannot demonstrate control operation, even if outcomes were acceptable. The most common risk factor is missing evidence that BAI11 is actually operating. ¹

Practical 30/60/90-day execution plan

First 30 days (stabilize and define)

• Name BAI11 control owner (IT governance or PMO) and GRC reviewer.
• Define “project” and classification tiers; publish the matrix.
• Draft the lifecycle SOP and artifact checklist (minimum viable).
• Pick the system of record for artifacts and set folder/tool standards.

Days 31–60 (enforce on new work)

• Turn on stage gates for new in-scope projects.
• Train PMs, system owners, and key third parties on required artifacts.
• Implement exception process and register.
• Start monthly sampling: one completed or late-stage project per major IT area.

Days 61–90 (prove operation and close gaps)

• Perform an internal “mini-audit” using your sampling pack.
• Fix systemic misses (testing evidence, approvals, third-party deliverables).
• Tie reporting to governance: portfolio review includes risk, exceptions, and gate compliance.
• Map each artifact and control step to BAI11 in your GRC tool (Daydream or equivalent) to speed audits and reduce rework.

Frequently Asked Questions

Does BAI11 require a specific project methodology (Waterfall vs Agile)?

No specific method is mandated by the provided COBIT objective summary, but you must have a defined approach and evidence that projects follow it. For Agile, treat epics/releases as the unit of governance and keep approvals, risk logs, and acceptance records.

What projects should be sampled for audit evidence?

Sample across risk tiers and delivery types, especially projects that touch production, sensitive data, or have third-party delivery. Auditors gain confidence when you can show consistency across different teams.

How do I enforce BAI11 on third-party-led implementations?

Put minimum artifact requirements into the SOW and make stage-gate outputs contractual deliverables. Require your go-live approval and acceptance criteria regardless of the third party’s internal method.

What is the smallest “evidence set” that still satisfies exam expectations?

Intake/classification, sponsor approval, plan/milestones, RAID log, change approvals, testing/acceptance evidence, and closeout sign-off. If you cannot produce these quickly, your control will read as “not operating.”

How do we handle emergency work that behaves like a project?

Route it through an exception path: document why normal gates were bypassed, who approved, what risk was accepted, and what retrospective controls were completed after stabilization.

Where does BAI11 intersect with change management?

Projects create change. Use change management for individual production releases, and use BAI11 to govern the overall delivery lifecycle, risk, and acceptance from initiation to handoff.

Footnotes

1. ISACA COBIT overview; OSA COBIT 2019 objective mapping

2. ISACA COBIT overview

3. OSA COBIT 2019 objective mapping