PCI DSS scope of self-hosted payment orchestration

Which vault model keeps the cardholder data environment smallest

What enters the cardholder data environment in a Hyperswitch deployment

The PCI SSC defines the cardholder data environment (CDE) by what stores, processes or transmits account data, plus anything with unrestricted connectivity to it. In a self-hosted Hyperswitch deployment, several components fall inside that boundary, and some sit outside it only if the design keeps them that way.

Mapping PCI DSS requirements 12.5.1, 12.5.2 and 12.8 to self-hosted orchestration

This table maps three PCI DSS v4.x requirements to the work a self-hosted Hyperswitch deployment creates for the entity, and shows how to configure each one. Read each row as a control the entity owns, even when a vault or processor carries part of the load. The main takeaway is that a compliant processor or vault narrows the work but never removes the entity's own annual scope confirmation or its third-party oversight duties.

How segmentation and significant change keep scope confirmed

The sequence maps where card data flows, isolates the parts that store and process it, tests that the boundary holds, and re-confirms scope whenever the architecture changes. The output is a scope record that an assessor can check against the running environment.

1. Map data flows from checkout to processors

   Trace every path that account data takes, from the checkout page or SDK through the Hyperswitch Router, the vault, each processor connector, and back to the merchant systems that receive authorization results. The integration or security team owns the diagram, and the payment engineering team confirms it against the deployed connectors. The step is done when the diagram lists every data flow, every storage location (including logs, backups and reconciliation exports), and every third-party connection, and each item has a named owner.

2. Place the vault and encryption service in a restricted segment

   Put the card vault and the encryption service for key management in a network segment with the narrowest possible inbound and outbound rules, with only the connections the data flow map requires. Keep PostgreSQL and Redis instances that touch card data in that boundary or confirm they never receive it. The platform team records the segment design, firewall rules and Kubernetes network policies. The step is done when the rule set matches the diagram and an unlisted path is denied by default.

3. Define which components are in scope

   Using the segment design, classify each system component as in scope (stores, processes or transmits account data, or has unrestricted connectivity to those that do) or out of scope with a documented reason. Include the Control Center, admin workstations, CI/CD pipelines, monitoring stacks and log pipelines, since each can affect the security of account data. The output is the component inventory with a stated function for each item, which the PCI DSS inventory requirement expects.

4. Test segmentation and admin access paths

   Verify that Router and Scheduler traffic, admin access to the Control Center, and maintenance sessions reach only the paths defined in the design. Testing methods (for example, penetration-style testing from out-of-scope segments, rule review, or network mapping) are chosen by the assessor and the entity's own design, so confirm the approach in advance with your QSA. Record the test scope, method, results and remediation. The step is done when the tests show that out-of-scope networks cannot reach the vault or key services, and the findings are filed.

5. Confirm the processor and TPSP list

   For every processor, acquirer, fraud tool, vault provider or hosting provider in the route, record which party is responsible for each PCI DSS requirement, the written agreement and security acknowledgment, the date of due diligence, and the most recent review of its compliance status. A processor's own PCI DSS compliance does not remove your responsibility for your part, so this list is a control record, not a substitute for your assessment. The step is done when each TPSP has an entry with its responsibility split.

6. Document the annual scope confirmation

   Write the scope record covering data flows, account data locations, the CDE and connected components, segmentation controls and third-party connections, then confirm it with the accountable owner. This is the entity's own confirmation, separate from the assessor's scoping during the annual assessment, so keep it current between assessments. The step is done when the record is dated, signed off, and linked to the diagram, inventory and test results from the earlier steps.

7. Re-confirm scope on significant change

   Trigger a new scope review before production changes that could alter the data path or the boundary. Examples to assess include a new processor connector, a switch to a different vault model, or a Kubernetes or database migration. Whether a change is significant is a judgment the entity should document and confirm with its assessor, using the PCI SSC significant change guidance as the reference. The step is done when each change has a recorded decision, and the affected steps above are repeated where needed.

8. Read the PCI SSC segmentation supplement before design

   Before the first design, have the architecture and compliance leads read the PCI SSC information supplement on scoping and segmentation for modern network architectures, including containers and cloud networking. Use it to test your design assumptions, then confirm with your QSA how it applies to your environment. The output is a short note of design decisions and open questions that feeds the first scope record. Confirm the supplement's current version on the PCI SSC site, since the standard and its supplements change over time.

Questions buyers ask about PCI DSS scope for self-hosted payment orchestration

What tooling alone does not satisfy

Self-hosting Hyperswitch changes where cardholder data sits and which controls you run, but it does not produce validation evidence or remove your own obligations. The cards below cover the gaps that tooling leaves open and the process, people and records that close them.

Evidence auditors ask for and which component produces it

This table maps each evidence item an assessor or auditor typically asks for to the PCI DSS requirement it supports and the component or record that produces it. Use it to plan which records your team, Hyperswitch deployment and third parties must generate before the assessment begins. AOCs and ROCs come from the assessor and each provider, not from DeployOpen.

Deciding whether to self-host or use an outsourced vault

How to set up processor and TPSP management under Requirement 12.8

This sequence produces a current, written inventory of every processor, vault provider and hosting provider in the payment route, with the security responsibilities of each party recorded and reviewed on a fixed cycle. It keeps your own PCI DSS obligations visible even when the providers are compliant.

1. Inventory every provider in the payment route

   Your payments or security lead lists each processor, PSP, card vault provider, payment method provider, cloud or hosting provider and managed service that stores, processes, transmits or could affect account data in the route. Include the Hyperswitch deployment's underlying cloud services, such as managed databases, key management and logging, because they can touch the cardholder data environment. The step closes when the list is complete, each entry names the function it performs and the data it touches, and the list matches the connector configuration in your Hyperswitch Control Center. Confirm each entry against your system component inventory under Requirement 12.5.1.

2. Collect attestations and responsibility splits

   For each provider, request its current PCI DSS attestation of compliance, the scope of services it covers and the provider's responsibility matrix for each requirement. Ask the provider which parts of the service fall under its assessment and which parts remain yours, such as how you configure the connector or handle keys. The step is done when every provider has a dated attestation on file or a documented reason it is not in scope, and each responsibility split is stored with your scope records. Note that a compliant provider does not transfer your own compliance responsibility.

3. Execute written agreements with security acknowledgments

   Your legal and procurement teams sign an agreement with each provider that includes a written acknowledgment that the provider is responsible for the account data it stores, processes or transmits, or could affect. Confirm that the contract covers incident notification, cooperation with your assessor and the obligation to keep its PCI DSS status current. The step is complete when each signed agreement is filed alongside its provider entry in the inventory, and no provider remains in the route without a contract that contains these acknowledgments.

4. Complete due diligence before go-live

   Before any connector carries live traffic, your security team reviews each provider's attestation, the scope and date of its assessment, its incident history where disclosed, and its security controls for the services you use. For self-hosted vault models, also review who operates the external vault and where keys are held. Record the review outcome and the approver. The step closes when every provider has a signed-off due diligence record dated before the first live transaction, and any gap is either resolved or accepted in writing by a named owner.

5. Record which party manages each requirement

   Using the provider list and responsibility splits, your team builds a responsibility matrix that assigns each PCI DSS requirement to you, to a provider or to both. Areas to cover include key management, card data storage, network segmentation, logging and access control for the Hyperswitch application servers and database. Review the matrix with your QSA or internal assessor so the shared areas are described consistently. The step is complete when the matrix is approved, stored with your scope documentation, and each shared requirement names the evidence each party will supply.

6. Schedule and run status reviews every 12 months

   Set a recurring review for each provider, at intervals of no more than 12 months, to confirm its PCI DSS status is still current. The review obtains the latest attestation, checks for changes to the service or data flows, and updates the responsibility matrix. Your compliance lead owns the calendar and the outcome record. The step is complete when every provider has a dated review entry in the tracker, with the next review date set. Significant changes, such as adding a connector, should also trigger an out-of-cycle review.

7. Reconcile TPSP changes with annual scope confirmation

   When a provider is added, replaced or changes its service, update the provider list, the responsibility matrix and the scope documentation together. Confirm the change against your annual scope confirmation under Requirement 12.5.2, which the assessor's own scoping does not replace. The step closes when the updated records are approved and the scope confirmation reflects the current route. Keep the change history so an assessor can see when each provider entered and left the route.