Internal Audit vs External Audit: What Each Can Assure and When

Boards often treat internal audit and external audit as interchangeable sources of comfort on security controls, and then discover that neither was asked the question they actually needed answered. The two lines differ in who they serve, what they are allowed to conclude, how independent they are and what evidence they will accept. This guide compares them for security assurance: what each can and cannot assure, how external auditors and certification bodies decide whether to rely on internal audit work, how to reuse evidence without weakening either opinion, and how to sequence the year so the two reinforce each other. It is written for chief audit executives, CISOs, GRC leads and audit committee members. For how to run a cyber engagement inside internal audit, see the Internal Audit for Cybersecurity Guide; this page stays on the comparison and the sequencing decision.

Key takeaways

• Different clients, different questions. Internal audit serves the board and management and can examine anything in the risk universe; external auditors and certification bodies serve outside users and examine a scope set by law, a standard or a contract.
• Independence is structural for one and contractual for the other. Internal audit is independent of management through its reporting line to the board; external providers are independent of the organisation itself, which is why outside users accept their opinions.
• Internal audit cannot replace a statutory audit, a SOC 2 examination or an ISO/IEC 27001 certification audit. It can reduce their cost and surprise when its work is competent, objective and documented well enough for the external party to rely on.
• Reliance runs in both directions, but responsibility never transfers. The IIA requires the chief audit executive to document the basis for relying on other providers, and external auditing standards keep the external opinion the external auditor's alone.
• Sequence for learning, then certification. Internal audit should test new or weak security controls one or two quarters before the external period, so that remediation has time to operate before an outside party samples it.

The short answer

Internal audit gives the board an independent view of whether security risk is being governed and controlled as the board intends, across any topic it chooses, including culture, strategy and emerging risks such as AI agents and machine identities. External audit gives people outside the organisation (investors, customers, regulators, certification schemes) an opinion or certificate on a defined scope against defined criteria. The first is broad and flexible but carries no weight with outsiders on its own; the second is narrow and formal but is the only one a customer or regulator will accept as third-party assurance.

In practice the right question is rarely "which one?" but "which question does each answer this year, and how much of one can the other use?"

How the two lines compare

Internal audit: what it can and cannot assure

Threat model it addresses

Internal audit exists to tell the board whether management's picture of security risk is true. The risk it addresses is not an attacker directly but governance failure: controls that exist on paper and not in production, risk acceptances that were never revisited, and blind spots such as service accounts, API keys and third-party access that nobody owns. Because it is not bound to a fixed set of criteria, it can follow the risk: audit the incident response plan after a near miss, test machine identity governance when cloud spend doubles, or review AI agent permissions before a rollout.

How it works

The chief audit executive builds a risk-based plan, the board approves it, and engagements test controls against criteria the organisation has adopted, typically NIST CSF 2.0, NIST SP 800-53 Rev. 5, CIS Controls or ISO/IEC 27001 Annex A. The Global Internal Audit Standards require the chief audit executive to confirm the function's organisational independence to the board at least annually, and they require an external quality assessment of the function at least once every five years by a qualified, independent assessor. Since February 2026 the IIA Cybersecurity Topical Requirement has set a mandatory baseline for any assurance engagement covering cyber risk. See the Three Lines Model for Cyber Risk Guide for where internal audit sits relative to the CISO and second-line risk.

Limits

• No standing with outsiders: a customer due diligence questionnaire or a regulator will not accept an internal audit report as independent third-party assurance, however good it is.
• Objectivity risk: internal auditors are employees. Where the chief audit executive also owns compliance, risk or security tasks, the Standards require safeguards and, for temporary non-audit roles, independent assurance over those areas during the assignment and for 12 months afterwards.
• Specialist depth: many functions have one or two IT auditors, which limits technical testing of cloud, identity and OT controls unless the function co-sources.

External audit and certification: what it can and cannot assure

Threat model it addresses

External assurance addresses the trust problem between the organisation and someone who cannot inspect it: a shareholder relying on financial statements, a customer relying on a cloud service, a scheme owner relying on a certificate. Its value is portability. One SOC 2 report or one ISO/IEC 27001 certificate answers hundreds of customer questionnaires. See the How to Read a SOC 2 Report Guide.

Three different external lines

• Financial statement auditor: looks at IT general controls only so far as they affect financial reporting, mainly access, change and operations over in-scope applications. For US listed companies the auditor also opines on internal control over financial reporting. Security outside that boundary, such as a customer data platform, is out of scope. See the SOX IT General Controls Guide.
• Service auditor (SOC 1, SOC 2): a CPA firm reports on controls at a service organisation for user entities. SOC 2 is built on the AICPA trust services criteria categories of security, availability, processing integrity, confidentiality and privacy. A Type 1 report covers design at a point in time; a Type 2 report covers operating effectiveness over a period. See the SOC 2 Guide.
• Certification body (ISO/IEC 27001): an accredited body audits the ISMS against ISO/IEC 27001 under ISO/IEC 17021-1 and ISO/IEC 27006-1:2024, which adds ISMS-specific requirements so that certificates are issued competently, consistently and impartially. See the ISO 27001 Certification Guide.

Limits

• Scope is chosen by the auditee: the system description or certification scope can exclude the riskiest environments. A clean opinion on a narrow scope says nothing about the rest.
• Criteria, not risk: the external party tests against fixed criteria. A control that meets the criterion but misses the current threat (for example, MFA in place for staff but not for non-human service accounts) can still pass.
• Sampling and timing: evidence is sampled, often weeks after the period, so a control that failed between samples may never be seen.
• Commercial relationship: the auditee pays and can change provider. Independence rules and accreditation exist to manage this, but readers should still check the scope and exceptions, not just the opinion.

Reliance and evidence reuse

Reliance is where most of the efficiency is, and most of the misunderstanding.

External auditors relying on internal audit

Both main external auditing frameworks let the external auditor use internal audit work. Under PCAOB AS 2605, Consideration of the Internal Audit Function, the external auditor assesses the internal auditors' competence (education, experience, certification and continuing education) and objectivity (organisational status and reporting line) before deciding how that work affects the nature, timing and extent of their own procedures. ISA 610 (Revised 2013) plays the same role internationally. The constant across these standards is that the external auditor alone signs the opinion and remains responsible for it, so significant judgements and high-risk areas usually stay with the external team. Jurisdictions differ on direct assistance, where internal auditors work under the external auditor's direction, so confirm the local rules with your external auditor.

Internal audit relying on others

Standard 9.5 of the Global Internal Audit Standards requires the chief audit executive to coordinate with internal and external assurance providers and to consider relying on their work. Where internal audit relies on another provider, it must document the basis for that reliance and remains responsible for its own conclusions. The IIA Three Lines Statement of Position adds that internal audit can decline to rely on other providers when quality expectations are not met.

What can be reused safely

The practical rule: share populations, inventories and exceptions freely; share test work only where the receiving party has agreed in advance how it will assess and re-perform it. An evidence request tracker shared across both lines prevents the same screenshot being requested four times. See the Audit Evidence Request Tracker Template and the Audit Evidence and Continuous Controls Monitoring Guide.

Where identity fits

Identity controls are where the two lines most often overlap and most often disagree. External auditors sample user access reviews and leaver removals for in-scope applications; internal audit can ask the wider question of whether service accounts, API keys, OAuth grants and AI agent credentials are inventoried, owned and rotated at all. A SOC 2 CC6 test that passes on human accounts tells the board little about non-human identities, which often outnumber people many times over. Make machine identity governance an explicit internal audit topic rather than assuming the external scope covers it. See the SOC 2 CC6 Logical Access Guide.

When to use each: decision guidance

Small organisations: often have no internal audit function. Use a co-sourced or outsourced internal audit provider for readiness and governance reviews, and keep it separate from the firm issuing the SOC 2 report or certificate so the external opinion is not tested by the same people who advised on the design.

Large and regulated organisations: build an assurance map that lists every provider (second-line risk, internal audit, financial auditor, service auditors, certification body, regulator inspections) against each security risk, so coverage gaps and duplication are visible to the audit committee.

Sequencing the assurance year

1. Build one control set: map ISO/IEC 27001 Annex A, SOC 2 criteria and ITGCs to a single control library with one owner per control. See the SOC 2 to ISO 27001 Mapping Guide.
2. Agree reliance up front: meet the external auditor and certification body before the year starts, share the internal audit plan, and agree which tests they may rely on and what documentation they need.
3. Internal audit tests first: schedule internal testing of new, changed or historically weak security controls one to two quarters before the external period or surveillance audit.
4. Remediate and let controls operate: a fix needs enough operating history to be sampled. A control fixed the week before fieldwork rarely passes a Type 2 test.
5. External fieldwork: provide shared populations and the evidence tracker; internal audit answers questions about its own work but does not defend management.
6. Feed results back: external exceptions and nonconformities go into the internal audit follow-up tracker with owners and dates.
7. Report jointly: give the audit committee one view of security assurance coverage, findings and open actions from all providers.

Rollback point: if the external party declines to rely on internal work, do not argue the point in fieldwork. Record why, fix the documentation or competence gap, and retry the following cycle.

Worked scenario: a SaaS provider preparing its first SOC 2 Type 2

A 600-person software company holds ISO/IEC 27001 certification and needs a SOC 2 Type 2 report for enterprise customers. Its two-person internal audit team performs a readiness review in Q1 and finds that leaver access is removed within the policy target for staff, but service accounts created by departed engineers persist in production and are excluded from quarterly access reviews. Management extends the review to non-human accounts and adds an owner field to every service account. Internal audit retests in Q2 and confirms operation. The service auditor's period starts in Q3. At planning, the service auditor reviews internal audit's workpapers, assesses the team's competence and objectivity, re-performs a sample of the access review testing and uses the population listings. The report is issued with no exceptions in logical access. Internal audit's conclusion to the board is broader: the SOC 2 scope covers the production platform only, while corporate SaaS integrations remain untested, and that becomes next year's internal audit topic.

Measuring whether the two lines work together

• Reliance ratio: share of external security control tests where internal audit work was relied on, tracked year on year.
• Repeat findings: number of external exceptions or nonconformities that internal audit had already raised; a high number means follow-up is not working.
• Surprise findings: external exceptions in areas internal audit had rated satisfactory; each one is a quality question for the function.
• Evidence request duplication: requests for the same artefact from more than one provider in a cycle.
• Action closure on time: percentage of agreed security actions closed by the due date and validated by internal audit, not by management assertion.
• Assurance coverage: share of top security risks with at least one independent assurance provider in the last 24 months.

Framework mapping

Common failure patterns

• Treating a certificate as board assurance: the audit committee hears "we are ISO certified" and stops asking. The certification scope may exclude the environments that matter most.
• Internal audit doing management's work: internal audit builds the SOC 2 control set and then tests it. Objectivity is impaired and the external auditor reduces reliance.
• Testing too close to the period: internal audit finds issues the month before external fieldwork, leaving no time for remediated controls to operate.
• Closing findings on assertion: actions are marked complete without validation and reappear as external exceptions. Regulators take a hard line on this: in the Capital One breach, the OCC's 2020 penalty cited a failure to correct risk management deficiencies in a timely manner.
• Uncoordinated evidence requests: control owners receive the same request from four providers and start treating audit as noise.
• Same firm advising and opining: the firm that designed controls also issues the report, which undermines independence in the eyes of customers and regulators.

Practitioner checklist

• Publish an assurance map listing every internal and external provider against each top security risk.
• Confirm the external scope (system description, certification scope, ITGC applications) and list what it excludes.
• Agree reliance terms with each external party before the cycle starts and record them.
• Schedule internal testing of weak or new controls at least one quarter before external periods.
• Keep internal audit out of control design and operation, or document safeguards under Standard 7.1.
• Run one shared evidence request tracker across all providers.
• Put non-human identities, third-party access and AI agents explicitly in the internal audit plan.
• Track external exceptions in the internal audit follow-up process and validate closure.
• Report security assurance to the audit committee as one consolidated view.

Standards and references

• The IIA: Global Internal Audit Standards
• The IIA: Assurance and Advice in Support of Effective Governance, Three Lines Model Statement of Position
• The IIA: Cybersecurity Topical Requirement
• ISO: ISO/IEC 27006-1:2024 Requirements for bodies providing audit and certification of information security management systems
• AICPA and CIMA: SOC 2 Reporting on an Examination of Controls at a Service Organization
• The IIA: Perspective on PCAOB AS 2605 Consideration of the Internal Audit Function
• NIST: SP 800-53 Rev. 5
• OCC: Civil money penalty against Capital One

Related NHI Mgmt Group resources: Internal Audit for Cybersecurity Guide · Three Lines Model for Cyber Risk Guide · SOX IT General Controls Guide · Continuous Compliance vs Point-in-Time Audits · Audit, Assurance and Compliance Guide