Lesson 6 of 6
Audit walkthrough
12 min
The best way to know whether your sign-off is audit-ready is to rehearse the audit. In this lesson we follow an auditor walkthrough of one Contoso SOX control through the S/4HANA release that introduced it, and note what makes each answer strong or weak. The same pattern applies to a GxP inspection of a validated function.
The control
Control P2P-C07: supplier invoices for company code 1710 whose price differs from the purchase order beyond the configured tolerance are blocked for payment, and only authorized accounts payable supervisors can release them. Supplier: Lakeside Components. The control is automated (tolerance check) with a manual element (authorized release).
- Invoice enteredLakeside Components invoice for company code 1710
- Tolerance checkAutomated: price compared with the purchase order against the configured tolerance
- Blocked for paymentOutside tolerance → invoice cannot be paid
- Authorized releaseManual: only an accounts payable supervisor can release the block
- PaymentReleased invoice is included in the payment run
The walkthrough
| Auditor asks | Strong answer | Weak answer |
|---|---|---|
| What is the control and its risk? | Control description, risk rating and owner from the control register, linked to the requirement | "It blocks wrong invoices" |
| How do you know it was designed correctly? | Configuration specification for tolerance keys, reviewed and approved, with the tolerance values | A consultant says it is standard |
| How was it tested? | Test cases TC-P2P-071 to 073 at, inside and outside tolerance; linked in the traceability matrix | A single positive test |
| Show me the evidence. | Test runs with tester, date, system and client, invoice numbers and block status, expected vs actual | Screenshots without dates or document numbers |
| What failed, and what happened? | Deviation record, fix, retest and approval | "Nothing failed" when the log shows a failure |
| Who approved, and when? | Process owner Dan, after execution, with the meaning of the approval | Approval dated before testing |
| How do you know it has not changed since? | Change management records for the configuration; access review for release authority | No answer |
Walking an auditor through one control. Prepare these answers before the audit, for every key control.
- Control registerP2P-C07, risk High, owner Dan
- DesignTolerance configuration spec, approved
- TestsTC-P2P-071, 072, 073 linked in the matrix
- EvidenceRuns with invoice numbers and block status
- DeviationNone for this release
- ApprovalDan, after execution
- OngoingChange control and access review keep it effective
Preparing for the real thing
- Pick a sample of key controls or validated functions and run a mock walkthrough with someone who did not do the testing.
- Time how long it takes to retrieve each piece of evidence; anything over a few minutes is a risk.
- Check approval timestamps against execution timestamps for every sampled item.
- Confirm that the people who will answer questions know the evidence and the procedure.
- Fix gaps through documented corrections, never by silently editing records.
After the audit
Treat audit findings like escaped defects. For each finding, record the root cause (missing negative test, unclear procedure, weak retrieval, an access gap), the corrective action and the preventive action, each with an owner and a date. Feed the preventive actions into your evidence standard, your test templates and the release assessment procedure, so the same finding cannot recur next year. Close each action with evidence, because the auditor will check the follow-up at the next review.
- FindingRecorded with the control or function it concerns
- Root causeMissing negative test, unclear procedure, weak retrieval or an access gap
- Corrective actionFixes this instance, with an owner and a date
- Preventive actionUpdates the evidence standard, test templates or release assessment
- Close with evidenceProof ready for the auditor's follow-up at the next review
What auditors and inspectors notice
Experienced reviewers look less at volume and more at consistency. They notice when the procedure says one thing and the evidence shows another, when approvals come before execution, when failures vanish, and when nobody can explain why a function was tested lightly. They are reassured by clear risk rationales, honest deviation records, quick retrieval and people who understand their own evidence. A sign-off built on those qualities survives audit; one built on volume often does not.
What would you do?
During a mock walkthrough, Grace notices that approval for control O2C-C03 is time-stamped one day before the retest that made it pass. What should happen?
- Rehearse audits with mock walkthroughs of sampled controls or validated functions.
- Strong answers come from linked records: register, design, tests, evidence, deviations, approval, ongoing control.
- Check approval timestamps against execution, and make sure evidence can be retrieved in minutes.
- Consistency and honest deviation records matter more to auditors than volume.
Check your understanding · not graded
Lesson check
1. What is the strongest answer to "how do you know the control has not changed since testing?"
2. Why run a mock walkthrough with someone who did not do the testing?
3. An approval is time-stamped before the evidence it approves. What is the right response?
4. What do experienced auditors value most in evidence?