Data Quality and Integrity

Data quality and integrity failures rarely show up as a single broken control. They show up as downstream symptoms: unexplained metric swings, reporting restatements, weak model outputs, incomplete customer records, or reconciliations that “always break” at month-end. COSO frames this as an information systems obligation: the system must produce information that meets defined quality attributes (timely, current, accurate, complete, accessible, protected, verifiable, and retained) so management can operate and evidence internal control (COSO IC-IF (2013)).

For a Compliance Officer, CCO, or GRC lead, the fastest path to execution is to treat “data quality and integrity” as an internal control requirement with testable assertions. That means (1) deciding which reports, metrics, data feeds, and extracts are “in scope for internal control,” (2) defining quality criteria that match COSO’s attributes, (3) implementing preventive and detective controls at the points where data is created or changed, and (4) retaining evidence that proves those controls ran and exceptions were handled.

This page gives requirement-level guidance you can hand to data owners, IT, Security, Internal Audit, and process owners, with a practical plan you can start immediately.

Regulatory text

COSO requirement (Principle 13 – Point of Focus): “Information systems produce information that is timely, current, accurate, complete, accessible, protected, verifiable, and retained.” (COSO IC-IF (2013))

Operator interpretation (what you must be able to prove)

You must be able to demonstrate, with evidence, that the information used to operate, monitor, and evidence internal control meets each attribute below:

Attribute	What an auditor/examiner expects you can show
Timely / Current	Data is refreshed on a defined schedule aligned to decision and control needs; stale data is detected and escalated.
Accurate	Validations exist at entry and transformation; reconciliations tie to authoritative sources; error handling is tracked.
Complete	Required fields and records are present; missing data is detected; completeness thresholds exist for critical feeds.
Accessible	Authorized users can retrieve needed information for control performance and oversight; availability issues are logged and addressed.
Protected	Access is restricted and reviewed; changes are controlled; sensitive data is handled per policy.
Verifiable	Lineage exists from source to report; transformations are documented; outputs can be reproduced.
Retained	Records supporting internal control are retained per a defined schedule and can be retrieved for audit/testing.

This is not a requirement to make all enterprise data perfect. It is a requirement to ensure the information used for internal control meets quality standards and can withstand testing (COSO IC-IF (2013)).

Plain-English requirement (what it means day to day)

If a control relies on information (a report, dashboard, metric, extract, ticket queue, model output, exception list), you must treat that information as a controlled asset. You define what “good” looks like, implement checks that prevent or detect bad data, control access and change, and keep enough evidence to show the information was reliable at the time the control ran.

Who it applies to

Entity scope

• Any organization applying COSO internal control expectations (COSO IC-IF (2013)).
• Internal audit and second-line functions assessing internal control design and operating effectiveness (COSO IC-IF (2013)).

Operational context (where it bites)

• Financial close and management reporting.
• Compliance reporting and regulatory submissions (where governed internally, even if COSO is the umbrella framework).
• Operational risk and control testing metrics (KRIs, control performance dashboards).
• Identity and access reporting used for reviews (user listings, privileged access reports).
• Third-party risk reporting (inventory completeness, assessment status, issue aging).
• Data pipelines supporting automated controls (ETL jobs feeding control reports).
• Model inputs/outputs used in decisioning and monitoring.

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

Step 1: Define “information used for internal control”

Create an inventory of in-scope information objects, not just systems:

• Key reports (including “shadow” spreadsheets that feed controls)
• Dashboards/BI outputs
• Data extracts (CSV exports, API pulls)
• Exception queues and tickets
• Reconciliations and control logs

Practical tip: Start from your control library. For each control, ask: “What information does the control operator use to perform or evidence this control?”

Step 2: Tier critical data and reports by risk

Classify in-scope information into tiers such as:

• Tier 1 (high impact): information that drives key controls, material reporting, or high-risk compliance obligations
• Tier 2: monitoring and management oversight
• Tier 3: operational analytics with limited control reliance

Tie the tiering to:

• Control criticality (key control vs. non-key)
• Manual vs. automated reliance
• Sensitivity (confidential, regulated data)
• Change frequency and complexity (multiple transformations increase integrity risk)

Step 3: Assign accountable owners (business + technical)

For each Tier 1 object, assign:

• Business owner (defines meaning, tolerances, use cases)
• Technical owner (pipeline/system reliability, logging, access)
• Control owner (responsible for the control that depends on the information)

Document ownership in the inventory. Auditors look for named accountability, not shared mailboxes.

Step 4: Define quality rules aligned to COSO attributes

Create a short “data quality spec” per Tier 1 object:

• Refresh frequency and allowed lag (timely/current)
• Valid ranges, permitted values, and cross-field checks (accuracy)
• Required fields and record counts/completeness checks (complete)
• Approved distribution channel and access method (accessible)
• Access roles, encryption expectations, and handling rules (protected)
• Lineage and reproducibility requirements (verifiable)
• Retention schedule and retrieval method (retained)

Keep this pragmatic. A one-page spec per Tier 1 object beats a generic enterprise policy that nobody can test.

Step 5: Implement preventive and detective controls at the right points

Map controls to the data lifecycle:

Capture / entry

• Field-level validations (required fields, format checks)
• Duplicate detection
• Approval workflows for sensitive overrides

Transform / pipeline

• Automated reconciliation between source and target totals
• Job monitoring with alerts on failures and late runs
• Change control for transformations (versioning, peer review, rollback)

Storage / access

• Role-based access control aligned to least privilege
• Periodic access reviews for Tier 1 objects
• Integrity controls (hashing/signing where appropriate for extracts), plus audit logs

Use / reporting

• Report certification: documented query logic, filters, and parameters
• Evidence that the report used in the control run was the approved version
• Exception management workflow: triage, correct, re-run, document

Retention

• Retention configuration for logs, extracts, and control run evidence
• Retrieval tests (prove you can produce evidence on request)

Step 6: Build verifiability (lineage + reproducibility) into your operating model

Audits often fail on “verifiable,” because teams cannot explain how a number was produced. Minimum baseline for Tier 1:

• Source systems identified
• Transformation steps documented (even if high level)
• Report logic controlled (query stored, versioned)
• “Run context” recorded (date/time, parameters, data snapshot identifier)

Step 7: Test, document exceptions, and close gaps

Run a short internal test cycle:

• Pick a sample of Tier 1 controls
• Trace the information used back to source (lineage test)
• Re-perform a reconciliation
• Pull access logs and show who changed the logic
• Confirm evidence retention and retrieval

Track findings like control issues: owner, due date, remediation evidence, retest.

Required evidence and artifacts to retain

Keep evidence proportional to tiering. For Tier 1, retain:

Governance and scope

• Inventory of in-scope information objects (mapped to controls)
• Data/report tiering and rationale
• RACI/ownership assignments

Quality and control design

• Data quality specifications (timely/current/accurate/complete/etc.)
• Documented control procedures (what check runs, by whom, how exceptions are handled)
• Data lineage documentation (diagram + narrative)

Control operation

• Data validation logs and exception reports
• Reconciliation workpapers and sign-offs
• Pipeline/job run logs, alerts, and incident tickets
• Access review evidence and approvals
• Change management records for report logic and transformations (tickets, approvals, version history)
• Retention configuration evidence and retrieval test results

Practical note: Evidence must be retrievable. If it lives in ephemeral chat threads or local laptops, it will fail the “retained” and “verifiable” expectations (COSO IC-IF (2013)).

Common exam/audit questions and hangups

Expect these lines of questioning:

• “Which controls rely on this report, and who owns the report logic?”
• “How do you know the report is complete and accurate for the period tested?”
• “Show me the lineage from source system to report output.”
• “What happens when the nightly job fails or runs late? Who is alerted? Where is the ticket?”
• “Who has access to change the report/query/ETL mapping? Show approval and evidence.”
• “Can you reproduce last quarter’s output with the same filters and parameters?”
• “What is your retention schedule for control evidence, and can you retrieve it now?”

Hangups usually occur where teams have informal operational practices but no durable evidence.

Frequent implementation mistakes (and how to avoid them)

1. Treating data quality as a generic policy problem.
   Fix: Build object-level specs and controls for Tier 1 reports/feeds that drive internal control (COSO IC-IF (2013)).

2. Skipping report logic change control.
   Fix: Require tickets and approvals for changes to queries, transformations, or “business logic” measures. Store versions.

3. Relying on manual spreadsheet steps without controls.
   Fix: Register spreadsheets as in-scope information objects, restrict editing, track versions, and reconcile inputs/outputs.

4. No defined timeliness requirement.
   Fix: Set refresh expectations per use case (close vs. daily monitoring) and log when data is late.

5. Access is “protected” in theory but not reviewed.
   Fix: Run periodic access reviews for Tier 1 objects and retain approvals and removals.

6. Evidence exists but cannot be retrieved.
   Fix: Standardize where evidence lives (ticketing system, GRC tool, controlled repository) and test retrieval.

Enforcement context and risk implications

No public enforcement cases were provided for this requirement. Practically, weaknesses here drive:

• Internal control deficiencies because control performers rely on unreliable information (COSO IC-IF (2013)).
• Audit findings tied to inability to verify report completeness/accuracy and to reproduce results.
• Operational risk: decisions based on stale or incorrect information, and delayed detection of issues.
• Security and privacy risk where “protected” and “accessible” are mismanaged (overbroad access, untracked extracts).

Practical 30/60/90-day execution plan

Use a phased plan without artificial precision. Adapt scope to your audit calendar and highest-risk processes.

First 30 days (Immediate stabilization)

• Identify Tier 1 processes and key controls that rely on reports/feeds.
• Build the initial inventory of in-scope information objects mapped to those controls.
• Assign business and technical owners for each Tier 1 object.
• Pick a small set of Tier 1 objects for a pilot and document baseline quality specs.

Days 31–60 (Control implementation and evidence)

• Implement or formalize validations, reconciliations, and job monitoring for pilot objects.
• Put report logic and ETL changes under change control with ticket evidence.
• Establish access review cadence for Tier 1 objects and run the first review.
• Centralize evidence storage and standard naming so retrieval works under audit pressure.

Days 61–90 (Scale and test)

• Expand from the pilot to remaining Tier 1 objects.
• Perform traceability tests (source-to-report) and document results.
• Run a “mock audit” walkthrough: reproduce outputs, show exceptions, show approvals, show retention retrieval.
• Convert recurring issues into backlog items with owners and remediation evidence.

Where Daydream fits naturally: If you struggle to keep an accurate inventory of in-scope reports, owners, controls, and evidence locations, Daydream can act as the system of record for mapping controls to information objects and attaching run evidence, change tickets, and access reviews in one place.

Frequently Asked Questions

What counts as “information used for internal control” in practice?

Any report, extract, dashboard, ticket queue, or spreadsheet that a control performer uses to execute a control or prove it operated. If a control relies on it, it is in scope for this requirement (COSO IC-IF (2013)).

Do I need enterprise-wide data governance to satisfy this?

No. Start with Tier 1 information objects tied to key controls and implement testable quality, access, change, and retention controls. You can expand governance over time while still meeting control needs (COSO IC-IF (2013)).

How do we show “verifiable” to auditors?

Maintain lineage from source to output, store report/query logic with version history, and record run context (parameters, timestamps, dataset identifiers). Auditors want reproducibility and traceability, not narrative assurances (COSO IC-IF (2013)).

We export data to spreadsheets for reconciliations. Is that automatically a failure?

No, but the spreadsheet becomes an in-scope information object. Control access, track versions, document transformation steps, and retain evidence that inputs match source data and outputs were reviewed.

What is the minimum evidence set we should retain?

Keep the inventory and ownership record, the object-level quality spec, logs of validations/reconciliations, access review evidence, change approvals for logic/pipelines, and retention/retrieval proof. Without these, “protected,” “verifiable,” and “retained” are hard to demonstrate (COSO IC-IF (2013)).

How do we handle third-party data feeds that affect controls?

Treat the feed as a Tier 1 information object if controls rely on it. Set completeness/timeliness checks at ingestion, document file/API specifications, and keep exception and escalation records. If the third party can change formats or definitions, add change notification expectations to the contract and monitor adherence.