Do developers actually need security training for SOC 2? Reading the TSC and AICPA source documents

"Do developers specifically need security training for SOC 2?" is one of those questions where the answer depends heavily on whether you're reading the source documents or reading what the market has come to expect from them. The two are related but not identical. This guide works through the actual AICPA Trust Services Criteria (TSC) text, the accompanying points of focus, and the way auditors have come to interpret both, so an engineering leader can tell the difference between "required by the framework" and "expected by the typical auditor."

The short version is that the TSC does not name developers specifically, does not name security training as a control, and does not prescribe a cadence. What it does do is establish a principle (competence of the workforce) that auditors operationalize through training evidence. Whether that evidence has to cover developers specifically is an interpretive question with a consistent practical answer: yes, if developers are in scope for the system being audited.

TL;DR

1. The 2017 TSC is the primary source. The two criteria that drive training evidence are CC1.4 (competence) and CC2.2 (internal communication of internal-control information).
2. Neither CC1.4 nor CC2.2 names "training" as a required control. Training is the standard evidence pattern auditors use to demonstrate compliance with the principles.
3. Developers are in scope when they have logical access to the system boundary. Because most modern software-as-a-service systems draw that boundary to include the development pipeline, developers are almost always in scope.
4. The TSC's 2022 revision did not change the training-relevant text; it refined the points of focus but kept CC1.4 intact.
5. The question "do developers need developer-specific training (as opposed to general awareness)" is an interpretive one. The framework does not require role-specific content. Good auditors tend to ask about it anyway, because generic training strains credibility for an engineering-heavy organization.

What the TSC actually says

The 2017 Trust Services Criteria, with revised points of focus in 2022, is the governing document. Two criteria are relevant to training.

CC1.4 (COSO Principle 4)

The criterion itself reads, in part: "The entity demonstrates a commitment to attract, develop, and retain competent individuals in alignment with objectives." The accompanying points of focus (which auditors treat as non-binding but persuasive interpretive guidance) include references to establishing policies and practices, attracting and developing competent individuals, providing mentoring and training, and evaluating competence.

The training reference is indirect. "Training" appears as one among several ways the organization might demonstrate its commitment to workforce competence. The framework does not prescribe annual cadence, does not prescribe specific topics, and does not specify who must be trained. The operational question of "what does a passing training program look like" is left to the auditor's professional judgment, informed by the organization's own stated commitments in its policies.

CC2.2 (Internal communication)

CC2.2 reads, in part: "The entity internally communicates information, including objectives and responsibilities for internal control, necessary to support the functioning of internal control." The points of focus include communicating roles and responsibilities, communicating security objectives, and providing mechanisms for employees to report concerns.

Training is again not named explicitly. It becomes relevant because an organization that cannot demonstrate that its workforce understands their security responsibilities has a hard time satisfying CC2.2. Training records become the evidence. Awareness communications (quarterly emails, acceptable-use policy acknowledgments) can support CC2.2 without being "training" in the formal sense.

Why auditors treat training as required anyway

Reading CC1.4 and CC2.2 literally, an auditor could theoretically accept other evidence of workforce competence: hiring requirements, job-performance evaluations, certifications, peer review. In practice, a structured training program is the dominant evidence pattern because:

1. It scales. Evaluating each engineer's security competence individually doesn't work for an organization beyond about 15 engineers.
2. It produces exportable records. Auditors sample. Training platforms produce per-user, per-course, per-date records on demand. Other evidence patterns (interviews, performance reviews) don't export cleanly.
3. It aligns with adjacent frameworks. Organizations pursuing SOC 2 almost always also face ISO 27001 Annex A.6.3 (which does name training explicitly) or regulated-industry requirements that do the same. A single training program satisfies all of them.

The practical answer is that while training isn't required by name under SOC 2, it's so strongly expected that teams who try to substitute other evidence end up spending more effort defending the alternative than they would have spent running a training program.

What "in scope for developers" means

An employee is in scope for a SOC 2 audit when they have logical access to the system being audited. For most SaaS companies, the system boundary includes:

1. Production infrastructure (cloud accounts, Kubernetes clusters, databases).
2. The code repositories, CI/CD pipelines, and artifact stores that generate production deployments.
3. Customer data, including data in staging environments if seeded from production.
4. Access-control systems (identity provider, secrets manager).

Developers usually have read access to the second and third of those, and sometimes to the first. Under the TSC's definition, that makes them in-scope personnel.

The narrower interpretive question is whether a developer with access only to a repository for a non-production subsystem (say, a marketing microsite) is in scope for the audit of the primary product's security. AICPA's guidance here is that the scope is defined by the system being audited, not by the individual. Most auditors draw a wide boundary, which pulls most developers in.

What about role-specific (developer-focused) content?

This is where the interpretive gap is widest. The TSC doesn't require role-specific content. It requires that the workforce has appropriate competence for their responsibilities. For a developer, those responsibilities plausibly include writing code that doesn't introduce security vulnerabilities, handling customer data responsibly, and responding appropriately to security incidents in the software they maintain.

A generic security awareness course (phishing, password hygiene, data classification) doesn't meaningfully address the first of those. Auditors differ on how strictly they probe this. We've seen audits pass with a single awareness-focused curriculum applied to all employees, including developers. We've also seen auditors specifically flag the lack of developer-focused content as a control weakness, especially in the context of engineering-heavy organizations claiming to take security seriously.

The defensible position is to include developer-focused content (OWASP-aligned, covering the specific risk categories for your stack) as part of the training curriculum for anyone with code-repository access. If an auditor doesn't ask about it, you haven't over-spent. If they do, you have an answer.

How this connects to CC6 and CC7

The Common Criteria also include CC6 (logical and physical access) and CC7 (system operations), which describe controls around access provisioning, change management, incident detection, and incident response. Training sometimes gets pulled into evidence conversations for these as well:

1. CC6.2 (access provisioning): auditors sometimes look for evidence that new hires complete training before production access is granted. This is a procedural question more than a curriculum question.
2. CC7.3 (evaluation of security events to determine whether they are incidents) and CC7.4 (response to identified security incidents): auditors look for evidence that employees know how to report and respond to security events. A module in the training curriculum covering incident reporting procedures and response playbooks is a common way to satisfy both. CC7.4 is the more direct cite for response-specific awareness; CC7.3 comes in when training also covers how to recognize and escalate events.

The takeaway is that training evidence tends to get sampled across multiple criteria, not just CC1.4 and CC2.2. A well-constructed curriculum surfaces as evidence in three or four places in the typical SOC 2 report.

Why we read the source documents

When we were buying training for our own 60-person engineering team before building our product, the first question we asked every vendor was "what SOC 2 criteria does this satisfy?" The answers ranged from vague ("everything auditors need") to precise (a literal CC-number mapping). The more precise answers came from vendors who had clearly read the source documents themselves and designed their content to map to specific points of focus. That became the bar we aimed for when we built our own curriculum: direct mapping from modules to CC-numbers, so a customer's auditor can follow the trail without interpreting vendor marketing copy.

Further reading

• AICPA 2017 Trust Services Criteria (with 2022 revised points of focus): the primary source.
• AICPA SOC 2 reporting framework overview: context for how the TSC fits into the broader SOC 2 structure.
• COSO Internal Control Integrated Framework: the parent framework CC1.4 inherits from. Principle 4 is the direct ancestor of CC1.4.
• ISO/IEC 27001:2022, Annex A.6.3: the comparable control in the ISO framework, notably more explicit about training content appropriate to the job function and role.
• Our own SOC 2 developer security training requirements guide: the implementation-level companion to this interpretive piece.

FAQ

Does the TSC explicitly require annual training?

No. The TSC does not specify any cadence. Annual has become the default because organizations typically include an annual cadence in their own policies, and auditors hold organizations to their stated policies. An organization that stated "biennial" in its policy and consistently followed that cadence could pass an audit, though auditors would probably probe the rationale.

If our training is annual, does that satisfy CC1.4?

Training alone doesn't satisfy CC1.4. Training is one evidence pattern supporting a broader demonstration that the organization is committed to workforce competence. Auditors also look at hiring practices, performance evaluation, and leadership messaging. Training is the most sampled because it produces the cleanest evidence.

Can developers opt out of training if they have relevant certifications or recent security coursework?

Rarely, and never cleanly. The TSC doesn't prohibit accepting certifications in place of training, but the operational complexity of tracking and validating each developer's individual competence evidence is high enough that most programs just enroll everyone in the same training. A few organizations carve out exceptions for security-specific roles (platform security engineers, for example) with documented equivalent training.

What if we're pre-product and don't have customers yet?

The TSC applies to the system being audited. If there's no system in production, there's nothing to audit. Pre-product organizations sometimes pursue a "readiness" assessment or a Type I audit covering design-phase controls, but a Type II audit requires a reporting period with the system operational.

Does the TSC require specific evidence formats (PDF, CSV, system export)?

No. Auditors have preferences (system-generated exports with verifiable timestamps are strongly preferred), but the TSC itself is format-agnostic. What matters is that the evidence is reliable enough to support the auditor's conclusions.

How do changes to the 2022 revised points of focus affect developer training?

The 2022 revision did not materially change the CC1.4 or CC2.2 text. It refined the points of focus across multiple criteria, mostly to reflect guidance from the COSO 2013 framework update. The training-relevant interpretive guidance is effectively unchanged.

Is there a version of the TSC that will update for 2026 or 2027?

AICPA periodically reviews the TSC and has not announced a major revision through early 2026. The most recent significant update was the 2022 points-of-focus revision. Any future revision would likely refine rather than restructure the training-relevant criteria, based on the pattern of prior updates.

Where should I look if my auditor is asking for something I don't see in the TSC?

Most such requests come from the auditor's professional judgment rather than from the TSC directly. Ask the auditor to cite the criterion or point of focus they're evaluating against, then compare that citation to the actual text. If the request is reasonable and operationally cheap, it's usually worth satisfying. If it feels disproportionate, a direct conversation referencing the source text is the right move.