Security at Keel

Keel is a risk management platform for Australian businesses. We help organisations build risk appetite statements, identify and assess risks, and maintain ongoing risk governance.

Our platform handles organisational data including business profiles, risk assessments, governance structures, team member accounts, and AI-generated risk analysis. We take the security of this data seriously, and this page describes how.

This is a self-assessment. We have not yet undergone formal third-party security certification (such as SOC 2 or ISO 27001). Where our assessment is incomplete, we say so. We intend to update this page as our security posture evolves.

Keel voluntarily complies with the Australian Privacy Principles regardless of whether the small-business exemption applies. We do not sell customer information, and we do not use customer business data to train machine-learning models. Keel is designed for use by adults in a business context.

Hosting and data residency: Keel's frontend is hosted on Netlify's global CDN. Our database, authentication, edge functions, and file storage run on Supabase in the Sydney region (AWS ap-southeast-2). All production customer data - organisation profiles, risk assessments, user accounts - resides in Australia.

Environment separation: Keel maintains separate environments — such as development, staging, and production — each with its own Supabase project, database, authentication configuration, secrets, and edge function deployments. No data is shared between environments. Production is the only environment that contains customer data; non-production environments use synthetic or seed data only.

Shared responsibility: Supabase manages infrastructure security, database engine patching, physical security, network-level DDoS protection, TLS termination, and backup infrastructure. Keel manages application-level access control (row-level security on every database table), edge function security, API key management, data model design, third-party integration security, and monitoring.

Third-party data flow: Four services receive data outside Australia in the normal course of operation. OpenAI (US) processes AI prompts containing organisation context for risk analysis, document generation, and question assistance. Google AI (US) is available as a fallback AI provider. Resend (US) processes transactional email addresses and notification content. Cloudflare (US) provides invisible CAPTCHA/bot protection on authentication forms, receiving technical signals such as IP address and browser characteristics — no account or accounting data.

We'll add detailed per-framework findings as each assessment is completed. Our current priority is NIST 800-53 control coverage.

User authentication is handled by Supabase Auth, running in the Sydney region. Users sign in with a password and a second factor: a one-time code from an authenticator app (TOTP-based multi-factor authentication). MFA is required for every user to reach their data, not just administrators. Passwords are never stored in plain text — they are salted and hashed by our authentication provider (Supabase Auth). Password reset is self-serve via a verified-email link. Sessions use JWT tokens with configurable expiry. Auth errors force re-authentication.

Authentication uses the PKCE flow — access tokens are never carried in browser URLs or history.

Multi-factor authentication (TOTP) is enforced for all users. Administrators are additionally subject to stricter re-verification. Destructive admin actions require fresh TOTP verification with a single-use, time-limited token bound to the specific action. MFA is also required by policy for tech team members accessing infrastructure platforms.

Idle session timeouts are enforced for all users, with a shorter window for platform administrators.

Users can review and revoke their own active sessions. Platform administrators can revoke any user session, with real-time enforcement — a terminated session is evicted from the browser within seconds rather than waiting for the next token refresh.

Data isolation between organisations uses PostgreSQL Row Level Security (RLS). Row-level security is enabled on every database table, audited in February 2026 and re-audited in April 2026, and verified by automated multi-tenant isolation tests on every change. Each table containing organisation data has policies that filter by the authenticated user's organisation membership. One customer cannot access another customer's data through the application or the API.

Role-based access provides multiple permission tiers within each organisation, with editors and viewers limited to their scope of work. A separate platform administrator role exists for Keel staff and is governed by stronger controls (MFA, rate limits, single-use tokens for destructive actions). Permissions are enforced at the database layer (RLS), the edge function layer (centralised auth helpers), and the application layer (role-based hooks).

Admin functions are rate-limited. Infrastructure access requires both MFA and VPN by policy.

All data in transit is encrypted using TLS. Supabase manages TLS certificates for API, database, and realtime connections; Netlify provides TLS for the frontend. All data at rest is encrypted using AES-256 in the Sydney region (verified against Supabase's published trust page).

Sensitive credentials (such as Xero OAuth tokens) are stored in Supabase Vault via server-side RPCs. API keys and service role keys are stored as edge function environment variables and are not exposed to the client.

Customer data is retained according to a documented retention policy, enforced by an automated nightly purge of time-bounded data such as logs and pre-registration records. When an organisation is deleted, customer data is hard-deleted across the database and all private storage buckets in the same operation. A separate cross-border disclosure assessment documents which sub-processors receive data and what residual data remains in vendor systems after deletion.

User credentials, passwords, email addresses, authentication tokens, and accounting data are never sent.

All AI requests are authenticated and authorised at the edge function layer before any data is sent to the provider. Prompts are constructed server-side - users cannot inject arbitrary prompt content. All AI features have fallback behaviour when the API is unavailable, and users can always proceed without accepting AI suggestions.

OpenAI operates under Zero Data Retention, so prompts and responses are not retained after the request completes. Google AI is used on the paid tier and does not use prompts or responses to improve its products. We have a Data Processing Agreement in place with Supabase, our primary infrastructure provider.

A complete and current list of our sub-processors, the data each receives and where it is held, is maintained in our Privacy Policy at meetkeel.com/privacy. Sub-processors and connected services are covered under separate sub-headings within Section 4 of that policy.

Connected Systems

Keel allows organisation administrators to connect third-party services — such as task management, collaboration, and general ledger systems such as Xero — directly from within the platform. These are distinct from the sub-processors listed above. Connected services are operated by the organisation under its own agreements with those providers.

Data may flow outbound (Keel pushing actions, tasks, or notifications to the connected service), inbound (the connected service sending data into Keel), or both, depending on the integration and how the administrator has configured it.

Data in transit between Keel and a connected service is encrypted and handled using the same security measures that apply across the rest of the platform. Once data is transmitted to a connected service at the administrator's instruction, it is held by that service under its own security and privacy practices. Data received by Keel from a connected service is then held and protected under Keel's privacy policy.

A current list of available integrations is accessible in the platform's integration settings. Organisation administrators can review, configure, and revoke connections at any time.

Keel is built with React and TypeScript on the frontend, with Supabase Edge Functions (Deno) on the backend. We assess our application security posture against the OWASP Top 10.

Edge functions enforce authentication and authorisation checks before processing requests, using centralised auth helpers. Cross-origin resource sharing (CORS) is configured with per-environment origin allowlists - responses are restricted to explicitly configured domains rather than using a wildcard. Content Security Policy headers are enforced in production. The application also sets a bundle of defence-in-depth response headers covering frame embedding, MIME sniffing, referrer leakage, browser sensor APIs, and HTTP Strict Transport Security with preload.

Outbound email from Keel's domains is authenticated with SPF and DKIM to prevent spoofing, and DMARC monitoring is in place with enforcement being progressively rolled out.

A dedicated URL validation module protects against server-side request forgery (SSRF). It enforces protocol allowlists (HTTP/HTTPS only), blocks private IP ranges and cloud metadata endpoints, detects URL-encoded bypass attempts, and validates hostnames. All user-provided URLs are validated before outbound requests are made.

Input validation is handled by a shared validation module providing UUID validation, HTML escaping, string length limits, and email format checks. Unauthenticated endpoints have additional hardening (rate limiting, payload size limits, field validation).

Sign-up and sign-in are protected by an invisible CAPTCHA (Cloudflare Turnstile) to mitigate automated abuse and credential attacks.

AI features include defensive prompt construction to reduce indirect prompt injection from third-party content, and the prompt-injection attack surface is reviewed on an annual cadence.

Frontend dependencies are monitored by GitHub Dependabot (weekly scans). An automated security scanner (OWASP ZAP) runs weekly against the staging environment, checking for common vulnerability patterns including injection, cross-site scripting, header misconfigurations, and cookie security.

The application is covered by automated unit tests, database security tests (verifying row-level security policies against a real database), end-to-end browser tests, continuous dependency vulnerability scanning, and weekly automated security scanning.

A detailed OWASP Top 10 self-assessment will be published when complete.

Keel maintains an incident response process covering detection, containment, notification, and recovery. In the event of a security incident affecting customer data, we follow the Notifiable Data Breaches scheme under the Privacy Act 1988. Where we identify an eligible data breach likely to result in serious harm, we will notify the Office of the Australian Information Commissioner and affected individuals as required by Part IIIA — OAIC notification within 30 days of becoming aware, and individual notification as soon as practicable.

Detection is automated through threshold-based alerts on authentication rejections and edge function error rates, with admin-side dashboards for review. Containment actions — disabling accounts, terminating sessions, rotating credentials — are documented per scenario in an internal incident response plan and exercised against the platform's threat model.

If you've found a security vulnerability in Keel, we'd like to hear about it. Our responsible disclosure policy describes how to report it, what's in scope, and what to expect from us. We'll acknowledge reports within 3 business days. If you follow the policy, we consider your research authorised and will not pursue legal action.

Security issues can be reported to security@meetkeel.com.

The production database is backed up daily and retained for seven days in the Sydney region. Recovery is performed by restoring the most recent daily backup (recovery point objective: up to 24 hours). Backup restoration is periodically rehearsed. The frontend is stateless and can be redeployed from source.

In addition to the primary daily backups, critical financial records and the application source code are replicated to independent, tamper-resistant (write-once) off-site storage in a second Australian location, so they survive loss of the primary platform.

Recovery procedures are coordinated with the incident response plan so that a service outage and a security incident can be handled by the same on-call process.

We're actively investing in the following areas:

• Stronger authentication options for end users
• Working toward SOC 2 Type II readiness as our customer base grows

Contact security@meetkeel.com for any questions about these policies.