Understand the real environment
Map payment channels, data flows, relevant systems, people and third-party dependencies before deciding what is in scope.
01 / The Starting Point
Protect Payment Data Without Expanding the Compliance Burden
PCI DSS is the global payment card security standard for organisations that store, process or transmit account data, or whose systems can affect the security of the cardholder data environment.
Prioritise real control gaps
Separate missing protections and ineffective operating controls from documentation and evidence gaps, then make the improvement plan manageable.
Choose the right validation route
Determine whether your compliance-accepting entity requires an SAQ, QSA-led Report on Compliance or another validation arrangement.
PCI DSS v4.0.1 is a technical and operational standard, not a guarantee of immunity from payment fraud or cyber incidents.
02 / The PCI DSS Service Portfolio
Find the Right Help for Your PCI DSS Situation
Start with the business problem you need to solve. The PCI DSS journey may require one focused service or a coordinated programme spanning architecture, controls, evidence and assessment.
01 / SERVICE GROUP
Scope and Readiness
Map payment flows, isolate what matters and establish a reliable starting position
01PCI DSS ScopingDefine CDE boundaries, connected components and service providers↗02Scope ReductionReduce unnecessary account-data exposure and assessment complexity↗03PCI DSS Gap AnalysisIdentify control and evidence weaknesses before formal assessment↗04PCI DSS RemediationPrioritise and address security, process and documentation gaps↗
02 / SERVICE GROUP
Validation and Assessment
Prepare for the reporting route applicable to your business
03 / SERVICE GROUP
Specialist Payment Security
Address technical assurance and payment-model challenges
01PCI DSS Penetration TestingAssess relevant systems and segmentation in the cardholder data environment↗02PCI DSS for EcommerceReview payment-page exposure, scripts and outsourcing responsibilities↗03PCI DSS for Service ProvidersDefine shared responsibilities and customer-facing assessment evidence↗
03 / Where to Begin
Start With Your Payment Architecture Not the Questionnaire
Outsourced processing, connected services and different transaction channels can change what PCI DSS applies to. Understanding the architecture before selecting assessment paperwork helps avoid a misleading scope or validation route.
01 Where does account data enter, move or persist?
02 Which services can affect payment security?
03 What is your required validation and reporting route?
2-sec can help you work through those questions before committing to unnecessary technology or assessment work.
PAYMENT FLOWSMap Where Data Moves
Checkout, terminals, integrations, recurring payments and suppliers.
SCOPEDetermine What Applies
Cardholder data environments, connected systems and responsibilities.
VALIDATIONChoose the Evidence Route
SAQ, RoC, AOC and the documentation your receiving entity requires.
04 / The Compliance Journey
From Uncertainty to Defensible PCI DSS Validation
The route varies with your environment and reporting requirements. A practical PCI programme makes scope, control ownership and evidence explicit before the formal validation milestone.
01
Scope
Map cardholder data, connected services, third parties and the systems that can affect CDE security.
THE DECISIONDo we know exactly what needs to be protected?Working output: Documented boundaries and assumptions
02
Assess
Review applicable PCI DSS v4.0.1 requirements and evidence of implemented controls.
THE DECISIONWhich requirements are not yet demonstrated?Working output: Control and evidence gap register
03
Prioritise
Sequence technical, procedural and governance improvements by risk, complexity and assessment impact.
THE DECISIONWhat changes should come first?Working output: Remediation plan and control owners
04
Remediate
Support internal teams with corrective work and improved control evidence.
THE DECISIONAre the weaknesses actually addressed?Working output: Updated controls, processes and evidence
05
Validate
Complete the applicable SAQ or QSA-led assessment and required attestations.
THE DECISIONWhat proof does the accepting entity require?Working output: Assessment and validation documentation
06
Maintain
Keep recurring testing, reviews, third-party oversight and risk processes operational throughout the year.
THE DECISIONCan we sustain compliance between reviews?Working output: Ongoing programme and evidence cadence
Illustrative programme sequence. Formal assessment requirements and responsibilities depend on the validation route and the agreed engagement.
05 / Scope and Control Ownership
The Boundary Is Technical The Responsibility Is Shared
PCI DSS scope reaches beyond a single payment server. The programme needs a defensible understanding of the systems, services and people that store, process, transmit or can affect the security of account data.
2-sec / PAYMENT SECURITYILLUSTRATIVE SCOPE ARCHITECTURE
PAYMENT CHANNELS
Web checkout
Card-present terminals
Service integrations
→
CARDHOLDER DATA ENVIRONMENTAccount DataPeople · Processes · Technology
ControlsEvidenceAccess
↔
CONNECTED SERVICES
Processors and gateways
Cloud and hosting
Managed suppliers
Boundary reviewThird-party dependenciesResponsibility mappingSegmentation assurance
Account data exposure
Where does payment account data actually enter, pass through or remain?Avoid unnecessary data handling and confirm the scope of affected payment channels.
Segmentation and connected components
Can surrounding systems affect the security of the CDE?Validate protective boundaries and their operational dependencies.
Third-party responsibilities
Which controls sit with the organisation and which with providers?Document the division of responsibilities and available compliance evidence.
Assurance and verification
What establishes that controls operate as intended?Connect policy statements with technical configuration, testing and records.
Change management
What happens when payment architecture or services evolve?Reassess scope and evidence as systems, suppliers and payment journeys change.
06 / Payment Security in the Cloud
PCI DSS Compliance Across AWS Azure and Cloud Services
Running payments in the cloud changes how controls are implemented, not whether they are required. The right starting point is identifying where account data travels, which cloud services can affect the cardholder data environment and who operates each relevant control.
2-sec / CLOUD PAYMENT ASSURANCEILLUSTRATIVE RESPONSIBILITY MAP
↔
↔
Shared responsibility must be verified for the actual services deployed
Understand which services affect payment security
Map cloud accounts, subscriptions, gateways, hosted checkouts, applications and third-party connections that store, process or transmit account data or can affect CDE security.
Define who must demonstrate each control
Review provider attestations and responsibility matrices alongside customer-managed IAM, configuration, encryption, monitoring and vulnerability responsibilities.
Test and evidence the actual environment
Examine how cloud infrastructure, segmentation, application changes and connected services affect testing, documentation and continuing PCI DSS compliance.
AWS and Microsoft Azure are examples of relevant environments, not a claim that their hosting automatically makes an organisation PCI DSS compliant. Cloud-platform security consultancy is available as a separate service.
07 / PCI DSS Technical Testing
Penetration Testing That Supports Defensible PCI DSS Scope
PCI DSS v4.0.1 Requirement 11.4 addresses internal and external penetration testing and the correction of exploitable weaknesses. Where segmentation keeps systems outside the CDE, testing must also demonstrate that the separation is effective.
This is not the same as a vulnerability scan. Penetration testing follows an authorised methodology to examine security weaknesses and validate realistic attack paths.
2-sec / CONTROL VALIDATIONPCI DSS 11.4
01Internal and external testsValidate exploitable security weaknesses
02Segmentation boundariesConfirm isolation of out-of-scope systems
03Remediation and retestingVerify corrections and preserve evidence
SCOPE → EXPLOITABILITY → VERIFICATION
Internal and External Penetration Testing
Typically required at least once every 12 months and after significant infrastructure or application changes, using an appropriate methodology and qualified, organisationally independent testers.
Correct and Retest Weaknesses
Address exploitable weaknesses according to the entity’s risk assessment and repeat penetration testing to verify the corrections.
Segmentation Validation
Where segmentation is used to isolate the CDE, confirm that it works. The baseline frequency is at least annually and after segmentation changes; an additional six-month requirement applies to service providers.
The applicable testing requirements depend on the entity’s PCI DSS scope, assessment route and service-provider status. Requirements shown summarise PCI DSS v4.0.1 and do not replace the standard.
08 / Evidence That Stands Up01 02 03 04 05
Make Compliance Evidence Useful Beyond the Assessment
Documentation alone is not a compliance programme. 2-sec helps connect control design, operating effectiveness, reporting responsibilities and remediation to an evidence position your teams can maintain.
Scope and responsibility documentation
Payment flows, CDE boundaries, supplier dependencies and control ownership.
Control gap assessment
Applicable requirements, implementation weaknesses and evidence limitations.
Prioritised remediation roadmap
Sequenced corrective work with responsibilities and assessment dependencies.
Validation evidence
Policies, technical records, testing outcomes and required assessment artefacts.
Ongoing compliance activities
Recurring assurance, review schedules and accountability between validations.
The actual output package depends on your requirements and contracted scope.
2-sec / PCI DSS
ILLUSTRATIVE ASSESSMENT WORKSPACEControl Evidence
Control Evidence
& Readiness
01Scope and boundaries
02Applicable PCI controls
03Evidence and owners
04Remediation status
Conceptual document · Not actual customer data
09 / Different Teams One Programme01 02 03 04
Compliance Needs Coordinated Control Ownership
QSA expertise matters, but control implementation and evidence depend on people across the business. PCI programmes work best when each stakeholder knows what needs to be decided, delivered and demonstrated.
Business and risk leadership
Reporting obligations, risk decisions, resourcing and accountability.
IT and security teams
Systems, access, monitoring, technical controls and testing evidence.
Payments and application teams
Payment flows, checkout architecture and service integrations.
Third-party providers
Shared responsibilities, service boundaries and assessment evidence.
2-secPCI DSS GOVERNANCE
EXECUTIVE COMPLIANCE VIEW / CONCEPTOne programme
One programme
Clear ownership
01Account dataScope establishedDEFINED
02Control ownersResponsibilities assignedOWNED
03EvidenceOperating proof collatedTRACKED
04ValidationAssessment route confirmedPLANNED
SCOPE → ACCOUNTABILITY
10 / Compliance PathwaysNEW OR CHANGING ASSESSMENT APPROACHING ONGOING
Different PCI DSS Needs Different Starting Points
Choose an appropriate engagement based on your current compliance position, environment and the obligations of your accepting entity.
Scope and readiness
Establish PCI applicability, map payment channels, reduce unnecessary scope and identify control gaps.
Validation support
Prepare required evidence, resolve outstanding issues and undertake the applicable SAQ or QSA-led assessment.
Compliance maintenance
Support recurring control operation, security testing, third-party oversight and evidence management.
11 / Why 2-secQSA EXPERTISE TECHNICAL DEPTH PRACTICAL DELIVERY
QSA Experience Backed by Practical Cyber Security Capability
2-sec's published PCI DSS offering combines QSA-led assessment with related work across technical assurance, governance and remediation, rather than treating compliance as an annual evidence collection exercise.
Understand requirements in context
Work through scope, evidence, applicability and validation with qualified PCI DSS assessment expertise.
Connect compliance with security
Call on penetration testing, vulnerability management, cloud security and incident response capability as needed.
Prioritise action over paperwork
Focus improvement plans on protecting payment data and demonstrating controls that operate in practice.
12 / PCI DSS Questions
What to Know Before Your Next PCI DSS Assessment
These answers clarify where the standard applies, who determines validation requirements and how to reduce uncertainty before formal assessment.
Which PCI DSS version currently applies?
PCI DSS v4.0.1 is the active version of the standard. The future-dated v4.x requirements became effective after 31 March 2025. Confirm the latest PCI SSC publications and any programme-specific guidance.
Does PCI DSS apply if we use an external payment processor?
It may. Outsourcing payment processing can reduce PCI scope but does not automatically remove all obligations. Applicability depends on how your payment channels and systems affect the cardholder data environment.
Do we need a QSA or can we complete an SAQ?
Your compliance-accepting entity, often an acquirer or payment brand, determines the required validation route. SAQs apply to eligible organisations; other environments may require a QSA-led Report on Compliance.
What counts as the cardholder data environment?
The CDE includes people, processes and technologies that store, process or transmit account data, together with relevant system components that can affect its security. Accurate scoping is essential.
Can segmentation reduce PCI DSS scope?
Potentially. Effective, appropriately verified segmentation can isolate systems that do not need to be in scope. The design and effectiveness of those boundaries must be supportable.
What is the difference between a gap analysis and an assessment?
A gap analysis is a readiness exercise identifying weaknesses against applicable requirements. A formal PCI DSS assessment evaluates the controls and produces the required validation documentation.
Is PCI DSS a once-a-year project?
No. Many requirements involve continuous or recurring activities, including monitoring, vulnerability management, access reviews, risk analyses and third-party oversight.
Can 2-sec help after a difficult assessment?
Yes. 2-sec offers remediation and compliance advisory support to help organisations address technical, procedural and evidence gaps, with formal assessment responsibilities agreed separately.
13 / Your Next Move
Make Your PCI DSS Programme Clearer and More Defensible
Tell 2-sec how you accept payments, what validation is expected and where the uncertainty sits. We'll discuss the best place to begin.
Prefer a conversation first? Call the 2-sec team using the number above.