In every surveillance audit, I look at the internal audit. I ask for two documents: the audit programme and at least one audit report.
The two words get mixed up a lot, and it’s more than a question of wording. ISO 19011, the guideline for auditing management systems, describes them as two separate things. ISO 27001 asks for both. If you know where one ends and the other begins, it gets much easier to set up an internal audit that actually tells you something.
So in this issue, I’ll walk you through how I look at it: the three kinds of audit, how the programme and the individual audit fit together, what I check in clause 9.2.2, and what a good programme looks like.
First, second, third party
Before we get to the programme, it helps to be clear about which kind of audit we’re talking about. Audits are grouped by who audits whom:
Your internal audit is first party. When you audit your cloud provider, or a customer audits you, that’s second party. When I come in for a certification audit, that’s third party.
Each kind has its own standards. ISO 19011 gives guidance for first- and second-party audits, and ISO/IEC 27007 adds the information security part for an ISMS. As a certification auditor, I work under ISO/IEC 17021-1 and, for ISMS certification, ISO/IEC 27006-1.
The wording is worth a second look. ISO 19011 is a guideline, so it says “should”. ISO 27001 and ISO/IEC 17021-1 say “shall”, and I can only raise a nonconformity against a “shall”. Nobody will give you a nonconformity for ignoring ISO 19011. What your internal audit is measured against is ISO 27001, clause 9.2. Still, when someone asks me how to meet 9.2, ISO 19011 is the first thing I point them to.
The audit programme and the audit
ISO 19011 describes two processes, one inside the other. I’ve arranged them by Plan, Do, Check, Act, because that’s the easiest way I’ve found to explain how they connect:
The upper half is the audit programme. It covers all the audits you plan for a period, usually a year, and the reasons behind them. It runs as a cycle: you set objectives, look at the risks, put the programme together, carry it out and keep an eye on it. At the end, you review it, and the next cycle starts with what you learned.
The lower half is a single audit. It has a beginning and an end: you initiate it, prepare it, conduct it, write the report and close it. Each audit is one piece of “implement the programme”, and its results flow back into monitoring the programme.
Side by side, it looks like this:
A list of dates with “Clauses 4 to 7” next to each one is a calendar. It’s a useful start, but it isn’t a programme yet. It doesn’t say why these audits, why this often, or against what.
What I check in 9.2.2
Clause 9.2.2 contains four things I check. For each one, there’s a question I usually start with:
Here’s what sits behind each question.
With the programme, I want to see that it reflects how important each process is and what earlier audits found. What makes me dig deeper is the same cycle for every process, unchanged for years, with incidents and risk results never making it in. A small organization’s programme can be a single audit, and that’s fine, as long as you can explain why.
With scope and criteria, the warning sign is “Scope: ISMS. Criteria: ISO 27001” on every report. The two are easy to mix up, so this is how I separate them. Criteria are what you compare against: the standard, but also your own policies, procedures and legal or contractual obligations. Scope is what you look at: which locations (physical and virtual), functions and processes, and which period. An audit that never uses your own policies as criteria can’t tell you whether you follow them, and that’s exactly what 9.2.1 asks.
With objectivity, I look at who audited what. The typical problem is the ISMS manager auditing the processes they run themselves, or the consultant who built the ISMS also running its internal audit.
With reporting, I follow the results. They’re an input to the management review (9.3.2). If the report never gets past the ISMS manager, top management never sees it, and the loop is broken.
If you want the bigger picture of clause 9, with monitoring, internal audit and management review together, my guide to performance evaluation walks through it.
What a programme looks like: Barvello
To make this concrete, here’s an excerpt from the 2026 programme of Barvello Coffee Systems, the fictional company I use in my ISO 27001 Lead Implementer course. Barvello has 504 employees in Munich, Treviso and Charlotte and runs its own cloud platform, Barvello Connect, with 21,700 connected machines.
The programme opens with its objectives: confirm that the ISMS conforms to ISO 27001 and to Barvello’s own policies, and put the effort where the risk is highest. High-risk processes are audited every year, everything else at least once every three years. The ISMS manager runs the programme, management approves it, and the results go into the management review in December.
If I were auditing this, I’d start with the last column. Every audit is in there for a reason: a high risk, findings from last year, a new supplier. That’s what 9.2.2 means by the importance of the processes and the results of previous audits.
Then I’d look at scope and criteria. Each audit has its own, and the criteria name Barvello’s policies and SoA rows, not just the standard. Nobody audits their own work. And the supplier audit sits in the same programme, so there’s one plan for all of it.
How to check your own programme
If you want to look at your own programme the way I would, this is the order I’d go in:
Write down why each audit is in the programme and why at that frequency, and put the programme’s objectives at the top. If you can’t explain an audit, start there.
Give each audit its own scope and criteria: where, which processes, which period, and against which policies and SoA rows.
Check who audits what. If someone audits their own processes, swap auditors between areas or bring someone in from outside.
Plan when the results reach management, so the report is ready before the management review.
Keep the records: the programme, the audit plans, the reports, and evidence that your auditors are competent (ISO 27001, 7.2).
A quick way to start: take your current programme and ask yourself the four questions from the table above. The first one you can’t answer is the one to work on.
What’s new in ISO 19011:2026
ISO published the fourth edition in May 2026, replacing the 2018 edition. Since it’s a guideline, there’s no transition period. The structure and the seven principles of auditing are the same as before.
The biggest change is remote auditing, which is now a defined audit method. The programme risks also include two new questions: can the method you chose actually achieve the audit objectives, and is the platform you audit on secure? If you run internal audits by video call, name that method in your programme and think through both.
Also new: a lack of sponsorship from leadership is now listed as a risk to the audit programme. If management never sees your audit results, you have that risk.
This Friday: Audit your internal audit, with Tristan Roth
On Friday, November 6, at 3 PM CET (9 AM ET), I’m going live on GRCLab, and this time I’m not alone: Tristan Roth is joining me.
We’ll go through it step by step, and then you get to audit:
The audit programme process from ISO 19011, clause by clause
What we check in 9.2.2, and the questions we ask
A live workshop: together, we audit the internal audit programme and one audit report of a fictional SaaS company. You find the nonconformities and the opportunities for improvement.
What changed in ISO 19011:2026, and what it means for remote audits
Bring your own programme and your questions. There’s a live Q&A at the end, and it’s free.
See you on Friday, Aron
P.S. How many internal audits are in your 2026 audit programme? Just reply with the number. I read every reply.