Does CloudArq make my AWS environment PCI DSS compliant?

No — and no scanner can. CloudArq is a read-only posture tool: it checks your AWS configuration against the infrastructure portions of PCI DSS and maps each finding to the requirement it evidences. PCI DSS compliance is a formal assessment performed by a Qualified Security Assessor (QSA) or a self-assessment questionnaire (SAQ), covering people, process and physical controls that no automated AWS scan can see. CloudArq gives you the technical evidence and the exact fix; the assessment is still yours to complete.

Which PCI DSS version does the mapping follow?

The mapping uses the classic v3.2.1-style requirement numbering (Req 1.3, 3.4, 8.2, 10.1, and so on). We do not claim a v4.0 mapping — the customised-approach and expanded requirements introduced in v4.0 are not reflected in these check-to-requirement links. If your assessment is scoped to v4.0, treat these mappings as the equivalent technical controls and confirm the current requirement number with your QSA.

What are the most common AWS misconfigurations that fail a PCI assessment?

The recurring three are: a security group allowing 0.0.0.0/0 on SSH (22) or RDP (3389) into the cardholder-data environment (Req 1.3), unencrypted storage holding or adjacent to card data — EBS/RDS without encryption at rest (Req 3.4), and CloudTrail disabled in a region or without log-file validation (Req 10.1 / 10.5). CloudArq checks for all of these via `open_ssh`, `open_rdp`, `unencrypted_ebs`, `unencrypted_rds`, `no_cloudtrail`, `cloudtrail_no_log_validation` and ships a copy-paste remediation for each.

Is CloudArq read-only? Does it ever touch cardholder data?

Yes to read-only, and no to touching card data. CloudArq connects through a read-only IAM role scoped by an ExternalId and reads only AWS configuration metadata — security-group rules, encryption settings, IAM policies, logging status. It never reads S3 objects, database contents, or application data, and it never stores your credentials. It detects and gives you the remediation steps; it never auto-applies a change. Data is AES-256-GCM encrypted at rest and hosted in the EU (Helsinki).

Which CloudArq tier includes the PCI DSS mapping?

PCI DSS is one of the eight frameworks the product maps to, and the full eight-framework set — including PCI DSS — is on the Max tier. The Pro tier maps four frameworks (CIS, SOC 2, ISO 27001, GDPR). The free Starter tier runs the core check set without the framework grouping. Framework coverage per tier is defined by the pricing source of truth, not this page; see the pricing page for current prices.

Can I hand CloudArq output straight to my QSA?

You can use it as supporting technical evidence for the AWS-infrastructure requirements, grouped by PCI requirement number, with each finding’s current state and the exact CLI/Terraform fix. It is not a Report on Compliance (ROC) or an Attestation of Compliance (AOC) — a QSA still produces those. Think of it as the evidence-gathering and gap-remediation layer that shortens the back-and-forth, not a replacement for the assessment itself.

frameworkpci dss

scopeaws

numberingv3.2.1

compliance guide · aws · pci dss

PCI DSS on AWS: which controls your AWS config evidences

A requirement-by-requirement map from the AWS-infrastructure portions of PCI DSS to concrete checks against your account. For each requirement — restrict inbound traffic, render PAN unreadable, keep an audit trail — you see the exact setting an assessor looks at, the scanner that verifies it, and the fix. CloudArq is read-only and never auto-applies a change.

Updated 2026-07-20 · ~11 minute read

checks mapped to PCI DSS

requirements evidenced

requirement groups below

agents installed

See CloudArq map these View pricing

audience

Who this is for

Teams running a cardholder-data environment (CDE) on AWS — a payment page, a checkout API, a service that stores, processes, or transmits primary account numbers — and facing a QSA assessment or a self-assessment questionnaire. If you already have a compliance team and a QSA on retainer, use this as the AWS-technical-evidence layer. If you are an engineering lead who just learned "we need PCI", read top to bottom.

definition

What "PCI DSS on AWS" actually covers

PCI DSS (Payment Card Industry Data Security Standard) is a set of requirements maintained by the PCI Security Standards Council for anyone handling card data. It spans people, process, and technology — network segmentation, key management, access control, logging, testing. A large slice of it lands on cloud infrastructure: how your VPCs are segmented, whether storage is encrypted, whether an audit trail exists and is tamper-evident. That slice is what an automated scan of your AWS account can verify. CloudArq maps 51 checks to those infrastructure requirements, using the classic v3.2.1-style requirement numbering. The requirements below are the ones your AWS configuration alone can evidence.

what this does · and doesn't do

What it does

Maps 51 automated checks to the AWS-infrastructure portions of PCI DSS, grouped by requirement number.
Shows the current state of each setting and a copy-paste CLI / Terraform fix.
Reads only AWS configuration metadata through a read-only IAM role scoped by ExternalId.

What it does not do

It is not a QSA assessment and does not produce a ROC or AOC.
It does not certify or guarantee cardholder-data-environment compliance. CloudArq the business holds no PCI certification.
It does not cover the people/process requirements — segmentation policy, key-management procedure, personnel training — that a scan cannot see.
It never reads card data or application data, never stores credentials, and never auto-applies a fix.

Build & maintain a secure network (Req 1 & 2)

Restrict inbound traffic to the cardholder-data environment; kill vendor defaults.

4 checks

PCI 1.3No security group allows 0.0.0.0/0 on SSH (22) or RDP (3389) into the CDE — checks open_ssh and open_rdp.
PCI 1.3No self-hosted inference endpoint is exposed to the public internet — check exposed_self_hosted_inference_endpoint.
PCI 2.1Workloads are not running in the account default VPC — check default_vpc_in_use.
PCI 2.1A password policy replaces vendor defaults (length + complexity + rotation) — check no_password_policy.

Protect stored & transmitted cardholder data (Req 3 & 4)

Render PAN unreadable at rest; strong cryptography for data in transit.

5 checks

PCI 3.4All EBS volumes are encrypted at rest — check unencrypted_ebs.
PCI 3.4All RDS instances are encrypted at rest — check unencrypted_rds.
PCI 3.4The credential/token vault uses a customer-managed KMS key, not the AWS-owned default — check token_vault_no_cmk.
PCI 4.1CloudFront distributions require HTTPS, not plaintext HTTP, on the viewer path — check cloudfront_no_https.
PCI 4.1CloudFront enforces a modern TLS policy, no outdated protocol/cipher — check cloudfront_outdated_tls.

Maintain a vulnerability-management program (Req 6)

Patch known vulnerabilities; prevent common coding and container weaknesses.

4 checks

PCI 6.2Managed instances are patched — no SSM instance is missing critical updates — check ssm_unpatched.
PCI 6.2No Lambda function runs a deprecated/EOL runtime — check lambda_deprecated_runtime.
PCI 6.5No ECS task definition runs a privileged container — check ecs_privileged_container.
PCI 6.5No Lambda execution role carries admin (wildcard) permissions — check lambda_admin_role.

Implement strong access control (Req 7 & 8)

Restrict access to system components on a need-to-know basis; authenticate every user.

5 checks

PCI 7.1No agent/role has an oversized blast radius across the account — check agentic_blast_radius.
PCI 7.1No Lambda role grants more than its function needs (least privilege) — check lambda_admin_role.
PCI 8.2The root account has MFA enabled — check no_mfa_root.
PCI 8.2IAM users have MFA enabled — check iam_users_no_mfa.
PCI 8.2A password policy enforces strength requirements for console users — check no_password_policy.

Track & monitor access (Req 10)

Capture an audit trail for every access to system components; keep the trail tamper-evident.

5 checks

PCI 10.1CloudTrail is enabled and recording API activity across regions — check no_cloudtrail.
PCI 10.1VPC flow logs are enabled so network access is auditable — check vpc_flow_logs_disabled.
PCI 10.1Bedrock model-invocation logging is on where GenAI touches in-scope data — check bedrock_invocation_logging_off.
PCI 10.5The CloudTrail log store is encrypted — check cloudtrail_not_encrypted.
PCI 10.5CloudTrail log-file validation is enabled so tampering is detectable — check cloudtrail_no_log_validation.

Regularly test networks & systems (Req 11)

Detect intrusions and unauthorised changes at the perimeter.

2 checks

PCI 11.4GuardDuty threat detection is enabled across regions — check guardduty_disabled.
PCI 11.4Public application load balancers sit behind a WAF — check alb_no_waf.

product · output

How CloudArq groups the gaps by requirement

compliance-gaps · framework · pci dssillustrative example

Critical2High2Medium1

PCI 1.3

Security group 0.0.0.0/0 on SSH into the CDE

sg-0example · eu-north-1

fix →

PCI 3.4

RDS instance not encrypted at rest

db-example-payments

fix →

PCI 10.5

CloudTrail log-file validation disabled

trail: example-org-trail

fix →

PCI 8.2

IAM user without MFA

iam · user/example-deploy

fix →

PCI 11.4

Public ALB with no WAF attached

alb-example · eu-north-1

fix →

Each failing requirement ships with a copy-paste CLI / Terraform fix and its evidence pointer for the assessor.

faq

Frequently asked

01Does CloudArq make my AWS environment PCI DSS compliant?: No — and no scanner can. CloudArq is a read-only posture tool: it checks your AWS configuration against the infrastructure portions of PCI DSS and maps each finding to the requirement it evidences. PCI DSS compliance is a formal assessment performed by a Qualified Security Assessor (QSA) or a self-assessment questionnaire (SAQ), covering people, process and physical controls that no automated AWS scan can see. CloudArq gives you the technical evidence and the exact fix; the assessment is still yours to complete.
02Which PCI DSS version does the mapping follow?: The mapping uses the classic v3.2.1-style requirement numbering (Req 1.3, 3.4, 8.2, 10.1, and so on). We do not claim a v4.0 mapping — the customised-approach and expanded requirements introduced in v4.0 are not reflected in these check-to-requirement links. If your assessment is scoped to v4.0, treat these mappings as the equivalent technical controls and confirm the current requirement number with your QSA.
03What are the most common AWS misconfigurations that fail a PCI assessment?: The recurring three are: a security group allowing 0.0.0.0/0 on SSH (22) or RDP (3389) into the cardholder-data environment (Req 1.3), unencrypted storage holding or adjacent to card data — EBS/RDS without encryption at rest (Req 3.4), and CloudTrail disabled in a region or without log-file validation (Req 10.1 / 10.5). CloudArq checks for all of these via `open_ssh`, `open_rdp`, `unencrypted_ebs`, `unencrypted_rds`, `no_cloudtrail`, `cloudtrail_no_log_validation` and ships a copy-paste remediation for each.
04Is CloudArq read-only? Does it ever touch cardholder data?: Yes to read-only, and no to touching card data. CloudArq connects through a read-only IAM role scoped by an ExternalId and reads only AWS configuration metadata — security-group rules, encryption settings, IAM policies, logging status. It never reads S3 objects, database contents, or application data, and it never stores your credentials. It detects and gives you the remediation steps; it never auto-applies a change. Data is AES-256-GCM encrypted at rest and hosted in the EU (Helsinki).
05Which CloudArq tier includes the PCI DSS mapping?: PCI DSS is one of the eight frameworks the product maps to, and the full eight-framework set — including PCI DSS — is on the Max tier. The Pro tier maps four frameworks (CIS, SOC 2, ISO 27001, GDPR). The free Starter tier runs the core check set without the framework grouping. Framework coverage per tier is defined by the pricing source of truth, not this page; see the pricing page for current prices.
06Can I hand CloudArq output straight to my QSA?: You can use it as supporting technical evidence for the AWS-infrastructure requirements, grouped by PCI requirement number, with each finding’s current state and the exact CLI/Terraform fix. It is not a Report on Compliance (ROC) or an Attestation of Compliance (AOC) — a QSA still produces those. Think of it as the evidence-gathering and gap-remediation layer that shortens the back-and-forth, not a replacement for the assessment itself.

Where CloudArq helps

CloudArq automates the AWS-side evidence for every requirement group on this page. 51 checks are mapped to their PCI DSS requirement numbers; the compliance-gaps view groups failing requirements together, and each finding ships with a CLI command or Terraform block you can apply today. It detects and hands you the fix — it is read-only and never auto-applies a change.

Mapping another framework? See the SOC 2 on AWS checklist and HIPAA on AWS, which cover the same evidence engine against different control sets.

See the demo View pricing