Related Posts
Hey fishes, pls help me unlock DMs. Thanks!
USA USA USA
Additional Posts in Audit Bowl
New to Fishbowl?
Download the Fishbowl app to
unlock all discussions on Fishbowl.
unlock all discussions on Fishbowl.
Hey fishes, pls help me unlock DMs. Thanks!
USA USA USA
This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.
Download the Fishbowl app to unlock all discussions on Fishbowl.
Copy and paste embed code on your site
Send download link to your phone
OR
Scan your QR code to download
Fishbowl app on your mobile
Ah the ole EY IPE obsession😏
In all seriousness, it’s probably just documented in a different way than you’re used to. Your IPE templates are very structured and detailed.
You can normally get by just testing one report, but there are ITGC deficiencies (like specific system access issues) that could require you to test each instance you sampled.
Thanks for the reminder about IPE, I was getting annoyed with my industry job there for a minute, but I'm good now 😂 EY can keep its ever changing forms
KPMG has IPE too and it’s frankly exhausting. I would second the above comments and guess that PWC just documents the related control and moves on. Which feels like that’s what you should do, controls exist in layers. Data is produced, data is checked, data is used.
The concept of IPE has created more harm than good for us. The amount of people at our firm who try to needlessly argue that every report is IPE even for a non-ICOFR audit AND when it’s subject to audit procedures is insane. Those people would call the GL IPE if you let them
Only in my dreams.
If I get two more “but PwC never asked for this information” before the end of the week, I’m going off the grid, wish me luck
I dare you
PwC does "key report" testing over any system generated reports used in the execution of the control or used by PwC in their testing. It would be pretty surprising if no one from PwC asked the control owner "how do you get comfort that this system generated report is complete/accurate?"
Where it gets tricky is if the report is used in substantive testing only or as a population for PwC to perform control testing (i.e., report isn’t used by management to perform the control itself). In these cases, we do ask for screenshots of the parameters or query used to generate the report, unless we can prove its a standard report. Regardless, PwC has to get comfort over C&A somehow (tie out to GL, perform full-false accept/reject, tie to another report that’s being tested for C&A, or rely on management’s procedures). However, most controls testing, especially review controls, documenting management’s C&A procedures over “key reports” is required along with what is PwC doing to get comfort over C&A - we’ve been hammered in audit trainings how to document IPE in the last 3-4 years.
When I worked on IT audit I did mostly external audit but also helped out on an internal audit where PwC was the external auditor. They focus way more on the underlying code and completeness and accuracy of the reporting itself from an IT standpoint than EY does. For the EY folks that’s risks 2i and 3, which we do way less around (assuming effective change management).
I’m not surprised that control owners would be saying PwC never asked for this because it felt like a whole different world to me honestly.
What does IPE mean in EY talk and we can address it
That’s correct, because the control owner needs to show they know it’s complete and acccurate. It’s their control, not ours. They should do this by using standard reports or if a custom report tying it back to the TB
We document IPE risks as well in control walkthroughs, but usually it’s not so bad because most IPE comes out of a ERP/AIS that is already tested through GITC procedures. So really it’s not too heavy of a lift because we reference those work papers and maybe agree to the GL if needed.
😂 this thread has me cracking up.
If the IPE is coming from an in scope IT application and the report is tested once during the year, you shouldn’t be doing any other procedures except inspecting that the control operator validated the parameters were appropriate and the information pulled was complete. Should be two attributes in your test plan. Sounds like EY is going overboard on its testing if you cannot check off those two boxes easily.
Sounds like you may need to blow them up.
Are they simple parameters, or is it apparent in the data that the parameters would need to be correct (for example embedded parameters)? If so, there’s probably not much risk that the control isn’t effectively.
You’d still need the parameters to document an ITGC approach to testing C/A.
Deloitte loves the IPE too. We just shipped it off to India to test and took their word for it that it was good.
We don’t call it IPE. We just say completeness and accuracy of reports.
GT has been becoming obsessed with C&A over all IPEs used in each control too. Big pain the the ass.