MEA02: Managed System of Internal Control

MEA02 in COBIT 2019 focuses on managing a system of internal control that leadership can trust and auditors can verify. For a Compliance Officer, CCO, or GRC lead, the practical objective is simple: you need a structured way to confirm that your controls over technology and IT-enabled business processes are designed appropriately, operate consistently, and produce evidence that stands up in audits and regulator exams.

Teams often “have controls” but fail MEA02 in practice because controls are informal, ownership is unclear, testing is ad hoc, or evidence is missing. MEA02 pushes you toward an operating model: documented control objectives, accountable owners, defined procedures, monitoring and testing, and tracked corrective actions. It also forces decisions about scope (which systems and processes matter most), and how to connect control performance to enterprise risk.

This page gives requirement-level implementation guidance you can execute quickly: who should be involved, what to build, how to run testing, what artifacts to retain, where audits get stuck, and a practical execution plan you can run with your current tooling (or accelerate with a platform like Daydream once your baseline is clear).

Regulatory text

Framework excerpt (provided): “COBIT 2019 objective MEA02 implementation expectation.” ^{1 2}

Operator interpretation: MEA02 expects you to implement and manage an internal control system for IT governance and management. In operational terms, you must:

• Define the internal control approach (scope, control objectives, roles, and responsibilities).
• Implement controls in processes and systems, not only in documentation.
• Monitor and evaluate whether controls operate effectively.
• Maintain evidence and remediation tracking so you can prove control performance over time. ¹

Plain-English interpretation (what MEA02 requires)

MEA02 requires a managed internal control system that is intentional and testable. “Managed” means:

1. someone owns each control,
2. the control has a defined purpose and procedure,
3. you can show it ran (or is continuously operating),
4. you can detect failures, fix them, and prevent repeats.

If your internal control environment depends on tribal knowledge (“Alex always reviews access”) or scattered evidence (“screenshots in Slack”), you will struggle to demonstrate MEA02 conformity, even if the underlying security work is strong.

Who it applies to (entity and operational context)

Applies to: Enterprise IT organizations and any organization adopting COBIT 2019 practices for governance and management of information and technology. ¹

Operationally relevant for:

• Regulated organizations mapping COBIT to other obligations (SOX, SOC 2, ISO 27001) and needing a single control system.
• IT, security, and GRC functions that must show consistent execution across multiple teams (Infrastructure, IAM, Engineering, Service Management).
• Outsourced or hybrid environments where third parties operate key controls (managed services, cloud providers, SaaS platforms). MEA02 still expects you to manage the control system end-to-end, including oversight evidence.

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

Step 1: Set scope and control objectives

Build a written scope statement that answers:

• Which processes are in-scope (e.g., access management, change management, incident response, backups)?
• Which systems are in-scope (production identity provider, core applications, logging platforms)?
• What “internal control” means in your environment (preventive/detective, manual/automated, continuous vs periodic).

Output: “MEA02 Control System Scope & Objectives” document approved by IT risk leadership.

Step 2: Create a control register with ownership

Create a control register that is more than a list. Minimum columns that auditors expect to see:

• Control ID / name
• Control objective (what risk it addresses)
• Process area (IAM, Change, SDLC, Ops)
• Control owner (individual role, not a team name)
• Operator (who performs it day-to-day)
• Frequency / trigger (event-based vs periodic)
• Evidence produced (what artifact proves execution)
• Systems/tools in use (where evidence lives)
• Dependencies (including third parties)
• Control type (manual, automated, hybrid)
• Link to policy/procedure

Practical rule: If a control has no named owner and no defined evidence, treat it as “not implemented” for MEA02 purposes.

Step 3: Document control procedures at the “performer” level

For each key control, write procedures that a new hire can follow. Avoid policy-only language. Include:

• Preconditions (access required, tools)
• Steps to perform
• Decision points (what constitutes an exception)
• How to record completion
• Escalation path

Tip: If you rely on a third party (e.g., managed SOC), document your oversight steps and what you receive (reports, tickets, attestations). MEA02 is satisfied by managed oversight when the evidence is consistent and review is accountable.

Step 4: Map controls to risks and requirements

Build a mapping that lets you answer: “Why do we have this control?”

• Risk statements (e.g., unauthorized access, unapproved production changes)
• COBIT objective mapping (MEA02 to your internal control framework)
• Crosswalk to other frameworks if relevant (SOC 2, ISO 27001) for reuse

This is where many teams lose time during audits. A clean mapping reduces debates and rework. OSA’s COBIT objective mappings can support your crosswalk work. ²

Step 5: Define a control monitoring and testing approach

You need two motions:

1. Operational monitoring (control owners confirm performance; exceptions get logged).
2. Independent testing/assurance (GRC, Internal Audit, or second-line tests design and operating effectiveness).

Build a simple test plan:

• Which controls are “key controls” (high-risk, high-impact)
• Test method (inquiry, observation, re-performance, inspection)
• Evidence period (what time window you sample)
• Pass/fail criteria
• Issue severity and due dates for remediation (your internal taxonomy)

Daydream fit: Once your control register exists, Daydream can act as the system of record for control ownership, evidence requests, and mappings, so you stop chasing artifacts across tools.

Step 6: Run issues management with root cause and closure evidence

MEA02 expects control failures to lead to corrective actions that actually close. Minimum issue workflow:

• Issue statement tied to a specific control
• Impacted systems/processes
• Root cause
• Corrective action plan
• Owner and target completion date (internal target)
• Validation step (how you prove it’s fixed)
• Closure approval

Operator habit that matters: keep “closure evidence” (screenshots, tickets, config diffs, approval records) linked to the issue. Auditors will ask for it.

Step 7: Establish governance and reporting

Stand up a recurring internal control review forum (could be a risk committee agenda item) that reviews:

• Control health (open exceptions, overdue tests)
• Top issues and themes (recurring failures)
• Changes in scope (new systems, decommissions)
• Third party control dependencies and oversight status

Keep minutes and action items. Governance evidence often becomes the difference between “controls exist” and “controls are managed.”

Required evidence and artifacts to retain

Use this as your MEA02 evidence checklist:

Artifact	What it proves	Owner
MEA02 scope & control objectives	Defined control system boundaries and intent	GRC lead / IT risk
Control register with owners	Controls exist, are accountable, and are traceable	GRC + control owners
Control procedures / runbooks	Controls are executable and standardized	Control owners
Evidence samples per control	Control operation (approvals, logs, tickets, reports)	Control operators
Test plan + test results	Independent evaluation of design/operation	GRC / Internal Audit
Exceptions register	Control failures are logged and tracked	GRC
Issues and remediation tickets	Corrective action lifecycle and closure	Control owners
Governance minutes/reporting	Management oversight of the control system	Risk committee secretary

Common exam/audit questions and hangups

Expect these questions and prep answers with artifacts:

• “Show me your control inventory and how you decide what is key.”
• “Who owns this control, and what happens if they’re out?”
• “Where is the evidence stored, and how do you know it’s complete?”
• “How do you test operating effectiveness, and who is independent of operations?”
• “Show me a control failure and the remediation trail to closure.”
• “Which controls depend on third parties, and how do you oversee them?”

Hangups auditors flag quickly:

• Evidence that is not reproducible (one-off screenshots with no context).
• Controls defined at a high level with no performer steps.
• Testing that only confirms documents exist, not that controls ran.

Frequent implementation mistakes (and how to avoid them)

1. Mistake: Policy-only compliance.
   Fix: require each key control to have a procedure and evidence type in the register.

2. Mistake: Shared mailbox ownership.
   Fix: name a role accountable for outcomes; name a backup; document delegation.

3. Mistake: No pass/fail criteria.
   Fix: define what “good” looks like (approval present, timestamps, reviewer independence).

4. Mistake: Tool sprawl for evidence.
   Fix: designate a system of record for evidence links and use consistent naming conventions. Daydream can centralize this without forcing you to replace operational tools.

5. Mistake: No third-party oversight artifacts.
   Fix: retain vendor reports, tickets, meeting notes, and your review sign-offs. Treat oversight as a control with its own owner and evidence.

Enforcement context and risk implications

COBIT is a framework, not a regulator. Enforcement usually shows up indirectly: audits, customer due diligence, SOC reports, and regulator exams that expect strong internal controls over IT. The practical risk is operational and contractual: if you cannot evidence a managed internal control system, you invite audit findings, delayed sales cycles, and increased residual risk because failures are discovered late. ¹

Practical 30/60/90-day execution plan

First 30 days (baseline and scope)

• Confirm in-scope processes and systems for the internal control system.
• Build the first version of the control register with owners, procedures, and evidence types.
• Identify “key controls” based on risk and materiality.
• Stand up a single exception log and issue workflow.

Days 31–60 (evidence and testing)

• Collect evidence samples for key controls and store links centrally.
• Write a test plan and run initial design effectiveness checks.
• Run a first operating effectiveness test cycle for a subset of controls.
• Fix obvious evidence gaps and ownership gaps immediately.

Days 61–90 (governance and repeatability)

• Operationalize recurring reporting to leadership (control health, exceptions, remediation).
• Expand testing coverage to remaining key controls.
• Formalize third-party control dependencies and oversight controls in the register.
• Prepare an “audit-ready” MEA02 package: scope, register, tests, issues, governance minutes.

Frequently Asked Questions

What’s the minimum I need to show to satisfy MEA02 in an audit?

A scoped control register with named owners, documented procedures, and repeatable evidence, plus a test plan with recorded results and tracked remediation. Auditors want proof the system runs, not just that it exists on paper.

Do automated controls count more than manual controls for MEA02?

MEA02 does not require automation, but automated controls often produce stronger evidence and reduce inconsistency. If you keep manual controls, make the procedure specific and standardize the evidence.

How do I handle controls performed by a third party?

Treat oversight as your control: define what you receive (reports/tickets), how often you review it, and who signs off. Keep the third party artifacts plus your review evidence in the same control record.

Who should own MEA02: compliance, security, or IT?

GRC typically owns the control system and testing approach, while IT and security own control execution. Assign control ownership to the operational leader closest to the process, and keep accountability explicit in the register.

We already have SOC 2 / ISO controls. Do we need to rebuild everything for MEA02?

Usually no. Reuse the control statements and evidence approach, then map them to MEA02 and fill gaps in ownership, monitoring, and issue closure documentation.

What does “missing implementation evidence” look like in practice?

Controls with no consistent artifacts (no tickets, approvals, logs, reports) or evidence that can’t be tied to a time period and control performer. Fix this by defining an evidence standard per control and storing links in a system of record.

Footnotes

1. ISACA COBIT overview

2. OSA COBIT 2019 objective mapping