What should organisations do when ITAC testing only happens at audit time?

Why Audit-Only ITAC Testing Fails Operationally

When ITAC testing is deferred until audit time, the control is no longer managed as a live business process. Teams end up proving a point-in-time claim instead of validating whether the control actually works in day-to-day conditions, which means gaps in ownership, evidence quality, and remediation timing stay hidden until they are expensive to fix.

That usually turns the audit into a proxy for control design. A control that only gets tested under deadline pressure often has no stable test cadence, no clear evidence trail, and no dependable exception handling, so the organisation learns about weak controls too late to change behaviour before review.

What Changes When Testing Becomes Routine

Routine testing shifts ITAC from a retrospective proof exercise to an operating discipline. Evidence capture can happen at the point of execution, exceptions can be triaged while the context is still fresh, and control owners can correct failures before they become audit findings. That is materially different from assembling screenshots and approvals after the fact.

For organisations that also need defensible governance records, the point is to treat testing artefacts as part of normal control operation, not as audit theatre. NHIMG’s Ultimate Guide to NHIs for Regulatory and Audit Perspectives reinforces the same pattern for access governance and audit trails: recurring review is what makes evidence reliable.

In practice, routine testing works best when it is attached to the process that produces the control outcome. If approvals, recertifications, logging, or exception sign-offs are happening elsewhere, the evidence will always be more fragile than the control itself.

How to Manage Exceptions Without an Audit Scramble

Exceptions should be reviewed through normal governance, with a clear decision on whether they are temporary, compensating, or must be removed. The useful distinction is between a controlled deviation with a documented expiry date and a permanent gap that has simply been tolerated long enough to become invisible.

SOC 2 Trust Services Criteria (AICPA) is a good external reference point for this discipline because it expects controls to be demonstrable, not improvised at review time. A similar mindset applies whether the control is internal, customer-facing, or part of a third-party assurance story.

Where the organisation uses cloud or platform controls, the same principle applies to configuration, access review, and evidence retention. The most common failure is assuming that a control is “covered” because a screenshot or export can be produced later, when in reality no one can prove the control operated continuously.

Risk and Threat Considerations

Audit-only testing creates a blind spot between reviews, and that gap is where control drift, undocumented exceptions, and stale evidence accumulate. The result is not just audit pain, it is also weaker detection of failed approvals, expired reviews, and access that remains active because nobody is checking it in the normal operating rhythm.

Failure mechanism: testing is separated from execution, so problems are discovered only when evidence is assembled for assurance rather than when the control first fails.

Impact: remediation becomes compressed into audit windows, exception volume rises, and the organisation is more likely to carry control weaknesses into the next reporting period.

Practitioner Guidance

What to prioritise: Move from annual or audit-led verification to a recurring test schedule that matches the control’s real operating frequency. The most valuable controls to start with are the ones whose failure would create the biggest exception backlog or the hardest-to-reconstruct evidence trail.

What to verify: Confirm that each control has an owner, a test cadence, a defined evidence source, and an exception workflow with expiry and remediation dates. If any of those four items are missing, the control is still audit-dependent even if it is formally documented.

Common mistake: Treating evidence collection as a separate compliance task instead of a byproduct of normal operations. That shortcut usually produces good-looking files and poor assurance, because it records what was assembled rather than what was actually done.

Practitioner takeaway: A control is only audit-ready when it is already operating, measured, and correctable in steady state, not when a team can temporarily reconstruct it under deadline pressure.

Related resources from NHI Mgmt Group

• How do organisations reduce the dwell time of exposed credentials at scale?
• What happens when organisations rely on point-in-time security testing instead of continuous attack emulation?
• What happens when organisations rely on point in time security testing instead of continuous analytics?
• What happens when organisations try to clean up entitlements only at audit time?