5 Step Risk Based IT Audit Process for Engineering and Finance Firms

An IT audit is an independent, risk-based evaluation of an organization’s IT systems, governance, and controls, built to confirm that assets are protected, data stays accurate and available, and technology genuinely supports business goals. For financial services firms and engineering practices in particular, that verdict carries regulatory weight, not just operational tidiness. Auditors measure this against recognized standards like ITAF and ISSAI 5300, not gut feeling.

---

TL;DR:

• IT audits should prioritize systems critical to business operations and compliance, especially those handling sensitive or regulated data.
• Evidence collection must include system logs, configurations, and interviews, with continuous monitoring logs increasingly replacing point-in-time snapshots.
• Auditors test both general controls like access management and backup procedures, and application controls within specific systems, using tools like penetration testing.
• The success of an audit depends on clear documentation, stakeholder engagement, and follow-up on remediation, with re-testing of controls to verify fixes.
• Outsourced IT and cloud environments are part of the control environment and require documented reliance and testing beyond provider attestations.

---

Why an IT audit matters to your business, not just your IT department

An IT audit exists to answer three questions: are the organization’s digital assets safeguarded, is its data trustworthy and accessible when needed, and does the technology stack actually move the business forward. Those three objectives, drawn from the ITAF definition ISACA maintains, apply whether you run a five-partner engineering consultancy or a mid-sized asset management firm.

IT audits rarely stand alone anymore. They increasingly get folded into broader financial or operational audits, especially where financial reporting depends on system-generated data, which is most of the time now. That’s the logic behind an integrated audit approach.

What this looks like in practice:

• Financial controls testing that pulls in IT general controls because the numbers originate in a system, not a ledger
• Compliance reviews that check technology against a specific regulatory obligation
• Standalone technical assessments focused purely on infrastructure health

ISSAI 5300 frames the whole exercise as risk-based rather than exhaustive. You don’t audit everything equally; you audit where failure would hurt most.

Choosing the right type of IT audit for your risk profile

Not every engagement needs the same scope. A compliance audit checks adherence to a specific framework or regulation. A controls audit tests whether safeguards around access, change, and data actually function as designed. A performance audit looks at whether systems deliver value efficiently, not just safely. A forensic audit investigates after something has already gone wrong, usually fraud or a breach. An integrated audit blends IT testing into a wider financial or operational review.

Scoping decisions come down to a handful of practical factors:

• Which systems, if compromised, would stop the business from operating or reporting accurately
• Whether third parties or cloud providers hold a meaningful share of your control environment
• How sensitive the data is, and who regulates it
• The time and staff available to execute the audit properly

ISACA’s guidance is explicit that this practice scales down as well as up. A 30-person engineering firm doesn’t need the audit machinery of a national bank. It needs a scope matched to its actual exposure, which usually means prioritizing whatever system handles client funds, project data, or regulated records.

How to conduct an IT audit: a practical process

Every credible information technology audit process follows a similar arc, whether it’s run internally or by an external firm. The details shift by industry, but the sequence doesn’t.

1. Scope by risk. Identify the systems and processes where a control failure would cause the most damage, financially, operationally, or reputationally. This is the ISSAI 5300 starting point.
2. Plan the engagement. Define objectives, name stakeholders, agree on timelines, and list the evidence you’ll need before fieldwork starts.
3. Collect evidence. Pull system logs, configuration exports, access lists, and change records. Conduct interviews with system owners and IT staff to understand how controls operate day to day.
4. Test controls. Run compliance testing to confirm a control exists and operates as documented, then substantive testing to confirm the underlying data or transaction is actually correct.
5. Report findings. Document what was tested, what evidence supported each conclusion, and what needs remediation, in language a non-technical executive can act on.

Computer-assisted audit techniques, or CAATs, come into play heavily at the evidence stage when you’re dealing with large transaction volumes or system-generated data. The WGITA/IDI handbook on IT audit recommends them specifically wherever manual sampling would miss too much.

Pro Tip: Build your evidence file so that a second auditor, with no prior context, could reach the same conclusion from the same documents. That reproducibility standard, drawn from ISSAI guidance, is what separates a defensible audit from a rushed one.

The controls auditors actually test, and how they test them

Auditors split IT controls into two buckets. General IT controls (GITCs) cover the environment as a whole, things like access management, change management, backup processes, and network security. Application controls sit inside a specific system, checking that data entered into, say, an accounting platform or engineering design tool is complete, accurate, and authorized.

Typical tests include: run specialized penetration testing and vulnerability assessments as part of thorough controls evaluation, drawing on expert technical security services and penetration testing to identify weaknesses.

• Reviewing access logs to confirm terminated employees lost system rights promptly
• Sampling change tickets to verify nothing went to production without approval
• Confirming backups actually restore, not just that they run
• Scanning network configurations for open ports or unpatched vulnerabilities

Continuous monitoring has changed what counts as acceptable evidence. Instead of a point-in-time screenshot, auditors increasingly expect control telemetry and system logs collected over the audit period, particularly in cloud environments where configurations shift constantly. A firm using Microsoft 365 or Azure should expect auditors to ask for activity logs, not a one-time export. Reported salary data for IT auditors reflects how specialized this skill set has become, a point covered more in the next section.

Who runs IT audits, and what skills the job demands

Internal audit teams handle recurring, lower-risk reviews. External firms typically come in for regulatory attestations, forensic work, or when independence rules require it. Larger financial services firms often run both in parallel.

The skill mix matters more than the org chart:

• Technical grounding in networks, cloud platforms, identity and access management, and log analysis
• The soft skill of translating a technical gap into a business risk statement an executive will actually act on
• Interview technique, since a lot of evidence comes from asking system owners the right follow-up question

ISACA’s IT Audit Fundamentals certificate is the standard entry point, covering the audit function, controls and risk, and the IT environment before candidates move toward CISA. In South Africa, reported mid-range monthly salaries for IT auditors commonly fall between R38,000 and R72,000, depending on experience and sector, notably higher than the national average, which tells you how much premium the market places on this combination of skills.

Best practices that separate a useful audit from a checkbox exercise

Auditors who prioritize by technical visibility instead of business risk waste time testing the systems that are easiest to access rather than the ones that matter most. Fix that ordering first.

1. Rank systems by business impact before you rank them by how easy they are to test.
2. Bring stakeholders in during planning, not after the report lands as a surprise.
3. Translate every finding into a business consequence: revenue at risk, compliance exposure, client trust.
4. Document evidence trails that another reviewer could follow without asking you questions.
5. Watch third-party and cloud control environments closely. Outsourced services are still part of your control surface, and provider attestations only go so far.

Common red flags worth flagging immediately: manual controls that haven’t been reviewed in years, access rights that outlive the employee, and backup routines nobody has actually tested with a real restore.

Pro Tip: If a control depends on one person remembering to do something manually, treat it as a finding even if nothing has gone wrong yet. Manual, undocumented controls are where audits go to die a slow death two years later.

A well-structured IT security audit checklist helps keep this consistent across audit cycles rather than reinventing scope every time.

What happens after the audit report lands

The report is the midpoint, not the finish line. Every finding needs an owner, a remediation deadline, and a documented management response, whether that response is “we agree, here’s our plan” or “we accept this risk, here’s why.” Skipping the formal response step is one of the more common ways audits lose credibility internally; findings that never get a documented answer tend to reappear, unresolved, in the next cycle.

Remediation tracking works best as a living register, not a one-time action item list buried in the final report. Each item should carry a status, a responsible person, and a target date, reviewed on a set cadence, monthly for high-risk items, quarterly for lower-priority ones. For financial services firms under regulatory scrutiny, that register often becomes evidence in itself, proof that governance is functioning even when individual controls occasionally fail.

Re-testing matters too. A control marked “remediated” without follow-up verification is just an assumption wearing a checkmark. Build a short re-test into the following audit cycle, or sooner for anything flagged as high risk.

Finally, feed findings back into planning. If the same control category keeps failing across audit cycles, that’s a signal the underlying process, not just the control, needs redesign. A risk assessment checklist built for your next planning cycle can help make sure recurring gaps actually get addressed instead of re-flagged year after year.

How managed IT support changes the audit conversation

Most of the friction in an IT audit comes from missing documentation, not missing controls. Some managed IT service providers work with engineering and financial services firms specifically because their audit exposure is high and their internal IT bandwidth usually isn’t.

Proactive monitoring, centralized logging, and structured backup and disaster recovery planning generate exactly the evidence trail auditors ask for, continuously, rather than scrambled together the week before fieldwork. Clear IT documentation practices turn “we think that’s how it works” into a defensible answer. If your organization is heading into an audit cycle without confidence in its documentation, that’s worth fixing before the auditor asks, not after.

A blunt take on why most IT audits underdeliver

The audits that disappoint executives aren’t the ones that find problems. They’re the ones that find problems nobody acts on, because the report never translated technical gaps into terms a CFO or managing partner could weigh against other priorities. That translation step gets skipped constantly, and it’s the single biggest reason remediation stalls.

There’s also a quieter failure mode worth naming: treating the audit as a pass or fail test rather than a measurement of how well controls align with what the business actually needs. A control can be technically present and still be wrong for the risk it’s supposed to cover. ISACA’s own framing backs this up, control effectiveness matters relative to business objectives, not in the abstract.

For engineering and financial services firms specifically, the third-party and cloud blind spot deserves more attention than it usually gets. Outsourced IT, cloud platforms, and vendor-managed systems are part of your control environment whether or not your audit scope acknowledges that. Firms that document provider reliance and test what they can, rather than assuming a vendor’s certification covers everything, come out of audits with fewer surprises.

— Steven

Sources

• ITAF FAQs — ISACA
• ISSAI 5300: Guidelines on IT Audit
• IT Auditor Salary in South Africa (2026) – About South Africa
• IT Audit Fundamentals Certificate — ISACA

FAQ

What does an IT audit do?

It independently evaluates an organization’s IT systems, governance, and controls to confirm that assets are protected, data is accurate and available, and technology supports business objectives, following standards such as ITAF and ISSAI 5300.

How much does an IT auditor earn in South Africa?

Reported mid-range monthly salaries for IT auditors in South Africa commonly fall between R38,000 and R72,000, depending on experience level and sector.

What qualifications do I need to be an IT auditor?

Most practitioners start with ISACA’s IT Audit Fundamentals certificate, which covers the audit function, controls and risk, and the IT environment, then progress toward the CISA designation as experience grows.

How do I become an IT auditor in South Africa?

Build technical grounding in networks, cloud platforms, and access management, complete a recognized entry certificate like IT Audit Fundamentals, and gain hands on experience through an internal audit team or an external audit firm before pursuing CISA.

What’s the difference between general IT controls and application controls?

General IT controls cover the environment as a whole, such as access management and backup processes, while application controls check that data within a specific system is complete, accurate, and properly authorized.