An ISO 27001 internal audit is your organization’s own evidence-based check that the information security management system (ISMS) conforms to ISO/IEC 27001, conforms to your own ISMS requirements, and is effectively implemented and maintained, in practice, that means more than confirming that policies exist: the auditor should compare requirements, procedures, risks, controls, records, interviews, and operating evidence.
ISO/IEC 27001:2022 Clause 9.2 requires internal audits at planned intervals for this purpose, including an audit programme, criteria and scope for each audit, objective and impartial auditing, reporting to relevant management, and retained documented information on the programme and results, as summarised in Intertek’s ISO/IEC 27001:2022 transition checklist.
Source: Intertek ISO/IEC 27001:2022 transition checklist
What Is An ISO 27001 Internal Audit?
An ISO 27001 internal audit is a first-party audit: it is conducted by, or on behalf of, the organization. It is different from a certification audit, which is a third-party audit performed by an independent certification body. ISO 19011 describes audits as systematic, independent, documented processes for obtaining and objectively evaluating evidence against audit criteria.
Source: ISO 19011 auditing guidelines
The internal audit helps you find gaps before certification, surveillance, recertification, or management review. It should test whether the ISMS is working as described. Not just whether documents are present.
A practical internal audit asks:
- What requirement or internal criterion applies?
- What process or control does the organization say it operates?
- What evidence shows that it happened?
- Does the evidence support conformity, or does it show a gap, inconsistency, or ineffective operation?
What Clause 9.2 Requires In Practical Terms
Clause 9.2 does not require a generic checklist exercise. It requires a managed audit programme that can show the organization is checking its ISMS at planned intervals.
In practical terms, you need to define and retain evidence of:
- Audit programme: what will be audited, when, by whom, and using what methods.
- Frequency: how often audits happen, based on the programme.
- Audit criteria: the requirements used as the benchmark, such as ISO/IEC 27001 clauses, internal policies, procedures, the Statement of Applicability, risk treatment commitments, or contractual ISMS requirements.
- Audit scope: the business areas, systems, locations, processes, clauses, and controls included.
- Auditor objectivity and impartiality: how conflicts are avoided.
- Reporting: how results are reported to relevant management.
- Documented information: records of the audit programme and audit results.
The output does not have to follow one universal report format, but it should be complete enough for someone else to understand what was audited, what evidence was reviewed, what was found, and what action is required, if any.
Who Can Perform The Internal Audit?
The auditor can be an internal employee, an external consultant, or another suitably competent person acting on behalf of the organization. The key requirement is not a specific training certificate; it is that the audit arrangement can demonstrate objectivity and impartiality.
For an internal auditor, the main risk is self-review. Someone who owns the access review process, for example, should not be the only person auditing whether access reviews are operating effectively. In a small organization, complete separation may be difficult, so document the practical safeguards used: peer review, cross-functional audit assignments, external support for high-risk areas, or management approval of the audit arrangement.
Use external help when independence, competence, or capacity is limited. That does not transfer control ownership away from the organization; or rather, process owners still need to explain the ISMS, provide evidence, and complete corrective actions.
How Often Should ISO 27001 Internal Audits Happen?
ISO 27001 requires internal audits at planned intervals, but it does not prescribe one universal frequency. Set the frequency through the audit programme and make it basically defensible.
Consider:
- ISMS scope and complexity
- importance and risk of each process
- recent organizational, system, supplier, or control changes
- previous audit results and open corrective actions
- certification, surveillance, or recertification timing
- evidence volume and maturity of the ISMS
A low-change process with strong recent evidence may not need the same attention as a recently migrated cloud environment, a new supplier model, or a control area with repeated findings. The point is to show that frequency is planned and risk-aware, not arbitrary.
How To Plan An ISO 27001 Internal Audit
Start by defining the audit objective. For example: “Assess whether the ISMS for the in-scope SaaS platform conforms to ISO/IEC 27001:2022, the organization’s ISMS requirements, and selected Statement of Applicability controls, and whether those controls are operating as described.”
Then define:
- Scope: business units, systems, services, locations, processes, and time period.
- Criteria: ISO/IEC 27001 clauses, internal policies, procedures, risk treatment plan, SoA, contractual ISMS requirements, or previous corrective actions.
- Schedule: audit dates, interviews, evidence request deadlines, and reporting date.
- Auditor assignment: who will audit each area and how impartiality is maintained.
- Sampling approach: which records will be reviewed and why the sample is proportionate.
- Evidence request: documents and records needed before interviews begin.
Common evidence sources include, where relevant to the audit scope:
- ISMS scope statement
- Statement of Applicability
- risk assessment and risk treatment plan
- information security policies and procedures
- asset inventory
- access review records
- supplier review or monitoring records
- vulnerability management records
- incident records
- change records
- logging or monitoring evidence
- management review minutes
- previous internal audit reports
- corrective action records
Do not assume every organization keeps these records in the same format. The audit should request evidence that matches the organization’s documented ISMS, selected controls, risks, and procedures.
How To Perform The Audit: Questions, Evidence, And Testing
Perform the audit by comparing stated requirements with actual evidence. Review documents first, then interview process owners, then test a sample of records to see whether the process operates as described.
Look for three different evidence problems:
- Missing evidence: the process may have happened, but there is no retained record.
- Inconsistent evidence: records conflict with the policy, procedure, SoA, or interview explanation.
- Ineffective operation: the control exists but does not address the stated risk or requirement in practice.
The following checklist is illustrative editorial guidance, not an ISO template. Adapt it to your ISMS scope, risks, SoA, procedures, and audit criteria.
| Audit area | Sample question | Evidence to request | Test method | Possible finding/risk | Follow-up |
|---|---|---|---|---|---|
| Access reviews | Are privileged and user access reviews performed as defined? | Access review procedure, user export, privileged access list, completed review records, removal tickets | Select a sample of users and privileged accounts; compare review dates, reviewer approval, exceptions, and removal evidence | Review not completed, incomplete population, or terminated users retaining access | Confirm removals, update review workflow, assign owner for recurring review evidence |
| Asset inventory and risk alignment | Are in-scope assets recorded and considered in risk assessment? | Asset inventory, CMDB/export, risk register, system ownership records | Sample critical systems from the inventory and verify owner, classification, risk linkage, and treatment status | Critical asset missing from risk assessment or ownership unclear | Update inventory, assign owner, assess related risk, update treatment plan if needed |
| Supplier review | Are relevant suppliers assessed and monitored according to the supplier process? | Supplier list, supplier risk ratings, due diligence records, contracts/security addenda, review records | Select high-risk or in-scope suppliers; compare required review steps with completed evidence | Supplier used without required assessment or expired review | Complete review, document risk decision, update supplier monitoring schedule |
| Vulnerability management | Are vulnerabilities identified, assessed, and tracked through remediation or risk acceptance? | Scan reports, vulnerability tickets, remediation evidence, exception/risk acceptance records | Sample critical/high findings; trace from detection to closure, mitigation, or documented acceptance | Vulnerabilities exceed internal handling criteria without documented decision | Validate remediation, document acceptance where appropriate, review ownership/escalation |
| Logging and monitoring | Are required logs enabled and reviewed for selected systems? | Logging standard, SIEM/log source list, alert records, monitoring procedure | Sample in-scope systems; verify log source onboarding and evidence of alert review or investigation | Key system not logging as expected or alerts not reviewed | Restore logging, define monitoring owner, verify alert review evidence |
| Change control | Are security-relevant changes reviewed and approved as required? | Change procedure, change tickets, approvals, test results, deployment records | Sample recent production changes; check approval, risk/security review, testing, and rollback evidence | Emergency or production changes lack required approval or review | Retrospective review, update change workflow, clarify emergency change handling |
| Management review | Are audit results, nonconformities, and corrective actions considered by management? | Management review agenda, minutes, action register, audit report | Compare required inputs with meeting records and resulting actions | Audit results or corrective action trends not reviewed by relevant management | Add missing inputs to next review, assign actions, retain minutes |
| Corrective action follow-up | Are previous findings closed based on evidence, not only status updates? | Previous audit report, corrective action plan, closure evidence, effectiveness review | Sample closed actions; verify cause addressed, action completed, and effectiveness reviewed where appropriate | Ticket closed without evidence or recurring issue not addressed | Reopen or revise action, define verification method, report status to management |
A good audit trail is specific. Instead of writing “access reviews look incomplete,” record the exact population, sample, date range, evidence reviewed, and criterion used.
How Annex A Controls Relate To Internal Audit Findings
Annex A controls matter because they are connected to risk treatment and the Statement of Applicability. ISO/IEC 27001 requires the organization to determine necessary controls for risk treatment, compare them with Annex A so necessary controls are not omitted, and produce a Statement of Applicability that records applicable controls and justifications for inclusion or exclusion.
Source: Intertek ISO/IEC 27001:2022 transition checklist
That does not mean every Annex A control automatically applies, or that Annex A alone defines the audit scope. The auditor should start from the SoA, risk treatment plan, policies, procedures, and selected criteria.
A finding should be tied to a requirement or criterion, not personal preference. For example:
- If the SoA says supplier monitoring is applicable, the auditor should be able to ask what monitoring is required and review evidence that it occurred.
- If the access control procedure requires quarterly privileged access reviews, the auditor can test whether the review happened for the defined population.
- If a risk treatment plan assigns a control owner and target action, the auditor can check whether the action is complete or still open.
Findings can indicate conformity, nonconformity, risk, opportunity for improvement, or good practice, provided they are based on verifiable evidence and evaluated against defined criteria. If the organization uses classifications such as major, minor, observation, or opportunity for improvement, define them in advance, make the definitions clear, and apply them in a clear and consistent way.
What The Internal Audit Report Should Include
The internal audit report should make the audit reproducible. A reader should be able to understand what was checked, what evidence was used, what conclusions were reached, and what happens next.
Include:
- audit objective
- audit scope
- audit criteria
- audit dates
- auditor or audit team
- people interviewed
- evidence reviewed
- sampling approach, where relevant
- summary of results
- conformities or effective practices, where useful
- findings or nonconformities
- classification, if used
- corrective action owners
- due dates
- follow-up or verification status
- retained documented information supporting the programme and results
The following example is illustrative editorial guidance, not a required ISO report format.
| Field | Example |
|---|---|
| Condition | Privileged access review for the production administration group was not completed for Q2. |
| Evidence | IAM export dated 5 July showed 18 privileged users. Access review calendar required Q2 completion by 30 June. No completed Q2 review record was available for the production administration group. |
| Requirement / criterion | Internal access control procedure requiring quarterly privileged access reviews; Statement of Applicability mapping for applicable access control; ISO 27001 internal audit criterion for effective implementation of ISMS controls. |
| Risk | Privileged access may remain active after role changes, transfers, or departures, increasing the risk of unauthorized administrative activity. |
| Classification | Classification per the organization’s documented method. |
| Owner | IAM owner, with Engineering leadership support. |
| Corrective action | Complete the missed review, remove or approve access exceptions, confirm the full privileged user population, and update the recurring review workflow so evidence is retained at completion. |
| Due date | Set by the organization based on risk, corrective action process, and management expectations. |
Avoid vague findings such as “access control needs improvement.” A defensible finding names the condition, evidence, criterion, risk, owner, and expected action.
How To Follow Up After The Audit
An internal audit is not done just because the report is issued. Findings still need owners, actions, due dates, and verification.
For nonconformities, corrective action should include responding to the issue, addressing causes as appropriate, reviewing effectiveness, and retaining documented information on actions and results. Management review also considers audit results and trends in nonconformities and corrective actions.
Source: Intertek ISO/IEC 27001:2022 transition checklist
A practical follow-up flow is:
- Confirm the finding with the process owner.
- Assign an accountable owner and due date.
- Determine whether cause analysis is needed.
- Define corrective action that addresses the cause, not just the missing record.
- Retest or verify completion using evidence.
- Update the corrective action register.
- Feed results into management review.
- Retain the audit report, evidence references, corrective action records, and verification results.
If your team uses Ciphrix, keep the same discipline there: map controls to criteria, keep evidence current, and manage corrective actions as operational work rather than a pre-audit document scramble.
A strong ISO 27001 internal audit is impartial, evidence-based, documented, and followed through. Plan the audit around your ISMS criteria, test whether controls operate as described, write findings that connect evidence to requirements, and close the loop through corrective action and management review.