Most Australian SMBs encounter internal audits for the first time as a requirement — ISO 27001 mandates them, SOC 2 expects them, and enterprise customers increasingly ask whether you conduct them. But what does an IT internal audit actually involve? And why does it matter whether you do it yourself or engage someone independent?
This guide covers what IT internal audits cover, how they differ from external certification audits, and what you should expect from the process.
What Is an IT Internal Audit?
An IT internal audit is a structured, independent assessment of your IT controls — evaluating whether they are operating effectively, aligned with your policies, and adequate for the risks your business faces.
Unlike a gap assessment (which tells you what's missing before you build controls) or a penetration test (which tests technical exploitability), an internal audit evaluates whether your controls are actually working as designed.
The key word is independent. An internal audit conducted by the same team that operates the controls is not independent. That's not a technicality — it's the reason ISO 27001 explicitly requires internal auditors to be independent of the areas they audit.
Internal vs External Audit — What's the Difference?
This confuses most first-time clients:
- Internal audit — Conducted by or on behalf of the organisation, before a certification or compliance deadline. The purpose is to find gaps and fix them before an external auditor does.
- External audit (certification audit) — Conducted by an accredited certification body (e.g., for ISO 27001) or a licensed CPA firm (e.g., for SOC 2). Results in a formal certificate or report.
Internal audits prepare you for external audits. They surface the findings while there's still time to remediate — not after the certification auditor has written them into a report. A clean external audit is largely the result of effective internal auditing.
What Does an IT Internal Audit Actually Cover?
The scope varies depending on the framework (ISO 27001, SOC 2, Essential Eight, custom) and your business context. But a comprehensive IT internal audit typically examines these areas:
Access Control
- Are access rights granted based on least privilege?
- Are access reviews conducted regularly?
- Is access revoked promptly when staff leave?
- Is privileged access logged and monitored?
Change Management
- Are changes reviewed and approved before deployment?
- Is there a testing process for changes to production?
- Are emergency changes tracked and reviewed after the fact?
Incident Management
- Is there a documented incident response procedure?
- Are incidents recorded, classified, and reviewed?
- Are lessons learned captured and acted on?
Asset Management
- Is there an accurate inventory of hardware and software assets?
- Are assets classified by sensitivity?
- Is end-of-life hardware and software tracked?
Vulnerability Management
- Are patches applied within defined timeframes?
- Is there a process for scanning and tracking vulnerabilities?
- Are penetration test findings tracked to remediation?
Supplier & Vendor Risk
- Are critical suppliers assessed before onboarding?
- Are supplier security obligations documented in contracts?
- Are high-risk suppliers reviewed periodically?
Business Continuity
- Are backups tested and verified as restorable?
- Is there a documented recovery procedure?
- Has the recovery plan been tested in the past 12 months?
Physical Security
- Are server rooms and sensitive areas access-controlled?
- Is visitor access logged?
- Is clean desk policy enforced?
The auditor doesn't just check whether documentation exists — they test whether controls are operating. Asking to see evidence of the last access review, pulling a sample of change tickets, checking backup restoration logs. Evidence-based testing, not policy review.
What Auditors Look For That Most Teams Miss
The most common gaps we find in internal audits of Australian SMBs aren't missing policies — they're controls that exist on paper but weren't maintained consistently:
- Access reviews that were done once and then never repeated — ISO 27001 and SOC 2 require periodic access reviews. A single review two years ago is not periodic.
- Vendor risk assessments completed at onboarding but never reviewed — A supplier's security posture changes. The assessment needs to reflect current state, not onboarding state.
- Incident logs that record events but not classification or response — An incident register with event descriptions but no severity ratings, response actions, or closure dates is not audit-ready.
- Patching SLAs that exist but aren't measured — "Critical patches within 14 days" is a policy. Evidence that critical patches were actually applied within 14 days is what auditors need.
- Backup restoration that hasn't been tested — Backups are worthless if restoring from them has never been tested. Auditors ask for restoration test records.
The internal audit mindset: An effective internal audit is not a compliance exercise — it's a genuine attempt to find the gaps before someone else does. Treat every finding as a gift. The alternative is discovering it during certification, in a customer security review, or after a breach.
How Often Should IT Internal Audits Run?
Framework requirements and practical guidance:
- ISO 27001: Requires internal audits "at planned intervals" — in practice, most organisations do at least one per year, with the full ISMS audited before each certification or surveillance audit.
- SOC 2: Doesn't mandate internal audits by name, but the pre-audit readiness review serves the same function — and is essential before the observation window closes.
- Essential Eight: Annual maturity assessment serves as a de facto internal audit of ACSC framework compliance.
- General best practice: Annual at minimum. Semi-annual for higher-risk environments or rapidly growing companies where controls and systems change frequently.
Who Should Conduct Your Internal Audit?
Independence is the non-negotiable requirement. That means the auditor cannot audit processes they own, operate, or are responsible for.
For most Australian SMBs, this means engaging an external party to conduct the internal audit — not because internal teams lack the skills, but because independence cannot be self-certified. A developer cannot independently audit their own change management process.
An external internal audit gives you:
- Genuine independence from the controls being tested
- An objective perspective on what's actually operating vs. what's documented
- A defensible audit record that satisfies ISO 27001 clause 9.2 and certification auditor expectations
- Findings that your team actually takes seriously (teams take external findings more seriously than internal self-assessments)
See our IT internal audit service page for how we structure and run internal audits for Australian SMBs.
What Does an Internal Audit Report Look Like?
A good internal audit report contains:
- Scope and objectives — What was audited, against which framework or criteria, and over what period
- Methodology — How the audit was conducted (interviews, document review, evidence sampling, observation)
- Findings — Each finding with a description, evidence reviewed, non-conformity or observation classification, and risk rating
- Corrective action register — Each finding mapped to a required action, responsible owner, and target remediation date
- Management summary — An overall opinion on control effectiveness, suitable for board or executive reporting
The report is not the end of the engagement — it's the start of a remediation process. The corrective action register needs to be tracked to closure, and the auditor should verify that identified issues have been resolved before the next external audit.