EDM05: Ensured Stakeholder Engagement

To meet the edm05: ensured stakeholder engagement requirement, you must run a repeatable governance process that identifies stakeholder needs, translates them into decision criteria and priorities for I&T, and proves ongoing engagement through documented communications, approvals, and feedback loops. Operationalize EDM05 by assigning ownership, defining cadence and triggers, and retaining a consistent evidence bundle each cycle. ¹

Key takeaways:

• Define who your stakeholders are, what they need, and how their needs drive I&T priorities and decisions under board-level oversight. ¹
• Turn engagement into an operating cadence: defined forums, agendas, decisions, escalation paths, and measurable follow-through. ²
• Evidence matters: keep inputs, approvals, outputs, and remediation tracking to show engagement is real and continuous. ²

EDM05 (“Ensured Stakeholder Engagement”) is the COBIT governance expectation that stakeholder needs do not stay as informal opinions or one-time survey results. You need a governed mechanism to capture stakeholder drivers (regulatory, customer, business, operational resilience, security, financial), convert them into enterprise-aligned objectives for information and technology (I&T), and keep stakeholders engaged through decisions and outcomes. ¹

For a CCO, GRC lead, or CIO-aligned risk owner, EDM05 shows up in audits and customer diligence as deceptively simple questions: “Who signs off I&T priorities?”, “How do you reconcile security risk with product timelines?”, “How does the board know technology is delivering value and managing risk?”, and “Prove you listened to stakeholders and acted.” If you cannot show ownership, cadence, and traceable evidence, EDM05 will fail in practice even if your policies sound strong. ²

This page gives requirement-level implementation guidance you can execute quickly: a practical stakeholder map, a governance runbook (forums, triggers, decision rights), a minimum evidence bundle, exam-ready Q&A, and a phased execution plan.

Regulatory text

Provided excerpt: “COBIT 2019 objective EDM05 implementation expectation.” ¹

Operator interpretation (what you must do):

• Identify and maintain stakeholder groups and their needs relevant to I&T outcomes (value delivery, risk management, resource optimization, transparency). ¹
• Set up governance touchpoints where stakeholder input is received, decisions are made, and outcomes are reported back to stakeholders. Treat this as a control that operates on a defined cadence with defined triggers. ²
• Demonstrate traceability from stakeholder needs → enterprise objectives → I&T priorities/decisions → outcomes and follow-up actions, with evidence retained. ²

COBIT is a framework, not a statute. Examiners and customers still expect you to implement it as an auditable management system: clear ownership, repeatable operation, and consistent records. ²

Plain-English interpretation of the requirement

EDM05 means you can answer, with evidence:

1. Who your stakeholders are for I&T governance (internal and external).
2. What they need from I&T (and what they care about most).
3. How you decide when needs conflict (for example, speed vs. control; cost vs. resilience).
4. How you communicate decisions and performance back to stakeholders.
5. How you prove it happens continuously, not only during an annual planning cycle. ²

A strong EDM05 implementation looks like disciplined “technology governance communications,” not ad hoc meetings.

Who it applies to (entity and operational context)

Entity types: Enterprises using COBIT for governance, including regulated and non-regulated organizations with formal I&T risk and performance oversight. ¹

Operational contexts where EDM05 is highest impact:

• Board and executive oversight of technology strategy, cyber risk, resilience, and major spend.
• Product and engineering organizations where delivery pressure can override stakeholder risk needs.
• Outsourced/third-party heavy environments where stakeholders care about service quality, data protection, and concentration risk.
• Post-incident periods where stakeholders demand corrective actions and proof of follow-through. ²

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

Step 1: Create the EDM05 “control card” (owner, scope, triggers, cadence)

Write a one-page runbook that a new control owner can execute without tribal knowledge:

• Control name: EDM05 Ensured Stakeholder Engagement
• Owner: Named role (not a team). Common owners: Head of IT Governance, CIO Chief of Staff, GRC Director, or Enterprise Risk lead for technology governance.
• In-scope decisions: I&T strategy, major initiatives, security risk acceptance, resilience priorities, architectural exceptions, material third-party selections, and incident postmortem reporting.
• Triggers (examples): annual planning, major program approval, material risk acceptance, audit findings, major incidents, material third-party onboarding/renewal.
• Operating cadence: define your forums (see Step 3) and required reporting cycle. ²

This is the difference between “we engage stakeholders” and “we operate a control.”

Step 2: Build and maintain a stakeholder register

Create a stakeholder register with enough structure to support decisions:

• Stakeholder group (Board/Audit Committee, CEO/COO/CFO, CISO, Product, Engineering, Legal/Privacy, Compliance, Internal Audit, Customer Success, key customers, key third parties where relevant)
• Primary needs/expectations (risk appetite, availability targets, regulatory commitments, delivery timelines, cost constraints, data residency, auditability)
• Engagement channel (forum, QBR, steering committee, incident review)
• Decision rights / consultation (RACI-style)
• Required artifacts they expect (dashboards, risk memos, OKR progress, audit reports) ¹

Keep it updated as org structure changes. Auditors often test freshness by sampling whether current leaders appear.

Step 3: Stand up governance forums with decision records

Define a small number of forums. Fewer, better-run meetings beat many informal ones.

Minimum set most teams need:

• I&T Steering Committee: prioritization, funding alignment, delivery risk, cross-functional tradeoffs.
• Technology Risk & Acceptance Forum: risk acceptance decisions, exception approvals, security debt prioritization.
• Board/Audit Committee reporting: concise reporting on risk posture, significant changes, and decision escalations. ²

For each forum, document:

• Charter: purpose, scope, attendees, quorum, escalation path.
• Agenda template: decisions required, metrics reviewed, risks discussed.
• Decision log: date, decision, options considered, approver(s), conditions, follow-ups.
• Action tracking: owner, due date, evidence of closure. ²

Step 4: Translate stakeholder needs into decision criteria

This is where EDM05 either works or becomes a box-check.

• Create decision criteria for prioritization (examples: regulatory commitments, customer contractual obligations, risk reduction, reliability impact, strategic value, cost).
• Create risk acceptance criteria tied to your enterprise risk appetite (even if qualitative).
• Require that major decisions include a stakeholder impact summary: who benefits, who carries residual risk, and who must be informed or approve. ²

Step 5: Define the minimum evidence bundle (by cycle)

For each operating cycle (monthly/quarterly/trigger-based), retain the same categories of proof so you can respond fast to audits and diligence. ²

A workable minimum bundle:

• Inputs: stakeholder register snapshot, submitted agenda items, risk memos, initiative proposals
• Approvals: meeting minutes, decision log entries, approvals in ticketing/workflow tools
• Outputs: updated priorities/roadmap notes, risk acceptance letters/memos, escalations sent
• Follow-through: action tracker with validated closure evidence

Step 6: Run control health checks and remediate gaps

Treat EDM05 as a living control:

• Periodically test whether forums occurred, quorum was met, decisions were recorded, and actions were closed.
• Track remediation items to closure with a clear owner and proof. ²

If you use Daydream or a similar GRC workflow, map EDM05 to a control record with tasks, recurring attestations, and an evidence checklist so the control does not depend on one person’s memory. ²

Required evidence and artifacts to retain

Use this list as your audit-ready checklist:

Artifact	What it proves	Retention tips
EDM05 control card (runbook)	Ownership, triggers, and operating method	Store in GRC repository; version control
Stakeholder register	You know who stakeholders are and how to engage them	Date-stamp exports or quarterly snapshots
Forum charters + attendee lists	Engagement mechanism exists and is intentional	Keep current and prior versions
Agendas and minutes	Meetings occurred and topics matched scope	Minutes should capture decisions, not transcripts
Decision log (with approvers)	Stakeholder input translated into governance decisions	Tie to epics/projects/risk tickets
Action tracker + closure evidence	Follow-through and accountability	Require evidence links for “closed” status
Board/Audit reporting pack	Transparency and upward reporting	Keep final pack and distribution record

Common exam/audit questions and hangups

Expect these lines of questioning:

• “Show me who owns EDM05 and how it’s executed.” If you cannot produce a runbook and calendarized cadence, you will struggle. ²
• “How do you know you captured stakeholder needs?” Auditors look for a maintained register or equivalent structured intake. ¹
• “Prove decisions were made and acted on.” Minutes without decision logs and action closure evidence often fail. ²
• “How do you handle conflicting stakeholder priorities?” You need decision criteria and escalation paths, not informal negotiation.

Frequent implementation mistakes and how to avoid them

1. Mistake: Treating engagement as comms only. Newsletters and dashboards help, but EDM05 is about decisions and accountability.
   Avoidance: Require a decision log and action tracking for defined governance topics. ²

2. Mistake: No clear stakeholder definition. Teams forget Legal/Privacy, Customer Success, Internal Audit, or key customer voices until late.
   Avoidance: Maintain a stakeholder register and review it when org changes occur. ¹

3. Mistake: Evidence scattered across email and chat. You will not reconstruct it under audit pressure.
   Avoidance: Define a minimum evidence bundle and a single retention location per artifact type. ²

4. Mistake: Forums exist but have no decision rights. Meetings become status updates, not governance.
   Avoidance: Add charters, quorums, escalation paths, and explicit “decisions required” agenda sections. ²

Enforcement context and risk implications

No public enforcement cases were provided for this specific COBIT objective in the supplied sources. In practice, EDM05 gaps raise operational and assurance risk: stakeholders claim they were not informed, risk decisions are undocumented, and post-incident accountability is unclear. Those failure modes commonly become audit findings, customer trust issues, and board-level escalations. ²

Practical 30/60/90-day execution plan

First 30 days: Establish ownership and minimum operating model

• Assign the EDM05 owner and publish the control card (scope, triggers, cadence, evidence). ²
• Build the first stakeholder register version; validate it with the CIO/CCO/CISO.
• Pick governance forums you will run; draft charters and decision log template.
• Define the minimum evidence bundle and where each artifact is stored.

Days 31–60: Run the first cycles and prove traceability

• Hold initial steering/risk forums with agenda discipline.
• Populate the decision log with real decisions (priorities, risk acceptances, escalations).
• Start action tracking with owners and closure evidence.
• Produce a stakeholder-facing reporting pack draft (exec or board-appropriate) aligned to the needs you captured. ²

Days 61–90: Harden the control and make it durable

• Perform a control health check: sample decisions and verify evidence completeness end-to-end. ²
• Fix gaps (missing minutes, unclear approvals, inconsistent action closure).
• Automate reminders and evidence collection through your GRC workflow (Daydream can hold the control card, recurring tasks, and evidence bundles in one place). ²
• Formalize escalation paths for disputes and document how exceptions are approved.

Frequently Asked Questions

Do we need board involvement to satisfy EDM05?

You need governance at the right level for material I&T decisions, plus a way to report and escalate. Many organizations include board or audit committee reporting for major risks and investments. ¹

What counts as a “stakeholder” for EDM05?

Include anyone who sets expectations for I&T value, risk, or performance, such as executives, risk and compliance functions, and key business owners. Add external stakeholders where contractual or regulatory commitments drive technology outcomes. ¹

Can we meet EDM05 with existing meetings?

Yes, if those meetings have documented charters, decision rights, minutes, and a decision log with follow-through. If they are status meetings without recorded decisions, they usually do not produce audit-grade evidence. ²

What is the minimum evidence auditors usually want first?

A named owner, a stakeholder list, a repeatable forum cadence, and a decision/action trail that shows engagement led to outcomes. Start with a simple evidence bundle you can reproduce every cycle. ²

How do we handle stakeholder conflicts (for example, Product vs. Security)?

Define decision criteria and escalation paths in the forum charters, then document the decision and residual risk acceptance with the right approvers. The goal is a traceable decision, not unanimous agreement. ²

How should EDM05 map to third-party risk work?

Stakeholder needs often include customer requirements, regulatory expectations, and operational resilience that depend on third parties. Bring material third-party decisions and concentration risks into the same decision log and escalation path used for internal initiatives. ²

Footnotes

1. ISACA COBIT overview

2. ISACA COBIT usage guidance