How to collect audit evidence for ISO 27001 awareness

TL;DR

How to collect audit evidence for ISO 27001 awareness is not a mystery. It is a workflow.

For each client tenant, you need to show who was trained, what they were trained on, when it happened, whether they completed it, what policies or risks the training supported, and which gaps or exceptions still exist.

That evidence supports ISO 27001 Clause 7.3 and Annex A 6.3. It does not prove the whole ISMS, it does not prove certification, and it should not be mixed with technical control evidence. MSPs should build a repeatable evidence pack before audit week, so ISO 27001 awareness stops turning into a screenshot hunt.

What ISO 27001 awareness evidence is

ISO 27001 awareness evidence is the set of records that show people inside the ISMS scope understand their security responsibilities.

That sounds simple. It gets messy fast when an MSP has 30 clients, each with different users, policies, training dates, overdue staff, onboarding cycles, and audit requests.

The official ISO/IEC 27001:2022 page describes ISO 27001 as the best-known standard for information security management systems. It says the standard defines requirements an ISMS must meet and helps organisations manage risks related to data security.

For awareness, the direct requirement sits in Clause 7.3. ISMS.online's guide to ISO 27001 Clause 7.3 Awareness summarises it as making personnel aware of the information security policy, their contribution to the ISMS, and the consequences of not conforming with ISMS requirements.

Annex A 6.3 is the matching awareness, education, and training control. ISMS.online's Annex A 6.3 guide explains that personnel and relevant interested parties should receive appropriate information security awareness, education, and training, with regular updates tied to their roles.

For an MSP, the plain-English evidence question is this:

Can you prove the right people received the right awareness at the right time, for the right client, without exposing another client's data?

If the answer depends on one engineer searching inboxes and downloading screenshots from 4 places, the evidence process is broken.

Why MSPs should collect awareness evidence all year

Most ISO evidence problems are calendar problems.

The training may have happened. The client may be happy. The platform may show completion. But when the audit request arrives, the MSP has to reconstruct the story from exports, rosters, policy versions, email reminders, and exceptions.

That is not a compliance process. That is archaeology.

Bridewell's guide to Stage 1 and Stage 2 ISO 27001 certification audits explains the practical difference: Stage 1 focuses on documentation and readiness, while Stage 2 tests implementation and effectiveness. Awareness evidence has to survive both levels of scrutiny.

Stage 1 may ask whether the awareness process exists and is documented. Stage 2 may ask whether it actually ran, who it covered, whether people understood it, and what happened when users missed it.

Security awareness evidence also gets reused outside the certification audit:

• A client asks for proof before a supplier review.
• A vCISO needs a quarterly compliance pack.
• A board wants a clean summary before renewal season.
• An insurer asks whether staff receive ongoing security awareness training.
• An internal auditor wants to sample completion data.
• A new compliance lead asks what happened last year.

The MSP cost is not the training module. It is the repeat work around the module: gathering data, separating tenants, explaining coverage, cleaning exports, and writing a report the client can understand.

That is why the evidence should be collected as part of normal delivery.

Not at the end.

What auditors need to see for ISO 27001 awareness

Auditors do not need theatre. They need enough evidence to judge whether the requirement is met.

High Table's guide to ISO 27001 Annex A 6.3 is blunt about record keeping: keep records of training and awareness, and be ready for auditors to check completion rates, onboarding integration, and staff understanding.

That does not mean every client needs a 70-page pack.

It means the pack needs to answer specific questions:

• What was the scope?
• Which people or groups were included?
• Which people were excluded, and why?
• Which topics, policies, or risks were covered?
• When was training assigned?
• When was it completed?
• Who is overdue?
• How was understanding checked?
• Were new starters trained during onboarding?
• Were refreshers delivered after policy, risk, or role changes?
• Can the MSP reproduce the evidence later?

Secureframe's ISO 27001 evidence collection list and Sprinto's guide to ISO 27001 evidence collection both frame evidence as more than a document library. Evidence has to show that controls exist and operate, not just that a policy was written.

For awareness, that means a PDF certificate is useful, but incomplete.

A certificate says a person completed something. A stronger evidence pack says what the person completed, why it mattered, which policy or control it supported, whether anyone missed it, and how the MSP handled the misses.

ISO 27001 awareness evidence pack: what to include

Use this as a practical MSP checklist. The goal is not to make the pack bigger. The goal is to make it answer audit questions faster.

Evidence item	What it proves	MSP field to include	Common weak version
Scope summary	Which client, tenant, user groups, and date range the evidence covers	Client name, tenant ID or tenant label, date range, included groups, excluded groups	One export with no scope or date context
User roster	Which users were expected to complete awareness activity	Name, email, role or group, status, start date where relevant	A stale user list that does not match current staff
Assignment record	What was assigned and when	Campaign name, module name, assigned date, due date, user list	Screenshot of a dashboard total
Completion record	Who completed the assigned activity	Completion date, status, overdue users, completion percentage	Certificates only, with no assigned-user baseline
Topic map	Which risks, policies, or responsibilities were covered	Topic, related policy, related control, target role	Generic "cyber awareness" label
Assessment or acknowledgement	Whether users understood or acknowledged the content	Quiz result, pass/fail, acknowledgement date, phishing simulation result where used	Completion counted as understanding without any check
Reminder record	Whether the MSP followed up on non-completion	Reminder dates, overdue list, escalation owner	Manual emails that are not retained
Exception log	Why users were excluded or missed the deadline	User, reason, approver, review date, next action	Hidden exclusions or verbal explanations
Version record	Which content or policy version was used	Training version, policy version, campaign version	Old module with no version or policy link
Report export	What was handed to the client or auditor	Export date, report owner, file name, tenant, source system	Rebuilt report with no source trail

The table is intentionally boring.

Boring evidence is easier to review. It is easier to defend. It is easier to update next quarter.

Step-by-step: how to collect audit evidence for ISO 27001 awareness

1. Start with the client scope

Do not open the reporting dashboard first.

Start with the scope: the client, business unit, tenant, date range, employees, contractors, and relevant third parties. ISO 27001 scope matters because awareness requirements apply to people doing work under the organisation's control, not to a random export of whoever happened to be in a portal.

For MSPs, this is also the tenant-separation step. Client A's evidence pack must not include Client B's users, completion rates, domains, report names, or policy references.

2. Map awareness evidence to Clause 7.3 and Annex A 6.3

Keep the mapping plain.

Clause 7.3 evidence should show that people know the information security policy, how their work contributes to the ISMS, and what happens when they do not follow ISMS requirements.

Annex A 6.3 evidence should show appropriate awareness, education, and training, with regular updates tied to job function.

You do not need to pretend every training module maps to every ISO control. A clean 1-page map beats a bloated spreadsheet that claims too much.

3. Export the user and completion baseline

Every awareness evidence pack needs 2 lists:

• the users who were expected to complete the training
• the users who actually completed it

Without both, the evidence is weaker.

A 100% completion dashboard means little if nobody can tell whether the original user list was correct. A completion certificate means little if the auditor cannot see who else was assigned, who was overdue, and whether the excluded users were approved.

4. Capture topic and policy context

Training evidence should not be a mystery label.

If the module covered phishing, MFA prompts, password managers, reporting suspicious emails, data handling, secure remote work, or AI voice scams, say so. If it supported an acceptable use policy, incident reporting procedure, password policy, remote access procedure, or supplier security obligation, include that link in the pack.

This is where ISO awareness evidence becomes more useful to the client. It stops being "training completed" and becomes "this is what staff were told to do."

5. Add onboarding and refresher records

Annual training alone can leave a gap.

New starters need awareness when they join. People moving into higher-risk roles may need different content. Policy changes, incidents, and new risks may justify refreshers.

NIST SP 800-50, Building an Information Technology Security Awareness and Training Program, is old but still useful here. It treats awareness and training as an ongoing program, not a once-a-year file. NIST SP 800-53 Rev. 5 also includes an Awareness and Training control family, which reinforces the same program view.

For an MSP, the evidence pack should show the rhythm: onboarding, recurring awareness, reminders, refreshers, and exception handling.

6. Record misses instead of hiding them

A perfect-looking report is not always a better report.

If users missed training, record it. If a user was on leave, document it. If a service account appeared in a roster and was excluded, explain it. If an executive needed escalation, note the escalation owner and date.

Auditors do not expect every process to be flawless. They do expect the organisation to know what happened and act on gaps.

7. Package one client-ready report

The final pack should be easy to open and understand.

For each client, include:

1. Cover note.
2. Scope and date range.
3. Clause/control map.
4. User roster.
5. Assignment and completion records.
6. Assessment or acknowledgement data.
7. Reminder and exception notes.
8. Report export date and source.
9. Open actions.

A multi-tenant SAT platform makes this easier because evidence starts separated by client. Automated reports make it easier to repeat the pack without rebuilding the same file for every audit request.

8. Review evidence before it goes to the client

Do a 10-minute evidence check before sending anything.

Ask:

• Does this report show the right client only?
• Does the date range match the request?
• Are the controls named correctly?
• Are overdue users visible?
• Are exclusions explained?
• Does the report claim more than awareness evidence can prove?
• Can we reproduce this export later?

That last question matters.

If the MSP cannot reproduce the pack, the evidence process is still too fragile.

What good ISO 27001 awareness evidence looks like

Good evidence has 6 traits.

It is scoped. The pack names the client, tenant, date range, users, and groups covered.

It is specific. The report shows topics, modules, policies, dates, and assignments. It does not hide behind a generic "security training" label.

It is tenant-separated. One client's audit pack never exposes another client's data.

It shows exceptions. Overdue users, missed users, excluded users, and follow-up actions are visible.

It is mapped, not exaggerated. The pack supports Clause 7.3 and Annex A 6.3. It does not pretend training proves backup testing, MFA enforcement, vulnerability management, or incident evidence handling.

It is repeatable. The MSP can produce the same style of report next month, next quarter, or next audit without asking a senior engineer to rebuild it from memory.

This is the operational bar.

Not prettier screenshots. Better evidence.

Mistakes to avoid when collecting ISO 27001 awareness evidence

Mistake 1: Treating certificates as the whole pack

Certificates help. They are not the whole story.

If the auditor asks who was assigned training, why certain users were excluded, what topics were covered, or whether new hires were trained, a folder of certificates will not answer enough.

Use certificates as a supporting artefact, not the evidence model.

Mistake 2: Mixing client data in one export

This is an MSP-specific risk.

A generic LMS export may include multiple clients, shared admin notes, internal labels, or users from the wrong tenant. That creates a trust problem before the audit conversation even starts.

Each pack should be client-specific by default.

Mistake 3: Claiming awareness evidence proves technical controls

Awareness evidence does not prove MFA is enforced. It does not prove backups restore. It does not prove patching was completed. It does not prove incident evidence was preserved.

ISMS.online's guide to Annex A 5.28 Collection of Evidence is about evidence collection during information security incidents, including integrity, legality, and handling. That is a different evidence story from routine awareness training records.

Keep the boundaries clean.

Mistake 4: Forgetting onboarding evidence

Annual training can leave a bad gap if the client hired 14 people after the campaign closed.

The evidence pack should show how new users are added, when onboarding awareness is assigned, and how overdue new starters are handled. If that process is manual, write it down. If it is automated, export the proof.

A platform with training automation can reduce the hand work, but the evidence still needs a clear scope and review.

Mistake 5: Sending raw exports with no explanation

Raw exports make the client do the MSP's job.

Add a short cover note. Explain what the pack proves, what date range it covers, and what it does not prove. If technical control evidence lives somewhere else, say that.

A good report reduces questions. A raw dump creates them.

Framework mapping for awareness evidence

ISO 27001 is the main target here, but awareness evidence often supports other requests.

Framework or request	Where awareness evidence fits	What to avoid
ISO 27001 Clause 7.3	Shows people understand policy, their ISMS contribution, and consequences of nonconformity	Treating awareness as a one-off e-learning event
ISO 27001 Annex A 6.3	Shows appropriate awareness, education, training, and updates relevant to job function	Claiming generic training covers every role equally
NIST CSF Protect	NIST's Protect function includes Awareness and Training, where personnel and partners receive cybersecurity awareness education and training	Using NIST labels without evidence of scope, dates, or roles
NIST SP 800-53 AT family	Supports awareness and training controls for assigned users and roles	Treating federal control language as a direct ISO substitute
CIS Control 14	CIS Control 14 focuses on establishing and maintaining a security awareness and skills training program	Sending only certificates without program records
Cyber insurance questionnaires	Helps answer whether users receive ongoing security awareness training	Overstating training as proof of technical safeguards
Client QBRs	Gives the MSP a clean service report and open-action list	Turning QBRs into compliance theatre

The same evidence can serve more than 1 audience if it is scoped, dated, mapped, and written clearly.

That does not mean you should use one giant report for every request.

It means the underlying data should be clean enough to create the right report quickly.

How Defendwise fits

Defendwise is built for MSPs that need SAT to work across clients without turning every report into a custom project.

With white-label training, multi-tenancy, and compliance reporting, an MSP can deliver awareness training under its own brand, keep client tenants separated, and produce client-ready evidence without adding a per-seat tax to every new user.

That does not certify a client to ISO 27001. It does make the awareness evidence layer cleaner, faster, and easier to explain.

FAQ

How do you collect audit evidence for ISO 27001 awareness?

Start with the client scope, then collect training assignments, user rosters, completion data, topic maps, policy acknowledgements, assessment results, reminder logs, exception notes, and report exports. Package the evidence with a short mapping to ISO 27001 Clause 7.3 and Annex A 6.3.

What counts as ISO 27001 awareness evidence?

Useful evidence includes completion exports, certificates, quiz results, policy acknowledgements, onboarding records, refresher records, reminder logs, exception notes, and client-ready reports. The evidence should show who was trained, on what, when, and for which client scope.

Is a training certificate enough for ISO 27001 awareness evidence?

Usually, no. A certificate can prove an individual completed a module, but it does not show the full scope, assigned-user baseline, topic relevance, overdue users, policy links, or exception handling. Use certificates as one artefact inside a wider pack.

Which ISO 27001 clause covers awareness?

Clause 7.3 covers awareness in the management-system requirements. Annex A 6.3 covers information security awareness, education, and training as a control. In practice, MSPs should map awareness evidence to both where relevant.

How often should ISO 27001 awareness evidence be collected?

Collect it throughout the year. A practical MSP rhythm is to capture onboarding evidence as users join, export monthly or quarterly completion reports, record annual refreshers, and update the pack after policy, role, or risk changes.

What should an MSP include in an ISO 27001 awareness evidence pack?

Include a cover note, scope, date range, user roster, assigned training, completion records, topic map, policy acknowledgements, assessment results, reminder logs, exception notes, report export date, and open actions. Keep the pack tenant-specific.

Can awareness evidence prove ISO 27001 certification?

No. Awareness evidence supports part of the ISMS evidence story, especially Clause 7.3 and Annex A 6.3. ISO 27001 certification also needs evidence across risk management, policies, leadership, controls, monitoring, internal audit, management review, and continual improvement.

Where does Defendwise fit into ISO 27001 awareness evidence?

Defendwise helps MSPs run flat-rate, white-label awareness training across client tenants and produce client-ready reporting. It can support the awareness evidence layer, while the client and MSP still own the broader ISO 27001 audit evidence pack.

Source notes

External sources used for claims and research:

1. ISO, ISO/IEC 27001:2022 - official standard page and ISMS context.
2. ISMS.online, ISO 27001 Clause 7.3 Awareness - awareness requirement summary.
3. ISMS.online, ISO 27001 Annex A 6.3 - awareness, education, and training control summary.
4. High Table, ISO 27001 Annex A 6.3 Information Security Awareness - auditor focus, record keeping, and training-program guidance.
5. Bridewell, What to Expect From Stage 1 and Stage 2 ISO 27001 Certification Audits - audit-stage framing.
6. Secureframe, ISO 27001 Evidence Collection List - evidence collection context.
7. Sprinto, From Policy to Proof: Mastering ISO 27001 Evidence Collection - evidence collection process context.
8. ISMS.online, ISO 27001 Annex A 5.28 Collection of Evidence - distinction between incident evidence collection and awareness-training evidence.
9. NIST, Cybersecurity Framework Protect Function - Awareness and Training category context.
10. NIST, SP 800-50 - security awareness and training program guidance.
11. NIST, SP 800-53 Rev. 5 - Awareness and Training control family context.
12. CIS, Control 14: Security Awareness and Skills Training - security awareness program context.
13. A-LIGN, ISO 27001: Everything You Need to Know - certification and audit context from certification-assessment perspective.