SOC 2 and PCI DSS readiness: cyber security training for financial services teams

Financial services teams tend to sit under two overlapping compliance regimes at once. Payment Card Industry Data Security Standard (PCI DSS) obligations apply wherever a team stores, processes, or transmits payment card data. System and Organization Controls 2 (SOC 2) expectations apply wherever a team operates as a service organization handling customer data.

Both regimes expect documented security training. Neither names a single course, vendor, or certification that satisfies the requirement, which leaves anyone planning training for a team to work out what an assessor will actually accept.

This guide sets out what each standard asks for, where the two differ, and how a team can build hands-on training that maps to both and produces records worth showing.

In short:

• PCI DSS Requirement 6.2.2 is prescriptive. It asks for developer training at least once every 12 months, covering software security relevant to the developer's job function and languages, secure design and coding techniques, and, where security testing tools are used, how to use them to detect vulnerabilities.
• SOC 2 is criteria-based. The Trust Services Criteria published by the American Institute of Certified Public Accountants (AICPA) expect demonstrated competence (Common Criteria CC1.4) and clearly communicated security responsibilities (CC2.2), evidenced rather than prescribed. There is no mandated curriculum, seat time, or cadence.
• In practice both reward the same things: role-relevant, hands-on training that covers a real attack surface and leaves a per-person record an assessor can map back to a control.
• A training platform supplies content and completion records. Whether a program is sufficient is evaluated by the organization's Qualified Security Assessor (QSA) or SOC 2 auditor in the context of its scope, so training is best planned as evidence toward a control rather than as a compliance guarantee.

What do SOC 2 and PCI DSS actually require in terms of security training?

Both frameworks expect an organization to be able to show that people in relevant security and control roles have the competence and information their work requires, though they express that expectation at different levels of detail.

PCI DSS is specific about developers. Requirement 6.2.2, in version 4.0.1 of the standard, states that software development personnel working on bespoke and custom software are trained at least once every 12 months on software security relevant to their job function and development languages, on secure software design and secure coding techniques, and, where security testing tools are used, on how to use those tools to detect vulnerabilities.

A separate control, Requirement 12.6, covers a formal security awareness program for all personnel, which the standard treats as general awareness distinct from the developer training in 6.2. The current version is PCI DSS v4.0.1, and the future-dated v4.x requirements became mandatory on 31 March 2025, so a program shaped to satisfy the older v3.2.1 reading may now leave gaps. The primary source is the PCI Security Standards Council document library.

SOC 2 is criteria-based rather than prescriptive. It is built on the AICPA Trust Services Criteria, of which the Security category (the Common Criteria, CC1 through CC9) applies to every examination. Two criteria carry the training expectation: CC1.4, which asks the organization to demonstrate a commitment to attract, develop, and retain competent individuals and to provide training that maintains the competencies needed to meet its objectives, and CC2.2, which asks the organization to internally communicate the information and responsibilities people need to carry out their control duties.

The criteria prescribe no curriculum, no minimum seat time, and no fixed cadence. In practice, organizations often use a documented training program and role-specific evidence, including completion records, to show how those competencies and responsibilities are maintained and communicated, so training tends to be effectively expected even though it is nowhere mandated in detail.

Neither standard names a vendor, a format, or a certification. Both leave the organization to design controls that meet the requirement and to hold evidence that the design works.

How do PCI DSS and SOC 2 training expectations differ?

The two differ mainly in how prescriptive they are about training: PCI DSS specifies what developers are trained on and how often, while SOC 2 leaves the curriculum and cadence to the organization and asks it to demonstrate role-appropriate competence. Both are ultimately judged on the evidence a team can produce.

The practical takeaway is that a single, well-evidenced training program can often serve both regimes for the developer population. A curriculum that satisfies PCI DSS Requirement 6.2.2 for in-scope developers, with per-person records mapped by role, generally also produces the kind of competence-and-communication evidence a SOC 2 examination looks at under CC1.4 and CC2.2. The reverse is less reliable: a general security-awareness course may not, on its own, cover the language-specific and tooling clauses PCI DSS spells out for developers.

What does PCI DSS Requirement 6 ask developers to learn?

Requirement 6.2.4 identifies the vulnerability categories that secure software engineering techniques must be in place to prevent or mitigate, which gives a useful framework for designing training content. The categories it names are injection flaws, attacks on data and data structures, attacks on cryptography usage, attacks on business logic, attacks on access control mechanisms, and any high-risk vulnerabilities identified through the vulnerability-tracking process in Requirement 6.3.1. Business logic abuse is among the categories the version 4 rewrite calls out explicitly, and it tends to be the least well served by generic secure-coding material.

A widely recognized, vendor-neutral reference for the same categories is the Open Worldwide Application Security Project (OWASP) Top 10. Hands-on labs that walk a developer through finding, exploiting, and then remediating each class can support training on the vulnerability categories Requirement 6.2.4 addresses. On TryHackMe, those categories line up with grouped rooms drawn from the Web Application Pentesting path. The rooms in each group below are examples of where that class is covered hands-on, not a complete list:

• Injection flaws. Advanced SQL Injection, NoSQL Injection, XXE Injection, Server-side Template Injection and LDAP Injection cover the class directly, with Injectics as a no-walkthrough challenge.
• Access control and broken authentication. Enumeration & Brute Force, Session Management, JWT Security and OAuth Vulnerabilities map to the access control and authentication categories.
• Attacks on data, data structures, and business logic. Insecure Deserialisation, SSRF (server-side request forgery), File Inclusion, Path Traversal and Race Conditions cover data-handling and logic-abuse classes that many catalogues address only lightly.
• Client-side and payment-page integrity. XSS (cross-site scripting), CSRF (cross-site request forgery), DOM-Based Attacks and CORS & SOP cover the client-side attack classes behind the payment-page script controls in Requirement 6.4.3.

How can a team build hands-on training that maps to these requirements?

Turning either standard into training a team can evidence tends to come down to a few practical moves: scope the population first, set a common annual core, add role and language depth, cover tooling competence where tools are in use, and add evidence of applied skill. Each maps to a specific clause, and each has a hands-on resource behind it. The modules and rooms named below are examples of where each area is covered, not a prescribed or exhaustive list.

• Scope the population first. Requirement 6.2.2 applies to developers working on in-scope bespoke and custom software, so a useful first step tends to be identifying which teams are in scope and grouping them by role and primary language before any content is assigned. A team plan through TryHackMe for Business can group in-scope developers, assign a defined curriculum, and track completion against it, so the training population maps to the population an assessor reviews rather than a company-wide broadcast.
• Set a common annual core. Giving every in-scope developer the same baseline each year is what makes a consistent standard demonstrable. The OWASP Top 10 (2025) module is one example, covering identification and authentication failures, application design flaws, and insecure data handling in a learn-then-exploit-then-remediate format that lines up with the vulnerability categories Requirement 6.2.4 addresses.
• Add role and language depth. The clause in 6.2.2 that training be relevant to a developer's development languages is one a single generic course does not satisfy on its own. The Web Frameworks module is one example, with code-review and exploitation content for Java, Python and .NET, a PHP source code review room, and a framework-agnostic code review room, so a developer can be assigned the content that matches their stack.
• Cover tooling competence where tools are in use. Where security testing tools are used, Requirement 6.2.2 also asks for training on using them to detect vulnerabilities, a clause that is easy to overlook. The Security in the Pipeline module is one example, with practical static application security testing (SAST), dynamic application security testing (DAST), and dependency management labs that are also relevant to the software-inventory and patch-management expectations in Requirements 6.3.2 and 6.3.3.
• Add evidence of applied skill. A task a learner solves without a walkthrough can show engagement that a completion record alone does not. Pairing walkthrough rooms with a no-walkthrough challenge such as Injectics, then recording the challenge completion, can add that kind of artifact alongside scope-appropriate internal assessment.

Whichever rooms a team assigns, one point is worth keeping in view: completing them builds training and produces completion records, and TryHackMe supplies both, but neither the content nor the records certify PCI DSS or SOC 2 compliance on their own. Whether a program is sufficient is evaluated within the organization's assessment or examination, against its specific scope, by its QSA or SOC 2 auditor, so these moves are best treated as ways to build training and evidence that map to the requirements.

What counts as evidence of training for an auditor or QSA?

An auditor or QSA evaluates the evidence an organization presents that its training produced people who can recognize and handle the risks in their role. A completion record may be one part of that evidence; an organization seeking stronger evidence can also document demonstrations of applied skill, such as an assessment a developer completes without a walkthrough.

Two points are worth being clear about when planning training as audit evidence. A training platform provides content and completion records; it does not itself certify PCI DSS or SOC 2 compliance, and the sufficiency of any program is evaluated by the organization's QSA or SOC 2 auditor in the context of its scope. Planning training as evidence toward a named control, with records mapped by role and language, tends to hold up better under that review than treating any single course as proof of compliance in its own right.

Hands-on exploitation content and remediation tools built into the code editor serve different halves of the same goal, and tend to work best together. Exploit-and-understand labs build the attacker intuition that helps secure coding stick, while a remediation tool sitting in the editor reinforces the fix at the moment code is written.

A program can reasonably use both. An independently solved challenge can provide stronger evidence of applied engagement than attendance alone, particularly alongside scope-appropriate internal assessment. The depth of that evidence, from a completion certificate through to an independently solved challenge with a written finding, is a fair bar to measure any provider against, and not every format clears it.

For senior application security staff, a professional certification can add portfolio-grade evidence on top of internal records. The Web Application Pentester Level 1 (WEB1) certification, drawn from the Web Application Pentesting path and aligned to the OWASP Top 10, asks a candidate to find, exploit, and write up real web vulnerabilities, which produces per-vulnerability reports a hiring manager or an auditor can read. It sits well beyond what Requirement 6.2.2 asks of a general developer population, so it tends to fit a specialist or reviewer role rather than a whole team.

How often should financial services teams run developer security training?

PCI DSS sets a floor of at least once every 12 months for in-scope developers. SOC 2 sets no fixed interval; a Type II examination assesses whether controls operated effectively across a review period, so the training evidence needs to support the operation of the organization's controls over that period. Depending on how the control is designed, a single annual training event may or may not be sufficient on its own.

Annual training can meet the minimum cadence PCI DSS sets for this control. Many organizations still choose a broader rolling program, one annual baseline that every in-scope developer completes plus periodic assignments drawn from newer content as threats and techniques change, to maintain competence and respond to changing risk. That pattern aligns with the version 4.x framing of PCI DSS as a continuous, business-as-usual activity, and with Requirement 6.3.1's expectation that new vulnerabilities be tracked from industry sources on an ongoing basis. It also spreads the delivery load, so a team is not compressing a year of training into the month before an assessment.

FAQ

What security training does PCI DSS require for developers?

PCI DSS Requirement 6.2.2, in version 4.0.1 of the standard, requires that software development personnel working on bespoke and custom software are trained at least once every 12 months. The training must cover software security relevant to the developer's job function and development languages, secure software design and secure coding techniques, and, where security testing tools are used, how to use those tools to detect vulnerabilities. A separate control, Requirement 12.6, covers a general security awareness program for all personnel, which is treated as distinct from developer-specific training.

Does SOC 2 require security awareness training?

SOC 2 does not name security awareness training as a line-item requirement, but the Trust Services Criteria make it effectively expected in practice. Common Criteria CC1.4 asks an organization to demonstrate a commitment to developing and retaining competent people, including through training, and CC2.2 asks it to communicate the responsibilities people need to carry out their control duties. To show how those competencies and responsibilities are maintained, organizations commonly use a documented training program with role-appropriate content and per-person records, though the criteria prescribe no specific curriculum or cadence.

What is the difference between PCI DSS and SOC 2 training requirements?

PCI DSS is prescriptive about developer training: it names the topics, sets an at-least-annual cadence, and, in Requirement 6.2.4, identifies the vulnerability categories secure development must address. SOC 2 is criteria-based: it asks an organization to demonstrate competence and communicate responsibilities, and leaves the curriculum, format, and cadence to the organization to design against its own risks. A program detailed enough to satisfy PCI DSS 6.2.2 for in-scope developers generally also produces the competence evidence a SOC 2 examination looks at under CC1.4 and CC2.2.

How do you evidence developer security training for an audit?

Evidence for an audit generally combines a program description, a role-based curriculum mapping, and a per-person completion register held across the review period. An organization seeking evidence of applied skill, rather than attendance alone, can add an artifact such as an independently solved challenge with a written finding. On TryHackMe, per-developer completion records, challenge rooms such as Injectics used as competency checks, and the per-vulnerability write-ups produced in the WEB1 certification are examples of records a team can present. A platform supplies the content and the records; whether the overall program is sufficient is evaluated by the organization's QSA or SOC 2 auditor in the context of its scope.

How often does PCI DSS developer training need to happen?

PCI DSS Requirement 6.2.2 requires in-scope developer training at least once every 12 months, which is the stated minimum for this control. Because version 4.x frames compliance as a continuous activity and Requirement 6.3.1 expects new vulnerabilities to be tracked on an ongoing basis, many teams add periodic refreshers on top of that annual baseline. For a SOC 2 Type II examination, which assesses controls across a review period, the training evidence needs to support how the control operated over that period, so how much is enough depends on the control's design.

Learn more about building your cyber capability at TryHackMe for Business.