APO02: Managed Strategy

To meet the apo02: managed strategy requirement, you need a documented, approved, and maintained enterprise (or IT) strategy that is clearly linked to business goals, translated into executable roadmaps, and governed through defined ownership, review cadence, and evidence of decision-making. Operationalize APO02 by assigning accountable owners, running a repeatable strategy cycle, and retaining artifacts that prove strategy-to-execution alignment.

Key takeaways:

• Strategy must be explicitly linked to business objectives and translated into funded roadmaps and measurable outcomes.
• Auditors look for governance: ownership, approvals, review triggers, and decision records that show the strategy is actively managed.
• Evidence wins: maintain a minimum evidence bundle per cycle (inputs, approvals, outputs, and retention location).

APO02 (“Managed Strategy”) is where many governance programs become real, or fail quietly. Policies, standards, and control catalogs do not substitute for an explicit strategy that ties business direction to technology direction, and then ties that direction to investment decisions and execution plans. APO02 expects you to manage strategy as an operating process: define it, approve it, communicate it, keep it current, and prove it influenced priorities and funding. ¹

For a Compliance Officer, CCO, or GRC lead, the fastest path is to treat APO02 like a control with a fixed evidence set. You need clear accountability (who owns the strategy and who approves it), a defined strategy lifecycle (inputs → decisions → outputs), and a traceable link from strategy statements to roadmaps, project intake, and portfolio governance. ²

This page gives requirement-level implementation guidance you can implement without reinventing enterprise architecture or PMO. It focuses on what examiners, auditors, and customer diligence teams usually ask: “Show me the current strategy, who approved it, how it was reviewed, and where it shows up in what you built and funded.” ²

Requirement: APO02 managed strategy (plain-English meaning)

Plain-English interpretation: You must run a disciplined strategy management process for IT/digital that (1) aligns to business goals, (2) produces actionable roadmaps and investment priorities, and (3) is governed with clear ownership, approvals, and ongoing maintenance. The strategy cannot be a slide deck that never changes; it must be a living decision framework that drives the portfolio. ²

What “good” looks like in practice

• A current strategy document that states goals, scope, and strategic themes, mapped to business objectives.
• A roadmap (or portfolio plan) that translates themes into initiatives, sequencing, dependencies, and outcomes.
• Defined governance: who proposes updates, who approves, what triggers a refresh, and how exceptions are handled.
• Evidence that strategy influenced decisions (project intake criteria, investment approvals, de-prioritization decisions, and architecture standards). ²

Regulatory text

Provided excerpt (framework expectation): “COBIT 2019 objective APO02 implementation expectation.” ³

Operator translation: Treat this as a requirement to establish, maintain, and govern an enterprise/IT strategy as an operational capability. You should be able to demonstrate:

1. strategy definition and alignment to enterprise objectives,
2. strategy approval and communication,
3. translation into roadmaps and investment decisions, and
4. ongoing monitoring and refresh based on defined triggers. ²

Who this applies to (entity and operational context)

Applies to: Enterprise IT organizations and any organization using COBIT as a governance baseline, including regulated entities and SaaS providers adopting COBIT for customer assurance. ¹

Operational contexts where APO02 becomes “exam critical”:

• Material technology transformation programs (cloud migrations, core platform rebuilds, major security uplift).
• Heavy third party dependency (outsourced infrastructure, critical SaaS, MSPs) where strategy must address concentration risk and exit paths.
• M&A, rapid growth, or product expansion where priorities shift and strategy needs controlled updates.
• Audit or customer diligence environments where you must explain how technology decisions trace back to business intent. ²

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

Treat APO02 as a control you can run on a defined cadence, with named owners and a standard evidence bundle. A workable implementation has seven steps.

Step 1: Assign accountable ownership and approval authority

• Name an APO02 Control Owner (often CIO, Head of Enterprise Architecture, or VP Technology Strategy).
• Name an Approver (executive steering committee, CIO + business exec, or equivalent governance body).
• Define consult/inform roles: Finance (funding), Security (risk posture), Product (demand), Procurement (third party commitments). ²

Artifact: Strategy governance RACI and approval matrix.

Step 2: Define the strategy lifecycle (inputs → decisions → outputs)

Document the operating process so it can be repeated:

• Inputs: business plan, risk register themes, major incidents, audit findings, architecture constraints, third party contracts, capacity/skills constraints.
• Decisions: strategic themes, target state, priorities, investment guardrails, risk appetite alignment.
• Outputs: strategy document, roadmap, portfolio guardrails, comms plan, exception process. ²

Artifact: “Requirement control card” (objective, owner, trigger events, execution steps, exception rules). ²

Step 3: Write or refresh the strategy (keep it operational)

Avoid vague statements. Your strategy should include:

• Scope (enterprise-wide vs business unit vs platform).
• Strategic themes (each with intent and measurable outcomes defined by your organization).
• Target state principles (architecture, data, security, resilience expectations).
• Constraints and assumptions (key dependencies, third party lock-in risks, skills gaps). ²

Practical tip: Keep “vision” content short; put effort into “how decisions get made” and “what gets funded.”

Step 4: Translate strategy into an executable roadmap and portfolio guardrails

You need a bridge from strategy to work intake:

• Roadmap: initiatives, sequencing, dependencies, and ownership.
• Portfolio guardrails: criteria that portfolio governance uses to approve/deny work (alignment scoring, architectural fit, risk impact, operational readiness).
• Funding linkage: show how major initiatives are planned and approved within your budgeting model. ²

Artifacts: Roadmap, portfolio prioritization criteria, investment/steering minutes.

Step 5: Establish review triggers and an exception process

Define what forces a strategy review. Examples: major regulatory change, material security incident, significant third party failure, major product shift, or budget reset. ²

Define exceptions: who can approve deviations from strategy and what documentation is required (business justification, risk acceptance, compensating controls, time-bound remediation).

Artifacts: Strategy refresh triggers, exception register, signed approvals.

Step 6: Communicate the strategy to operators and affected stakeholders

Auditors often test whether the strategy is “known” by the people executing it. Communication can be lightweight but must be provable:

• Publish in a controlled repository.
• Brief portfolio governance groups and key delivery leaders.
• Align architecture standards and security roadmaps to it. ²

Artifacts: Distribution list, briefing deck, attendance/acknowledgements, repository link and version history.

Step 7: Run control health checks and track remediation to closure

Strategy controls fail through drift: roadmaps change informally, approvals are skipped, or evidence disappears. Build a recurring check that verifies:

• strategy is current and approved,
• roadmap exists and is used in intake,
• exceptions are documented, and
• action items are closed with proof. ²

Artifact: Control health check log and remediation tracker with validated closure evidence.

Required evidence and artifacts to retain (minimum evidence bundle)

Use a standardized “evidence bundle” so you can answer audits quickly. ²

Evidence item	What it proves	Owner	Retention note
Approved strategy (versioned)	Strategy exists, is current, and has governance	Control Owner	Keep version history and approvals
Strategy-to-business mapping	Alignment to enterprise objectives	Strategy/EA	Link to business goals/OKRs as your org defines them
Roadmap / portfolio plan	Translation to execution	PMO/Portfolio	Include dates and ownership as applicable
Steering/approval minutes	Decisions, prioritization, funding direction	Governance chair	Store agendas, attendees, and decision records
Exception register + approvals	Controlled deviation	Control Owner	Include rationale and time bounds
Communications evidence	Strategy was communicated	Strategy/PMO	Briefing record and distribution evidence
Control health check + remediation	Ongoing operation	GRC/Control Owner	Track to validated closure

Common exam/audit questions and hangups

What auditors ask (and what to show):

1. “Who owns the strategy and who approves it?” → RACI + latest approval record.
2. “How do you know delivery aligns to strategy?” → intake criteria + sample approvals mapped to themes.
3. “How is strategy kept current?” → triggers + evidence of refresh decisions.
4. “How are deviations handled?” → exception workflow + example exception with sign-off. ²

Hangups that create findings:

• Strategy exists but lacks approval evidence.
• Roadmap exists but portfolio decisions are inconsistent with it.
• Strategy updates occur but are not version-controlled, so you cannot prove what was “in effect” at a point in time.

Frequent implementation mistakes (and how to avoid them)

1. Mistake: Strategy is aspirational and not decision-oriented.
   Fix: Add explicit prioritization rules and investment guardrails tied to governance decisions. ²

2. Mistake: No defined triggers for refresh.
   Fix: Document triggers and require a decision record even when the outcome is “no change.”

3. Mistake: Evidence scattered across inboxes and chat.
   Fix: Define the evidence bundle and a single system of record for approvals and minutes. ²

4. Mistake: Strategy owned by IT only, with weak business linkage.
   Fix: Require business sponsor participation in approvals and maintain an explicit mapping to business objectives. ²

Enforcement context and risk implications

No public enforcement cases were provided in the available source catalog for this requirement, and COBIT is a framework rather than a regulator. Your risk is indirect but real: weak strategy governance commonly drives audit findings around governance, investment oversight, and unmanaged technology risk because you cannot show rational prioritization, controlled exceptions, or sustained oversight. ²

Practical execution plan (30/60/90-day)

You asked for speed. Use these phases as a sprint plan for standing up APO02 without boiling the ocean.

First 30 days: Stabilize governance and evidence

• Appoint APO02 owner, approver body, and RACI.
• Publish the requirement control card (objective, triggers, steps, exceptions). ²
• Inventory existing strategy artifacts and decide what is “current.”
• Create the minimum evidence bundle template and a retention location. ²

Days 31–60: Make strategy executable

• Produce a strategy-to-business mapping that leadership will sign.
• Create or refresh the roadmap and connect it to intake/prioritization criteria.
• Stand up exception handling (register + approval workflow).
• Run one governance session that produces minutes and decisions you can retain.

Days 61–90: Prove operation and close gaps

• Run a control health check; record gaps as remediation items with owners and due dates. ²
• Test audit readiness: pull a complete evidence bundle for the latest cycle within a short turnaround.
• Socialize with PMO, Architecture, Security, Procurement, and third party owners so the strategy shows up in delivery and sourcing decisions.

Where Daydream fits naturally: If you struggle with repeatability and evidence assembly, Daydream can manage the APO02 control card, schedule health checks, and standardize evidence bundles so audits and customer diligence requests do not become a fire drill.

Frequently Asked Questions

Do I need a single enterprise strategy document, or can I have multiple strategies (security, data, cloud)?

Multiple is fine if you can show governance, alignment, and a consistent roadmap/portfolio linkage across them. Auditors care more about traceability and approvals than document count. ²

What is the minimum “approval” that will satisfy APO02?

You need an identifiable approver and a retrievable approval record tied to a specific version. A meeting minute with a decision record can work if it clearly approves the strategy artifact and scope. ²

How do I prove the strategy is actually used to make decisions?

Show portfolio intake criteria mapped to strategic themes and provide a sample of funded and rejected initiatives with the rationale captured in steering minutes. The linkage must be traceable in artifacts, not just explained verbally. ²

What if the business changes frequently and the roadmap is always shifting?

Define explicit refresh triggers and keep versioned roadmaps with decision records. The control is about managed change, not preventing change. ²

How does APO02 relate to third party risk management?

Your strategy should reflect major third party dependencies, sourcing principles, and exit considerations where concentration risk exists. Keep evidence that sourcing decisions and contract renewals align with strategic direction. ²

We have strategy slides but no formal exception process. Is that a real gap?

Yes, because teams will deviate under delivery pressure, and you need a controlled way to approve deviations with documented risk acceptance. Build a lightweight exception register and require sign-off. ²

Footnotes

1. ISACA COBIT overview

2. ISACA COBIT usage guidance

3. ISACA COBIT overview; Source: OSA COBIT 2019 objective mapping