Hyperswitch card vault and PCI DSS requirement 3

What a self-hosted Hyperswitch card vault covers under PCI DSS requirement 3

A team that stores card data in a self-hosted Hyperswitch vault must answer for PCI DSS requirement 3, and the platform helps with 3.5.1, 3.5, 3.6.1, 3.6.1.2 and, for service providers only, 3.6.1.1. It does not satisfy requirement 3 on its own, and it does not cover the other eleven principal requirements, such as network security, access control and logging across the cardholder data environment. DeployOpen plans, deploys and documents the vault and its key handling inside your infrastructure, and prepares the systems, controls and evidence an assessor will review. DeployOpen does not issue Reports on Compliance, Attestations of Compliance or certifications; a Qualified Security Assessor or your payment brand's validation process does that. PCI DSS v4.0.1 is the only active version, so every mapping in this section uses it.

Requirement 3.5.1 accepts four ways to render stored PAN unreadable: one-way hashes of the entire PAN based on strong cryptography, truncation, index tokens, or strong cryptography combined with key-management processes. Confirm which of these the Hyperswitch vault relies on in your configuration, and document that choice before you design anything around it. Requirement 3.5 extends the same expectation to non-primary stores such as backups, audit logs and troubleshooting logs. In a self-hosted stack, that means the Router and Scheduler logs, PostgreSQL backups, Redis contents and any exports must be checked for PAN before you treat them as out of scope. If you intend to hash PAN, read PCI SSC FAQ 1089 on hashing and scope and FAQ 1308 on correlating hashed and truncated values, since both affect whether those values stay in scope.

Requirement 3.6.1 asks you to restrict key access to the fewest custodians, keep key-encrypting keys at least as strong as the data-encrypting keys they protect, store them separately, and keep keys in the fewest possible locations and forms. Requirement 3.6.1.2 requires secret and private keys to be held at all times either encrypted under a separate key-encrypting key, inside a secure cryptographic device such as an HSM, or as at least two full-length key components or shares. The Hyperswitch identity and access docs describe distributed key management, in which key custodians must collaborate to start the application, so no single person can alter or access the vault alone. Name your custodians, record how many must cooperate to start the service, and decide where the encryption service keys are held. Requirement 3.6.1.1 applies only if you are a service provider and requires a documented cryptographic architecture with an inventory of HSMs and other secure cryptographic devices.

Start by choosing one of the three documented vault models: the self-hosted in-house PCI vault, self-hosted orchestration with an external PCI vault provider such as VGS or Tokenex, or self-hosted orchestration with the SaaS Hyperswitch Vault. The Hyperswitch docs state that under the in-house model the merchant is fully responsible for PCI DSS certification and data handling, so this choice largely sets the size of your evidence file. Expect an assessor to ask for a data flow diagram, the inventory of every store that could hold PAN, key custodian appointment records, key ceremony logs, key rotation records, and HSM or key-component handling records. Confirm with your assessor whether a customized approach, which meets a stated objective in a different way, is acceptable for any requirement, and get a written scope that lists each artifact and who produces it.

Mapping PCI DSS requirement 3 to Hyperswitch capabilities and configuration

This table maps the five Requirement 3 controls most relevant to a self-hosted card vault to the Hyperswitch components that touch stored card data, and to the settings you must set or confirm. Read each row as a question to answer before assessment: where PAN lives, who holds keys, and where those keys are stored. Where the supplied documentation does not confirm a capability, the table says so and names who to ask. The main takeaway is that the vault is only one part of Requirement 3, and logs, caches, backups and key custodianship remain your responsibility.

Requirement	Platform capability	Configuration to set or confirm
3.5.1: Render stored PAN unreadable	The card vault is a separate service documented as built for PCI DSS requirements. Confirm the specific PAN rendering method with Hyperswitch documentation or the vendor.	Confirm which accepted method the vault applies, and that PAN is never written in plaintext to PostgreSQL or Redis.
3.5: Non-primary storage (backups, logs, caches)	Router and Scheduler use PostgreSQL and Redis, which can hold payment data outside the vault. Confirm what each component persists.	Confirm PAN is absent from application logs, backups, Redis queues and any Control Center exports. Test with sample cards before go-live.
3.6.1: Key protection procedures	The Hyperswitch Vault uses distributed key management, so key custodians must collaborate to start the application. Confirm the custodian split with the vendor.	Name custodians, restrict key access to the fewest people, keep key-encrypting keys at least as strong as the keys they protect, and store them separately.
3.6.1.2: Secret and private key storage	The encryption service handles key management. Confirm whether keys are held encrypted under a separate key, in an HSM, or as split components.	Document which of the three permitted forms each key uses at all times, and confirm HSM support with the vendor before selecting hardware.
3.6.1.1: Documented cryptographic architecture (service providers only)	Not a product feature. The document is written by the operator and applies only if you act as a service provider.	Confirm applicability with your acquirer or assessor. If it applies, list algorithms, keys, expiry, key usage and an HSM inventory.

How the self-hosted Hyperswitch vault renders stored PAN unreadable

Requirement 3.5.1 of PCI DSS v4.x lists four accepted ways to render stored primary account number (PAN) unreadable: one-way hashes of the entire PAN based on strong cryptography, truncation, index tokens, and strong cryptography with key-management processes. A hash, a truncated value or an index token cannot be reversed to the card number by someone who holds only the stored data. A reversible encrypted vault can be read by anyone who can decrypt it, so it falls under the last option, where the encryption matters as much as the key-management processes around it. The SAQ D notes to 3.5.1 also extend the requirement to non-primary storage such as backups, audit logs and troubleshooting logs, so a method chosen for the main database does not settle the question on its own.

The Hyperswitch card vault, also called the locker, is a separate Rust service in the juspay/hyperswitch-card-vault repository, apart from the core app server that handles routing and retries. The Hyperswitch architecture docs describe it as built for PCI DSS requirements. That description does not tell you which method 3.5.1 the vault applies, or whether the vault is the only place PAN lands in your deployment. Confirm both with the vendor in writing, then check the code and your configuration. Ask how PAN is encrypted, which component holds the data-encrypting and key-encrypting keys, and whether any hashed or truncated value is written alongside the encrypted record. Each answer changes which of the four methods your evidence must support.

Tokens need the same scrutiny as stored PAN. A token returned to your payment flow is only useful if it cannot be turned back into a card number outside the vault. Find out whether tokens are random references issued by the vault or values derived from the PAN. A deterministic derivation, such as a hash of the card number, may behave as an index token or a hashed PAN, and either can keep the systems that hold it in scope. PCI SSC FAQ 1089 addresses hashing PAN and its effect on scope, and FAQ 1308 covers correlating hashed and truncated PANs across datasets. Use these as starting points for discussion with your assessor, who decides how your design is scoped.

Start with an inventory of every location where PAN or a value derived from it can appear. Include the vault database and its replicas, the PostgreSQL and Redis tiers used by the core services, backups, application and troubleshooting logs, message queues, Control Center exports and any analytics copies. For each location, record whether the value is encrypted, hashed, truncated, tokenized or absent, and which roles can read it. Your assessor will expect this inventory to support the 3.5.1 method you claim. Gaps found at this stage are cheaper to fix before you configure logging and backups than after an assessment has started.

Which Hyperswitch vault model moves requirement 3 work onto your team

With the native Hyperswitch Vault, your organization runs the card vault inside its own infrastructure, so the requirement 3 work sits with your team from start to finish. The Hyperswitch docs state that the merchant is fully responsible for PCI DSS certification and data handling in this in-house model. Expect your team to own:

Rendering stored PAN unreadable under requirement 3.5.1 in every store that holds it, including the backups, audit logs and troubleshooting logs that the SAQ D notes bring into 3.5.
Key custodian roles. The Hyperswitch IAM docs say key custodians must collaborate to start the vault, so you need a recorded list of who holds each custodian share and how that list changes.
Key storage that meets requirement 3.6.1.2, whether keys are encrypted under a separate key-encrypting key, held in a secure cryptographic device, or split into at least two full-length components.
The cryptographic architecture documentation and HSM inventory that requirement 3.6.1.1 asks for if you are a service provider.
Evidence that stays current through upgrades, key rotations and custodian changes.

Confirm with your Qualified Security Assessor which items your validation type requires and where the vault sits within your scope.

How key custodians and key storage meet requirements 3.6.1 and 3.6.1.2

The Hyperswitch IAM docs describe the Hyperswitch Vault as using distributed key management, in which key custodians must collaborate to start the application, so no single person can alter or access the vault alone. That design addresses the core of requirement 3.6.1, which restricts key access to the fewest custodians and requires key-encrypting keys to be at least as strong as the data-encrypting keys they protect. It is a starting point, though. Your assessor will expect to see the design written into your own procedures, with named people, documented ceremonies and a record of where each piece of key material physically sits. Treat the Hyperswitch description as a vendor statement to confirm, and build your evidence from your own environment.

Map requirement 3.6.1 to three questions. First, fewest custodians: how many people hold a key component or can start the vault, and is that number the minimum your operations actually need? Second, separate storage: are key-encrypting keys stored apart from the data-encrypting keys and from the encrypted card data they protect, including in backups and disaster recovery copies? Third, fewest locations and forms: how many copies of each key exist, and in how many places? Ask Hyperswitch whether the startup threshold is configurable, how many custodians the documented procedure requires, and what happens when a custodian is unavailable. Record the answers in your key management procedure, because a configurable threshold that nobody has set is still a control you must explain.

Requirement 3.6.1.2 requires secret and private keys to be stored at all times in one of three forms: encrypted under a separate key-encrypting key, inside a secure cryptographic device such as a hardware security module, or as at least two full-length key components or shares. The phrase at all times matters. Keys in backups, staging copies and recovery media are covered too, which links this requirement to the non-primary storage expectations under requirement 3.5. Confirm with Hyperswitch which form its card vault and encryption service use, and whether the encryption service's own key hierarchy follows the same form. If you use split components, each share should sit with a different custodian in a different location, and no custodian or small group should hold enough shares to rebuild the key. Requirement 3.6.1.1 applies only to service providers, so confirm whether it applies to your entity before you build a device inventory.

Document three things before the first live ceremony. The key custodian roster should list each custodian by role, with appointment, an acknowledgement of responsibilities, a named backup for each role and a removal step for when someone leaves or changes role. The ceremony steps should cover who must be present, how the environment is prepared and checked, how components are generated or entered, who witnesses the process, what gets logged, and how the application is confirmed running afterward. The key material location register should show every place a key or component lives, including its form, custodian, location and the date it was last verified. DeployOpen can help prepare these records as part of a readiness engagement, but your staff must own the custodian role and run the ceremony.

Plan for the operational risks that come with a startup ceremony. Vault restarts after a failure, host replacement, a version upgrade or a restore from backup may each require custodians to be available, so the availability design has to account for them. Confirm with Hyperswitch whether routine upgrades or pod rescheduling trigger the ceremony again, and whether a rekey or component regeneration is needed when a custodian leaves. Run a full dry run in a non-production environment with the actual custodians, time it against your real recovery objectives, and keep the outcome as evidence. Lost components are a second risk: if a share is lost and the remaining shares cannot rebuild the key, the data may become unrecoverable, so confirm the recovery path before go-live.

What evidence an assessor will ask for from a self-hosted Hyperswitch vault

An assessor will ask for six groups of records that together show how stored PAN is rendered unreadable and how the keys behind it are controlled. Each record must match the running environment and be refreshed after each Hyperswitch release. The assessor, not DeployOpen or Hyperswitch, decides whether any item is sufficient evidence for requirement 3.

Scope definition and data flow diagram

A written scope statement and data flow diagram showing every system that stores, processes or transmits PAN, including the vault service, Router, Scheduler, PostgreSQL, Redis, log pipelines and backups. Requirement 3.5 also reaches backups, audit logs and troubleshooting logs, so the diagram must show where they hold card data. Compliance and platform teams produce it from the deployed Helm values and network policies. Revisit it at each upgrade, because new dependencies such as the Superposition service required from v1.124.0 can change the flows. Check that the diagram matches the live cluster.

Vault configuration and deployment manifests

The Helm chart values, rendered Kubernetes manifests and pinned image versions used to deploy the card vault in production. The assessor compares them with the scope diagram and with the method chosen for rendering PAN unreadable under requirement 3.5.1. Keep them in version control with change approval, and re-render them for each monthly Hyperswitch release, recording the compatibility matrix for Control Center and client versions. Export the actual cluster state at assessment time, so the evidence shows what is running rather than what was planned.

Key custodian records and ceremony logs

Records naming each key custodian, the key component or share they hold, their authorization and training, and logs of every key ceremony. Each log should show who attended, what was generated or loaded, and where components were stored. Hyperswitch's docs describe distributed key management in which custodians must collaborate to start the vault, so the logs should show that no single person could start it alone. Requirement 3.6.1 asks for access to be limited to the fewest custodians, so keep the list short and current. Record a ceremony whenever a release changes key handling.

Key lifecycle and rotation records

Records of how each data-encrypting key and key-encrypting key was generated, stored, rotated, retired and destroyed, with dates, reasons and the custodians involved. Requirement 3.6.1.2 requires secret and private keys to be stored at all times as encrypted under a separate key-encrypting key, inside a secure cryptographic device, or as at least two full-length components. The record should show the storage form at each stage. Ask the vendor how the vault rotates keys and re-encrypts stored PAN, then test that procedure before the assessment, since an untested rotation is hard to evidence.

Access records for custodians and administrators

Logs and periodic reviews showing who can reach the vault, its key components, the Kubernetes namespace, the database and the Control Center. Hyperswitch Control Center SSO supports OpenID Connect only, with no JIT or SCIM provisioning, and roles are managed inside Hyperswitch. User lists and role assignments must therefore be reconciled with the identity provider by hand. Keep the review cadence and removal evidence for leavers. Sources include identity provider logs, Kubernetes audit logs, PostgreSQL audit settings and Hyperswitch user records.

Cryptographic architecture inventory

A documented inventory of algorithms, protocols, keys with their strength and expiry, key usage, and each HSM or other secure cryptographic device. Requirement 3.6.1.1 applies only to service providers, so confirm your entity's status with your payment brands or acquirer before building it. Other entities still need the same details to evidence requirements 3.5.1 and 3.6.1, so keeping the inventory current costs little. Review it at each monthly Hyperswitch release, since algorithm and protocol settings can change between versions.

Where card data can leak into backups, logs and troubleshooting copies

Requirement 3.5 does not end at the primary store. According to the SAQ D notes to requirement 3.5.1, the requirement also reaches non-primary storage, including backups, audit logs and troubleshooting logs. In a self-hosted Hyperswitch deployment, the card vault is only one place where stored PAN can sit, so the operator needs a complete inventory of data locations before an assessor asks for one. Build that inventory during design or before a PCI DSS assessment begins, and name an owner for every location in it. An inventory that covers only the vault will miss the places that nobody reviews regularly.

Start the inventory with the Hyperswitch components that hold data. The Router and Scheduler services (Producer and Consumer) process payment requests and scheduled work. PostgreSQL runs with a master and a replica, and Redis serves caching and the scheduler queue. The card vault, or locker, is a separate Rust service in its own repository. For each component, record whether it could hold PAN or a PAN-derived value, such as a hash, a truncated value or an index token, in memory, on disk, in a queue, in a log line or in a replica copy. The answer depends on your connectors, your integration and your payment flows, so confirm it in your build. Run a test transaction with test card data in a non-production environment, then trace where the value appears. PCI SSC FAQ 1089 and FAQ 1308 are useful references when a hashed or truncated value is in scope.

Logging and debug settings need the same scrutiny. Confirm the log levels in each service, whether request and response bodies are written to logs, whether debug or trace output is enabled in any environment that handles live data, and where log streams are shipped and how long they are kept. Do not assume that a vendor default or a configuration copied from a development environment is safe to run in production. Ask the team that operates the deployment for the actual configuration files or Helm values, and compare them with your inventory. Also check the diagnostic paths people use during incidents, such as support bundles, exported request traces and dashboard screenshots, because these copies often leave controlled systems faster than the logs do.

Backups need an explicit decision on encryption, access and retention. Cover database dumps from the primary and the replica, any Redis persistence files, log archives and configuration snapshots. For each, decide how it is encrypted, which keys protect it and where those keys are held, who can restore it, and how long it is kept before secure deletion. Set the retention period from your own written policy and reference that policy in your evidence. Test a restore into an isolated environment and check whether the restored data holds anything the live system no longer keeps, such as a value removed after a fix. Record the results, because the assessor will ask how backups were protected and how restores were controlled, and your answers must match the configuration you can show.

What the platform does not cover for requirement 3

The platform handles vault mechanics, but several requirement 3 obligations stay with your organization. Each card names one gap, what it affects in a self-hosted vault, and who should confirm it before you commit to the in-house model.

Full PCI DSS responsibility stays with you

Hyperswitch documents that in the self-hosted, in-house PCI model the merchant is fully responsible for PCI DSS certification and data handling. That responsibility covers the vault service, its databases, backups and logs wherever stored PAN appears. Confirm with your acquirer and payment brands which validation path applies to your organization, and ask your Qualified Security Assessor whether the vault sits inside your cardholder data environment.

No attestation of compliance from Hyperswitch

Hyperswitch does not issue an attestation of compliance for your deployment. Your validation rests on your own Report on Compliance or Self-Assessment Questionnaire, with its Attestation of Compliance, and assessors will sample evidence from your environment for stored PAN. Ask your assessor which evidence they expect for requirement 3, including vault database encryption settings, backup contents and log redaction, and plan to collect it from your systems.

OIDC-only SSO limits custodian access control

Control Center single sign-on supports OpenID Connect only, with no SAML, no JIT provisioning and no SCIM. Users must be invited first, and roles are managed inside Hyperswitch rather than pulled from your identity provider. For key custodians, joiner, mover and leaver steps therefore run in two systems, so your access reviews must cover both. Confirm with your identity team and your assessor whether this meets your custodian access procedures.

No announced date for the next PCI DSS version

PCI DSS v4.0.1 was published on 11 June 2024 and is the only active version. The PCI SSC ran a request for comments from 3 June to 20 July 2026 to begin the next iteration, and as of October 2026 it had announced no release date for a new version. Design your requirement 3 controls against v4.0.1, and confirm the current status directly with the PCI SSC before each assessment cycle.

HSM, key ceremony and crypto architecture are yours

Requirement 3.6.1 requires secret and private keys to be stored encrypted under a separate key-encrypting key, inside a secure cryptographic device such as an HSM, or as at least two full-length key components. Hyperswitch does not select your HSM, define your key ceremony or write your cryptographic architecture document. Your security architecture team and HSM vendor should make those decisions, and your assessor should confirm whether the service provider documentation requirement in 3.6.1.1 applies to you.

Configuration sequence for a requirement 3 ready vault

This sequence takes a self-hosted Hyperswitch card vault from scoping to an assessment-ready state for PCI DSS requirement 3. Each step ends with a decision or check an assessor can trace, so the architecture, key handling and evidence line up before testing begins.

Define the cardholder data scope
Before build work starts, agree with your assessor which systems store, process or transmit cardholder data, or could affect that environment. Include the Hyperswitch router, Scheduler, PostgreSQL, Redis, Control Center, the card vault, the encryption service and every network path that carries PAN. Your team proposes the boundary and the assessor confirms it. Done when a written scope statement lists each component and data flow.
Choose the vault model
Select one of the three self-hosted vault models Hyperswitch documents: the native Hyperswitch Vault under in-house PCI, an external PCI vault provider such as VGS or Tokenex, or the SaaS Hyperswitch Vault. The in-house model makes the merchant fully responsible for PCI DSS certification and data handling, so this choice sets how much of requirement 3 your team owns directly. Record the decision, its reasons and the responsibilities it moves. Done when the accountable owner approves it and the assessor has reviewed it.
Confirm the PAN rendering method
Decide how stored PAN becomes unreadable under requirement 3.5.1. The accepted options are one-way hashes of the entire PAN based on strong cryptography, truncation, index tokens, or strong cryptography combined with key-management processes. A vault that must recover PAN for processing usually depends on the last option, so confirm the choice with your assessor and review the PCI SSC FAQs on hashing and correlation first. Done when the method is written against each storage location that holds PAN.
Design the key custodian roster
Name the key custodians and limit key access to the fewest people needed under requirement 3.6.1. Hyperswitch's distributed key management requires custodians to collaborate to start the application, so no single person can alter or access the vault alone. For each secret or private key, choose a storage form under requirement 3.6.1.2: encrypted under a separate key-encrypting key, held in a secure cryptographic device such as an HSM, or split into at least two full-length components. Key-encrypting keys must be at least as strong as the keys they protect. Done when the roster and storage forms are approved and the custodian start-up is tested in a non-production environment.
Deploy the vault in a segregated environment
Deploy the Hyperswitch card vault and encryption service with the documented Helm charts on Kubernetes, in a network segment restricted to the cardholder data environment and separated from development and general workloads. Allow only the router to reach the vault, limit administrative access, and keep key material out of images and plain configuration files. Test that traffic from outside approved paths is blocked and that one operator cannot start the vault. Done when the deployment record shows the segment rules and the custodian start-up test results.
Configure logging and backups with PAN exclusion
Requirement 3.5 extends beyond the primary store to backups, audit logs and troubleshooting logs. Configure logging for the router, Scheduler, PostgreSQL and Redis so PAN and sensitive authentication data never reach log sinks or debug output. Confirm that vault and database backups are encrypted and governed by the same key model. Run sample transactions, then search logs, backup restores and debug output for PAN patterns. Done when those searches return no cleartext PAN and the results are saved as evidence.
Document the cryptographic architecture
If service provider rules apply, requirement 3.6.1.1 requires a documented cryptographic architecture. It must list algorithms, protocols, keys, key strength and expiry, key usage, and an inventory of HSMs and other secure cryptographic devices. Merchants that are not service providers still benefit from a similar key inventory, since it answers most of the questions an assessor asks under requirement 3.6.1. Confirm applicability with your assessor and payment brand. Done when the document matches the deployed configuration and the key custodians have signed it.
Plan the evidence pack before assessment
Assemble the evidence the assessor will request before fieldwork begins. It should include the scope statement, the vault model decision, the PAN rendering method, the custodian roster and key storage records, segmentation test results, log and backup search results, and the cryptographic architecture where it applies. Ask the assessor which formats they accept and whether they sample. The assessment itself is recorded on the PCI SSC Report on Compliance or Self-Assessment Questionnaire with an Attestation of Compliance. DeployOpen prepares the evidence but does not issue the attestation. Done when each item has an owner and a stored location.

What does PCI DSS requirement 3 work cost for a self-hosted Hyperswitch vault?

Which factors push PCI DSS requirement 3 effort up or down in a self-hosted vault?

Cost depends on scope size, vault model, key ceremony design, the number of environments and the volume of evidence. No price is set on this page, and a quote follows from the written scope.

Scope size: the number of systems that store, process or transmit primary account numbers, plus systems that could affect that environment.

Vault model: Hyperswitch documents three self-hosted models: the native Hyperswitch Vault used as an in-house PCI solution, an external PCI vault provider such as VGS or Tokenex, and orchestration with the SaaS Hyperswitch Vault. The in-house model carries the most PCI work, because the merchant is fully responsible for certification and data handling.

Key ceremony design: how custodians are named, how key components are split and where keys are held.

Environments and evidence: each additional environment and each additional set of logs, change records and access reviews that an assessor samples adds effort.

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

Duration is set by a small number of drivers, so ask for a plan that shows each one. The main drivers are how many environments hold card data, whether the vault model is in-house or external, how many key ceremonies must be designed and rehearsed, how much existing key management can be reused, and how quickly your team can schedule custodian time and infrastructure access.

Evidence collection usually runs alongside build work, but the assessment window itself adds time at the end. Confirm your assessor's availability before fixing dates, because that calendar often sets the final milestone. Ask the partner to list each milestone with the dependency it waits on, so delays can be traced to a specific input.

What does our team need to provide during a requirement 3 engagement?

Your team provides custodian time, infrastructure access, assessor contact and records. The scope should name each item before work starts.

Custodians: named staff who attend key ceremonies, hold key components and set aside time for training and each ceremony.

Infrastructure access: accounts, clusters, database and secrets stores, logging and backup systems in scope, with change windows agreed in advance.

Assessor contact: the Qualified Security Assessor or the team that will complete the assessment, engaged early so that evidence formats and sampling expectations are agreed before the build.

Records: policies, past change tickets and asset inventories. Name one internal owner who approves design decisions and signs off the scope.

Can our security team complete PCI DSS requirement 3 work without an outside partner?

A capable internal team can do the work if it has skills in applied cryptography, Kubernetes operations and PCI DSS assessment, and if it has time that is not already committed to other projects. The hardest parts are usually the key ceremony design, the evidence pack and the independent review of both.

Many teams build the vault in-house and bring in outside help for the design review or the evidence set. Be clear about who will operate the vault after go-live, because key rotation and custodian changes recur.

DeployOpen plans, implements, hardens and documents self-hosted platforms in your infrastructure, and it prepares systems, controls and evidence for assessment. It does not issue reports or attestations.

Who signs the Attestation of Compliance after a self-hosted vault is built?

The entity being assessed signs its Attestation of Compliance, and DeployOpen does not sign it. The AOC is part of an official PCI SSC template, either a Report on Compliance completed by a Qualified Security Assessor or a Self-Assessment Questionnaire. The merchant or service provider that operates the cardholder data environment owns the result.

Confirm with your assessor which signatures the chosen template requires. Certificates are not recognized as validation. The PCI SSC does not enforce compliance, since the payment brands decide who must validate and run any enforcement programs. DeployOpen's role is to prepare the systems, controls and evidence that the assessor reviews.

Which key custody design choices change the evidence an assessor requests?

Key custody design sets much of the evidence. Requirement 3.6.1 asks for key access limited to the fewest custodians, key-encrypting keys at least as strong as the data-encrypting keys they protect, separate storage for keys, and keys kept in the fewest possible locations and forms.

Requirement 3.6.1.2 requires secret and private keys to be stored at all times in one of three ways: encrypted under a separate key-encrypting key, inside a secure cryptographic device such as an HSM, or as at least two full-length key components or shares.

Each choice changes what the assessor samples, such as ceremony logs, custodian acknowledgments, HSM inventories and key storage records. Hyperswitch's identity documentation describes distributed key management in which custodians must collaborate to start the vault, which helps show that no single person can access it alone.

What should a fixed-scope written quote for this work include?

Ask for a written, fixed-scope quote that names the systems in scope, the vault model, the number of environments and the key ceremony design covered. The quote should also state what is excluded.

Request deliverables as a list: architecture and data-flow documentation, the key management design, custodian roles and procedures, ceremony runbooks, configuration baselines, logging and backup configuration, and an evidence index mapped to requirement IDs 3.5.1, 3.6.1 and 3.6.1.2.

Ask which items are one-time and which recur, such as key rotation support, ongoing testing or evidence refresh. Confirm your responsibilities, the change process for scope additions and the assumptions made about the assessor. Request the timeline as milestones with their dependencies.

How DeployOpen scopes, configures and documents requirement 3 evidence

DeployOpen treats the self-hosted Hyperswitch card vault as a PCI DSS requirement 3 system from the first scoping call, so storage, key and log decisions are documented before the build starts. The work runs inside infrastructure you control, with your team and ours agreeing on who holds each key custodian role and where each control's evidence lives. DeployOpen prepares systems, controls and evidence for assessment, while the assessor or the SAQ process decides the outcome.

How we scope

The written scope names which vault model applies: in-house PCI, external PCI vault or SaaS Hyperswitch Vault.
Scope records every place PAN may land, including primary storage, backups, audit logs and troubleshooting logs.
Engagements are fixed-scope, with deliverables agreed in writing before work starts; ongoing support is available as a retainer.

How we build

Configure the vault to render stored PAN unreadable with a method chosen under requirement 3.5.1, documented per data store.
Define key custodians and distributed key management so no single person can start or alter the vault alone.
Map key storage for each key under requirements 3.6.1 and 3.6.1.2: encrypted under a separate key, HSM, or split shares.

How we hand over

Deliver a requirement 3 evidence pack: data flow and storage inventory, configuration records and key custodian roster.
Document the cryptographic architecture under requirement 3.6.1.1 where your role applies, since it targets service providers.
Hand over a runbook covering key rotation, custodian changes and log review, plus items your assessor must confirm.

How we support

Retainers can cover Hyperswitch upgrades, including dependency changes such as the Superposition service required from v1.124.0.
Re-verify storage, key access and log settings after each upgrade and before evidence is collected for assessment.
Agree in writing who answers assessor questions about the vault, and how quickly, before the assessment starts.

Self-hosted Hyperswitch card vault and PCI DSS requirement 3