Draft — pending legal review. These terms are not legally binding until finalized. Questions or corrections: legal@rateplane.com.
Last updated: April 24, 2026
Security posture
This page describes the security controls Rateplane Ltd operates today, our incident-response commitments, our compliance roadmap, and how to report a vulnerability. It is a living document; changes are dated at the top. For the legal-framework counterparts, see our Privacy Policy and Data Processing Addendum.
1. Current controls
Encryption in transit
All traffic to the dashboard, marketing site, and API is served over TLS 1.2+ with HSTS enabled on production domains. Certificates are managed by our hosting provider and rotate automatically.
Envelope encryption at rest for cloud credentials
Cloud-provider credentials (AWS access keys, Azure service-principal secrets, GCP service-account JSON) are encrypted with AES-256-GCM using an envelope-encryption scheme with a key-encryption key held outside the database. The scheme supports key rotation without re-encrypting every row in place.
Password and session security
Passwords are hashed with bcrypt. Authentication is handled by NextAuth with JWT sessions. Sessions have an explicit inactivity expiry and sliding refresh policy. Forgot-password tokens are sha-256 hashed server-side, expire after 60 minutes, and are single-use.
Role-based access and workspace isolation
Each workspace is logically isolated. Workspace roles (OWNER, ADMIN, MEMBER, VIEWER) gate every mutation endpoint server-side. Plan limits (API keys, team members, alerts, comparisons, budgets) are enforced at the API layer, not just the UI, so a crafted client cannot bypass them.
Rate limiting and abuse controls
Rate limits apply to authentication endpoints, password-reset flows, invite creation, and catalog search. Registration uses a persistent bucket keyed by IP and email to stop credential-stuffing. API-key requests are rate-limited per plan.
Transport and platform hardening
Security headers are set on every response: Content-Security-Policy, Strict-Transport-Security, X-Frame-Options: DENY, X-Content-Type-Options: nosniff, X-XSS-Protection, Permissions-Policy. The X-Powered-By header is suppressed. Inbound third-party webhooks (Stripe, GitHub) are signature-verified before processing.
Audit logging
Account-level actions — credential changes, recommendation and waste transitions, automation executions, invite creation and revocation — are written to a structured audit log with the user, workspace, action, and metadata. Audit events are retained for 365 days on Pro and negotiable on Enterprise.
2. Access to production systems
- Access to production databases, credential-encryption keys, and customer data is restricted to a small named set of engineering and operations staff under the principle of least privilege.
- Privileged access requires multi-factor authentication and, where available, short-lived credentials issued per session rather than standing passwords.
- Access is reviewed quarterly. Access is revoked on termination or role change the same business day.
- Production admin actions are logged; logs are retained separately from the primary application database.
3. Incident response
72-hour breach-notification commitment. If a personal-data breach is likely to result in a risk to the rights and freedoms of data subjects, we will notify the UK Information Commissioner's Office (ICO) without undue delay and no later than 72 hours after becoming aware, in accordance with Article 33 UK GDPR. Where the breach is likely to result in a high risk to data subjects, we will notify affected customers directly and without undue delay.
Our incident-response process has the following phases:
- Detect. Alerts from structured logging, error-monitoring, and provider-side signals feed a single on-call rota.
- Triage. The on-call engineer confirms the signal, opens an incident channel, and assigns a severity (SEV-1 customer impact / SEV-2 degraded / SEV-3 internal-only).
- Contain. Relevant access is revoked, suspect credentials rotated, and affected code paths disabled where necessary.
- Notify. For personal-data breaches, the ICO is notified within 72 hours of confirmation, and affected customers are notified directly where the risk is high.
- Recover. Services and data are restored; customers are given a status update on cadence.
- Review. A blameless post-incident review produces follow-up actions and a customer-facing summary where appropriate.
4. Business continuity and backups
- Primary databases are backed up at least daily; backups are encrypted at rest.
- Backups are retained on a rolling window; customer data purged from primary storage on account deletion is removed from rolling backups within 90 days.
- Restore procedures are tested periodically. Recovery-time and recovery-point objectives are documented internally; they are disclosed to Enterprise customers on request under a confidentiality arrangement.
5. Compliance roadmap
| Standard / attestation | Status |
|---|---|
| UK GDPR + Data Protection Act 2018 | Operated against today. See Privacy Policy. |
| SOC 2 Type I | In progress. Scoping complete; observation period starting. |
| SOC 2 Type II | Planned, following Type I. |
| ISO 27001 | Roadmap. Targeted after SOC 2 Type II lands. |
| Annual penetration test | Scheduled. First engagement booked; attestation letter and executive summary available to Enterprise customers under NDA. |
Compliance artifacts (policies, SOC 2 reports, pentest summaries) are shared with Enterprise prospects and customers under a confidentiality arrangement. Contact security@rateplane.com.
6. Responsible disclosure
Report a vulnerability
Email responsible-disclosure@rateplane.com with a description of the issue, reproduction steps, and any proof-of-concept. We acknowledge reports within 3 business days and aim to triage within 10 business days.
We ask security researchers to follow these rules of engagement:
- Test only your own account and your own workspace. Do not access data that does not belong to you.
- Do not run automated scanners against production without prior permission; they are rate-limited and will burn our on-call.
- Do not perform denial-of-service testing, social engineering against staff, or physical-security testing.
- Give us a reasonable time to fix the issue before public disclosure — typically 90 days.
We are committed to not taking legal action against researchers who operate in good faith under these rules. A formal bug-bounty programme with monetary rewards is on our roadmap; in the interim we offer public acknowledgement to reporters who request it.
7. Subprocessor security
We select sub-processors that hold their own security attestations (SOC 2 and/or ISO 27001 or equivalent) and flow equivalent data-protection obligations down through written contracts. The current sub-processor list is maintained in the Privacy Policy and in Annex III of the Data Processing Addendum.
8. Changes to this page
We revise this page when controls change. The "Last updated" date at the top reflects the most recent material change. The change history is tracked internally; we share a redlined summary with Enterprise customers on request.
9. Contact
General security enquiries: security@rateplane.com
Responsible disclosure: responsible-disclosure@rateplane.com