Audit should define the assurance objective, finance should own the business process risk, and IT should maintain the configuration and monitoring needed to keep the control effective. If those roles are separated without a shared inventory and exception workflow, the organisation ends up with fragmented evidence and unclear ownership.
How to divide ITAC responsibility without blurring ownership
ITACs work best when the control owner and the control operator are not the same by default. Audit sets the assurance expectation, finance owns the business risk that the control is meant to address, and IT owns the technical design, evidence capture, and ongoing monitoring. That separation keeps the control testable and prevents one function from grading its own work.
The practical issue is that ITACs often sit across process, system configuration, and reporting logic, so responsibility has to follow the control objective rather than the org chart. If finance owns a reconciliation, for example, it should still depend on IT for parameter integrity, logging, and change management where the control is automated.
What each function should own in practice
Audit should define what “effective” means for the control, including the assertion, the population in scope, and the evidence needed to support testing. Finance should own the business process risk, decide the tolerance for exceptions, and approve remediation when the process design changes. IT should own the system configuration, interface reliability, access controls, and the operational checks that keep the control functioning between audits.
A useful boundary rule is this: if a failure would change the financial assertion, finance owns the risk decision; if the failure would change how the system enforces the control, IT owns the technical fix; if the failure would change how assurance is evidenced, audit owns the testing standard. That avoids the common problem where everyone is “involved” but nobody is accountable.
For many organisations, the cleanest split is to treat audit as independent validation, finance as the control sponsor, and IT as the control maintainer. When the control spans multiple systems, a shared inventory of ITACs and named exceptions becomes essential, because otherwise each team will maintain its own partial view and the evidence will not reconcile.
Why fragmented ownership breaks control effectiveness
When ITAC ownership is split informally, the failure usually is not the control itself but the handoff. A finance team may believe a report is still covered after a system upgrade, while IT has changed the underlying job or data feed, and audit only discovers the gap at the next review cycle. The result is stale evidence, duplicated testing, and exceptions that are tracked in different places.
That is why a shared inventory and exception workflow matters as much as the control design. In practice, the inventory should show the control objective, system dependency, owner, reviewer, test frequency, and approved compensating controls. The exception workflow should record who accepted the risk, for how long, and what evidence will close it.
Where the control depends on privileged configuration or automated jobs, the boundary becomes even more important because the operating team can change the control without changing the policy. In that situation, the organisation should use independent review of control changes, much like how access governance distinguishes between control owners and approvers. See Ultimate Guide to NHIs, Regulatory and Audit Perspectives for a broader treatment of audit trails, governance obligations, and evidence discipline across identity-dependent controls.
Practical operating model for shared accountability
Start by assigning one named business owner, one technical owner, and one assurance owner for every ITAC. The business owner, usually in finance, should accept the risk and decide whether a control weakness can be tolerated. The technical owner, usually in IT, should be accountable for configuration, monitoring, and change control. The assurance owner, usually audit or control testing, should validate whether the control still works as designed.
Then make the handoffs explicit. Any change to a source system, interface, report logic, or privileged access path should trigger a review of the related ITAC record before production deployment. Any exception should have an expiry date and a compensating control, or it should be treated as a control failure rather than a temporary deviation.
That model also scales better for audits because it produces a single trail of ownership decisions instead of a chain of emails. If the organisation can show who approved the risk, who implemented the fix, and who verified the evidence, the control is far easier to defend than a process that depends on institutional memory.
Risk and Threat Considerations
Shared ITAC responsibility can fail when ownership is split by function but not by decision. The most common exposure is silent control drift: finance assumes the process is still controlled, IT changes the underlying system, and audit only sees the break after the reporting period closes.
Failure mechanism: The control changes in production without a corresponding update to the control inventory, exception log, or test plan, so the evidence no longer matches the real process.
Impact: The organisation can miss material weaknesses, overstate control effectiveness, or spend audit effort testing a control that no longer exists in the form documented.
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 sets the technical controls, while ISO/IEC 27001:2022 and SOC 2 (AICPA) define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AU-6 — Audit Record Review, Analysis, and Reporting | ITAC ownership depends on reviewable evidence and exception tracking. |
| AC-6 — Least Privilege | ITACs often fail when IT or finance retain unnecessary control access over the process. | |
| Recommendation — Use AU-6 to define who reviews control evidence and how exceptions are escalated. Apply AC-6 to restrict control administration to the minimum required access. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | ITAC effectiveness relies on clear control ownership and access boundaries over systems and evidence. |
| Recommendation — Define access boundaries so control operators cannot silently alter the evidence path. | ||
| SOC 2 (AICPA) | CC6.1 — Logical and Physical Access Controls | Shared ITAC responsibility depends on preventing unauthorized changes to control operation. |
| Recommendation — Implement CC6.1 to ensure only authorized roles can change control-relevant settings. | ||
Practitioner Guidance
What to verify: Require every ITAC to have a named business owner, technical owner, and assurance owner, plus a current description of the control objective and evidence source. If any one of those is missing, the control should be treated as unresolved rather than “shared.”
Common mistake: Teams often split responsibility by task instead of by decision. That produces overlap in review work but no one accountable for accepting risk, maintaining the control, or proving it still operates as intended.
What good looks like: One inventory, one exception workflow, one test standard, and one clear path for changes from system update to control revalidation. When those are in place, audit can test independently without having to reconstruct ownership from multiple departments.
Practitioner takeaway: For ITACs, shared responsibility works only when each function owns a distinct decision, not just a piece of the workflow, and the inventory is the control plane that keeps those decisions aligned.
Related resources from NHI Mgmt Group
- How should audit, finance, and IT share responsibility for ICFR evidence?
- Why do non-human identities create more audit risk than human accounts?
- Why do non-human identities create audit risk in modern environments?
- Who is accountable for maintaining internal controls over financial reporting when security and finance teams share responsibility?