Most SOC 2 readiness guides describe security awareness training as a single line item. In practice, auditors sampling that control look at roughly ten distinct pieces of evidence. A training program that has nine of them and misses one usually still passes, but only after a back and forth exchange that extends the audit timeline by a week or two. The checklist below is what we wish we had when we went through our first audit, written as the specific questions auditors tend to ask, with notes on what "passing" evidence looks like for each.
This is written for engineering-heavy teams preparing for a Type I or Type II audit under the 2017 Trust Services Criteria (TSC), which AICPA continues to reference as the current framework in its 2022 revision notes.
TL;DR
- The TSC text actually requires very little. The auditor's interpretation of that text is where most of the work lives.
- Auditors sample a subset of users rather than reviewing everyone. Sample sizes vary by firm and by control frequency, so plan as if any in-scope user could be sampled: everyone needs a clean record.
- The five pieces of evidence that matter most are: a named policy, a dated roster, per-user completion records, curriculum that maps to your risks, and a new-hire process.
- The two pieces of evidence that are nice to have but not strictly required are signed attestations and a comprehension check (quiz).
- The three common failure modes are: contractors omitted from the roster, new hires who completed training months after joining, and a curriculum that doesn't mention anything specific to how your product actually works.
The checklist
1. A named, dated security training policy
What the auditor asks: "Can you show me your security awareness training policy?"
What passing looks like: A document, ideally committed to a version-controlled policy repository (Vanta, Drata, Secureframe, or a self-managed GitHub repo), that names the program, defines who is in scope, specifies the required cadence, and describes the evidence retention approach. Must have an effective date and a review date within the last twelve months.
Common gotcha: The policy mentions "annual security training" but doesn't say which content counts as training. When the auditor asks "annual training of what?" and the answer is vague, that usually triggers follow up sampling.
2. A current list of everyone in scope
What the auditor asks: "Can you show me the roster of individuals subject to the training policy?"
What passing looks like: A dated spreadsheet or system export listing every full-time employee, part-time employee, and contractor who has logical access to production systems, customer data, or the development pipeline. Pulled within the last 30 days, with clear start dates.
Common gotcha: Contractors, especially offshore developers working under agency contracts, get left off the list. Auditors specifically look for this because it's a known gap pattern. If you use Deel, Remote.com, or a similar EOR platform, export from there in addition to your HRIS.
3. Per-user completion records for the current period
What the auditor asks: "For these five users I'm sampling, can you show me they completed training in the current reporting period?"
What passing looks like: A record per user that includes the user's name or employee ID, the course or curriculum completed, the completion date, and ideally a score or pass/fail indicator. The date must fall inside the reporting period for Type II or before the audit date for Type I.
Common gotcha: The training platform has the data but the audit trail doesn't survive an export. A PDF dated six months after the fact looks suspicious even when it isn't. A system-generated export with timestamps or an API-pulled CSV is strongly preferred.
4. Curriculum that maps to the organization's actual risks
What the auditor asks: "How did you decide what topics to include in the curriculum?"
What passing looks like: A mapping document (even a one-page table) showing how training topics map to the organization's risk assessment or threat model. For engineering-heavy teams, this typically means OWASP-aligned topics plus general security awareness (phishing, data handling, incident reporting).
Common gotcha: The curriculum is generic enough that it could apply to any company. Auditors under SOC 2 don't flag this as a fail, but in ISO 27001 audits under Annex A.6.3, the specificity requirement is explicit: the content must be appropriate to the "job function and role." If you're pursuing both certifications, specificity matters more than you might expect.
5. A new-hire training process
What the auditor asks: "For this employee hired in May, when did they complete training?"
What passing looks like: A documented onboarding process that includes security training within a specific window of hire. The AICPA doesn't mandate a window; your own policy sets it. Strong policies require training before production access is granted; softer policies allow 30 to 90 days post-hire. Evidence for any new hires during the reporting period: their completion date must fall inside whichever window you've committed to in writing.
Common gotcha: A policy says "within 30 days of hire" but the most recent hire completed training on day 62 because onboarding was chaotic. Auditors will note this as a control deviation. The fix is usually to either (a) extend the policy to 90 days, which most auditors accept, or (b) add a reminder to the onboarding checklist.
6. A refresh cadence you actually follow
What the auditor asks: "Your policy says annual training. Can you show me that this person completed it in both 2025 and 2026?"
What passing looks like: Two consecutive years of completion records for at least a sample of employees who have been with the company that long. For shorter-tenured startups, evidence that the training was offered before a cycle could plausibly have elapsed.
Common gotcha: The first year's training rolled out smoothly and then the program went dormant. The second year's records show completions in the three weeks before the audit, all at once. Auditors notice the timing pattern. A rolling refresh (by anniversary date, for example) looks more natural and is easier to maintain.
7. Evidence retention policy
What the auditor asks: "How long do you retain training records?"
What passing looks like: A stated retention period (commonly three to seven years) in the security training policy or a parent records-retention policy. For Type II audits, records need to cover the full reporting period plus the previous year for comparison.
Common gotcha: Training completed in a third-party LMS that you later stopped paying for. If the vendor expired the account, the records are gone. Export training completion records to your own storage (S3, Google Drive, the auditor-readable policy repo) quarterly, regardless of how trustworthy the LMS seems.
8. A method for tracking exceptions
What the auditor asks: "What happens when someone doesn't complete training on time?"
What passing looks like: A documented escalation path (typically manager notification after a set number of days, then HR involvement, then access revocation) and a log of any exceptions granted during the reporting period. For most startups, the log is empty, which is fine. What isn't fine is not having the policy at all.
Common gotcha: A former employee was terminated mid-period and never completed their annual training. Auditors want to see that either the training was completed before termination or that their access was revoked in a timely way. The intersection of "offboarding" and "training" is a sampling target.
9. (Optional but helpful) A comprehension check
What the auditor asks: Usually nothing directly. The comprehension check comes up as a credibility signal rather than a requirement.
What passing looks like: A quiz, exam, or scored exercise with a minimum passing threshold (70 percent is common) and evidence that users who didn't pass on the first attempt retook until they did.
Common gotcha: This is not required by the TSC. Some auditors have started treating it as an implicit expectation, but we've seen plenty of clean audits without it. The case for including it: it strengthens your evidence story if an auditor pushes back, and it meaningfully improves actual outcomes. The case against: it's extra operational overhead for programs that already feel tight.
10. (Optional but increasingly common) Signed attestations
What the auditor asks: Occasionally: "Do you have evidence that employees acknowledged the training?"
What passing looks like: A signed document or system-generated attestation per user, timestamped, stored alongside completion records.
Common gotcha: We've passed SOC 2 audits multiple times without signed attestations, using completion records and quiz scores as the primary evidence. But attestations create a second, independent proof layer that some auditors like, and they're operationally cheap if your platform supports them. If you're facing an auditor who has asked for them before, they're easier to add than to argue about.
Three common failure modes, in priority order
After talking to dozens of teams going through their first SOC 2, three patterns show up over and over as audit-extending findings:
- Contractors omitted from the roster. Fix: run the contractor export separately and reconcile monthly.
- New hires who missed the training window. Fix: put training completion into the onboarding checklist, with a blocker on production access until complete.
- A curriculum that is visibly generic. Fix: a one-page mapping document showing which training topics cover which risks. Even a crude mapping beats no mapping.
Why we built our program around these specifics
When we went shopping for security training before building our own product, every platform we evaluated had the content covered, but most of them made the evidence story unnecessarily hard. Exports were PDFs instead of CSVs. Attestations were an enterprise-tier add-on. Retention beyond the active subscription was unclear. Contractor seats were priced at two to three times employee seats. Our own program is opinionated about this: per-user timestamped records are the default, signed attestations are included in the base tier, and exports are built for audit workflows first. That opinionation is a direct result of having been the customer trying to check boxes 1 through 10.
Further reading
- AICPA Trust Services Criteria: the primary source for CC1.4 and CC2.2.
- OWASP Top 10:2025: the canonical developer-risk list.
- ISO/IEC 27001:2022, Annex A.6.3: the ISO training control, useful as a complementary requirement if you pursue both certifications.
- Vanta's SOC 2 readiness guide: strong operational walkthrough of the surrounding controls.
- Our own SOC 2 developer security training requirements guide: the companion piece with more on evidence architecture.
FAQ
Is security awareness training actually required for SOC 2?
Yes, under the 2017 Trust Services Criteria. Specifically, CC1.4 (COSO Principle 4) requires the organization to "demonstrate a commitment to attract, develop, and retain competent individuals," and CC2.2 addresses internal communication of information "necessary to support the functioning of internal control," which auditors interpret to include security responsibilities. Training is the standard evidence pattern used to satisfy both.
How often do employees need to complete training?
Annually is the default cadence most organizations adopt. The TSC itself doesn't specify a cadence; the requirement comes from the organization's own policy. Once you state a cadence in your policy, auditors hold you to it. Annual is a defensible choice for most startups. Some programs do semi-annual or quarterly for higher-sensitivity environments.
Do contractors need to complete training?
Yes, if they have logical access to production systems, customer data, or the development pipeline. This is one of the most common places first-time audit programs fall short. Roster your contractors alongside employees.
What's the difference between training, awareness, and education in SOC 2 terms?
The TSC uses "competence" as the umbrella term. In practice, auditors treat "training" (scheduled courses with completion records) as the highest-evidence form, "awareness" (posters, reminders, quarterly emails) as a supporting layer, and "education" (formal degrees, certifications) as rare and mostly for security-specific roles. Your SOC 2 evidence story should lead with training.
Do we need signed attestations to pass SOC 2?
No, not strictly. Completion records plus quiz scores are typically sufficient primary evidence. Attestations add a second, independent proof layer and some auditors prefer them. If your platform supports attestations at no extra cost, they're worth including. If they'd require significant operational overhead, completion records alone are defensible.
How do auditors sample training completion evidence?
There is no AICPA-mandated sample size. AICPA guidance leaves sampling to the auditor's professional judgment, based on population size, control frequency, risk, and tolerable deviation rate. Published firm methodologies vary; some use tables, some use percentage-with-floor-and-ceiling formulas. The practical implication is that any in-scope user could end up sampled, so plan as if everyone's record will be reviewed. Auditors typically draw samples across teams and tenure bands and often include at least one new hire and one recently separated employee.
What if our curriculum changed during the reporting period?
Auditors expect curriculum changes, especially for fast-moving organizations. The evidence pattern is a documented curriculum for each version, with effective dates, and completion records that reference which version the user completed. OWASP's shift from the 2021 Top 10 to the 2025 release is an example where showing a curriculum transition strengthens rather than weakens your story.
Can we use free training content and still pass?
Yes, as long as the content is documented, mapped to risks, and backed by per-user completion evidence. OWASP publishes free content, Snyk Learn has a free tier, and many organizations pass audits using a combination of free content with a paid platform providing the evidence backbone. The cost of training software is not a SOC 2 requirement. What matters is the evidence story.