Compliance & frameworks
PCI-DSS
PCI-DSS v4.0.1
PCI-DSS is the security standard the major card brands require of every organization that touches payment card data. It sets concrete controls for protecting the cardholder data environment (CDE) — the systems that store, process, or transmit primary account numbers — and it is enforced through your acquiring bank and payment processors rather than a government regulator. In the cloud, most of a PCI assessment comes down to how tightly you have scoped and segmented that environment and whether the controls around it hold up.
Who it applies to
Any organization that stores, processes, or transmits cardholder data — merchants, payment service providers, and the SaaS platforms that handle payments on their behalf — falls under PCI-DSS. Your validation path depends on transaction volume and role, ranging from a Self-Assessment Questionnaire (SAQ) to a Report on Compliance signed by a Qualified Security Assessor. Using a tokenization provider or hosted payment page can shrink scope significantly, but it rarely removes you from PCI entirely — the connected systems and the segmentation around them still count.
Cloud control themes
What PCI-DSS asks of your cloud
- Scope and network segmentation (Req 1) — defining the CDE boundary and isolating it from the rest of the estate
- Secure configuration and no vendor defaults (Req 2) — hardened baselines, no default credentials
- Protecting stored account data (Req 3) — encryption, key management, and minimizing what you retain
- Encrypting cardholder data over open networks (Req 4) — strong, current TLS
- Least-privilege and strong authentication (Req 7 & 8) — need-to-know access and MFA into the CDE
- Logging and monitoring of all CDE access (Req 10) — audit trails, time sync, and retention
Domain × framework
Which assessment domains produce PCI-DSS evidence
| Assessment domain | How it maps |
|---|---|
| Network exposure | Segmentation and boundary findings define and validate the CDE scope for Requirement 1 — the single decision that most affects the size and cost of your assessment. |
| Configuration & posture | Baseline-drift and vendor-default findings evidence Requirements 2 and 6 — hardened, patched systems with no default credentials. |
| Data security | Encryption-at-rest, key-management, and storage-exposure findings map to Requirement 3 for stored account data, and Requirement 4 for cardholder data crossing open networks. |
| Identity & access | Least-privilege, MFA, and stale-credential findings support Requirement 7 need-to-know access and Requirement 8 authentication into the CDE. |
| Logging & monitoring | Log-coverage, retention, and time-synchronization findings map to Requirement 10 — the audit trail for every access to cardholder data. |
What you get
A findings report organized around your cardholder data environment: each cloud gap tied to the PCI requirement it touches, ranked by risk, with segmentation and scoping issues surfaced first — because reducing what falls inside the CDE is the highest-leverage move you can make before a QSA ever arrives.
Most relevant to: FinTech, Commercial real estate
Questions
Does the health check make us PCI compliant?
No. PCI-DSS is validated through a Self-Assessment Questionnaire or a Report on Compliance signed by a Qualified Security Assessor (QSA). The health check is readiness work — it finds the cloud gaps in your CDE and its segmentation so they don't surface late in a formal assessment. We are not acting as your QSA.
Do you define our CDE for us?
We help you identify which cloud resources store, process, or transmit cardholder data and evaluate the segmentation meant to keep everything else out of scope. The formal scope decision stays with you and your QSA, but our findings give you the technical picture to make it defensibly.
Which version of PCI-DSS do you assess against?
PCI-DSS v4.0.1, including the future-dated requirements that became mandatory in 2025. We focus on the cloud-technical requirements; the policy, physical, and process requirements are yours and your assessor's domain.
Framework work in practice
Evidence rooms and compliance tables
Mapping is for auditors and operators — shown in the spaces where evidence is reviewed.
