How GitLab supports PCI DSS requirement 6 and where it stops
GitLab can help with PCI DSS requirement 6 by producing evidence for secure development and change control, but it does not replace the controls themselves, the assessor, or the Report on Compliance or Self-Assessment Questionnaire. If your organization is a merchant, processor, acquirer, issuer or service provider in scope, and it builds custom software that touches the cardholder data environment, GitLab can hold the records that show how that software was reviewed, tested and approved before release. On the 6.2 side, merge requests with required approvals, protected branches and pipeline logs can support the pre-release code review expectations of 6.2.3 and the approval step of 6.2.3.1, provided reviewers are someone other than the author and your policy defines who qualifies. Security scanning jobs in pipelines can contribute to the attack-class testing of 6.2.4 and the testing expectations in 6.5.1, but the scanners find only what their rules cover.
Requirement 6.3 is where the component inventory and patching records sit. GitLab can generate software bills of materials and dependency lists from pipelines, which can feed the inventory expected by 6.3.2, but you must confirm which languages, package managers and bespoke components your scanners actually cover. Vulnerability risk ranking under 6.3.1, patch timing under 6.3.3 and the decision to accept a risk remain people and policy work that GitLab only records. The 6.5 change procedures also depend on your process: separating roles between developers and production, removing test data before go-live and documenting security impact are decisions your change board must make, and GitLab approvals and protected environments can show that those decisions were followed.
Ask your assessor early which evidence they will accept, including how they expect pipeline and approval records to be retained and exported. Confirm what your current GitLab edition provides, since security scanning and compliance features are tied to tiers listed on the GitLab pricing page, and confirm with your QSA whether the customized approach is relevant to your environment. Plan the evidence gaps, such as manual review quality and training records, before the assessment begins rather than during it.
Mapping PCI DSS 6.2, 6.3 and 6.5 to GitLab features and configuration
This table maps PCI DSS v4.0.1 requirement 6 sub-requirements to the GitLab capability that supports each one and the setting you must configure. Closely related sub-requirements are grouped into single rows, and the coverage column marks where GitLab supplies evidence but a written process or manual check must still be completed. Confirm which features each GitLab tier includes before you finalize the design.
| Requirement | GitLab capability | Configuration to set | Coverage |
|---|---|---|---|
| 6.2.1 and 6.2.2: secure development and annual developer training | Shared project templates and documented contribution standards in the repository | Add secure coding standards to a group-level project template and README. Record training completion outside GitLab and link it to reviewer assignments | Partial |
| 6.2.3 and 6.2.3.1: pre-release code review by a second, qualified person with management approval | Merge request approval rules, code owners and author self-approval controls | Require at least one reviewer other than the author, enable code owners, and block author self-approval. Use a separate approval step for management sign-off | Partial |
| 6.2.4: preventing common software attacks such as injection and access control bypass | Security scanning jobs in pipelines (static testing, dynamic testing and secret detection) | Include scanner templates in each pipeline and block merges on critical findings. Scanners do not cover every listed attack class, so keep manual review in place. Confirm scanner availability by tier | Partial |
| 6.3.1: identifying vulnerabilities from industry sources and assigning risk rankings | Vulnerability management and dependency scanning findings | Triage findings into a tracked register, assign severity, and document your risk ranking method in project policy. The ranking criteria come from your own process | Partial |
| 6.3.2: inventory of bespoke software and third-party components | Dependency lists and software bill of materials generated from pipelines | Generate dependency lists on each build and store the output as release artifacts. Confirm the SBOM output format and which tier includes it | Supported, confirm tier |
| 6.3.3: installing security patches and updates | Merge requests and scheduled pipelines for dependency and base image updates | Schedule dependency update pipelines, require review, and track patch deadlines. Plan GitLab instance patching on the stable release cadence, since security fixes reach the previous two monthly releases | Partial |
| 6.5.1: documented, approved and tested production changes with a rollback path | Protected environments, deployment approvals and pipeline and deployment history | Protect production with approval rules and limit who can deploy. Use merge request templates to record security impact, and keep pipeline records as change evidence. Rollback steps stay in your runbook | Supported, confirm tier |
| 6.5.2, 6.5.3 and 6.5.4: re-confirming PCI controls after significant change, separating pre-production from production, and separating duties | Protected branches, environment scoping and separate projects or groups | Keep production projects and runners separate from pre-production. Restrict maintainer rights on protected branches and scope CI variables to each environment. Re-check PCI controls through your own change process | Partial |
| 6.5.5 and 6.5.6: no live card numbers in test environments and removal of test data and accounts before go-live | No built-in check for live card numbers in test data. Pipeline jobs and a go-live checklist provide the controls | Use masked or synthetic test data, restrict copies of production data, and add a go-live step that removes test accounts. Confirm whether any scanner in your tier detects card numbers | Partial |
Which GitLab records an assessor can review
Most of the evidence for requirement 6 already exists in GitLab as a side effect of normal delivery work. The value comes from deciding which records to keep, where they live, and who reviews them before an assessor asks. The qualified security assessor decides whether any record is sufficient for the requirement.
Merge request approvals and review history
Each merge request holds the reviewer list, approval decisions, comment threads and the commits reviewed. For requirement 6.2.3.1, check that the approver is someone other than the code author and that the review shows security-relevant reasoning, not only a click. Export or snapshot these records on a schedule so they survive project archiving. Confirm which review fields appear in your version's export.
Protected branch and approval rules
Protected branch settings and approval rules show who could merge to release branches and what approvals were mandatory at the time. Assessors look for evidence that the rules were enforced, so keep a dated record of configuration changes. Ask a security reviewer to confirm that administrators cannot bypass these rules without a logged exception. Confirm how your version records rule changes before relying on them.
Pipeline and security scan results
Pipeline logs and scanner reports show which tests and security checks ran against each change, and whether findings blocked the merge. These records support the expectation that custom software changes are tested against the attack classes in requirement 6.2.4. Retain the job logs and report artifacts for the period your assessment covers, and confirm the artifact expiry settings in your configuration. Scanner coverage depends on your tier, so confirm which scanners you license.
Component and dependency records
Dependency scanning output, software bill of materials files and the project's lock files support the software and component inventory in requirement 6.3.2, which is required now rather than best practice. Generate the inventory from the pipeline so it matches each release, and store it with the release record. Ask your QSA how they expect the inventory to be organized for bespoke code and third-party components.
Environment deployment history
Deployment records and protected environment settings show what reached production, when, and under which approval. Together with the pipeline history, they help show separation between pre-production and production under requirement 6.5. Check that production deployments can only be triggered by authorized roles, and review that list at each assessment cycle. Confirm how deployment records are retained and exported in your version.
Audit events and access records
Audit events record changes to users, groups, projects and settings, and support the change authorization trail that sits beside code review. Decide where exports are stored, who can read them, and how long they are kept. Test that a sample change can be traced from request to approval to deployment. Confirm the exact event names and exported fields in your version, because they vary by release.
Configuring GitLab for requirement 6 evidence
This sequence turns a self-managed GitLab instance into a controlled system of record for PCI DSS requirement 6 evidence, covering scope, approvals, scanning, environment separation, retention and a dry run with the assessor. Each step ends with an artifact you can show a Qualified Security Assessor or internal reviewer.
Confirm PCI scope of repositories and environments
Start by listing every repository, pipeline, runner and deployment target that builds or releases software touching the cardholder data environment or that could affect its security. Your compliance lead and the engineering owners should agree the list, and your assessor should confirm it, because scope decides which projects must follow the approval and testing controls. Record the decision in a scope register stored in GitLab. You are done when each in-scope project has a named owner and a documented reason for inclusion or exclusion.
Decide the self-managed deployment and tier
Choose the install method, hosting location and GitLab edition that will hold the evidence. The GitLab installation methods page lists the Linux package, Helm chart, GitLab Operator, Docker and source installs, and the offline environments page covers air-gapped operation. Map the features you need, such as merge request approvals, security scanning and compliance controls, against the pricing page tiers, and confirm with GitLab which features your chosen tier includes. Document the decision with a version, a backup plan and an upgrade plan, since upgrades must pass through required upgrade stops. You are done when a signed architecture note covers hosting, tier and the upgrade and backup owners.
Enforce protected branches and reviewer approvals
Configure protected branches so that no one can push directly to release branches, and set merge request approval rules so that at least one approver other than the author must review each change before merge. Requirement 6.2.3.1 expects manual reviews by someone who knows secure coding and approval by management before release, so the approval rule should name the reviewer group and, where your policy requires it, a management approver. Test the rule by attempting a self-approved merge in a sandbox project. You are done when a self-approved change is blocked and the approval settings are exported as configuration you can show an assessor.
Configure pipelines with scanning and component inventory
Add pipeline jobs for the security scanners your tier supports, along with a software bill of materials or dependency inventory for each in-scope project. These outputs support requirement 6.3.2, which now requires an inventory of bespoke software and third-party components, and they feed the vulnerability risk ranking expected under requirement 6.3.1. Decide which findings block a merge and who triages the rest, and write that rule down. Confirm with your scanner vendors and GitLab documentation which scanners run offline if your instance is air-gapped. You are done when a pipeline run on a sample project produces scan reports and an inventory artifact that are retained with the build.
Separate pre-production and production runner access
Create separate environments and protected deployment targets for pre-production and production, and restrict who can trigger production deployments. Assign runners to these environments so that production jobs execute only on runners dedicated to production and cannot be started from unreviewed branches. This supports the separation of duties and environment separation expected under requirement 6.5. Keep the runner major and minor versions aligned with GitLab, as the Runner documentation advises. You are done when a test branch cannot deploy to production and the runner tags and environment rules are recorded in configuration.
Set retention and export for audit records
Decide how long merge requests, approval history, pipeline logs, scan reports and audit events are kept, and who can read them. Export audit events and evidence to storage that GitLab administrators cannot alter, and document the export schedule and the person responsible. Your retention period should come from your PCI assessor and your payment brand requirements, so confirm it before you set it. Backups are part of this step: follow the GitLab backup and restore documentation, test a restore into a separate instance, and confirm that the restored instance still shows the approvals and pipeline records. You are done when a restore test reproduces a sample merge request with its approval trail.
Run a dry-run evidence walkthrough with the assessor
Before the formal assessment, walk the assessor through one release from start to finish: the scope register, a merge request with an independent reviewer, the scan and inventory outputs, the production deployment record and the exported audit trail. Ask the assessor which artifacts they expect for each sub-requirement and whether the defined or customized approach fits your controls. Record gaps as tasks with owners. Keep the walkthrough record as part of your assessment evidence. You are done when the assessor confirms the sample release contains the evidence they need, or the gap list is assigned and scheduled.
How a change moves from merge request to production with evidence
The evidence for requirement 6.2.3.1 and requirement 6.5.1 is created at specific points in one path: the author opens a merge request, the pipeline runs, a reviewer who is not the author records a review, an approver signs off, and the deployment is tied to that approval. Each step produces a record you can point an assessor to, so decide early which people and roles fill the reviewer and approver positions. Your organization defines those roles, and GitLab only enforces the rules you configure. Write down who may review code in each project, who may approve for management, and what happens when the author is the only available person with the right skills.
The merge request is the main record for 6.2.3.1. Enable approval rules that require at least one approver other than the author, and block self-approval so the author cannot count toward the required approval. Reviewer comments, approvals and the diff are kept on the merge request. For 6.2.4, add the secure coding checks you rely on to the pipeline, such as GitLab's SAST and secret detection templates, so the review record also shows the automated checks that ran against the change. Confirm which scanners your edition includes, because the pricing page places application security testing in the Ultimate tier. Protected branches restrict who can push to the release branch, so changes reach it only through a reviewed merge request.
The deployment step supports 6.5.1, which requires documented security impact, approval by authorized parties and a way back to a secure state. Use protected environments so only the approved roles can start a production deployment job, and keep rollback jobs in the same pipeline so a failed change has a defined return path. Audit events record permission changes and approvals, but confirm with your own testing which events export to your retention system and how long your instance keeps them. Before you go live, run a sample change end to end and check that the merge request, pipeline, approval and deployment records link to one another in a way an assessor could follow.
Questions buyers ask about GitLab and PCI DSS requirement 6
Does using GitLab make our organization PCI DSS compliant?
No. GitLab is a tool that can produce evidence for requirement 6, but compliance is decided by your assessor after reviewing your processes, people and records. PCI DSS is maintained by the PCI Security Standards Council, which does not enforce compliance itself. The payment brands decide who must validate, and assessments are documented on a Report on Compliance completed by a Qualified Security Assessor or on a Self-Assessment Questionnaire, each with an Attestation of Compliance. Your assessor will check whether the merge request approvals, scan results and inventory records actually operate the way your written procedures say they do.
What drives the cost of setting up requirement 6 evidence in GitLab?
The main cost drivers are the number of repositories and pipelines in scope, how many approval rules and protected branches you need, which security scanners you enable, and how much of your existing process must be written down. GitLab's published pricing lists Free at 0 US dollars, Premium at 29 US dollars per user per month billed annually, and Ultimate as custom priced, with all three available for self-managed installations. The scanning and vulnerability management features that many requirement 6 controls rely on are listed under Ultimate, so the tier choice is often the largest recurring line. Ask any partner for a quote that separates one-time configuration and documentation work from recurring licence, infrastructure and support costs.
How long does it take to set up GitLab for requirement 6?
The duration depends on scope rather than on a fixed number. Teams with a small number of repositories, an existing approval process and a settled pipeline design need far less time than organizations that must redesign branch protections, split duties between developers and release staff, and integrate scanners across many projects. Time also depends on whether a self-managed instance already exists and how many environments need to be wired into the evidence trail. Ask for a written scope and timeline before work starts, and confirm which items are in and out of scope, including documentation of your secure development procedures.
What do we need from our own team for this work?
You will need named people in four roles: reviewers who can perform manual code reviews without being the code author, approvers who can authorize production changes and sign off on the review rules, repository owners who manage branch protection and project settings, and pipeline owners who maintain the CI/CD configuration and scanner jobs. Management must also approve the review process, because requirement 6.2.3.1 expects approval before release. Your team will also need to supply the current list of applications and their third-party components so the inventory under requirement 6.3.2 can be built from accurate starting data.
Can our internal team configure GitLab for requirement 6 without a partner?
Often yes, if your engineers know GitLab administration, CI/CD design and your PCI DSS scope. The work is largely configuration, documentation and evidence design, so the risk lies less in clicking through settings and more in gaps: a reviewer who is also the author, a pipeline job that can be skipped, or a release path that bypasses approvals. Before deciding, check whether the team has experience with the assessor's expectations for requirement 6.5.1 change records and can run a mock evidence pull. An outside partner can be useful for an independent review of the design, but whether to use one is your decision.
How did the 6.3.2 software inventory move from best practice to a requirement?
Requirement 6.3.2 requires an inventory of bespoke and custom software and third-party components, used for vulnerability and patch management. It was a best practice until 31 March 2025, when the future-dated requirements of PCI DSS v4.0 became effective, and it is now a required control under PCI DSS v4.0.1, the only active version. Before that date, organizations could mark it not applicable. In GitLab, the inventory is usually built from dependency and component data produced by pipelines, but you should confirm with your assessor that the output covers all in-scope applications and that the inventory is maintained as a living record.
How should we prepare for a Report on Compliance or SAQ with an Attestation of Compliance?
Start by agreeing with your assessor which path applies, a Report on Compliance completed by a Qualified Security Assessor or a Self-Assessment Questionnaire, and which official PCI SSC template the work will be documented in. Then prepare evidence for a sample of recent releases, including the review record, the approver, the scan results and the production deployment. Keep written procedures for secure development, change approval and vulnerability ranking current, and confirm that certificates from third parties are not accepted as validation. Finally, confirm which party signs the Attestation of Compliance, since the assessor or your organization completes it according to the path chosen.
Choosing between an internal build and an outside partner
The core decision is whether your own engineers can run the GitLab controls that Requirement 6.2 and Requirement 6.5 depend on, every release, for as long as the cardholder data environment exists. Protected branches, approval rules, pipeline-enforced scanning and retained merge request records are each simple to switch on once. What takes effort is keeping them correct as projects are added, runners change, and the GitLab version moves through its required upgrade stops. Before you choose, ask your team who owns the protected branch and approval configuration for every project in scope, who reviews changes to the pipeline definitions themselves, and who can show an assessor a complete, dated record of a release for a sample of changes.
An outside partner would start from a written scope: which projects, runners, environments and approval groups are in the cardholder data environment, which Ultimate or Premium features your edition covers, and which evidence an assessor will sample. The deliverables should be named in that document, such as the configured approval and branch rules, the scanning and component inventory outputs, a runbook for emergency changes and a list of open gaps. Most engagements of this kind are fixed-scope, so the scope and timeline are agreed before work begins. Ongoing upgrades, scanner tuning and periodic evidence reviews can be handled under a retainer if your team wants continuing support rather than a one-time build.
Some responsibilities stay with your organization whichever path you take. Management must approve releases as Requirement 6.2.3.1 requires, your Qualified Security Assessor or internal assessor decides whether the evidence meets the requirement, and the Attestation of Compliance is issued through the payment brand process, not by DeployOpen. Ask any partner to state in writing what it will not do, and ask your own team to confirm who will operate the GitLab instance, its backups and its runners after handover. A quote should separate the one-time build from recurring operation and upgrade work, so you can compare it fairly with the staff time your team would need to commit.
How DeployOpen scopes and delivers requirement 6 configuration
DeployOpen plans, implements, hardens and documents self-managed GitLab inside your own infrastructure, including the review, scanning, inventory and approval controls that requirement 6 depends on. We agree the scope in writing before work starts, so you know which requirement 6 sub-requirements the configuration is meant to support and what evidence it will produce.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- We confirm which cardholder data environment systems, repositories and pipelines fall inside the GitLab scope.
- We map merge request approval rules, protected branches and pipeline stages to the review and change steps you already run.
- We agree which assessor-facing evidence the written scope will produce, and which parts remain your responsibility.
How we build
- We configure approval rules so authors cannot approve their own merge requests and reviewers are drawn from a defined group.
- We add SAST, dependency and secrets scanning to pipelines, with findings routed to triage and recorded against each release.
- We set up component inventory generation from pipelines and confirm it is retained for each production release.
- We test the configuration against deliberate bypass attempts, including direct pushes to protected branches and unapproved merges.
How we hand over
- You receive configuration documentation covering approval rules, protected branches, runner isolation and scanning settings.
- We document how each control produces evidence, so your team or your Qualified Security Assessor can pull it without us.
- Runbooks cover adding reviewers, handling emergency changes and responding to failed scans or blocked pipelines.
- Knowledge transfer sessions are scoped in the written agreement, with your staff operating the configuration afterward.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, agreed separately from the initial scope.
- Upgrades follow GitLab's required upgrade stops, and we plan them against your change calendar before applying them.
- We can rerun bypass and scanning tests after significant changes to pipelines, approval rules or the runner fleet.
- Assessment decisions remain with your QSA and the payment brands, since DeployOpen prepares controls and evidence without issuing attestations.
