Encrypting with Evervault reduces your PCI DSS compliance scope.
The Payment Card Industry Data Security Standard (PCI DSS) — published in 2005 — is a global security standard which applies to any organisation which stores, processes or transmits credit card data (”Cardholder Data”). The standard is designed to mitigate the risk of cardholder data theft, and drastically reduce successful card fraud. Card fraud is still increasing yearly, and according to a European Central Bank report, 2019 saw card fraud figures hitting €1.87 billion globally.
The presence of PANs (Primary Account Numbers — more often referred to as credit card numbers), PINs or Sensitive Account Data (e.g. card validation codes, PINS, magnetic stripe contents, or anything used to authenticate cardholders) in an environment is the factor which determines whether an organisation is in scope for PCI DSS. Organisations who impact the security of a Cardholder Data Environment (CDE) can also be in scope for PCI DSS.
Organisations who have been found to be non-compliant or breached can be subject to fines, increased transaction fees and, in some extreme instances, termination of an acquiring contract. Fines can vary, but a breached organisation should expect to:
- Pay between $3 (PAN only) and $18 (PAN with CVV/PIN) per card breached;
- Absorb the costs of the remediation effort to contain and eradicate the threat actor; and
- Lose access to the card networks—effectively shutting off the ability to process card payments until such time that the organisation can prove the threat is neutralised.
PCI DSS is a particularly rigorous security standard (an annual spend of $100k+ is not uncommon), and with that rigour comes significant overhead required to manage and demonstrate the continuous security of card data. That’s why organisations who handle cardholder data are wise to de-risk and thereby de-scope their environments.
Why is PCI DSS Required?
PCI DSS is mandated by six major Card Brands (Visa, Mastercard, JCB, Amex, Discover and Union Pay) and is contractually enforced by Acquiring Banks.
If you are a merchant and have signed an acquiring contract with a bank since 2005, it is highly likely that you are contractually bound to be PCI DSS compliant.
It applies to service providers too. If you are a service provider, it’s likely that your merchants will be asking for your Attestation of Compliance (AoC), and its absence can often result in barriers to winning business.
Audit requirements, rigour of audit and stakeholders differ based on the business model and volume of transactions, but the table below gives a high-level overview:
|Level||Service Provider||Merchant||External Audit Required||Attestation|
|1||>300k||>6m||Yes||Report on Compliance (ROC)|
|2||<300k||1-6m||No||Self Assessment (SAQ)|
|3||n/a*||20k-1m||No||Self Assessment (SAQ)|
|4||n/a*||<20k||No||Self Assessment (SAQ)|
Service providers can only be categorized as Level 1 or Level 2.
Where do I start with PCI DSS?
Getting started can seem overwhelming — there is a lot of content and nuance to decipher. However, like any audit, the first step is to determine scope. The Cardholder Data Environment (CDE) comprises people, processes, and technologies that store, process, or transmit cardholder data or sensitive authentication data. By mapping out your cardholder data flows, you can determine your scope.
PCI DSS requirements apply to all system components included in or connected to the CDE. In the simplified diagram below—which describes a system handling plaintext credit card data—all components are in scope for the 300+ PCI DSS Requirements, because they directly store, process or transmit card data (or connect to systems which store card data). For developers impacted by these requirements, it becomes critical that you secure the data, infrastructure and code in your CDE.
What does this mean for developers?
Traditionally, responsibilities have been assigned to specific skill sets like network engineers, database administrators, and systems administrators. In smaller companies comprised of full-stack developers, the technical and management implementation across all areas may fall squarely within their remit. Some of the controls you may be responsible for are listed in the table below.
- Network Security
- Rules management
- Load balancing
- System Hardening and Configuration
- Secure Cryptographic Implementation
- Encryption Key Management
- Algorithm selection and configuration
- TLS Configuration
- Anti-Malware Management
- Secure Coding Training
- Dependency Assessment
- Application Security
- Web Application Scanning (DAST/SAST)
- Dependency Analysis
- OWASP Top 10 training
- Peer Code Review
- Software Development Change Management
- Defensive Programming Techniques
- Script Inventory Management
- Patching and Vulnerability Management
- Strict Change Management
- Segregation of Cloud Accounts
- Implementation of Least Privilege principle
- Authentication Security
- Multi-Factor Authentication
- Physical Security
- Logging, Monitoring and Alerting
- 24x7 Response
- Intrusion Detection
- Vulnerability Scanning
- Penetration Testing
- Risk Assessment
- Policy Development
- Incident Response Management
- Awareness Training
- Threat Landscape Monitoring
- Phishing Simulations
- Third-Party Risk Management
Achieving and maintaining PCI DSS compliance typically requires an enormous engineering effort. This is often expensive, and diverts engineering effort away from the core product.
The autonomy to focus on product is revoked in order to fulfil onerous compliance requirements.
How can I reduce the burden?
There are three primary ways to reduce the burden of PCI DSS Compliance.
1. Never handle plaintext card data
By never handling plaintext card data, your scope is hugely reduced — from ~300 controls to 12 basic security hygiene and policy-based controls. The technical controls can be managed through software:
- Authentication Configuration
- User Account Management
- Embed iFrames from Level 1 Service Providers (like Stripe Elements or Evervault Inputs)
- Leverage Network Encryption Proxies (like Evervault Inbound Relay)
- Completely outsource processing and application management to a compliant third-party.
By automating your PCI DSS compliance program with third-party and/or in-house tooling, you can reduce the human/time investment despite still being responsible for mapping to all ~300 PCI DSS controls.
- Using pre-built secure Terraform templates
- Automated patching
- Automated vulnerability scanning
- Automated exception remediation
- Integrated governance management systems like Vanta or Secureframe.
3. Reduce CDE footprint
By reducing the footprint of your Cardholder Data Environment, you can reduce the effort required to comply with all ~300 PCI DSS controls by making sure they only apply to a smaller number of people, processes and systems.
- Segment people involved with card data processing from those that do not
- Architect software such that the Cardholder Data Environment is entirely segregated from the rest of your infrastructure.
Evervault and PCI DSS
Evervault provides a complete solution to help organisations minimize the effort required to become PCI DSS compliant, and to de-risk their environments from cardholder data breaches.
Using Evervault reduces the PCI DSS mandated controls to the following:
- Instance patching and vulnerability scanning
- Authentication Security and MFA
- Script and Code Dependency Inventory Management
- Third-Party Risk Management
- Incident Response Management
Evervault Inputs makes it easy to collect cardholder data securely in the browser with our client-side SDKs.
Evervault Inputs is served within an iFrame retrieved directly from Evervault’s PCI-compliant infrastructure, and all operations on card data, such as validity checks, also occur within the Evervault environment.
Adopting this approach for card data collection can reduce your PCI DSS compliance scope to the simplest form (SAQ A Control Set), once integrated correctly.
You can learn more about Evervault Inputs on the Inputs product page.