APO08: Managed Relationships

The apo08: managed relationships requirement expects you to formally manage relationships between IT and internal/external stakeholders so expectations, accountability, and communication are clear and measurable. Operationalize it by defining relationship owners, stakeholder maps, engagement cadences, service expectations, and evidence that issues and feedback flow into governance and improvement ¹.

Key takeaways:

• Assign relationship ownership and build a stakeholder register tied to services and outcomes ².
• Standardize engagement: communication plans, escalation paths, and feedback loops that trigger action ³.
• Keep evidence: meeting artifacts, decisions, issue logs, satisfaction signals, and improvement actions mapped to APO08 ².

APO08: Managed Relationships is where governance becomes operational: it requires you to manage the “human interface” between IT and the parties who depend on IT services. That includes business units, executives, audit/compliance, and third parties such as outsourcers, cloud providers, consultants, and software providers. The control objective is simple: relationships should not be ad hoc, personality-driven, or dependent on tribal knowledge. They should be owned, structured, measurable, and reviewable ².

For a Compliance Officer, CCO, or GRC lead, APO08 is often tested indirectly. Auditors rarely ask “show me APO08”; they ask why expectations were unclear, why escalations failed, or why recurring issues were never addressed. If you can show defined relationship roles, consistent communications, and documented follow-through, you can usually satisfy APO08 even in a messy environment ³.

This page gives requirement-level implementation guidance you can execute quickly: who owns what, what processes to set up, what evidence to retain, and what exam teams tend to challenge. It is written for teams implementing COBIT-aligned governance ².

Regulatory text

Framework excerpt (provided): “COBIT 2019 objective APO08 implementation expectation.” ¹

Operator interpretation: APO08 expects you to run stakeholder relationships as a managed process, with clear ownership, defined interaction models, and evidence that communications, escalations, and feedback produce decisions and improvements ². In practice, you must be able to demonstrate:

• You know who your stakeholders are and what they need from IT.
• You have named owners for those relationships.
• You communicate routinely, not only during incidents.
• You track issues, risks, and dissatisfaction, and you act on them through governance channels ³.

Plain-English interpretation (what the requirement really means)

APO08: Managed Relationships means you treat stakeholder trust, expectations, and communications as a control surface. If the relationship fails, controls fail: approvals stall, incidents become political, risk acceptance becomes ambiguous, and third-party dependencies surprise you.

Think of APO08 as three deliverables you must keep continuously current:

1. Relationship structure: who owns the relationship, who is consulted, who approves, and who gets notified.
2. Engagement mechanics: what gets discussed, how often, and how escalations work.
3. Evidence of management: meeting outputs, decisions, issue handling, and improvements tied to stakeholder needs ².

Who it applies to (entity and operational context)

APO08 applies to enterprise IT organizations and the governance functions that oversee them, including GRC and security governance teams ².

Operationally, you should scope APO08 across:

• Internal stakeholders: executive sponsors, business/product owners, finance, HR, legal, compliance, internal audit, privacy, and security.
• External stakeholders (third parties): key technology and service providers, managed service providers, outsourcers, consultants, and other operational partners whose work affects your control environment ³.

High-impact environments where APO08 becomes a priority:

• Outsourced operations or heavy SaaS reliance.
• Regulated business processes where IT enables control execution (access, logging, change management).
• Distributed product/engineering organizations where “IT” is federated and relationship boundaries are blurry ².

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

Step 1: Set relationship ownership and governance boundaries

1. Define “relationship owner” roles for each major stakeholder group (business unit owners, security, audit, critical third parties).
2. Document accountability using a simple RACI for: service expectations, risk decisions, escalations, communications, and issue closure.
3. Tie ownership to services (applications, platforms, infrastructure services) so APO08 is anchored in operational reality ².

Practical tip: Avoid assigning relationship ownership to a shared inbox or a rotating duty manager. Auditors want a named role with continuity.

Step 2: Build a stakeholder register and relationship map

Create a stakeholder register with:

• Stakeholder name/group and executive sponsor.
• Services consumed or provided.
• Criticality (high/medium/low) based on business impact.
• Primary contacts, backups, and escalation contacts.
• Preferred communication channels and decision forums ³.

Then build a relationship map (one page is fine) that shows which governance forums cover which stakeholders (e.g., service review, security steering, third-party review).

Step 3: Standardize engagement cadences and meeting outputs

Define a minimum engagement model by stakeholder criticality:

• Operational touchpoints: service review agenda (incidents, changes, problems, capacity, vulnerabilities, third-party performance where relevant).
• Governance touchpoints: risk acceptance, exception approvals, audit findings, remediation status.
• Strategic touchpoints: roadmap alignment, investment needs, major architectural shifts ².

For each recurring forum, require consistent outputs:

• Agenda and pre-reads.
• Minutes with decisions and owners.
• Action log with due dates.
• Escalations and risk items routed to the right governance body ³.

Step 4: Implement an escalation path that works under pressure

Document and test:

• Trigger conditions: repeated SLA misses, control failures, high-severity incidents, third-party nonperformance, audit findings at risk.
• Escalation ladder: operational lead → service owner → executive sponsor → risk committee.
• Time expectations: define internal expectations, but focus your evidence on “was it escalated, who decided, what happened next” rather than arbitrary clocks ².

Step 5: Capture feedback and convert it into measurable improvement

APO08 is weak if relationship management is “meet and talk.” Add a feedback-to-action loop:

• Intake channels (service reviews, stakeholder feedback, audit issues, post-incident reviews).
• Triage and categorization (service quality, security gaps, communication failures, third-party concerns).
• Prioritization and assignment into your improvement backlog (problem management, control remediation, roadmap).
• Closure evidence: what changed, when, and who approved it ³.

Step 6: Map artifacts to APO08 for audit readiness

Create a lightweight APO08 evidence index that points to where artifacts live (GRC tool, ticketing system, shared drive) and who maintains them. Daydream can store control ownership, procedures, and evidence pointers mapped to APO08 so you can answer audits without rebuilding context each time ².

Required evidence and artifacts to retain

Keep artifacts that prove consistent operation, not just intent:

Evidence type	Minimum content	Where it usually lives
Stakeholder register	Stakeholders, services, owners, escalation contacts	GRC repository or service portfolio
Relationship RACI	Owners for expectations, escalations, decisions	Policy/control library
Communication plan	Forums, cadence, agendas, distribution	PMO/ITSM knowledge base
Meeting artifacts	Agenda, minutes, decisions, action log	Collaboration tool, ticketing, GRC
Escalation records	Trigger, escalation path used, decision, remediation	ITSM tickets, email archive, GRC issues
Feedback and improvement log	Feedback source, prioritization, actions, closure	Problem mgmt, risk register, backlog tool
Third-party touchpoints (where applicable)	QBR notes, SLA reports, issues, remediation	Vendor management files / ITSM

Tie each artifact to APO08 in a simple crosswalk so evidence is easy to assemble ².

Common exam/audit questions and hangups

Auditors and exam teams commonly probe these areas:

• “Who owns the relationship with X?” If you can’t name an owner, APO08 looks informal.
• “Show evidence of recurring communication.” One-off emails do not show a managed process.
• “How are stakeholder issues tracked to closure?” Teams often discuss issues but fail to show disposition.
• “How do you handle third-party-caused incidents?” If responsibilities between you and a third party are unclear, relationship management is not controlled ³.

Hangup to anticipate: relationship management is often spread across ITSM, procurement, security, and PMO. If evidence is fragmented, create an evidence index and ownership model so you can produce a coherent story ².

Frequent implementation mistakes (and how to avoid them)

1. Mistake: Treating APO08 as “customer satisfaction surveys.”
   Fix: Focus on ownership, engagement mechanics, escalations, and closed-loop improvements, with evidence.

2. Mistake: Documenting a communication plan that nobody follows.
   Fix: Standardize agendas and require action logs. Use existing forums and make outputs mandatory ³.

3. Mistake: Confusing third-party management with relationship management.
   Fix: APO08 covers relationships broadly. If you already have vendor management, connect it to stakeholder engagement and escalation paths rather than duplicating it ².

4. Mistake: No link from complaints to governance.
   Fix: Route recurring issues into problem management, risk acceptance, or remediation governance with clear decisions and owners.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for APO08. Treat APO08 as a governance expectation that reduces operational and compliance risk: unclear ownership and unmanaged stakeholder expectations commonly lead to unresolved findings, repeated incidents, and weak third-party accountability ².

Practical 30/60/90-day execution plan

First 30 days (stabilize and assign)

• Name relationship owners for top stakeholders and critical third parties.
• Build the first version of the stakeholder register and escalation ladder.
• Identify existing forums (service reviews, steering committees) you can standardize rather than creating new meetings.
• Create an APO08 evidence index with links to where artifacts will be stored ².

Days 31–60 (standardize and produce evidence)

• Publish standard agendas and templates for minutes and action logs.
• Start capturing consistent meeting outputs for priority stakeholder groups.
• Stand up a single issue-to-closure mechanism (ITSM problem record, GRC issue, or backlog ticket) for relationship-driven issues.
• Pilot the escalation path with one real issue and document the decision trail ³.

Days 61–90 (operate, measure, and tune)

• Expand the model to remaining stakeholder groups based on criticality.
• Review recurring issues and demonstrate at least one improvement action tied to stakeholder feedback.
• Run an internal “mock audit” using your APO08 evidence index: confirm you can answer who owns relationships, what forums exist, what decisions were made, and what changed.
• If you use Daydream, map each artifact to APO08 control ownership so evidence requests become pull-button rather than a scramble ².

Frequently Asked Questions

How do I scope APO08 without boiling the ocean?

Start with stakeholders tied to critical services and high-risk processes, plus your most important third parties. Expand coverage once you have repeatable meeting outputs and an issue-to-closure loop ².

Does APO08 require new committees?

No. Reuse existing operational and governance forums, then standardize agendas, minutes, and action logs so the relationship management is provable ³.

What’s the single most important artifact for audit readiness?

A stakeholder register with named relationship owners and escalation contacts, plus evidence of recurring touchpoints that generate decisions and tracked actions ².

How do we handle relationship ownership for shared platforms used by many business units?

Assign a service owner for the platform relationship and document stakeholder-specific points of contact for each business unit. Use a standard service review forum and route business-specific risks into the right governance channel ³.

Where does third-party management fit under APO08?

Treat key third parties as stakeholders in your relationship map, then connect performance reviews, escalations, and incident communications to the same evidence model you use for internal stakeholders ².

How do we prove “feedback loops” without a formal satisfaction survey program?

Use existing signals: recurring complaints in service reviews, post-incident review actions, audit issues, and backlog items. The key is traceability from feedback to decision to remediation evidence ³.

Footnotes

1. ISACA COBIT overview; OSA COBIT 2019 objective mapping

2. ISACA COBIT overview

3. OSA COBIT 2019 objective mapping