Security at Swepay is implemented in code and infrastructure, not in slide decks. The list below is verifiable, each item is something you or your security team can validate during a technical review.
Data residency: sa-east-1
All Swepay production services run in AWS sa-east-1 (São Paulo). Your data does not leave Brazil by default, and there is no configuration today to transfer it elsewhere. When an auditor asks 'where is my data?', the answer is one region in São Paulo.
Encryption at rest and in transit
TLS 1.2+ enforced on every API surface. Database storage uses managed encryption keys. Object storage (where presigned certificate downloads live) uses server-side encryption with a managed key service. No plaintext sensitive data persists on disk.
Root CA keys in managed key custody
Your tenant's root CA key is generated inside a managed cryptographic key store and used via managed cryptographic operations. The key material is not extractable by Swepay operators in normal operations. Access requires multi-party approval logged through an immutable cloud audit trail.
Audit log, immutable
Every administrative API call is logged with timestamp, tenant ID, action, request fingerprint, and result. Logs are retained per your subscription tier (30 days to 1 year). Tampering would require compromise of the cloud-managed log retention service, a security boundary that is not in Swepay's threat model.
Tenant isolation
Each tenant has a dedicated private Certificate Authority with its own root key, its own audit log scope, and its own access boundary. Multi-tenancy is enforced from API down to storage layer, not implemented as a column filter in a shared database.
Least-privilege IAM
Swepay's internal operators operate under least-privilege AWS IAM roles. Break-glass procedures exist for emergency access and are themselves audit-logged. Routine engineering work does not require access to tenant data.
Vulnerability management
Dependencies and infrastructure are scanned automatically through standard dependency and vulnerability tooling. Critical vulnerabilities are addressed within defined SLAs. We do not yet have a public bug bounty program; responsible disclosure goes to [email protected].