PCI DSS v4.0 — Payment Card Industry Data Security Standard¶


Regulator	N/A
Jurisdiction	Global
Status	live
Applicability	Platform

PCI DSS is the security standard for all entities that store, process, or transmit cardholder data (CHD). For a bank issuing or accepting card payments, PCI DSS compliance is mandatory as a condition of the card scheme agreements with Visa and Mastercard — see Visa/Mastercard Rules. Version 4.0 became the only valid version from March 2024, replacing v3.2.1. PCI DSS is enforced by the card schemes, not a statutory regulator.

PCI DSS defines 12 requirements across six goals. As a card-issuing bank the bank is a Level 1 Service Provider if it processes more than 6 million transactions per year, requiring an annual on-site assessment by a Qualified Security Assessor (QSA) and quarterly network scans. The applicable validation form (SAQ-A vs full Report on Compliance) depends on tokenisation scope: if the bank uses tokenisation to prevent raw PAN from entering its application tier, scope may be significantly reduced.

Key v4.0 additions: phishing-resistant MFA required for all Cardholder Data Environment (CDE) access; targeted risk analysis (TRA) required to justify customised control implementations; all scripts on payment pages must be inventoried and integrity-checked; e-commerce environments must have web application firewall and bot detection.

Compliance register¶

This register maps every material PCI DSS v4.0 requirement to the platform control or institutional process that satisfies it. It is the static traceability layer for the Totara compliance report — dynamic data (module build status, test evidence, control test dates) is overlaid at runtime.

Scope legend¶

Symbol	Meaning
🤖 Automated	Platform enforces or performs the obligation. Primary control mode is GATE, AUTO, CALC, or ALERT. Human action is not required in the normal case.
📊 Evidenced	Platform captures the evidence trail automatically. Human compliance decision sits on top. Primary control mode is LOG.
🏛 Institutional	Obligation is met by a process entirely outside the platform — QSA audit, physical access controls, penetration testing programme. Platform may generate evidence inputs but does not own the process.
N/A	Obligation does not apply to this deployment configuration.

Build legend¶

Symbol	Meaning
✅	Module built and deployed
🔨	Module planned — not yet built (`build_status: Not started`)
❌	Uncontrolled gap — no module attributed

Requirement 1 — Install and maintain network security controls¶

Req	Obligation	Scope	Policy	Platform controls	Build
1.1–1.3	Network security controls documented, configured, and reviewed; inbound and outbound traffic restricted; deny-all default	🤖 Automated	PAY-006	MOD-075 (GATE) — all service-to-service traffic passes through TLS-terminated endpoints with mutual authentication; unauthenticated requests rejected at gateway	🔨
1.4	Network segmentation validated; CDE isolated from out-of-scope networks	🏛 Institutional	PAY-006	Network segmentation design is an infrastructure and architecture obligation; MOD-104 provisions the VPC and security group structure from IaC	—

Requirement 2 — Apply secure configurations¶

Req	Obligation	Scope	Policy	Platform controls	Build
2.1–2.3	System components configured securely; default credentials changed; unnecessary services disabled; configuration standards documented	🤖 Automated	PAY-006	MOD-104 (GATE) — all AWS resources provisioned by IaC at synthesis time; untagged resources blocked; secure default configurations enforced; MOD-103 (GATE) — database roles provisioned at bootstrap, cross-domain connections structurally prevented	🔨

Requirement 3 — Protect stored cardholder data¶

Req	Obligation	Scope	Policy	Platform controls	Build
3.2–3.3	CHD stored only where necessary; no sensitive authentication data stored after authorisation; PAN masked when displayed	🤖 Automated	PAY-006	MOD-124 (AUTO) — card personalisation data transmitted to bureau using P2PE; full PANs never stored in application logs or databases outside PCI DSS-compliant storage	🔨
3.5 — Key management	Cryptographic keys used to protect stored CHD managed with documented key management procedures; rotation enforced	🤖 Automated	PAY-006	MOD-045 (AUTO) — secrets cannot be extracted by developers; key rotation automated, no reliance on manual rotation schedule; MOD-104 (GATE) — KMS CMKs provisioned per data classification level	🔨
3.6 — Tokenisation	Where tokenisation used to reduce CDE scope, token vault and de-tokenisation service protected	🤖 Automated	PAY-006	MOD-124 (AUTO) — P2PE ensures raw PAN not in scope; MOD-045 manages tokenisation keys	🔨

Requirement 4 — Protect cardholder data with strong cryptography during transmission¶

Req	Obligation	Scope	Policy	Platform controls	Build
4.1–4.2	Strong cryptography used to safeguard PAN during transmission over open, public networks; no unprotected PAN in messaging	🤖 Automated	PAY-006	MOD-075 (GATE) — all service-to-service traffic TLS-terminated with mutual authentication; MOD-124 (AUTO) — P2PE applied for all card bureau transmissions	🔨

Requirement 5 — Protect all systems against malware¶

Req	Obligation	Scope	Policy	Platform controls	Build
5.1–5.4	Anti-malware solutions deployed on all system components; automatic updates; periodic scans; malware protection logs retained	🏛 Institutional	PAY-006	AWS-managed compute with container workloads limits malware attack surface; anti-malware scanning for any persistent endpoints is an institutional infrastructure obligation	—

Requirement 6 — Develop and maintain secure systems and software¶

Req	Obligation	Scope	Policy	Platform controls	Build
6.1–6.3 — Vulnerability management	Vulnerability identification and remediation process; patches applied within required timelines; vulnerability scanning	🏛 Institutional	PAY-006	Vulnerability management programme is an institutional obligation; MOD-076 (ALERT) — observability detects anomalies that may indicate exploitation	—
6.4 — WAF	Web application firewall deployed and maintained for public-facing web applications	🤖 Automated	PAY-006	MOD-075 (GATE) — API gateway provides rate limiting and request validation; WAF configuration at the load balancer layer is part of the AWS shared infrastructure	🔨
6.5 — Script management	All scripts on payment pages inventoried and integrity-checked (v4.0 new)	🏛 Institutional	PAY-006	Script inventory and integrity verification is a development and release management obligation; MOD-045 manages the keys used for content integrity	—

Requirement 7 — Restrict access to system components and cardholder data by business need to know¶

Req	Obligation	Scope	Policy	Platform controls	Build
7.1–7.3	Least privilege access control; documented access rights; deny-all default; role-based access	🤖 Automated	PAY-006	MOD-046 (GATE) — no standing production access: every session approved, time-limited, and logged; MOD-044 (GATE) — RBAC enforced at API gateway; least-privilege enforced, no client-side security reliance	🔨

Requirement 8 — Identify users and authenticate access to system components¶

Req	Obligation	Scope	Policy	Platform controls	Build
8.2–8.4	Unique IDs for all users; no shared credentials; identity verified before access granted	🤖 Automated	PAY-006	MOD-044 (GATE) — role separation enforced; no single user can hold conflicting roles; no shared API credentials	🔨
8.5 — MFA for CDE	MFA required for all non-console administrative access into the CDE; phishing-resistant MFA required (v4.0)	🤖 Automated	PAY-006	MOD-068 (GATE) — enforces MFA and device trust checks as a prerequisite for session establishment; FIDO2/passkeys for phishing-resistant authentication	🔨
8.6 — PAM	Privileged accounts managed; sessions monitored and logged	🤖 Automated	PAY-006	MOD-046 (GATE) — no standing production access; every session approved, time-limited, and logged; all production access sessions auditable	🔨

Requirement 9 — Restrict physical access to cardholder data¶

Req	Obligation	Scope	Policy	Platform controls	Build
9.1–9.5	Physical access to CDE systems controlled; media handling; visitor logs; CCTV where applicable	🏛 Institutional	PAY-006	Cloud-native platform — no physical CDE servers; AWS data centres are ISO 27001 and PCI DSS certified and cover requirement 9 for cloud infrastructure; office physical access is an institutional obligation	—

Requirement 10 — Log and monitor all access to system components and cardholder data¶

Req	Obligation	Scope	Policy	Platform controls	Build
10.1–10.4	Audit logs generated for all system components; log entries contain required fields; logs protected from modification	📊 Evidenced	PAY-006	MOD-044 (LOG) — all authenticated API calls logged with user ID, role, endpoint, and timestamp; MOD-046 (LOG) — production access sessions logged; MOD-104 (LOG) — CloudTrail enabled from bootstrap, every AWS API call logged from day one	🔨
10.5 — Log retention	Audit logs retained for minimum 12 months; 3 months immediately available	📊 Evidenced	PAY-006	MOD-076 (LOG) — 90-day hot retention window; cold storage via S3 satisfies 12-month retention; log tamper-protection via CloudTrail integrity validation	🔨
10.6–10.7 — SIEM	Security events reviewed daily using automated tools; SIEM deployed to detect anomalies	📊 Evidenced	PAY-006	MOD-076 (LOG, ALERT) — platform-level system events captured; alerting rules evaluated; anomalies surfaced; security event review is an institutional process	🔨

Requirement 11 — Test security of systems and networks regularly¶

Req	Obligation	Scope	Policy	Platform controls	Build
11.1 — Rogue access point	Detect and respond to rogue wireless access points	N/A	PAY-006	Cloud-native platform; no wireless access points in scope	—
11.2 — Network scans	Quarterly internal and external vulnerability scans; ASV scans for external-facing systems	🏛 Institutional	PAY-006	Vulnerability scanning programme is institutional; MOD-104 provides the infrastructure that is the subject of scans	—
11.3 — Penetration testing	Annual penetration test (internal and external); post-change tests for significant changes	🏛 Institutional	PAY-006	Annual penetration testing programme is institutional; platform modules are the subject of testing	—
11.4 — Change-triggered testing	Penetration testing conducted after significant changes to the CDE	🏛 Institutional	PAY-006	Change-driven penetration testing is an institutional programme obligation; release management process triggers	—

Requirement 12 — Support information security with organisational policies and programmes¶

Req	Obligation	Scope	Policy	Platform controls	Build
12.1–12.4	Information security policy; risk assessment; responsibility assignment; documentation	🏛 Institutional	PAY-006, DT-001	CISO owns the information security policy programme; DT-001 is the platform-level policy	—
12.5 — PCI DSS scope	Define and document PCI DSS scope annually; validate tokenisation scope reduction	🏛 Institutional	PAY-006	PCI scope definition is an institutional compliance function; MOD-124 P2PE controls support scope reduction argument	—
12.6 — Security awareness	Security awareness programme covering cardholder data handling	🏛 Institutional	PAY-006	Institutional training programme; not platform scope	—
12.10 — Incident response	PCI DSS incident response plan; response tested annually	🏛 Institutional	PAY-006	MOD-076 (ALERT) — incident detection and alerting; incident response plan is institutional	—

Institutional obligations (not platform scope)¶

Obligation	Owner	Platform evidence input
QSA annual assessment or SAQ completion	CISO / Head of Payments	All platform control evidence is provided to the QSA
PCI DSS scope documentation and annual validation	CISO	MOD-124, MOD-046, MOD-044, MOD-075 evidence
Quarterly ASV vulnerability scans	CISO	Platform infrastructure is the subject of scans
Annual penetration testing (network + application)	CISO	Platform modules subject to testing
Physical access controls to offices	COO	AWS covers data centre physical controls
Security awareness training for staff handling CHD	CISO / CPO	Institutional training programme

Coverage summary¶

Area	Total obligations	Platform automated 🤖	Platform evidenced 📊	Institutional 🏛	N/A
Req 1 — Network security	2	1	0	1	0
Req 2 — Secure configs	1	1	0	0	0
Req 3 — Stored CHD	3	3	0	0	0
Req 4 — Transmission	1	1	0	0	0
Req 5 — Anti-malware	1	0	0	1	0
Req 6 — Secure software	3	1	0	2	0
Req 7 — Access restriction	1	1	0	0	0
Req 8 — Authentication	3	3	0	0	0
Req 9 — Physical access	1	0	0	0	1
Req 10 — Logging	3	0	3	0	0
Req 11 — Security testing	4	0	0	3	1
Req 12 — Policy / programme	4	0	0	4	0
Total	27	11 (41%)	3 (11%)	11 (41%)	2 (7%)

PCI DSS is heavily balanced between platform technical controls and institutional programme obligations. Physical access (Req 9) is N/A for the cloud-native deployment. All attributed modules are currently build_status: Not started.

Policy	Title
PAY-006	PCI DSS Compliance Policy
PAY-003	Card Scheme Compliance Policy
DT-001	Information Security Policy

See D06 Payments & Settlement and D05 Data & Technology for the full risk domains.

Official documentation¶

Policies referencing this standard¶

PAY-003 — Card Scheme Compliance Policy
PAY-006 — PCI DSS Compliance Policy

Compiled 2026-05-22 from source/entities/regulations/industry-pci-dss.yaml