Which Hyperswitch vault deployment model fits your PCI scope
A team self-hosting Hyperswitch has to decide where card data is stored and who carries the PCI DSS obligations for it. The short answer: the native Hyperswitch Vault keeps card data inside your own PCI scope, the external PCI vault model moves storage to a provider such as VGS or Tokenex while your team still orchestrates payments, and the SaaS Hyperswitch Vault model keeps orchestration in your infrastructure but places the vault with Juspay. Choose by how much PCI responsibility you can carry, how much control you need over card data, and how much assessment and operations effort your staff can sustain.
The native model fits teams that already run a mature PCI program, have a Qualified Security Assessor (QSA) relationship, and want card data handled by their own locker service, the Hyperswitch card vault. The Hyperswitch docs state that the merchant is fully responsible for PCI DSS certification and data handling in this model, so the in-scope environment covers the vault, its keys, the database and every system that can reach them. An external vault provider shifts part of that storage burden to a third party, but the provider's own attestation, the responsibility matrix and your integration still need review. The SaaS model reduces the vault you run, but it changes who holds the data and what your assessor must examine. Ask your QSA or acquirer which model they will accept, how each one is scoped, and what evidence they expect, because the PCI DSS Attestation of Compliance (AOC) for your environment is what counts. Review the Hyperswitch docs on self-hosted and in-house PCI before you commit.
Side-by-side: PCI responsibility, control and effort by vault model
This table compares the three documented ways to store cards with self-hosted Hyperswitch across storage location, PCI DSS responsibility, key and vault control, operating effort and assessment evidence. Only the in-house model has a documented responsibility statement, so the other splits are marked for confirmation with each vendor and your assessor before you commit.
| Row | Native Hyperswitch Vault (in-house PCI) | External PCI vault provider (for example VGS or Tokenex) | SaaS Hyperswitch Vault |
|---|---|---|---|
| Where card data is stored | Inside your own PCI scope, in the Hyperswitch card vault (locker) that you host | With the external vault provider, while Hyperswitch orchestrates payments in your infrastructure | With the SaaS Hyperswitch Vault, while Hyperswitch orchestrates payments in your infrastructure |
| PCI DSS responsibility | Documented: the merchant is fully responsible for PCI DSS certification and data handling | Confirm with the vault provider and your assessor which requirements the provider covers and which remain yours | Confirm with Juspay and your assessor how responsibility is split between you and the hosted vault |
| Control over vault and keys | Highest: you operate the vault service and control its key management | Shared: the provider controls its vault, so confirm who holds and rotates encryption keys | Confirm whether you can control key management, and what access you keep to stored data |
| Effort to operate | Highest: you run, patch, back up and secure the vault alongside the payments stack | Lower vault operations, but integration, access reviews and provider oversight remain yours | Lower vault operations, but integration and dependency on the hosted service remain yours |
| Evidence the merchant must produce | Your own PCI DSS assessment covering the vault, using the official ROC or SAQ with an AOC | Provider's current attestation plus your own assessment of the integration and data flows | Vendor attestation as documented by Juspay plus your own assessment of the integration |
| Questions to ask before choosing | Who on your team owns the vault, key rotation and the scope of your assessment? | Which requirements does the provider's attestation cover, and how do tokens flow through your systems? | Where is the hosted vault located, who can access stored card data, and what evidence can Juspay supply? |
What each vault model keeps inside your PCI scope
Each Hyperswitch vault model decides where cardholder data is stored and who answers for it. The cards below trace, for each model, which components touch the card number, where the PCI DSS boundary falls, and what remains your responsibility regardless of the model you pick.
Native Hyperswitch Vault (in-house PCI)
In this model the card vault runs as a separate Rust service from the juspay/hyperswitch-card-vault repository, and your self-hosted deployment stores the card numbers there. The Router, the PostgreSQL and Redis stores, and the vault service all sit inside your cardholder data environment, so the PCI DSS boundary covers your whole Hyperswitch footprint. The Hyperswitch docs state that the merchant is fully responsible for PCI DSS certification and data handling. Check which network segments, backups and logs can reach the vault before you assume the scope is small.
External PCI vault provider
Here Hyperswitch still orchestrates payments on your infrastructure, but card numbers go to an external PCI vault provider such as VGS or Tokenex, and your stack holds tokens. The external provider takes on the cardholder data storage, so the boundary shifts toward that provider's service and the connection between it and your Router. Your Router, PostgreSQL and Redis still process transactions and must be scoped for the flows you keep. Ask the provider for its current attestation and the responsibility matrix for your integration.
SaaS Hyperswitch Vault with self-hosted orchestration
This model keeps your Router, PostgreSQL and Redis on your own infrastructure while card storage moves to the SaaS Hyperswitch Vault. Your in-house cardholder data footprint shrinks to the systems that handle tokens and transaction flows, but those flows still touch your stack. Confirm with Juspay which PCI DSS responsibilities the hosted vault covers, how the boundary between the two environments is documented, and what evidence it can provide for your assessor. Do not treat the hosted vault as removing your own scope by default.
Built for PCI is not compliant
The architecture docs describe the native card vault as built for PCI DSS requirements, but that description refers to design intent, not a finished assessment. Your compliance depends on how you deploy, configure, network, patch and operate the vault and every component around it. PCI DSS does not certify software; an entity's validation comes from a Report on Compliance by a Qualified Security Assessor or a Self-Assessment Questionnaire with an Attestation of Compliance. Plan for that evidence before you go live.
What stays with you in every model
Whichever vault you choose, you still own the systems that handle cardholder data around the vault: hosting, access control, logging, key handling for your deployment, incident response and the assessment itself. Your Router, Scheduler, PostgreSQL and Redis can all process or expose card-related data in transit, so their configuration counts toward your scope. Map each data flow, including retries and webhooks, before choosing a model, and record which party controls each step.
How PCI DSS responsibility shifts between the three models
PCI DSS applies to any entity that stores, processes or transmits cardholder data or sensitive authentication data, and to any entity that could affect the security of the cardholder data environment. A merchant running self-hosted Hyperswitch is therefore in scope under all three vault models. The Router, Scheduler, PostgreSQL, Redis and Control Center still handle payment flows and sit beside whichever vault you choose. In the self-hosted, in-house model, the Hyperswitch documentation states that the merchant is fully responsible for PCI DSS certification and data handling. Before you pick a model, map every component in your deployment, including the Kubernetes cluster and its logging, to the systems that could touch card data.
Outsourcing the vault narrows the environment you must assess, but it does not remove your obligations for the rest of the stack. With an external PCI vault provider, such as VGS or Tokenex as named in the Hyperswitch documentation, card numbers move to the provider's vault and your assessment focus shifts toward the tokenization path, the integration and the systems that handle tokens. The SaaS Hyperswitch Vault changes which party stores the data, so the split of duties differs again. Ask each provider for a written responsibility matrix that assigns every relevant requirement to you, to the provider, or to a shared control, with evidence for the provider's share. Then confirm with your QSA or acquirer how the matrix affects your scope.
Plan your evidence against the version that is active today. PCI DSS v4.0.1 is the only active version, because v4.0 was retired on 31 December 2024 and v3.2.1 was retired on 31 March 2024. A validation uses a Report on Compliance completed by a Qualified Security Assessor, or a Self-Assessment Questionnaire, and each route ends in an Attestation of Compliance. Certificates are not accepted as validation, so do not ask a vault provider for one as proof of your compliance. The PCI SSC does not enforce compliance itself, and your payment brands or acquirer determine which validation applies to you. Request the official PCI DSS standard page context from your acquirer and confirm the required template in writing.
Which vault model suits which team profile
A team with an in-house PCI program and an assessor already holds the responsibility the self-hosted, in-house PCI model assigns. The Hyperswitch docs state that the merchant is fully responsible for PCI DSS certification and data handling in that model, so the program that already owns cardholder data scope is the natural owner of the native vault. This model gives the most direct control over vault configuration, key handling and access paths, and it places every control that touches card data inside your assessed environment.
- Control: You decide vault configuration, key custody and access policy, and you explain each choice to your assessor.
- Staffing load: Operating the vault, patching the stack and keeping evidence current stay with your team on an ongoing basis.
- Evidence: Expect a Report on Compliance from a Qualified Security Assessor or a Self-Assessment Questionnaire with an Attestation of Compliance, depending on your validation type. Certificates are not accepted as validation.
- Approach choice: PCI DSS v4.x allows the customized approach for entities with mature security and risk management, so your assessor can judge whether it fits your program.
Confirm with Juspay which vault components and configuration guidance apply to your deployment, and agree the scope boundary with your assessor before you build.
A team without a dedicated PCI function can still run Hyperswitch, but the external PCI vault and SaaS vault models move card storage to a provider that carries its own PCI DSS responsibility. That shifts part of the storage-side work outward. It does not remove your obligations. Your team still runs the self-hosted orchestration layer, the PostgreSQL and Redis tiers and the access reviews that touch the rest of the payment flow, so the staffing reduction applies to the vault function only.
- Control: You have less direct control over where card data is stored and how it is protected, which is the cost of taking on less storage-side work.
- Staffing load: Your team keeps operating the orchestration services, so plan for ongoing ownership of the parts you still host.
- Evidence: Collect each provider's current PCI DSS attestation and a written responsibility split, then document the scope you still own.
- Condition: The external provider model fits when you can manage a third-party contract and its evidence but cannot yet staff a PCI function. The SaaS vault fits when one hosted vault contract and hosted storage are acceptable to your risk owners.
Ask Juspay and any provider to put the responsibility split in writing, and ask your assessor which evidence they will accept for each party.
A team that must keep card data inside its own network for contractual or regulatory reasons needs to check residency before choosing a model. The native in-house model keeps the Hyperswitch card vault inside infrastructure you operate, which matches that requirement directly. The external PCI vault and SaaS vault models place card storage with a third party, so those models only fit if the contract and the regulator allow it and the storage location meets your rules.
- Residency: The native model keeps the card vault in your own infrastructure, so residency follows your hosting choices.
- Contract terms: Check whether your customer or payment agreements restrict storage with third parties or limit the regions where data may sit.
- Provider location: For the external and SaaS models, confirm in writing where cardholder data is stored, processed and backed up.
- Evidence: Map data flows, network segmentation and key custody so auditors and the contracting party can trace every copy of card data.
Before signing with any vendor, confirm the exact data locations, backup locations and sub-processors with Juspay or the provider, and confirm the boundary with your assessor.
Operating each vault model: upgrades, key handling and skills
This table compares the day-to-day tasks your team carries under each vault model, from upgrades and key handling to access, logging, incident response and skills. Where the Hyperswitch docs document a split, the cell says so. Where they do not, the cell names what to request in writing before you commit.
| Operating task | Self-hosted native vault (in-house PCI) | External PCI vault provider | SaaS Hyperswitch Vault |
|---|---|---|---|
| Upgrades to Router, Scheduler and card vault | You upgrade the Router, Scheduler and the separate card vault service, and test each release in your own environment. | You upgrade the Router and Scheduler. The provider controls its vault release cadence, so ask for change notice and test windows in writing. | You upgrade the Router and Scheduler. Confirm in writing who applies vault updates, and how much notice you receive. |
| Encryption service and key management | You own key generation, storage and rotation for the encryption service that protects stored card data. | Confirm in writing which keys, if any, you still hold for the encryption service, and who rotates the vault keys. | Confirm in writing where the vault encryption keys are held, who rotates them, and how you would evidence rotation. |
| Access control to the Control Center and hosts | You manage who reaches the vault hosts and the Control Center. Users must be invited, and roles are managed in Hyperswitch. | You manage access to the Router and Control Center. Ask the provider how its operator access to your card data is restricted and reviewed. | You manage Control Center access. Ask Juspay how its staff access to the hosted vault is controlled, logged and reviewed. |
| Logging and monitoring | You collect and retain logs from the Router, Scheduler and card vault, and feed them to your monitoring or SIEM. | You collect Router and Scheduler logs. Ask the provider for vault audit logs, their retention period and export format. | Ask for vault access logs, retention and export options in writing, so your SIEM can receive them. |
| PostgreSQL (master and replica) and Redis | You run, back up and fail over PostgreSQL and Redis, which also hold the scheduler queue and cache. | You still run PostgreSQL and Redis for the Router and Scheduler. Confirm in writing that no card data lands in these stores. | You still run PostgreSQL and Redis for the Router and Scheduler. Confirm in writing that no card data lands in these stores. |
| Incident response | You lead detection, containment and any notification for the vault, since the card data sits in your scope. | Split the response with the provider. Request its incident contacts and notification timing in a written runbook. | Request a joint incident runbook in writing that names who detects, contains and notifies, and within what timeframe. |
| PCI DSS evidence under v4.0.1 | The Hyperswitch docs state you are fully responsible for PCI DSS certification and data handling in this model. | Ask for the provider's attestation scope and a written responsibility matrix covering the vault component. | Ask whether an attestation covers the hosted vault, and for a written responsibility matrix before you sign. |
| Skills needed in-house | Kubernetes and Helm, PostgreSQL high availability, Redis, key management and PCI DSS evidence work. | Integration engineering, vendor oversight, and PCI scope analysis. Fewer infrastructure skills are needed for the vault itself. | Integration engineering and access governance. Fewer infrastructure skills are needed, but vendor oversight becomes central. |
What buyers ask before choosing a Hyperswitch vault model
Does an external PCI vault take my business out of PCI DSS scope?
Not by itself. Moving card storage to an external PCI vault provider, such as VGS or Tokenex, can reduce the systems that store, process or transmit cardholder data in your environment, but whether your scope shrinks, and by how much, depends on how your traffic and systems touch card data. PCI DSS applies to any entity that could affect the security of the cardholder data environment, so your orchestration layer may still be in scope. Ask your Qualified Security Assessor to document the scope boundary for your exact architecture, and confirm the vault provider's own attestation and responsibility matrix before you rely on it.
How much extra PCI work does the native Hyperswitch vault add?
The in-house model places the most PCI work on your team. The Hyperswitch docs state that the merchant is fully responsible for PCI DSS certification and data handling in this model. Effort rises with the number of environments that connect to the vault, the key management and access controls you must evidence, and the depth of the assessment your acquirer or brand requires. Assessment type is set by your payment brands and acquirer, not by PCI SSC, so confirm with them which Report on Compliance or Self-Assessment Questionnaire applies before you size the work.
Can I switch from one vault model to another later?
Usually yes, but the switch is a migration project, not a configuration change. Moving stored card data or tokens between vaults involves re-tokenization, connector updates, reconciliation of stored payment methods and a new scope review. Ask your engineering lead to test the token migration path in a staging environment, and confirm with the vault provider whether bulk export of tokens is supported and under what contract terms. Plan change control and a rollback window before you commit to a model.
What does my internal team need to run a self-hosted vault?
Your team needs skills across several areas:
- Kubernetes and Helm operations for the Router, Scheduler, PostgreSQL and Redis components
- Key management and encryption service administration
- Access control, logging and change control that an assessor can review
- Someone who can read PCI DSS requirements and map them to your systems
The external vault models shift some of the card-handling burden to the provider, but your team still owns orchestration, integrations and evidence. Confirm your internal skill gaps before you decide how much outside help to buy.
How long does a vault model change take to implement?
No duration is published for this work, so treat any timeline as something to get in writing. The schedule depends on the number of integrated environments, the connectors you need to re-point, the assessment cycle your acquirer runs, and how quickly your change control approves production changes. DeployOpen plans most engagements as fixed scope, with scope, deliverables and timelines agreed in writing before work starts. Ask for a written plan that lists each environment, dependency and approval step.
What drives the cost of each vault model?
Cost has four main drivers: the scope of your PCI assessment, the number of environments and connectors that handle card data, the skills your staff already have, and the change control your organization requires. In the in-house model, you pay for the hosting, the assessment and the internal effort to evidence controls. In the external vault model, you also pay the vault provider's fees, which recur. Ask every quote to separate one-time implementation, recurring hosting and vault fees, and assessor costs. DeployOpen does not publish prices, and a quote follows from the written scope.
Who is responsible for PCI DSS evidence in each model?
The merchant remains responsible for its own PCI DSS validation in every model, and the vendor or provider responsibility is set by contract. Under the in-house model, you produce all evidence yourself. With an external vault or the SaaS Hyperswitch Vault, you should request the provider's Attestation of Compliance and a responsibility matrix that shows which requirements they cover. Independent assessors issue reports and attestations, and DeployOpen prepares systems, controls and evidence for those assessments but does not issue them. Confirm each division of responsibility with your assessor before go-live.
How to choose and document your vault model
This sequence turns the three self-hosted vault options into a documented decision that your acquirer, QSA and internal assessors can review. It ends with a record of scope, responsibilities, test evidence and sign-off that supports the choice.
Map card data flows and entities
Document every point where card data enters, is stored, is processed or is transmitted, including the Hyperswitch components, connectors, logs, backups and support access. Confirm the entity types with your acquirer and your Qualified Security Assessor, since the payment brands decide which entities must validate. Name the payments lead as owner of the data flow diagram. The step is done when the diagram and entity list are signed off by both the acquirer and the QSA.
Shortlist vault options against the scope
Compare the native in-house vault, an external PCI vault provider such as VGS or Tokenex, and the SaaS Hyperswitch Vault against the flow map from the previous step. For each option, note whether card data would sit inside your cardholder data environment, which party operates the vault, and who runs the key and access controls. The security architect owns this comparison. The step is done when each option has a one-page note that states its scope impact.
Map each option to PCI DSS v4.0.1 requirements
For the shortlisted model, list which of the 12 principal PCI DSS requirements apply and which controls the vault provider covers under its own assessment. Use the defined approach by default, and consider the customized approach only if your organization has the risk management maturity it requires. Your QSA should confirm any customized approach before you rely on it. The compliance lead owns the matrix. The step is done when every requirement has an owner, a control reference and an evidence source.
Request responsibility matrices and documentation in writing
Ask each vault provider, and Juspay for the SaaS option, for a written responsibility matrix, current attestation documents and the configuration documentation for your chosen deployment model. Ask what their attestation covers, what evidence they will supply for each shared requirement, and how changes are notified. Ask which quote items are one-time and which recur. The procurement lead owns the request. The step is done when the written responses are filed and reconciled against your matrix, with gaps logged.
Test the chosen model in non-production
Deploy the chosen model in a non-production environment using the documented Docker or Kubernetes setups, then run card tokenization, retrieval, deletion and failure-path tests with non-production data. Confirm that logs, error messages and backups do not expose card data, and that access to the vault is restricted as the matrix states. The platform engineering lead owns the test plan. The step is done when test results, configuration snapshots and any defects with fixes are recorded.
Record the decision and its evidence
Write a decision record that names the chosen vault model, the scope boundary, the responsibility matrix, the provider documents and the test results. Include any customized approach and the QSA's position on it. Store the record with the assessment evidence so the Report on Compliance or Self-Assessment Questionnaire can cite it. The compliance lead owns the record, and the QSA reviews it before the assessment begins. The step is done when the record is approved, versioned and linked from the assessment file.
How DeployOpen scopes and delivers a Hyperswitch vault deployment
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, so the vault choice is worked through against your cloud account, network and cardholder data flows. Engagements are fixed-scope, with scope and deliverables agreed in writing before any work starts.
How we scope
- Map every path where card data enters, is stored, or leaves your environment before choosing a vault model.
- Confirm which entities and systems would fall inside your PCI DSS scope under each of the three models.
- Agree in writing which vault model, connectors, environments and deliverables the engagement covers, with timelines set in the scope.
How we build
- Deploy Hyperswitch with its documented Helm charts on your Kubernetes platform, including the card vault service and its database.
- Configure the chosen vault integration, tokenization flow and key management to match the selected deployment model.
- Test tokenization, detokenization, access restrictions and failure behaviour in a non-production environment before go-live.
How we hand over
- Document the architecture, data flow diagram, network boundaries and the responsibilities split between your team and each vendor.
- Provide control evidence and configuration records that your QSA or internal assessor can review for the PCI DSS assessment.
- Walk your operations and security teams through backup, upgrade and incident procedures so they can run the stack after handover.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer, scoped separately from the initial build.
- Re-check scope and controls when you add connectors, change vault providers or move to a different Hyperswitch release.
- Coordinate with your assessor and your vault provider on evidence requests, but leave the attestation itself to the assessor.
