Accelerate PCI DSS Adoption with MongoDB Atlas

What PCI DSS Looks Like, and Where the Layers Split

The PCI Security Standards Council maintains PCI DSS and organizes a set of requirements grouped under control objectives:

Under the shared-responsibility model, these requirements split across these layers:

• Infrastructure layer (the provider's responsibility): Comprises physical security, network controls, platform patching, and encryption at rest of the underlying storage. MongoDB Cloud is a PCI DSS certified service provider, validated by a QSA, Coalfire Systems. For the CHD environment in MongoDB Cloud, a QSA can rely on the MongoDB Cloud AOC, available on request through the MongoDB Trust Center. This pre-validated layer eliminates the need for customers to re-audit the underlying infrastructure.

• Application layer (the customer's responsibility): Comprises how the product stores, protects, queries, masks, and audits CHD, and who is allowed to read the information. This layer remains the customer's design decision.

Figure 1. PCI DSS shared responsibility layered model

click to enlarge

The PSP project fills the application layer. It comprises a reference architecture and a set of best practices. It shows how to use MongoDB to align the application layer with the PCI DSS control objectives for protecting stored data, restricting access, monitoring it, and reducing audit scope. This project constitutes a starting point to accelerate the PCI DSS adoption.

The Architectural Proposal

The PSP project is a PCI DSS-aligned PSP platform. It runs the payment lifecycle on MongoDB Atlas: card checkout and authorization, automated fraud scoring, and multi-tier analyst investigation. It shows how analysts can search encrypted data with a clear design philosophy:

Encrypt everything. Query anything. Keys are yours.

With the infrastructure layer inherited from Atlas (see Figure 1), the remaining work happens at the application layer. Atlas provides diverse features to support this work, with Queryable Encryption being the central one. The full set of features is enumerated in the MongoDB capabilities section.

Queryable Encryption in Focus

With a conventional approach, a field is either kept in plaintext so it can be searched (readable by anyone with database access), or encrypted so it is protected (but no longer searchable). Queryable Encryption removes that either/or for the query types it supports.

Figure 2. MongoDB Encryption Architecture: Queryable Encryption, Key Management, and Data Protection Layers

click to enlarge

For an equality-searchable field, the flow proceeds as follows:

• The driver encrypts the search value on the client side, using the field's DEK.

• The server matches that encrypted value against an encrypted index. It compares ciphertext to ciphertext and does not decrypt the field.

• When matching documents return to the application process, the driver decrypts the target fields in memory. MongoDB Atlas stores and processes only ciphertext, held as BSON Binary Subtype 06; as a result, a database administrator with full cluster access sees only opaque bytes.

The concrete effect in the PSP project: a fraud analyst searches for a customer by encrypted email, phone, or account reference and gets the record back, while the plaintext value does not reach Atlas. This capability keeps sensitive PII encrypted at rest and available by value, without the bulk decryption that widens the CDE.

Fields that need protection but not search use a non-searchable mode, decrypted only for an authorized, escalated request. The data model section covers both modes and the fields they protect.

MongoDB Capabilities for the Application Layer

The PSP project combines several MongoDB and Atlas capabilities. Each maps to a specific part of the PCI DSS application-layer work:

Adjacent Use Cases

The core principles of this solution, including a stable API boundary, field-level Queryable Encryption, and a DEK-per-access-tier model, can be applied to other use cases:

• Open finance: Consent-scoped data access that restricts a third party to the fields a customer authorized, such as PSD2 and consumer data right.

• Healthcare: Protected health information under the HIPAA.

• Insurance and wealth: Platforms handling government identifiers and financial account data under the GDPR.

Architecture Components

The architecture uses the following components:

• PSP dashboard (Frontend): The presentation layer. It does not talk to the database directly. On checkout it tokenizes the PAN so the full PAN is not transmitted or stored by the PSP core.

• PSP API gateway (Backend): The single entry point and the only component that can decrypt protected fields. It holds the Queryable Encryption client, resolves the caller's role, and selects the correct key tier per request. All callers, including the user interface, service accounts, and integrations, pass through the same API and are subject to the same RBAC and key rules.

• MongoDB Atlas (M10 or higher) with Queryable Encryption: Stores only ciphertext (Binary Subtype 06) for every protected field. A database administrator with full cluster access sees opaque bytes. TLS 1.3 protects all data in transit. The PSP project relies on equality search, which is supported in production.

• AWS KMS: Holds the CMK that wraps and unwraps the data encryption keys. The CMK stays in KMS, and MongoDB does not have access to it. A local key provider is available as an offline fallback for demos.

Query Types and How the Project Applies Them

MongoDB Queryable Encryption keeps a field encrypted client-side while still allowing the server to query the ciphertext. The PSP project uses these query types:

• Equality (production): The searchable mode for the PCI DSS-scoped lookup keys. The driver encrypts the query value and matches it against an encrypted index, so the server does not decrypt the field. This feature lets a fraud analyst find a record by email, phone, or account reference without exposing plaintext.

• No query (retrieval-only): The non-searchable mode for the highest-sensitivity fields, including residential address, government identifier, and raw gateway payloads. An authorized client decrypts these fields just-in-time only.

• Range (production): Used for value-band lookups, such as filtering by an amount range. It keeps the amount encrypted.

• Prefix, suffix, and substring (public preview): Demonstrated for KYC style partial-match lookups on encrypted identity fields.

For the PCI DSS-scoped card and PII fields below, the access design reduces to the following categories:

Design choices that keep cardholder data out of scope where possible include:

• PAN tokenization: The application replaces the full PAN with a tok_<uuid> surrogate token and retains only the last four digits for display purposes.

• Zero SAD capture: Endpoints never capture SAD such as CVV or PIN.

Reduce Scope through Segmentation and Tokenization

A common PCI DSS practice keeps cardholder data out of systems that do not need it, so that most of the platform falls outside the CDE. These techniques apply segmentation, which isolates the CDE from the rest of the system, and tokenization, which replaces the primary account number with a surrogate token held in a dedicated tokenization vault. Segmentation is not a PCI DSS requirement, but it takes systems out of scope and reduces assessment cost; when used, it must be documented, justified, and validated.

The PSP project applies these techniques at the data layer:

• The full PAN never resides in the PSP core: The core stores only the surrogate token, the BIN, and the last four digits. Most of the platform carries no cardholder data and stays out of scope. The full PAN belongs to the card-issuer subsystem, which is external in production. In the demo, a replaceable built-in issuer module stands in and stores the PAN in its own isolated vault, encrypted with QE:equality. This field can be matched for exact lookup and duplicate detection without being decrypted.

• PII is centralized: Identity fields, such as email, or phone, live in a single BIAN SD-13 party collection that the agreement, card, and transaction records reference. One place to protect and process a data-subject erasure request.

• Sensitive fields sit behind a separate key tier: QE:none fields use a different data encryption key tier than the searchable QE:equality fields, so the boundary between sensitive and non-sensitive data is enforced by the keys.

This is a reference pattern, not a certification. The CDE definition and its validation remain the customer's responsibility and the assessor's to confirm.

Access Control Enforced Keys, Not Application Code

Separate DEK back the encryption tiers:

• Lookup tier: QE:equality keys are available to all authenticated analyst roles for search.

• Sensitive tier: QE:none keys are available only to a level 2 investigator holding a valid, short-lived escalation token, and to a read-only security auditor.

• The design core: A level 1 client's encrypted-field map omits the sensitive keys, so the driver cannot decrypt those fields and returns them as ciphertext. Field-level access control here is cryptographic rather than a projection in application code, which reduces the risk of an accidental leak through a query bug. When an analyst escalates a case and a level 2 investigator approves, the investigator receives an escalation token that activates the sensitive-tier client pool for that request.