SOC 2 developer security training requirements: what auditors actually ask for

SOC 2 does not specify a security training curriculum. What it requires is evidence that your team has been trained, that the training covers the risks relevant to your environment, and that the training is recurring. Auditors decide whether your evidence satisfies the Trust Services Criteria. When teams fail this part of the audit, it is almost always because the evidence is thin or informal, not because the training itself was bad.

We built Top 10 Dev Training after spending months trying to buy a training tool that would clear SOC 2 for a 60-person engineering team without costing $5,000. Every vendor we talked to was priced for the Fortune 500. We kept hearing "just use Udemy certificates" as a workaround, which carried its own set of tradeoffs we'll get into below. This guide is what we wish we had on day one.

TL;DR

SOC 2 maps training requirements to Common Criteria CC1.4 ("demonstrates commitment to competence") and CC2.2 ("internally communicates information, including objectives and responsibilities for internal control"). Neither prescribes content.
Auditors want four pieces of evidence: a training policy, a defined curriculum, per-person completion records, and proof of recurrence (usually annual).
For engineering teams, the de facto curriculum is the OWASP Top 10, plus general security awareness (phishing, data handling, access control).
The most common audit failure is missing or informal completion records: people watched a video but nothing was logged, so there is no per-person record to hand the auditor.
Third-party certificates (Udemy, Coursera, etc.) create real operational overhead: no central tracking, no policy mapping, no competency verification. Outcomes vary by auditor; most teams find the workaround costs more than a purpose-built tool.
Signed attestations are optional but a useful defensibility layer, especially if you run into a stricter auditor or end up in an incident retrospective.

What the standard actually says

SOC 2 is built on the AICPA's Trust Services Criteria. The two criteria that govern security training are:

CC1.4: The entity demonstrates a commitment to attract, develop, and retain competent individuals in alignment with objectives.

The word "develop" is the training hook. A Type II auditor will ask how you develop your people's security competence, and how you verify the development happened.

CC2.2: The entity internally communicates information, including objectives and responsibilities for internal control, necessary to support the functioning of internal control.

Translation: you need to prove that your developers know their role in keeping the product secure. That knowledge has to be communicated, not assumed.

Neither criterion lists the topics you must cover, how long the training must be, or what format it must take. That is a deliberate design choice on the AICPA's part. The auditor uses their professional judgment to decide whether your training is "adequate" given the risks of your product.

That ambiguity is why teams over-buy enterprise LMS suites. They're trying to de-risk a judgment call. In practice, a lightweight program with good evidence passes; a heavyweight program with bad evidence fails.

The four pieces of evidence auditors actually ask for

After going through SOC 2 Type II multiple times and comparing notes with other startup founders who've done the same, here's the pattern every auditor we've encountered converges on. Some auditors ask for more; none that we've met have asked for less.

1. A written training policy

One or two pages. Owned by the CTO or compliance lead. States:

Who must take security training (usually: everyone with access to customer data or production systems).
What topics it covers (OWASP Top 10 for engineers; general security awareness for everyone; role-specific modules for admins and on-call).
How often it's required (annually is standard; quarterly for high-regulated industries).
What happens if someone doesn't complete it (access revocation, escalation to manager).
Who is responsible for enforcement.

The policy doesn't need to be long. It needs to exist and be referenced in your broader information security policy. Auditors will check that both documents acknowledge each other.

2. A defined curriculum

The set of modules every in-scope person must complete. For engineering teams, this is almost always:

OWASP Top 10 (current edition is OWASP Top 10:2025). Covers the ten most critical web application security risks. Non-negotiable for anyone shipping web code.
General security awareness: phishing, password hygiene, data classification, incident reporting, safe browsing.
Role-specific additions: admins get extra modules on access control and third-party risk; anyone on-call gets incident response.

Auditors rarely argue with this list. If you tell them you cover OWASP Top 10 plus general awareness, you've hit the expected baseline.

3. Per-person completion records

The single most-requested artifact. For each person in scope, the auditor wants:

Full name and email.
Role at the time of training.
Which modules were assigned.
Completion date for each module.
A quiz score or competency check, if your training includes one (most auditors prefer that it does).

This is where informal programs fail. "Everyone watched the OWASP talk at the engineering all-hands last January" is not a completion record. The auditor cannot verify who was present, what was covered, or whether anyone understood it.

4. Evidence that the training is recurring

SOC 2 Type II covers a period (usually 6 to 12 months), not a point in time. The auditor wants to see training evidence across the whole period. A batch of attestations dated January 15 followed by nothing for the next 11 months raises a flag. You should have:

A schedule showing when retraining is due.
A trigger for onboarding new hires within a window committed to in your own policy. The AICPA doesn't mandate a window; common choices range from "before production access is granted" to 90 days post-hire, depending on how conservative you want to be.
A log of retraining events.

This is also where auto-expiring training credits matter. If credits expire annually, you've baked the recurrence requirement into the system; the auditor sees it in the data rather than having to trust your process document.

Optional: signed attestations

We've passed SOC 2 multiple times without formal signed attestations and so have plenty of other teams we've talked to. Most auditors accept per-person completion records as sufficient evidence of training. An attestation is a formal statement the learner signs, typically including their name, the course and version, the date, and a statement that they understand the content and their security responsibilities.

So why include attestations at all? Two reasons, neither of them "required":

Defensibility in an audit that goes sideways. If you get a stricter auditor, switch auditors, or end up in an incident retrospective where a breach traces back to a specific person's area, an attestation turns "they took the training" into "they personally acknowledged responsibility for the content." It's a belt-and-suspenders habit.
Framework portability. ISO 27001 auditors ask about attestations more often than SOC 2 auditors do. If you're dual-tracking or plan to add ISO 27001 later, building attestation into the training system now costs nothing extra.

We build attestations into our product for both reasons. Completion records on their own have cleared SOC 2 for us and will likely clear it for you. If your auditor wants more, attestations are the natural upgrade.

The three ways teams most commonly fail

Based on conversations with startup founders who've been through SOC 2, the same three patterns account for almost every training-related audit finding.

Failure 1: "We showed them the OWASP videos but nothing was logged"

The training happened. There is no per-person record. The auditor cannot rely on self-report or a "we held a session" paragraph in a Slack thread.

Fix: adopt a system, any system, that logs completion per person. At minimum, a Google Form that captures name, date, and a checkbox confirming completion. Auditors prefer purpose-built systems because they include competency verification (quiz scores) and produce an export-ready audit trail.

Failure 2: "We used [big name LMS] but can't pull a report"

Enterprise LMSes are often optimized for HR, not compliance. Completion data is trapped inside the vendor's UI, not exportable as a compliance report. The auditor ends up with screenshots.

Fix: pick a system that produces a CSV compliance report filtered by user, course, and date range. If your current tool can't do this, that's a real audit risk.

Failure 3: "Contractors weren't included in the training program"

SOC 2 scope includes anyone with access to customer data or production systems, contractor or employee. We've seen finders that treated this as an employee-only thing and missed their full-time contractors entirely.

Fix: apply the training policy to access, not to employment status. If you onboard a contractor to your production database, they take the training. Period.

What about Udemy, Coursera, or CBT Nuggets certificates?

These come up constantly. Some auditors accept them, some don't. The outcome depends on your auditor, your supplemental documentation, and whether you've bridged the gap between what the third-party cert proves and what your policy requires. The issues aren't the content quality: the content from most of these platforms is fine. The issues are operational:

No policy mapping. A Udemy cert says "completed this course." It does not say "completed your company's required OWASP Top 10 training." To satisfy the auditor you need a mapping document: for each internal required topic, which external course and which sections cover it.
No central system of record. Each learner emails you a PDF. You maintain a folder of PDFs and a tracking spreadsheet. When a new learner starts, you have to remember to assign them the same course, track their completion, and nag them for the certificate. This is where programs silently drift over time.
Competency verification varies. Some platforms issue certificates based on video attendance only; others include quizzes. Auditors prefer programs that verify understanding, not just seat time.
Scaling pain. For 10 engineers, a folder of PDFs is manageable. For 50 or 100, it breaks: every new hire is a new ticket, every renewal is another round of reminders.

Whether a third-party cert passes your specific audit is ultimately your auditor's call. What we can say confidently is that by the time you've built the mapping document, the tracking spreadsheet, and the renewal reminders, you've usually done more work than adopting a purpose-built SOC 2 training tool would have cost.

ISO 27001 and NIST cross-reference

If you're dual-track-compliant, a core training program is portable across frameworks, but each framework has its own wrinkles:

ISO 27001 Annex A.6.3 ("Information security awareness, education and training"): requires three distinct content types (awareness, education, AND training) per ISO 27002:2022 guidance. A training platform plus per-user records covers the education and training legs; the awareness leg usually requires a separate channel (phishing simulations, security newsletters, posters). ISO auditors also increasingly look for effectiveness evidence (click rates, reporting rates) on top of completion records. See our SOC 2 vs ISO 27001 mapping guide for the detailed comparison.
NIST SP 800-53 Rev. 5 controls AT-2 and AT-3 ("Literacy Training and Awareness" / "Role-Based Training"): more prescriptive. AT-2 maps to general awareness; AT-3 is explicit about role-based content mapped to job function. FedRAMP programs operationalize these and usually push teams toward more role-specific curricula than SOC 2 strictly requires.

A SOC 2 training program covers the core training evidence both ISO and NIST want, but it rarely covers all of either. Plan to add phishing simulations and a documented policy tying the program to A.6.3 if you're pursuing ISO, and role-specific modules tied to job function if you're pursuing FedRAMP.

How Top 10 Dev Training handles this

We built our product backwards from the evidence list above:

A training policy template is published at top10devtraining.com/resources/security-training-policy and surfaced in company onboarding, so every new company has a starting-point policy on day one. Adapt it to your organization.
The curriculum is OWASP Top 10:2025 plus General Security Awareness, covering the expected baseline for engineering SOC 2.
Per-module quizzes with an 80% passing threshold produce completion records with real competency verification, not just attendance.
Annual credit expiration automates the recurrence requirement. You can't forget to retrain because the system won't let you.
CSV compliance reports export in the exact format auditors ask for: name, email, course, modules passed, quiz scores, completion dates, attestation dates.
Signed attestations are included as the optional defensibility layer described above. Timestamped, digitally signed at course completion, stored with IP address and user agent for anyone who wants the paper trail.

It's $11.99 per learner per year. No enterprise sales call. If you're preparing for SOC 2 and want to see what a compliance-ready training record looks like before you buy anything, the module content is free to read without signing up.

FAQ

Does SOC 2 specifically require OWASP Top 10 training for developers?

No. SOC 2 requires evidence of competency development; it does not prescribe OWASP specifically. That said, auditors use OWASP Top 10 as the de facto benchmark for web application security training because it's the industry standard reference for critical web risks. If you train on OWASP, no auditor will argue. If you train on something else, expect to justify why.

How often does security training need to be retaken?

Annually is the standard SOC 2 expectation. Some auditors accept biannually for low-risk roles; high-regulated sectors (healthcare, fintech) often push to quarterly. If your training credits expire annually, you've satisfied the recurrence expectation without an additional calendar.

Do contractors need to take the same training as employees?

If they have access to customer data or production systems, yes. SOC 2 scope follows access, not employment status. Excluding contractors is one of the most common training-related audit findings.

What if someone fails the quiz?

A well-designed program allows unlimited retakes with a passing threshold (80% is common). The auditor cares that the learner eventually demonstrated competency, not that they got it on the first try. Store every attempt; auditors occasionally sample the failed attempts to verify your retake process.

Is a PDF certificate from Udemy or Coursera enough?

Sometimes, depending on your auditor and how much supplemental documentation you wrap around them. The content is rarely the problem; the operational overhead is. You still need a policy-to-course mapping document, a central tracking spreadsheet, per-person completion records, and renewal reminders. Most teams find that by the time they've built all that, they've done more work than a purpose-built tool would have cost. If you go this route, expect your auditor to ask how you verify the external courses cover your required internal topics.

How long does SOC 2 developer training actually take?

A typical learner spends 50 to 90 minutes per course if they move quickly, closer to 1 to 2 hours per course if they actually read the code examples and think through the quizzes. The full curriculum (OWASP Top 10:2025 plus General Security Awareness) is 19 modules across two courses, so budget 2 to 4 hours total for a learner who's engaging with the material.

The OWASP course has shorter content per module but the quizzes are deliberately tough. We ask about real attack patterns (JWT algorithm confusion, dependency confusion, TOCTOU race conditions) rather than "what is phishing" trivia. The General Security Awareness course is the reverse: longer reading, more moderate questions.

This is an intentional design choice. A lot of compliance training exists to tick a box, which is why its quiz questions tend to be trivial. We wanted training that would actually move a developer's security competence, which means the quiz questions have to be hard enough that passing them means something. The pass threshold is 80 percent with unlimited retakes, so learners can iterate, but they can't coast.

Does the training need to be role-specific?

SOC 2 does not explicitly require it, but ISO 27001 Annex A.6.3 and NIST SP 800-53 AT-3 do. If you're dual-tracking, plan for role-specific modules for admins, on-call engineers, and anyone handling financial or health data.

What's the cheapest SOC 2-compliant training option?

Writing the curriculum and tracking yourself is technically free, but the time cost is usually several weeks of engineering leadership time plus ongoing maintenance. Paid options start around $12 per learner per year for purpose-built tools and scale to $300+ per learner for enterprise LMS suites. The gap between "free but expensive in time" and "paid but cheap in effort" is one of the most predictable hidden costs in SOC 2 prep.