SOC 2 security awareness training requirements

SOC 2 does not prescribe a course or a frequency, but auditors test whether staff are trained on their security responsibilities and whether the records prove it. This page explains the criteria, the evidence and how to run training on a self-hosted platform.

On this page

What SOC 2 requires for security awareness training

When a customer or contract asks for a SOC 2 report and your training evidence is missing or scattered, the gap is usually not the training itself but the proof that it happened. SOC 2 sets no fixed course, no minimum number of hours and no required frequency. Instead, your organization must show through its own controls that personnel are made aware of their security responsibilities, and that your records prove who was trained, on what and when. The program is yours to design and run. Only the independent CPA firm that examines you issues the report, and it will test whether your program works as you describe it.

The expectation comes mainly from two common criteria. CC2.2 asks how the organization communicates information needed for internal control, including responsibilities, incident reporting methods and security awareness information. CC1.4 asks how the organization develops and retains competent people, including training to maintain technical competencies. The points of focus under these criteria, drawn from the AICPA's 2017 Trust Services Criteria, describe characteristics that help you design and evaluate the control. They are not separate requirements, so you do not have to address every one, but you should be able to explain which ones your program covers and why. If privacy is in scope, the privacy points of focus on CC2.2 add expectations about privacy knowledge and awareness, so your curriculum and records should reflect that category too.

Start by deciding what your written training control promises: the audience (employees, contractors and any other personnel with system access), the topics, the triggers for initial and recurring training, and who reviews completion. Then decide what the auditor will sample. Typically that means a list of personnel in the period, with a completion record for each, and evidence that overdue learners were followed up. Confirm with your CPA firm how it expects to sample records and over what period, because a training program that exists only in a policy document will not survive testing. If a cloud or hosting provider's shared responsibility model assigns awareness and training to both parties, confirm which part of the program is yours to evidence.

Training content for different audiences

Every employee needs a baseline of security awareness that matches the organization's policies and its reporting channels. Under CC2.2, the points of focus expect staff to know their responsibilities, how to report incidents, and the system objectives and boundaries that affect their daily work. If privacy is in scope, the same baseline also covers privacy awareness, such as how personal information should be handled and who to contact about a concern. The content is generic enough for non-technical roles, so it should focus on recognizing phishing, handling customer data, using approved tools, and reporting suspected events quickly.

  • Responsibilities: Explain what each employee must do under the information security policy and what they must not do.
  • Reporting paths: Name the channel, the mailbox or form, and the escalation contact for suspected incidents.
  • Data handling: Cover classification labels, approved storage locations and the rules for sharing customer information.
  • Social engineering: Show common phishing and pretexting patterns and the verification step expected before acting on a request.
  • Privacy content: Add it only when privacy is in scope, and record that decision in the training policy.

Check that the training policy lists every employee group covered by the all-staff track, and that the content version and date are recorded for each assignment.

Adding privacy awareness when privacy is in scope

Privacy awareness is an add-on, not a default. The CC2.2 points of focus that talk about communicating information to improve privacy knowledge and awareness apply only when the privacy category is in scope for your examination. If privacy is out of scope, your security awareness record stands on its own and you do not need a separate privacy module to pass. If privacy is in scope, the auditor will expect the training program to reach the people who handle personal information and to show that they were told what their privacy duties are.

Privacy content differs from security content in what it teaches. Security training covers passwords, phishing, reporting incidents and handling devices. Privacy training covers the commitments in your privacy notice, when personal information may be collected, used, retained, disclosed or deleted, how customers exercise their rights, and who to contact when a request or a possible disclosure arises. Many organizations write a short privacy module for support, sales, engineering and data-handling roles, then add it to the same learning platform so that completion is recorded per learner and per module. Tailor the content to the roles that touch personal data rather than repeating the full company-wide course for everyone.

The in-scope decision changes the training record in two ways. First, the completion log must show the privacy module as a distinct item with its own assignment, date and learner list, so the auditor can match it to the privacy commitments in your system description. Second, you need a documented rule for who must take it and how new joiners and role changes are handled. Confirm with your CPA firm, before fieldwork starts, whether privacy is in scope, which privacy criteria apply, and what evidence they will sample. Ask them to state this in writing so the scope decision is not reopened during testing.

How to set up a training program the auditor can test

This sequence turns the awareness expectations behind CC1.4 and CC2.2 into a program with a named owner, defined audience, course content, completion rules and records that an auditor can sample across the examination period. Each step ends with an output you can show the auditor.

  1. Define the audience and scope

    Start by listing everyone who must complete training: employees, contractors, and any vendor staff who access systems or data in scope. Map each group to the system boundary in your system description, and note whether privacy is in scope, since the privacy points of focus under CC2.2 apply only then. The output is a written population list that matches your personnel records, so the auditor can test completeness by comparing it to the HR roster and the access list.

  2. Assign a named program owner

    Name one accountable owner, usually in security or compliance, with a deputy for coverage. The owner approves course content, sets the completion rules, reviews overdue reports and signs off the annual review. The output is a documented role assignment, referenced in the information security policy and the training procedure, that shows management has allocated responsibility for communicating security awareness.

  3. Author or import course content

    Moodle does not ship security awareness content, so your team must author courses or import material it has licensed or written. Cover the topics your own policies and risks call for, such as phishing, handling customer data, reporting incidents, and secure use of company accounts. Keep a versioned copy of each course with its date and approver. The output is a content inventory that shows what each audience was taught and when that material changed.

  4. Set completion rules on the platform

    Configure the course so completion is recorded on a condition you can defend, such as a graded quiz with a pass mark or a required activity view with a tick-off. Moodle's activity completion marks an activity complete when a learner views it, receives a grade, or ticks it manually, depending on the conditions you set, so choose the condition deliberately and document it. The output is a written completion standard that the auditor can read against the recorded completions.

  5. Collect and retain completion records

    Export completion reports on a regular schedule and store them in your evidence repository with the course version, learner name, date and the score or completion condition. Confirm that the records survive platform upgrades and backups, since auditors sample completions across the period. The output is a complete, time-stamped record set per audience that you can produce on request without manual reconstruction.

  6. Follow up on overdue learners

    Run a recurring report of people who have not completed required training by the due date set in your policy, and escalate to their manager and the program owner. Record each reminder, exception and approved extension, and note who approved it. Access restrictions for non-completers, if you use them, should be documented as well. The output is a follow-up log that shows overdue items were chased and closed, which is often what an auditor tests when a sample includes a late completion.

  7. Review the program each cycle

    At the end of each cycle, review the audience list, course content, completion rules and the follow-up log against changes in personnel, systems and risks. Record decisions, update the content, and confirm with the independent auditor which evidence periods they expect to test. The output is a signed review memo with its supporting changes, which shows the program is maintained rather than set once and forgotten.

Which completion records auditors sample

A service auditor testing security awareness training does not take the training program on trust. They pick learners and periods, then ask for the records that show who was trained, when, on what content, and what happened to anyone who fell behind. The cards below cover the six records most often sampled and how to keep each one unaltered.

Enrollment roster for the period

The roster lists every person in scope for training during the examination period, including employees, contractors and any vendor staff with system access. Auditors compare it against the HR and identity records to confirm nobody with access was left out. Export it from the source system with a timestamp, and keep the export logic so you can explain how the population was built. Check that people who joined or left mid-period appear with their start and end dates.

Completion dates within the period

Each sampled learner needs a completion date that falls inside the audit window. Auditors check that training was finished before or soon after access was granted, and that refresher completions happen at the interval your own policy sets. Record the completion timestamp from the learning platform, not a date typed into a spreadsheet. A date that falls outside the period, or a missing one, becomes an exception the auditor must report.

Course version and content

A completion only proves something if the auditor can see what the learner completed. Keep each course version with its identifier, publication date and the slides, modules or quiz questions it contained. When the content changes, such as new phishing examples or a revised reporting procedure, retain the prior version so older completions remain explainable. Confirm how your platform stores course history, because many systems overwrite content in place unless you export it.

Assessment and attestation results

Many programs test knowledge with a quiz or ask learners to acknowledge the security policy. Auditors sample these results to confirm that completion reflects understanding or an explicit acknowledgment, not just a click through. Keep the score, the pass threshold, the number of attempts and the signed or recorded acknowledgment. If your platform marks a course complete on viewing alone, state that in your description so the auditor does not assume a test was passed.

Follow-up on overdue learners

Auditors look for what happens after a learner misses a deadline. Keep the overdue report generated during the period, the reminders sent, the escalations to managers, and the date access was restricted or the learner was completed. Show the chain from detection to resolution for a sample of overdue cases. Without this trail, a roster with gaps reads as a control that was never monitored.

New-hire training timing

For each sampled new joiner, the auditor compares the start date with the completion date of initial training. Your policy should state the window the organization commits to, and the records must show whether that window was met. Store the joiner's start date from the identity or HR system alongside the training timestamp so the comparison can be reproduced. Confirm your own window with your auditor before the period begins, since it becomes the standard you are tested against.

Running training on a self-hosted learning platform

A self-hosted learning platform can produce the completion records a SOC 2 auditor samples, but only if its completion settings match the training policy you wrote. Moodle is a useful example because it is licensed under the GPL-3.0-or-later and runs inside your own infrastructure. Its activity completion feature marks an activity complete for each learner when they view it, when they receive a grade from it, or when they tick it manually, depending on the conditions you set for that activity. A page view is not the same as understanding the material, so decide which trigger your policy requires before any learner starts the course. A course that completes on view will show full completion even if nobody read past the first slide.

Moodle does not ship security awareness content, so the course itself must be authored in-house, imported from a vendor, or built from material your organization is licensed to use. Your team owns that content and must be able to show the auditor which version was live during the period, when it changed, and who approved the change. Map each module to the topics your policy names, such as phishing, credential handling and incident reporting, so the auditor can trace policy to course to completion. Where you include privacy content because the privacy category is in scope, keep it in a separate module so its records can be pulled on their own.

Before relying on the platform for evidence, confirm two things in your own environment. First, review the license terms with your counsel and the version you deploy, including any third-party plugins, because the GPL terms attach to the software you distribute and do not settle your content licensing. Second, run a test course and export the completion report, then check that it shows learner name, course, completion date, trigger and the record of any manual ticks. If the export cannot show those fields, plan a supplementary report from the database or a documented procedure, and agree the format with your auditor before fieldwork begins.

What usually makes training fail the audit

Most training findings in a SOC 2 examination do not come from a lack of courses. They come from records that cannot be tied back to people, policies and the system, so the auditor cannot tell whether training happened as described. The six pitfalls below are the ones that tend to surface when auditors sample completion records.

No written training policy

Auditors look for a documented rule that says who must train, on what topics, how often and what happens when someone misses a deadline. Without it, the training program has no stated design to test against, and each completion looks like an ad hoc event. Check that the policy names the audience, the refresher cycle, the topics tied to your system and policies, and the owner who reviews completion. Confirm the policy has been approved and dated within the examination period.

Completion records not tied to a roster

A learning platform report showing that some people finished a course proves little unless it is matched to the current list of workforce members in scope. Auditors ask for the population first, then check whether every sampled person appears with a completion date. Reconcile the training export against the identity provider or HR roster each cycle, and record anyone who was in scope but has no completion. Explain how contractors and departed staff are handled.

Course content that does not match the system

Generic awareness modules rarely mention your ticketing process, your approved channels for sharing data, or the incident reporting route your policies describe. An auditor comparing the course to the information security policy may find that staff were trained on procedures the organization does not use. Map each course topic to a policy or control, update content when the system or policy changes, and keep the version history so the sampled course matches the period under test.

Gaps for contractors and vendor staff

Teams often train employees and forget people with production access who sit outside the payroll, such as contractors, consultants and staff at a managed service provider. If those individuals can reach the system, the auditor may ask how their awareness was established and evidenced. Decide which external people are in scope, require training or an equivalent acknowledgement through the contract, and keep their records alongside employee records so the population is complete.

Missed new-hire training

Training that only runs as an annual campaign leaves people who joined mid-cycle untrained for months. Auditors sampling new joiners during the period look for completion before or shortly after system access was granted, and a gap there becomes an exception. Tie the course assignment to the onboarding workflow so enrollment happens on the start date, and define a deadline for completion. Check the joiner sample against the first training completion date.

Manual edits to exported records

Spreadsheets that are retyped, filtered or patched by hand before they reach the auditor undermine the evidence, even when the underlying training happened. An auditor who finds dates or names that do not match the system export may widen testing or question the completeness of the whole population. Export records directly from the learning platform with timestamps, keep the raw file unchanged, and document any transformation, such as joining to the roster, in a separate step that can be re-performed.

Common questions about SOC 2 training

Does SOC 2 require a specific training course or a fixed frequency?

No. SOC 2 does not name a course, a vendor, a number of hours or a fixed refresh interval. The relevant criteria are CC1.4 on competence and CC2.2 on communicating information to personnel, including security awareness information. Each organization designs its own program and sets its own frequency, then follows it. Auditors test whether the program exists, whether it reaches the people it should, and whether the organization does what it wrote down. A common approach is onboarding training for new staff plus a recurring refresher, but the cadence you choose is the one you must prove you kept. Confirm the frequency your auditor expects for your scope before you commit to a schedule.

Is privacy awareness training required for SOC 2?

Only when the privacy category is in scope. The Trust Services Criteria add privacy points of focus under CC2.2 about communicating information to improve privacy knowledge and awareness. If your report covers privacy, your training should address how staff handle personal information, including collection, use, retention, disposal and disclosure. If privacy is out of scope, those privacy points do not apply, though many organizations still include basic data handling guidance. Your scope decision, made with your auditor, determines this answer.

Must contractors and vendor staff complete the same training?

SOC 2 does not list contractors by name, but the criteria apply to personnel who work within the system in scope, and auditors generally expect contractors with system access to be covered. The practical question is what each group can reach. Contractors with production or customer data access should complete training equivalent to employees, with records kept the same way. Vendor staff who operate parts of your system may fall under their own provider's report, which you review through your vendor management process. Document the population you decided to cover and why, so an auditor can compare that decision with your access records.

How much effort does a SOC 2 training program take, and what drives it?

No supplied figure exists for effort, so the honest answer is that the workload depends on your inputs. The main drivers are headcount, how often people change roles, how many distinct groups need tailored content (engineering, support, finance, privacy-sensitive teams), whether you author content yourself or buy it, and how much manual tracking you do. Costs fall into one-time work (choosing or building content, configuring the learning platform, writing the policy) and recurring work (refreshers, new hire enrollment, updates after incidents, and collecting completion records for each audit period). Ask any provider for a written breakdown of which parts are one-time and which recur.

Can our own team run SOC 2 security awareness training without outside help?

Yes, many organizations do. SOC 2 has no requirement to hire a consultant for training, and the organization owns its controls and its program. The work that usually needs skills you may not have in-house is authoring content that matches your systems, configuring a learning platform, and building a reporting routine that produces clean records. Moodle, for example, does not ship security awareness content, so courses must be written or imported, and its activity completion features need to be configured so that completion means what your policy says. An implementation partner such as DeployOpen can prepare and host a self-hosted platform, build courses and set up records inside your infrastructure, but the training program remains yours and only an independent auditor issues the report.

What will the auditor ask to see for security awareness training?

Expect the auditor to ask for the written program, the training content, and a population of completion records to sample. Typical requests include the list of personnel in scope during the audit period, evidence that new hires completed training after joining, evidence that refreshers happened on your chosen schedule, and proof of follow-up for people who did not complete it. Completion records should come from the system of record, with dates and user identifiers, not from a manually edited spreadsheet. Auditors may also ask how you handle exceptions and whether management reviews completion rates. Prepare a sample-ready export before fieldwork begins.

How do we prove training completion on a self-hosted learning platform?

Use the platform's own completion tracking and keep exports that show who completed what and when. In Moodle, activity completion can be set to mark an activity complete when a learner views it, when they receive a grade from it, or when they tick it manually, so pick the condition that matches your evidence need and document it. A quiz with a passing grade gives stronger evidence than a manual tick. Store exports in your evidence repository on a schedule, and confirm that the platform's logs and backups are covered by your retention rules. Confirm the exact completion settings with your platform team and your auditor before the audit period starts.

How DeployOpen prepares training systems and evidence

DeployOpen plans, builds and documents self-hosted learning platforms inside your own infrastructure so that security awareness training can be run, recorded and sampled cleanly. We prepare the systems and evidence; your organization owns its controls, and only an independent CPA firm issues the SOC 2 report.

How we scope

  • Engagements are fixed-scope, with the training audience, courses, platform and deliverables agreed in writing before work starts.
  • The written scope states which criteria the training supports, such as CC1.4 and CC2.2, and whether privacy awareness is included.
  • We confirm with your auditor which completion records and sample populations they expect before configuration begins.

How we build

  • We deploy and harden the learning platform in your cloud account, data center or air-gapped network under your access controls.
  • Courses are authored or imported to match your policies, and completion rules are configured so records reflect real completion.
  • Enrollment feeds from your identity provider so that joiners and leavers appear in the training population automatically.

How we hand over

  • You receive documentation of the platform configuration, course inventory, enrollment logic and completion reporting steps.
  • We provide a sample evidence pack that shows how a completion record can be exported, dated and tied to a named employee.
  • Runbooks explain who reviews overdue learners, how exceptions are escalated and how records are retained for the audit period.

How we support

  • Ongoing support, upgrades and maintenance of the learning platform are available as a retainer after handover.
  • Retainers can cover course refreshes, annual content updates and periodic checks that the completion records still export correctly.
  • Your auditor, not DeployOpen, decides whether the training program and its records meet the criteria under examination.

Sources and further reading

Talk to our team.

Tell us what you're working on, whether it's a deployment, an audit, a security test or a cyber range. You'll speak with an engineer who can help you scope it.

  • 30-minute call: free, with no obligation.
  • NDA on request: we can sign before you share details.
  • Clear next steps: a scope and plan after the call.