Requirement
Requirement lens
This control is not only annual awareness training. It requires appropriate awareness, education, training, and regular updates based on job function and relevant policies/procedures.
“Personnel of the organization and relevant interested parties shall receive appropriate information security awareness, education and training and regular updates of the organization’s information security policy, topic-specific policies and procedures, as relevant for their job function.”
Plain-language meaning
People need to know how to behave securely in their actual role. Everyone needs baseline awareness, but people with specific responsibilities need deeper training that matches their work, systems, information access, and security duties.
Training should happen early enough to be useful, should be repeated when needed, and should be updated when threats, policies, procedures, systems, roles, or incidents change.
Why this matters
Untrained personnel make avoidable mistakes. They may mishandle information, use systems incorrectly, ignore procedures, fall for social engineering, corrupt data, lose information, or bypass controls because they do not understand the risk.
Training is also a control enabler. Policies, procedures, access rules, incident reporting, classification, acceptable use, privacy, and supplier rules are weak if people do not understand them.
Implementation guidance
Implementer focus
Build training into the personnel lifecycle: onboarding, role change, privileged access, policy update, incident lessons learned, and periodic refresh.
1. Define training audiences
Start by identifying who needs training and why.
| Audience | Training need |
|---|---|
| All employees | Basic security awareness, policy expectations, incident reporting, acceptable use |
| Contractors and third-party users | Relevant policy, confidentiality, acceptable use, reporting, data handling |
| Managers | Management responsibilities, enforcement, team awareness, non-compliance handling |
| Privileged users and administrators | Secure administration, authentication, logging, change, incident response |
| HR, legal, procurement, finance | Role-specific handling, privacy, fraud, contractual and supplier security obligations |
| Developers and project teams | Secure design, project security requirements, evidence, change control |
| Senior management | ISMS responsibilities, risk, governance, management review inputs |
The training plan should reflect job function and security responsibility. Generic annual slides are not enough for specialist roles.
2. Separate awareness, education, and training
Use the distinction deliberately.
| Term | Practical meaning | Example |
|---|---|---|
| Awareness | Keeps security expectations visible | Phishing reminders, policy updates, posters, short briefings |
| Education | Builds understanding of concepts | Why classification matters, how risk treatment works |
| Training | Builds role-specific capability | How to handle incidents, administer systems securely, classify records, use secure transfer tools |
This helps avoid the weak answer “we sent everyone a security email.”
3. Build a training plan
The plan should define:
- required training by role;
- mandatory induction topics;
- supplementary training for specialist responsibilities;
- timing before access or before performing high-risk tasks;
- refresher frequency;
- trigger events for updates;
- internal or external provider approval;
- competence requirements for trainers;
- evidence records and metrics.
Training can be internal, external, classroom-based, online, practical, conference-based, or on-the-job, but informal training still needs a defined scope and record.
4. Keep training current and usable
Training should be reviewed and updated when:
- policies or procedures change;
- new threats emerge;
- incidents or audit findings show knowledge gaps;
- systems, tools, or information processing practices change;
- personnel move into new roles;
- legal, regulatory, or contractual requirements change.
Training that reflects the organization’s actual culture, tools, incidents, and work patterns is stronger than generic content.
5. Measure effectiveness
Do not treat attendance as the only success metric.
Useful measures include:
- completion rate by role and department;
- assessment scores;
- phishing simulation results where appropriate;
- incident and near-miss trends;
- audit findings linked to awareness gaps;
- feedback from trainees and managers;
- practical exercise outcomes;
- overdue training items.
Metrics should drive improvement. If incidents show repeated mistakes, the training plan should change.
6. Record training in individual records
Training records should show:
- person or role;
- training title and scope;
- date completed;
- provider or trainer;
- result or assessment score where applicable;
- next refresher date;
- evidence location;
- exceptions or equivalent competence claims.
Claims of prior experience or existing qualifications can be acceptable, but they should be current, relevant, and verified, especially for key roles.
Audit guidance
Auditor focus
Test appropriateness, timing, records, currency, and effectiveness. A completion report alone does not prove training is suitable for the role.
Auditors should verify that training is appropriate to job function, security responsibilities, and access to information or services.
Audit testing should include:
- training policy, plan, and role-based training matrix;
- induction training records for employees, contractors, and third-party users;
- supplementary training for people with specialist security responsibilities;
- samples showing training was completed before access or before work requiring the skill;
- training material currency and alignment to current policies/procedures;
- trainer or supplier competence and approval;
- individual training records and assessment results;
- interviews with randomly selected personnel;
- evidence that training effectiveness is reviewed and improved;
- links between incidents, audit findings, feedback, and training updates.
The auditor should challenge training that is generic, stale, undocumented, or not provided until after people already perform the role.
Evidence examples
Evidence quality
Strong evidence proves that the right people received the right training at the right time, understood it, and that the program improves over time.
| Evidence | What it proves |
|---|---|
| Security awareness and training policy | Training expectations are defined |
| Role-based training matrix | Training is matched to job function and responsibility |
| Training plan or calendar | Training is planned and repeated |
| Induction training records | Baseline awareness is provided before work/access |
| Specialist training records | Higher-risk roles receive deeper training |
| Training materials and version history | Content is current and aligned to policy |
| Assessment results | Understanding is tested |
| Attendance and completion reports | Training delivery is tracked |
| Training supplier approval | External provider suitability is assessed |
| Incident-to-training update record | Lessons learned feed awareness content |
| Training effectiveness metrics | Program performance is reviewed |
Strong evidence
- Training matrix covers employees, contractors, third-party users, managers, administrators, and specialist roles.
- Induction training is completed before access to information or services.
- Training content references current policies, topic-specific policies, procedures, and real organizational examples.
- Specialist roles have supplementary training plans.
- Individual records show completion, date, scope, trainer/provider, and assessment where applicable.
- Training effectiveness is measured and reviewed.
- Incidents, audit findings, and emerging threats lead to updated training.
- Equivalent experience or qualifications are verified rather than accepted from CV claims alone.
Weak evidence
- Annual generic security video with no role-specific training.
- Attendance list with no content, date, version, or assessment.
- Contractors and third-party users excluded.
- Training happens after system access is granted.
- Training material is stale or inconsistent with current policy.
- No evidence that managers or privileged users receive supplementary training.
- No review of training effectiveness.
- Prior experience is accepted without verification.
Common failures
Implementation watchouts
Training fails when it is treated as HR administration instead of an operational security control.
| Failure | Why it matters |
|---|---|
| One-size-fits-all training | Specialist roles remain underprepared |
| Training after access | People can make mistakes before they know the rules |
| No contractor coverage | Non-employees can mishandle information or systems |
| No content version control | Auditors cannot prove training matched current policy |
| Attendance-only evidence | Completion does not prove understanding or suitability |
| No effectiveness review | Repeated mistakes do not improve the program |
| No trigger-based refresh | Training becomes stale after policy, system, or threat changes |
| Unverified competence claims | Key roles may be staffed by people whose skills were never validated |
Exam traps
Exam focus
A.6.3 is broader than awareness. It includes awareness, education, training, and regular updates relevant to job function.
| Trap | Correct interpretation |
|---|---|
| Annual awareness training is enough | Training should be appropriate to role, responsibility, and current procedures |
| Only employees need training | Contractors, third-party users, and relevant interested parties can be in scope |
| Attendance proves competence | Stronger evidence includes content, timing, assessment, role fit, and effectiveness review |
| Technical staff do not need policy training | Administrators, managers, application users, and technical staff all need relevant training |
| Prior experience always replaces training | Experience or qualifications should be current, relevant, and verified |
| Training only happens during onboarding | Refreshers and updates are needed when risks, policies, procedures, systems, or roles change |
Related controls and concepts
- A.6 People Controls MOC
- A.6.1 Screening
- A.6.2 Terms and Conditions of Employment
- Information Security Policy
- Roles and Responsibilities
- Management Responsibilities
- A.5.10 Acceptable Use of Information and Other Associated Assets
- A.5.12 Classification of Information
- A.5.24 Information Security Incident Management Planning and Preparation
- A.5.27 Learning from Information Security Incidents
- A.5.34 Privacy and Protection of PII
- Internal Audit
- Management Review
- Security Awareness and Training Plan
- Role-Based Security Training Matrix
- Security Training Record
- A.6.3 Audit Evidence Pack
- A.6.3 Audit Checklist
KB-ready summary
- A.6.3 requires appropriate awareness, education, training, and regular updates.
- Training should match job function, access, responsibilities, and current policies/procedures.
- Everyone needs baseline awareness; specialist roles need supplementary training.
- Contractors, third-party users, and relevant interested parties can be in scope.
- Training should be delivered before access or before the relevant work is performed.
- Records should show what was taught, to whom, when, by whom, and with what result.
- Training effectiveness should be measured and improved using feedback, incidents, audit findings, and changing threats.
Templates and checklists
- Iso27001
- Iso27002
- Annex a
- People controls
- Awareness
- Training
- Education
- Audit
Note Metadata
Aliases: A.6.3, Information Security Awareness Education and Training, Security Awareness Training
Source: 03 Annex A People Controls/A.6.3 Information Security Awareness Education and Training.md
Control dependency map
How this control connects to work products
Generated from the static research graph. It shows navigation and evidence dependencies; it is not an audit conclusion.
10
links
Requirement context
Primary control text, framework notes, or adjacent controls this note points to.
Implementation artifacts
Templates and working records that help operate the control.
Evidence required
Evidence packs and proof records that support auditability.
Audit checks
Audit questions, checklists, or review material connected to the control.
Graph-sourced resources
Templates and evidence
Implementer templates
Working artifacts for control owners and operators.
Auditor evidence packs
Evidence collections and audit-facing verification material.
Related Notes
- Internal Audit
- Management Review
- Roles and Responsibilities
- ISO 27001 A.5.1 - Policies for Information Security
- ISO 27001 A.5.10 - Acceptable Use of Information and Other Associated Assets
- ISO 27001 A.5.12 - Classification of Information
- ISO 27001 A.5.24 - Information Security Incident Management Planning and Preparation
- ISO 27001 A.5.27 - Learning from Information Security Incidents
- ISO 27001 A.5.34 - Privacy and Protection of PII
- ISO 27001 A.5.4 - Management Responsibilities
- ISO 27001 A.6.1 - Screening
- ISO 27001 A.6.2 - Terms and Conditions of Employment
- ISO 27001 A.6.4 - Disciplinary Process
- ISO 27001 A.6.7 - Remote Working
- ISO 27001 A.6.8 - Information Security Event Reporting
- A.6 People Controls MOC
- A.6.3 Audit Evidence Pack
- AQ-ISO27001-A.6.3 Information Security Awareness, Education and Training
- ISO 27001 A.8.12 - Data Leakage Prevention
- ISO 27001 A.8.23 - Web Filtering
- ISO 27001 A.8.7 - Protection Against Malware
- A.6 People Controls Implementation Guide
- A.6 People Controls Audit Guide
- ISO27001-A.6.3 Information Security Awareness, Education and Training
- A.6 People Controls Implementation Audit Risk Mapping
- EXAM-017 - Awareness, Education and Training
- ISO 27002 Annex A Control Interpretation Map
- A.6.3 Audit Checklist
- Developer Security Training Matrix
- Malware Awareness Checklist
- Malware Protection Standard
- Role-Based Security Training Matrix
- Security Awareness and Training Plan
- Security Training Record
- Annex A Controls MOC