APO14: Managed Data

APO14 in COBIT 2019 is the governance objective that forces clarity on a question auditors and regulators ask repeatedly: “Who owns the data, what rules apply to it, and can you prove you follow those rules?” COBIT is a framework, not a statute, but many regulated enterprises adopt it or map to it to show disciplined control design and operation (ISACA COBIT overview).

For a CCO, compliance officer, or GRC lead, APO14 is often where data governance meets audit reality. Teams may have pockets of strong controls (privacy, security, records management), yet still fail APO14 because ownership is unclear, data is not consistently classified, quality controls are informal, and evidence is scattered across tools and teams. Examiners also expect coverage across the full data lifecycle, including data shared with third parties and data generated by SaaS platforms.

This page translates APO14 into requirement-level steps you can execute: scoping, roles, minimum control set, and an evidence plan that survives an audit. Where COBIT text is proprietary, this guidance relies on the public COBIT objective overview and mappings (ISACA COBIT overview; OSA COBIT 2019 objective mapping).

Regulatory text

Excerpt (provided): “COBIT 2019 objective APO14 implementation expectation.” (ISACA COBIT overview; OSA COBIT 2019 objective mapping)

Operator interpretation: APO14 expects you to implement managed data practices as a defined governance capability. In practical audit terms, you need (1) documented ownership and standards, (2) lifecycle controls that are consistent across systems, and (3) evidence that the controls run as designed (ISACA COBIT overview).

What an operator must do to satisfy the excerpt

• Assign accountable owners for data domains and critical datasets (business accountability, with IT support).
• Document enforceable rules for data classification, quality, access, retention, and acceptable use.
• Embed the rules into operations (access workflows, change management, SDLC, vendor management, data pipelines).
• Retain evidence that the rules are applied and reviewed, and that exceptions are tracked to closure.

Plain-English interpretation (what APO14 is really asking)

APO14 requires you to manage data like a controlled enterprise asset. That means:

• Someone can answer: “This dataset exists, it has an owner, it has a classification, and we know where it flows.”
• Your organization can show: “We control access, maintain quality, retain and dispose per rules, and we monitor compliance.”
• Auditors can verify: “Those controls operate in practice, not just on paper.”

If you already run privacy, security, and records programs, APO14 is the governance wrapper that ties them together into one provable control story (ISACA COBIT overview).

Who it applies to

Entity types

• Enterprise IT organizations adopting COBIT 2019 directly or mapping controls to COBIT objectives (ISACA COBIT overview).

Operational contexts where APO14 becomes “must-pass”

• Data warehouses/lakes, analytics and AI/ML pipelines, master data management, ETL/ELT processes.
• High-volume SaaS ecosystems where data is created and stored outside your core network.
• M&A integration where data domains and definitions collide.
• Third party relationships that host, process, enrich, or transmit your regulated or sensitive data.

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

Use this sequence to operationalize the apo14: managed data requirement without boiling the ocean.

Step 1: Define scope and the “data that matters”

1. Identify critical business services and the datasets that support them (customer, employee, financial, product, logs).
2. Decide which data domains you will govern first (example: Customer, Payments, HR).
3. Set materiality criteria for “in scope” datasets (example: regulated data, high-impact operational reporting, security telemetry).

Deliverable: a one-page scoping memo that your CIO/CISO and business owners can sign.

Step 2: Assign ownership and decision rights (RACI that works)

1. Name a Data Owner per domain (accountable for definitions, access approval standards, quality thresholds, retention intent).
2. Name a Data Steward (operational lead for metadata, issue triage, quality monitoring).
3. Define IT custodianship (platform teams that implement controls).
4. Define GRC oversight (policy maintenance, control testing, exception governance).

Artifact: APO14 RACI + role descriptions (kept current as org changes).

Step 3: Build a minimum viable data inventory with lineage

Start simple; auditors want completeness for what you claim is in scope.

1. Inventory in-scope datasets: system, owner, purpose, locations, consumers.
2. Capture data classification (confidentiality tier) and regulated attributes (if applicable).
3. Document data flows: sources, transformations, destinations, third parties.

Evidence: inventory export, lineage diagrams, system architecture docs, and change tickets showing updates.

Step 4: Establish enforceable standards (policy + procedures)

Write standards that can be tested. Avoid “should.” Minimum set:

• Data classification and handling standard (labels, required safeguards by class).
• Data quality standard (defined quality dimensions, monitoring, issue management).
• Retention and disposal standard (retention triggers, legal hold workflow, deletion verification).
• Access governance standard (least privilege, approvals, periodic review, break-glass).
• Metadata standard (required fields for critical datasets: owner, definition, lineage, sensitivity).

Map each standard to where it is implemented (IAM, DLP, SIEM, ticketing, MDM, pipeline controls).

Step 5: Embed controls into operational workflows

This is where most programs fail APO14: standards exist, but operations ignore them.

Implement these control hooks:

• Joiner/mover/leaver integration: access provisions based on role; removals verified.
• Access requests: require business owner approval for sensitive datasets; log decisions.
• Change management: schema changes require steward review; lineage updated as part of “done.”
• Data incident handling: data quality incidents and data leakage incidents have severity, owners, and post-incident actions.
• Third party management: contracts and security reviews reflect classification, retention, deletion rights, and breach notification.

Step 6: Make evidence collection automatic

Design your evidence plan before the audit request.

• System logs: access grants, permission changes, admin actions.
• Ticketing: approvals, quality issues, retention exceptions.
• Review records: access recertifications, data owner attestation, stewardship meeting minutes.
• Reports: DLP events, encryption posture, backup and restore tests (where relevant to data availability and integrity).

Daydream can help by mapping APO14 to your actual artifacts and creating an evidence “bill of materials” per dataset and system, so you are not assembling proof manually each audit cycle.

Step 7: Govern exceptions and measure control health

1. Create an exception register for data governance deviations (temporary access, retention overrides, unmanaged data stores).
2. Require time-bounded approvals and compensating controls.
3. Track remediation to closure and retain closure evidence.

Required evidence and artifacts to retain

Use this checklist to pass control design and operating effectiveness testing.

Evidence category	What to retain	What auditors look for
Governance	Data governance charter, RACI, committee cadence	Named accountable owners and decision process
Inventory	Dataset/system inventory, classification tags, lineage	Coverage of in-scope “crown jewels”
Standards	Data classification, access, quality, retention procedures	Testable language; aligns to operations
Access control	Access request tickets, approvals, recert results, IAM logs	Owner approvals for sensitive data; periodic review evidence
Quality	Quality dashboards, issue tickets, root-cause notes	Thresholds defined; issues resolved or risk-accepted
Retention	Retention schedule, deletion/archival tickets, legal hold logs	Retention triggers and execution proof
Third parties	DPIA/security reviews, contract clauses, deletion attestations	Data handling aligned to classification and retention

Common exam/audit questions and hangups

• “Show me your authoritative data inventory. Who updates it, and how do you know it’s current?”
• “Who is the data owner for this dataset, and what decisions do they actually make?”
• “How do you ensure classification labels are applied consistently across SaaS and cloud storage?”
• “Prove your access reviews cover analytics tools and service accounts, not only core apps.”
• “How do you enforce retention and deletion in systems where users can export data?”

Typical hangup: teams present policies, but cannot show operating evidence tied to specific datasets.

Frequent implementation mistakes (and how to avoid them)

1. Owning data governance in IT only. Fix: make business leaders accountable as Data Owners; IT stays custodian.
2. Inventory that lists systems, not datasets. Fix: for critical services, inventory datasets and key tables/objects, not just platforms.
3. Classification without handling rules. Fix: define required safeguards per class and link them to technical controls (IAM, encryption, DLP).
4. Retention schedules that don’t execute. Fix: add deletion/archival workflows with tickets and verification artifacts.
5. Ignoring third party data processing. Fix: include SaaS apps and processors in lineage and apply the same access/retention expectations.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement. Practically, APO14 gaps show up as findings under broader obligations: privacy violations, weak access controls, records failures, incident response breakdowns, and inability to support investigations. Your operational risk is compounded when you cannot prove where sensitive data lives or who accessed it.

Practical 30/60/90-day execution plan

You asked for speed. This plan assumes you already have baseline security and ITSM.

First 30 days (stabilize and define)

• Confirm in-scope domains and critical services.
• Assign Data Owners and Stewards; publish the RACI.
• Build the initial inventory for the most material datasets (include third party processors).
• Draft minimum standards: classification/handling, access approvals, retention intent, quality issue workflow.

Exit criteria: named owners, a defensible inventory slice, and standards ready to operationalize.

Day 31–60 (operationalize and collect evidence)

• Implement approval workflows for sensitive dataset access (tickets + IAM groups).
• Start access recertification for in-scope datasets and analytics platforms.
• Stand up a quality issue queue with triage rules and owner SLAs.
• Add retention execution mechanisms for at least one key system (archival/deletion tickets and verification).

Exit criteria: operating evidence exists for access, quality, and retention controls.

Day 61–90 (scale, test, and harden)

• Expand inventory coverage across remaining in-scope systems.
• Validate lineage for critical data flows, including exports and third party transfers.
• Run an internal control test: sample access requests, retention actions, quality incidents, and exception approvals.
• Establish a standing governance cadence with metrics and an exception register.

Exit criteria: you can pass a mock audit walkthrough for one domain end-to-end.

Frequently Asked Questions

What is the minimum dataset scope to claim APO14 is implemented?

Start with data supporting critical business services and any regulated or sensitive datasets. Document your scope rationale and expand iteratively, but do not claim enterprise-wide coverage without inventory evidence.

Do we need a dedicated data governance tool to meet APO14?

No. You can meet APO14 with documented ownership, standards, and evidence from existing systems (IAM, ticketing, logging). Tools help scale, but auditors will still ask who approves access and how exceptions are tracked.

How do we handle APO14 for SaaS platforms where we can’t enforce retention or deletion directly?

Treat it as a third party control problem: contract clauses, configuration controls, and deletion/return attestations. Keep evidence of periodic reviews and any exceptions where the SaaS platform cannot meet your retention standard.

Who should be the data owner: IT, Security, or the business?

The business should be accountable for data definitions and risk decisions because they bear the operational and compliance impact. IT and Security implement and monitor controls as custodians and control owners.

What evidence is most persuasive in an audit for “managed data”?

Operating evidence tied to specific datasets: access approvals and recertifications, quality issue tickets with resolution, and retention/deletion records. Policies without operational artifacts rarely clear testing.

How can Daydream help with APO14 execution?

Daydream can map APO14 expectations to your existing controls and artifacts, then produce an evidence map that shows exactly what to collect per system and dataset. That reduces scramble during audits and makes gaps visible early.