Cybersecurity at GuardAssist
This page is maintained by the GuardAssist team to explain, in plain English, the controls currently in place to protect the application and the small amount of data it processes. It is a factual description of measures we operate — it is not an independent certification, audit or accreditation.
Last reviewed: 12 July 2026
Transport security
All traffic to and from GuardAssist is served exclusively over HTTPS (TLS 1.2+) with modern cipher suites. HTTP requests are automatically upgraded.
The service is delivered through a global edge network with DDoS protection and automatic certificate renewal.
Data storage & encryption at rest
Application data is stored in a managed Postgres database hosted within the EU. Storage volumes and automated backups are encrypted at rest using AES-256.
Backups are retained by the managed platform on a rolling basis and are not exposed to the public internet.
Secrets & keys
API keys, service credentials and signing secrets are stored as environment secrets in the hosting platform and are never committed to source control or exposed to the browser.
Only publishable client keys — designed by the platform to be safe in the browser — appear in front-end code, and are additionally constrained by row-level security in the database.
Access control
The administrator area at /admin is protected by a shared password, an encrypted server-side session cookie (HTTP-only, Secure, SameSite=Lax) and a time-limited 8-hour session.
Password comparison is performed server-side using a constant-time hash comparison to mitigate timing attacks. The admin password is never sent to, stored in, or readable by the browser.
Database access from the app enforces row-level security (RLS) policies, so users can only read or write rows they are entitled to.
Application architecture
GuardAssist runs on a modern serverless edge runtime. Privileged operations (admin metrics, administrative reads) execute on the server only; the browser receives just the finished result, never service-role credentials.
Public API endpoints validate inputs with strict schemas before touching the database.
Data we collect
GuardAssist is designed to hold as little personal data as possible. The application processes:
- Anonymous page-view analytics (path, referrer, coarse user-agent, browser-generated session id) used only for aggregate site metrics.
- Optional user-submitted content (feedback, incident notes) when a user chooses to submit it.
We do not sell data, we do not run third-party advertising trackers, and we do not build behavioural profiles.
Patching & dependencies
Third-party libraries are kept current and reviewed for known vulnerabilities. Security-relevant updates are applied promptly through routine deployments.
The underlying platform (runtime, database, edge network) is patched and maintained by the hosting provider.
Reporting a vulnerability
If you believe you have found a security issue in GuardAssist, please report it responsibly via the feedback form and mark it as a security concern. Please avoid publicly disclosing details until we have had a reasonable opportunity to investigate and respond.
We will acknowledge legitimate reports and work to remediate confirmed issues as a priority.
Shared responsibility
GuardAssist provides the technical controls described above. Company policy, assignment instructions, client requirements and the individual user's own device security (screen lock, up-to-date OS, avoiding untrusted networks) remain the responsibility of the employing organisation and the user. GuardAssist is a decision-support resource and does not replace formal information security policies or professional judgement.
This statement reflects controls in place at the time of last review and may be updated as the platform evolves. It is not a warranty, certification or legal representation.