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 are hashed with Argon2id; session, activation, and API-key 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 | In progress. We are building toward a SOC 2 examination; a report is not yet available. |
|---|---|
| ISO/IEC 27001 | In progress. We are working toward certification of our information security management system. |
| GDPR & UK GDPR | Designed to align with GDPR/UK GDPR through data minimisation and a published DPA. |
[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; SHA-256 for session, activation, and API-key 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: [TO BE CONFIRMED] — depends on the database/hosting used in production.
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: [TO BE CONFIRMED] (least-privilege, production access policy).
6. Infrastructure & operations
Hosting provider, network controls (WAF/DDoS), logging and monitoring are deployment-dependent and should be documented here: [TO BE CONFIRMED]. The platform maintains an append-only audit trail of administrative and key actions.
7. Secure development
Practices such as code review, dependency scanning, and third-party penetration testing: [TO BE CONFIRMED] — describe what you currently do 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 [TO BE CONFIRMED] (formalise the runbook and timeline).
10. Report a vulnerability
We welcome responsible disclosure. Email [TO BE CONFIRMED] (security contact) with details and we will acknowledge promptly. Please do not access or modify data that is not yours.