Apply secure configurations to all system components

To meet the apply secure configurations to all system components requirement in PCI DSS 4.0, you must define approved hardening standards (secure baselines) for every in-scope system and prove those baselines are consistently applied, exceptions are formally approved, and drift is detected and corrected. Treat it as a lifecycle control: build standards, implement them, and continuously verify them. ¹

Key takeaways:

• “Secure configurations” means documented, approved baselines plus repeatable enforcement, not ad-hoc hardening.
• Scope is everything that supports or can impact the cardholder data environment (CDE), including cloud and network components.
• Audit success depends on evidence: standards, implementation records, exception approvals, and configuration verification results.

PCI DSS 4.0 expects you to harden in-scope systems using approved secure configurations, and to be able to prove it during assessment. ¹ For a CCO, compliance officer, or GRC lead, the practical challenge is rarely writing a policy; it’s operationalizing secure baselines across diverse infrastructure while keeping evidence clean, current, and assessor-friendly.

This requirement is “medium” severity in many internal risk taxonomies because failures often look procedural (“we meant to harden that server”), but the impact is real: insecure defaults, unnecessary services, and inconsistent settings are common paths to compromise. The fastest way to operationalize is to treat secure configuration as a controlled standard with: (1) explicit baseline documents per platform, (2) automated deployment where possible, (3) formal exception handling, and (4) ongoing configuration monitoring for drift.

The guidance below is written to help you implement quickly: what counts as “approved,” which systems are in scope, what evidence you must retain, and how to execute a practical 30/60/90-day plan that your security team can actually run.

Regulatory text

PCI DSS 4.0 requirement (excerpt): “Harden in-scope systems using approved secure configurations.” ¹

Operator translation (what you must do):

• Identify all in-scope system components and ensure each has an approved secure configuration baseline (a documented, controlled standard).
• Implement those configurations consistently (build-time and change-time), then verify they remain in place (drift detection and remediation).
• Maintain evidence that configurations were applied, reviewed, and exceptions were approved. ¹

This is a “show me” requirement. Assessors will look for repeatable process and proof, not a one-time hardening project. ¹

Plain-English interpretation of the requirement

“Apply secure configurations to all system components” means you do not run PCI in-scope infrastructure on vendor defaults or team-by-team preferences. You define what “secure” means for each platform you operate (Windows server, Linux server, Kubernetes nodes, firewalls, cloud accounts, databases, endpoint builds, payment applications), get it approved, and then enforce it with change control and ongoing checks.

A secure configuration program typically includes:

• Baselines (what settings must be true)
• Build/implementation methods (how settings become true)
• Verification (how you prove they stay true)
• Exceptions (how you allow deviations safely, with compensating controls and approvals)

Who it applies to

Entity scope: Merchants and service providers in PCI DSS scope. ¹

Operational scope (what systems are covered):

• Systems in the CDE and systems that support or can impact the CDE. In practice, that includes infrastructure that provides identity, networking, security controls, logging, admin access, CI/CD for payment apps, and management planes for cloud resources, when those planes can affect CDE assets. ¹
• “System components” is broader than servers. Expect this to include:
  • Network devices (firewalls, routers, switches, WAFs)
  • Virtualization and cloud components (hypervisors, cloud tenant configs, IAM, security groups)
  • Operating systems and databases
  • Applications and middleware in scope
  • Security tooling (bastions/jump hosts, EDR configurations) where it governs access or hardening

Common scoping decision that trips teams up: management interfaces and “shared services.” If the system can administer, authenticate to, route to, patch, or monitor the CDE, you should treat it as in-scope for secure configuration unless scoping documentation clearly shows isolation. ¹

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

1) Build an authoritative inventory of in-scope components

• Start from your PCI scope definition and network diagrams.
• Produce an exportable list of system components with: owner, environment, platform, location (on-prem/cloud), and whether it’s CDE or connected/supporting.
  Output: “PCI in-scope system inventory” that you can reconcile to scanning, CMDB, cloud asset inventory, and endpoint management.

2) Define “approved secure configurations” per platform

Create baseline standards for each major platform type you operate in scope:

• Windows Server baseline
• Linux baseline(s) by distro
• Network device baselines by device class
• Database baselines (e.g., PostgreSQL, MS SQL, MySQL) if in scope
• Cloud tenant baseline (IAM, logging, network defaults, encryption defaults) where applicable
• Container/Kubernetes baseline if it runs in scope

Each baseline should include, at minimum:

• Secure build settings (disable unused services, enforce admin controls, strong auth settings, logging defaults)
• Network exposure defaults (only required ports/services)
• Time sync and logging requirements where relevant to your environment
• Configuration for remote administration (MFA, restricted source networks, hardened SSH/RDP posture)
• Patch/config change prerequisites (how changes are tested and approved)

Approval mechanics: Put baselines under document control (versioning, owner, review cadence, approval record). “Approved” should be provable. ¹

3) Map each system component to a baseline and an enforcement method

Create a simple mapping table:

Component type	Baseline standard	Enforcement mechanism	Verification method
Windows servers	WIN-SRV-BL	GPO/MDM/config mgmt	CIS-aligned scanner or config compliance reports
Linux servers	LNX-BL	Ansible/Puppet/Chef	Agent-based compliance checks + spot validation
Firewalls	FW-BL	Standard templates	Config review + diff checks

Keep this table current. Assessors want to see you are not guessing how hardening is applied.

4) Implement baselines through controlled change processes

Operationalize in two lanes:

• Build-time: golden images, infrastructure-as-code modules, configuration management profiles, network templates.
• Change-time: change tickets (or equivalent) that reference the baseline version, peer review approvals, and implementation records.

For legacy assets, create a remediation backlog prioritized by scope criticality (CDE first, then connected/supporting). Track progress in your GRC system so you can report status without re-inventing spreadsheets.

5) Stand up configuration drift detection and response

You need a way to verify the baseline remains in place:

• Scheduled configuration compliance checks (tooling can vary; the requirement is outcome and evidence).
• Defined thresholds for action: what triggers a ticket, what is emergency vs routine.
• A remediation workflow: assign, fix, re-check, close.

Drift response must be auditable: show initial finding, assignment, remediation evidence, and the follow-up check confirming closure.

6) Create an exception process that does not become a loophole

Define what qualifies for an exception:

• Business justification
• Risk assessment summary
• Compensating controls (if any)
• Expiration date and review requirement
• Approvals (system owner + security + compliance or risk)

Keep exceptions narrow and time-bound. Assessors frequently sample exceptions and test whether they were reviewed and whether compensating controls exist in practice.

7) Validate continuously and prepare assessor-ready narratives

At least quarterly (or aligned to your internal control cycle), run:

• Baseline review for material changes in platforms
• Evidence spot checks (sample of systems per baseline)
• Exception list review and renewals/closures

If you use Daydream to manage PCI requirements, treat this control like a living checklist: link each baseline document, each scan/report, and each exception approval to the requirement record so you can answer assessor sampling requests in minutes rather than days.

Required evidence and artifacts to retain

Keep evidence aligned to how assessors test: “documented, implemented, operating.”

Baseline and governance

• Secure configuration standards per platform (versioned)
• Approval records (change log, sign-off)
• Scope mapping: which baseline applies to which asset classes

Implementation and operations

• Build artifacts: golden image configuration notes, IaC repos/modules, configuration management policies
• Change records referencing baseline versions (tickets, PRs, peer reviews)
• Configuration compliance reports (dated, scoped)
• Drift remediation tickets with closure proof
• Exception register with approvals, expirations, and compensating controls

Assessor support

• Sampling list preparation (how you select systems)
• Admin access evidence for how baselines are applied (screenshots are secondary; exports and reports are stronger)

Common exam/audit questions and hangups

• “Show me the approved baseline for this system type, and who approved it.”
• “How do you know these settings are applied to all in-scope servers, not just new builds?”
• “How do you detect configuration drift? Show me findings and remediation.”
• “What happens when engineering needs to deviate from the baseline?”
• “How do you scope ‘system components’ for cloud management planes and shared services?” ¹

Hangup to anticipate: teams present a policy but cannot prove enforcement or coverage across the in-scope inventory.

Frequent implementation mistakes and how to avoid them

1. Hardening standards exist, but are not mapped to scope.
   Fix: maintain a baseline-to-asset-class mapping and reconcile it to your in-scope inventory.

2. One-time hardening project, no drift control.
   Fix: schedule compliance checks and track drift like vulnerability management: find, ticket, fix, retest.

3. Exceptions are informal (“approved in Slack”).
   Fix: require recorded approvals, an expiration date, and compensating controls where needed.

4. Over-reliance on screenshots and tribal knowledge.
   Fix: keep exportable reports (config compliance outputs, change records, exception registers). Screenshots rarely scale for sampling.

5. Cloud misalignment: secure baselines only for servers, not for cloud accounts and IAM.
   Fix: create cloud tenant/account baselines where those settings can impact the CDE.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement. The practical risk is straightforward: inconsistent configurations and insecure defaults increase the likelihood of compromise pathways (exposed services, weak admin controls, excessive privileges) and make incident response harder because “normal” differs across systems. PCI assessors also treat weak evidence as a control failure even if your teams believe systems are hardened, because PCI is evidence-driven. ¹

A practical 30/60/90-day execution plan

First 30 days: establish scope, ownership, and minimum viable baselines

• Confirm in-scope inventory sources (CMDB, cloud inventory, EDR, network management). Produce a reconciled list.
• Identify your top platform types in scope and assign baseline owners.
• Draft baseline standards for the highest-risk/highest-volume platforms first (commonly server OS and firewalls).
• Stand up an exception register and approval workflow.

Deliverables: inventory, baseline drafts, baseline ownership list, exception process.

Days 31–60: implement enforcement and start measuring compliance

• Implement baselines for new builds (golden images, IaC modules, config management).
• Start rolling baselines to existing systems with change control.
• Deploy configuration compliance checks for at least one major platform type and generate your first dated report.
• Create a drift remediation workflow with tickets and retest evidence.

Deliverables: enforcement for new builds, first compliance reports, drift ticket workflow, remediation backlog.

Days 61–90: expand coverage and make it audit-ready

• Expand baselines to remaining in-scope component types (databases, cloud tenant settings, Kubernetes/network segments as applicable).
• Run internal sampling: pick systems, compare configs to baseline, document gaps and fixes.
• Review exceptions for quality (justification, compensating controls, expiry).
• Package evidence in a requirement-focused repository (GRC system) with clear naming and dates.

Deliverables: broader baseline library, ongoing compliance reporting, clean exception register, assessor-ready evidence bundle.

Frequently Asked Questions

What counts as an “approved secure configuration” in PCI DSS 4.0?

A documented baseline standard that your organization has formally approved (with ownership and version control) and that you can show is applied to in-scope systems. “Approved” must be provable through records, not informal agreement. ¹

Does this requirement apply to cloud services and SaaS?

It applies to in-scope system components, including cloud configurations that support or can impact the CDE. For SaaS, focus on configuration settings you control (tenant security settings, IAM, logging, network restrictions) and retain evidence of those settings. ¹

How do we handle legacy systems that can’t meet the baseline?

Put them under a documented exception with justification, compensating controls, and an expiration date, then track a remediation plan. Assessors typically test whether exceptions are controlled and revisited. ¹

What evidence is strongest for auditors: screenshots or reports?

Exportable, dated reports from configuration compliance tools and change management records scale better for sampling and show repeatability. Screenshots can supplement, but they rarely prove “all system components.” ¹

How often do we need to re-validate secure configurations?

PCI DSS 4.0 requires you to harden using approved secure configurations and prove ongoing operation. Set a validation cadence that matches your change rate and risk, and be able to show consistent execution through dated reports and remediation records. ¹

How can a GRC team operationalize this without owning engineering tools?

Own the standard, evidence model, and exception governance; require engineering to map assets to baselines and produce scheduled compliance reports. Tools like Daydream help by tying baseline documents, reports, and exceptions directly to the requirement record for fast sampling support.

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