How to Implement Card Tokenization in 2025: A Comprehensive Guide
Implementing card tokenization in 2025 is straightforward and versatile. It also remains a crucial step to enhance payment security and streamline compliance efforts.
Implementing encryption can be daunting. It’s hard to know where to start, and there are many questions to consider:
By following these steps, your organisation can start encrypting data while avoiding the pitfalls many companies fall into while trying to increase their security posture:
Drivers for encryption primarily fall into two categories:
Implementing encryption is one of the most effective controls to mitigate the severity of a sensitive data breach. A well-implemented solution will segregate the encrypted data from the encryption keys so that the impact is negligible if the entire database is compromised in an external attack, as part of a storage misconfiguration error or during a malicious insider breach.
There are many standards and regulations that require data encryption for specific data categories; we commonly work with organisations that must adhere to standards and regulations such as PCI DSS (PAN and CVV), GDPR (Special Category) and the California Security Breach Information Act 2003.
Beyond global standards and regulations, cyber insurance policies are increasingly mandating specific categories of data are encrypted to mitigate the risk of breach. The absence of encryption may result in the non-payment or reduction of a claim in the event of a breach.
These factors are among those which you should consider when deciding what data to encrypt.
There are three steps to understanding your data flows:
Here’s an example table for documenting relevant information when conducting the business and technology flow mapping exercise:
Sources | Channel | Storage Locations | Data flow Direction | Data Type | Regulations and Standards |
---|---|---|---|---|---|
Web Requests (website / APIs) | App.acmeFE.com | S3 (Name) | Inbound | CVV, PAN Global Special Category | PCI GDPR, CCPA, POPIA |
Web Requests (website / APIs) | App.AcmeBE.com | RDS (Name) | Inbound | CVV, PAN Global Special Category | PCI GDPR, CCPA, POPIA |
Web Requests (website / APIs) | App.BackOffice.Acme.com | Dax (Name) | Inbound | CVV, PAN Global Special Category | PCI GDPR, CCPA, POPIA |
Web Requests (website / APIs) | sft.acme.com | S3 (Name) | Inbound | EFT - Banking Details | GDPR, California Security Breach Act |
Web Requests (website / APIs) | App.stripe.com | - | Outbound | CVV, PAN, Name | PCI DSS |
Web Requests (website / APIs) | App.adyen.com | - | Outbound | CVV, PAN, Name | PCI DSS |
Web Requests (website / APIs) | sft.databroker.com | - | Outbound | Personal Data, Special Category | GDPR, CCPA, POPIA |
You can download your own copy of the table to use for identifying your key information flows and information types here.
The information classification policy will vary depending on geography, sector, the type of information processed, and organisational risk appetite. What is consistent in all classification policies are the following:
A typical policy will apply security mitigation on the basis of risk. “Top Secret” or “Restricted” information will attract greater attention than information categorised as “Internal” or “Public”. The most critical information is always encrypted.
Before executing the plan, you should ensure you are fully aware of the potential implications of implementing the encryption scheme.
If they do, you can leave the information in the clear (depending on the driver) or rewrite the reports and queries considering the new context.
Once you understand the relevant standards/regulations and how they apply to your data flows, reports and queries, you can begin to encrypt data.
Organisations typically start with a single workflow, implement the encryption solution and monitor. E.g. PCI DSS requires that the Primary Account Number and CVV must always be encrypted, Using the Evervault transparent encryption proxy - Relay, there is no need to change the database schema, worry about managing keys or how to match decryption keys with backup data. All of this is all taken care of by Evervault. An original inbound flow (top) vs the Evervault flow (bottom) is shown for reference:
If you want to share the data with another third party, the converse is the case, and you can share the decrypted data with them.To gain maximum protection, organisations should continue to increase the types and volume of information encrypted and adopt this model to improve their security posture.
Evervault scales with organisations as they increase the use of the platform. In a traditional environment, the complexity of having multiple systems with multiple keys for encryption and decryption can become overbearing, and particularly high risk if those keys are mismanaged. Evervault mitigates the risk of key mismanagement by managing keys from the outset, automatically identifying encrypted data, and storing the associated decryption keys directly in the Evervault platform.Some organisations (such as those that process sensitive health or payment data) must process that data in high-trust environments. For these use cases, Trusted Execution Environments (TEE) are among the state-of-the-art technologies available. Often referred to as Confidential Computing, these environments are highly restricted with reduced visibility from Cloud Service Providers, limited I/O, limited logging, closed communication channels by default and critically, the ability to attest that code running in a cloud environment matches exactly the code produced in the organisation's CI pipeline, providing unparalleled integrity guarantees for applications running on the cloud.
Evervault has built Cages on top of AWS Nitro Enclave TEE technology, allowing organisations to run their applications (Docker Images) on encrypted data in a high trust, cryptographically attestable environment.
You can start encrypting data today by creating an Evervault account.
Head of Compliance