P2PE and tokenisation: how each one changes your scope

Two different mechanisms with two different effects on what you have to assess. Both reduce scope going forward, and neither does anything about the data you already hold.

P2PE and tokenisation both get described as ways to take systems out of PCI scope. They work differently, they apply at different moments, and conflating them leads to claiming a scope reduction you have not earned.

What each one does

The distinction that matters: P2PE keeps card data from entering your systems in usable form in the first place. Tokenisation removes a reason for it to stay.

The conditions attached

For P2PE, the scope reduction available depends on whether the solution is a validated one listed by the PCI SSC, and on your implementing it as the solution requires. A P2PE Instruction Manual comes with a validated solution and describes what you must do; departing from it undermines the claim. Encryption between two points is not the same thing as a validated P2PE solution, and the two get conflated in sales conversations.

For tokenisation, the relevant question is whether the token can be used to obtain the original number, and where the mapping between them lives. If the vault is yours, it is squarely in scope. If it is the provider's, that is a Requirement 12.8 relationship with a responsibility split you should have in writing.

The current requirements for both are in the standard and in the SSC's supporting material. Check them there rather than relying on any summary, including this one.

The standard says this itself about P2PE: a validated solution can significantly reduce the number of PCI DSS requirements applicable to a merchant's cardholder data environment, but it does not completely remove the applicability of PCI DSS in the merchant environment. Validation is still determined by your acquirer.

The limit both share

Both are forward-looking. They change what happens to card data from the point you implement them.

Neither touches the card data already sitting in your estate: the exports taken last year, the spreadsheets built before the change, the emailed numbers in three mailboxes, the reconciliation files in a finance folder. That data is unaffected by a decision made afterwards, and it keeps those systems in scope regardless of how clean the new flow is.

This is the specific way a scope-reduction project fails to reduce scope. The architecture is genuinely better and the assessment does not shrink, because nobody removed the historic data and nobody looked for it.

Doing it in the right order

1. 1Implement the mechanism, following the solution's own requirements.
2. 2Search the estate for card data predating the change, including endpoints and mailboxes.
3. 3Remove what you find, and record the removal with a date.
4. 4Redraw scope, and confirm it against the search result rather than against the new architecture diagram.

Steps two and three are the ones that get deferred, because the project felt finished at step one.

How EmberHound fits

EmberHound scans enrolled company devices for stored card data and reports what it finds by location, which is how step two gets answered and how step four gets evidenced.

It does not implement P2PE or tokenisation. Those come from your payment provider.

This article is general information, not assessment advice. The standard and the SSC's P2PE and tokenisation material are the authority; your QSA determines what applies to you.