Cloud and security · Banking
PCI DSS 4.0 compliance engineering for payment systems
We provide PCI DSS 4.0 compliance engineering for payment systems: reducing the scope of cardholder data, segmenting and hardening the environments that remain in scope, tokenising and encrypting data, building the logging, authentication and vulnerability management the standard requires, and automating the evidence assessors ask for. Compliance becomes a property of how the system is built and run, and you own the controls and the code.
Checklist · Payments
Payment hub and ISO 20022 readiness checklist
A checklist for banks and payment firms planning a payment hub, a real-time payments connection or an ISO 20022 migration: formats, mapping, validation, routing, exceptions, reconciliation and resilience.- 01Eight areas to review before you choose or build a payment platform.
- 02The message and data points that cause rejections: addresses, identifiers and remittance data.
- 03Questions on cut-offs, liquidity and exception handling.
- 04Seven questions to put to any vendor or development partner.
Free download
Get it on screen in a few seconds.
What the system does, module by module.
- 01
Scope definition and reduction
Mapping of where cardholder data and sensitive authentication data flow and rest, and design changes that reduce or remove systems from scope. - 02
Network segmentation
Segmentation of the cardholder data environment with firewalls, cloud network policies and tested isolation, so scope is defensible. - 03
Tokenisation and encryption
Replacement of card numbers with tokens, strong cryptography for stored and transmitted data and managed keys in hardware security modules. - 04
Secure configuration and hardening
Baselines for operating systems, containers, databases and cloud services, enforced and monitored as code. - 05
Access control and authentication
Least-privilege access, multi-factor authentication for all access into the cardholder data environment and managed privileged accounts. - 06
Logging and monitoring
Central, tamper-resistant logs for all in-scope systems, with daily review automation, alerts and time synchronisation. - 07
Vulnerability and patch management
Scanning, penetration testing, risk-ranked remediation, and controls for payment pages and scripts that protect against skimming. - 08
Secure development
Secure coding, code review, dependency management and testing in the pipeline for software that touches card data. - 09
Evidence automation and assessment support
Continuous collection of configuration and test evidence, mapped to requirements, so the assessment and the targeted risk analyses draw on live data.
Reference architecture.
Standards and interfaces
What we design against.
- PCI DSS 4.0.1
- The Payment Card Industry Data Security Standard, with its twelve requirements, defined and customised approaches and targeted risk analyses.
- PCI P2PE, PIN and 3DS standards
- Point-to-point encryption, PIN security and 3-D Secure requirements that apply to specific payment flows.
- PCI scoping and segmentation guidance
- Guidance on scoping, segmentation and cloud shared responsibility from the PCI Security Standards Council.
- ISO/IEC 27001
- Information security management that provides the wider framework around payment security controls.
- OWASP ASVS and Top 10
- Application security requirements for payment applications and pages.
- Acquirer and card brand programmes
- Validation and reporting requirements of acquirers and card brands.
Data model
The core entities.
- Data flow and system
- System, data stored or transmitted, scope status and the controls that apply.
- Requirement and control
- PCI requirement, control, owner, approach (defined or customised) and test frequency.
- Evidence
- Control, artefact, collection time, result and retention.
- Targeted risk analysis
- Control, frequency chosen, rationale, approver and review date.
- Vulnerability and remediation
- Finding, severity, system, owner, due date and closure evidence.
- Key and token record
- Key identifier, purpose, custodians, rotation and token vault references.
- Assessment
- Scope, assessor, findings, remediation and attestation date.
When custom development is the right call.
Controls designed in, not added later.
Scope minimisation
The safest card data is the data you never hold. Tokens, hosted fields and short retention reduce risk and cost.Separation of duties
Administration, key custody, monitoring and development are held by different roles.Continuous control testing
Controls are tested automatically, and failures raise tickets and alerts before assessment time.Protection of payment pages
Inventory and integrity checks of scripts on payment pages, and content security controls against skimming.Incident readiness
Response plans specific to card data compromise, with forensic readiness and notification paths to acquirers and card brands.
From discovery to a system you run.
- 01
Scoping and gap assessment
We map card data flows and systems, and assess the current controls against the standard with security, payments and engineering. - 02
Scope reduction design
Changes that remove systems and data from scope are designed and prioritised, with segmentation and tokenisation architecture. - 03
Build and harden
The remaining environment is built and hardened as code, with logging, authentication and vulnerability management in place. - 04
Evidence automation and readiness test
Evidence collection is automated, and a pre-assessment checks readiness and closes gaps. - 05
Assessment and continuous compliance
The assessment is supported with ready evidence, and controls keep running and being tested between assessments.
Relevant work
Where to see our work.
Common questions.
- Does Deview act as a Qualified Security Assessor?
- No. We engineer the controls and the evidence. The assessment and attestation are carried out by a Qualified Security Assessor or by you, depending on your validation level, and we work with them.
- How can we reduce our PCI scope?
- By using hosted payment fields or a payment provider so card numbers never touch your systems, tokenising data you do store, limiting retention and segmenting what remains. The best project is often one that removes systems from scope.
- What changed in PCI DSS 4.0?
- Among other things: a customised approach to meet objectives, targeted risk analyses to set the frequency of some controls, stronger authentication requirements and additional controls for payment page scripts. Requirements phased in over time and are now all in effect.
- Can compliance be continuous rather than annual?
- Yes. Automated configuration checks, evidence collection and alerts show control status every day, so the annual assessment confirms rather than discovers.
- Who owns the code and the controls?
- You do. The infrastructure code, the controls and the evidence stay yours.