Security and Data Protection

1. Our commitment

Handover HQ processes some of the most sensitive material an organisation holds: what a departing employee knows, who they worked with, and what is at risk when they leave. We treat that material accordingly.

This document describes the security controls that are in place today, the standards we hold ourselves to, and — in section 10 — the controls we have not yet built. We would rather be useful to your security reviewer than impressive to them, so nothing below is aspirational unless it is explicitly marked as planned.

These protections apply equally to every account, whether on a free trial or a paid subscription.

2. Hosting and data residency

2.1 Where your data lives

Customer data is stored at rest in Australia. Our database and authentication layer run on AWS ap-southeast-2 (Sydney) via Supabase, and our application API runs in Fly.io’s Sydney region. Frontend assets are delivered from Vercel’s edge network, which holds no application data at rest.

Some sub-processors that support the Service operate in the United States — specifically AI processing, voice synthesis, email delivery and error monitoring. Where data is transferred internationally we rely on the safeguards described in our Privacy Policy and Data Processing Agreement. Section 11 links the full register.

2.2 Platform resilience

• Managed, redundant infrastructure with automatic failover handled by our hosting providers.
• Network-layer denial-of-service mitigation is provided by Vercel and Fly.io at their edge. We do not operate our own web application firewall.
• Automatic scaling so that load spikes degrade throughput rather than availability.

3. Encryption

3.1 In transit

All traffic between your browser and our servers, and between our own services, is encrypted with TLS 1.2 or above. HTTPS is enforced on every endpoint and we send HTTP Strict Transport Security headers to prevent protocol downgrade.

3.2 At rest

All stored data is encrypted at rest with AES-256, managed by AWS through Supabase. This covers account records, handover content (questionnaire responses, uploaded documents, voice recordings and transcriptions) and every backup.

3.3 Secrets and keys

Encryption keys are managed by our infrastructure providers’ key management services. Application secrets are held as encrypted environment variables in Fly.io and Vercel, are never committed to source control, and are accessible only to the small number of people who administer production.

4. Access control and tenant isolation

4.1 Authentication

• Sessions are managed by Supabase Auth using signed, expiring JSON Web Tokens.
• Sign-in is available with Google or Microsoft (Azure AD). Where your organisation enforces multi-factor authentication on those identity providers, that enforcement carries through to Handover HQ.
• New team members are invited by single-use magic link sent from a verified sender domain.
• Sessions expire automatically after a period of inactivity.

Native multi-factor authentication and SAML single sign-on are not yet available. Both are on the roadmap in section 10.

4.2 Tenant isolation

Handover HQ is a multi-tenant platform, so the boundary between one customer’s data and another’s is the control that matters most. We enforce it in two independent layers:

• Database layer. PostgreSQL row-level security is enabled on every table in the application schema — 77 of 77 tables, carrying 163 policies as at 1 September 2026. The database role our API connects as is explicitly unable to bypass row-level security, so these policies are enforcement rather than advice.
• Application layer. Global query filters in our data-access layer scope every query to the authenticated user’s organisation before it reaches the database, as defence in depth.

Cross-tenant access is verified by an automated test that attempts to read another organisation’s records and asserts that zero rows are returned.

4.3 Authorisation

• Role-based access control limits users to the data and actions appropriate to their role in a handover.
• Least privilege is applied to system and administrative access.
• Administrative actions are recorded in the audit log described in section 6.

4.4 Access by Handover HQ personnel

We are a small team, and we would rather describe that accurately than imply a larger control environment than exists.

• Production access is limited to a small number of named personnel and is granted only where it is needed to operate or support the Service.
• Access to production systems is logged.
• We do not access customer handover content except where you ask us to, or where it is strictly necessary to diagnose a fault you have reported.
• Formal background screening and a scheduled security-training programme will be introduced as the team grows; see section 10.

5. Application and platform security

• Security headers — HSTS, Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Referrer-Policy and Permissions-Policy are set on application responses.
• Rate limiting — eight tiered rate-limit policies apply across authenticated, AI, public, upload, chat and document endpoints, with separate daily budgets on voice synthesis per IP, per organisation and per interview token.
• Webhook integrity — inbound webhooks from HR systems are authenticated with HMAC signatures using constant-time comparison, with replay protection.
• Upload handling — uploaded files are validated on filename and URL before they are stored.
• Error handling — application errors are reported to our monitoring provider with authentication headers and tokens redacted, and error responses returned to users contain no personal data.
• Dependency management — dependencies are monitored for published vulnerabilities and patched on a rolling basis.

6. Audit logging and monitoring

Sensitive operations — authentication events, permission changes, handover lifecycle transitions, exports, API key issuance and administrative actions — are written to an append-only audit log. 52 distinct action types are audited as at 1 September 2026. Each entry records the acting user, the action, the entity affected, the source IP address, the user agent and a structured detail payload.

Administrators can review their own organisation’s audit log in the application under Settings. Audit records are currently retained indefinitely; a formal retention period will be set as part of our SOC 2 readiness work. Application errors and availability are monitored continuously, with alerting to our engineering team.

7. AI processing

AI is central to how Handover HQ captures knowledge, so it carries its own controls.

• Named providers. We use OpenAI for interview evaluation, summarisation and brief generation, and ElevenLabs for text-to-speech in voice interviews. Only question text is sent to ElevenLabs; answers are never transmitted to it. Both are listed in our Sub-processor Register.
• No training on your data. Our contracts with AI providers prohibit the use of customer data to train their models, and prohibit retention beyond the period needed to return a response.
• Tenant isolation. Data sent for AI processing is scoped to a single organisation. One customer’s content is never used to generate output for another. This applies to trial and paid accounts alike.
• Input validation. Content passed to AI models is validated and bounded to reduce the risk of prompt injection and to prevent unbounded spend.
• Human authority. AI output is a draft. Handover content is reviewed and approved by a person before it is treated as final, and every AI-generated question is labelled as such in the interface.

8. Retention, backup and deletion

8.1 Backup and recovery

• Automated daily backups with point-in-time recovery, managed by our database provider.
• Backups are encrypted and held under the same Australian data residency as primary storage.
• Formal recovery time and recovery point objectives are being documented as part of our SOC 2 readiness work; see section 10.

8.2 Deletion

When you delete data or close your account:

• Handover content remains available for export for 30 days after account closure or trial expiry.
• After the export window, data is permanently removed from primary storage within a further 30 days.
• Backup copies are purged so that all copies, including those in backup systems, are deleted within 90 days of termination. This matches the contractual commitment in clause 10 of our Data Processing Agreement.
• Written confirmation of deletion is available on request.

8.3 Trial data

Data processed during a free trial receives exactly the same protection as data under a paid subscription. If a trial ends without conversion, data is retained for 30 days to allow you to convert or export, after which the deletion process above applies.

9. Incident response

We maintain a documented incident response process:

• Detection — automated monitoring and alerting on errors, availability and anomalous request patterns.
• Assessment — triage of severity, scope and affected customers.
• Containment — immediate action to limit impact, including credential rotation and service isolation where warranted.
• Notification — where an eligible data breach affects personal information, we will notify affected customers and the relevant regulators as required by law, including the Australian Notifiable Data Breaches scheme and, where applicable, the UK and EU GDPR. This applies to trial data as well as paid accounts.
• Remediation and review — root cause analysis, corrective action, and a written post-incident review.

Where a breach affects data we process on behalf of a subscribing organisation, we will notify that organisation without undue delay and in any event within 48 hours of becoming aware of it, so they can meet their own notification deadlines. This is the commitment given in clause 8 of our Data Processing Agreement.

10. Compliance status and roadmap

We publish our compliance position honestly, including what is not yet done. Independent certification takes time and we are not going to imply we hold attestations we do not.

10.1 Regulatory obligations we are subject to

• Privacy Act 1988 (Cth) — we operate under the Australian Privacy Principles and the Notifiable Data Breaches scheme. Our Sub-processor Register is published. Our formal Notifiable Data Breach response plan is still being documented; the incident process in section 9 is what we operate today.
• UK and EU GDPR — alignment work is in progress. Our Data Processing Agreement is available to customers and incorporates the required processor obligations. Our data map, lawful-basis register and data subject request workflow are under construction, not yet complete.
• CCPA and CPRA — where they apply to a customer, we act as a service provider. The specific rights, the 45-day response commitment and the associated processor undertakings are set out in section 18 of our Privacy Policy and clause 15 of our Data Processing Agreement.

10.2 Certifications and controls in progress

• SOC 2 Type I readiness — internal assessment against the trust services criteria, in progress through the second half of 2026.
• SOC 2 Type II — targeted for the first half of 2027, following a continuous audit period.
• ISO 27001 — under evaluation; likely to follow SOC 2 if European enterprise demand justifies it.
• Native multi-factor authentication and SAML single sign-on — planned. Identity-provider MFA works today, as described in section 4.1.
• Independent penetration testing — planned as part of SOC 2 readiness. We do not currently commission routine third-party penetration tests, and we will say so plainly in security questionnaires.
• Formal background screening and scheduled security training — to be introduced as the team grows.
• Documented RTO and RPO targets — being formalised alongside SOC 2 readiness.

If a control you require is on this list rather than in force, tell us. Enterprise requirements shape this roadmap, and we will give you a straight answer on timing.

11. Sub-processors

We use a deliberately small number of third-party sub-processors. Each is bound by a data processing agreement requiring protection equivalent to the standards in this document.

The current list, with the purpose, data categories and hosting region for each, is published in our Sub-processor Register and mirrored in our Trust Centre. We give at least 30 days’ notice before adding or replacing a sub-processor that handles personal data. Email security@handoverhq.ai to subscribe to change notifications.

12. Responsible disclosure

If you find a vulnerability in the Service, please tell us at security@handoverhq.ai. We will acknowledge your report within 48 hours and keep you informed while we investigate.

We ask that you:

• Give us 90 days from your initial report to investigate and remediate before disclosing publicly.
• Do not access, modify or exfiltrate data belonging to other users.
• Avoid actions that degrade the Service for others, including automated scanning at volume.

We will not pursue legal action against researchers who act in good faith within these bounds.

13. Contact

Security enquiries, security questionnaires (SIG, CAIQ or your own), and requests for further detail: security@handoverhq.ai

Privacy enquiries and data subject requests: privacy@handoverhq.ai

General enquiries: enquiries@handoverhq.ai

Handover HQ Pty Ltd · ABN 34 689 167 477 · ACN 689 167 477 · handoverhq.ai