Every organisation that has been through an ISO/IEC 27001 audit has a version of the same story. The awareness evidence is a forty-slide deck, a sign-in sheet from eighteen months ago and a line in the induction checklist. The auditor nods, closes the folder, walks onto the floor and asks a dispatch clerk three questions: what would you do if you got an email asking you to change a supplier's bank details, where do you report something that looks wrong, and what happens to someone who ignores the rules. The clerk gets two of the three wrong. The deck was never the control. The clerk's answers were.
This article is about what the standard actually requires of security awareness and training — which turns out to be three different things in three different places — what an auditor tests, and how to build a programme that passes the audit because it works rather than instead of working. It is written for the people who run management systems and have just inherited the "security training" line in the plan.
A note on sources. This article paraphrases ISO/IEC 27001:2022 clauses 7.2 and 7.3 and Annex A control 6.3, ISO/IEC 27002:2022's guidance on that control, and the South African POPIA Regulations in plain English. It reproduces no standard or statute text. Work from your licensed copies; the words that bind you are there, not here. Statistics are current as at October 2026 and sourced at the end.
Three requirements, three different things
People say "awareness training" as one phrase and the standard splits it three ways.
Competence (clause 7.2) is about the people whose work affects information security performance — the administrators, the developers, the Information Officer, the person who runs the backups. The organisation decides what competence those roles need, makes sure the people in them have it through education, training or experience, acts where they do not, and keeps the evidence. Competence is specific and role-bound: can this person actually do this job securely? The record is a competence matrix and the training, qualification and experience behind each line — not an attendance register.
Awareness (clause 7.3) is about everyone who works under the organisation's control. They need to be aware of the information security policy, of how their own work contributes to the ISMS and what the benefit of better security performance is, and of what the consequences are when the system's requirements are not met. Awareness is general and universal, and it is tested by asking people — which is why the auditor walked onto the floor.
Awareness, education and training as a control (A.6.3) is the operational programme that delivers the two clauses above: planned, relevant to people's roles, updated as policies and procedures and threats change, and tied to the rules people are actually expected to follow. ISO/IEC 27002's guidance on the control is the useful part — a programme, not an event; role-relevant content; evaluation of whether it worked; and the reminder that contractors and external parties' personnel are in scope.
Three requirements, then: the right people can do their jobs securely; everyone knows the policy, their part and the consequences; and there is a living programme that makes both true and can show it. An auditor can raise a nonconformity against any of the three on its own.
What awareness has to cover
The clause gives the minimum; the control and common sense give the rest. A programme that would satisfy both covers, for every person in scope:
- The information security policy — not its text, but what it means for them: what the organisation has committed to and expects of them.
- Their own contribution — the handful of things their role does that protect or expose information, in their own terms. The dispatch clerk's list is not the finance clerk's list.
- The consequences of not conforming — for the organisation and for the person — stated plainly and matched by what actually happens.
- How to report an event or a suspicion, and that reporting is safe. This is the single highest-value piece of content in any programme, because the report-a-phish button is the control that catches the real one.
- The current threats that reach them: today, phishing in its many forms, business email compromise, credential theft, the misuse of free online tools with company data, and the social engineering that arrives by phone and in person.
- The rules that apply to their work — acceptable use, handling of personal information, clear desk, devices off site, passwords and multi-factor authentication — as rules they can repeat, not pages they once scrolled.
The programme should also change when something changes: a new policy, a new system, an incident that taught the organisation something, a threat that has started arriving. The deck from eighteen months ago fails this test before anyone reads a slide.
Who is in scope
Everyone doing work under the organisation's control. That phrase is wider than the payroll: temporary staff, contractors, the managed service provider's engineers with administrator access, the external developer, the cleaner with a key to the server room, the customer's driver who walks through the dispatch office. The programme does not have to put every one of them through the same module — the control says role-relevant — but it does have to reach them, and the auditor will ask how. The commonest finding here is that the organisation's own people are well covered and the third parties with the most access have had nothing at all.
What an auditor tests
An auditor has about forty minutes for this topic in a Stage 2 audit and spends them in a predictable way.
The plan. Is there a programme — content, audience, cadence, owner — or a calendar entry? Does it cover the clause 7.3 points and the role-specific content for the roles that matter?
The records. Who has done what, when: completion rates by group, new starters inducted before they get access, the third parties reached. A gap in the records for one site or one shift is the usual finding.
Effectiveness. This is where most programmes fail. Did it work? Phishing-simulation click and report rates over time, quiz results, the trend in events reported by staff, the number of policy breaches found at audit. If the organisation measures nothing, the auditor concludes the programme is an activity, not a control — and clause 7.2's requirement to evaluate the effectiveness of actions taken is a specific hook for that finding.
The floor. Three or four people, chosen by the auditor, asked the clause 7.3 questions in their own words at their own workstations. Where do you report? What would you do if? Why does it matter? What happens if you do not? Divergence between what the deck says and what the floor says is the finding — and it is also the only test that matters.
Designing a programme that passes because it works
A few design decisions separate programmes that produce evidence from programmes that produce slides.
Make it role-based, in layers. A short core module for everyone — policy, contribution, consequences, how to report, the current threats — and short role tracks for the roles whose mistakes cost most: finance and payments, administrators, people who handle personal information, managers, drivers and field staff with devices. Ten minutes that are about someone's own work beat forty that are about everyone's.
Run it on a cadence, not an anniversary. Induction before access; a short refresher each quarter tied to something current; a role track each year; a note when a policy or threat changes. Twelve short touches outperform one long one in every study of retention, and they produce twelve dated records instead of one.
Simulate, but do it well. Phishing simulations are the best effectiveness measure available, and the easiest to do badly. Measure the report rate as well as the click rate — reporting is the behaviour you want — and never punish a click. The organisation that disciplines clickers stops hearing about events, which is a worse outcome than any click. Brief managers before the first campaign so that the people caught hear "thank you for reporting" rather than "you failed".
Measure what matters, and show it. Completion rate, induction-within-five-days rate, simulation click and report rates, events reported by staff, awareness questions answered correctly in the pulse survey. These are the measures K-01 to K-04 and K-16 in the Qlause Metrics and Evidence Tracker, because they are the ones auditors ask for and boards understand.
Keep the content honest about its age. Threat content dates in months. Put a "current as at" line on it and diarise the refresh; an auditor who sees a 2024 threat slide in 2026 draws the right conclusion.
Record the right things. Attendance proves presence. Completion with a passed quiz proves exposure. A trend in behaviour proves effectiveness. Keep all three, and keep the third where management review can see it.
The number to use, and the number not to
Vendors of awareness platforms like to say that human error causes 85 to 95 per cent of breaches. The figure that survives scrutiny is lower and more useful: the Verizon Data Breach Investigations Report's 2026 edition puts the human element — people falling for social engineering, misusing access, making errors, or having credentials stolen — in about 62 per cent of the breaches it analysed. Sixty-two per cent is still the largest single factor, and it is the one awareness and the related controls can move. Quote it, and the source, and the programme looks like something built by people who read the evidence.
The POPIA overlap
In South Africa the awareness duty has a second owner. Regulation 4(1)(e) of the POPIA Regulations requires the Information Officer to see that internal awareness sessions are conducted on the Act, the Regulations, applicable codes of conduct and the Regulator's information. One programme can carry both: the core module covers what personal information is, why the organisation protects it, the basic rules for handling it, and how to report a suspected compromise — and the Information Officer signs the plan alongside the ISMS lead. The attendance and completion records then evidence the Regulation and the control at once. The POPIA ↔ ISO 27001 Crosswalk maps that duty and the twenty-three others.
What to do this quarter
- Write down the programme on one page: audiences, content per audience, cadence, owner, measures. If it does not exist on one page it does not exist for an auditor.
- Map the roles whose competence affects security — administrators, developers, backup owners, the Information Officer — to the competence they need, and record how each person has it. That is clause 7.2 and it is not the same document.
- Add the third parties: the managed service provider's engineers, the external developer, the contractors on site. Decide how each is reached — your module, their evidence, or a contract clause — and record it.
- Start measuring: completion rate, induction-within-five-days, and a first phishing simulation with the report rate as the headline number and a no-blame briefing before it.
- Put four questions on the pulse survey or the toolbox talk and track the answers: where do you report, what would you do if, why does it matter, what happens if you do not.
- Put a "current as at" date on every piece of threat content and a refresh in the diary.
Qlause Cyber Aware is built to this pattern: short scenario-based modules (three of them free to watch), each with a quiz and a dated, verifiable certificate that falls due again after twelve months, sold as yearly licences — for one person or a whole company, with toolbox talks, posters and attendance registers for in-house sessions. The free ISO 27001 masterclass and the Clause Explorer pages for 7.2, 7.3 and A.6.3 are there now.
Frequently asked questions
Is an annual training session enough for ISO 27001?
It satisfies the letter of a programme existing and it will not survive the floor test or the effectiveness question. Short, frequent, role-relevant touches with measured results are what the control describes and what auditors have come to expect.
Do contractors and our IT provider's staff have to do our training?
They are in scope — everyone doing work under the organisation's control — but the control says role-relevant, not identical. A contract clause requiring the provider to evidence its own equivalent training is an accepted way to cover them; a visitor briefing covers the people who walk through. What is not accepted is silence.
Do phishing simulations count as evidence?
They are among the best evidence available: a repeatable measure of behaviour over time. Report the click rate and the report rate, keep the trend, and keep the no-blame rule — a simulation that punishes people destroys the reporting culture it is meant to build.
What is the difference between competence and awareness in an audit?
Competence is tested against a role — can this administrator do this securely, and how do you know — and the evidence is a competence record. Awareness is tested against everyone — do people know the policy, their part and the consequences — and the evidence is what people say when asked. A nonconformity can be raised against either on its own.
How do we show that training was effective?
Measure something that should move if it worked: simulation results, reported events, quiz scores, audit findings on policy breaches, pulse-survey answers. Clause 7.2 asks for an evaluation of effectiveness; a dated measure with a before and an after is the simplest one there is.
Qlause is an independent training and templates provider, not a certification body. This article paraphrases ISO/IEC 27001:2022 and ISO/IEC 27002:2022 and the POPIA Regulations in plain English and reproduces no standard or statute text; work from your licensed copies. Sources: ISO/IEC 27001:2022 and 27002:2022 (iso.org); POPIA Regulations 2018, Regulation 4; Verizon 2026 Data Breach Investigations Report (human element in breaches).