Roles and Responsibilities for Secure Development

PCI DSS 4.0.1 Requirement 6.1.2 requires you to document, assign, and make sure people understand who does each secure development activity in Requirement 6. To operationalize it quickly, publish a secure development RACI (or equivalent), map each Requirement 6 activity to named roles, and retain evidence that teams were trained, performed the tasks, and management monitors gaps. (PCI DSS v4.0.1 Requirement 6.1.2)

Key takeaways:

• You must prove ownership: every Requirement 6 activity has an accountable role, not a shared inbox. (PCI DSS v4.0.1 Requirement 6.1.2)
• “Understood” needs evidence: training/attestation plus workflow artifacts that show the role executed the task. (PCI DSS v4.0.1 Requirement 6.1.2)
• Auditors look for consistency between policy, SDLC tooling, and actual practice across teams and third parties. (PCI DSS v4.0.1 Requirement 6.1.2)

Requirement 6 is where PCI DSS expects you to control how systems and software are built and changed. Requirement 6.1.2 is the people-and-governance hinge: if roles and responsibilities are unclear, every other secure development control becomes “best effort,” varies by team, and fails under staff turnover or outsourcing. PCI DSS is explicit that roles and responsibilities for Requirement 6 activities must be documented, assigned, and understood. (PCI DSS v4.0.1 Requirement 6.1.2)

For a Compliance Officer, CCO, or GRC lead, the fastest path is to treat this as an operating model deliverable, not a policy exercise. You need (1) a written role map that covers the full secure development lifecycle, (2) integration into how work is requested/approved in your tools, and (3) durable evidence that responsibilities are executed and overseen. This page gives requirement-level guidance you can implement without redesigning your entire SDLC: a practical role taxonomy, a step-by-step build plan, the exact artifacts to retain, and the audit questions you will get.

If you run multiple product lines, use agile teams, or rely on third parties to develop or maintain cardholder data environment (CDE)-impacting systems, this requirement is where you standardize ownership across those variations.

Regulatory text

Requirement statement (excerpt): “Roles and responsibilities for performing activities in Requirement 6 are documented, assigned, and understood.” (PCI DSS v4.0.1 Requirement 6.1.2)

What the operator must do

You must be able to show, on demand, that:

1. Documented: There is a written definition of roles/responsibilities for secure development activities under Requirement 6. (PCI DSS v4.0.1 Requirement 6.1.2)
2. Assigned: Those responsibilities are assigned to specific roles in your organization (and where applicable, to third parties), with clear accountability. (PCI DSS v4.0.1 Requirement 6.1.2)
3. Understood: People in those roles know what they must do, and you can evidence that understanding through training, attestation, and consistent execution records. (PCI DSS v4.0.1 Requirement 6.1.2)

This is an “operational clarity” requirement. Auditors typically test it by sampling change records, pull requests, vulnerability tickets, and exceptions, then asking who owned each step and where that ownership is defined.

Plain-English interpretation of the requirement

PCI DSS is telling you: “Secure development can’t be a shared aspiration. Name the owners.” If your secure coding standard says “code must be reviewed,” 6.1.2 forces you to answer: Who reviews it? Who approves exceptions? Who confirms security testing happened? Who tracks remediation? Who can override and under what governance?

A good implementation reads like an org chart for the SDLC, but grounded in actual work steps (design, build, test, deploy, remediate, emergency change handling), with explicit accountability and handoffs.

Who it applies to (entity and operational context)

Entity types: Merchants, service providers, and payment processors that must comply with PCI DSS and have activities in Requirement 6 (system/software development and change). (PCI DSS v4.0.1 Requirement 6.1.2)

Operational contexts where scoping matters:

• In-house development for applications that store, process, or transmit cardholder data, or that can impact the security of the CDE.
• Infrastructure-as-code and platform engineering where changes to networks, cloud configuration, or container platforms affect CDE security.
• Third-party development (consultants, outsourced dev shops, SaaS configuration partners). You still need role clarity, even if the “doer” is external and the “approver” is internal.
• Shared services models where central security sets standards but product teams ship code. Your RACI must reflect both.

What you actually need to do (step-by-step)

Step 1: Inventory the Requirement 6 activities you perform

Create a simple list of the secure development activities your organization performs that fall under Requirement 6. Start from your SDLC and change process. You are not writing prose yet; you’re building a checklist of “things humans must do.”

Examples of activity buckets (tailor to your environment):

• Secure coding standards ownership and updates
• Developer secure coding training assignment and completion tracking
• Code review expectations and enforcement
• Security testing coordination (SAST/DAST/dependency scanning or equivalents)
• Vulnerability triage and remediation workflow
• Change approval and emergency change governance
• Access control for code repositories and CI/CD administration
• Third-party component approval and exception handling

Step 2: Define a role model that matches how work happens

Avoid naming individuals in the core document; define roles, then map those roles to people/teams elsewhere. A pragmatic minimum set most environments can support:

• Product/Engineering Owner (accountable for delivery and remediation prioritization)
• Developer (implements standards, fixes findings)
• Code Reviewer/Peer Reviewer (performs independent review)
• Security Engineer / Application Security (sets security requirements, consults on findings)
• DevOps/Platform Engineer (CI/CD, deployment controls, infrastructure-as-code)
• Change Manager / CAB (governs standard vs emergency change approvals where used)
• Compliance/GRC (evidence, control testing coordination)
• Third-party Developer (if applicable; must be explicitly covered)

Step 3: Build a RACI matrix for Requirement 6

Create a one-page RACI (Responsible, Accountable, Consulted, Informed) mapping each Requirement 6 activity to roles. Your goal is to eliminate ambiguity:

• Only one Accountable role per activity.
• No activity with “everyone” responsible.
• If a third party performs the work, an internal role still owns acceptance and oversight.

Quick design rule: If your auditor asks “who approves exceptions?” and two groups answer, you have a control gap.

Step 4: Tie the RACI to your SDLC and tooling

Auditors will test reality, not documents. Put role accountability into the systems where work is done:

• Repository settings: define who can approve pull requests; require reviews for protected branches.
• CI/CD pipelines: define who can modify pipelines and approve production deployments.
• Ticketing/work management: templates that require fields like “security review completed by,” “exception approver,” or “risk acceptance owner.”
• Vulnerability management: define who triages, who assigns, and who verifies remediation.

If you use a GRC system like Daydream, store the RACI, role descriptions, and evidence requests as a single control “packet,” then map tickets/PR samples directly to the requirement for faster audits.

Step 5: Prove “understood” with training + role attestations

“Understood” is the part teams often under-evidence. Create two evidence paths:

• Role-based training assignment: secure coding and SDLC responsibilities by role (developer, reviewer, DevOps, security).
• Attestation: a lightweight quarterly or release-cycle acknowledgement for people in key roles that they understand and will perform their Requirement 6 responsibilities.

Make it easy to complete and hard to ignore. Track completion and exceptions.

Step 6: Operationalize oversight and exception handling

Add governance that makes the role model durable:

• Exception process: who can approve deviations from secure development requirements, and what documentation is required (risk rationale, compensating controls, expiry).
• Metrics (qualitative is fine): dashboards that show whether reviews and security checks are happening, and where bottlenecks exist.
• Joiner/mover/leaver integration: when people change teams, role mappings and access should update.

Required evidence and artifacts to retain

Keep artifacts that show documentation, assignment, and understanding. A solid evidence set includes:

Documentation

• Secure Development Roles & Responsibilities standard (or SDLC policy section) referencing Requirement 6 scope. (PCI DSS v4.0.1 Requirement 6.1.2)
• Requirement 6 RACI matrix, version-controlled with approvals.

Assignment

• Role-to-team mapping (e.g., Engineering team A is accountable for app X; AppSec consulted).
• Access control evidence that matches responsibilities (repo admin list, CI/CD admin list), as applicable.

Understanding

• Training completion reports by role.
• Attestations/acknowledgements for key roles.
• Onboarding materials that explain secure development responsibilities.

Execution samples (what auditors love)

• Pull request samples showing required reviews by the correct roles.
• Change tickets showing approvals and evidence of required security checks.
• Vulnerability tickets showing triage ownership and closure verification.

Common exam/audit questions and hangups

Expect these, and prepare clean answers with artifacts:

• “Show me where Requirement 6 responsibilities are documented, and who approved the document.” (PCI DSS v4.0.1 Requirement 6.1.2)
• “Pick a recent production change. Who reviewed it? Who approved it? Where is that role assignment defined?” (PCI DSS v4.0.1 Requirement 6.1.2)
• “How do you ensure new developers understand their secure coding responsibilities?” (PCI DSS v4.0.1 Requirement 6.1.2)
• “Which third parties write or maintain code, and how are their responsibilities and oversight defined?” (PCI DSS v4.0.1 Requirement 6.1.2)
• “How do you handle exceptions to secure development requirements, and who can accept risk?” (PCI DSS v4.0.1 Requirement 6.1.2)

Hangup to avoid: giving the auditor a policy that lists generic groups (“Engineering is responsible”) without mapping to concrete activities and workflow evidence.

Frequent implementation mistakes and how to avoid them

1. Mistake: One policy paragraph with no operational mapping.
   Fix: publish a RACI tied to SDLC stages and tools, and show execution samples.

2. Mistake: “Shared accountability” across multiple teams.
   Fix: assign a single accountable role per activity; others can be responsible/consulted.

3. Mistake: Ignoring platform/IaC work.
   Fix: include DevOps/platform responsibilities (pipeline changes, Terraform, cluster config) if they can impact CDE security.

4. Mistake: Third parties not covered.
   Fix: contractually require adherence to your secure development responsibilities, then document internal oversight and acceptance.

5. Mistake: No evidence of “understood.”
   Fix: training + attestations + onboarding evidence, then demonstrate that responsibilities show up in tickets and PRs.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement. Operationally, 6.1.2 failures tend to surface as “process breakdown” findings during assessments: inconsistent code review, unmanaged exceptions, orphaned vulnerabilities, and emergency changes without clear approval authority. The risk is less about the document and more about uncontrolled change reaching CDE-impacting systems.

A practical 30/60/90-day execution plan

First 30 days (Immediate)

• Identify all teams and third parties that develop or change CDE-impacting systems.
• Draft the Requirement 6 activity list and define your role model.
• Build the first RACI and get engineering/security/change management sign-off.
• Stand up an evidence folder (or Daydream control workspace) with version control and an audit-ready index.

By 60 days (Near-term)

• Update SDLC and change templates to reflect required approvers and reviewers.
• Configure repo and CI/CD guardrails that match your roles (review requirements, restricted approvals where appropriate).
• Launch role-based training assignments and collect initial attestations.

By 90 days (Operationalize and prove)

• Run an internal mini-audit: sample recent PRs, change tickets, and vulnerability items; verify the right roles acted.
• Fix gaps: unclear ownership, missing approvals, inconsistent third-party oversight.
• Establish a recurring cadence to review and update the RACI when org structure or tooling changes.

Frequently Asked Questions

Does PCI DSS require naming specific individuals for each secure development responsibility?

Requirement 6.1.2 requires responsibilities to be documented, assigned, and understood, but it does not require names in the policy. (PCI DSS v4.0.1 Requirement 6.1.2) In practice, define roles in the document and maintain a separate role-to-person/team mapping that stays current.

Can Engineering be both responsible and accountable for most Requirement 6 activities?

Yes, if your governance still produces independent checks where needed (for example, peer review by someone other than the author). (PCI DSS v4.0.1 Requirement 6.1.2) The key is that each activity has clear accountability and the workflow evidence matches it.

How do we show “understood” without creating heavy bureaucracy?

Use role-based training plus a short attestation that references the RACI and where to find procedures. (PCI DSS v4.0.1 Requirement 6.1.2) Then rely on workflow evidence (PR approvals, change tickets) as the ongoing proof.

We outsource development to a third party. Are we still on the hook?

You still need roles and responsibilities documented and assigned across the relationship, including who at your company approves releases, exceptions, and risk acceptance. (PCI DSS v4.0.1 Requirement 6.1.2) Put responsibilities in the contract/SOW and retain oversight evidence.

What’s the minimum evidence set an assessor will accept?

A documented RACI, proof it is assigned (role mapping and access/approval configuration where applicable), and samples showing people performed the activities. (PCI DSS v4.0.1 Requirement 6.1.2) Training/attestation records usually close the “understood” gap.

How can Daydream help with this requirement without turning it into paperwork?

Use Daydream to keep the RACI, role descriptions, training attestations, and sampled PR/change evidence in one control record, so you can answer assessor requests quickly. Map evidence to Requirement 6.1.2 once, then refresh it on a steady cadence. (PCI DSS v4.0.1 Requirement 6.1.2)