Skip to main content
Privacy Track
Category: Privacy Governance & Design

Tokenisation

Also known as: Tokenization
Simply put

In a data security context, tokenisation is the process of replacing a sensitive piece of data with a non-sensitive stand-in value called a token, so that the original data is not exposed where the token is used. For example, a payment card number can be replaced with a substitute number stored on a phone or watch instead of the real card details. The term is also used more broadly in finance to describe creating a digital representation, or token, of an asset such as a share, bond, or currency that can be recorded and traded, which is a distinct concept from data-security tokenisation.

Formal definition

Tokenisation, as applied to data security, is the substitution of a sensitive data element with a non-sensitive equivalent (the token), which typically has no exploitable meaning or value on its own outside the system that maps tokens back to the underlying data. In payment applications, this involves replacing a primary account number with a stand-in value that is stored on the device rather than the original card number. A separate but related usage in finance describes tokenisation as recording ownership of, or exposure to, an asset as a digital token, often on a blockchain or distributed ledger, enabling those tokens to be programmed, traded, and settled. Note that the evidence provided defines the technique in general and financial terms and does not address how tokenisation is assessed under data protection law; whether tokenised data constitutes personal data, pseudonymised data, or anonymised data is context-dependent and should be assessed separately against the applicable legal framework and current regulatory guidance.

Why it matters

Tokenisation is a widely used data security technique that lets organisations reduce their exposure to sensitive data by replacing it with a stand-in value that has no exploitable meaning on its own outside the system that maps it back to the original. In payment contexts, for example, a card number can be replaced by a substitute number stored on a phone or watch rather than the real card details, so the underlying data is not present where the token is used. This approach is relevant to any organisation seeking to limit where high-risk data such as payment card numbers is stored, processed, or transmitted.

From a data protection standpoint, it is important not to assume a particular legal characterisation of tokenised data. The evidence here defines the technique in general and financial terms and does not address how tokenisation is treated under data protection law. Whether tokenised data amounts to personal data, pseudonymised data, or anonymised data is context-dependent and turns on factors such as who holds the mapping between tokens and original values and how readily re-identification is possible. That assessment should be carried out separately against the applicable legal framework and current regulatory guidance, rather than treated as settled by the use of tokenisation alone.

A further point of care is terminology. The word tokenisation is also used in finance to describe creating a digital representation, or token, of an asset such as a share, bond, or currency, often recorded on a blockchain or distributed ledger. This financial usage is a distinct concept from data-security tokenisation, and conflating the two can cause confusion in compliance and technical documentation. Practitioners should confirm which meaning is intended in any given context.

Who it's relevant to

Engineers and security architects
Those designing systems that handle sensitive data, such as payment card numbers, may use tokenisation to substitute sensitive elements with tokens and limit where original data is stored or transmitted. They should document how tokens map back to underlying data and where that mapping is held, as these factors bear on both security and any subsequent data protection assessment.
Data protection officers and compliance leads
DPOs and compliance leads need to assess, on a case-by-case basis, whether tokenised data constitutes personal data, pseudonymised data, or anonymised data under the applicable framework. The technique itself does not settle that question, so the characterisation should be evaluated against current regulatory guidance rather than assumed.
Privacy and technology lawyers
Lawyers advising on data security measures or drafting related documentation should distinguish data-security tokenisation from the distinct financial concept of asset tokenisation, and avoid asserting a fixed legal status for tokenised data without a context-specific analysis.
Financial services and payments teams
Teams in payments and financial services may encounter both meanings of the term: the substitution of card numbers with stand-in values, and the creation of digital tokens representing assets on a distributed ledger. Clarity about which concept is in play helps prevent misalignment in technical, contractual, and compliance work.

Inside Tokenisation

Token
A surrogate value substituted for an original data element (such as an identifier or account number). The token has no exploitable meaning or value on its own and generally cannot be reversed to the original data without access to the separately held mapping or vault.
Token vault or mapping
The repository or lookup mechanism that stores the association between tokens and their corresponding original values. Because this mapping enables re-identification, it is typically held separately and subject to strict access controls.
Tokenisation process
The method by which original values are replaced with tokens. This may be vault-based (using a stored lookup) or vaultless (using cryptographic or algorithmic techniques). The technique chosen affects the reversibility and risk profile.
Reversibility
The characteristic that, in most implementations, tokenised data can be mapped back to the original by an authorised party. This is a key reason tokenised data generally remains personal data under the GDPR rather than being treated as anonymous.
Relationship to pseudonymisation
Tokenisation is generally regarded as a technique that can achieve pseudonymisation, which is referenced in the GDPR (including in Article 4 definitions and as a security and data protection by design measure). Whether a specific tokenisation deployment meets the pseudonymisation standard depends on how the mapping and additional information are separated and protected; readers should verify against the current official text.

Common questions

Answers to the questions practitioners most commonly ask about Tokenisation.

Does tokenisation make personal data anonymous and therefore take it outside the scope of the GDPR?
Generally no. Tokenisation is typically a pseudonymisation technique rather than anonymisation, because the original values can usually be restored through a token vault, mapping table, or reversible process. Where re-identification remains reasonably possible, whether by the controller or another party with access to the mapping, the data is still personal data and the GDPR continues to apply. True anonymisation requires that re-identification be no longer reasonably possible, which tokenisation on its own does not usually achieve. This assessment is context dependent and should be documented; regulators and guidance have historically set a high bar for treating data as anonymous.
Is tokenised data treated the same as encrypted data under the GDPR?
Not necessarily. Both are often cited as security or pseudonymisation measures, but they operate differently. Encryption transforms data using a key and an algorithm, while tokenisation typically substitutes values with tokens that have no mathematical relationship to the original, relying on a separate mapping to reverse the process. The two can attract different risk considerations and may be assessed differently in a given security or transfer context. Neither is automatically sufficient on its own, and the appropriateness of either should be evaluated against the specific processing and risk, subject to assessment.
Where should the token mapping or vault be stored to support the security benefit of tokenisation?
The security value of tokenisation generally depends on keeping the mapping that links tokens to original values separate from the tokenised dataset, with strict access controls. Storing the vault alongside the tokenised data can undermine the intended protection, because a single point of access could allow re-identification. Access to the mapping should typically be limited, logged, and governed by organisational and technical measures. The specific arrangement should be determined by a risk assessment and documented as part of your accountability record.
Can tokenisation help satisfy the data protection by design and by default expectations?
Tokenisation can form part of a data protection by design and by default approach, as it is a recognised way of reducing the identifiability of data during processing. However, it is one measure among several and does not by itself demonstrate compliance. It should generally be combined with other technical and organisational measures, appropriate legal bases, and governance. Whether it is adequate depends on the nature, scope, context, and purposes of the processing and the associated risks, which should be assessed and documented.
Do data subject rights still apply to tokenised data?
In most cases yes, where the tokenised data remains personal data because re-identification is reasonably possible. Rights such as access, rectification, and erasure can still be engaged, and the controller should consider how to fulfil them when working with tokenised datasets and their mappings. Where a controller genuinely cannot re-identify an individual and can demonstrate this, certain provisions on identification and rights may be affected, but this depends on the facts and should be evaluated carefully rather than assumed.
Should tokenisation and its effect on identifiability be documented in records and assessments?
Generally yes. Because tokenisation is typically a pseudonymisation and security measure, it is relevant to accountability, records of processing, and risk assessments where they are required. Documenting how tokenisation works, where the mapping resides, who can access it, and its effect on identifiability supports demonstrating the appropriateness of your measures. Where the processing is likely to result in high risk, its role should also be considered within the relevant impact assessment. The precise documentation obligations should be verified against the current official text and applicable guidance.

Common misconceptions

Tokenised data is anonymous and therefore falls outside the scope of the GDPR.
Because tokenisation is typically reversible where the mapping or additional information exists, tokenised data generally remains personal data and stays within the scope of the GDPR. It is more accurately characterised as pseudonymisation than anonymisation in most cases; a genuinely anonymous outcome requires that re-identification is no longer reasonably possible, which is subject to assessment.
Tokenisation and encryption are the same thing.
They are distinct techniques. Encryption transforms data using an algorithm and key so it can be decrypted, whereas tokenisation substitutes a surrogate value that typically relies on a separate mapping (or algorithmic method) rather than a decryption key. Both can serve as security measures, but they should not be conflated when documenting technical and organisational measures.
Applying tokenisation is sufficient on its own to make processing compliant.
Tokenisation is a technical and organisational measure that can support security and data protection by design, but it does not by itself establish a lawful basis under Article 6, satisfy Article 9 conditions for special category data, or discharge transparency and other obligations. Compliance remains context and risk dependent.

Best practices

Treat tokenised data as personal data by default and document the assessment justifying any different classification, rather than assuming it is anonymous.
Store and manage the token vault or mapping separately from the tokenised data, with strict access controls, so that the additional information needed for re-identification is kept apart in line with pseudonymisation principles.
Record tokenisation within your technical and organisational measures and, where relevant, in data protection by design and by default documentation, while identifying a lawful basis independently.
Where tokenisation is used for security purposes, evaluate it alongside complementary measures rather than relying on it in isolation to reduce risk.
Document the tokenisation method (vault-based or vaultless) and its reversibility characteristics so that the residual re-identification risk can be assessed and reviewed.
Verify how tokenisation is characterised for any cross-border transfer or specific processing against the current official GDPR text and applicable regulatory guidance, noting that regulator positions can diverge.