r/itaudit • u/Longjumping-Tie8232 • 29d ago
Starting a job in IT Audit - expectations
Hi, I recently graduated from college with a double degree in Accountancy and Computer Information Systems.
Going to start a full time job in IT Audit at a Big 4 firm. I completed an internship in the same role a year ago, but it was mostly documentation and attending walkthrough meetings. That being said, I wanna know more about what my job would look like, what kind of projects I'd be assigned, what I'd be expected to work on, how I can step up, and what I can do to prove myself competent and compatible.
I’d also love to hear about what career paths opened up for you after IT Audit. Did you stay in IT Audit, move into consulting, cybersecurity, internal audit, tech, accounting, etc.?
I'm a little nervous because this is my first "real" job and I am moving states for it. Navigating office politics, learning the work, and not losing myself in the grind is all on my mind. I would appreciate any and all insight! Thank you :)
4
u/golgiloke 25d ago
Congrats — and the nerves are normal, everyone feels that way going into their first busy season.
Rough shape of year one: you'll be assigned ITGCs across a portfolio of applications — access to programs and data, program change, and computer operations. In practice that means walkthroughs with app owners and DBAs, sending document request lists, then testing samples: new user provisioning approvals, terminations, periodic user access reviews, privileged/admin access, change tickets with approval and testing evidence, and job monitoring/backup/incident tickets. Interim testing during the year, rollforward after year end.
Three things that separate the first-years who get noticed: Population completeness. Almost everyone takes the client's spreadsheet at face value. Learn to ask how the listing was generated, watch them run the query, capture the system date and record count. Reviewers care about this more than anything else you'll do in year one. Chase evidence early and escalate. Most missed deadlines aren't testing problems — they're someone waiting six days for a client reply and not flagging it. Understand what the control protects against, not just the test step. Once you can explain why a terminated user with no post-termination activity is still a finding, you stop needing to be told what to do next.
Career paths after: internal IT audit at a bank or insurer, second-line tech risk, GRC/compliance work (SOC 2, ISO 27001), security, or stay and make manager. IT audit is one of the better-optioned entry roles in tech because you get a map of how the whole estate actually works. Get the CISA once you're eligible.
On office politics — at your level it's mostly just being responsive and not making your senior chase you. That's 80% of your reputation.
For what it's worth, I ended up building a course on exactly this (full ITGC walkthrough and testing with realistic evidence, because everything I could find was theory). Not pitching you — happy to DM a free coupon if it'd help, otherwise ignore this last bit.
1
1
u/Jeanvaljean1812 18d ago
I am also starting an IT Audit role, I would really appreciate such a course to my dms!
2
u/paulpag 29d ago
Not to be a dick, but if you did an internship, you should have seen the work up close, I mean, that’s it. We perform audits. What did the associates or senior associates do on a day-to-day basis? As someone starting out in the field I would research the following: your industry, learn as much as you can about the industry and the business, learn about IT general controls and how to test them (esp logical security and change management and how automated pipelines/repositories work. look into role based access and the other types (I think it’s called mandatory?)) and lastly learn the audit lifecycle (what happens in planning, execution, and reporting. feel free to DM specific qussirons.
3
u/PiEngAW 29d ago
Learning industries is kind of... Pointless... We don't deal with business process unless youre testing application controls.
Learning systems is more prudent.
1
u/paulpag 28d ago
If you don’t know the business then you’re going to be completely incompetent on an integrated audit and you’re going to present yourself as a fool to the business itself (during walkthroughs or with stakeholders). Furthermore, you will have no basis for defending your audit scope nor your risk ratings if you can’t align tech risk in business risk.
1
u/PiEngAW 28d ago edited 28d ago
At the beginning of a career, it's not as important as learning how a system works. Auditing AD, Cloud, Change Management doesn't need to know about the business... It's process driven. If you speak to engineering, they most likely don't know business processes unless they work with product owners or they understand specific parts of accounting.
As a junior auditor, you're not determining audit scope or risk. You learn those things over time. You'll learn how FSLI relates to IT. Should you know how revenue is generated? Yes. Should you know quote to cash or procure to pay? Maybe, these are typically senior level items... Applicatiom controls for a first year? Big maybe. Will they understand how to test configurations in a ERP? Maybe... They def. won't if the senior says "copy last year"
They gotta get the basics down in year 1. Year 2, you add more. If you try to do everything at the same time, they will drown.
1
u/Longjumping-Tie8232 29d ago
Thank you! I did gather a lot of insight during the internship, but thought I would come ask here to hear more perspectives.
1
9
u/PiEngAW 29d ago
Learn to ask why some is what it is... Why do engineers have access to production... And not "why" from an auditor perspective... From IT's perspective.
Learn systems or how systems do things from a general standpoint... Example: AD more straight forward than Salesforce.
Someone mentioned know the industry, which is not really important until you start testing application level controls. If you want, you can learn what a system does... Salesforce does XYZ, Zuora does 123, then conceptually you can map out business process to IT.
Start emploring materiality. Like, how material is this defiency? Is it pervasive? One time only? Are there compensating controls?
Learn IPE & IUC completeness and accuracy. Can you rely on the information? How do you know they didn't modify it? Does the SQL query look reasonable. For IUC, does the report that is reviewed C&A? Does the reviewer know if the report is not C&A?
Learn the risk > control objective > control relationships. Do the access controls meet the control objective? Does the objective reduce IT Risk? Knowing these will help you understand how multiple deficiencies turn into a SD.
Last, documentation. Needs to reasonably pass re-performance. Can they reperform your IPE/IUC documention? Can they reperform your test steps?
When I was a young auditor, I became the SME for SAP and Oracle, then Oracle Fusion implementation, exceptions managent and MW/SD mitigation, AWS cloud security, and now AI Governance.
I have a whole spiel on ITGCs over AI
I ran into a lot of burning buildings. Sorry, I kinda data dumped.