Security Policies and Procedures for Secure Development

PCI DSS 4.0.1 Requirement 6.1.1 requires you to have documented security policies and operational procedures for secure system/software development, keep them current, prove teams actually follow them, and ensure everyone affected knows them. Operationalize this by defining the Requirement 6 policy set, mapping it to SDLC workflows, and collecting repeatable evidence. (PCI DSS v4.0.1 Requirement 6.1.1)

Key takeaways:

• Document the full set of Requirement 6 policies/procedures, not just “a secure SDLC policy.” (PCI DSS v4.0.1 Requirement 6.1.1)
• Auditors will test “in use” and “known,” so you need workflow proof and training/acknowledgment evidence. (PCI DSS v4.0.1 Requirement 6.1.1)
• Treat policy maintenance as a controlled change process with owners, versioning, and review triggers. (PCI DSS v4.0.1 Requirement 6.1.1)

Requirement 6 in PCI DSS is where assessors spend time when your environment includes in-scope applications, scripts, infrastructure-as-code, or configuration that can affect the security of cardholder data. Requirement 6.1.1 is the “table stakes” control for that whole domain: it does not ask you to implement a specific secure coding technique; it asks you to prove you run secure development through documented, current, used procedures that the right people actually know. (PCI DSS v4.0.1 Requirement 6.1.1)

For a Compliance Officer, CCO, or GRC lead, the fastest path is to treat 6.1.1 as a governance-and-evidence problem. You need a defined policy set (what documents exist), an operating model (who follows them, in what tools), and an evidence plan (what artifacts prove “kept up to date,” “in use,” and “known”). (PCI DSS v4.0.1 Requirement 6.1.1)

This page breaks the requirement into implementable parts, gives you an execution checklist, and shows the evidence auditors typically request so you can close gaps without rewriting your whole SDLC.

Regulatory text

Text (verbatim): “All security policies and operational procedures that are identified in Requirement 6 are documented, kept up to date, in use, and known to all affected parties.” (PCI DSS v4.0.1 Requirement 6.1.1)

What the operator must do:

• Document the policies and procedures needed to meet PCI DSS Requirement 6 (secure development and maintenance of systems and software). (PCI DSS v4.0.1 Requirement 6.1.1)
• Keep them up to date through a managed review and change process that results in current versions being accessible. (PCI DSS v4.0.1 Requirement 6.1.1)
• Show they are in use by tying procedures to real SDLC workflows (tickets, PRs, CI/CD checks, release gates) and producing evidence that teams follow them. (PCI DSS v4.0.1 Requirement 6.1.1)
• Ensure they are known to all affected parties through role-based communication, training, and acknowledgment for everyone who must follow or support the procedures. (PCI DSS v4.0.1 Requirement 6.1.1)

Plain-English interpretation

You must run secure development like an operational discipline, not a policy binder. Assessors expect a coherent set of written rules for how you build, change, test, approve, and deploy in-scope systems; proof those rules match how teams work today; and proof the people who need to follow them can find them and understand their obligations. (PCI DSS v4.0.1 Requirement 6.1.1)

Who it applies to (entity and operational context)

Applies to: merchants, service providers, and payment processors subject to PCI DSS where Requirement 6 is in scope. (PCI DSS v4.0.1 Requirement 6.1.1)

Operationally, this hits you if you have any of the following in or connected to the cardholder data environment (CDE):

• Custom applications (web, mobile, API) that store, process, or transmit cardholder data, or that can impact CDE security.
• Scripts, jobs, integrations, or middleware that touch payment flows.
• Infrastructure-as-code, configuration management, or platform engineering changes that can alter security posture.
• Third parties who develop, maintain, or support in-scope software or system components (they are “affected parties” if your procedures apply to them). (PCI DSS v4.0.1 Requirement 6.1.1)

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

1) Define the “Requirement 6 policy set” as a controlled document inventory

Create a short inventory that lists each policy/procedure document that supports Requirement 6. Don’t start by writing; start by enumerating what must exist and who owns it. (PCI DSS v4.0.1 Requirement 6.1.1)

Minimum structure that tends to work in practice:

• Secure Development Policy (management intent, scope, roles)
• SDLC / Change-to-Production Procedure (how changes move from request to deploy)
• Secure Coding Standard (language/framework-specific guidance where you can)
• Code Review Procedure (requirements, exceptions, approvals)
• Security Testing Procedure (what testing must occur before release)
• Vulnerability Remediation Procedure (triage, fix, verify, close)
• Third-party development procedure (how external developers comply, handoffs, access) (PCI DSS v4.0.1 Requirement 6.1.1)

Keep the list tight: assessors prefer a clear, navigable set over dozens of loosely related documents.

2) Map each document to one or more SDLC workflows and tools

Requirement 6.1.1 is where “policy meets evidence.” Build a simple mapping table:

Requirement phrase	What it means	Where it must show up
Documented	Written and accessible	GRC repository, wiki, controlled docs
Kept up to date	Managed review and updates	Document control, change log
In use	Followed in daily work	Jira/ADO tickets, Git PRs, CI/CD gates
Known to affected parties	Communicated and understood	Training, acknowledgments, onboarding

Then tie procedures to system controls where possible (for example, branch protection rules that enforce review, or CI checks that block releases without required steps). The requirement does not mandate specific tooling, but tooling makes “in use” easier to prove. (PCI DSS v4.0.1 Requirement 6.1.1)

3) Assign owners, approvers, and an update trigger model

For each policy/procedure, assign:

• Document owner (writes/maintains)
• Executive approver (signs off)
• Operational SMEs (Dev, AppSec, Platform, QA)
• Audience (“affected parties”) (roles that must know and follow it) (PCI DSS v4.0.1 Requirement 6.1.1)

Define triggers that force review/update, such as:

• Major SDLC tool change (new CI/CD, new ticketing workflow)
• New programming language/framework used for in-scope apps
• Material security incident or recurring defect class
• New third-party development arrangement that changes responsibilities (PCI DSS v4.0.1 Requirement 6.1.1)

4) Build “known to affected parties” into onboarding and access

Auditors rarely accept “it’s on Confluence” as proof that people know the procedures. Put in place:

• Role-based onboarding modules (Dev, QA, Release Manager, AppSec, SRE)
• Annual or periodic refresher training where appropriate
• Acknowledgment workflow (HR LMS, GRC attestation, or ticket-based sign-off)
• A method for third parties to attest to your procedures (contract exhibit + onboarding + acknowledgment) (PCI DSS v4.0.1 Requirement 6.1.1)

5) Create an evidence plan that samples real work

Design evidence so you can answer: “Show me this is in use.” Pull a small set of recent work items for in-scope applications/systems and show:

• Change request/ticket with required fields completed
• Linked pull request with review evidence
• Security testing evidence tied to the release
• Approval/release record
• Post-deploy verification where your procedure requires it (PCI DSS v4.0.1 Requirement 6.1.1)

A practical approach is to maintain an “assessment-ready” evidence folder per in-scope application that contains a rolling set of example releases/changes and their artifacts.

6) Operationalize exceptions without undermining “in use”

You will need exceptions (hotfixes, urgent patches, third-party limitations). Write:

• What qualifies as an exception
• Who can approve it
• What compensating steps are required
• How exceptions are logged and later reviewed (PCI DSS v4.0.1 Requirement 6.1.1)

If exceptions are informal (Slack approvals, undocumented bypasses), assessors often conclude procedures are not “in use.” (PCI DSS v4.0.1 Requirement 6.1.1)

Required evidence and artifacts to retain

Keep evidence that supports each clause of the requirement. Examples below are typical and defensible. (PCI DSS v4.0.1 Requirement 6.1.1)

Documented

• Approved policies and procedures for Requirement 6 topics (versioned)
• Document inventory with owners and scope statements

Kept up to date

• Review history (meeting notes, approval records, version control log)
• Change log summarizing material updates and rationale
• Evidence of trigger-based updates (for example, update after tooling change)

In use

• Samples of change tickets and linked PRs showing required steps occurred
• CI/CD logs or screenshots showing checks and gates ran
• Release approvals and deployment records tied to in-scope systems
• Evidence of security testing performed per procedure (reports, results, sign-offs)

Known to all affected parties

• Training content and completion records
• Role-based onboarding checklists
• Policy acknowledgment attestations (employees and relevant third parties)
• Communications announcing material updates (email, LMS notices, ticketed comms) (PCI DSS v4.0.1 Requirement 6.1.1)

Tooling note: If you use Daydream to manage evidence collection for PCI DSS, set up a control record for Requirement 6.1.1 that (a) links the policy set, (b) defines the evidence sample you’ll collect from engineering tools, and (c) runs attestations for affected roles on a schedule you control. Keep the underlying source artifacts available, not just summaries. (PCI DSS v4.0.1 Requirement 6.1.1)

Common exam/audit questions and hangups

Assessors tend to probe these areas because they expose “paper programs.” (PCI DSS v4.0.1 Requirement 6.1.1)

• “Show me the policies and operational procedures identified in Requirement 6.” Hangup: you have one policy, but no operational procedures, or procedures exist only in tribal knowledge.
• “How do you know these are current?” Hangup: no versioning, no review history, owners can’t explain last update.
• “Prove it’s in use for this application.” Hangup: procedures don’t map cleanly to Jira/Git/CI evidence, or teams can’t reproduce the workflow during interviews.
• “Who are the affected parties, and how do they know?” Hangup: contractors/third parties aren’t trained, or product owners/release managers weren’t included. (PCI DSS v4.0.1 Requirement 6.1.1)

Frequent implementation mistakes and how to avoid them

1. Writing a policy that restates PCI DSS instead of describing your SDLC.
   Fix: write procedures in the language of your tools and roles (ticket states, PR requirements, release gates). (PCI DSS v4.0.1 Requirement 6.1.1)

2. Treating “known” as “published.”
   Fix: require onboarding + acknowledgment for all roles that touch in-scope code and releases, including third parties. (PCI DSS v4.0.1 Requirement 6.1.1)

3. Not scoping “affected parties” correctly.
   Fix: list roles and teams explicitly; include platform/SRE/release engineering if they can change production controls. (PCI DSS v4.0.1 Requirement 6.1.1)

4. No exception governance.
   Fix: document an exception path that still produces audit-friendly evidence and is reviewed after the fact. (PCI DSS v4.0.1 Requirement 6.1.1)

5. No evidence sampling plan until the assessor arrives.
   Fix: maintain a rolling evidence set for in-scope applications so you can answer requests quickly and consistently. (PCI DSS v4.0.1 Requirement 6.1.1)

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so you should treat enforcement risk in practical terms: if you cannot prove documented/current/in-use/known procedures for Requirement 6, an assessor can record a deficiency that impacts PCI DSS compliance status. Operationally, gaps here also increase the chance that insecure changes reach production because teams lack consistent, enforced steps. (PCI DSS v4.0.1 Requirement 6.1.1)

A practical 30/60/90-day execution plan

First 30 days: stabilize the requirement and stop evidence gaps

• Build the Requirement 6 policy/procedure inventory and confirm owners/approvers. (PCI DSS v4.0.1 Requirement 6.1.1)
• Identify in-scope applications/systems and the SDLC tools they use (repo, CI/CD, ticketing, release). (PCI DSS v4.0.1 Requirement 6.1.1)
• Draft or refresh the minimum viable Secure Development Policy and SDLC procedure so they match current workflows. (PCI DSS v4.0.1 Requirement 6.1.1)
• Stand up a central, controlled location for documents and versioning. (PCI DSS v4.0.1 Requirement 6.1.1)
• Start collecting sample evidence from one recent production change per in-scope app (ticket + PR + release record). (PCI DSS v4.0.1 Requirement 6.1.1)

By 60 days: make it “in use” and measurable

• Implement training/acknowledgment for affected roles, including relevant third parties. (PCI DSS v4.0.1 Requirement 6.1.1)
• Add workflow controls where feasible (templates, required ticket fields, PR review rules) so compliance becomes the default. (PCI DSS v4.0.1 Requirement 6.1.1)
• Publish an exception process and require logging of exceptions with approvals. (PCI DSS v4.0.1 Requirement 6.1.1)
• Run a tabletop “mock audit” on one application: ask engineering to produce artifacts on demand and document gaps. (PCI DSS v4.0.1 Requirement 6.1.1)

By 90 days: operational cadence and continuous readiness

• Finalize the full Requirement 6 document set referenced by your inventory and retire obsolete docs. (PCI DSS v4.0.1 Requirement 6.1.1)
• Establish a standing review cadence tied to triggers (tooling change, incident learnings, major SDLC change). (PCI DSS v4.0.1 Requirement 6.1.1)
• Create an assessment-ready evidence pack per in-scope app with repeatable sampling rules. (PCI DSS v4.0.1 Requirement 6.1.1)
• If you use Daydream, configure a recurring control workflow: document review tasks, role attestations, and evidence collection reminders so you are not rebuilding the story at assessment time. (PCI DSS v4.0.1 Requirement 6.1.1)

Frequently Asked Questions

Do we need separate policies for every development team and tech stack?

No. Keep one governing Secure Development Policy and add stack-specific secure coding standards only where differences matter (for example, web vs. mobile). What matters is that affected parties can find the right rules and you can prove they’re followed. (PCI DSS v4.0.1 Requirement 6.1.1)

What counts as “operational procedures” versus “policy”?

Policy states expectations and scope; procedures describe the steps teams take in tools and workflows. If a developer asked “what do I do next,” the answer should be in a procedure, not left to convention. (PCI DSS v4.0.1 Requirement 6.1.1)

How do we prove procedures are “in use” without screenshots for everything?

Prefer system-of-record artifacts: tickets, pull request histories, CI/CD logs, and release approvals. Build an evidence sampling approach tied to a small set of representative changes per in-scope application. (PCI DSS v4.0.1 Requirement 6.1.1)

Are third-party developers “affected parties”?

If they develop, maintain, or deploy code or configuration that can affect in-scope systems, treat them as affected parties. Include contractual obligations, onboarding, and acknowledgment evidence aligned to your procedures. (PCI DSS v4.0.1 Requirement 6.1.1)

What if our SDLC is different for hotfixes and emergency changes?

Document an emergency path with defined approvals and required minimum steps, then log each exception. Assessors mainly object to undocumented bypasses that produce no evidence trail. (PCI DSS v4.0.1 Requirement 6.1.1)

How often do policies need to be updated to satisfy “kept up to date”?

PCI DSS 6.1.1 does not specify a fixed interval in the provided text; you need a review approach that keeps documents aligned to current practice. Use owner accountability, versioning, and trigger-based updates so you can show why the current version is current. (PCI DSS v4.0.1 Requirement 6.1.1)