TL;DR: IT application controls are embedded checks that decide whether transactions are complete, accurate, authorised, and valid, but auditors can only rely on them when underlying IT general controls and access governance are effective, according to SafePaaS. The real shift is from proving controls exist to proving they stay effective continuously across systems, identities, and changes.
NHIMG editorial — based on content published by SafePaaS: IT application controls, ITGCs, and SOX audit readiness
By the numbers:
- Only 5.7% of organisations have full visibility into their service accounts.
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
Questions worth separating out
Q: How should teams prove that IT application controls are actually effective?
A: Teams should prove effectiveness by tying each control to a specific risk, testing the underlying access and change paths, and retaining system-generated evidence of operation.
Q: Why do IT general controls matter so much for IT application controls?
A: IT general controls determine whether IT application controls can be trusted.
Q: What do organisations get wrong about ITAC testing?
A: They often test the control at a point in time but ignore the conditions that can silently disable it later.
Practitioner guidance
- Map control ownership to risk and assertion Link each in-scope IT application control to the specific financial statement assertion it protects, the business process it governs, and the system owner responsible for change approval.
- Treat control override rights as privileged access Review who can alter approval thresholds, posting rules, or matching logic, and fold those permissions into the same access review process used for other high-risk identities.
- Re-test controls after every material change Require formal revalidation after upgrades, patches, workflow redesign, or migration work so a control cannot drift from design intent without detection.
What's in the full article
SafePaaS's full article covers the operational detail this post intentionally leaves for the source:
- Detailed examples of ITAC domains such as three-way match, tolerance limits, and approval thresholds across ERP environments.
- The control checklist for change management, testing, and revalidation after upgrades or process redesign.
- How SafePaaS frames continuous monitoring, exception reporting, and SOX-aligned evidence generation.
- The platform-specific view of access governance, ITGC dashboards, and audit preparation workflows.
👉 Read SafePaaS's guide to IT application controls and SOX assurance →
IT application controls: why continuous assurance is now the issue?
Explore further
IT application controls are only as trustworthy as the identity paths behind them. The article correctly separates ITACs from ITGCs, but the deeper governance point is that transaction controls inherit risk from the identities that can configure, approve, or override them. If access to control parameters is not lifecycle-managed, the transaction rule becomes a policy statement rather than an enforceable control. Practitioners should treat control override rights as privileged access, not routine application access.
A few things that frame the scale:
- Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: Who is accountable when transaction controls fail in a SOX environment?
A: Accountability sits with the control owner, the system owner, and the identity governance function that allows override access. When a control fails, organisations need to show who approved the change, who monitored the exception, and who owns remediation. Continuous assurance makes that chain visible before audit findings do.
👉 Read our full editorial: IT application controls need continuous proof, not periodic sampling