Security Overview
How Guardivion protects your organisation and users with a device-based authentication architecture.
1. Our security model
Guardivion is built on a device-based authentication model. In the Guardivion mobile app, each user authenticates with an ECDSA P-256 key pair generated inside the device's hardware-backed keystore (e.g. Android Keystore / StrongBox), unlocked by the device's biometric or credential. The private key never leaves the device and is never transmitted to Guardivion — we hold only the public key. Authentication requests are delivered by push notification and approved on the device.
2. Administrator authentication
Access to the web portals uses an email and password plus a time-based one-time passcode (TOTP) for MFA. Passwords and API keys are hashed with Argon2id; session and activation values are stored only as SHA-256 hashes. Key management and org-lifecycle actions are restricted to owner-role accounts.
3. Compliance status
| SOC 2 | Not yet certified. Built with SOC 2 principles in mind; a report is not yet available. |
|---|---|
| ISO/IEC 27001 | Not yet certified. Our information security management practices are designed with ISO/IEC 27001 in mind. |
| GDPR & UK GDPR | Designed to align with GDPR/UK GDPR through data minimisation and a published DPA (available on request — contact@guardivion.com). |
| PSD2 SCA (EU/UK) | Designed with PSD2 SCA principles in mind: hardware-backed possession element with challenge signing and audit logging. Login supported today; payment approval with dynamic linking planned. SCA obligations remain with the payment service provider. |
[TO BE CONFIRMED] target dates and the auditor / certification body, once engaged.
4. Data protection
- Encryption in transit: HTTPS/TLS; HSTS can be enabled per deployment.
- Credential storage: Argon2id for passwords and API keys; SHA-256 for session and activation values — no reusable secrets in plaintext.
- Key isolation: end-user private keys remain in the device hardware keystore; Guardivion stores only public keys.
- Data minimisation: no biometric templates and no end-user passwords; minimal device metadata.
- Encryption at rest: production data is stored in Railway-managed PostgreSQL in Railway's EU region. All data is encrypted at rest at the storage level, covered by Railway's SOC 2 Type II-audited controls (see the Railway Trust Center).
5. Access control
- Administrator MFA (password + TOTP) on the portals.
- Owner-role restriction on key management and org-lifecycle operations.
- Per-organisation tenant isolation so one organisation's data is scoped away from another.
- Internal / staff access controls: production access is limited to the founder. Hosting (Railway) and Firebase consoles are accessed via Google sign-in protected by 2-Step Verification. A formal least-privilege access policy will be published as the team grows.
6. Infrastructure & operations
The platform runs on Railway (PaaS; SOC 2 Type II and SOC 3 certified), with all application services, PostgreSQL, and Redis deployed in Railway's EU region. TLS terminates at Railway's edge; every service additionally enforces HSTS, a Content-Security-Policy, X-Content-Type-Options: nosniff, and X-Frame-Options: DENY. Tenant isolation is enforced with PostgreSQL row-level security scoped per organisation, and the internal administration service has no public domain — it is reachable only over Railway's private network. The platform maintains an append-only audit trail of administrative and key actions.
7. Secure development
Dependency vulnerability scanning (pip-audit) runs in every deployment build and fails the build on known CVEs. Code review and third-party penetration testing: [TO BE CONFIRMED] — describe current practice before publishing.
8. Resilience & continuity
Backup cadence, restore testing, and disaster-recovery targets (RPO/RTO): [TO BE CONFIRMED]. A public status page is [TO BE CONFIRMED] (not yet live).
9. Incident response
A documented incident-response process governs detection, triage, containment, and recovery. Customers affected by a personal data breach are notified without undue delay, consistent with our DPA (available on request — contact@guardivion.com) [TO BE CONFIRMED] (formalise the runbook and timeline).
10. Report a vulnerability
We welcome responsible disclosure. Email contact@guardivion.com with details and we will acknowledge promptly. Please do not access or modify data that is not yours.