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