On this page
- Is security awareness training required for SOC 2?
- What should SOC 2 security awareness training cover?
- How often should SOC 2 training happen?
- What evidence should you retain for the auditor?
- How an auditor tests the training control
- How do you prove the training was understood?
- Security awareness training software is optional
- Training gaps that commonly create exceptions
- An audit-ready training checklist
SOC 2 security awareness training teaches personnel how to follow your security policies and gives the auditor evidence that the training control operated. A defensible program maps primarily to CC1.4 and CC2.2, covers all in-scope personnel, defines its own cadence, and retains completion and comprehension records.
SOC 2 does not prescribe one course, software platform, quiz score, 30-day onboarding deadline, or annual training date. Your organization defines a control that fits its risks. The auditor then tests whether the control is suitably designed and whether you followed it throughout the review period.
At minimum, keep a complete personnel roster, the course version each person received, assignment and completion dates, assessment results, policy acknowledgments, and records of overdue-training follow-up.
Is security awareness training required for SOC 2?
A SOC 2 organization generally needs a security awareness control because the Trust Services Criteria require competent personnel and effective internal communication. The criteria are outcomes to satisfy, not a fixed AICPA training syllabus. Your control design determines the exact audience, timing, content, and evidence.

The primary mapping is:
| Trust Services Criterion | What it addresses | How training supports it |
|---|---|---|
| CC1.4 — commitment to competence | The organization develops and retains people with the competence needed to meet its objectives. | General and role-based training give personnel the security knowledge required for their duties. |
| CC2.2 — internal communication | The organization communicates information needed to support internal control responsibilities. | Training explains security policies, expected behavior, reporting routes, and each person’s responsibilities. |
Use the AICPA’s 2017 Trust Services Criteria with revised points of focus (2022) as the canonical criteria source. Your auditor may map the same training control to additional criteria when the content supports a scoped risk, but CC1.4 and CC2.2 are the clearest starting points.
The distinction between a criterion and a control matters. The AICPA defines the outcome. You might implement it through onboarding training, an annual refresher, role-based modules, policy acknowledgments, and short updates after material incidents. Those are your controls and procedures, not a universal AICPA checklist.
For the wider framework, see what SOC 2 compliance requires.
What should SOC 2 security awareness training cover?
SOC 2 security awareness training should cover the security decisions every worker makes and add role-specific material for higher-risk duties. The curriculum should match your policies, systems, data, risk assessment, and reporting process rather than rely on a generic compliance course alone.

An all-personnel module commonly covers:
- recognizing and reporting phishing, impersonation, suspicious links, and unexpected requests
- password-manager use, multi-factor authentication, credential handling, and account recovery
- data classification, approved storage and sharing tools, and secure disposal
- acceptable use of company devices, remote-work practices, and physical security
- incident reporting: what to report, where to report it, and what information to include
- the security policies each person must acknowledge and follow
Role-based training should follow actual access and authority:
| Audience | Add these topics | Evidence to retain |
|---|---|---|
| Engineering and administrators | Secure coding (OWASP Top 10), secrets, privileged access, production data, change management, and incident escalation | Assigned module, completion record, assessment result, and course version |
| Sales and marketing | CRM data handling, customer-data volume on laptops and phones, and the risk of untrusted Wi-Fi and public networks | Completion record plus acknowledgment of the data-handling and device policy |
| Finance and executives | Business email compromise, payment-change verification, wire approvals, and executive impersonation | Scenario or module completion plus acknowledgment of the approval procedure |
| Support and customer success | Identity verification, account recovery, data exports, and social-engineering escalation | Completion record and evidence that the support procedure was communicated |
| HR and people operations | Personnel data, onboarding and offboarding, background checks, and insider-risk reporting | Completion record tied to the current personnel-security procedures |
The training page should not become a complete phishing-defense manual. Use the SOC 2 phishing and social engineering guide for attack scenarios, simulations, and the technical and procedural controls that sit around employee training.
How often should SOC 2 training happen?
SOC 2 does not set a universal training frequency. Define a cadence that covers new personnel, recurring reinforcement, role changes, and material events; write that cadence into the control; then retain dated evidence that every required session occurred on time.
A practical control calendar has four triggers:
| Trigger | Defensible control design | Evidence |
|---|---|---|
| Joining the organization | Assign baseline training before in-scope access where practical, or within a documented onboarding deadline. | Start date, assignment date, completion date, and access date if the control links training to access |
| Recurring cycle | Run a full refresher on the frequency stated in policy; annual training is common, but it is not an AICPA-mandated interval. | Population report for each cycle, overdue list, and management review |
| Role or access change | Assign role-based training before privileged or higher-risk duties begin. | Role-change date, module assignment, completion, and approval |
| Material event | Update or repeat relevant content after a major policy change, system change, incident, audit finding, or new threat. | Dated update, audience, delivery record, and revised content version |
Do not write a control that your workflow cannot meet. If the policy says every new hire completes training within 30 days, a completion on day 31 is a deviation even though SOC 2 itself did not choose the 30-day deadline. A tighter promise creates a tighter audit test.
NIST SP 800-171r3 section 3.2 provides a useful implementation benchmark: initial training, an organization-defined recurring frequency, updates after defined events, and role-based training before relevant access or duties. NIST is not the SOC 2 standard, but this event-based model helps teams write a control that stays current.
For phishing specifically, CISA advises against relying on annual training alone. Regular reminders and a known reporting route reinforce the full course between cycles.
What evidence should you retain for the auditor?
Retain evidence for control design, population completeness, delivery, comprehension, and exceptions. A completion certificate proves one person finished one module; it does not prove that every in-scope employee and contractor received the right training by the deadline.

Prepare this evidence packet:
| Evidence artifact | Minimum useful fields or contents | What it helps prove |
|---|---|---|
| Approved training policy or control narrative | Owner, audience, timing, required content, completion deadline, escalation path, and review frequency | The control is defined and assigned |
| Versioned training materials | Course title, version, publication date, topics, and linked policy versions | The delivered content matched the control and current policies |
| In-scope population | Employees and contractors, unique identifier, role, start date, end date, and access status | The completion report can be tested for completeness |
| Assignment and completion log | Person, role, module, assigned date, due date, completion date, status, and next due date | Required training occurred on schedule |
| Comprehension record | Assessment score, pass threshold, attempts, pass date, and retraining where applicable | Personnel demonstrated the knowledge your control says they must acquire |
| Policy acknowledgments | Person, policy version, acknowledgment date, and method | Required policies were communicated and accepted |
| Exception and escalation log | Overdue person, reason, manager, escalation date, corrective action, and closure date | Deviations were identified and resolved |
| Optional behavior evidence | Simulation date, audience, reporting rate, failure outcome, and follow-up assignment | The program tests or reinforces behavior over time |
Export the source records when possible. A dashboard screenshot may show a completion percentage, but a row-level report lets the auditor reconcile the training population to HR or identity records and select a sample.
Store the evidence by audit period and preserve the version actually used. Replacing last year’s slide deck with the current version removes the evidence needed to show what personnel learned during the earlier part of a Type 2 period. The broader SOC 2 documentation guide explains how this training packet fits with policies, procedures, and evidence from other controls.
How an auditor tests the training control
An auditor typically compares your stated control to a complete personnel population, checks that required training occurred within the defined cadence, and inspects sampled records. The exact sample and procedure depend on the auditor, population, control frequency, risk, and report period.
A typical test follows this sequence:
- Read the control language. The auditor identifies who must train, which modules apply, the deadline, the frequency, and what happens when someone is late.
- Obtain an independent population. HRIS, contractor, and identity records establish who was in scope rather than relying only on the LMS list.
- Reconcile the population to the completion export. Missing contractors, recent hires, terminated workers, duplicate accounts, and blank completion dates become visible here.
- Select samples. The auditor traces sampled workers to assignment dates, completion dates, assessment results, acknowledgments, and the training version delivered.
- Test event-driven operation. New hires, role changes, policy revisions, or incidents may require separate evidence under your control language.
- Inspect deviations. Late or failed training should have a documented escalation, corrective action, and closure.
This is why a “100% complete” dashboard can still fail testing. The LMS may show 100% of enrolled users while the HRIS shows two contractors who were never enrolled. The control failed at the population boundary, not inside the training platform.
For the fieldwork process across other controls, use the SOC 2 audit checklist.
How do you prove the training was understood?
Use separate evidence for completion, comprehension, and behavior. Completion shows attendance, an assessment shows whether the learner understood the material, and simulations or incident-reporting data can show how personnel respond. SOC 2 does not impose one universal passing score or phishing target.
| Measure | What it answers | Sensible follow-up |
|---|---|---|
| Completion status | Did each in-scope person finish by the control deadline? | Escalate overdue assignments and document closure |
| Quiz or knowledge check | Did the learner understand the required concepts? | Set an internal passing threshold and require a retest or targeted module after failure |
| Scenario exercise | Can the person apply the procedure to a realistic request? | Record the scenario, participants, result, and corrective action |
| Phishing simulation | Did personnel click, submit data, or report the test message? | Assign focused retraining and compare results across comparable campaigns |
| Incident-reporting records | Do personnel use the reporting route in real operations? | Review response quality and update training when recurring confusion appears |
KnowBe4’s 2026 Phishing by Industry Benchmarking Report, published 7 July 2026, analyzed 42 million simulated phishing tests across 14.8 million users at 64,000 organizations. The global baseline Phish-prone Percentage before training was 33.2%. Organizations running ongoing training saw that fall to 20.1% at 90 days and 4.2% after twelve months (KnowBe4 press release, 7 July 2026; report landing page). Treat those figures as an industry reference point from a vendor-published dataset, not as a SOC 2 target. Auditors test the cadence and follow-up your control promises, not whether you hit 4.2%.
Choose metrics that match the control. If your control promises only annual completion, the auditor may not test simulation improvement. If it promises quarterly simulations and remedial training after failures, both the campaign records and the follow-up assignments become part of the test.
Avoid arbitrary success claims. A lower click rate or higher report rate can support a behavior-change narrative, but campaign difficulty, audience, sample size, and delivery conditions affect the comparison. Preserve the raw campaign reports and compare like with like.
Security awareness training software is optional
No specific security awareness platform is required for SOC 2. You need a reliable way to assign training, preserve the correct content version, track the complete population, record results, and export evidence. Software is useful when it makes those jobs more dependable.
An LMS or training platform should earn its place by supporting:
- HRIS or identity-system synchronization for employees and contractors
- role-based assignments and event-driven enrollment
- immutable or controlled completion records
- assessment scores, retakes, reminders, and escalation
- content-version history and policy acknowledgments
- row-level exports for the full audit period
None of the prices below is a SOC 2 requirement. They are planning bands so you can budget a delivery method. SOC 2 tests whether your control operated; it does not prescribe software.
| Delivery method | Published cost | Retrieved | Notes |
|---|---|---|---|
| KnowBe4 SAT (list) | Foundation $1.63/user/month and Advanced $2.79/user/month at 501–1,000 seats on a 3-year term (about $20–$33/user/year). Smaller seat bands list higher. | May 2026 list, KnowBe4 pricing | Unlimited phishing tests are included in SAT. Quote-based above 1,000 seats. |
| Other LMS / SAT platforms | Quote-based. The KnowBe4 list is a reference point, not a market ceiling. | 13 August 2026 | Same evidence job: assignment, versioning, completion export. |
| Live instruction | No license line. External facilitators are quote-based. | — | Useful for high-risk roles; pair with an LMS for the completion log. |
| Standalone phishing tools | Often bundled with the LMS. | — | Relevant only when the control promises simulations. |
A controlled spreadsheet and live-session attendance records can work for a small population. Manual tracking becomes weak when enrollment is incomplete, versions are unclear, corrections are unrecorded, or the roster cannot be reconciled to the personnel population.
Choose software for the evidence workflow, not for a “SOC 2 compliant” label. A vendor cannot make the organization compliant by itself; the organization still owns the scope, cadence, content, follow-up, and evidence.
Training gaps that commonly create exceptions
Training exceptions usually come from a mismatch between the written control and the retained evidence. Missing people, late completion, unversioned content, and undocumented follow-up are easier for an auditor to identify than broad arguments about whether a course was engaging.
Check these failure points before fieldwork:
- Contractors are absent from the LMS. If contractors can access in-scope systems or data, decide whether the control includes them and make the population match.
- The onboarding deadline is not measured. Keep both the start date and completion date; a completion date alone cannot prove timeliness.
- The course content does not match current policies. Version the course and update it after material policy or system changes.
- Role-based training is assigned by department name alone. Base assignments on actual duties and access, especially privileged administration, payment approval, support recovery, and customer-data handling.
- Failed assessments have no disposition. Record retraining, retesting, manager escalation, or an approved exception.
- A simulation is promised but not run. Remove unsupported control language or execute and retain every scheduled campaign.
- The completion report is not reconciled. Compare LMS users with HRIS, contractor, and access records before handing the population to the auditor.
An audit-ready training checklist
An audit-ready training control has a defined owner, audience, curriculum, cadence, evidence schema, and exception process. It also produces records that can be reconciled to an independent personnel population and traced to the course version delivered during the audit period.
Before fieldwork, confirm:
- The control maps to CC1.4 and CC2.2 in your control matrix.
- The policy names all in-scope employees, contractors, and role-based audiences.
- Onboarding, recurring, role-change, and event-driven triggers are defined.
- Training content matches current security, data-handling, access, and incident-reporting policies.
- The HRIS or access population reconciles to the assignment and completion log.
- Every sampled record has assignment, due, completion, and assessment data where required.
- Policy acknowledgments and training versions are retained for the full audit period.
- Overdue, failed, or missed training has an owner, escalation, and documented closure.
- Optional simulations and behavior metrics are retained only when they are actually part of the control.
If the evidence does not support the wording, fix the workflow or narrow the control before the observation period begins. During a Type 2 examination, the auditor tests what the organization said it would do and what the records show it did.
Need an auditor who can test this control without turning the evidence request into guesswork? Compare SOC 2 auditors, timelines, and pricing based on your scope and company profile.