10 Things Every Auditor Should Test for an ITAC
The approach that will turn you into the auditor client actually trusts.
When I first started testing IT application controls, I made the same mistake over and over again.
I would open the control description, skim through it, and start pulling attributes from last year’s workpapers.
It was quick. It looked efficient.
But it was also wrong.
I was testing without truly understanding the control. And the more controls I tested, the more I realized something simple but game-changing.
No matter how complex the control looks, there are 10 things you must understand and test every single time.
Miss even one, and you leave risk on the table.
This list didn’t come from a textbook. It came from late nights, tricky walkthroughs, and review comments that stung.
So here are the 10 things I now test for every ITAC without exception.
1. Where the control fits in the business process
You can’t test in isolation. Controls exist for a reason, and that reason is tied to a risk in the business process.
Example (Business Process): An automated invoice generation control in an Order-to-Cash process ensures every customer invoice contains mandatory fields (customer ID, tax rate, payment terms) and accurate totals.
If it fails? Revenue may be misstated or invoices may be legally non-compliant.
SOX 404 Angle: This control directly impacts revenue recognition - a key financial statement assertion. An error here could be a material weakness.
2. Systems and applications involved
Many ITACs aren’t single-system features. They pull data from, or feed into, other systems.
Example: A purchase order approval control in Oracle may rely on vendor master data from SAP. If that vendor data is incomplete or incorrect, the control can fail even if Oracle is working fine.
Why it matters: If you don’t know the full system landscape, you’ll miss upstream or downstream dependencies that impact your test.
3. Tailored testing attributes
Your attributes must reflect this control, in this process, in this client’s environment.
Example: A validation control that checks the date format in journal entries may require testing for:
DD/MM/YYYY format acceptance
Rejection of MM/DD/YYYY
Handling of blank dates
If you copy last year’s attributes without this detail, you might pass the control without ever proving it works for its real-world risks.
4. Test scenarios
The biggest gap I see in ITAC testing is lack of negative scenarios.
Example: Control: “System restricts posting of journal entries to closed periods.” Test scenarios should include:
Posting to open period (should succeed)
Posting to closed period (should fail)
Changing period status mid-process (should follow updated rules)
SOX 404 Tip: Negative testing is critical evidence for design and operational effectiveness.
5. Trigger mechanism
How does the control start? If you don’t know the trigger, you might test at the wrong time or miss dependencies.
Example:
User-initiated: A credit limit check runs only when a sales order is saved.
Scheduled: An interface reconciliation runs nightly at 2:00 AM.
User Termination: User's access is automatically revoked when the HR team inputs the termination date.
6. Frequency
Frequency determines sampling.
Example: If a control runs daily (e.g., automated three-way match of PO, GRN, and invoice), you need to test multiple days to ensure consistency.
If it’s annual (e.g., vendor master review), one instance is your population and it better be right.
7. Configuration settings
An ITAC is only as strong as its configuration.
Example: An ERP prevents unbalanced journal entries but only if the “Require balanced journal entries” flag is enabled.
If an admin can disable that flag, the control’s design effectiveness is compromised. Document the settings that make the control function and what happens if those change.
If one toggle can disable a control, you need to know about it.
8. System manuals and standard functionality
If it’s a standard ERP feature, use the manual but match the version to the environment.
Example: Workday’s standard validation to prevent duplicate employee IDs is great evidence unless the client’s environment is on a different version where that setting is optional.
9. People involved
List who can configure, run, or review the control. Access testing here is just as important as functional testing.
Example: If a junior AP clerk can change tolerance levels for invoice matching, your control is exposed even if it “works” technically.
10. Review process
If human review is part of the control, understand exactly what the reviewer checks.
Example: An automated exception report is generated daily and reviewed by a supervisor. Testing should verify:
The report includes all exceptions (completeness)
The supervisor follows up on each one (effectiveness)
SOX Reminder: A review without follow-up is not a control it’s a checkbox.
These 10 points are my guardrails.
They keep me from falling into the trap of “testing by template.”
The difference between an average ITAC tester and a great one isn’t technical skill, it’s how deeply you understand the control’s context.
In Part 4, we’ll go deeper into how to test each ITAC type from Part 2 with scenarios, pitfalls, and real evidence examples.
If you haven’t caught up yet: