payment-gateway.app Docs
Deployment

Shared Responsibility Matrix

Clarifies which data-protection controls are covered by the application and which must be operated by the self-hosted customer.

Shared Responsibility Matrix

In a self-hosted model, data protection is shared between:

  • the Payment Gateway application capabilities, and
  • your operational implementation as system operator.

Use this matrix during onboarding, audits, and internal security reviews.

Responsibility Overview

Control AreaApplication ProvidesOperator Must Provide
Payment data boundaryProvider-tokenized card flow patterns; no raw PAN/CVC storage by gateway servicesProvider account configuration, checkout-domain security, and integration review
EncryptionSystem and organization encryption features; KMS integrations; key lifecycle workflowsKMS account setup, key policies, credential custody, and rotation execution
Data retentionRetention settings in Admin UI (Settings > Retention)Legal retention decisions, approved policy values, and periodic policy review
Backup/recoverymgob integration model and restore runbooksBucket security, backup schedule/retention ownership, and tested restore drills
Access controlRBAC, API key scope model, auth middlewareIAM policy for infrastructure/admins, least-privilege governance, periodic access reviews
Logging/auditabilityApp-side logs and auditable operations in servicesCentral log retention, SIEM/monitoring, and incident response workflow
Deployment securityConfigurable TLS and secure-by-default deployment templatesHost hardening, patching, network segmentation, firewall/WAF, secret management
Compliance operationsTechnical control surface for GDPR-oriented implementationDPA/ROPA, legal basis mapping, DSR workflows, policy documentation, legal review

Minimum Operator Control Set

Before production go-live, ensure you have:

  1. Documented owner for each control area above.
  2. Approved retention policy values per data type.
  3. Key-rotation and secret-rotation procedures.
  4. Restore drill cadence with evidence retention.
  5. Access review cadence for admins and API keys.
  6. Incident response process with escalation contacts.

Evidence to Keep

Keep records for:

  • encryption enablement and key-rotation events,
  • retention configuration changes,
  • backup success checks and restore test outcomes,
  • administrative access grants/revocations,
  • security incidents and remediation actions.

On this page