Your SOC 2 auditor asks to see your security awareness training records. You pull up a shared folder with one video from two years ago, no completion log, and half the team hasn’t even watched it. That’s not a training programme. That’s a checkbox somebody forgot to check.
A security awareness training policy is the document that turns ad hoc training into a structured, auditable programme. It defines who must complete training, how often, on what topics, and what happens if they don’t. It assigns ownership, sets a review cadence, and gives you the paper trail auditors expect to see.
Without it, training happens whenever someone remembers to send a link. With it, training is a controlled, documented, enforceable process that satisfies SOC 2, ISO 27001, HIPAA, and NIST requirements.
Every major security framework treats this as a required control:
- SOC 2: CC1.4 and CC9.2 require demonstrated workforce training on security responsibilities
- ISO 27001: Annex A 6.3 mandates security awareness, education, and training for all relevant personnel
- HIPAA: 164.308(a)(5) requires a formal security awareness and training programme for all workforce members
- NIST 800-53: The AT control family (AT-1 through AT-4) covers training policy, delivery, role-based requirements, and record-keeping
- PCI DSS: Requirement 12.6 mandates a formal security awareness programme with annual training
By the end of this guide, you’ll know exactly what to put in your security awareness training policy, how to roll it out, and what evidence to keep so you’re never caught flat-footed in an audit.
Here’s what I’ll cover:
- What a security awareness training policy is and what it must include
- A free, ready-to-use policy template
- How to roll it out and collect the right evidence
- How it maps to SOC 2, ISO 27001, HIPAA, and NIST
- What auditors actually check for
- Common mistakes that trip up compliance programmes
What Is a Security Awareness Training Policy?
Most companies have some form of security training. A phishing simulation here, an annual video there, a Notion page nobody reads. The problem isn’t that they’re not doing training. It’s that none of it is governed.
A security awareness training policy is a formal document that governs how your organisation trains employees to recognise and respond to security threats. It mandates training frequency, defines the topics that must be covered, specifies who delivers it, and sets consequences for non-completion.
It is not the training itself. The policy is the governing document. The training programme is the delivery mechanism.
A security awareness and training policy is sometimes written as a security training and awareness policy. Different names, same document. What matters is that it exists, it’s approved, it’s communicated, and people actually follow it.
Security Awareness Training Policy Definition
A useful security awareness training policy definition covers three dimensions: (1) what it mandates (training requirements and topics), (2) who is responsible (ownership and enforcement), and (3) what it produces (records and evidence). Every other clause in the policy supports one of those three.
The core elements are:
- Mandatory training requirements: who must complete training, by when, and how often
- Topic coverage: the minimum subjects all employees must be trained on
- Role-based requirements: additional training for high-risk roles (developers, finance, HR, IT)
- Phishing simulation requirements: frequency, follow-up process, escalation
- Acknowledgement process: how employees confirm they’ve completed training
- Enforcement: what happens if someone doesn’t complete training on time
- Record-keeping: what documentation must be maintained and for how long
Who Owns the Security Awareness Training Policy?
The CISO or Head of Security typically owns this policy. They approve the training content, set the curriculum, and are accountable for completion rates.
HR co-owns the enforcement side: integrating training into onboarding, tracking completion across the organisation, and escalating non-compliance. This makes the security awareness training policy a natural companion to your HR security policy.
For companies without a dedicated CISO, the IT lead or a senior engineer usually takes ownership. The exact title matters less than the fact that someone is accountable.
What an Information Security Awareness Training Policy Actually Covers
An information security awareness training policy defines the minimum topics that all employees must be trained on. The list should include:
- Phishing and social engineering: recognising and reporting suspicious emails, links, and calls
- Password hygiene: strong passwords, password managers, avoiding reuse
- Multi-factor authentication: why it’s required and how to use it
- Data classification and handling: what counts as sensitive data and how to treat it
- Incident reporting: what to do and who to contact when something looks wrong
- Remote work security: VPN requirements, home network risks, unattended devices
- Physical security: clean desk policy, tailgating, screen locks
- Acceptable use: what company systems can and cannot be used for
Role-based modules layer on top of this for high-risk functions. More on that in Section 5.
Why Security Awareness Training Policies Reduce Real Risk
Here’s a number worth knowing: 74% of data breaches involve a human element, according to Verizon’s 2024 DBIR. Not a misconfigured firewall. Not an unpatched server. A person clicking something they shouldn’t have, or handing over credentials because someone asked nicely.
Security controls can stop a lot. They can’t stop an employee who doesn’t know what a phishing email looks like.
The purpose of security awareness training policy is to change that. A well-run training programme creates a workforce that recognises threats and knows what to do when they see one. That’s not just a compliance checkbox. It’s one of the most cost-effective security controls available.
The compliance angle matters too. Every major audit framework treats training as a required control, not a recommended one. ISO 27001 auditors will ask for training records. SOC 2 auditors will ask for completion logs and acknowledgements. HIPAA investigators will look for evidence that all workforce members received training before accessing systems containing protected health information. If you can’t produce those records, you have a finding.
The operational argument is simpler: without a policy, training happens inconsistently. Some teams do it, some don’t. New hires sometimes get trained in week one, sometimes in month six. There’s no standard, no record, and no way to prove anything was done. A policy fixes that by making training a controlled, repeatable process.
The Business Cost of Skipping Security Awareness Training
I’ve talked to founders who skipped formal training programmes to move faster, then watched their SOC 2 audit drag on for months because auditors kept flagging the gap. Training isn’t just a risk control. It’s a trust signal.
Enterprise customers ask about it in security questionnaires. Auditors check for it before issuing Type II reports. HIPAA enforcement actions regularly cite insufficient training as a contributing factor in breach investigations.
The average cost of a data breach is over $4 million (IBM, 2024). A KnowBe4 licence for a 20-person company costs less than $500 a year. The maths isn’t complicated.
Which Companies Need a Security Awareness Training Policy?
If any of the following apply to you, you need this policy:
- You’re pursuing SOC 2, ISO 27001, HIPAA, or PCI DSS certification
- Your customers ask for evidence of security training in vendor questionnaires
- You handle sensitive customer data, financial records, or health information
- You have contractors or third-party vendors with access to your systems
- You have remote employees or a distributed team
That’s most companies with any meaningful security footprint. The frameworks make it mandatory. The business risk makes it sensible. If you’re selling to enterprise, you’ll be asked about it before the deal closes.
Is This Policy Required Before You Start an Audit?
For SOC 2 and ISO 27001: yes. Training must be in place and documented before your audit period begins. Auditors don’t just check that you have a policy. They check that training actually happened, that completion was tracked, and that acknowledgements were collected, across the entire audit period.
For HIPAA: required before any workforce member accesses systems containing PHI. This isn’t a suggestion. It’s in the regulation.
For NIST 800-53: required for federal contractors. Strongly recommended for everyone else, and increasingly expected in enterprise vendor assessments.
Does Company Size Change the Requirement?
No. The control applies regardless of headcount. What changes is the depth and delivery method.
A 5-person startup needs a simple policy, an annual training video, a completion log, and quarterly phishing simulations. That’s enough to satisfy SOC 2.
A 200-person company needs role-based tracks, a proper LMS, automated reminders, monthly phishing simulations, and board-level reporting on completion rates.
The requirement is the same. The implementation scales to your stage.
Key Functions and What Your Security Awareness Training Policy Should Cover
Take any security awareness training policy from a well-run company and you’ll find the same core structure underneath. The specifics vary. The skeleton doesn’t.
Security Awareness Training Policy Key Functions
Before getting into the table, it’s worth naming the key functions of a security awareness training policy clearly:
- Define the mandate: who must complete training and by when
- Set the curriculum: what topics training must cover
- Establish role-based requirements: additional training for high-risk functions
- Govern phishing simulations: frequency, failure handling, escalation
- Require acknowledgements: documented confirmation that training was completed
- Specify enforcement: consequences for non-completion
- Set the review cadence: when and why the policy gets updated
Every section of the policy supports one of these functions. If a section doesn’t serve one of them, it probably shouldn’t be there.
| Policy section | What to include |
|---|---|
| Purpose | Why the policy exists and what it aims to prevent: reducing human-layer security risk and meeting framework training requirements |
| Scope | All full-time employees, part-time employees, contractors, consultants, and third parties with access to company systems or data |
| Roles and responsibilities | Policy owner (CISO), enforcement owner (HR), managers (team completion), all employees (completing training and reporting threats) |
| Training requirements | Onboarding training within 30 days of hire; annual refresher for all staff; role-based modules for high-risk functions |
| Training topics | Phishing, social engineering, passwords, MFA, data classification, incident reporting, remote work, physical security, acceptable use |
| Phishing simulations | At least quarterly; targeted follow-up training for failures; repeated failures escalated to manager |
| Acknowledgement | Completion confirmed via LMS attestation or signed form; records retained for 2-3 years |
| Exceptions | Written request to CISO and HR; documented and time-limited; requires alternative control |
| Enforcement | Access suspension for overdue training; written warning from HR; escalation for repeated failures |
| Review cadence | Annual review minimum; also triggered by major incidents, regulatory changes, or significant changes to systems or workforce |
| Records | Training completion logs, phishing simulation results, acknowledgement records, exception approvals |
Role-Based Training Requirements
Baseline training applies to everyone. Role-based training applies to anyone whose job function creates additional risk.
| Role | Additional Training Required |
|---|---|
| Developers and engineers | Secure coding practices, OWASP Top 10, secrets management, code review security |
| Finance and HR | Business email compromise (BEC), wire fraud recognition, sensitive data handling |
| IT and security | Incident response procedures, privilege escalation awareness, threat detection |
| Executives and board | Social engineering targeting senior leadership, data governance responsibilities |
Role-based modules don’t need to be elaborate. A focused 30-minute module on secure coding is more useful than a 4-hour generic training that developers tune out.
Onboarding vs. Annual vs. Role-Based Training
These three tracks have different triggers and different purposes.
Onboarding training fires when someone joins. Complete it within 30 days of start date, before accessing systems containing sensitive data. It covers all baseline topics and establishes the expectation that security is everyone’s responsibility from day one.
Annual training is the recurring refresh. All staff, same deadline (usually 30 days from assignment), updated content reflecting any new threats or policy changes from the past year. This is the one that appears in your completion logs for auditors.
Role-based training is triggered by job function or access change. When a developer joins, they get the secure coding module. When someone moves into a finance role, they get the BEC module. When access is elevated, training should follow.
Free Security Awareness Training Policy Template
You can pull a generic security awareness training policy template off the internet in five minutes. The problem is that generic templates don’t pass audits: they have the right headers but the wrong substance, and the substance is what auditors read.
This security awareness training policy template is pre-populated with best-practice content. Replace the bracketed fields with your company’s specifics. Everything else is ready to use.
Also available as a downloadable security awareness training policy pdf below, pre-formatted for SOC 2 and ISO 27001 evidence packages. This same document works as a cyber security awareness training policy template for companies whose primary threat landscape is internet-facing: add the relevant role-based modules for your engineering team and you’re covered.
Security Awareness Training Policy Example and Sample Clauses
The following security awareness training policy example shows what a complete, audit-ready document looks like. Adapt it to your organisation before use.
Security Awareness Training Policy
[Company Name] Version: 1.0 Effective Date: [Date] Last Reviewed: [Date] Next Review Date: [Date + 1 year] Policy Owner: [CISO / Head of Security / IT Lead]
1. Purpose
This policy establishes mandatory requirements for security awareness training at [Company Name]. Its purpose is to ensure all personnel can recognise and respond to security threats, protect company and customer data, and meet the training requirements of applicable compliance frameworks including SOC 2, ISO 27001, and HIPAA.
Security incidents caused by human error, including phishing, credential compromise, and data mishandling, represent the most common and preventable category of breach. This policy addresses that risk through structured, documented, and enforced training.
2. Scope
This policy applies to all individuals with access to [Company Name] systems, data, or facilities:
| Category | In Scope |
|---|---|
| Full-time employees | Yes |
| Part-time employees | Yes |
| Contractors and consultants | Yes |
| Temporary staff and interns | Yes |
| Third-party vendors with system access | Yes |
| Board members with system access | Yes |
3. Roles and Responsibilities
| Role | Responsibility |
|---|---|
| CISO / Head of Security | Owns this policy; approves training curriculum; reviews completion data; escalates systemic non-compliance |
| HR | Coordinates onboarding training; tracks completion for all employees; issues warnings for overdue training |
| Managers and team leads | Ensure direct reports complete training within required timeframes; escalate persistent non-compliance |
| IT team | Maintains training platform; manages phishing simulation tool; provides completion reports |
| All employees and contractors | Complete all assigned training on time; report suspicious activity to the security team |
4. Training Requirements
4.1 Onboarding Training
All new employees, contractors, and personnel with access to company systems must complete security awareness training within 30 days of their start date. Access to systems containing sensitive data may be restricted until onboarding training is complete.
4.2 Annual Refresher Training
All in-scope personnel must complete annual security awareness training. Training is assigned at the start of each calendar year and must be completed within 30 days of assignment. The curriculum is reviewed and updated annually to reflect current threats and any policy changes.
4.3 Role-Based Training
Personnel in high-risk roles must complete additional training modules relevant to their function:
| Role | Module | Frequency |
|---|---|---|
| Developers and engineers | Secure coding, OWASP Top 10, secrets management | Annual |
| Finance and HR | BEC and wire fraud recognition, sensitive data handling | Annual |
| IT and security | Incident response, privilege escalation awareness | Annual |
| Executives | Social engineering targeting senior leadership | Annual |
Role-based training is assigned by HR in coordination with the CISO when a new hire joins or when an employee changes role.
4.4 Phishing Simulations
[Company Name] conducts simulated phishing exercises at a minimum of once per quarter. Simulations are designed to reflect current phishing tactics and may target specific departments.
Employees who fail a simulation (click a link or submit credentials) will be automatically assigned a targeted phishing awareness module and must complete it within 14 days. Repeated failures within a 12-month period will be escalated to the employee’s manager and HR for further action.
Phishing simulation results are retained for audit purposes and reviewed quarterly by the CISO.
5. Training Topics
All security awareness training programmes must cover, at minimum:
| Topic | What It Covers |
|---|---|
| Phishing and social engineering | Recognising suspicious emails, links, attachments, and phone calls; internal reporting procedure |
| Password hygiene | Strong password requirements; use of password managers; prohibition on password reuse |
| Multi-factor authentication | Why MFA is required; how to use it; what to do if an MFA prompt arrives unexpectedly |
| Data classification and handling | What counts as confidential or sensitive data; how to store, share, and dispose of it |
| Incident reporting | How to recognise a potential incident; who to contact; what information to provide |
| Remote work security | VPN usage; home network risks; device encryption; screen lock requirements |
| Physical security | Clean desk policy; tailgating prevention; screen privacy in public spaces |
| Acceptable use | Permitted and prohibited uses of company systems, devices, and networks |
Training content is reviewed annually and updated to reflect the current threat landscape and any changes to company policy.
6. Acknowledgement
All employees must acknowledge completion of each training module via [LMS platform / signed acknowledgement form]. Acknowledgement records are retained for a minimum of three years and made available to auditors on request.
For onboarding training, acknowledgement is required before access to sensitive systems is granted.
7. Non-Compliance
Failure to complete mandatory training within the required timeframe will result in progressive enforcement:
| Stage | Action |
|---|---|
| 7 days overdue | Automated reminder sent by LMS; manager notified |
| 14 days overdue | Access to sensitive systems may be suspended until training is complete |
| 30 days overdue | Written warning issued by HR; documented in employee record |
| Repeated non-compliance | Escalation to department head and CISO; further disciplinary action per HR policy |
A significant violation of this policy includes: repeated failure to complete mandatory training, deliberately circumventing phishing simulations, and failure to report a known security incident.
8. Exceptions
Exceptions to training requirements (for example, extended medical leave or parental leave) must be submitted in writing to the CISO and HR before the training deadline. Approved exceptions must document:
- The reason for the exception
- The duration and expiry date
- An alternative control or compensating measure where applicable
- The name of the approving manager and CISO
Exceptions are reviewed quarterly and closed when the individual returns to active status.
9. Review and Updates
This policy is reviewed annually by the policy owner. It is also reviewed and updated in response to:
- A security incident involving a human-layer failure (phishing, social engineering, credential compromise)
- Changes to applicable compliance frameworks or regulations
- Significant changes to company systems, workforce, or risk profile
- Results of phishing simulations indicating systemic gaps in employee awareness
10. Version History
| Version | Date | Author | Summary of Changes |
|---|---|---|---|
| 1.0 | [Date] | [Name] | Initial policy |
How to Write and Roll Out Your Security Awareness Training Policy
Writing the policy is the easy part. Rolling it out is where most companies stumble: the policy gets approved, sits in a folder, and nobody completes the training that was supposed to follow.
Here’s a step-by-step process that actually works.
Assign ownership. Name the CISO or IT lead as policy owner. Name HR as co-owner for enforcement. Both need to sign off before you communicate anything.
Choose your training platform. For early-stage companies: KnowBe4 or Curricula work well and include phishing simulation tools. For very small teams, a recorded video plus a Google Form acknowledgement is an acceptable starting point. Pick something that generates a completion report you can export.
Draft the policy. Use the template above. Customise training frequency, role-based module list, and consequences to match your context. Keep the language plain. This document will be read by engineers and sales reps, not just your security team.
Get executive approval. CEO or COO sign-off. Document it. This establishes the tone that training is not optional.
Communicate to all staff. Send via email and your internal comms channel. Include the deadline, a link to the training, and the reason it matters. One message from a leader lands better than three messages from IT.
Track completion weekly. Pull a completion report from your LMS every week until the deadline. Flag overdue employees to their managers. Don’t wait until the deadline to find out 40% of the team hasn’t done it.
Run your first phishing simulation. Within 60 days of launch. Use the results to identify gaps and assign targeted follow-up training. Don’t punish people for failing the first one: use it to calibrate.
Collect acknowledgements. LMS attestation works. Signed forms work. What doesn’t work is assuming people have read the policy because you sent a link.
Map to your control library. Update your SOC 2 or ISO 27001 controls to reference this policy. SOC 2 CC1.4 and CC9.2, ISO 27001 A.6.3, HIPAA 164.308(a)(5). This is what connects the policy to your audit evidence.
Store evidence centrally. Completion logs, simulation results, acknowledgements, and exception records all go in one place: your GRC tool or a dedicated folder in your document management system.
Schedule the annual review. Calendar reminder for 12 months from approval date. Review the policy, update training content if needed, and confirm the platform and process still reflect how you actually work.
SOC 2, ISO 27001, HIPAA, and NIST Framework Requirements
Security awareness training is one of the few controls that appears in almost every major framework. The requirements differ in specifics but not in intent: train your people, document it, and prove it happened.
| Framework | Control Reference | What It Requires |
|---|---|---|
| SOC 2 | CC1.4, CC9.2 | Training on security responsibilities; demonstrated workforce competence in security practices |
| ISO 27001 | Annex A 6.3 | Awareness, education, and training for all relevant personnel; regularly updated |
| HIPAA | 164.308(a)(5)(i) | Security awareness and training programme for all workforce members |
| NIST 800-53 | AT-2, AT-3, AT-4 | Literacy training for all users; role-based training for high-privilege staff; training records |
| PCI DSS | Req. 12.6 | Formal security awareness programme; training at hire and at least annually |
ISO 27001 Security Awareness Training Policy: What Annex A 6.3 Requires
ISO 27001 Annex A 6.3 (updated in the 2022 revision) requires that all personnel receive appropriate awareness education and training, plus regular updates aligned to company policies and procedures relevant to their job function.
That last part is important: training must be tailored. Generic phishing videos satisfy the letter of the requirement but not the spirit. A developer’s training should cover secure coding. A finance team’s training should cover wire fraud. Auditors increasingly ask to see role-based tracks, not just a single company-wide video.
Evidence ISO 27001 auditors will ask for: training records showing completion dates and topics, acknowledgement logs, and documentation showing the curriculum was reviewed and updated within the past year.
NIST Security Awareness and Training Policy: The AT Control Family
The NIST 800-53 AT control family covers security awareness and training in four controls:
- AT-1: Policy and procedures for security awareness and training. A documented policy is required.
- AT-2: Literacy training and awareness. Mandatory for all system users. Must cover recognising and reporting threats, and be completed within a defined timeframe of onboarding and annually thereafter.
- AT-3: Role-based training. Required for personnel with elevated privileges, security responsibilities, or access to sensitive systems. Content must be tailored to role.
- AT-4: Training records. Completion records must be retained and available for review.
NIST-aligned training requirements are also referenced in FedRAMP (for cloud providers serving the US federal government) and CMMC (for defence contractors).
SOC 2 Auditor Expectations
SOC 2 auditors don’t just check that you have a training policy. They verify that training actually happened, across the entire audit period.
What they’ll ask for:
- The signed, approved policy document
- Training completion reports from your LMS, covering all in-scope employees for the audit period
- Evidence that new hires completed onboarding training within the required timeframe
- Phishing simulation results (quarterly, at minimum)
- Signed acknowledgements or LMS attestation
- Role-based training logs for high-risk functions
The most common SOC 2 finding on this control: the policy exists, training happened once, but completion logs are incomplete or acknowledgements were never collected. Don’t let the last step be the one that fails you.
What Auditors Actually Check for Security Awareness Training
The policy gets you to the room. The evidence is what keeps you in it.
Every auditor I’ve spoken with says the same thing about security training: the documentation is almost always the weak point. Not the training itself. The records.
Here’s exactly what auditors expect to see:
| Record type | What it looks like |
|---|---|
| Approved policy document | Final version with policy owner, approver, effective date, and review date visible |
| Training completion log | LMS report showing employee name, training module, completion date, and pass/fail status for all in-scope staff |
| Onboarding training records | Evidence showing new hires completed training within the required window (usually 30 days) |
| Phishing simulation results | Quarterly reports showing: simulation date, employees targeted, click rate, follow-up training assigned |
| Acknowledgement records | LMS attestation or signed forms per employee, per training cycle |
| Role-based training completion | Separate completion log showing module names and completion dates for each high-risk role |
| Policy review history | Evidence of annual review: who reviewed it, what changed, who approved the update |
| Exception records | Documented approved exceptions: reason, duration, alternative control, approver |
One practical note: most LMS platforms export all of this automatically. If yours doesn’t, build the reporting process before your audit period starts. Trying to reconstruct records after the fact is how findings happen.
Common Security Awareness Training Policy Mistakes (and How to Avoid Them)
Security awareness training is one of those controls that looks easy on paper and falls apart in practice. Here are the mistakes I see most often, and what to do instead.
Treating training as a one-time checkbox. Completing training in month one and never running it again doesn’t satisfy SOC 2 or ISO 27001. Annual training is the minimum. If you can’t show a completion log for the entire audit period, you’ll get a finding.
No completion tracking. Sharing a Loom link in Slack isn’t training. It’s a link. If you can’t produce a completion report showing who watched what and when, auditors have nothing to verify. Use an LMS, even a basic one.
Excluding contractors and third parties. The policy must cover anyone with access to your systems, not just full-time employees. Contractors who aren’t trained are a gap. Auditors will ask about them specifically.
No consequences for non-completion. A policy that says training is mandatory but has no enforcement mechanism isn’t really mandatory. Build the escalation process before launch: automated reminders, manager notification, access suspension for persistent non-completers.
Generic training not tailored to your threat profile. A team of 15 engineers faces different threats than a 200-person company with a large sales force. Phishing looks different. Social engineering looks different. Role-based modules exist for a reason. Use them.
Skipping phishing simulations. The policy should mandate simulations, not just classroom-style training. SOC 2 and ISO 27001 auditors increasingly expect evidence of simulations. More practically: simulations are the only way to know if training is working.
Not updating the policy after incidents. If your company had a phishing incident and your training programme still looks exactly the same, auditors will question whether you learned anything. Update the policy and curriculum after significant security events.
Storing acknowledgements informally. A shared spreadsheet with names ticked off is not audit evidence. Use your LMS attestation records or a document management system with version control. Acknowledgement records are the proof that employees actually received the training.
Right-Sizing Your Security Awareness Training Policy for Your Company Stage
The same control applies at every stage. The implementation looks very different.
Early-Stage Startups (1–20 employees)
Keep it simple. A one-page policy covering purpose, scope, training requirements, acknowledgement, and consequences is enough to satisfy most auditors at this stage.
For delivery: an annual training video from KnowBe4, Curricula, or a similar platform covers the baseline. Most of these tools include phishing simulation capabilities and generate the completion reports you’ll need for SOC 2.
For tracking: your LMS completion report is the record. Export it quarterly and store it alongside your policy.
Phishing simulations: quarterly. Most LMS platforms include this. For very small teams, even a simple simulation with a free tool works as a starting point.
Cost at this scale: most LMS platforms run $3-6 per user per month. For a 10-person team, that’s less than a single hour of engineer time.
Growing Companies (20–100 employees)
At this stage, the policy needs more structure. Add role-based modules for developers, finance, and HR. Build the training programme into your onboarding workflow so new hires can’t slip through.
Use a dedicated LMS with automated reminders, manager reporting, and a proper completion dashboard. The manual tracking that worked at 15 people breaks at 50.
Phishing simulations: quarterly, with targeted follow-up training for failures. Track your click rate over time. If it’s not improving, your training content needs to change.
Map your training policy to SOC 2 or ISO 27001 controls explicitly. When auditors ask for evidence of CC1.4, you should be able to pull completion logs and acknowledgements within minutes.
Larger Companies (100+ employees)
At this scale, the policy becomes more granular. Department-specific annexes help when different functions face materially different risks. Contractor training requirements may need a separate addendum if you work with a large number of external vendors.
Your LMS should support SCORM content, role-based tracks, and automated escalation for overdue training. Completion metrics get reported to the board or security committee annually.
Phishing simulations move to monthly for high-risk departments. Track not just click rate but mean time to report: how quickly do employees flag suspicious emails to the security team?
At this stage, your training policy is also an input to your vendor management process. Customers will ask about it in security questionnaires. Make sure whoever handles those requests knows where the records live.
Managing Your Security Awareness Training Policy with ComplyJet
Drafting the policy is one afternoon of work. Keeping it audit-ready over 12 months is where the effort actually lives: tracking completions, collecting acknowledgements, updating content after incidents, filing evidence, and remembering to review it before the next audit cycle.
ComplyJet handles the operational side of this.
The policy comes pre-built, mapped to SOC 2 CC1.4, CC9.2, ISO 27001 A.6.3, and HIPAA 164.308(a)(5). You customise it, get it approved, and it’s live with a full version history attached.
Acknowledgement collection happens inside ComplyJet: employees receive a prompt, confirm they’ve read the policy, and the record is stored automatically. No spreadsheet, no chasing people.
When auditors ask for evidence, you pull a report rather than assembling records from four different tools. Completion logs, acknowledgements, review history, and control mapping are all in one place.
Annual review reminders fire before the policy goes stale. If you update the policy mid-year because of an incident, the new version goes through an approval workflow and the previous version is archived.
Frequently Asked Questions
How do you define a security awareness training policy?
A security awareness training policy is a formal document that governs how your organisation trains employees to recognise and respond to security threats. It defines who must complete training, how often, on what topics, and what happens if they don’t. It’s the governing document for your training programme, not the training itself. Without it, training happens inconsistently and there’s no evidence trail for auditors.
What should a security awareness training policy include?
At minimum: purpose and scope, who must complete training, training frequency (onboarding plus annual), a list of required topics, phishing simulation requirements, an acknowledgement process, consequences for non-completion, and a review schedule. Role-based training requirements for high-risk functions should also be included. See Section 5 for the full table.
How often should security awareness training be conducted?
Annual training is the minimum required by most frameworks. Best practice is: onboarding training within 30 days of hire, annual refresher for all staff, quarterly phishing simulations, and role-based modules assigned by job function or when access levels change. More frequent simulations are better than less frequent, especially in the first year of your programme.
Does SOC 2 require a security awareness training policy?
Yes. SOC 2 CC1.4 and CC9.2 require that the organisation demonstrates workforce training on security responsibilities. Auditors check for the policy document, training completion records covering the full audit period, phishing simulation results, and signed acknowledgements. A policy that exists on paper but isn’t evidenced by records doesn’t satisfy the control.
What does ISO 27001 require for security awareness training?
ISO 27001 Annex A 6.3 requires all relevant personnel to receive appropriate security awareness, education, and training, with regular updates. The 2022 revision emphasises that training must be tailored to job function and updated to reflect the current threat landscape. Evidence required: training records, completion logs, and documentation showing the curriculum was reviewed within the past year.
Is security awareness training required for HIPAA compliance?
Yes. HIPAA Security Rule 164.308(a)(5) explicitly requires covered entities and business associates to implement a security awareness and training programme for all workforce members. This applies to anyone who accesses systems containing PHI. The requirement predates meaningful HIPAA enforcement and is checked in every investigation following a breach.
Who is responsible for the security awareness training policy?
The CISO or Head of Security owns the policy and is accountable for the training curriculum, completion rates, and audit evidence. HR co-owns enforcement: integrating training into onboarding, tracking completion, and escalating non-compliance. For companies without a dedicated CISO, the IT lead or a designated security owner takes the policy owner role.
What evidence do auditors ask for when reviewing security awareness training?
Auditors typically ask for: the signed policy document with effective date, LMS completion reports covering all employees for the audit period, onboarding training records showing the 30-day window was met, phishing simulation results for the past 12 months, signed acknowledgements or LMS attestation per employee per cycle, role-based training logs, and evidence of the most recent annual policy review. Missing any of these is a common finding.
Related Policies
HR Security Policy: Covers the full employee security lifecycle: background checks, onboarding security requirements, and offboarding procedures. Security awareness training is one component of a broader HR security programme.
Information Security Policy: The parent policy that governs all information security controls across the organisation. The security awareness training policy sits beneath it and is referenced within it.
Personnel Security Policy: Defines security obligations for all staff throughout their employment. Training completion is a core personnel security requirement, alongside background checks and acceptable use agreements.
Password Policy: Password hygiene is one of the core topics covered in security awareness training. The password policy sets the specific requirements (length, complexity, reuse rules) that training teaches employees to follow.






