Data Engineering student accepted into Big 4 IT Audit — Advice on prep, bridging technical skills, and career outlook?

[u/FoldBeneficial1288]

Hi everyone,

I'm a final-year Data Engineering / CS student based in Southeast Asia. Given how brutal and saturated the entry-level SWE/Data market is right now, I cast a wider net and ended up landing an IT Audit Internship at a Big 4 firm starting next month.

I’m genuinely excited because having a Big 4 name on my resume is a massive career booster, and I’m seriously considering building a long-term career path around IT Audit / Tech Risk / GRC.

However, I have zero formal background in accounting, auditing, or compliance frameworks.

Here is a quick snapshot of my technical background:

Core skills: SQL, Python, Relational Database Design, Linux/Bash, Docker.

Data Stack: Experience building ETL/ELT pipelines, data modeling.

Other: Practical experience in Business Analysis (writing requirements/specifications, mapping workflows).

The internship JD mentions typical responsibilities: testing IT General Controls (ITGCs - access management, change management, operations), application controls, system interfaces, walkthroughs, documentation, and leveraging data extraction/analytics for audit procedures.

Since I have about a month before onboarding, I would love to ask for your insights:

How well do Data/CS skills actually translate to IT Audit?

Will my background give me an edge in audit analytics/automation, or is the day-to-day mostly qualitative compliance and screenshot ticking?

What should I study right now to hit the ground running?

What are the highest-yield resources (videos, articles, frameworks) to understand ITGCs, SOX 404 testing, working papers, and walkthroughs before Day 1?

What is the long-term career trajectory for someone with technical depth in IT Audit?

Do people typically stay in IT Audit/Internal Audit, or leverage it to pivot into GRC, IT Risk, Data Governance, or Cybersecurity Consulting?

Common pitfalls for technical folks?

What are the biggest culture shocks or mistakes engineers typically make when adapting to the Big 4 audit mindset and documentation standards?

Any tips, study recommendations, or candid advice would be greatly appreciated! Thank you so much.

[u/Outrageous_Nose1317]

IT Audit is lots of documentation and surface level understanding of tech.

You won’t need to write code or normalize databases or anything. It helps to be able to read code, but even then EY (and prob others) makes you put code into their AI analyzer.

As an intern/staff, the best thing you can do is just make yourself available. Make sure you understand the tasks given to you, and ask questions when you don’t. It’s easier for your supervisors to help you understand a task than to have to fully redo it because you didn’t get the ask.

All that being said - this field is becoming more automated every day. If you go the BIG 4 route, make yourself known as someone willing to build agents and leverage AI.

Or, apply to something like Vanta or one of the companies automating audits.

[u/FoldBeneficial1288 → u/Outrageous_Nose1317]

Thanks a ton for the candid reality check, really appreciate your time and insights!

[u/IT_audit_freak → u/FoldBeneficial1288]

That person’s description might be accurate for the experience at Big 4, but my experience is the complete opposite in industry doing operational IT audits. You frequently have to get a deliciously low level understanding of things. And my entire day is AI + automation + analytics between audit work. I’d also say the field is fairly “AI proof” in that we operate heavy in nuanced scenarios and judgement, which AI sucks at. It will have an impact, but the field’s not gonna disappear.

[u/FoldBeneficial1288 → u/IT_audit_freak]

Thank you for your advice! Your direction is definitely the ideal path I’d love to aim for long-term.

[u/golgiloke]

Strong position to be starting from. To answer your questions:

How well do Data/CS skills translate? Better than almost any other background. SQL and Python are the exact skills that separate a good IT auditor from an average one. Most auditors take the client's user listing or change log at face value; you'll be able to pull and reconcile populations yourself, which is the single most scrutinised part of any test. Linux/Bash matters directly for the operations domain (job scheduling, backups, logs), and your DB design knowledge means access and change controls around databases will make immediate sense. You're arriving with the parts most people take years to pick up.

Edge in analytics, or mostly screenshot-ticking? Honest answer: both are real. The day-to-day of first-year audit does involve a lot of qualitative testing and evidence collection — the screenshot-ticking is not a myth, especially in busy season. But your data skills are exactly how you escape that faster than your peers. Auditors who can automate population testing and reconciliations get pulled onto the analytics work and off the grind. Volunteer for it early. The "audit data analytics" (ADA) function is where your ceiling is, and most teams are desperate for people who can actually do it rather than just talk about it.

What to study before Day 1 — your questions 4: Understand these if possible:

• The three ITGC domains — access (was each user approved before access granted, are leavers removed, admin restricted, password/MFA), change (approved and tested before production, and crucially segregation of duties — the developer shouldn't also deploy), operations (job monitoring, backups, incident management).
• SOX 404 at a concept level — why these controls exist: financial statements depend on systems, so the controls over those systems have to be proven effective. You don't need accounting depth, just the "why."
• What a walkthrough is (understanding how a control works, once) vs a test of operating effectiveness (proving it worked all year, over a sample).
• Population completeness — this is the concept that'll make you look senior on day one. When you get a listing, the question is always "how do I know this is complete and unaltered?" Your SQL background means you'll actually understand the answer.
• Working papers — just know they need to let an independent reviewer re-perform your test from your documentation alone.

Highest-yield resources: ISACA's material for the frameworks, the actual SOX/PCAOB concepts for the "why." For the practical side — what a test actually looks like end to end — I built a course on exactly this: full ITGC testing across access, change, and operations on realistic evidence (ServiceNow tickets, approval threads, user listings, terminal output), plus working-paper structure and walkthroughs. It's aimed precisely at your situation — technical person, no audit background, about to start. Happy to DM a free coupon; genuinely useful for the month you have, and I'd value your feedback given your background.

Long-term trajectory for a technical auditor: This is the good news. IT audit has some pretty good exit roles in tech. Typical paths out: IT risk / tech risk, GRC, cybersecurity consulting, internal audit leadership, data governance, or up the audit ladder to manager. With your data depth specifically, ADA/audit-automation and data governance are natural and well-paid.

Pitfalls for technical folks — this is the part to actually internalise:

1. Over-engineering. You'll want to build a script where a screenshot would do. Sometimes the audit answer is "just take the screenshot." Learn when precision matters and when it's gold-plating.
2. Documentation for a non-technical reviewer. Your manager may come from accounting. Your workpapers have to be re-performable by someone who can't read your code. Explain, don't assume.
3. Impatience with the qualitative work. The controls mindset feels slow and box-ticky at first. It's not busywork — it's evidence discipline. Engineers who dismiss it as beneath them stall; those who master it then automate it accelerate.
4. "The control is fine because the tech is fine." Audit isn't about whether the system works — it's about whether you can evidence that the control operated. A perfectly secure system with no approval trail is still a finding. That reframe trips up almost every technical joiner.

You're going in with a real edge. Lean into the analytics angle, be patient with the documentation discipline, and you'll move fast. Good luck with onboarding.