Summary
This policy describes how OnboardMe protects the Service for this United Kingdom deployment: recovery objectives, backups, disaster recovery, monitoring, incident and privacy-breach response, security controls, access management, and vendor risk. It should be read with the Privacy Policy, Data Processing Agreement, and Terms of Service.
- Document owner: Lee Williams, Co-Founder
- Review: at least twice a year, or after a major incident
Business continuity objectives
OnboardMe is a cloud-based onboarding and compliance platform used to collect, validate, store, and process personal and regulated data as defined in the Terms and Privacy Policy.
Target recovery metrics
| Tier | Services | RTO | RPO |
|---|---|---|---|
| Tier 1 | Authentication, payments, onboarding APIs | 4 hours | 24 hours |
| Tier 2 | Compliance workflows and reporting | 8 hours | 24 hours |
| Tier 3 | Analytics and non-critical logging | 24 hours | 48 hours |
SLA target: 99.9% uptime, subject to exclusions in the Terms. External uptime is published on our status page.
Critical services covered
- Customer engagement and onboarding APIs
- Authentication and authorisation
- Payment integrations and transaction logging
- Compliance and identity validation workflows
- Integrations into third-party systems the Customer connects
Data protection and backups
Primary infrastructure
- Cloud provider: Amazon Web Services (AWS)
- Primary region: London
- EC2 volumes encrypted via AWS KMS
- S3 buckets encrypted at rest and in transit
- TLS 1.2+ for data in transit
- Primary production data and backups for this deployment are stored in the United Kingdom.
- Access controls: MFA, RBAC, and cloud IAM policies
Sensitive data classification
OnboardMe may process personal and contact details, Unique Taxpayer References (UTRs) and similar tax identifiers, bank details, identity documents, and AML records. These are protected with encryption and access policies as described here and in the Privacy Policy.
Backup and replication
- Nightly database replication to United Kingdom (London region)
- Nightly machine-image / volume backups to United Kingdom (London region)
- Backups encrypted at rest
Retention
- Audit logs: 12 months
- Database backups: 365 days
- Volume snapshots: 7 days
- Object-storage documents: until deleted in line with the Privacy Policy and DPA
Destruction and disposal
- After the subscription ends, Customer Personal Data is deleted from production within 90 days, or returned if requested, as set out in the Data Processing Agreement
- Deletion is applied across primary storage, backups, and replicas on the backup cycle
- Infrastructure media disposal follows the hosting provider’s certified processes
Disaster recovery
Nightly encrypted backups in the United Kingdom are used to restore services. Compute and networking are provisioned in the deployment region as part of recovery.
Recovery workflow
- Event detection via automated alerts or the on-call team
- Disaster declared by a co-founder or delegated incident commander
- Environment provisioned (compute and networking) for recovery
- Data restored from replicated backup sets
- DNS updated to recovered endpoints
- Core service tests executed
- Customers notified via the status page and support
Business impact
| Downtime | Estimated impact |
|---|---|
| 0–1 hour | Minimal — automated alerting, no customer impact expected |
| 1–4 hours | Moderate — customer workflows interrupted, SLA at risk |
| 4–8 hours | High — SLA breach, customer notification required |
| 8–24 hours | Critical — regulatory notification assessed, escalation to co-founders |
| 24+ hours | Severe — potential mandatory breach duties, executive crisis management |
Critical dependencies include hosting-region availability, payment providers, identity-verification APIs, DNS, and optional practice integrations (for example Xero, FYI, or Karbon).
Monitoring and incident response
Service uptime monitoring
- External uptime monitoring via Uptime Robot: status page
- Internal health checks, logs, and CloudWatch (or equivalent) alarms
- 24×7 automated alerting to the operations team
Logging
- Logs are retained for 12 months
- Infrastructure logs (for example AWS CloudWatch on AWS deployments)
- PostHog for product analytics; Sentry for application errors
- Application and payment event logs in the Service
- Database audit trails for key events
Incident classification
| Severity | Description |
|---|---|
| SEV-1 | Major outage affecting production |
| SEV-2 | Partial loss of service impacting users |
| SEV-3 | Internal degradation |
| SEV-4 | Informational |
- Automated alerts for thresholds (error spikes, region failure indicators)
- Incident command with defined escalation
- Root-cause analysis and post-incident reporting
Privacy breach response
Upon detection of a suspected data breach:
- The incident commander is notified immediately.
- Access is verified and credentials are reset where needed, targeting within one hour.
- Scope is assessed: what data, how many individuals, and what risk.
- Where UK GDPR requires it, the ICO is notified without undue delay and, where feasible, within 72 hours of becoming aware. Affected individuals are notified when there is a high risk to their rights and freedoms.
- An internal post-incident review is completed within 72 hours.
- Legal counsel is engaged where required.
Assessment follows the UK GDPR and the Data Protection Act 2018, including ICO notification duties where they apply.
Security controls
Vulnerability management
- Internal vulnerability scanning at least quarterly
- Critical vulnerabilities patched within 72 hours of identification
- High vulnerabilities patched within 14 days
- Findings tracked to resolution with documented sign-off
Application security
- OWASP Top 10 used as a baseline security reference
- Dependency scanning (for example Dependabot and Snyk)
- Secrets management via AWS KMS on AWS deployments, and equivalent controls otherwise
Network security
- Services are deployed within an AWS VPC with private subnets
- A web application firewall (WAF) is in place for the public-facing application
- Inter-service communication uses TLS 1.2 as a minimum
- Security groups restrict inbound and outbound traffic to what is required
Change management
- Production changes are deployed via a CI/CD pipeline
- No direct production access without documented approval
- Rollback procedures are documented for deployments
- An emergency change process is defined for critical hotfixes
Security awareness
- Staff complete security awareness training on onboarding
- Annual refresher training is mandatory
- Training records are maintained
Access and identity management
Principles
- Least privilege across systems
- Role-based access control (RBAC) in the Service
- Multi-factor authentication (MFA) mandatory for staff accounts
- Privileged access (cloud console, production database) requires MFA and is limited to authorised personnel
Joiners, movers, and leavers
- New staff: access provisioned by role, approved by a co-founder or manager, from the start date
- Role changes: access reviewed and updated within five business days
- Departures: access revoked on the day of departure, including cloud IAM, application admin, and third-party tools
- An offboarding checklist is maintained and signed off per departure
Access reviews
- Quarterly review of privileged access accounts
- Annual review of user access rights
- Immediate review after security incidents or personnel changes
Privileged access
- Production database access is restricted to named individuals
- Break-glass / root credentials are stored securely and used only for emergencies
- Break-glass access is logged and reviewed after use
Vendor and third-party risk
Material subprocessors are also listed in the Privacy Policy and the Data Processing Agreement.
| Vendor | Function | Criticality |
|---|---|---|
| Amazon Web Services | Primary infrastructure | Critical |
| Stripe | Payment processing | Critical |
| ComplyCube | Identity verification and AML screening (where enabled) | High |
| Resend | Transactional email | High |
| Mailgun | Transactional email | High |
| TallBob | SMS messaging | Medium |
| PostHog | Product analytics | Low |
| Sentry | Error monitoring | Low |
- Critical vendors are assessed for security posture before onboarding
- Critical vendor security documentation is reviewed at least annually (for example SOC 2, ISO certificates, or penetration-test summaries where available)
- Contractual processing terms are in place for vendors that handle personal data, as described in the Data Processing Agreement
- Critical vendor outages are escalated using the severity matrix above
Physical infrastructure security is AWS’s responsibility. OnboardMe is responsible for the security of data, applications, and access controls within AWS. AWS compliance information is published at aws.amazon.com/compliance.
Live uptime and SLA transparency
A public Uptime Robot dashboard provides visibility into service availability, including uptime over 24 hours, 7 days, 30 days, and 90 days, against a target of 99.9% (subject to exclusions in the Terms of Service).
Reporting a vulnerability
If you discover a security vulnerability, email [email protected]. We acknowledge reports within 24 hours and aim to provide a more detailed response within 72 hours.
Please report issues such as:
- SQL injection, XSS, CSRF, SSRF, or remote code execution
- Authentication or authorisation bypasses
- Data exposure or leakage
- Any other security concern in the Service
We ask that you:
- Give enough detail to reproduce the issue
- Allow reasonable time for investigation
- Do not access or modify other users' data without permission
- Do not use denial-of-service or other disruptive testing
With your permission, we may acknowledge your contribution without disclosing personal information.