Security Overview

Draft — to be reviewed by a qualified legal practitioner before publication.

Version 1.0 · Effective 25 September 2026

This overview describes the security controls that protect SiteMinutes and our customers' data. It supports our Privacy Policy and Data Processing Addendum.

Our controls are organised along the lines of ISO/IEC 27001 (Annex A) and the SOC 2 Trust Services Criteria (security, availability, confidentiality). SiteMinutes itself is not certified to ISO/IEC 27001 and has no SOC 2 report; our main infrastructure providers do (section 9). We keep this page accurate, but we do not publish every detail, so that we do not help attackers.

1. Governance and risk management

• A named person (Martin Bosman) is responsible for information security and privacy.
• We maintain written policies for security, acceptable use, data retention and incident response, and review them at least once a year and after significant changes.
• We assess security and privacy risks when we design new features (privacy by design and by default) — for example, recordings stay on the device and only a temporary copy is uploaded for transcription.
• Anyone who works on SiteMinutes is bound by confidentiality and receives these policies.

2. Asset and data management

• We keep an inventory of our systems, providers and the categories of data each holds (see the sub-processor list in the Data Processing Addendum).
• Data is classified by sensitivity; customer content and secrets receive the strongest protection.
• Retention and deletion follow the Data Retention & Deletion Policy. Temporary audio copies are deleted after the minutes are written, and in any case within 7 days.

3. Access control

• Company isolation. Every record carries the identifier of the company workspace it belongs to. Row level security in the database lets a signed-in user see and change only the records of workspaces in which they are an active member — enforced by the database itself, not only by the apps. Triggers stop a record being attached to a parent in another company, and a record's company can never change. Stored files sit in private storage buckets under the company's own folder, with the same rules.
• Least privilege. Apps and web pages cannot permanently delete project data (deletion is a reversible "soft delete"); only controlled server jobs purge data. Seats, plans and billing can only be changed by the server after a verified payment.
• No privileged keys in the web app. The web app always acts as the signed-in user, subject to row level security; privileged keys exist only inside server functions.
• Administrators. Only named platform administrators can use the admin portal. Every administrative database function checks this on each call, access can be revoked immediately, and administrator access requires a confirmed e-mail address. Administrative access to our provider accounts is protected with multi-factor authentication.
• Customers' users. Owners and admins control who is in their company and can remove users at once; invitations are bound to the invited e-mail address.
• Authentication. Passwords are stored only as salted hashes by the authentication service; sessions use secure, HTTP-only cookies and are verified with the authentication server on each request.

4. Cryptography and secrets

• In transit: all connections to the web app, the API and our providers use HTTPS/TLS.
• At rest: the database, file storage and backups are encrypted by our hosting provider (AES-256).
• Secrets: API keys for our AI providers and payment-gateway keys are stored encrypted in Supabase Vault. They are entered once, never displayed again (only the last four characters), and can be read only by server functions.

5. Operations security

• Logging and monitoring: our providers log access and errors; we review logs when investigating issues. Our own functions do not log transcripts, minutes, API keys, payment checksums or e-mail addresses.
• Change management: changes are made through version control. Database changes are applied as reviewed migrations, tested with automated database tests (for example that one company cannot read another's data), and checked with the database provider's security and performance advisors.
• Abuse protection: rate limits protect the AI help assistant, and payment callbacks are verified by signature and by a fresh query to the gateway.
• Malware and hardening: we use managed platforms that are patched by the provider, and keep our dependencies up to date.

6. Secure development

• Inputs are validated on the server; user-provided text is displayed without executing HTML.
• Standard protective headers are set (no MIME sniffing, no framing of our pages, a strict referrer policy), and the payment hand-over pages use a strict Content Security Policy.
• Database functions that run with elevated rights check the caller and use a fixed, safe search path.
• Security issues found in review or reported to us are prioritised and fixed.

7. Payments

• Card details are entered only on the payment provider's secure page (PayGate / DPO Group, PCI DSS Level 1). SiteMinutes never receives card numbers.
• Every payment result is verified with PayGate directly (signed checksum and a fresh query of the transaction) before a plan is activated; amounts, currency and references must match exactly.

8. Business continuity and availability

• Supabase takes daily backups of the database, kept for 7 days.
• Because the apps are local-first, recordings and projects remain available on your devices even if our servers are unavailable, and minutes can be requested again once service is restored.
• Our infrastructure runs in a major cloud region (Frankfurt) on providers with their own redundancy.

9. Supplier security

We choose established providers with their own security programmes and bind them with data processing terms: Supabase and Vercel (both with SOC 2 Type 2 reports), OpenAI and Anthropic (business API terms, no training on API data by default), PayGate / DPO Group (PCI DSS Level 1) and Apple. We review our providers' terms and certifications at least once a year. See the list of sub-processors in the Data Processing Addendum.

10. Incident management

We have a documented incident response process: detect, contain, investigate, fix the cause, and record what happened and what we learned. If personal information is affected, we notify affected customers without undue delay (where feasible within 48 hours) so they can meet their own obligations, and we notify regulators and individuals where we are required to (for example the Information Regulator under POPIA, or a supervisory authority within 72 hours under the GDPR, where we are the controller).

11. Compliance

We design our controls to support compliance with POPIA, the GDPR and UK GDPR, and other applicable privacy laws, and we check this page and our policies against them at least once a year.

12. What you can do

• Use a strong, unique password and keep it secret.
• Set a passcode on devices that run SiteMinutes, and keep them updated.
• Remove users from your company as soon as they leave.
• Review AI-drafted minutes before sending them.

13. Reporting a vulnerability

Please report security issues to help@siteminutes.com. Give us reasonable time to fix the issue before disclosing it, and do not access or change other customers' data. We will acknowledge your report, keep you informed, and not take action against good-faith research that follows these rules.