Post-Implementation Review (PIR) in IS Audit
UAT asks if the system is ready. A PIR asks what it actually delivered.
A post-implementation review (PIR) looks back at a system once it is live and settled, and asks two questions: did the project deliver what the business case promised, and are the controls working as designed in real use. It belongs to the last SDLC phase, maintenance.
It is not a repeat of user acceptance testing. UAT asks whether the system is ready to go live. A PIR asks what actually happened after it did. The evidence is different too: production error logs, real reconciliations, actual costs and actual benefits.
You save ₹450
- Full-length timed mocks
- Module-wise practice
- Emerging-tech coverage
One payment, no subscription · Valid for 2 months
PIR, UAT and Post-Release Review
User acceptance testing
When
Before go-live
Question it answers
Does the system meet documented requirements, so users can sign it off?
Auditor's pre-implementation opinion
When
After testing, before go-live
Question it answers
Does the system meet requirements and include appropriate controls, and can it move to production?
Post-release review
When
After a change is released
Question it answers
Did this change work as intended? (the review step of change management)
Post-implementation review
When
After the new system has stabilised
Question it answers
Were objectives and benefits achieved, and are controls operating in live use?
| Review | When | Question it answers |
|---|---|---|
| User acceptance testing | Before go-live | Does the system meet documented requirements, so users can sign it off? |
| Auditor's pre-implementation opinion | After testing, before go-live | Does the system meet requirements and include appropriate controls, and can it move to production? |
| Post-release review | After a change is released | Did this change work as intended? (the review step of change management) |
| Post-implementation review | After the new system has stabilised | Were objectives and benefits achieved, and are controls operating in live use? |
Timing
Module 3 says enough time should pass for the system to stabilise in the live environment before the review, so that significant problems have had a chance to surface. ICAI sets no fixed period. Letting at least one period-end close run on the new system is a sensible test, since cyclical processes like year-end and quarter-end are where errors appear.
What the IS Auditor Checks
Paraphrased from the auditor's role in maintenance and post-implementation in ICAI's Module 3:
- checkWhether the system's objectives and requirements were achieved
- checkWhether the costs and benefits from the feasibility study are being measured
- checkWhether required controls were built in and are operating as designed
- checkError logs, for resource or operating problems that point to poor planning or testing
- checkInput and output control balances and reports, to confirm complete and correct processing
- checkThe procedures for authorising, prioritising and tracking changes, and a sample of changes since go-live
- checkProgram change documentation retained as an audit trail
- checkAccess restrictions over production source and executable code
- checkProcedures for emergency changes and controls over emergency logon IDs
Quick practice on audit concepts. No signup.
Benefit Realisation
A PIR tests the business case, so the indicators must follow from what the system was meant to do. If a bank built a new loan origination system to cut turnaround time and reduce documentation errors, the measures are turnaround time and documentation exceptions before and after, not general IT metrics.
Module 3's own chapter-end question makes the point: for an in-house application, a fall in virus attacks is not a benefit of that application, because it is a benefit of anti-virus software. More customers, fewer regulatory audit findings and higher productivity can be.
Independence
An auditor who sat on the project team can still do the PIR only if they did not design, select or implement the controls under review. ICAI's own answer treats building an integrated test facility differently, since it is an audit tool, not a control. If the internal audit team signed off the access matrix, the PIR on access controls should go to someone else.
How the DISA Assessment Test Tests This
- check_circlePurpose of a PIR: whether objectives and benefits were achieved; the trap answer is "to find bugs", which is testing
- check_circleTiming: after stabilisation, not immediately after go-live
- check_circleIndependence: which prior project role still lets the auditor review
- check_circleBenefit indicators: pick the one that follows from the system's purpose
FAQs
What is a post-implementation review in IS audit?expand_more
A review after a new system has stabilised in live use, checking whether it met its objectives and expected benefits and whether its controls operate as designed.
When should a post-implementation review be done?expand_more
Once the system has stabilised. ICAI's material gives no fixed period, only that enough time should pass for significant problems to surface.
What is the difference between UAT and a post-implementation review?expand_more
UAT is before go-live and decides whether users accept the system. A PIR is after go-live and measures what the system actually delivered and whether controls work in production.
Can an auditor who worked on the project do the PIR?expand_more
Only if they did not design, select or implement the controls being reviewed. Otherwise they would be auditing their own work.
Next steps
Take a full DISA mock testAssessment Test format, timed and scored.