EDM01: Ensured Governance Framework Setting and Maintenance

EDM01 requires you to formally set, approve, and maintain an enterprise IT governance framework that assigns decision rights, defines oversight routines, and stays current as strategy, risk, and operating conditions change. To operationalize it quickly, publish a governance charter, map governance bodies and accountabilities, define a governance calendar, and retain repeatable evidence of decisions and reviews. ¹

Key takeaways:

• Document governance decision rights, forums, and accountabilities in a board- or executive-approved governance charter.
• Turn “framework maintenance” into a scheduled cadence with triggers (strategy changes, incidents, M&A) and defined evidence bundles.
• Prove operation with artifacts: agendas, minutes, approvals, exception logs, and remediation tracking tied to governance decisions. ²

EDM01: ensured governance framework setting and maintenance requirement is where COBIT stops being a reference book and becomes an operating system for how IT-related decisions get made, escalated, approved, and revisited. You are not being asked to adopt a specific diagram or template. You are being asked to make governance explicit, assign ownership, and show that governance is maintained over time, not “set once” and forgotten. ¹

For a Compliance Officer, CCO, or GRC lead, the fastest path is to treat EDM01 as a small set of auditable governance mechanics: (1) a defined governance framework with scope and principles, (2) named governance bodies with decision rights, (3) a predictable governance calendar and review triggers, and (4) evidence that decisions and oversight activities occurred and led to action. ²

This page gives requirement-level implementation guidance you can put into a runbook, then defend during internal audit, external audit, customer diligence, or regulator conversations where COBIT is used as a reference framework. It prioritizes operational proof over theory, with concrete artifacts and common failure points.

Regulatory text

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

Operator interpretation: You must define an IT governance framework, get it approved at the right level (board, executive committee, or equivalent governance authority), and keep it current through a managed lifecycle. “Ensured” means you can demonstrate it is in place and functioning, using evidence of governance forums, decisions, and follow-through. ²

What an auditor will look for: a coherent governance framework statement, clear decision rights, oversight cadence, and records showing the framework is reviewed and updated when conditions change. ²

Plain-English interpretation (what EDM01 means in practice)

EDM01 requires you to answer five questions with documents and repeatable routines:

1. What governance framework are we using for IT, and what does it cover? (scope, principles, alignment to enterprise governance). ¹
2. Who decides what? (decision rights for strategy, risk, architecture, investment, sourcing, security, and exceptions).
3. Where do those decisions happen? (committees/forums, escalation paths, quorum/approvals).
4. How do we keep governance current? (review cadence and change triggers).
5. How do we prove governance happened and resulted in action? (minutes, approvals, action logs, remediation closure). ²

A common failure pattern is “policy without plumbing”: you have governance statements, but no calendar, no named accountable owners, and no evidence bundle that ties decisions to outcomes. That is the core risk factor called out in the provided guidance. ²

Who it applies to (entity and operational context)

Applies to: enterprises and enterprise IT organizations using COBIT 2019 as a governance and management framework for information and technology. ³

Where it shows up operationally:

• Board and executive oversight of IT strategy, portfolio, and risk.
• CISO/CTO/CIO governance forums (security steering, architecture review board, change advisory board).
• GRC operating model (policies, risk acceptance, control exceptions, audit remediation).
• Third-party risk and sourcing governance where IT services are outsourced or cloud-based.

Practical scoping tip: EDM01 is enterprise-level. You can delegate execution, but you cannot delegate accountability. Your governance framework must connect enterprise governance to IT governance with a defined escalation path.

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

Use this sequence to get to “operational” fast and defensible.

1) Publish a governance framework charter (the one-page anchor)

Create a charter that states:

• Governance objective and scope (what parts of IT it governs).
• Governance principles (alignment to enterprise objectives; risk-informed decision-making).
• Relationship to other frameworks you use (security program framework, enterprise risk management, internal audit approach). ¹

Output artifact: IT Governance Framework Charter (versioned).

2) Define governance bodies and decision rights (RACI is not enough by itself)

Create a decision-rights matrix that lists, at minimum:

• IT strategy approval
• Technology standards/architecture exceptions
• Security risk acceptance
• Major incident governance and post-incident accountability
• Material third-party engagements and renewals (where applicable)
• IT investment/portfolio prioritization

For each decision, document:

• Decision owner (who is accountable)
• Approver (who signs off; include delegated authority thresholds if your organization uses them)
• Forum (where it’s reviewed)
• Inputs required (risk assessment, architecture review, security review, financial analysis)
• Evidence produced (minutes, approvals, risk acceptance memo)

Output artifacts: Governance body map (org chart view) + decision rights matrix.

3) Establish a governance calendar and triggers (maintenance is the requirement)

Create a governance calendar that includes:

• Standing meeting cadence for each forum (security steering, architecture, risk committee, portfolio governance).
• Scheduled reviews: governance charter review, KPI/KRI review, audit issue review, exception review. ²

Define trigger events that force an out-of-cycle governance review, such as:

• Material changes in business strategy or operating model
• Significant incidents or control failures
• Major technology migrations or platform changes
• Mergers, acquisitions, or divestitures
• Material third-party changes (critical provider outage, subprocessor change, contract renewal)

Output artifact: Governance calendar + trigger register embedded in your governance charter or operating procedures.

4) Build “control cards” for governance routines (make execution repeatable)

For each governance routine, create a control card (a short runbook) with: objective, owner, frequency/trigger, steps, required attendees/quorum, approvals, exception rules, and where evidence is stored. This is a recommended control approach in the provided best practices. ²

Examples of governance routines to cardify:

• Quarterly governance framework review
• Risk acceptance workflow and approvals
• Architecture exception process
• Audit issue remediation governance
• Control health checks and reporting

5) Define your minimum evidence bundle (design it before the exam)

For each routine, define a minimum evidence bundle containing:

• Inputs (slides, dashboards, risk memos, proposals)
• Approvals (signatures, tickets, workflow approvals)
• Outputs (decisions, action items, exception decisions)
• Retention location (GRC system, document repository, ticketing system) This is explicitly recommended as a best practice to prevent evidence gaps. ²

Evidence rule that works in practice: if it wasn’t retained where your process says it lives, it didn’t happen.

6) Prove maintenance through health checks and remediation closure

Run recurring governance/control health checks. Track findings to validated closure with due dates, and keep the validation evidence. This is a recommended control and is one of the cleanest ways to show “maintenance,” not just “framework exists.” ²

Output artifacts: control health check reports, issue log, remediation plans, closure validation.

Required evidence and artifacts to retain

Keep these artifacts in a controlled repository with version history:

Evidence	What it proves	Owner
IT Governance Framework Charter (versioned)	Framework is defined, scoped, and approved	CIO/CTO + GRC
Governance body map + decision rights matrix	Clear decision rights and escalation	GRC / Enterprise governance
Governance calendar + trigger register	Maintenance is planned and event-driven	GRC
Agendas, minutes, attendance, quorum notes	Governance forums operated	Chair / PMO
Decision log (including exceptions)	Decisions were made and recorded	Forum secretary / GRC
Risk acceptance memos / approvals	Risk decisions follow process	CISO / Risk owner
Action item tracker + closure evidence	Follow-through and accountability	PMO / Control owners
Control health check results + remediation tickets	Ongoing monitoring and improvement	GRC / Internal audit liaison

Common exam/audit questions and hangups

Expect these lines of questioning:

1. “Show me the governance framework.” They want a single artifact with scope, ownership, and approval, not a pile of policies. ²
2. “Who has authority to accept risk and grant exceptions?” If you cannot show decision rights and delegated authority, the process looks informal.
3. “How do you keep it current?” They will test whether reviews are scheduled and whether trigger events caused updates.
4. “Prove operation.” Minutes, decision logs, and action tracking matter more than well-written policy.
5. “What happens when governance fails?” They will look for health checks, issue escalation, and remediation governance. ²

Frequent implementation mistakes and how to avoid them

• Mistake: Governance exists only as a policy statement.
  Avoid: Build control cards and an evidence bundle per routine. ²

• Mistake: Unclear ownership (“IT owns it”).
  Avoid: Name accountable individuals for each forum and each decision type; document alternates.

• Mistake: No exception governance.
  Avoid: Maintain an exception register (architecture exceptions, security exceptions, control exceptions) with expiry dates and renewal approvals.

• Mistake: Meetings occur, but nothing is retained.
  Avoid: Standardize minutes templates, decision logs, and storage locations; train forum secretaries.

• Mistake: “Maintenance” is treated as annual document review only.
  Avoid: Add triggers tied to real operational events and prove they work with at least one exercised example when available.

Enforcement context and risk implications

No public enforcement cases were provided for this requirement in the supplied source catalog. For regulated environments, the practical risk is indirect: weak IT governance increases the likelihood of control failures, unmanaged third-party exposure, and inconsistent risk acceptance. The common diligence failure is the inability to show ownership, cadence, and evidence of operation. ²

Practical 30/60/90-day execution plan

Use this as an execution path; adjust sequencing to your enterprise governance rhythms.

First 30 days (stabilize and document)

• Draft the IT Governance Framework Charter and route it for executive approval. ¹
• Inventory existing governance forums and map them to required decision types.
• Create the decision rights matrix and validate it with CIO/CTO, CISO, Risk, and Internal Audit.
• Stand up a central evidence repository and standard minutes/decision log templates.

Days 31–60 (operationalize and produce evidence)

• Create control cards for priority governance routines (risk acceptance, exceptions, portfolio approvals, audit remediation). ²
• Define the minimum evidence bundle for each routine and train meeting owners on retention expectations. ²
• Publish a governance calendar and embed trigger events into the charter or procedures.
• Run at least one governance cycle end-to-end (meeting, decision, action tracking, retention).

Days 61–90 (prove maintenance and close gaps)

• Run a control health check across governance routines; log gaps and assign remediation owners. ²
• Test trigger-based updates (for example, after a material incident review) and record the resulting governance changes.
• Review and refine the decision rights matrix based on friction points and escalations observed.
• If you use a GRC platform, configure workflows for approvals, exception expirations, and evidence attachments; Daydream can streamline control cards, evidence bundles, and recurring health checks so governance stays auditable without manual chasing. ²

Frequently Asked Questions

Do we have to “adopt COBIT” formally to meet EDM01?

EDM01 focuses on having an explicit governance framework and maintaining it. If you reference COBIT, keep a clear mapping between your governance artifacts and the EDM01 expectation. ¹

Who should approve the governance framework charter?

Approval should sit with the enterprise governance authority that owns IT oversight in your organization (often a board committee or executive committee). Document delegated authority clearly in the charter and decision rights matrix.

What is the minimum evidence to prove EDM01 is operating?

Keep the charter, decision rights, governance calendar, and recurring proof of operation (agendas, minutes, decision logs, and action tracking). Add health checks and remediation closure evidence to prove maintenance. ²

How do we handle governance for third parties and outsourced IT?

Treat third-party decisions as governed decisions: define who approves critical third-party selection, renewals, and risk acceptances; retain contract/risk inputs and approval records in the evidence bundle.

Our committees meet, but minutes are inconsistent. What’s the quickest fix?

Standardize a single minutes template with required fields (attendance, quorum, decisions, actions, approvals). Make the repository location part of the meeting agenda and assign a named owner for retention.

Can a GRC tool replace governance meetings?

No. Tools record and route decisions, but EDM01 expects governance decision-making and oversight to occur. Use a tool to enforce workflows, evidence capture, exception expirations, and health checks so you can prove consistent operation. ²

Footnotes

1. ISACA COBIT overview

2. ISACA COBIT usage guidance

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