Description

A focused course, tailored for you

The Acquirer Security Lead's PCI v4 Scope Reduction Playbook

Cut your card data environment in half before the next QSA arrival, using tokenisation, P2PE, and segmentation that your engineering team will actually implement.

Your scoping workbook keeps growing. Every cycle a new merchant API, a new fraud microservice, a new boarding tool gets dragged into the CDE and stays there. The QSA is going to ask why on the next assessment, and a segmentation diagram is not an answer.

$199 one-time

Tailored to your situation. Access within 24 hours. 30-day money-back.

Includes a hand-built implementation playbook delivered alongside course access, generated for your specific situation.

Why this course

Acquirer security leads sit at the centre of a problem nobody owns end to end. Product wants to launch a new merchant onboarding flow this quarter. Engineering wants the fraud service to read full PANs because tokenised lookups are slower. Finance wants chargeback data joined to settlement data without the work of de-scoping the join. Legal wants merchant contracts to promise the same SAQ levels the team is trying to push merchants down off. The PCI program lead becomes the person who either says no to everything (and gets routed around) or says yes to everything (and ships an in-scope environment that grows 20 percent year on year). The way out is not another control list. It is a written scope-reduction case per component, signed by the engineering owner, defensible to the QSA, and re-usable when the next product line shows up. That artefact is what this course teaches you to produce.

What you walk away with

Produce a written customised-approach worksheet for at least one control where the defined approach is unworkable, and defend it to a QSA without a six-week back-and-forth.
Write a P2PE solution boundary memo that holds up when the solution provider's listing changes mid-cycle.
Draft tokenisation scope-reduction letters that engineering and the QSA both sign without rewriting them three times.
Build a segmentation test evidence pack the QSA accepts on first read, so you stop spending two weeks per cycle on penetration-test artefact assembly.
Stand up a RACI that names the engineering owner per CDE component, so next cycle's scope diagram is smaller, not bigger.

The 12 modules

Module 1. The scoping workbook as a written case, not a diagram

The default scoping artefact at most acquirers is a Visio diagram and a spreadsheet. Neither survives a QSA challenge or a product launch. This module rebuilds the workbook as a per-component written scope case: name the component, name the data flow, name the control type, name the in-scope or de-scoped conclusion, name the engineering owner. The template is the one used in the remaining eleven modules.

Module 2. PCI DSS v4.0.1 customised-approach worksheets that hold up

v4.0.1 made the customised approach a real option, and most QSAs will accept it on a small number of controls if the worksheet is written well. This module walks the structure of a defensible worksheet: control objective, defined approach reason for non-use, customised approach control description, targeted risk analysis, and testing procedure for the QSA. You write one for a control you actually want to challenge, not a hypothetical.

Module 3. Tokenisation scope-reduction letters engineering will sign

Tokenisation reduces scope only when the QSA can read the letter that says which components stopped seeing PAN and when. This module teaches the letter as an artefact: the cryptographic boundary description, the key custody chain, the de-tokenisation use cases that remain in-scope, and the engineering attestation that the production path matches the letter. The output is a letter your QSA can paste into the report.

Module 4. P2PE solution boundary memos that survive listing changes

P2PE solutions get re-listed, re-validated, and re-scoped by their providers more often than acquirers track. This module covers the boundary memo as a living document: which terminals, which acquiring connections, which decryption environment, and what happens when the provider's PIM changes mid-cycle. You finish with the memo and the change-trigger list that flags when it needs an update.

Module 5. Segmentation test evidence the QSA accepts on first read

Most segmentation pen-test reports arrive as a PDF with three findings and no narrative the assessor can use. This module rebuilds the artefact: the network ruleset extract, the controlled-test methodology, the negative-test results that prove segmentation holds, and the QSA-facing summary that ties each test back to the scoping diagram. The deliverable is the report the QSA will copy-paste from.

Module 6. Merchant-facing AOC language that does not over-promise

Merchants read your AOC for what you promise them about their data. Promise too much and the next breach is your liability. Promise too little and the merchant routes to a competitor. This module is the language layer: how to describe the in-scope environment, the tokenisation surface, the P2PE surface, and the residual responsibilities the merchant carries, in language a merchant procurement team accepts and a QSA does not flag.

Module 7. Customer security questionnaires from large merchants without rewriting from scratch

A large merchant security questionnaire arrives with 400 questions and a deadline. The wrong answer reopens scope you spent a cycle reducing. This module is the answer library: per-question canonical responses tied back to the AOC and the scope diagram, plus the escalation rules for the 20 questions per questionnaire that genuinely need a security lead to think. You stop rewriting the same answers four times a quarter.

Module 8. The fraud and risk service: in-scope or compensating control

Acquirer fraud services usually want full PAN visibility for rules and modelling. PCI usually wants them out of scope. This module is the decision artefact: which fraud features genuinely need PAN, which can run on token vault references, which require a compensating control, and how to write the control description so the QSA accepts it. You finish with a fraud-service scoping decision your CISO and your data science lead both sign.

Module 9. Chargeback and dispute systems: the join that creates scope

The chargeback portal does not store PAN. The settlement system does. The join between them frequently does, and nobody owns the join. This module walks the dispute and chargeback data path component by component: where PAN enters, where it exits, where token references replace it, and where a join recreates an in-scope surface. The output is a chargeback data-flow memo that engineering and PCI both endorse.

Module 10. Legacy merchant boarding systems: the de-scope migration

Most acquirers run at least one merchant boarding tool that has been promising to migrate for three years. This module is the migration as a PCI-scoping case: the data the legacy tool still holds, the cost of keeping it in-scope versus migrating, the migration plan, and the AOC-impact paragraph that justifies the spend to finance. You finish with a one-page case the CFO can sign.

Module 11. Internal RACI that stops scope creep next cycle

Scope grows because no engineering owner is named per CDE component. Twelve months later, a new microservice is in-scope and nobody can explain why. This module is the RACI: per CDE component, name the owner, the scope-change approver, the assessment contributor, and the residual-risk holder. The deliverable is a one-page chart and a quarterly review cadence that survives team reorganisations.

Module 12. The conversation with the QSA: the meeting, not the documents

Most of the audit cycle is documents. The week the QSA is onsite or on calls is when the program is actually won or lost. This module is the meeting prep: the order in which you present the workbook, the customised-approach worksheets, the tokenisation letters, the P2PE memos, and the segmentation evidence. You finish with a runbook for the kickoff call, the daily standups, and the close-out meeting where findings get framed before they become observations.

How this addresses your situation

Specific modules that map to what you said you are dealing with.

Scoping workbook expanding cycle over cycle: modules 1, 11, 12 produce the artefacts that reverse that trend.

QSA pushback on the defined approach for one or two controls every cycle: modules 2 and 12 produce the customised-approach case and the meeting flow.

Tokenisation and P2PE adoption that engineering keeps building around: modules 3 and 4 produce the letters and memos that turn the adoption into actual scope reduction.

Large merchant security questionnaires consuming a week per quarter: modules 6, 7, and 9 produce the AOC language, the answer library, and the chargeback data-flow memo that cut response time.

What you get with this course

Twelve written modules covering each artefact named above, with worked examples drawn from acquirer and processor environments.
Downloadable templates: scoping workbook, customised-approach worksheet, tokenisation letter, P2PE boundary memo, segmentation test evidence pack, RACI chart.
A hand-built implementation playbook scoped to the components you list on intake, written specifically for your environment rather than as a generic checklist.
30-day money-back guarantee if the course does not produce at least one usable artefact for your next assessment cycle.

What you will have in hand by Day 1, Week 1, Month 1

Within 24 hours of purchase: learning environment access provisioned and the hand-built implementation playbook delivered.

Modules 1 to 4 in the first week: scoping workbook rebuilt, first customised-approach worksheet drafted, first tokenisation letter started.

Modules 5 to 8 in the second week: P2PE memo, segmentation evidence pack, AOC language updated, fraud-service scoping decision documented.

Modules 9 to 12 in the third week: chargeback data-flow memo, legacy boarding migration case, RACI signed off, QSA meeting runbook prepared.

Ongoing: quarterly RACI review cadence and template refresh against the latest PCI DSS v4.0.1 guidance.

Before and after

Before

The scoping workbook is a diagram. The QSA reads it once and asks for everything. Each component stays in-scope because no engineering owner has signed a de-scoping case. Merchant questionnaires get rewritten from scratch every quarter. Customised-approach worksheets never get attempted because the structure looks too hard.

After

The scoping workbook is a written case per component. Three components are out of scope this cycle because the tokenisation letters and P2PE memos hold up. Two customised-approach worksheets are signed off and the QSA accepted them on first read. Merchant questionnaires get answered from the library in two days, not two weeks. The RACI names an engineering owner per CDE component and scope is smaller next cycle.

What happens if you do not address this

The CDE grows another 15 to 25 percent over the next assessment cycle. The QSA spends an extra week onsite. One or two compensating controls get flagged because the underlying scope-reduction case was never written. A large merchant escalates because the AOC language did not match what they were promised in procurement. None of this is fatal in any single cycle. The cumulative cost is the security lead's calendar and the program's credibility, both compounding the wrong way.

Who it is for

A security or compliance lead inside a merchant acquirer, payments processor, or large fintech who owns PCI DSS scoping, attestation, and the conversation with the QSA. You have at least one production environment that touches PAN, at least one product team pushing new merchant-facing functionality every quarter, and at least one merchant segment asking pointed questions about your AOC. You are not the QSA. You are the person inside the company who has to make the QSA's life easy and the engineering team's life possible.

Who this is NOT for. A QSA looking for assessment methodology. A merchant trying to get to SAQ A. A consultant selling PCI readiness gap assessments. The course is built for the person inside the acquirer or processor who owns the scope diagram and the AOC year over year.

How it arrives

Text-based course in the Art of Service learning environment, plus downloadable templates and worked examples for every module, plus the hand-built implementation playbook delivered alongside course access.

Time investment. About 12 to 16 hours of reading and template work spread over three weeks, plus the time needed to walk each draft past the relevant engineering owner before the QSA cycle starts.

Why $199 is the right number

Generic PCI DSS v4.0.1 readiness courses cover the standard, not the artefacts an acquirer security lead has to produce. QSA-led readiness assessments give you findings, not the writing skill to defend a customised-approach worksheet. Internal templates carried over from prior cycles encode the same scope creep the program is trying to reverse. This course is the artefact layer the others assume already exists.

FAQ

Is this aligned to PCI DSS v4.0.1 specifically?

Yes. The customised-approach worksheets, the targeted risk analyses, and the testing procedure language all match the v4.0.1 reporting template. The course will be updated when the next revision lands.

Will this work if our QSA is conservative?

The worksheets and letters are written for a conservative QSA. The point is to give the assessor language they can paste into the report, not language that requires them to defend a stretch.

What does the hand-built implementation playbook actually cover?

On intake you list the CDE components, the tokenisation surface, and the P2PE deployment if any. The playbook is then written specifically to your component list, with the scope-reduction case partially drafted for each one. It is not a generic checklist.

What about SAQ-level merchants we acquire?

Module 6 covers the AOC language merchants read, and module 7 covers the questionnaire library. Both are designed for the acquirer side of the merchant relationship, not for the merchants themselves.

Refund policy?

30 days, full refund, if the course does not produce at least one usable artefact for your next assessment cycle.

30-day money-back guarantee. If after a week of working through the materials this is not what you needed, reply to the receipt email and a full refund is processed. No questions, no forms.

Within 24 hours your account in the learning environment is provisioned and the tailored implementation playbook is delivered alongside it.