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
Production dashboard, marketing, and API traffic is served over HTTPS. TLS certificates are managed by the hosting provider, and HSTS is enabled on production domains where the platform configuration supports it.
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 mutation endpoints server-side. Plan limits for connected accounts, API keys, alerts, comparisons, budgets, and related workspace objects are enforced by API routes where those workflows are implemented.
Rate limiting and abuse controls
Rate limits apply to authentication endpoints, password-reset flows, invite creation, and public catalog search. Registration uses a persistent bucket keyed by IP and email to reduce credential-stuffing and automated abuse.
Transport and platform hardening
Application responses set defensive headers including Content-Security-Policy, Strict-Transport-Security, X-Frame-Options: DENY, X-Content-Type-Options: nosniff, and 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 such as credential changes, recommendation and waste transitions, automation executions, invite creation, and revocation are written to structured audit events where those workflows are implemented. Retention windows are plan and deployment dependent.
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 | Planned. Not complete and not represented as an active attestation. |
| SOC 2 Type II | Planned, following Type I. |
| ISO 27001 | Roadmap. No certification is currently claimed. |
| Annual penetration test | Planned. Third-party report availability is not claimed until a completed assessment exists. |
Security questionnaires and current policy summaries can be shared under a confidentiality arrangement. Completed SOC 2 or penetration-test reports are not claimed on this page. 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 aim to acknowledge reports within 3 business days and 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 do not intend to pursue 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 may offer public acknowledgement to reporters who request it.
7. Subprocessor security
We review sub-processors for appropriate security controls and, where available, independent attestations such as SOC 2, ISO 27001, or equivalent reports. Data-protection obligations are flowed 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