6.2 Secure bespoke and custom software development

What PCI DSS 6.2 asks for in bespoke and custom software

Requirement 6.2 applies to software your organization commissions to its own specifications or builds for its own use. The PCI SSC glossary calls the first bespoke software, developed by a third party for the entity to its specifications, and the second *custom software*, developed by the entity for its own use. Requirement 6.2 sets out a secure development lifecycle, annual developer training, pre-release code review, and engineering techniques that stop common attacks such as injection, cross-site scripting (XSS) and access control bypass. If your payment team, an assessor or a buyer asks whether 6.2 covers a system, start with the question of who wrote it and for whom. Off-the-shelf products and open-source components you consume without modifying them sit under other requirements, including 6.3, which covers vulnerability management for all software.

The risk behind 6.2 is simple. A flaw introduced during development, such as an unchecked query parameter, a missing authorization check in an API or a business rule that can be bypassed, becomes an entry point into the cardholder data environment (CDE). Attackers rarely need to break the network when the application that handles payment data can be tricked into revealing it. Assessors therefore look for evidence that the defenses are built into each release, not only that a policy describes them. The hard part is proving the process ran on every change. Teams often hold a secure coding policy and a training slide deck but cannot show which developers completed training in the last 12 months, which pull requests received an independent review, or which security tests ran before a given release.

Start by building an inventory that separates bespoke and custom code from third-party software, because the boundary decides what you must evidence under 6.2. Then confirm with your assessor how they will sample releases, which records they expect and whether a customized approach or compensating control could apply to any sub-requirement. The five sub-requirements (6.2.1 to 6.2.4 and 6.2.3.1) cover the lifecycle, training, review and attack prevention in turn, and the sections that follow take them one at a time. Confirm the current wording in the official Self-Assessment Questionnaire D for Service Providers and your assessor's expectations, since the standard's requirement text governs.

Which bespoke and custom software falls under PCI DSS 6.2

Requirement 6.2 applies to software your organization or a contractor builds for you, not to everything that runs in the cardholder data environment. The cards below cover the classification decisions that determine whether 6.2 reaches a given application, service or pipeline, and the checks to make before you assume it does or does not.

Bespoke software built to your specifications

Bespoke software is written by a third party for your organization to your specifications. Requirement 6.2 applies to it because you direct the design and the code is delivered to you for use in your environment. Confirm the contract states that the vendor built the code to your requirements, and that you receive source code or a defined delivery path. Ask the developer to show how their own secure development practices map to 6.2, since your assessor will look for that evidence in the delivery process.

Custom software your staff builds

Custom software is developed by your own team for your internal use. Every application that handles payment flows, authentication, card data or payment-related business logic falls under 6.2 when your staff write it. Inventory each custom application, its owner and the repositories that hold its code. An application that looks like an internal tool can still be in scope if it sits in the payment flow or touches cardholder data.

Third-party software that 6.2 does not cover

Off-the-shelf and commercial third-party software is not bespoke or custom under the PCI SSC glossary, so Requirement 6.2 does not apply to it. Your obligations for these products move to other requirements, such as vulnerability management and patching under 6.3. Keep a clear record of which products you bought as-is and which were built for you, because mixed products such as a commercial platform with custom modules need that line drawn for each component.

Systems in or affecting the cardholder data environment

Custom code is in scope for 6.2 when it runs in the cardholder data environment or could affect its security. Map every application, API and service that stores, processes or transmits account data, plus any system that can alter those flows, such as authentication services or internal tools that manage payment settings. A connected system that cannot affect the cardholder data environment may fall outside 6.2, but that conclusion must be documented and checked against your network segmentation.

Developers and contractors who write code

Anyone who writes bespoke or custom code is subject to the training and review expectations of 6.2, including employees, contractors and offshore teams. Build a roster of every person who commits code to in-scope applications, and record which of them are internal and which are external. Confirm that contract terms require the same secure coding training and review practices, because your assessor will ask for evidence from each group.

CI/CD tooling and code repositories

Source code repositories, build pipelines and security scanning tools are components of the development process that 6.2 relies on. A repository that allows direct pushes to protected branches or a pipeline without a code review step can defeat the review control, even when the code itself is sound. Treat these platforms as in-scope process components, document who can merge and release, and retain logs that show which reviews and scans ran before each release.

How an assessor tests PCI DSS 6.2

This table lists each Requirement 6.2 sub-requirement with the test approach an assessor typically follows, the evidence requested and the findings that most often cause gaps. Read it as a preparation checklist: the evidence column shows what to have ready before the assessment starts, and the findings column shows where records tend to fail on review.

Sub-requirement	Test approach	Evidence requested	Common findings
6.2.1 Secure development process	Assessor reads the documented process and checks that it covers bespoke and custom software, follows the standard, and assigns roles for developers and reviewers.	Current secure development policy or procedure, role descriptions, and a sample of recent releases showing the process was followed.	Process document is generic, not tied to the repositories in scope, or describes steps that the team does not actually follow.
6.2.2 Developer training	Assessor matches each developer on sampled releases to training records and checks the dates against the 12-month window.	Training completion records for each developer covering software security, secure design and coding, and any security testing tools in use.	Training records predate the 12-month window, cover only general awareness, or omit the testing tools the team uses in its pipeline.
6.2.3 Pre-release code review	Assessor selects recent releases and checks that code was reviewed before it reached production, including manual and automated review where used.	Pull or merge request history, review comments, and pipeline logs showing scans ran before the release tag was created.	Releases deployed without review, hotfixes that bypassed the review gate, or review evidence that only covers part of the change.
6.2.3.1 Manual review rules	Assessor checks that each manual review was done by someone other than the author, by a reviewer with review and secure coding knowledge, and approved by management.	Reviewer identity separate from author in repository records, reviewer competence evidence, and management approval captured before deployment.	Author approves own change, reviewer lacks secure coding knowledge, or approvals are recorded after deployment.
6.2.4 Engineering techniques against attacks	Assessor reviews the team's secure coding standards and test results to confirm controls against injection, data structure attacks, cryptography misuse, XSS, CSRF, business logic abuse and access control bypass.	Secure coding standards, static analysis or security test results for sampled releases, and remediation tickets for findings.	Scans run but findings are not triaged, no test covers access control or business logic, or standards exist without evidence they are applied.
Sampling and record inspection	Assessor samples recent releases and developers, then inspects repository, pipeline and approval records to trace each release through the process.	A list of releases and developers in scope, with repository access and approval records available for the sample.	Records cannot be linked from a release to its review, approval and training, which forces the assessor to widen the sample.

How to implement PCI DSS 6.2 in sequence

This sequence takes an organization from an unclear picture of its bespoke and custom software to a tested, documented secure development process for Requirement 6.2. Each step closes with an artifact an assessor can review, and the organization keeps ownership of every decision.

Confirm the in-scope software inventory
Start by listing every codebase your organization develops for its own use (custom software) or commissions from a third party to your specifications (bespoke software). Mark which ones store, process or transmit cardholder data or could affect the security of the cardholder data environment. Third-party software that you buy off the shelf falls outside Requirement 6.2, so record it separately. The engineering lead and the compliance owner should sign off the list. The output is a dated inventory with a named owner for each codebase, which becomes the baseline for every later step.
Document the secure development process and roles
Write a secure development lifecycle procedure that shows how requirements, design, coding, testing and release happen for each in-scope codebase. Name the roles involved, including developers, code reviewers, the approver who signs off releases, and whoever owns the security tooling. Confirm the document with the engineering and security leads and have management approve it. The output is an approved procedure with a role matrix that assessors can compare against what developers actually do.
Set up and record annual developer training
Define a training plan that covers software security, secure design and coding practices, and the security testing tools your teams use. Every developer working on in-scope code must complete it at least once every 12 months, so schedule the cycle from each person's completion date. Record each completion with the person's name, the course, the date and the content covered. Tool vendor courses can count if they cover the required topics, but confirm that with your assessor. The output is a training matrix and completion log that shows current status for every developer.
Configure protected branches and approval rules
In your code repository, set protected branches on the main and release branches so that only defined roles can push or merge. Block direct pushes to the protected branches, keep force pushes disabled unless a named owner has explicitly allowed them, and require a review from someone other than the author before merge. GitLab Community Edition supports these controls through protected branches. Test the settings by attempting a direct push with a developer account and confirming that it fails. The output is a configuration export and a test record showing that the controls enforce the procedure.
Add static analysis and dependency scanning to the pipeline
Add automated static analysis to the continuous integration pipeline so every change is scanned before merge. Semgrep Community Edition supports many languages and can run custom rules that reflect your coding standard. Add dependency and software bill of materials scanning as well: Trivy can generate an SBOM and scan dependencies, and OWASP Dependency-Track can track vulnerable components over time. Confirm the languages in your codebases are covered by the tools you choose. The output is pipeline configuration, a sample of scan results and a documented triage process for findings.
Define the manual code review standard
Write a manual review standard that states who may review code, how the reviewer must be independent of the author, and what a review checklist covers, including secure coding points and the attack classes in Requirement 6.2.4. Require that a reviewer knows secure coding and code review, and that management approves the release before it goes live. Apply the standard to a sample of recent changes to check that reviews are being recorded. The output is an approved review standard, a checklist and a set of completed review records.
Build attack-prevention checks into the coding standard
Translate each attack class named in Requirement 6.2.4 into concrete coding rules for your stack. Cover injection, attacks on data structures, cryptography misuse, business logic abuse including cross-site scripting and cross-site request forgery, and access control bypass. For each class, state the required pattern, the prohibited pattern, and the pipeline rule or review checklist item that enforces it. Have the security lead and the lead developers approve the standard. The output is a coding standard with a traceability table linking each attack class to a control and a test.
Run an internal assessment against the sub-requirements
Before engaging an external assessor, have an internal team test each sub-requirement of 6.2 against the evidence produced in the earlier steps. Check the inventory, procedure, training records, branch settings, pipeline results, review records and coding standard, and note every gap with an owner and a remediation date. Confirm the timeline with your own team, since it depends on how many codebases are in scope and how many developers work on them. The output is an internal assessment workbook with findings, owners and a remediation plan. Whether your controls meet the requirement is decided by your assessor, not by this review.

Evidence that satisfies PCI DSS 6.2 and how to keep it current

An assessor testing Requirement 6.2 samples records from each stage of the development lifecycle, not a single policy document. The six artifacts below connect the written process, the people, the code, the reviews, the scans and the release contents, and each one needs a routine that keeps it current between assessments.

Written secure development process

The assessor expects a current, documented secure software development process that names who owns each step, from design and coding through review and release. Check that the document covers the training, code review and attack-prevention practices in 6.2, and that role assignments list named functions rather than individuals who have since left. Record the approval date and the owner. Review the document at least once a year and after any material change to the toolchain or team structure, and keep prior versions so the assessor can see what was in force during the assessment period.

Developer training records

For bespoke and custom software, the assessor samples developers who wrote code in the period and checks that each one completed software security training at least once in the previous 12 months. Records should show the developer's name, the completion date, the course title and the topics covered, including secure design and coding and any security testing tools used in the pipeline. Generic attendance certificates with no content description are weak evidence. Keep a roster that is reconciled against the current list of committers each quarter so that new contractors are not missed.

Protected branch settings and approval history

Repository configuration is evidence that the code review rules are enforced, not just described. Export the protected branch settings for each production repository, showing which roles can push or merge and whether direct pushes and force pushes are blocked. GitLab Community Edition (MIT) supports protected branches that restrict push and merge roles and keep force pushes disabled unless explicitly allowed. Confirm these capabilities in your own GitLab version. Export the merge approval history at each release cycle and store it outside the repository, because the assessor may ask for a period that predates your current configuration.

Manual code review records

Requirement 6.2.3.1 expects manual reviews performed by someone other than the author who understands code review and secure coding, with management approval before release. For each sampled change, the record should show the author, the reviewer, the review date, the security points checked and the management approval. Reviews that show the same person as author and approver fail the test. Keep the reviewer qualification or training reference alongside the review log. Run a periodic sample of your own records against these elements so gaps are found before the assessor finds them.

Automated scan reports and triage decisions

Pipeline scan output shows that code is tested for the attack classes listed in 6.2.4, such as injection, cross-site scripting, cross-site request forgery and access control bypass. Keep the scan reports for each release, along with the triage decision for every finding: fixed, accepted with a documented reason, or false positive. Semgrep Community Edition (LGPL-2.1-only) can run in CI/CD pipelines with community or custom rules across many languages, including Java, JavaScript, Python and Go. Confirm the rule set and language coverage for your codebase before relying on it, and record which rules were active on each date.

Software bill of materials per release

An SBOM for each release shows which third-party components sit inside the bespoke software, which supports the review of component risk that 6.3 also requires. Generate the SBOM as part of the build and store it with the release record. Trivy (Apache-2.0) can produce an SBOM from OS packages and dependencies and can scan existing SBOMs. OWASP Dependency-Track (Apache-2.0) consumes CycloneDX SBOMs, flags known vulnerabilities and license risk, and keeps a history of components by project. Confirm the CycloneDX and SPDX support in the versions you deploy. Retain each SBOM alongside the release it describes.

What meeting PCI DSS 6.2 costs in money and effort

This table compares each cost component of meeting Requirement 6.2, who is paid for it, whether it is one-time or recurring, and what drives it up or down. Use it to build a like-for-like quote request, since most lines scale with repositories, releases and developers rather than with a fixed price.

Cost component	One-time or recurring	What drives it up	How to keep it down
Tooling and licenses	Recurring for hosting, one-time for setup	Number of repositories and pipelines, self-hosted server sizing, storage for scan results and SBOMs. GitLab Community Edition, Semgrep Community Edition, OWASP Dependency-Track and Trivy carry open-source licenses, so license spend can be zero	Confirm which community editions fit your repositories and languages. Budget for hosting, storage and maintenance, which remain even when licenses are free
Engineering time for protected branches and the pipeline	One-time, with periodic updates	Number of repositories, branch rules, pipeline complexity, and how many languages the static analysis must cover	Standardize branch protection and pipeline templates across repositories so each new project reuses them
Developer training	Recurring, at least every 12 months under Requirement 6.2.2	Number of developers working on bespoke and custom software, and whether training covers the security testing tools in use	Ask for a course that covers your languages and tools, and schedule it once a year for each developer team
Manual code review time per release	Recurring, every release	Release frequency, size of changes, number of reviewers needed to keep reviewer and author separate, and management approval steps	Use automated scanning to reduce manual review load, and keep changes small so reviews stay focused
Evidence upkeep	Recurring	Number of releases and repositories generating records, depth of traceability from change to review to approval, and retention period set by your own policy	Generate evidence from the pipeline and ticketing system automatically rather than by hand each release
External secure code review or application testing	Recurring, usually per engagement	Application count, code volume, release cadence, and whether testing covers business logic and access control or only automated findings	Ask for a written scope listing applications, release frequency and the testing model, then compare quotes against that scope
Assessor sampling during the QSA or self-assessment	Recurring, at each assessment cycle	Number of bespoke applications in scope, number of releases sampled, and how well evidence is organized before the assessor arrives	Prepare a sample-ready evidence set per application and confirm the assessor's sampling approach in writing before fieldwork

Who does what for PCI DSS 6.2: your team, a partner and the assessor

Your organization owns the software development lifecycle, the decisions it produces and the proof that it operated. Requirement 6.2 is a statement about how your developers work, so the policy, the training program, the review standard and the approval of each release must come from people inside the entity. Accountability for the software also stays with you even when external parties help build or test it.

Development process: Define the secure SDLC, the steps every bespoke or custom change passes through and who may approve each one.
Training program: Choose the curriculum, schedule and records that show each developer was trained at least once every 12 months on software security, secure coding and the security testing tools in use.
Code review decisions: Name the reviewers, confirm they are not the code author, and have management approve the release after manual review.
Review standard: Own the rules for what a manual review checks, including the attack classes in 6.2.4 such as injection, XSS, CSRF and access control bypass.
Evidence retention: Keep training records, review records, approvals and scan results in a location you control and can produce on request.

Check that each of these items has a named owner and that the owner can show the records without help from a vendor.

Where organizations fall short on PCI DSS 6.2

Most 6.2 findings are not missing tools. They are gaps in records: training that lapsed, reviews that were not independent, approvals that came after release, and scan results nobody triaged. Assessors test whether the process actually ran each time, so each card below names a gap, the reason an assessor flags it and the fix to put in place.

Training done once and never repeated

Many teams run secure coding training at onboarding and then assume it is covered. Requirement 6.2.2 expects developers of bespoke and custom software to be trained at least once every 12 months on software security, secure design and coding, and any security testing tools they use. An assessor will ask for the training date of each developer in scope and will flag anyone whose last record is older than 12 months. Fix it by keeping a training log per developer, with dates and topics, and tying renewal to a calendar reminder owned by the engineering manager.

Reviews by the code author

A manual review performed by the person who wrote the change does not count as an independent check. Requirement 6.2.3.1 requires manual code reviews to be done by someone other than the code author who knows code review and secure coding. Assessors look at pull request history for self-approvals and at reviewers' training records to confirm secure coding knowledge. Fix it by blocking self-approval in the repository settings and by naming a small group of trained reviewers for security-relevant changes.

Approvals recorded after release

Some teams deploy first and record management approval later, or treat a ticket comment as approval. Requirement 6.2.3.1 requires management approval of manual code review results before release, so the order matters to an assessor. Check the timestamps of the review, the approval and the deployment. Fix it by making the approval a required step in the merge workflow, so the release pipeline cannot run until the approval exists and is attributed to a named manager.

Review records not linked to releases

A review that exists in a chat thread or a spreadsheet cannot be traced to the code that shipped. An assessor typically picks a release, then asks for the review that covered its changes. If the record cannot be matched to the commit or build, the sample fails. Fix it by keeping the review in the merge request and tagging each release with the merge requests it contains, so the chain from change to review to approval to deployment can be traced in one place.

Scan findings never triaged

Teams often run static analysis in CI and then let findings pile up with no owner, severity or disposition. Semgrep Community Edition can scan repositories continuously in CI/CD pipelines, but scanner output alone is not evidence of review before release. Assessors ask what happened to each finding, whether it was fixed, accepted with a reason or marked as a false positive. Fix it by setting a triage rule in the pipeline, assigning owners to new findings and keeping the disposition with the code review record.

Attack classes left uncovered

Requirement 6.2.4 lists attack classes that engineering techniques must prevent, including injection, attacks on data structures, cryptography misuse, business logic abuse such as cross-site scripting and cross-site request forgery, and access control bypass. A team that tests only injection and XSS leaves access control and business logic unaddressed. Assessors ask which technique covers each class. Fix it by mapping each class to a named control in the development standard, such as parameterized queries, output encoding, CSRF tokens and authorization checks on every endpoint, and testing each one.

Bespoke and third-party software mixed

Requirement 6.2 applies to bespoke software, which a third party builds to the entity's specifications, and custom software, which the entity builds for its own use. It does not apply to third-party commercial or open-source software the entity merely uses. When both sit in one inventory without a flag, reviewers cannot show which components the requirement covers. Fix it by tagging each application as bespoke, custom or third-party, and generating a component inventory per application with Trivy or Dependency-Track so the boundary is visible.

Common questions about PCI DSS 6.2 cost, effort and outside help

How much effort does PCI DSS 6.2 take for a small team with one repository?

For a small team with one repository, most of the effort goes into paperwork and process rather than tooling: a short secure development procedure, a training record for each developer, branch rules that force a second person to review every change, and retained evidence of each review. No figure is given here because the effort depends on how many people commit code, how often releases ship and whether the existing workflow already records reviews. Ask your assessor or partner to walk through your repository and release history before estimating hours.

What drives the cost and effort of meeting PCI DSS 6.2 up?

Cost rises with the number of bespoke applications in scope, the number of developers and contractors who write code, the number of release pipelines, and how much of the review and training record is missing today. Gaps in the pipeline matter most: if manual reviews are not recorded, or if reviewers are the same people who wrote the code, the team must redesign the process and collect evidence for past releases. Ask any provider to quote each of these inputs separately so you can see which ones move the price.

Can an organization meet PCI DSS 6.2 without an outside partner?

Yes, an organization can meet Requirement 6.2 with its own staff, because the requirement applies to the entity that develops its software. The organization owns its controls and must produce the evidence an assessor will test. Internal teams often need help with secure coding training content, branch protection setup and documentation, and a partner can supply those pieces. Whether you need outside help depends on your team's experience with secure development and the size of your codebase.

What does a partner need from my team to start work on PCI DSS 6.2?

A partner typically needs read access to the source code repositories in scope, access to the CI/CD pipelines that build and release that code, a list of developers and their roles, and the release history for the past several months so that current practice can be assessed. It should also receive the existing secure development policy, any training records and any code review tickets. Access should be granted through named accounts with the least privilege needed, and the written scope should list exactly which repositories and pipelines are covered.

How long does PCI DSS 6.2 work take, and what sets the timeline?

No duration is given here. The timeline is set by the written scope, which should state the repositories, pipelines, number of developers, the current state of training and code review, and the deliverables agreed before work starts. Timelines also depend on how quickly your team can grant access and approve changes to the development process. Ask for a timeline tied to specific milestones, and confirm with your assessor when evidence must be available for the assessment period.

Do free open-source tools satisfy PCI DSS 6.2 on their own?

No. Open-source tools such as GitLab Community Edition, Semgrep Community Edition and OWASP Dependency-Track produce evidence that supports Requirement 6.2, such as branch protection settings, scan results and component inventories. They do not satisfy the requirement by themselves, because the organization still has to define the process, train developers, perform and record the manual code review, and show that the process runs consistently. Confirm each tool's current capabilities and license terms in its own documentation before relying on it.

Does automated scanning alone meet the manual code review requirement in 6.2.3.1?

No. Requirement 6.2.3.1 requires manual code reviews, performed by someone other than the code author who knows code review and secure coding, and approved by management before release. Automated scanning, such as static analysis run in a pipeline, supports the review and can flag common issues, but it does not replace a person reading the change. Your evidence should show who reviewed each change, that the reviewer was not the author, and that management approved the release.

Can the same firm implement the 6.2 controls and then assess them?

Generally not for the same entity. A partner can design, implement and document the secure development controls and prepare the evidence, but it cannot issue the assessment or report on controls it designed for you. Only an independent Qualified Security Assessor can complete the Report on Compliance. Keeping these roles separate protects the assessment's credibility. Ask your assessor early whether any planned partner work would affect their independence, and agree the division of responsibilities in writing.

How DeployOpen scopes and prepares PCI DSS 6.2 evidence

DeployOpen plans, implements and hardens self-hosted open-source platforms inside your own infrastructure, including the source control, pipeline and scanning tooling that produce 6.2 evidence. We prepare the systems and records for your assessor, while your organization owns the controls and an independent QSA issues the report.

How we scope

We confirm which applications are bespoke or custom software in your cardholder data environment, separating them from third-party software that 6.2 does not cover.
The written scope names the repositories, pipelines, developer groups and training records we will set up or review for 6.2.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts, and ongoing support is available as a retainer.

How we build

We configure protected branches so no one pushes directly to release branches and manual reviews must come from a second person.
We add static analysis to CI/CD pipelines to scan code for injection, XSS and access control issues before merge.
We track components with a software bill of materials and dependency tooling, so review records tie back to the code actually shipped.

How we hand over

We document the secure SDLC, review rules, approval steps and tool configurations so your team can run them without us.
We deliver a 6.2 evidence index mapping each sub-requirement to the repository settings, pipeline logs and records an assessor will request.
We confirm with your QSA which evidence format they accept, since the assessor decides what satisfies the requirement.

How we support

Retainers can cover tool upgrades, rule tuning and periodic review of review and approval records as the codebase changes.
Developer training records for 6.2.2 remain your responsibility, and we can help document course content and tool coverage.
Ask any provider to confirm in writing which tasks are one-time setup and which recur each year, so budgeting reflects both.