PCI DSS 6.1 secure development policies and roles

What PCI DSS 6.1 asks for and why assessors read the paperwork first

Requirement 6.1 asks for two things: current, documented policies and operational procedures for building and maintaining secure systems and software, and documented roles and responsibilities for the people who carry out that work. If you are a compliance lead or engineering manager, the practical question is whether you can hand an assessor a written secure development policy and name the person who owns each Requirement 6 activity, and then show that both are followed. Sub-requirement 6.1.1 covers the policies and procedures themselves. They must be documented, kept up to date, in use and known to everyone affected, including developers, reviewers, operations staff and anyone who approves a patch. Sub-requirement 6.1.2 covers roles. Who writes secure code standards, who triages vulnerabilities, who approves a change to production and who signs off on a release should each be written down, assigned and understood by the people holding those roles.

Undocumented development practice creates risk because it cannot be checked, handed over or repeated. When a senior engineer leaves, the team may not know which review steps were mandatory or which pipeline gates were optional. Assessors know this pattern well, so the SAQ D testing approach for 6.1.1 and 6.1.2 is to examine the documents and interview the people responsible. The evidence is usually a written secure development and change management procedure plus a roles and responsibilities record, such as a RACI matrix. Ask your assessor early which format they accept and whether they expect version history, approval dates and a review cycle.

This requirement is hard for two predictable reasons. The first is policies written once for an audit and never revisited, so the document describes a process that changed two tooling migrations ago. The second is roles that exist in practice but not on paper: a platform lead who approves every release, or a developer who quietly owns vulnerability triage. Before writing anything, walk through the last three releases and list who actually did each step. Then compare that list with the RACI and close the gaps, either by updating the document to match the real practice or by changing the practice to match a documented decision. Confirm with your assessor how they will sample evidence for your environment.

Which teams, systems and third parties the 6.1 policy and roles must cover

Requirement 6.1 only works if the policy and roles reach the people and systems that actually build and change payment software. The decisions below determine how much a team must document, and each one is worth settling in writing before an assessor asks.

In-scope development and change teams

List every group that writes, reviews, builds, deploys or approves code or configuration for systems in the cardholder data environment. That usually includes internal developers, DevOps engineers, release managers and the security team that signs off on changes. Check the list against your repository and deployment permissions, not against the org chart, because people with push or deploy rights often sit outside the teams you expect. Illustrative example: a platform engineer with production deploy rights who is not listed in any team is a gap an assessor will find.

Systems that build or change CDE components

Identify the CI/CD pipelines, source repositories, artifact stores, infrastructure-as-code repositories and configuration tools that can alter a component inside the cardholder data environment. Each one needs a named owner and a documented role for the activities it supports. A build server that signs release artifacts is as relevant to 6.1 as the application it compiles, so treat tooling as part of the scope rather than an afterthought.

Outsourced developers and software vendors

Contracted developers, offshore delivery teams and commercial software vendors that change your payment code or configuration fall inside the policy's reach even when they are not your employees. Confirm which of your procedures they must follow, who approves their commits and how their roles appear in your roles record. Ask each third party to show its own secure development practices, and keep the contractual responsibilities in writing so the split between your team and theirs is clear to an assessor.

One policy or separate development, patching and change documents

Decide whether a single Requirement 6 policy covers secure development, vulnerability and patch management and change management, or whether each activity has its own document. A single policy is easier to keep current and to show as in use, but it grows long and harder to maintain. Separate documents suit larger teams with different owners, provided they cross-reference each other and assign the same roles consistently.

How narrower scope cuts the roles list

Every team, system and third party in scope adds roles that must be documented, assigned and understood. A narrower boundary, such as a separate payment application that only a small group can change, reduces the number of roles, approvals and procedures to maintain. Before narrowing, confirm the boundary is defensible, because systems that can affect the security of the cardholder data environment stay in scope regardless of where they sit.

How an assessor tests the secure development policy under 6.1.1 and 6.1.2

This table compares how an assessor tests each sub-requirement of 6.1, what evidence they ask for and where organizations usually fall short. Read each row as the assessor's checklist: confirm the document exists and is current, then confirm staff know it and the roles are real people with real assignments.

Sub-requirement	Test approach	Evidence requested	Common findings
6.1.1 Policies and procedures	Examine the secure development and change management policy and procedures for currency, approval and scope, then interview developers, testers and release staff to confirm they know and follow them.	Approved policy with version history and review dates, linked operational procedures, training or acknowledgment records, and a sample of recent releases showing the procedure was followed.	Policy last reviewed years earlier with no owner; procedures describe a pipeline the team no longer uses; a developer's account of the release process contradicts the written steps.
6.1.1 Currency check	Compare the document's review date and content with current tooling, repositories and release practice.	Revision history, change log for the policy, and a list of tools named in the procedure that still exist in the environment.	Policy names a retired code review tool or branch model; no evidence of an annual review or update after a significant process change.
6.1.2 Roles documented	Examine the roles and responsibilities record for development, patching and change management activities, then check each role has an assigned owner.	RACI matrix or equivalent covering secure development, vulnerability patching and change approval, with named individuals or named groups with membership lists.	A role such as security approver has no named person; the same person is listed as both developer and sole approver for production changes.
6.1.2 Roles understood	Interview the people named in the matrix and ask them to describe their responsibilities without reading the document.	Interview notes, role acknowledgment records, and onboarding material that explains each role's duties.	Interviewee does not recognize the role assigned to them; responsibilities for patching sit with a team that believes the vendor handles them.
Interview consistency	Compare what interviewees say about approvals, testing and release with what the policy and RACI state.	Notes from interviews and matching samples from the change or ticketing system.	An interview answer contradicts the document, for example an engineer says emergency changes skip review while the policy requires it for all changes.
Access to the record	Confirm the policy and roles record are stored where assigned staff can read them and that changes are tracked.	Wiki or repository history showing who edited the document and when, plus the current access list for the record.	Policy exists only as an unversioned file on one person's drive; nobody outside the security team can find it.

Steps to write the policy, assign the roles and make both usable

This sequence turns Requirement 6.1 from a document on a shelf into a current policy, a named set of owners and a record that staff and assessors can check against how work actually happens. Each step closes with an artifact you can show a QSA or internal assessor.

Inventory the teams and tools involved
List every team that touches bespoke software, configuration changes, patching or releases, including developers, platform engineers, security, operations, QA and any outsourced development partner. Next, record the tools they use to track work, store code, review changes, run pipelines and document procedures. The output is a short inventory with each team, its tools and the systems it changes inside or near the cardholder data environment. You are done when a team lead confirms the list is complete and nothing obvious is missing.
Draft the secure development and change procedures
Write the policy as a short statement of intent, followed by procedures that describe how secure development and change management actually run, from requirement intake through code review, testing, approval and release. Name the tools each step uses, for example a protected branch in GitLab Community Edition or a static analysis job in CI using Semgrep Community Edition, so the procedure matches the systems you run. Keep the wording specific enough that an assessor can compare it with a sample of real tickets and commits. The output is a draft document with a version number and an owner.
Assign a named owner and backup for each activity
For each Requirement 6 activity, such as secure development, vulnerability handling, patch deployment and change approval, name one accountable person and one backup who can act when the owner is unavailable. Confirm that each person accepts the responsibility in writing and understands what it covers. Avoid assigning activities to a team alias or a job title with no individual behind it. The output is an assignment list in which every activity has an owner and a backup, and each name has been acknowledged.
Record the roles in a RACI matrix
Build a RACI matrix that maps each Requirement 6 activity to who is Responsible, Accountable, Consulted and Informed, using the teams from the inventory and the owners from the previous step. Check that every activity has exactly one Accountable party and that approval rights do not sit with the person who builds the change. Store the matrix in the same controlled location as the policy so both can be versioned together. The output is a RACI record with a date and version, which an assessor can compare with the interview answers of staff.
Obtain approval and communicate the documents
Route the policy, procedures and RACI matrix to the people who are accountable for security and for the affected systems, and record their approval with name, role, date and version. Then brief each affected team on the documents and on the parts of their own work they cover, and keep a sign-off log showing who received and acknowledged them. Keeping this log is what proves the documents are known to affected parties, not just written. The output is an approved version and a sign-off log with an acknowledgement from each affected group.
Set a review trigger and keep the record current
Define the events that require the policy, procedures or RACI matrix to be reviewed, such as a significant change to the development toolchain, a reorganization of teams, a change of owner, a new outsourced development partner, or a new version of the standard. Add a scheduled review as well, with the interval your organization sets and records. When a trigger fires, update the document, issue a new version and repeat the approval and communication steps. The output is a review schedule and a change history that shows the documents stayed in use and up to date.

How to keep the policy current between assessments

Most 6.1 findings are not caused by a missing document. They come from drift: the secure development and change management policy describes a process that the team has since changed, replaced or stopped following. Teams reorganize, people leave, a repository moves to a new code host, or a scanner is swapped for another one, and the written procedure stays the same. An assessor who examines the documentation and then interviews the people responsible will notice the gap quickly. Treat the policy as a living record with a named owner, and check it against how work is actually done at least once a year and whenever something material changes.

Set explicit review triggers so that updates happen when they should, not when the next assessment is scheduled. The useful triggers are a change in team membership or the RACI matrix, a change to the toolchain such as the wiki, the branch protection rules in GitLab, or the Semgrep rules run in CI/CD, a new version of PCI DSS (v4.0.1 is the only active version, and the Council has not announced a date for its successor), a significant security incident, and a failed sample during internal review. Assign sign-off to a role that owns the outcome, usually the security lead for the policy and the engineering manager for the procedure, and record the approval date and version in the page itself.

To show the policy was in use across the assessment period, keep evidence that the procedure ran, not only that it was written. XWiki and BookStack keep page version history and permission records, so the revision trail shows what changed, when and by whom. Protected branch settings and merge records in GitLab show that changes followed the review path. Ask your assessor early which evidence period they will sample and which documents they expect to see as of the start of that period. Confirm the retention settings of your wiki, code host and CI logs, because history that is purged on a schedule cannot demonstrate continuity.

Which evidence artifacts pass 6.1 and how to keep each one current

Requirement 6.1 is tested by examining documents and interviewing the people who own them, so an assessor needs the written policy, the procedures, the role assignments and proof that both are used. Each artifact below answers a different question, and each drifts out of date in its own way.

Approved secure development and change policy

The policy states how software is built, reviewed and changed for Requirement 6. An assessor checks that it is current, approved by a named owner and covers development, patching and change management together. Confirm that the version in force matches what teams actually do, and that the document names PCI DSS v4.0.1 as its reference. Keep the version history visible so the assessor can see when each change was approved and why.

Operational procedures for development work

Procedures turn the policy into steps: how a feature is designed, how code is reviewed, who can merge, and how a release is approved. Assessors look for procedures written at a level another engineer could follow. Refresh them when tooling changes, such as a new branch rule or scanner, and after any incident that exposed a gap. Protected branch settings in your code host should match the written steps rather than contradict them.

Roles and responsibilities record

A RACI matrix or equivalent table assigns each Requirement 6 activity to a responsible, accountable, consulted or informed party. Assessors compare it against the org chart and interview the named people to confirm they understand their duties. Review it after every reorganization, departure or vendor change, because an assignment to a former employee is an easy finding to make. Record the approver and date on the matrix itself.

Staff acknowledgements and training records

Acknowledgement records show that developers, testers, release managers and operations staff have read the current policy and procedures. Assessors sample individuals and ask them to explain their role, so the record must match the people in the RACI. Re-collect acknowledgements whenever a document changes materially, and keep leavers and new joiners in the cycle. Ask your assessor which format they accept, such as a signed register or system export.

Review log with dates and approvers

A review log lists each document, its owner, the date it was last reviewed, the reviewer and the outcome. It proves the documents are kept up to date rather than written once. Set a review cadence in the policy itself and show that reviews happened on schedule, including reviews where nothing changed. Gaps in the log are the most common reason an assessor questions whether a document is current.

Sample records of development and change work

Samples such as merge requests with approvals, change tickets and release sign-offs show the procedures operating in practice. Assessors pick a handful of recent changes and trace each one back to the written steps and the named roles. Pull a representative set before the assessment, check that each sample shows the expected approver, and fix any changes that skipped the process before presenting them as evidence. Semgrep scan results in CI can also show that secure review steps ran.

What meeting 6.1 costs in money and effort

This table breaks down the cost components of meeting requirement 6.1, who gets paid for each, whether the cost is one-time or recurring, and what moves it up or down. Use it to build a quote request, since the largest spend is usually people time rather than software licenses.

Cost component	One-time or recurring	What drives it up	How to keep it down
Tooling or licenses for documentation and access control	Recurring license or subscription fees for commercial wiki, document or repository tools; open-source options such as XWiki, BookStack and GitLab Community Edition remove license spend	Commercial licenses priced per user, large numbers of contributors or approvers, add-on modules for audit trails or approval workflows	Use self-hosted open-source tools where they fit your environment; budget for hosting, backups, patching and administration, which still recur
Engineering and management time to write and approve the policy	One-time for initial drafting; recurring for each review cycle	Many teams to consult, no existing secure development lifecycle to build from, unclear ownership of development and patching	Start from existing engineering practices, assign one accountable owner, and agree the approval path before drafting begins
Evidence upkeep and periodic review	Recurring, tied to each change in teams, tools or release process	Policies that drift from actual practice, roles that change without records, documentation kept outside version control	Keep procedures in version-controlled documentation, link roles to a RACI record, and schedule reviews after organizational changes
External review or consulting help	Usually one-time for gap analysis or policy review; may recur for retained advisory support	Limited in-house familiarity with the standard, a large number of bespoke applications, short timelines before an assessment	Ask for a written scope that names deliverables, review rounds and who owns the final documents; keep the consultant separate from the assessor
Assessor time spent sampling documents and interviewing staff	Recurring with each assessment cycle, paid to the independent assessor or QSA	Policies that are hard to locate, roles that staff cannot describe, large numbers of applications or teams to interview	Keep one current policy set, make roles easy to find and confirm that interviewed staff know their duties before the assessment

Which self-hosted open-source tools can produce 6.1 evidence

Requirement 6.1 is met by written policy, procedures and a roles record that people actually follow. The four tools below can hold that material and generate traces of its use, but each covers one slice of the evidence, and none satisfies 6.1 on its own. Confirm each fit against your environment and complete a licence review before you rely on it.

XWiki for policy version history

XWiki keeps every change to a page under version control, recording what changed, when and by whom. Assessors reviewing 6.1.1 look for a current policy and evidence that it is maintained, so the version trail shows review activity over time. Users can compare any two versions and roll back to an earlier one, which helps when an approved procedure is edited without sign-off. Check that your review and approval workflow lives outside the wiki history, and confirm the licence terms under LGPL-2.1-or-later with your legal team. Version history proves edits, not approval.

BookStack for controlled access

BookStack assigns user abilities through roles, and permissions can be overridden per role at the shelf, book, chapter or page level. This lets you limit who can edit the secure development policy while the wider team can read it, which supports the requirement that policies are known to all affected parties. Map the roles in BookStack to the roles in your 6.1.2 record so the two documents agree. Confirm the MIT licence terms and test that permission overrides behave as you expect before an assessor walks through them.

GitLab protected branches for change roles

GitLab Community Edition lets maintainers restrict which roles can push or merge to a branch. Setting push access to no one blocks direct pushes, and force pushes stay disabled unless explicitly allowed. These settings give technical evidence that development and release roles are enforced in code, not only described on paper. The 6.1.2 record should match the roles configured here. Confirm which protected branch settings your GitLab edition and version provide, and verify the MIT licence terms before adoption.

Semgrep for pipeline code scanning

Semgrep Community Edition scans code in many languages, including Java, JavaScript, Python, Go and Terraform, using community or custom rules. It can run in CI/CD pipelines to scan repositories continuously. Its output shows that secure coding checks run as part of the development process, which supports the secure development procedures 6.1.1 asks for. Choose rules that reflect your own secure coding standard, and confirm that your languages appear on the supported list. Review the LGPL-2.1-only licence terms with counsel before embedding it in your pipeline.

Who writes, who builds and who assesses the 6.1 work

Your organization owns Requirement 6.1. The policy, the procedures and the role assignments must reflect how your people actually build and change software, and they must be approved and maintained by your management. Nobody outside the organization can decide who is accountable for secure development or sign off that the policy is in force. Your team also keeps the evidence current, because an assessor will test what happens in day-to-day work, not what was written last year.

Policy ownership: Name an accountable owner for the secure development and change management policy and approve it at a level that can enforce it.
Role assignment: Assign responsibilities for development, patching and change approval to named people or documented functions, and confirm that each person understands their part.
Change approval: Approve changes through the process you have documented, and keep the approval record that proves it happened.
Evidence upkeep: Review the policy and RACI on a schedule you set, and retire or update items when teams or tools change.
Outsourcing limits: You can outsource drafting and tooling, but you cannot outsource accountability for the outcome.

Before engaging anyone, confirm that you can name the person who will defend the policy to an assessor.

PCI DSS 6.1 cost, effort, timing and consultant questions

Can we write the PCI DSS 6.1 policy and procedures in-house?

Yes, in most organizations the policy and procedures can be written by the team that owns software delivery, provided that person understands the requirement and can get sign-off from management. Requirement 6.1 asks for documented security policies and operational procedures for developing and maintaining secure systems and software, and for those documents to be current, in use and known to everyone affected. The harder part is not the wording. It is making sure the document describes what engineers actually do, that it is reviewed on a schedule, and that people can show they have read it. An assessor will test that by reading the documents and interviewing the people named in them, so a policy written in isolation from real practice tends to fail the interview.

How much staff effort does the 6.1 work need, and what drives it?

Effort depends mainly on how many teams build or change software in the cardholder data environment, how many repositories and pipelines they use, and how much of the process is already written down. An organization with one delivery team and a documented pipeline needs far less drafting and review than one with several teams, outsourced development and informal release steps. Expect effort in three parts: drafting the policy and procedures, mapping roles and reviewing the result with each affected group, and keeping the documents current as tools and teams change. Ask your team to inventory the software development and change activities before estimating, since the inventory sets the size of the job more than the document itself.

What does the 6.1 work need from engineering and management?

Engineering must describe the real development and maintenance workflow, including how code is reviewed, how builds and releases are approved and how vulnerabilities are handled. Management must assign accountable owners, approve the policy and provide time for the people named in it to take part. Requirement 6.1.2 expects roles and responsibilities to be documented, assigned and understood, so a RACI matrix or equivalent record must name real people or functions, not only job titles that nobody holds. Management also needs to accept that the documents will be checked against practice. If a procedure says every change is peer reviewed and the repository shows direct pushes to the main branch, the gap will be found.

Do we need a consultant for 6.1, and how do we keep consulting separate from assessment?

A consultant is not required by the standard, but many organizations use one to draft the documents, check the roles and prepare evidence. The key is independence. The organization owns its policies and controls, an implementation partner can help prepare them, and only a Qualified Security Assessor issues a Report on Compliance or validates the controls in a formal assessment. Keep the same firm from writing the controls and then certifying them as the assessor, and document who did what in the engagement. DeployOpen prepares systems, controls and evidence for compliance assessments but does not issue audit reports, attestations or certifications, so the assessor's conclusions come from their own testing.

What should we ask for in a quote for 6.1 help?

Ask for a written scope that names the deliverables, such as the policy, the procedure set, the roles record and the evidence list, and states which systems and teams are covered. Ask who does each task, what the client must provide and which items are one-time versus recurring, such as annual review and updates after tool or team changes. Confirm whether the quote covers interviews and walkthroughs with staff, and whether it includes support during the assessor's review. DeployOpen does not publish a price list, and a quote follows from the written scope, so a clear scope is what makes two quotes comparable. Ask your assessor, separately, what evidence they will request so the work matches their testing.

How does 6.1 relate to 6.2, 6.3, 6.4 and 6.5 in practice?

Requirement 6.1 sets the governing policy and roles, while 6.2, 6.3, 6.4 and 6.5 describe the operational controls that the policy must cover. In practice, 6.2 covers secure development of bespoke and custom software, 6.3 covers vulnerability identification and patching across all software, 6.4 covers public-facing web applications and payment page scripts, and 6.5 covers change management. The policy in 6.1 should point to the procedures for each of these, and the roles in 6.1.2 should name who owns each step. Write the 6.1 documents last, after the other controls are understood, so the policy reflects how they actually run. A single repository or ticketing system often holds the evidence for several of these requirements at once.

How DeployOpen works on this

DeployOpen helps organizations prepare the secure development policies, procedures and roles records that Requirement 6.1 expects, and the systems that hold them. We plan and document this work inside your own infrastructure, then hand over evidence that your team owns and your assessor can examine.

How we scope

Engagements are fixed-scope, with the 6.1 documents, systems and roles agreed in writing before work starts.
We confirm which teams build, patch and change payment-relevant software so the roles record covers the real workforce.
The written scope names the wiki, repository and code scanning tools in use, and who approves each document.

How we build

We set up or configure the documentation platform, such as XWiki or BookStack, with version history and role-based permissions.
We draft secure development and change management policies and procedures for your review, and map each section to the 6.1.1 expectations.
We configure repository controls such as protected branches in GitLab Community Edition and test that they restrict who can push or merge.

How we hand over

You receive the policy and procedure set, a roles and responsibilities record such as a RACI matrix, and a change log of approvals.
Each document carries an owner, review date and approval record so an assessor can confirm it is current and in use.
We walk your responsible personnel through their documented duties so they can explain them during interviews.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Retainers can cover periodic review of the policies and roles record when your teams, tools or software change.
Your organization owns its controls and its Attestation of Compliance. Independent assessors, such as a Qualified Security Assessor, make the validation decision.

6.1 Secure development processes and roles