Open source payment orchestration and PCI DSS requirement 3

Open source payment orchestration and PCI DSS requirement 3: what a self-hosted card vault must prove

A payments team that self-hosts Hyperswitch has to show how stored account data is minimized, protected and encrypted. Requirements 3 and 4 of PCI DSS v4.0.1 govern the card vault, the retention process and the transit path. Under the in-house model described in the Hyperswitch docs, the merchant or service provider carries full responsibility for PCI DSS certification and data handling, so the vault cannot be treated as a black box owned by the orchestration vendor. The PCI Security Standards Council defines the obligations, but the payment brands decide which entities must validate and run enforcement, and a Qualified Security Assessor or the entity's own assessment on an SAQ determines whether the controls meet the standard. DeployOpen prepares systems, controls and evidence for that assessment, but it does not issue reports, attestations or certificates.

Start with Requirement 3.2.1, which asks for retention and disposal policies covering every location of stored account data, including the Hyperswitch vault, PostgreSQL replicas, Redis, logs and backups. Confirm in writing which fields the orchestrator stores and which are tokenized, and verify on a fixed schedule, at least once every three months, that data past its retention period has been securely deleted or made unrecoverable. Under Requirement 3.3, sensitive authentication data must not be kept after authorization, and any that is held before authorization must be encrypted with strong cryptography. Test this with the actual Router and Scheduler logs and queues, not only with the vault schema.

For rendering PAN unreadable under Requirement 3.5.1, ask whether the design uses keyed hashes under 3.5.1.1, truncation, index tokens or strong cryptography with key management, and document the key hierarchy under Requirements 3.6 and 3.7. Requirement 4.2.1 governs the path between the browser or SDK and the vault, and 4.2.1.1 requires an inventory of trusted keys and certificates. Ask your implementation partner to produce that inventory, certificate expiry tracking and TLS configuration evidence before the first assessment.

How each Requirement 3 and 4 control maps to the Hyperswitch vault

This table pairs each PCI DSS control in scope for stored account data and transit encryption with the function it requires and the Hyperswitch component where that function is configured. Read each row as a question to answer in your own design review, then confirm the setting with your assessor and the Hyperswitch version you deploy. The main takeaway is that most of the evidence sits in the vault, the encryption service and the data stores, so those components should be scoped and documented first.

Control	Function that must happen	Configuration step and component
3.2.1 Retention and disposal	Define retention periods for every location of stored account data, delete or render data unrecoverable after expiry, and verify this at least every three months	Set retention rules per data type in the application configuration, schedule purge jobs through the Scheduler service, and check PostgreSQL, Redis and vault storage for leftover card data during each quarterly check
3.3.1 No SAD after authorization	Do not retain card verification codes, full track data, PINs or PIN blocks after authorization completes, including in logs, caches and queues	Exclude CVV and track data from request logging in the Router, confirm Redis entries for the scheduler queue hold no SAD, and test that authorization payloads are not written to PostgreSQL
3.3.2 SAD stored before authorization	Where SAD must be held electronically before authorization, encrypt it with strong cryptography	Confirm any pre-authorization hold of SAD passes only through the card vault and is encrypted by the encryption service before it reaches storage, and document where that window exists
3.5.1 PAN unreadable	Render stored PAN unreadable using one of the accepted methods: keyed hash, truncation, index token, or strong cryptography with key management	Store PAN only in the card vault (locker) and pass tokens to the Router, database and Control Center, so application tables and Redis hold tokens or truncated values instead of full PAN
3.5.1.1 Keyed hashes of PAN	Where hashes protect PAN, use keyed cryptographic hashes of the entire PAN, with key management under the key requirements	If any service computes hashes for matching or reconciliation, use a keyed hash with keys held by the encryption service, and confirm with your QSA how hashed values are scoped
4.2.1 Strong cryptography in transit	Use strong cryptography and secure protocols for PAN over open, public networks, accept only trusted certificates, and block fallback to insecure versions	Enforce current TLS on the Router ingress, the vault API and connector calls, disable older protocol versions in the load balancer and Helm values, and test that clients cannot negotiate downgrades
4.2.1.1 Trusted key and certificate inventory	Maintain an inventory of trusted keys and certificates used to protect PAN in transit, and check certificate validity and revocation status	Record certificates for the Router, vault, encryption service and each processor endpoint in an inventory, and set expiry alerts that cover the Kubernetes ingress and secrets store
Key management for the vault	Protect and rotate the keys that encrypt PAN, with documented custodians and access limits	Confirm the encryption service holds the master key material outside application pods, and ask the partner to show how rotation affects existing vault records and the PostgreSQL master and replica setup

Which self-hosted platforms fit a PCI-scoped orchestration layer

The vault model decides how much of the cardholder data environment your team owns. The options below differ in where PAN is stored, who holds the keys, and who answers for PCI DSS Requirements 3 and 4. Compare them before choosing a Hyperswitch deployment pattern.

Hyperswitch with in-house PCI vault

Hyperswitch runs the native card vault (locker) inside your own Kubernetes cluster, deployed with the project's Helm charts. The vault is a separate Rust service in its own repository, so you can isolate it at the network and access layer. The Hyperswitch docs state that in this model the merchant is fully responsible for PCI DSS certification and data handling. Check who operates the vault, where its keys live, and how Requirement 3.5.1.1 keyed hashing is implemented.

Self-hosted orchestration with external vault

Hyperswitch handles routing and orchestration in your environment while card data is tokenized by an external PCI vault provider such as VGS or Tokenex. PAN enters your systems only in the provider's vault path, which can shrink the cardholder data environment you must assess. Your team still owns Requirement 4.2.1 for any PAN in transit and the inventory of trusted keys and certificates under 4.2.1.1. Ask the provider for its current attestation and the exact data flows.

Self-hosted orchestration with SaaS vault

Your Hyperswitch deployment stays on your infrastructure, but card storage moves to the SaaS Hyperswitch Vault. This reduces the stored account data you keep on premises while leaving routing, configuration and merchant data under your control. Requirement 3.2.1 retention and disposal still applies to any data you hold, and Requirement 3.3 bars keeping SAD after authorization in every model. Confirm which PCI responsibilities the SaaS provider accepts in writing and how tokens can be exported if you change vendors.

Vault isolation and network segmentation

Whichever vault model you pick, the vault service, its database and its encryption service should sit in a segment that only the orchestration tier and authorized administrators can reach. Scope follows the systems that store, process or transmit account data or could affect their security. Document each connection to the vault and confirm that Control Center users, logs and backups do not carry PAN. Map this design to your segmentation testing before you rely on it for scope reduction.

Control Center access and SSO limits

The Hyperswitch Control Center supports single sign-on only through OpenID Connect, with no SAML, no JIT or SCIM provisioning, and roles managed inside Hyperswitch rather than mapped from your identity provider. Users must be invited first, so access reviews must be run in the platform. This matters for Requirement 7 and Requirement 8 evidence, because the vault can be reached through merchant administration. Confirm these limits with your identity team before you design the admin model.

Upgrade and release tracking

Hyperswitch publishes releases frequently, and v1.128.0 was published on October 16, 2026. Each upgrade can change the vault, encryption service or database schema, so every version needs a change record and a test that confirms PAN is still encrypted at rest and in transit. Track the release notes and set a rule for when a security fix must be applied. Ask any implementation partner how upgrades are tested against the vault before production.

Which vault model changes the Requirement 3 workload

In this model, Hyperswitch runs in your infrastructure with its native card vault, and the Hyperswitch docs state that the merchant is fully responsible for PCI DSS certification and data handling. Nearly the whole Requirement 3 workload stays with your team: the retention and disposal policy covering every location of stored account data, the rules that bar keeping sensitive authentication data after authorization, the method used to render stored PAN unreadable, and the key management behind it. Requirement 4 also stays with you, including the inventory of trusted keys and certificates protecting PAN in transit.

Retention and disposal: Your policy must cover the vault, database replicas, caches, queues, logs and backups, and a quarterly check must confirm that expired data is deleted or unrecoverable.
Sensitive authentication data: Your configuration and connector flows must confirm that card verification codes and PIN data are never persisted after authorization.
PAN rendering: Your team selects and documents the method, such as keyed hashing or strong encryption with key management, and governs the keys.
Transit protection: Your team owns TLS configuration, certificate validity checks and the inventory of trusted keys and certificates.
Assessment: Your environment is in full PCI DSS scope, so you carry the assessment and the attestation.

Confirm with your Qualified Security Assessor or internal assessor which assessment type applies to your environment before you commit to this model.

How to keep stored account data and sensitive authentication data out of the database

Start by separating two data types that teams often lump together. *Stored account data* is the cardholder data you may keep under a documented retention policy, such as the primary account number (PAN) and cardholder name. *Sensitive authentication data* (SAD) is the security information used to authenticate cardholders or authorize transactions, which the PCI SSC glossary lists as card verification codes, full track data, and PINs and PIN blocks. Requirement 3.3.1 bars retaining SAD after authorization, so SAD must never persist in the Hyperswitch database, Redis, logs or backups once the transaction is authorized. Confirm this with a test in which you search every datastore after a test authorization. The 3DS question needs a specific answer from your assessor: PCI SSC FAQ 1603 covers authentication values and SAD, so document how your connectors handle them before you go live. Storing SAD electronically before authorization is a separate rule, covered in PCI SSC FAQ 1154, and it requires strong encryption for the short window in which it exists.

Requirement 3.2.1 asks for a retention and disposal policy that covers every location of stored account data, and your inventory should name each one: the card vault (locker) database, PostgreSQL primary and replicas, Redis, application and webhook logs, reporting exports, reconciliation files, support tickets and backups. For each location, record what is kept, why, how long, and how deletion or unrecoverability is verified. Requirement 3.2.1 also requires a process that confirms at least once every three months that expired data has been securely deleted or rendered unrecoverable, so schedule that check and keep its evidence. The maximum storage period is a question many teams ask, and PCI SSC FAQ 1318 addresses it, but the standard does not set a number for you. Your legal, card brand and business obligations set the period, so decide it in your own policy and have your assessor review it.

What do buyers ask about PCI DSS requirement 3 for a self-hosted vault?

What drives the effort and cost of PCI DSS work for a self-hosted Hyperswitch vault?

The main drivers are how far cardholder data reaches into your environment, which vault model you choose, how many processors and payment methods sit in the route, which assessment type applies, and how large the Kubernetes footprint is. Under the in-house PCI model, the Hyperswitch documentation states that the merchant is fully responsible for PCI DSS certification and data handling, so your own assessment carries the vault. With an external PCI vault provider, the provider's own compliance evidence covers part of that load, but your scope still includes the integration and any card data you touch. Each processor adds connectors, data flows and third-party service provider management. Ask any partner to itemize these drivers in writing before you compare quotes, because the same scope produces very different work depending on the vault model chosen.

How long does a self-hosted PCI DSS vault project take?

Duration depends on the scope you agree, the vault model, the number of processors to connect, and how quickly you can provide inputs. No duration is set by the standard itself, and this page does not state one. The work usually depends on items you must supply: a current data flow diagram, an inventory of where account data is stored, your retention and disposal policies, the list of trusted keys and certificates, access to the Kubernetes environment, and named owners for processor contracts and key custody. Missing inputs are the most common reason plans slip. Ask for a written timeline that lists each client dependency and the assessor's schedule, and ask whether it includes the annual assessment or only the build.

Can an internal team run a self-hosted PCI DSS vault without outside help?

Yes, an internal team can run it alone if it has the skills, time and accountability for each requirement involved. The work spans Kubernetes operations, key management, encryption configuration, logging, access control, segmentation testing, and documentation for every requirement in scope. Requirements 3 and 4 alone cover retention and disposal, unreadable PAN, keyed hashing and strong cryptography in transit, and each needs evidence that holds up at assessment. Many teams keep operations in-house and bring in an implementation partner for the build, hardening and evidence preparation, then assess with a qualified assessor. DeployOpen plans, implements, hardens and documents self-hosted platforms in your own infrastructure and prepares evidence for compliance assessments, but it does not issue audit reports or attestations. Confirm which party owns each control in writing.

Does a self-hosted vault need a ROC or an SAQ, and who signs the AOC?

The answer depends on your merchant or service provider role, your transaction volume and how your payment brands classify you, so confirm it with your acquirer or the relevant payment brand. PCI DSS assessments are documented on official templates: either a Report on Compliance completed by a Qualified Security Assessor, or a Self-Assessment Questionnaire, each with an Attestation of Compliance. A self-hosted vault that stores card data is generally treated as a service provider environment, and the SAQ D for Service Providers is the questionnaire to review. The person who signs the AOC is the officer of your organization accountable for the attestation, and for a ROC the QSA signs the report. The PCI SSC does not enforce compliance. Payment brands decide who must validate and run enforcement, so ask them directly. Certificates are not accepted as validation.

What happens to PCI DSS obligations if the external vault provider changes?

A vault provider change moves stored account data, changes your scope, and requires new evidence. Your responsibility does not disappear with the provider. Before any change, you need a documented plan for how tokens and card data are transferred, verified and securely deleted from the old location, and how you confirm that no copies remain under your retention rules. Requirement 3.2.1 expects you to verify at least every three months that data past its retention period has been securely deleted or rendered unrecoverable, so the exit step must produce records. Review the provider's attestation for the period you rely on, update your data flow diagram, your inventory of stored account data and your third-party service provider list, and retest segmentation. Put the exit steps and the token migration method into the contract and the runbook before the first go-live.

Why do keyed hashes under requirement 3.5.1.1 matter for a card vault?

Keyed hashes matter because a plain hash of a card number can be reversed by guessing the small space of possible PANs, and that weakness is why the standard now expects a keyed cryptographic hash of the entire PAN. Requirement 3.5.1.1 became mandatory on 31 March 2025 and requires key management under requirements 3.6 and 3.7. For a self-hosted vault, this means the hashing key must be generated, stored, rotated and restricted with the same discipline as encryption keys, usually inside an HSM or equivalent protected service. If you use hashes to correlate transactions, check that the hashing design still supports your reporting and fraud use cases, because the same hash must be consistent over time. Ask your partner to show where the hashing key lives, who can access it and how rotation is logged.

Which vault model reduces PCI DSS scope most for a self-hosted Hyperswitch deployment?

Scope is usually smallest when card data never enters your systems, but the right model depends on your processors, your data location rules and the level of control you need. Hyperswitch documents three self-hosted vault models: self-hosted with the native Hyperswitch Vault, self-hosted orchestration with an external PCI vault provider such as VGS or Tokenex, and self-hosted orchestration with the SaaS Hyperswitch Vault. The in-house model keeps the vault in your environment and puts full PCI DSS responsibility on you. The external provider model moves card storage to a third party but leaves integration points in your cardholder data environment, so segmentation and evidence from the provider still matter. Ask each option to be mapped against your own data flow diagram before you choose.

Evidence assessors ask for under Requirements 3 and 4

This table maps each control area in Requirements 3 and 4 to the evidence an assessor will ask for and the Hyperswitch component that typically produces it. Read it as a collection checklist: if a row has no named owner or stored output in your environment, the control will be hard to demonstrate at assessment time.

Control area	Evidence an assessor expects	Component that produces it
Retention and disposal policy (3.2.1)	Written policy with a location inventory of every place stored account data resides, including logs, backups and the vault	Your own data inventory, cross-checked against the vault, Router database, Redis and log stores
Quarterly deletion verification (3.2.1)	Dated records showing each review that data past retention was deleted or made unrecoverable, at least every three months	Scheduled job output and deletion reports you define; confirm what the vault and Scheduler can evidence natively
SAD not stored after authorization (3.3.1)	Configuration and log proof that card verification codes, track data and PINs are not persisted post-authorization	Router configuration and logs, plus vault and database schema checks; confirm the connector payloads that are logged
Encryption of SAD before authorization (3.3.2)	Evidence that any SAD held electronically before authorization is encrypted with strong cryptography	Encryption service and key management configuration; confirm which flows ever hold SAD before authorization
Vault encryption and PAN protection (3.5.1)	Method selected for each PAN store, keyed hash records, truncation rules and key-management procedures	Card vault (locker) configuration and the encryption service; Kubernetes secrets for key material
Keyed hashing and key lifecycle (3.5.1.1, 3.6, 3.7)	Keyed hash specification, key generation, rotation and custodian records, with separation from the data they protect	Encryption service key records and Kubernetes secrets; confirm where master keys are held and who can read them
Trusted keys and certificates in transit (4.2.1, 4.2.1.1)	Inventory of trusted keys and certificates, validity checks, and proof that insecure protocol fallback is disabled	TLS termination points, ingress and Router configuration; certificate monitoring output
Administrative access to payment configuration	Access reviews, role assignments and login records for anyone who can change routing, vault or key settings	Control Center access records and Router logs; note that SSO uses OpenID Connect only and roles are managed in Hyperswitch

What the Hyperswitch software does not satisfy on its own

Installing Hyperswitch gives you a payments engine and a card vault, but it does not give you a PCI DSS assessment, a retention decision or a segmented environment. The cards below cover the gaps that remain with your organization, its assessor and its partners, and what to confirm with each before you rely on the platform for scope reduction.

The assessment and AOC

Hyperswitch is software, so it cannot be certified as PCI DSS compliant. Your organization completes a Report on Compliance with a Qualified Security Assessor or a Self-Assessment Questionnaire, each with an Attestation of Compliance, and the assessment covers your whole environment, not the platform alone. Ask your assessor which SAQ or ROC type applies to your role, and ask Juspay which responsibility matrix the self-hosted model assigns to you. Certificates from vendors are not accepted as validation.

Your own retention decisions

The platform stores what you configure. Requirement 3.2.1 expects a documented retention and disposal policy covering every location of stored account data, including logs, backups, replicas and the Redis cache. Decide how long tokens, payment records and vault entries are kept, then confirm with your assessor that deletion is verified at least once every three months. Hyperswitch will not decide this for you.

Key custody and HSM choices

Encrypting stored PAN with strong cryptography only works if key management is sound. Hyperswitch includes an encryption service for key management, but you decide where master keys live, whether an HSM holds them, who can rotate them, and how key custodians are separated. Requirements 3.6 and 3.7 cover these controls. Ask your partner to document the key hierarchy and confirm with Juspay how the encryption service stores and rotates keys in your chosen deployment.

Control Center SSO limits

The Control Center supports single sign-on through OpenID Connect only. SAML is not supported, there is no just-in-time or SCIM provisioning, users must be invited first, and roles are managed inside Hyperswitch instead of mapped from your identity provider. For Requirement 8 access reviews, this means you need a manual joiner, mover and leaver process for dashboard users. Confirm current behavior against the SSO configuration docs before you commit to an identity design.

Network segmentation and cloud boundaries

Scope depends on what can reach the card vault. Your Kubernetes cluster, PostgreSQL primary and replicas, Redis, the Scheduler and the Control Center all sit on networks you design. Place the vault in an isolated segment, restrict flows from the Router, and confirm that administrative access, logging and backups do not create a path into cardholder data. Your assessor will test this boundary, so document it before the assessment starts.

Third-party service providers in the route

Each processor, external vault provider, fraud tool or hosting provider that touches cardholder data becomes part of your third-party risk program. If you use an external vault such as VGS or Tokenex, the provider's attestation and responsibility split must be on file. Request each provider's current AOC, confirm which requirements they cover for you, and record the gaps in your own assessment. Do not assume a processor's compliance covers your environment.

Customized approach evidence

If you meet a requirement through the customized approach instead of the defined approach, you must document the stated objective, the controls you use, how you test them and the risk analysis behind them. The assessor reviews that evidence in detail, and the work is ongoing rather than a one-time document. Agree with your assessor in advance which requirements you plan to address this way, and budget time to keep the evidence current after each platform upgrade.

How a PCI-scoped Hyperswitch vault rollout proceeds

This sequence takes a self-hosted Hyperswitch card vault from an agreed scope to a documented, repeatable set of PCI DSS Requirement 3 and 4 controls with evidence an assessor can test. Each step names the output that closes it, so scope decisions are made before infrastructure is built.

Confirm vault model and assessment path
Before any build work, the payments owner, security lead and a Qualified Security Assessor (or the team preparing a Self-Assessment Questionnaire) choose one of the three documented vault models: self-hosted with the native Hyperswitch Vault, self-hosted orchestration with an external PCI vault provider, or self-hosted orchestration with the SaaS Hyperswitch Vault. The choice decides who carries which PCI DSS responsibilities, so the in-house model makes the merchant fully responsible for certification and data handling. Done when a signed scope statement names the vault model, the assessment type (Report on Compliance or SAQ) and the responsible party for each requirement. Confirm the applicable SAQ type with your acquirer or the brands, since the brands decide who must validate.
Map every location of account data
Engineers and the assessor trace how PAN, sensitive authentication data and tokens move from checkout through the Router, the card vault, Redis, PostgreSQL replicas, logs, backups, support tooling and any processor connector. The map records where each data element is stored, for how long and who can read it, which feeds the retention policy required under Requirement 3.2.1. Done when the data flow diagram and the storage inventory agree, and every location that holds stored account data appears in the retention policy. Anything not in the map is treated as out of compliance until it is classified.
Configure retention, deletion and SAD controls
The team sets retention periods for each stored data element and configures the platform so sensitive authentication data is never persisted after authorization, covering card verification codes, full track data and PIN data under Requirement 3.3. Where data must be held before authorization, it is encrypted with strong cryptography under the key management design. Done when the configuration review shows no SAD fields written to databases, caches, queues or logs, and each retention rule has an owner and a deletion job. Confirm the exact configuration keys with the Hyperswitch version you deploy, since settings change between releases.
Render PAN unreadable and protect keys
The team selects one of the accepted methods under Requirement 3.5.1 for each place PAN is stored: strong encryption with managed keys, truncation, index tokens or a one-way hash. Where a hash is used, it must be a keyed hash of the entire PAN, which has been mandatory since 31 March 2025. Key generation, storage, rotation and custody are documented under Requirements 3.6 and 3.7, and the encryption service is isolated from application administrators. Done when a key management procedure is approved, a test shows that a database extract yields no readable PAN, and the key custodians are named in writing.
Validate TLS, certificates and the trusted key inventory
Engineers test every path that carries PAN over open or public networks, including checkout to Router, Router to the vault, and connector calls to processors. The test confirms strong cryptography and security protocols are in use, that no fallback to insecure versions is possible, and that certificates are valid, unexpired and not revoked. Under Requirement 4.2.1.1, the team also records an inventory of trusted keys and certificates, which has been required since 31 March 2025. Done when scan output for each endpoint is archived and the certificate inventory lists owner, expiry and renewal process for each entry.
Test deletion and retention enforcement
Testers run the deletion jobs against seeded test data, then check that expired records are securely deleted or rendered unrecoverable, including in replicas and backups where applicable. The process also needs a recurring check at least once every three months under Requirement 3.2.1, so the test is designed to be repeated, not run once. Done when a test report shows expired data is gone from every location in the data map, and the recurring check has an owner and a ticket template. Discuss backup handling with the assessor early, since it is often the hardest location to confirm.
Collect evidence for the assessor
The team assembles the evidence an assessor will sample: the scope statement, data flow diagram, storage inventory, retention policy, configuration exports, key management procedures, TLS scan results, certificate inventory, deletion test reports and access logs. Each artifact is dated, versioned and linked to the requirement it supports. Done when the assessor confirms the evidence set covers the sampled controls, and any gaps are logged as tracked remediation items. DeployOpen prepares this evidence, but only the QSA or the SAQ signatory issues the validation, and PCI SSC does not accept certificates as proof of compliance.
Schedule the next version review
PCI DSS v4.0.1 is the only active version, since v4.0 was retired on 31 December 2024. The PCI SSC ran a request for comments on v4.0.1 from 3 June to 20 July 2026, and as of October 2026 it had announced no release date for a new version. The team records the current version in the control matrix, assigns an owner to monitor PCI SSC announcements, and sets a review trigger for when a new version is published. Done when the review owner, the trigger and the control matrix version are recorded, and the assessor has confirmed the version in the scope statement.

Defined approach or customized approach for Requirement 3

PCI DSS v4.x lets an entity meet each requirement through the defined approach, which follows the requirement as written, or through the customized approach, which meets the stated objective in a different way. The customized approach is open only to entities with robust security and risk management. Compensating controls are a separate route: they apply when an entity cannot meet a requirement explicitly, and they are not a substitute for a customized implementation. For a self-hosted Hyperswitch card vault, the defined approach is the default and the simpler path to evidence, because the requirements on PAN rendering, SAD deletion and retention are specific enough to test directly against the vault's configuration.

The customized approach can suit a team that wants to depart from a specific control, for example by using a different keyed hashing design or key lifecycle than the defined approach describes. The PCI SSC blog on compensating controls versus customized approach explains the difference between the two routes. Before choosing it, confirm with your Qualified Security Assessor whether your organization qualifies, and expect a documented targeted risk analysis, the objective being met, the controls in place, and evidence that those controls stay effective over time. Document the vault's key management and encryption design in the same detail whichever path you take.

Whichever route you choose, record the decision per requirement in your assessment documentation. Under the defined approach, the evidence is the configuration of the card vault, the encryption service, the retention jobs and the TLS settings, plus the three-monthly verification of deleted data. Under the customized approach, add the risk analysis and the test results proving the alternative design works. Confirm with your assessor and, where relevant, your acquirer or payment brand, which approach they will accept before the vault design is frozen, since changing route after build usually means rework in key management and evidence collection.

How DeployOpen scopes, delivers and supports PCI-ready Hyperswitch vaults

DeployOpen is a Chainscore Labs company that plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For Hyperswitch, we start with a written scope that separates what runs in the card vault from what only sees tokens, then build, test and document the environment so your team and your assessor can check the evidence for PCI DSS Requirements 3 and 4.

How we scope

Map every location where account data could be stored, including logs, backups, queues, caches and reporting exports
Confirm which vault model applies: in-house Hyperswitch Vault, external PCI vault provider, or SaaS vault
Agree in writing who owns PCI DSS responsibility for each component, since the in-house model places full responsibility on the merchant
Define retention periods and the quarterly deletion check for stored account data, in a fixed-scope agreement

How we build

Deploy Hyperswitch with Helm charts on your Kubernetes platform, isolating the card vault and encryption service from the rest of the stack
Configure PAN rendering with the methods your design chooses, and document how keyed hashes or tokens are managed
Set up TLS for all PAN in transit, with a maintained inventory of trusted keys and certificates
Test that no sensitive authentication data is written to databases, logs or observability tooling after authorization

How we hand over

Deliver architecture diagrams, data flow diagrams and a current inventory of stored account data locations
Provide configuration records, key management procedures and the evidence needed for your QSA or internal assessment
Document the SSO limits of the Control Center (OpenID Connect only, roles managed in Hyperswitch) and the access process around them
Run a handover session so operators can rotate keys, run the retention check and apply upgrades

How we support

Offer ongoing support, upgrades and continuous testing as a retainer, scoped separately from the initial build
Retest the vault and data flows after each Hyperswitch release or configuration change, before rollout to production
Keep documentation aligned with the version you run, and track PCI DSS version changes that affect your evidence
Coordinate with your PCI assessor and processors, while leaving the assessment itself to the QSA or your internal assessor

Open source payment orchestration and PCI DSS requirement 3