Finance should own the reporting objective, IT should own the operating controls that enable it, and audit should test whether the evidence proves control operation. The practical model is shared accountability with clear control ownership, so evidence for access, change, and operations can be reused without changing the underlying control meaning.
What shared responsibility means for ICFR evidence
ICFR evidence works best when the control owner and the evidence consumer are not the same decision-maker. Finance defines the reporting objective and materiality, IT operates the systems and access controls that produce evidence, and audit evaluates whether that evidence is sufficiently reliable, complete, and tied to the control being tested.
The important boundary is that evidence can be reused across functions without changing the underlying control. A change ticket, access review, or job log may support an ICFR assertion, but only if the control definition, ownership, and population being tested are clear enough that all three functions interpret the evidence the same way.
How finance, IT, and audit divide ownership without fragmenting the control
Finance should own the reporting requirement, the account balances or disclosures affected, and the threshold for what matters to the financial statements. That gives the control its business purpose and prevents IT from redefining the objective as a purely technical exercise.
IT should own the operating controls that make the reportable process work, including access provisioning, change management, batch processing, interfaces, and system configurations. Where those controls touch sensitive access or segregation of duties, the ownership should be explicit enough that the evidence shows who approved, executed, and reviewed the action. NHIMG’s Segregation of Duties (SoD) Guide is useful here because SoD conflicts often show up in the same finance-related workflows that generate ICFR evidence.
Audit should not design the control, but it should define what proof is needed for testing and whether the evidence is persuasive. That means audit may request different support for the same control depending on the risk, such as a log extract, approval record, or access recertification, as long as the evidence still proves the control operated as intended.
What makes ICFR evidence reusable and still meaningful
Reusable evidence depends on consistency, not convenience. If a single report, log, or approval trail is used by finance, IT, and audit, each party must understand the same control description, the same period of performance, the same population, and the same exception-handling rule. Otherwise the evidence may be authentic but not audit-ready.
Strong evidence usually has a clear origin, a defined system of record, and enough context to show that the control operated over the relevant period. For example, access evidence should show the user population and review outcome, while change evidence should show the request, approval, implementation, and post-change traceability. When those links are weak, the evidence may describe activity but not control operation.
For organizations that rely on cloud or shared platforms, the control owner should also know whether the evidence reflects a configuration state, a workflow approval, or a vendor report. In practice, that distinction matters because ICFR testing often fails when teams confuse operational convenience with control sufficiency.
Risk and Threat Considerations
ICFR breaks down when responsibility is shared informally, because each function may assume the others are verifying a different thing. That creates gaps in ownership, duplicated approvals, and evidence that is technically real but not aligned to the control objective. The result is not just a documentation problem, it can become a control failure if access, change, or operational activity is not actually constrained or reviewed.
Failure mechanism: Finance can accept evidence that supports the reporting assertion, IT can produce evidence that shows system activity, and audit can test a control that was never defined precisely enough to reconcile those two views. In that case, the evidence trail may look complete while the actual control meaning drifts across teams.
Impact: The organization can end up with passed tests that do not prove the right control, failed tests caused by unclear ownership rather than bad operation, or remediations that fix paperwork instead of the underlying process. Over time, that weakens trust in the ICFR program and makes repeat findings more likely.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while SOC 2 (AICPA) and ISO/IEC 27001:2022 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| SOC 2 (AICPA) | CC6.1 — Logical and Physical Access Controls | ICFR evidence often relies on access and approval controls that need auditable ownership. |
| Recommendation — Document control ownership and retain evidence showing access and approval controls operated as designed. | ||
| NIST SP 800-53 Rev 5 | AU-6 — Audit Record Review, Analysis, and Reporting | Audit must evaluate whether logs and records prove control operation, not just activity. |
| Recommendation — Review audit records for evidence that the control executed and exceptions were handled. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Shared ICFR evidence depends on explicit access ownership and reviewable access decisions. |
| Recommendation — Assign access ownership clearly and retain evidence for access reviews and approvals. | ||
| CIS Controls v8 | CIS-5 — Account Management | ICFR evidence commonly includes account and access governance over finance systems. |
| Recommendation — Centralize account ownership and preserve evidence for provisioning, review, and removal. | ||
Practitioner Guidance
What to verify: Confirm that every ICFR control has one accountable business owner, one operating owner, and one testing expectation. If the same evidence is used by multiple functions, document exactly what each party is supposed to conclude from it.
What good looks like: The control description states the objective in finance language, the operating procedure states the system action in IT language, and the audit workpaper can trace the evidence back to the tested control without reinterpretation.
Common mistake: Treating evidence as transferable without preserving context. A report, screenshot, or export is only useful if the period, population, exception rule, and approval path remain clear enough to support the same control assertion.
Practitioner takeaway: Shared responsibility works when finance owns the assertion, IT owns the mechanism, and audit owns the test, because ICFR evidence must prove control operation, not just show that activity occurred.