Security at QairoPay.

Certifications and audits

QairoPay maintains independent third-party assurance against the following frameworks. Reports and bridge letters are available to customers and qualified prospects under NDA.

• SOC 2 Type II — annual examination covering security, availability, processing integrity, confidentiality, and privacy.
• ISO/IEC 27001:2022 — annual surveillance audit; full re-certification every three years.
• PCI DSS 4.0 — Service Provider Level 1 baseline. Cardholder-data environment scoped to the Spend Card program and validated annually.
• FinCEN MSB — registered Money Services Business; see the Compliance page for the regulatory program.

Internal audits run continuously through automated control monitoring; remediation SLAs are tracked against control owners and reported to the Security Steering Committee monthly.

Encryption

All data is encrypted in transit and at rest. Encryption is layered, with separate key hierarchies for tenant-scoped data and for cardholder data.

In transit

• TLS 1.3 with forward secrecy for all external traffic. TLS 1.2 is the minimum negotiated version.
• Internal service-to-service traffic uses mutual TLS with workload identities issued by the cluster's identity provider.
• HSTS is enforced on all customer-facing domains with a one-year max-age and preload submission.

At rest

• Envelope encryption using AES-GCM-256 for application-layer ciphertext.
• Data encryption keys (DEKs) are wrapped by tenant-scoped key encryption keys (KEKs) held in Google Cloud KMS, backed by Cloud HSM (FIPS 140-2 Level 3).
• Database storage is additionally encrypted by the cloud provider with provider-managed keys, providing defense in depth.
• Cardholder PANs, where stored, are tokenized; raw PANs are never persisted to QairoPay-owned systems.

Key management

KEK rotation is automatic on a 90-day cadence; emergency rotation runs in under fifteen minutes against the full tenant set. KMS audit logs are streamed to the same immutable log sink used by the application audit log.

Access control

Customer authentication

• Email + password with rate limiting, breached-password checks, and optional WebAuthn / passkey enrollment.
• TOTP or WebAuthn second factor required for any account with elevated privileges; admin accounts cannot disable MFA.
• Session cookies are HttpOnly, Secure, and SameSite=Lax, with rotation on privilege change.
• SSO via SAML 2.0 and OIDC is available on the Business and Enterprise tiers.

Tenant isolation

Every record is tagged with a tenant_id. Application middleware enforces a tenant-scoped query context on every request; cross-tenant queries are technically impossible from the API surface and are alerted on at the database layer.

Internal access

• Role-based access control with the principle of least privilege; access reviews run quarterly.
• Production access is hardware-key gated (FIDO2) and time-bound via just-in-time grants.
• All production access is logged and replayable; sessions touching customer data are recorded.
• Background checks for all engineers with production access, refreshed every two years.

Infrastructure

QairoPay runs on Google Cloud Platform in us-central and us-east regions with active-active failover. Production workloads execute on GKE Autopilot; primary datastores are Cloud SQL (PostgreSQL) and Memorystore (Redis).

• Workloads are isolated in dedicated VPCs with private subnets, egress-only NAT, and Cloud Armor at the edge.
• All ingress is mediated by a managed WAF with OWASP Core Rule Set, custom rate limits, and bot management.
• Infrastructure changes are gated by Terraform plan review, two-person merge approval, and automated policy checks (CIS benchmarks, custom OPA rules).
• Container images are built from minimal distroless bases, scanned on every push, and signed with Sigstore; admission control rejects unsigned images.

Data handling and retention

QairoPay processes the minimum data required to deliver the service. Categories and retention windows are documented in the Privacy Policy; this section covers the technical handling.

• Tenant data is retained for the life of the contract plus 30 days, after which it is purged or anonymized.
• Audit events are retained for 12 months in hot storage and a further 6 years in GCS Archive cold storage, as required by financial-services record-keeping rules.
• Backups are encrypted, geo-replicated, tested quarterly, and retained for 35 days.
• Customer-initiated export and deletion are supported via the API; deletion is logically completed within 30 days and physically completed within 90.

Monitoring and audit log

Every authenticated action — API call, admin operation, pass issuance, settlement leg, role change — is recorded to an append-only audit log with a tenant-scoped Merkle chain. Audit records are immutable from the application's perspective and are streamed to a separate logging project that the application has no write access to.

• Real-time anomaly detection on authentication, key rotation, and privileged operations.
• Centralized SIEM with 24/7 on-call coverage; alerts are triaged to a P1 SLA of 15 minutes.
• Customers can stream their tenant's audit events via webhook or export via the API.

Incident response

QairoPay maintains a written Incident Response Plan reviewed annually and rehearsed quarterly via tabletop exercises.

• Severity 1 incidents (data exposure, sustained outage, integrity breach): customer notification within 24 hours; regulatory notification within statutory windows.
• Post-incident reports are shared with affected customers within 10 business days and include root cause, timeline, and remediation.
• A 24/7 on-call rotation covers production engineering, security operations, and legal.

Vulnerability disclosure

We welcome reports from independent security researchers. A formal Vulnerability Disclosure Program (VDP) and a private bug-bounty program are operated; safe-harbor terms cover good-faith testing within the program's scope.

• Scope, rules of engagement, and reward bands are documented in the VDP policy, available on request.
• Out-of-scope activities include denial of service, social engineering, and physical testing.
• We acknowledge valid reports within one business day and aim to remediate critical findings within 30 days.

Shared responsibility

Security is a shared responsibility. QairoPay secures the platform; customers secure their use of it. The most common customer-side responsibilities:

• Enforce SSO + MFA across your team; audit member access quarterly.
• Treat API keys as secrets — rotate on staff change, store in a secret manager, never embed in client code.
• Verify webhook signatures on every callback and reject unsigned payloads.
• Subscribe to status.qairopay.com for outage notifications and to the security advisories mailing list for critical patches.

Reporting a security issue

To report a suspected vulnerability or active incident, contact [email protected]. PGP keys are published at /.well-known/security.txt. Please include a clear reproduction path and any artifacts that demonstrate impact.

For customer-facing security questionnaires (CAIQ, SIG, vendor reviews), email [email protected] or request access to our Trust Center.

This page is informational and does not modify the contractual obligations defined in your QairoPay Master Services Agreement, Data Processing Addendum, or Security Schedule. Where this page conflicts with executed contract language, the contract governs.