Encryption
Last updated: July 4, 2026
Encryption is one of the most fundamental controls CORPYO relies on to protect customer data, both while it moves across networks and while it sits in our databases and backups.
Encryption in Transit
All network traffic to and from CORPYO — the website, dashboard, and API — is encrypted using TLS. Plaintext HTTP is not served; requests are automatically upgraded to HTTPS, and we publish HSTS (HTTP Strict Transport Security) headers instructing browsers to only ever connect over TLS. Internal service-to-service traffic between our application tier, database tier, and background workers is also encrypted, so data does not travel in plaintext even within our own network.
TLS Configuration
We terminate TLS at the network edge (Cloudflare) with a configuration that supports TLS 1.2 and TLS 1.3 and disables legacy, insecure protocol versions and cipher suites. Certificates are issued by trusted public certificate authorities and renewed automatically well before expiry. We periodically verify our TLS configuration against current industry guidance (such as Mozilla's TLS configuration recommendations) and adjust as guidance evolves.
Encryption at Rest
Customer data at rest — in our primary database, object storage, and backups — is encrypted using AES-256, a widely adopted industry-standard symmetric encryption algorithm. This applies to structured data (company records, KYC documents, billing information) as well as file uploads and database snapshots.
Password Hashing
CORPYO never stores account passwords in plaintext or in a reversible format. Passwords are hashed using a modern, memory-hard hashing algorithm (bcrypt-class or stronger) with per-user salts, so that even in the unlikely event of a database compromise, recovering original passwords is computationally infeasible. We support and encourage multi-factor authentication as an additional layer of account protection beyond the password itself.
Key Management
Encryption keys are managed through a dedicated key-management service (such as AWS KMS) rather than being embedded in application code or configuration files. Keys are access-controlled independently from the data they protect, rotated on a defined schedule, and never leave the key-management service in plaintext form. Access to key-management operations is logged and restricted to a small number of authorized systems and personnel.
Secrets Management
Application secrets — database credentials, API keys, signing keys, third-party service tokens — are stored in a managed secrets service and injected into application environments at runtime. Secrets are never committed to source control; our CI pipeline includes automated scanning to catch accidental secret exposure before it reaches a shared branch. Secrets are rotated periodically and immediately upon suspected exposure or personnel offboarding.