Description

A focused course, tailored for you

PCI DSS 4.0 Tokenisation Engineering for Merchant Platforms

The week-by-week build for security engineers owning cardholder-data scope reduction on a multi-tenant commerce platform.

Your merchants want SAQ-A. Your platform architecture, with embedded checkout, partner pixels, and a webhook fabric, keeps dragging them back toward SAQ-D. PCI DSS 4.0 made the scoping calls harder, not easier.

$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

Security engineering on a multi-tenant merchant platform sits at the intersection of three forces that pull in different directions. The merchant wants the smallest possible SAQ. The product team wants frictionless checkout and partner extensibility. The PCI Council's 4.0 requirements (3.4.2 PAN rendering, 6.4.3 payment-page script controls, 11.6.1 change-and-tamper detection on the payment page, 12.5.3 scope-confirmation cadence) want explicit, evidenced, repeatable control. The engineer in the middle is the one who has to translate all three into deploy-pipeline gates, code-level enforcement, and audit artefacts a QSA will accept. Most internal scope diagrams are 18 months old. Most token-vault threat models stopped at the boundary diagram. Most pixel-and-script inventories live in a spreadsheet a product manager updates when they remember. 4.0 removes the room those gaps used to live in, and the deadline for the new requirements has passed for assessments starting now.

What you walk away with

Threat-model the token vault and checkout iframe boundary against PCI DSS 4.0 requirements 3 and 4, in a form a QSA will accept as evidence.
Engineer the payment-page script inventory and tamper-detection control (6.4.3, 11.6.1) into the deploy pipeline so merchant-installed pixels are enforced, not catalogued after the fact.
Reduce merchant scope from SAQ-D toward SAQ-A by re-architecting the surfaces that historically pulled them back in (App Bridge embeds, service-worker caching, third-party analytics).
Build the change-and-inventory gate (12.5.3, 12.5.4) so the scope-confirmation cadence runs from CI/CD rather than a quarterly spreadsheet review.
Produce the QSA-facing artefact pack for each control family: data-flow diagrams, segmentation evidence, sample-set rationale, and the operational runbook that ties them together.

The 12 modules

Module 1. Mapping the cardholder-data flow across a multi-tenant merchant platform

Start with the actual surfaces a merchant touches: hosted checkout, embedded payment fields, App Bridge surfaces, partner pixels, webhook fabric, analytics pipeline, support tooling. Build the data-flow diagram QSAs want to see, with the trust boundaries marked at the points your platform actually enforces them. Output is a versioned diagram that the deploy pipeline can reference and that the next assessment will use as its starting artefact.

Module 2. PCI DSS 4.0 vs 3.2.1: what changed for an engineer, not a policy writer

Requirement-by-requirement walk through the 4.0 changes that touch engineering work: targeted risk analysis (12.3.1), customised approach option for individual requirements, the explicit script-inventory and tamper-detection requirements (6.4.3, 11.6.1), the PAN rendering update (3.4.2), and the authentication and key management shifts. The reading is short. The implications for the codebase are the focus.

Module 3. Tokenisation architecture: format-preserving, vault-based, and the hybrid your platform probably runs

Walk the three dominant token architectures and the trade-offs each one makes against requirement 3.5 and 3.6. Format-preserving vs vault-based vs hybrid. Where each one hides scope and where each one exposes it. The decision table for which architecture to push toward when a merchant feature request would expand the token surface.

Module 4. Threat-modelling the token boundary with STRIDE and DREAD, scoped to 4.0

Apply STRIDE element by element to the token vault, the token-issuing service, the detokenisation endpoint, and the surfaces that handle tokens vs PANs. Produce the threat-model artefact a QSA will accept as evidence under the customised approach for requirement 11.4 penetration testing. Includes the template the assessment team can refresh quarterly.

Module 5. Payment-page script inventory and tamper detection (6.4.3 and 11.6.1) as code

The two new 4.0 requirements that broke the most platforms. Build the script-inventory mechanism into the deploy pipeline so every script on the payment page is authorised before it ships. Build the tamper-detection control with subresource integrity, content-security-policy reporting, and a monitoring backend that catches a third-party-injected pixel within the change-detection cadence the requirement specifies.

Module 6. Segmentation engineering: VPC, service-mesh, and the merchant-extensibility tension

Segmentation is the cheapest scope reduction available. Most merchant platforms underuse it because the extensibility model fights it. Walk the segmentation patterns that work for embedded checkout, partner-extension surfaces, and webhook delivery to merchant-owned endpoints. The segmentation-evidence artefact pack a QSA will accept under 1.3.1 and 1.4.

Module 7. Key management and the HSM integration: requirement 3.6 and 3.7 engineered

Key-management requirements are where most platforms have aging documentation. Engineer the key-generation, key-rotation, key-revocation, and split-knowledge flows so they run as code against an HSM or KMS, with audit trails the assessment team can sample without asking engineering for screenshots. Includes the runbook for a quarterly key rotation that does not break merchant integrations.

Module 8. Authentication and access control across the engineering and operational paths (8.x and 7.x)

MFA on every account with access to cardholder data, including the engineer with a debug shim, the support agent with a customer-impersonation tool, and the data engineer with a query backend that touches detokenised data. The 4.0 changes around MFA implementation, password length, and session management, walked at the code and IAM-policy level.

Module 9. Logging, monitoring, and the 10.7 detection-and-response engineering

What 4.0 requires you to log, how long to retain it, and the engineering work to make sure detection-and-response runs on the right signals. The SIEM rules that catch a card-stealing pixel, a detokenisation spike, a service-account credential abuse. The retention-and-integrity controls (10.5.x) that survive an audit sample.

Module 10. The scope-confirmation cadence as a CI/CD gate (12.5.3 and 12.5.4)

Most platforms run scope confirmation as a quarterly spreadsheet review. 4.0 raised the bar. Build the scope-confirmation control as a deploy-pipeline gate: a new surface ships only after the data-flow diagram, the segmentation evidence, and the requirement-applicability mapping are updated. The artefact the QSA samples is the pipeline output, not a Word document.

Module 11. Third-party service provider management and the shared-responsibility matrix (12.8)

Your platform depends on a payment processor, a fraud service, an analytics vendor, a CDN, and likely several partner-built extensions. 12.8 asks for a written acknowledgement and a maintained list. Engineer the shared-responsibility matrix so the moment a vendor's PCI scope changes, the platform knows. The template, the cadence, and the integration with your vendor-management system.

Module 12. The QSA-facing artefact pack and the assessment-ready engineering posture

Wrap-up module. Produce the artefact pack a QSA will sample without back-and-forth: data-flow diagrams, segmentation evidence, threat-model output, key-management runbooks, script inventory snapshots, tamper-detection alert history, scope-confirmation gate logs. The engineering posture that turns the assessment into a sampling exercise rather than a discovery one.

How this addresses your situation

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

The 02:14 on-call PCI scoping question that touches four surfaces at once.

The product PRD for a partner pixel feature that would drag merchants from SAQ-A back to SAQ-D.

The QSA's sample request for the script inventory under 6.4.3, with the assessment starting next month.

The retro after a merchant's auditor flagged the analytics pipeline as in-scope because the data-flow diagram was 18 months old.

What you get with this course

12 written modules in the Art of Service learning environment, scoped to security engineering on a multi-tenant merchant platform.
Downloadable templates for each PCI DSS 4.0 requirement family the course covers: data-flow diagram, threat-model artefact, script inventory schema, key-rotation runbook, scope-confirmation gate definition, shared-responsibility matrix, QSA artefact pack index.
The hand-built implementation playbook, scoped to the merchant-platform architecture and the surfaces you specify on enrolment.
Worked examples per module showing the artefact in a state a QSA would accept.
30-day money-back if the engineering posture the course produces is not assessment-ready.

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

Within 24 hours your account in the learning environment is provisioned alongside the tailored implementation playbook scoped to the platform surfaces you specify on enrolment.

Week 1: modules 1 to 4. Map the cardholder-data flow, walk the 4.0 changes, choose the tokenisation architecture, threat-model the boundary.

Week 2 and 3: modules 5 to 8. Script inventory and tamper detection, segmentation engineering, key management, authentication and access control.

Week 4: modules 9 to 12. Logging and monitoring, scope-confirmation as a CI/CD gate, third-party management, the QSA-facing artefact pack.

Before and after

Before

Scope diagrams 18 months old. Script inventory in a spreadsheet a product manager updates from memory. Tamper-detection that catches the obvious pixel but missed the service-worker caching path. Key-rotation runbook last opened during the previous assessment. Scope-confirmation cadence done by quarterly meeting. Every assessment runs as discovery rather than sampling.

After

Scope diagrams generated from the deploy pipeline and versioned in the repo. Script inventory enforced at deploy time, not catalogued after the fact. Tamper detection wired into CSP reporting and SRI with a monitoring backend the SIEM consumes. Key-management runbook executable. Scope-confirmation as a CI/CD gate. Assessment is a sampling exercise the QSA can run on artefacts you generated continuously.

What happens if you do not address this

A merchant's QSA flags a previously SAQ-A surface as in-scope. The platform has 30 days to evidence the control or accept the scope expansion. Without the artefact pack and the deploy-pipeline gates, the engineering team spends six weeks reconstructing diagrams, sampling logs by hand, and writing compensating-control narratives. That work happens on top of normal feature work. The cost in engineering time, in merchant trust, and in the assessment outcome itself is the thing this course is built to remove.

Who it is for

Built for the security engineer or staff-level security engineer who owns part of a merchant-facing platform's cardholder-data environment. You write code, you review architecture, you sit in on QSA calls, you push back on product when a new feature would expand scope, and you are the person engineering reaches for when a merchant asks 'are we still SAQ-A on this surface?' You work alongside an internal compliance function but you are the one who has to make the controls real in the platform.

Who this is NOT for. Not for QSAs writing reports. Not for compliance analysts who don't touch the codebase. Not for product managers looking for a 4.0 overview deck. This is engineering work.

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. Roughly 4 to 6 hours per week across four weeks. Most of the work is engineering done against your own platform repo and pipeline using the templates as the starting point.

Why $199 is the right number

The PCI Council's 4.0 reference documents are free, exhaustive, and policy-oriented. The QSA's pre-assessment workshops are scoped to their specific reporting needs. Vendor courses from token-vault providers focus on their own product surface. This course is the engineering build a platform security engineer runs against their own architecture, with the artefacts a QSA will sample rather than the policy a compliance team will file.

FAQ

Does this cover SAQ-A-EP and the eligibility criteria changes?

Yes, module 1 and module 5 cover the SAQ-A vs SAQ-A-EP scoping calls and the new criteria around script controls that determine which one a merchant qualifies for.

Is this product-specific to a particular checkout or payment processor?

No. The course is architecture-pattern based. The implementation playbook is scoped to the surfaces and the processor stack you specify on enrolment.

Will it help if our QSA has already started this year's assessment?

Yes. Modules 1, 4, 5, and 12 are usable mid-assessment to produce the data-flow diagram, threat-model artefact, script inventory, and artefact pack the QSA will accept as evidence on requirements that are otherwise heading for a finding.

Do I need policy approval to use the templates?

The templates are engineering artefacts (data-flow diagrams, threat-model output, runbooks, gate definitions). They feed the policy work, they do not replace it. Your compliance function will recognise them as control evidence.

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.