---

What is an ISO 27001 Internal Auditor?

An ISO 27001 internal auditor is the person responsible for independently assessing your ISMS against the requirements of the standard. They examine whether your controls are implemented, operational and effective — and report their findings formally before your external certification audit.

The auditor doesn’t have to be a qualified ISO 27001 specialist, but they must be objective — meaning they can’t audit their own work. In practice, for smaller organisations this often means using a colleague from a different team, or outsourcing the audit entirely to an independent consultant.

No formal certification is required to act as an ISO 27001 internal auditor, though training courses are available if you want your auditor to build formal competence. What matters to the certification body is that the auditor is competent, objective, and that the audit is documented properly.

---

What is an ISO 27001 internal audit?

An ISO 27001 internal audit is a planned, evidence-based review of your Information Security Management System (ISMS) to confirm that:

• It conforms to your own ISMS requirements and documentation (i.e. anything you’ve said in your own policies and procedures); and
• It complies with the requirements of ISO 27001.

Internal audits are usually carried out by your own staff (or an external consultant acting as an internal auditor) and are required by clause 9.2.

They sit in the “Check” step of Plan–Do–Check–Act and should inform management review and corrective actions based on the reported findings and suggestions.

Internal vs External Audits

To clarify the difference in audits;

• Internal audits – conducted by you (or an external person working on your behalf) to check your ISMS is working and to pick up issues early. ISO requires you to conduct this at ‘planned intervals’.
• External audits – done by a certification body to decide whether you should be certified and whether your certificate can be maintained. Certification typically follows a three-year cycle, with surveillance audits conducted during the cycle and recertification at the end.

You need both, but a good, thorough internal audit makes an external audit much less painful.

---

Objectives of the ISO 27001 internal audit

Any audit is really just checking that you are doing what you said you would, through sampling of evidence. An internal audit should aim to:

• Confirm that the ISMS is implemented and maintained, not just a heap of shelfware documentation that isn’t actually being used.
• Check that mandatory documents, records and controls exist and are under control
• Identify nonconformities and opportunities for improvement before the external auditor does
• Provide assurance to management and interested parties (customers, partners, regulators)

If you’re small, think of it as your annual health check before the certification body turns up. This way, you can avoid disrupting the audit process when you arrive if something is substantially missing or incorrect – and believe me, I’ve seen it.

---

Step-by-step: how to run an ISO 27001 internal audit

1. Set up an internal audit programme

ISO 27001 expects you to “plan, establish, implement and maintain” an audit programme that considers:

• The importance of processes
• Changes affecting the ISMS
• Results of previous audits

In other words, don’t audit randomly, but focus on what matters most.

Your audit programme should define:

• Frequency – 27001 requires audits at ‘planned intervals’ (e.g., annually) and at major changes.
• Methods – interviews, document review, sampling of records, observation
• Responsibilities – who audits what
• Reporting – who receives reports and by when

If you’re small, you can audit the entire ISMS in one go. If you’re larger or rapidly changing, split it into quarters over the year, perhaps (e.g. Clauses 4–10 in Q1, key Annex A themes across the rest of the year).

27001 requires you to;

• Keep documented evidence of the audit programme(s) and audit results
• Ensure results are reported to relevant management

---

2. Define the audit scope and criteria

For each individual audit, you must define:

a) Scope – what you’re auditing

Be clear which parts of the ISMS are in scope, such as:

• Clauses (e.g. “4–10 for the whole ISMS”)
• Controls (the Annex A families within scope)
• Processes (e.g. “Access control and HR security”)
• Locations and systems (e.g. “UK office, AWS production environment”)

The scope needs to match your organisation’s circumstances and your ISMS scope.

b) Criteria – what you’re assessing against

Typically:

• Relevant ISO/IEC 27001:2022 clause requirements
• Your own ISMS documents (policies, procedures, Statement of Applicability, risk methodology). This is important: if you said you are doing something in your documentation, you need to be able to evidence it (don’t over-promise and under-deliver!).
• Any legal or contractual requirements you want to check

Your audit checklist should reflect these criteria and your own documentation, ensuring you test what you actually do.

---

3. Ensure auditor objectivity & capability

ISO 27001 states that internal audits must be objective and impartial, but it can be a bit of a problem for smaller organisations to demonstrate that, so in a moment we’ll look at some options, but what it means is;

• Don’t audit your own work if you can possibly avoid it.
• Rotate auditors between teams (e.g. someone from operations audits HR, and vice versa).
• If you’re very small, consider engaging an external ISO 27001 auditor (like me!) to serve as your internal auditor.

Whatever you decide, document the approach in your audit plan/procedure so you can show the certification auditor how you manage independence.

Auditors must also be competent in the areas they audit, ensuring they have sufficient training and understanding to conduct the audit thoroughly. So don’t throw a copy of 27001 at your junior help desk person and ask them to ‘go audit’ something without making sure they are equipped to do so. But you’d never do something like that – would you?

---

4. Prepare using an ISO 27001 audit checklist

Good preparation makes the actual audit much easier. It’s really important to establish the requirements, your questions, and the potential evidence you would expect to see when auditing. Sometimes, those you are auditing are new to 27001, and might need a gentle prompt in terms of ‘do you have x… evidence’ as an example – just a little guidance, not crossing the line, but saying what might be acceptable in terms of evidence.

So, to prepare;

Use your internal audit checklist (or my template in the kit) to build a line of enquiry around:

• Clauses 4–10
• Mandatory documents and records
• Key Annex A control areas relevant to the organisation

Before the audit, gather key documents and records. It’s best to do this first so you can give them a read through and understand the ISMS first. For example:

• ISMS scope
• Information security policy
• Statement of Applicability
• Risk assessment and risk treatment plan
• Asset inventory
• Training and awareness records
• Incident log
• Previous internal audit reports
• Nonconformity / corrective action log
• Latest management review minutes

This provides a baseline understanding before speaking with anyone and may even queue up a few opening questions on areas where you are seeking clarity.

---

5. Conduct the audit (fieldwork)

Now you actually go and see whether reality matches the paperwork through a series of meetings and reviews.

a) Opening / initiation

• Confirm the scope, objectives, timing and people involved. Making sure the verbal description matches the written description and your understanding of scope.
• I like to review the key dependencies (major outsourced services) and the overall architecture as well. Just at a high level.
• Explain that the audit exists to give assurance and improve, not to catch people out.

b) Interviews and observation

Depending upon the size and nature of the business, the review meetings will likely require you to talk to the people who operate the controls day-to-day:

• HR (onboarding/leavers, training)
• Engineering / DevOps / IT (access, backups, change, deployment)
• Compliance / security roles
• Management responsible for risk and decisions

Check awareness with simple questions:

• “How would you report an incident?”
• “Where do you find the information security policy?”
• “When did you last have security training?”

c) Document and record review

Compare what you witness in terms of evidence with what your procedure says should happen.

Sample records such as:

• New starter and leaver records
• Access reviews and approvals
• Change tickets and deployment records
• Supplier reviews and contracts
• Backup and restore tests
• Incident reports and follow-up actions
• System screenshots and demonstrations

d) Evidence capture

Record objective evidence as you go:

• Document titles and version numbers
• Dates
• URLs, ticket IDs, screenshots
• Meeting minutes and decisions

Link each piece of evidence back to the relevant clause or control in your notes so it’s easy to build the report later.

---

6. Classify and record findings

As you identify issues, log them immediately while the evidence is fresh. It also helps to classify findings in a way that mirrors external certification audits, so your internal audit feels like a true rehearsal.

A simple, widely recognised structure is:

Nonconformity (Major)

A major nonconformity is a serious breakdown or absence of a required element. It usually indicates the management system (or a key part of it) is not working as intended, or there is no effective implementation.

Examples

• No documented ISMS scope (Clause 4.3).
• No Statement of Applicability, or it exists but is not maintained and cannot be explained or evidenced (Clause 6.1.3 d)).
• An internal audit programme exists in name only, but audits are not being performed at planned intervals (Clause 9.2).

Nonconformity (Minor)

A minor nonconformity is an isolated lapse or partial failure that does not suggest the whole system is broken, but still needs corrective action.

Examples

• The ISMS scope exists, but it has not been reviewed after a significant organisational change (Clause 4.3).
• The Statement of Applicability exists, but one or two control justifications are missing or outdated (Clause 6.1.3 d)).
• A specific audit was planned but not completed for one area, or audit evidence is incomplete for one requirement (Clause 9.2).

Opportunity for improvement (OFI) / Area for improvement

The requirement is met, but the approach could be strengthened to improve consistency, efficiency, or assurance.

Examples

• Metrics exist, but aren’t routinely reviewed or reported to the ISMS group/management (Clause 9.1).
• Corrective actions are completed, but root-cause notes are brief and trends aren’t analysed over time (Clause 10.1).

Observation

Something to watch, tidy up, or clarify. Observations are not nonconformities, but they can become problems if left alone.

Examples

• Training records exist but are spread across tools and inboxes, making them hard to evidence quickly during an audit.
• A policy is in use, but the “owner” and next review date aren’t clearly shown on the document.

Log each finding with:

• A clear description
• The clause/control reference
• Evidence reference(s)
• Suggested action or next step

Feed these into your Nonconformity / Corrective Action Log so clause 10.2 (nonconformity and corrective action) can pick them up.

---

7. Write the internal audit report

Your internal audit report is what management and your certification auditor will actually read, so make it clear and concise.

A good report usually includes:

• Audit title, scope, date, auditor(s)
• Summary of overall ISMS maturity – what’s working well
• Key findings – significant strengths, nonconformities and areas for improvement
• A list of nonconformities (with clause references and evidence)
• A list of opportunities for improvement
• Any limitations (e.g. areas you couldn’t fully test)
• Who the report is issued to and when

---

8. Present findings to management / ISMS steering group

Don’t just email the report and file it away. Under clause 9.2.2 (d) you must review the findings with the appropriate leadership team(s).

Circulate the report in advance, then present the key findings to your ISMS/Information Security Group or equivalent steering group. Use the session to:

• Agree on which actions are must-do before the next external audit
• Update the risk register where needed
• Decide on priorities and owners
• Make sure findings and actions are fed into the next management review (clause 9.3)

This is what shows the auditor that your internal audits actually drive decisions.

---

9. Raise corrective actions and follow them through

Every nonconformity must feed into your corrective action process under clause 10.2.

For each nonconformity:

1. Describe the issue
2. Analyse the cause (not just the symptom)
3. Decide on actions to address the cause
4. Implement the actions
5. Verify that the actions were effective

Keep the evidence: updated documents, new records, screenshots, minutes, etc. This is how you demonstrate continual improvement over time, not just “passing the audit”.

---

FAQs

---

Final notes for internal auditors

• You don’t have to audit everything in one massive exercise. Splitting audits into ‘mini sessions’ focused on a clause or group of controls across the year is often easier for small tech teams. In fact, I’d recommend it.
• Use a simple, repeatable method rather than over-engineering your audit approach.
• Keep your audit results and supporting evidence until at least the next certification visit – longer if they’re useful to show improvement over time.