PCI DSS nginx / Apache Req 8.3Req 10.2Req 11.5

PCI DSS Evidence from nginx / Apache Access Logs

Why this matters for PCI DSS

If your web or API layer touches the cardholder data environment (CDE) in any way — even just as a routing layer in front of a payment processor — its access logs are in scope for PCI DSS audit evidence. Requirement 10 specifically mandates audit trails for all access to CDE-adjacent systems, and Requirement 11 requires intrusion detection coverage.

What evidence nginx/Apache logs provide

  • A timestamped audit trail of every request to CDE-adjacent endpoints, satisfying Req 10.2 (Audit Logs Implementation)
  • Evidence that strong authentication is enforced on payment-related endpoints (Req 8.3) — repeated unauthenticated access attempts without lockout is a direct finding
  • A record auditors use to confirm intrusion detection / prevention coverage (Req 11.5) by checking that attack patterns (SQLi attempts, credential stuffing) were actually flagged, not just loggable in principle

How LogTriage maps this to PCI DSS requirements

Detected credential-stuffing and brute-force patterns map directly to Req 8.3 (Strong Authentication for Users), and detected reconnaissance or intrusion patterns map to Req 11.5 (Intrusion Detection / Prevention). Every report includes the specific evidence note an assessor expects — what to retain, and why it satisfies the control — rather than leaving the auditor-mapping exercise for the audit itself.

Evidence checklist

  • Confirm logging is enabled and centrally retained for every system in the CDE network segment, not just the payment processor’s own endpoints
  • Document account lockout configuration and retain evidence it was actually triggered during any brute-force attempt
  • Maintain IDS/IPS alert records covering the same time window as the access logs
  • Confirm log retention meets PCI DSS’s minimum one-year requirement, with three months immediately available
  • Segment and clearly label which systems are in-scope CDE versus out-of-scope, since this materially changes what evidence is required

Frequently Asked Questions

Does every nginx access log need to be reviewed for PCI DSS, or just logs from CDE-adjacent systems?
Only logs from systems in or directly connected to the cardholder data environment (CDE). Any system that stores, processes, or transmits cardholder data, plus any network that could directly connect to those systems, is in scope. nginx logs from an entirely separate frontend with no CDE network access are out of scope.
What does PCI DSS Requirement 10 specifically require for access logs?
Req 10.2 requires capturing all individual user access to cardholder data, all actions by root or administrative users, access to all audit trails, invalid logical access attempts, and changes to identification and authentication mechanisms. nginx access logs cover several of these directly for web-tier access.
How often does PCI DSS require log review?
At least daily, per Requirement 10.6. That doesn't mean a human reads every line daily — it means there's a process that catches anomalies within 24 hours. LogTriage automates the analysis step so the daily review produces structured findings rather than raw log files.
Does LogTriage produce PCI-specific evidence notes?
Yes. LogTriage's compliance mapper automatically tags each detected finding with the specific PCI DSS requirement it relates to, and generates a structured report that maps evidence to controls, reducing the auditor-mapping work done manually before an assessment.

Related Resources

See your compliance mapping generated automatically

Every LogTriage report includes a deterministic compliance mapping — SOC 2, PCI DSS, HIPAA, NIST CSF, and ISO 27001 — stamped on every report, AI-generated or rule-based.