Information Requirements Identification

The “information requirements identification” requirement means you must run a defined, repeatable process to determine what information internal control owners need, when they need it, and what quality it must meet to support internal control and objective achievement. You operationalize it by mapping objectives and controls to specific data inputs, owners, sources, quality rules, and review cadence, then proving it works in practice. (COSO IC-IF (2013))

Key takeaways:

• Document an end-to-end process that links objectives and controls to specific information inputs and quality expectations. (COSO IC-IF (2013))
• Assign accountable owners for each information requirement, including source-of-truth systems, validation checks, and escalation paths. (COSO IC-IF (2013))
• Keep evidence that the information is identified, produced, reviewed, and used to operate controls as designed. (COSO IC-IF (2013))

Information failures break internal control quietly: a control can be perfectly designed, but if the data feeding it is incomplete, late, or wrong, the control outcome is unreliable. COSO’s Principle 13 includes a specific point of focus requiring “a process … to identify the information required and expected” to support the other internal control components and achievement of objectives. (COSO IC-IF (2013)) For a Compliance Officer, CCO, or GRC lead, this requirement sits at the seam between governance and operations. It forces clarity on questions auditors will ask anyway: What reports do control owners rely on? Where does the data come from? Who validates it? What happens if the report is wrong or late?

Operationalizing this requirement does not mean writing a theoretical “data is important” policy. It means building an inventory of information requirements tied directly to objectives, risks, and controls, then setting expectations for quality (accuracy, completeness, timeliness), access, retention, and change management. The goal is practical: you can point to each key control and show the exact information it needs, how that information is produced, and how you know it is dependable. (COSO IC-IF (2013))

Regulatory text

COSO Principle 13 – Point of Focus (excerpt): “A process is in place to identify the information required and expected to support the functioning of the other components of internal control and the achievement of the entity's objectives.” (COSO IC-IF (2013))

What the operator must do: establish, document, and run a process that determines (1) what information is needed for internal control to function across components, (2) what information is expected by control owners and decision-makers, and (3) how that information supports achieving objectives. Your process must be more than a one-time exercise; it must be repeatable and capable of responding to changes in objectives, systems, third parties, and risk. (COSO IC-IF (2013))

Plain-English interpretation (what this requirement really means)

You need a reliable way to answer: “What information do we need to run our controls and manage to our objectives, and how do we know that information is fit for purpose?” (COSO IC-IF (2013))

In practice, this becomes:

• A catalog of required information inputs tied to objectives and key controls (reports, dashboards, reconciliations, tickets, attestations, logs, third-party statements).
• Quality expectations for each input (what “good” looks like for accuracy, completeness, timeliness, and appropriate access).
• Operational ownership (who produces, who reviews, who approves, and who escalates issues).
• Ongoing maintenance so the catalog stays aligned when systems change, org structure shifts, or control design changes. (COSO IC-IF (2013))

Who it applies to (entity and operational context)

This applies to any organization implementing COSO’s Internal Control – Integrated Framework, including teams responsible for internal controls over operational, compliance, and reporting objectives. (COSO IC-IF (2013))

Operationally, you will involve:

• Control owners (Finance, Compliance, Security, Operations, HR) who consume information to execute controls.
• Data/report owners (Analytics, IT, system admins) who generate or maintain the sources.
• Second line / GRC who sets the standard, ensures coverage, and tests adherence.
• Internal Audit who evaluates whether the process exists and works as intended. (COSO IC-IF (2013))

This requirement becomes higher-friction where:

• Controls rely on spreadsheets or manual extracts.
• Data comes from multiple systems with inconsistent definitions.
• Key information is provided by a third party (SOC reports, uptime statements, subcontractor attestations).
• The business is undergoing system migrations or rapid process change. (COSO IC-IF (2013))

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

Step 1: Define scope and objectives you are supporting

Start with the objectives relevant to your internal control program (for example, compliance objectives, reporting objectives, operational objectives). Then list the key processes and controls that materially support them. Keep the initial scope focused on controls where information quality is a realistic failure mode. (COSO IC-IF (2013))

Artifact: Objectives-to-controls scope memo or control universe extract with “in scope for information requirements” flag.

Step 2: Build an “Information Requirements Register” tied to controls

For each key control (or control activity cluster), capture the information it requires. Treat “information” broadly: reports, system logs, approval records, exception queues, reconciliations, third-party confirmations, and management attestations. (COSO IC-IF (2013))

Minimum fields to include:

• Objective supported
• Control name/ID and owner
• Information input name (report/log/attestation)
• Source system(s) and system owner
• Method of generation (automated report, manual extract, third-party delivered)
• Frequency/availability expectations
• Downstream use (what decision/control step it enables)
• Storage location and retention expectations
• Known limitations (manual steps, dependencies, cut-off times) (COSO IC-IF (2013))

Practical example: If a control requires review of terminated-user access, the “information requirement” is not “access report.” It is a specific population with cut-off timing, required fields, inclusion/exclusion logic, and an owner who can explain the query or export steps.

Step 3: Set information quality expectations that match the control’s risk

Define what “required and expected” means for each input. Use simple quality dimensions that operators can test:

• Accuracy: values match the underlying system of record; calculations are correct.
• Completeness: population includes all required records (no missing entities, dates, business units).
• Timeliness: available when the control must be performed; data recency meets the control need.
• Access/Integrity: only authorized changes; protected from tampering where relevant. (COSO IC-IF (2013))

Then decide the validation approach. Examples:

• Automated controls: report logic reviewed upon change; sampling after major releases.
• Manual extracts: documented steps; independent re-performance checks; reconciliations to source totals.
• Third-party inputs: verification of authenticity and coverage; tracking of receipt and review. (COSO IC-IF (2013))

Artifact: Data quality expectations per information item, plus validation method.

Step 4: Assign ownership and escalation paths

Each information requirement needs an accountable owner for:

• Producing or obtaining the information
• Verifying quality checks ran and were reviewed
• Resolving issues (data gaps, late reports, broken queries)
• Escalating when quality failures affect control performance (COSO IC-IF (2013))

Avoid shared-mailbox ownership. Name a role and a backup.

Artifact: RACI for information items (producer, reviewer, accountable owner, escalation contact).

Step 5: Integrate the register into change management and control testing

Your process fails if it sits outside day-to-day operations. Add triggers to update the register when:

• A control changes (design, frequency, evidence)
• A source system changes (fields, logic, access roles)
• A report/query changes (filters, joins, calculation rules)
• A third party changes scope or provides different assurance artifacts (COSO IC-IF (2013))

Then, align testing: during control testing, validate that the information used matches the registered requirement and that quality checks occurred.

Artifact: Change triggers checklist; testing procedure updates referencing the register.

Step 6: Prove “the process is in place” with operating evidence

COSO is explicit about having a process. Show it operates:

• Meeting notes or tickets where information requirements were created/updated
• Approvals of new/changed information sources
• Evidence that control owners received information on time and acted on exceptions
• Issue logs showing defects were found, triaged, and remediated (COSO IC-IF (2013))

Where Daydream fits: Many teams track controls in one system, evidence in another, and report logic in someone’s head. Daydream can serve as the operational workspace to connect controls to their required information inputs, assign owners, and maintain a clean audit trail of changes and reviews across third-party and internal sources.

Required evidence and artifacts to retain (audit-ready list)

Maintain these artifacts in a consistent repository with clear versioning:

1. Information Requirements Register mapped to objectives and controls. (COSO IC-IF (2013))
2. Data dictionary / report specifications for key reports (definitions, filters, logic, parameters).
3. Ownership and RACI for information production, review, and issue resolution.
4. Quality checks and validation evidence (reconciliations, sampling workpapers, automated check logs).
5. Change management records for report/system changes impacting control information.
6. Control execution packages showing the information was used (review sign-offs, exception handling).
7. Issue log and remediation records for information quality problems and their fixes. (COSO IC-IF (2013))

Common exam/audit questions and hangups

Auditors and internal control evaluators commonly probe:

• “Show me the process” (not just a document). Who runs it, how often, and what triggers updates? (COSO IC-IF (2013))
• “How do you know this report is complete?” Walkthrough from system of record to report output.
• “What changed?” Evidence you reassessed requirements after system/report changes.
• “What happens when information is late or wrong?” They will look for documented exceptions and remediation.
• “Is the information requirement aligned to the control?” Controls often drift, while reports stay the same. (COSO IC-IF (2013))

Hangup to expect: teams confuse evidence retention with information requirements definition. Evidence is what you keep after performing a control; information requirements are what you must have available to perform it correctly.

Frequent implementation mistakes (and how to avoid them)

1. Listing generic inputs (“system report”) without specifications.
   Fix: record the exact report name, parameters, fields, logic owner, and where it is stored.

2. No quality expectation beyond “reviewed.”
   Fix: define completeness/accuracy checks that a second person could repeat.

3. Relying on tribal knowledge for manual extracts.
   Fix: document extraction steps and add independent verification for high-risk data pulls.

4. Ignoring third-party-provided information dependencies.
   Fix: include third-party artifacts in the register (what you expect, when, how you verify authenticity and scope). Use “third party” as a first-class source type.

5. Treating the register as a one-time implementation deliverable.
   Fix: connect it to change management and control testing so updates are routine. (COSO IC-IF (2013))

Enforcement context and risk implications

No public enforcement cases were provided in the source material for this COSO point of focus. (COSO IC-IF (2013)) Operationally, weak information requirements identification still creates real exposure:

• Controls may “pass” on paper while failing in substance because the underlying information is incomplete or inaccurate.
• Reporting and compliance decisions can be made on outdated or improperly scoped populations.
• Third-party risk decisions can rely on stale assurance artifacts or mismatched scope statements. (COSO IC-IF (2013))

Treat this requirement as a control reliability issue: if information quality is ungoverned, your control testing results become less trustworthy.

Practical execution plan (30/60/90-day)

Numeric timelines are useful, but your execution should follow phases driven by scope and readiness rather than promises about exact duration. Use this structure and adjust based on control count and system complexity. (COSO IC-IF (2013))

First phase (Immediate): Stand up the process and cover the highest-risk controls

• Name an executive sponsor and process owner (often GRC/Compliance).
• Define the register template and minimum required fields.
• Identify the set of key controls where information failure would break the control outcome.
• Draft information requirements for that set, assign owners, and confirm sources of truth.
• Add at least one quality check per critical information item and document how it is evidenced.

Second phase (Near-term): Validate, integrate with change, and make it testable

• Walk through a sample of controls end-to-end: source system → report → reviewer → exception handling.
• Tighten report specs and data definitions where walkthroughs expose ambiguity.
• Add update triggers to change management (system changes, report changes, control design changes).
• Update control testing procedures to reference the register and verify information quality evidence.

Third phase (Ongoing): Expand coverage and operationalize reporting

• Expand the register across remaining key controls and material processes.
• Create simple KPIs for operations (late reports, failed reconciliations, recurring data defects).
• Run periodic reviews with control owners and system/report owners to keep requirements current.
• Use tooling (including Daydream, if applicable) to centralize ownership, evidence, and change history. (COSO IC-IF (2013))

Frequently Asked Questions

What counts as “information” for information requirements identification?

Any input needed to execute controls or manage to objectives: reports, logs, reconciliations, approvals, exception queues, and third-party attestations. Capture both automated outputs and manual spreadsheets if they drive control decisions. (COSO IC-IF (2013))

Do I need a separate policy for this requirement?

A policy can help, but auditors typically want an operating process and proof it runs. A register tied to controls, plus ownership, quality rules, and change triggers, is usually more persuasive than a stand-alone statement. (COSO IC-IF (2013))

How detailed should a report specification be?

Detailed enough that another qualified person can reproduce the report and explain key filters, logic, and parameters. If the report changes, the spec should make it clear what must be reviewed and revalidated. (COSO IC-IF (2013))

How do we handle third-party-provided information (SOC reports, attestations, uptime statements)?

Treat third-party artifacts as information requirements with defined expectations: what document, coverage period, scope, and receipt date you require, plus who verifies authenticity and matches scope to your reliance. Record exceptions and follow-ups when artifacts are late or incomplete. (COSO IC-IF (2013))

Our controls rely on spreadsheets. Can we still meet the requirement?

Yes, but you need tighter definition and validation: document how the spreadsheet is populated, what source totals it reconciles to, who reviews formulas, and how version control is handled. If the spreadsheet is a recurring risk, plan a migration to a controlled reporting source. (COSO IC-IF (2013))

What is the minimum evidence to show “a process is in place”?

A maintained information requirements register, named owners, and operating records showing updates, approvals, and quality checks tied to actual control execution. Auditors want to see that requirements are identified, kept current, and used. (COSO IC-IF (2013))