"Your data is encrypted at every layer, always."
From the moment data enters Propeter's systems to the moment it rests on disk — and every hop in between — it is protected by industry-standard encryption with no exceptions.
Encryption at Rest
All data stored within Propeter's infrastructure is encrypted at rest. Encryption is enforced at the storage layer — meaning even if physical media were ever extracted, the data would be unreadable without the corresponding AWS KMS keys.
PostgreSQL Database (AWS RDS)
- AES-256 encryption via AWS RDS Encryption (enabled at instance creation)
- Encryption applies to: data files, automated backups, snapshots, read replicas, and logs
- AWS KMS Customer Managed Key (CMK) per deployment region
- Separate encryption context per tenant_id enforced at KMS policy level
- In-memory data: encrypted by RDS before being written to storage
File & Object Storage (AWS S3)
- Default: SSE-S3 (Server-Side Encryption with AWS-managed keys)
- Enterprise plan option: SSE-KMS with customer-managed keys (BYOK)
- All PUT operations require encryption header; unencrypted uploads are rejected by S3 bucket policy
- Bucket versioning enabled; all versions encrypted at creation
- S3 Object Lock available for compliance / legal hold scenarios
Backups & Snapshots
- RDS automated backups: encrypted with the same CMK as the source instance
- S3 backup archives: SSE-KMS, cross-region replication preserves encryption
- Backup encryption is not optional; cannot be disabled via any interface
- Key policy requires both the source and DR region KMS CMKs for cross-region restores
- Backup decryption requires MFA-authenticated IAM session (enforced by key policy)
Redis Cache (AWS ElastiCache)
- At-rest encryption enabled on all ElastiCache Redis clusters
- Encryption applied to: disk swap files, snapshots, read replicas
- Cache keys namespaced by tenant_id to enforce logical separation
- Sensitive data (session tokens, rate data) stored with additional application-layer encryption before caching
- Cache TTL enforced: rate data 4 hours, session data 30 minutes
Encryption Key Management at Rest
- Key storage: AWS Key Management Service (KMS) — FIPS 140-2 Level 3 validated hardware security modules
- Automatic key rotation: Every 12 months for all Customer Managed Keys (CMKs)
- Key access: Restricted to specific IAM roles; all key usage logged to CloudTrail
- Key deletion: 30-day pending deletion window; deletion requires dual authorisation
- Customer-managed keys (BYOK): Available on Enterprise plan — client provides their own CMK via AWS KMS key policy cross-account trust
Encryption in Transit
All data moving between systems — whether from a hotel manager's browser to Propeter's API, or between internal microservices — is encrypted in transit. No plaintext communication is permitted on any production channel.
External Client Traffic
- TLS 1.3 minimum enforced on all public-facing endpoints
- TLS 1.0 and TLS 1.1 are explicitly disabled; connections rejected
- TLS 1.2 permitted only for legacy PMS/OTA integrations where 1.3 is unsupported
- Certificate management: AWS ACM with automatic renewal (no manual certificate management)
- HSTS (HTTP Strict Transport Security) enforced: max-age 1 year with includeSubDomains and preload
- HSTS preload submitted to browser preload lists
Internal Service Communication
- mTLS (mutual TLS) for all service-to-service communication within ECS
- AWS Service Mesh (App Mesh) manages certificate issuance and rotation for internal services
- Each microservice has a unique service identity certificate
- Certificate validity: 24 hours for internal certs (auto-rotated by App Mesh)
- Plaintext communication between services is architecturally blocked by security group rules
Database & Cache Connections
- All application-to-RDS connections: TLS enforced via
ssl: requirein connection string - RDS certificate authority: AWS RDS CA 2019 (valid to 2024 — migrated to rds-ca-rsa4096-g1)
- All application-to-ElastiCache Redis connections: TLS in-transit encryption enabled
- Connection pooling (PgBouncer): TLS enforced on both client and server side
Third-Party API Connections
- PMS / OTA integrations: TLS 1.2 minimum; certificate validation enforced (no self-signed certs)
- Certificate pinning: implemented for high-risk integrations (Windcave payment API)
- WebSocket connections (real-time dashboard): WSS (WebSocket Secure over TLS 1.3)
- Outbound webhooks: HTTPS only; TLS certificate verified before payload delivery
- Twilio / SendGrid / Firebase: connections verified against provider CA chains
Cipher Suite Policy: Propeter enforces a restricted cipher suite — only AEAD ciphers are permitted (e.g., TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256). RC4, 3DES, and NULL cipher suites are explicitly blocked. Forward secrecy is required (ECDHE key exchange only).
Encryption Flow — End to End
The diagram below illustrates how data is protected at every layer as it travels from a hotel user's device to the database and back.
Every arrow represents an encrypted channel. There is no point in this chain where data travels or rests in plaintext.
Data Classification
Propeter classifies all data it handles into four tiers. Encryption requirements and access controls are determined by the classification tier assigned to each data category.
| Tier | Definition | Propeter Examples | Encryption | Access | Retention |
|---|---|---|---|---|---|
| Public | Information intended for public consumption; no harm if disclosed | Marketing content, published rate benchmarks (anonymised), help articles | TLS in transit; no at-rest requirement | No restriction | Indefinite |
| Internal | Business information not for public release; limited impact if disclosed | Internal product roadmaps, staff directories, non-sensitive system logs, support tickets | TLS in transit; encrypted S3 storage | Propeter staff only; RBAC enforced | Per retention schedule |
| Confidential | Sensitive business or client data; significant harm if disclosed | Hotel rate strategies, booking data, occupancy forecasts, client API keys, staff personal data, financial reports | AES-256 at rest; TLS 1.3 in transit; tenant-isolated KMS context | Authorised client users + Propeter infra team (JIT); full audit log | Contract term + 30 days post-termination |
| Restricted | Highest sensitivity; legal or regulatory obligation to protect; severe harm if disclosed | Payment tokenisation data, guest PII (passport numbers if stored), security audit logs, cryptographic key material, incident forensic data | AES-256 at rest; TLS 1.3 in transit; HSM-backed KMS key; field-level encryption where applicable | CISO + Infrastructure Lead only; dual authorisation; session recorded | Statutory minimum or 7 years (legal hold) |
Classification in Practice: Each data field in Propeter's PostgreSQL schema carries a classification annotation in the ORM model. Automated tooling (run on every migration) validates that Restricted and Confidential fields are never logged in plaintext to CloudWatch or Datadog.
Key Management
AWS KMS — Master Key Store
- All cryptographic keys stored in AWS KMS (FIPS 140-2 Level 3 HSMs)
- No master key material ever stored in application code, environment variables, or config files
- Application secrets (API keys, database passwords) stored in AWS Secrets Manager — never in SSM Parameter Store or code repositories
- KMS key policies follow least-privilege: each service has a dedicated IAM role with KMS access restricted to required key IDs only
Key Rotation Policy
- Public tier: no key requirement
- Internal tier: AWS-managed key, automatic annual rotation
- Confidential tier: CMK, 12-month automatic rotation, immediate rotation on suspected compromise
- Restricted tier: CMK, 12-month rotation, quarterly manual verification of key health
- Internal mTLS certificates: 24-hour rotation (automated via App Mesh)
- JWT signing keys: 30-day rotation, old keys valid for 24 hours during transition
Secrets Management
- AWS Secrets Manager for all operational secrets (DB passwords, third-party API keys)
- Automatic secret rotation configured for RDS master password (90-day cycle)
- Secrets injected into ECS task containers at runtime; never written to ECS task definition in plaintext
- Git repository pre-commit hooks block commits containing secret patterns (high-entropy strings, known key formats)
- Quarterly audit: Snyk and truffleHog scans of entire codebase for accidental secret commits
Customer-Managed Keys (BYOK)
- Available on Enterprise plan
- Client provides their own AWS KMS CMK via cross-account key policy grant
- Propeter uses client CMK for all client-specific data encryption (RDS, S3, Secrets)
- Key revocation by client immediately renders all client data inaccessible to Propeter
- BYOK setup requires a dedicated onboarding session with Infrastructure Lead and CISO
Hardware Security Module (HSM) Roadmap
AWS KMS uses FIPS 140-2 Level 3 validated HSMs for key storage — providing strong hardware-backed protection for all current workloads. For clients requiring dedicated HSM isolation (typically financial institutions or government-adjacent workloads), AWS CloudHSM integration is on Propeter's roadmap for H2 2026. CloudHSM provides single-tenant HSM clusters where no AWS personnel can access key material.
Payment Data — Special Section
✅ Propeter NEVER Handles Raw Payment Card Data
Propeter is architecturally designed to be entirely outside PCI DSS scope for cardholder data. Here is precisely how payment data flows:
- Card input: Collected exclusively via Windcave/Qvalent's hosted payment pages or iFrames — Propeter's servers never receive card numbers, CVVs, or full PANs
- Tokenisation: Windcave/Qvalent (PCI DSS Level 1 certified) converts card data to a non-reversible token before any data reaches Propeter
- Token storage: Propeter stores only the payment token — a random reference string that has no mathematical relationship to the underlying card number
- Token use: Subsequent charges use the stored token; the card data never re-enters Propeter's system
- PCI DSS scope: Windcave/Qvalent holds PCI DSS Level 1 certification and is responsible for all cardholder data security within their environment
For procurement teams: Propeter's architecture means you are not extending your PCI DSS scope by using Propeter. Our annual penetration test explicitly confirms cardholder data does not traverse or reside in Propeter's infrastructure. Evidence available on request (NDA required).
Encryption Audit Trail
Propeter maintains a comprehensive audit trail of all encryption-related events. This enables forensic investigation, compliance reporting, and early detection of key misuse.
AWS CloudTrail — Key Usage Audit
- Every KMS key usage event (Encrypt, Decrypt, GenerateDataKey, etc.) is logged to CloudTrail
- CloudTrail logs are tamper-protected: stored in a dedicated S3 bucket with Object Lock (WORM)
- Log integrity validation enabled: SHA-256 digest files for each log file
- Retention: 365 days in S3 Standard; archived to S3 Glacier Instant Retrieval after 90 days
- Alerting: Any KMS key policy modification or unexpected decrypt operation triggers an immediate PagerDuty alert
CloudWatch — Encryption Events
- Application-layer encryption/decryption events logged with correlation IDs
- Failed decryption attempts (e.g., wrong tenant context) logged as security events and reviewed
- Certificate expiry monitoring: alerts at 30 days, 14 days, and 7 days before expiry
- TLS handshake failure rates monitored; spike triggers investigation
Encryption Health Reports
- Monthly encryption health report: Available on request for Enterprise clients. Covers: key rotation status, certificate health, failed authentication events, and TLS cipher suite usage distribution.
- Annual cryptography review: Propeter's CISO conducts an annual review of all encryption algorithms in use, assessing against NIST recommendations and migrating any deprecated algorithms.
- Post-quantum readiness: Propeter is monitoring NIST's post-quantum cryptography standardisation process. Migration planning to quantum-resistant algorithms (e.g., CRYSTALS-Kyber) will begin when AWS KMS support is generally available.
Transparency: Enterprise clients can request their tenant-specific KMS key usage report (covering the prior 90 days) at any time. This report shows every encryption and decryption operation performed on your data, with timestamps and IAM role identifiers. Contact your Customer Success Manager to request this report.
Enhance customer engagement with our intelligent chatbot solutions. Seamlessly automate conversations and elevate user experiences with cutting-edge AI technology.
Products
Copyright © 2026 propeter | Powered by Propeter