Summary
This policy describes how OnboardMe protects the Service for this South Africa 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: Rackzar
- Primary region: Cape Town
- Stored customer data is encrypted at rest
- TLS 1.2+ for data in transit
- Access to production systems is limited to authorised personnel
- Primary production data and backups for this deployment are stored in South Africa.
- Access controls: MFA, RBAC, and cloud IAM policies
Sensitive data classification
OnboardMe may process personal and contact details, Tax and revenue 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 South Africa (Cape Town)
- Nightly machine-image / volume backups to South Africa (Cape Town)
- 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
Encrypted backups in South Africa are used to restore services. Compute and networking are provisioned in the Cape Town deployment 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 POPIA requires it, the Information Regulator and affected data subjects are notified in line with applicable timelines.
- An internal post-incident review is completed within 72 hours.
- Legal counsel is engaged where required.
Assessment follows the Protection of Personal Information Act (POPIA) and guidance from the Information Regulator.
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
- Production systems are isolated with network access restricted to what is required
- The public-facing application is protected with TLS
- Inbound and outbound traffic is limited to required services
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 |
|---|---|---|
| Rackzar | Primary infrastructure | Critical |
| Paystack | 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
Rackzar is responsible for the underlying hosting infrastructure. OnboardMe is responsible for the security of data, applications, and access controls on that infrastructure.
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.