Topic starter
19/08/2026 4:05 pm
TL;DR: PCI workloads can run on AWS S3, but compliance fails when organisations cannot continuously locate cardholder data across buckets, backups, logs, and AI-connected workflows, according to Strac. The practical shift is from infrastructure-only controls to DSPM and DLP that discover, classify, and remediate sensitive data before it spreads.
Editorial analysis by NHI Mgmt Group, based on content published by Strac: “Is AWS S3 PCI Compliant?”.
Key questions
Q: What fails first when AWS S3 stores PCI data without discovery?
A: The first failure is usually scope visibility.
Q: Why do encryption and IAM not solve PCI compliance on their own?
A: They protect access and confidentiality, but they do not identify every location where PAN or other regulated data exists.
Q: How do security teams know whether PCI access controls are actually working?
A: Look for evidence that access is both limited and reviewed: fewer broad entitlements, clear ownership for every privileged account, monitoring that flags unusual access, and remediation records for accounts that no longer need payment-system reach.
Practitioner guidance
- Implement continuous AWS data discovery Scan S3 and adjacent AWS stores continuously for cardholder data, backups, logs, exports, and unstructured files so PCI scope is based on actual content.
- Bind DSPM findings to remediation workflows Convert discoveries into masking, access blocking, alerting, labeling, or secure deletion so each PCI finding changes exposure rather than creating another ticket.
- Extend DLP into AI and MCP retrieval paths Inspect agent tool calls and connected workflows that can move AWS data into models or external apps, and block sensitive data before it leaves approved boundaries.
Bottom line: AWS S3 can be part of a PCI environment, but compliance breaks down when teams cannot locate cardholder data across the wider cloud estate.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
19/08/2026 4:39 pm
Discovery is now the decisive control plane for PCI in cloud storage: AWS configuration tells you whether a bucket is public or encrypted, but not whether regulated data has quietly spread into adjacent stores. That creates a governance gap because compliance teams can certify infrastructure while missing the actual regulated content. For practitioners, the lesson is to treat data location as a first-class control objective, not a secondary audit question.
A few things that frame the scale:
- 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
A question worth separating out:
Q: What should organisations do when PCI data appears in an unexpected AWS location?
A: Treat it as a governance exception, not a routine alert. Contain the exposure, determine how the data got there, restrict access, remove unneeded copies, and update discovery and retention rules so the same pattern does not recur in S3, backups, or connected workflows.
👉 Read our full editorial: AWS S3 PCI compliance depends on data discovery, not encryption alone