
GuardianHub protects your operational data, guard information, and client records with enterprise-grade security controls. Here is exactly how we do it — transparently and without marketing fluff.
This page describes GuardianHub's security controls accurately based on our current infrastructure. We do not claim certifications we do not hold. SOC 2, ISO 27001, Cyber Essentials, or SIA ACS badges are not displayed unless independently verified. Security is a shared responsibility — some controls described here are GuardianHub responsibilities, others are customer responsibilities.
Every GuardianHub customer operates in a fully isolated tenant. Data, users, and configurations are separated at the database level using PostgreSQL Row-Level Security (RLS). No customer can access another's data — not even accidentally.
All database queries pass through Supabase RLS policies that enforce tenant ownership at the row level. Even if a query is intercepted or modified, the database engine rejects unauthorised access before any data is returned.
We use Supabase Auth with secure password hashing (bcrypt), session management with refresh token rotation, and multi-factor authentication (MFA) support. Platform staff are required to use MFA/AAL2 for privileged operations.
All data in transit is encrypted using TLS 1.3. Data at rest is encrypted using AES-256 through Supabase's underlying infrastructure. File storage uses server-side encryption with unique keys per object.
Uploaded evidence, documents, and reports are stored in private Supabase Storage buckets. Public access is never enabled by default. Download URLs are time-limited and signed, expiring automatically.
Every significant action — logins, role changes, data exports, support access sessions, and configuration modifications — is recorded in an append-only audit log. Platform audit records cannot be edited or deleted through the UI.
Supabase provides continuous Point-in-Time Recovery (PITR) backups with configurable retention. Database backups are encrypted and stored redundantly across availability zones.
We maintain a documented incident response plan. Security incidents are triaged within 4 hours. Affected customers are notified without undue delay. Post-incident reviews are conducted for all confirmed incidents.
We maintain a public list of subprocessors and notify customers of changes. All subprocessors are vetted for security compliance and contractual obligations. See our Subprocessor List page for current providers.
Customer data is retained for the duration of the active subscription. Upon termination, data is held for 90 days to allow export, then securely deleted. Legal holds can extend retention where required.
All code changes pass through pull request review. Secrets are never committed to repositories. Dependencies are scanned for vulnerabilities. Production deployments require approval and are audited.
If you discover a security vulnerability, please report it to security@guardianhub.com. We commit to acknowledging reports within 48 hours and providing a timeline for resolution. We do not pursue legal action against good-faith researchers.
While GuardianHub provides the security controls listed above, customers are responsible for managing their own users, roles, and permissions. This includes enforcing strong passwords, enabling MFA for privileged accounts, reviewing access regularly, and maintaining the confidentiality of API keys and credentials issued to them.
Found a vulnerability? We want to hear from you. We practice coordinated disclosure and do not pursue legal action against good-faith researchers.
security@guardianhub.comOur team is happy to discuss our security posture, share documentation, or arrange a security review call with your team.