Develop and maintain secure systems and software

The PCI DSS 4.0 develop and maintain secure systems and software requirement means you must run secure build, patching, and secure development practices for every in-scope asset that stores, processes, or transmits cardholder data, or can impact that environment. Operationalize it by defining scope, standardizing secure configuration and SDLC controls, tracking remediation, and retaining audit-ready evidence across change, patch, and vulnerability workflows.

Key takeaways:

• Scope comes first: “in-scope assets” includes systems that can impact the cardholder data environment, not just payment apps.
• Auditors look for operating evidence: tickets, approvals, scan results, patch reports, and remediation closure records.
• The fastest path to maturity is a single system of record for patches, code changes, and vulnerability remediation mapped to in-scope assets.

A lot of PCI programs stall on Requirement 6-style work (secure development) and Requirement 2/11-style work (secure configuration, vulnerability management) because ownership is split across Infrastructure, Security, and Engineering. The result is predictable: “We patch,” “we scan,” and “we do code reviews,” but nobody can prove it consistently for the in-scope environment.

This requirement page focuses on the operator’s view: what you must implement and what you must be able to show on demand. The control intent is straightforward: in-scope systems and software should not drift into insecure states, and your delivery process should not introduce known vulnerabilities without detection and remediation. In practice, that means (1) knowing what is in scope, (2) having secure baselines and secure coding expectations, (3) enforcing change control, (4) patching and remediating vulnerabilities, and (5) retaining evidence that connects the work to the in-scope asset inventory.

If you want a clean audit, treat this as an evidence-engineering project, not a policy-writing project. Build workflows that automatically produce artifacts, then sample-test them the way a QSA (or internal audit) will.

Regulatory text

PCI DSS 4.0 (PCI-11) excerpt: “Apply secure development and maintenance practices for in-scope assets.” ¹

What the operator must do: implement repeatable practices that keep in-scope systems and software securely configured and securely changed over time. “Development” covers how you build and modify applications, scripts, and infrastructure-as-code that affect the environment. “Maintenance” covers patching, configuration drift control, vulnerability remediation, and change governance for those assets. ¹

Plain-English interpretation

You need a defensible, working program that answers three questions at any time for every in-scope asset:

1. What changed? (code, configuration, dependencies, infrastructure)
2. Was it reviewed and approved appropriately?
3. Were security issues found and fixed, or formally accepted as risk?

Auditors rarely fail teams for a single missed patch. They fail teams for missing scope clarity, inconsistent execution, and weak evidence trails across multiple teams.

Who it applies to

Entities: merchants and service providers that must comply with PCI DSS 4.0. ¹

Operational context (what “in-scope” means in practice):

• Systems that store, process, or transmit cardholder data.
• Systems that can impact the security of the cardholder data environment (CDE), such as identity systems, jump hosts, CI/CD runners that deploy to CDE, logging platforms, and management interfaces. ¹

Teams typically involved:

• Engineering (application code, pipelines, dependencies)
• Infrastructure/Platform (OS, containers, cloud resources, configuration baselines)
• Security (vulnerability management, secure SDLC controls, approvals/risk acceptance)
• Change management / ITSM (tickets, approvals, CAB where used)
• Third parties (hosting providers, managed service providers, payment integrations)

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

Step 1: Define and freeze your in-scope asset list (the “PCI scope register”)

1. Start from your CDE diagram and data flow.
2. Create an asset inventory that tags each item as: in CDE, connected to CDE, or security-impacting.
3. Assign an asset owner and system boundary per item.
4. Record where patches, scans, logs, and changes are tracked for that asset.

Operator tip: if you cannot list in-scope CI/CD tools, admin consoles, and identity providers, you will struggle to prove secure development and maintenance in an exam.

Step 2: Establish secure build standards for in-scope systems

1. Publish secure configuration baselines for OS images, containers, network devices, and managed services used in scope.
2. Require “golden images” (or hardened templates) for new builds.
3. Implement configuration drift detection or periodic configuration checks.
4. Tie exceptions to a documented risk acceptance workflow.

Evidence goal: show that new systems start secure and stay close to baseline.

Step 3: Operationalize patching as a tracked control, not an ad hoc task

1. Classify patches and updates (OS, middleware, database, libraries, firmware, container base images).
2. Define a workflow: detect → assess → test → deploy → validate → close.
3. Track patch status per in-scope asset in a single system of record (ITSM, patch tool, or GRC tracker).
4. Require documented exceptions and compensating controls when patching is delayed.

Minimum viable outcome: you can prove patch posture for any sampled in-scope asset and show remediation evidence.

Step 4: Build vulnerability remediation that closes the loop

1. Run vulnerability identification for in-scope assets (infrastructure and application where applicable).
2. Triage findings: false positive, accepted risk, or remediation required.
3. Create remediation tickets tied to the owning team and asset.
4. Validate closure with rescans or verification evidence.
5. Trend “open vs closed” findings for management reporting.

Hangup to avoid: scans alone do not satisfy “maintenance practices.” Auditors want to see closure discipline.

Step 5: Implement secure SDLC controls for software that touches in-scope assets

1. Define which repositories, services, and pipelines are in scope (including infrastructure-as-code).
2. Require basic engineering hygiene:
   • change review (peer review) for code and IaC changes
   • controlled merge process (protected branches or equivalent)
   • traceability from change request → code change → deploy record
3. Add security-focused checks appropriate to your environment (examples: dependency review, secret detection, security testing gates).
4. Document how you handle findings: fix, risk accept, or compensate.
5. Ensure releases to in-scope environments are tied to approved changes.

Practical standard: for any production change affecting the CDE, you can show who requested it, who approved it, what was tested/reviewed, and what deployed.

Step 6: Make third-party software and services part of the same lifecycle

1. List third-party products and managed services used in scope.
2. Define how you receive and apply third-party updates (release notes, patches, emergency fixes).
3. Require evidence from third parties when they operate systems on your behalf (patch reports, vulnerability remediation attestations, change records).

Operator tip: this is where programs break in real life. If a third party runs a critical in-scope component, you still need evidence that secure maintenance happens.

Step 7: Create an evidence pack aligned to how PCI exams work

Build an “audit binder” (folder or GRC workspace) that is organized by in-scope asset class and control type:

• build standards (baselines, images, templates)
• patching evidence
• vulnerability management evidence
• secure development/change evidence
• exceptions and risk acceptances

Daydream can help by mapping patches, secure coding controls, and remediation evidence back to the specific in-scope assets auditors sample, so you spend less time assembling last-minute proof and more time fixing real gaps.

Required evidence and artifacts to retain

Keep artifacts that connect scope → control → operating evidence → closure:

Scope and ownership

• In-scope asset inventory with owners and system boundaries
• CDE diagrams and data flow documentation (as maintained in your PCI program)

Secure build and configuration

• Secure configuration standards/baselines
• Golden image/template definitions and change history
• Exception records with approvals and compensating controls

Patching and maintenance

• Patch policy/standard for in-scope assets
• Patch deployment records or reports per sampled asset
• Change tickets and approvals for patch rollouts
• Post-deployment validation evidence (where applicable)

Vulnerability management and remediation

• Scan schedules and scan outputs for in-scope assets
• Triage notes and false-positive rationale
• Remediation tickets tied to assets
• Verification evidence that issues are closed (rescan, config proof, commit link)

Secure development / change control

• SDLC policy/standard for in-scope code
• Pull request/merge review evidence (sample set)
• CI/CD logs showing checks ran (as applicable)
• Release/deploy records tied to approved changes
• Risk acceptance records for deferred remediation

Common exam/audit questions and hangups

What auditors ask

• “Show me your current list of in-scope assets and who owns each one.”
• “Pick three in-scope servers and prove they are patched per your process.”
• “Show evidence that vulnerabilities are tracked through closure.”
• “For this application change, show request, review, test evidence, and deploy approval.”
• “How do you control emergency changes affecting the CDE?”

Typical hangups

• Asset inventory exists, but it’s not tied to patch/vulnerability tooling.
• Engineering uses Git workflows, but cannot tie production releases to an approved change record.
• Findings are tracked, but closure verification is inconsistent.
• Exceptions are granted informally in chat without retained approval.

Frequent implementation mistakes (and how to avoid them)

1. Mistake: treating “secure development” as a policy-only exercise.
   Fix: require objective evidence from your delivery tooling (PR reviews, pipeline runs, release records) and store samples monthly.

2. Mistake: scanning without remediation governance.
   Fix: enforce ticket creation and closure verification for findings on in-scope assets.

3. Mistake: unclear scope for pipelines and admin tooling.
   Fix: explicitly tag CI/CD runners, secrets managers, identity providers, and admin consoles as in-scope when they can impact CDE security.

4. Mistake: patching evidence is spread across emails and screenshots.
   Fix: standardize on reports from patch tools/ITSM and require asset identifiers that match your inventory.

5. Mistake: third-party managed components have no evidence trail.
   Fix: add contractual and operational requirements for patching/remediation attestations and deliverable reporting.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement. The practical risk is still clear: weak secure development and maintenance practices increase the likelihood that known vulnerabilities, insecure configurations, or unreviewed changes expose the CDE. For compliance, the main failure mode is inability to demonstrate operating effectiveness with traceable artifacts tied to in-scope assets. ¹

Practical 30/60/90-day execution plan

Days 0–30: Scope, ownership, and minimum evidence

• Finalize in-scope asset register with owners and system boundaries.
• Identify systems of record for: patching, vulnerabilities, and changes.
• Define the evidence pack structure and start collecting monthly samples.
• Publish baseline standards for in-scope builds (even if initial version is slim).

Days 31–60: Workflow hardening and closure discipline

• Require remediation tickets for in-scope vulnerability findings and patch exceptions.
• Implement a consistent approval trail for changes affecting CDE (ITSM or Git-based with defined controls).
• Add management reporting: open findings by in-scope asset, overdue remediation items, and exception counts.
• Run an internal “mock QSA sample” on a small set of in-scope assets to test evidence quality.

Days 61–90: Scale and reduce manual evidence work

• Expand controls across all in-scope asset classes (apps, infra, third-party services).
• Standardize secure build templates and drift checks.
• Formalize third-party evidence intake (scheduled reports, attestations, or portal exports).
• In Daydream, map artifacts (patch reports, PR samples, remediation closures) directly to in-scope assets to speed up exam response and highlight gaps early.

Frequently Asked Questions

Does this requirement apply to SaaS products we buy that touch cardholder data?

Yes if the SaaS is in scope or security-impacting for your CDE. You still need assurance and evidence that secure maintenance happens, which often means contract clauses plus periodic reports or attestations from the third party. ¹

What’s the minimum evidence an auditor will accept for “maintenance practices”?

Evidence must show repeatable operation for in-scope assets: patch tracking, vulnerability identification, and remediation through closure with approvals and timestamps. Policy alone rarely carries an exam without operating records tied to sampled assets. ¹

Can we rely on change management tickets instead of Git history for development evidence?

You can use either, but you need end-to-end traceability. If you use ITSM tickets, connect them to commits, pull requests, and deploy records so the audit trail shows what changed and who approved it. ¹

How do we handle patching exceptions for in-scope assets?

Treat exceptions as controlled risk decisions: document the reason, approving authority, compensating controls, and planned remediation date, then track the exception to closure. Store exceptions in the same system you use to track remediation work to avoid “lost” approvals.

Are scripts and infrastructure-as-code in scope?

If the code can change configurations or deploy workloads into the CDE, treat it as in scope for secure development controls. Apply code review, controlled merges, and traceable deployments the same way you do for application code. ¹

We have good tools, but evidence is messy. What’s the fastest fix?

Normalize around an in-scope asset inventory and require every patch, finding, and change record to reference an asset identifier. Then build an evidence pack that pulls from systems of record instead of screenshots and email threads.

Related compliance topics

• 2025 SEC Marketing Rule Examination Focus Areas
• Access and identity controls
• Access Control (AC)
• Access control and identity discipline
• Access control lifecycle management

Footnotes

1. PCI DSS v4.0