
How to Use Data Analytics in Internal Audit
Start with the audit question, not the software: define and validate the data, design risk-based tests, investigate exceptions in context and save logic for reuse or monitoring.
PDF • 6 Pages • Free

Match each risk to a practical data test, the fields it needs and whether it suits one-off audit work or continuous monitoring.
Generic analytics scripts produce results that do not answer an audit question. This tool helps auditors choose analytics that directly test a risk, linking the risk hypothesis to a test, the data fields required, the expected exception pattern, and whether the test suits one-time audit work or continuous monitoring.
Use it when designing analytics for an audit, requesting data from process owners, building continuous-monitoring routines or deciding which tests are worth automating. The core inputs are the risk hypothesis, process or transaction type, available datasets, key fields, expected pattern, population volume, refresh frequency and data-quality constraints. The decision matrix maps risk patterns to example tests and monitoring fit: duplicate invoices or payments, transactions just below approval limits, weekend or after-hours activity, recent bank changes before payment, and unusual price, quantity or claim outliers. The working sheet records test logic, expected exceptions, validation needed, frequency and the owner for follow-up.
The worked example tests whether employees split expenses to stay below approval thresholds, by finding same employee, merchant and day combinations whose combined value exceeds the threshold, then confirming legitimate multi-receipt cases, with monthly monitoring if claim data is consistently available.
© Salih Ahmed Islam

Start with the audit question, not the software: define and validate the data, design risk-based tests, investigate exceptions in context and save logic for reuse or monitoring.
PDF • 6 Pages • Free

Decide which audit tests should become monthly, weekly or near-real-time monitoring routines — based on risk, repeatable logic, reliable data and clear ownership.
PDF • 6 Pages • Free

Design and document a repeatable monitoring test: risk statement, data fields and rule logic, alert threshold and tolerance, false-positive handling, alert reviewers, evidence retained and escalation.
PDF • 6 Pages • Free

Issue clear PBC and information requests that state the item, period, population, required fields and format, track owner and status, and check completeness against the source system.
PDF • 6 Pages • Free