Security

Last updated 1 October 2026

How ShieldGuard protects the records our customers keep with us — and how to tell us about a problem you find.

1. Tenant isolation at the database level

Every workspace is a separate company record, and access is enforced by row-level policies inside the database itself — not only by the interface. A signed-in user can only ever read rows that belong to their own company, and role scoping is applied in the same place: admins see the company, managers see their own department, employees see their own trainings. We test these boundaries as part of development.

2. Encryption and file storage

Data is encrypted in transit (HTTPS/TLS) and at rest. Uploaded certificates live in private storage — there is no public URL for them. Files are served only through short-lived signed links that expire after about an hour, and only to people whose role allows them to see that record.

3. Access control

  • Roles (admin, manager, employee) decide what a person can see and change; the rules are enforced in the database, not just the UI.
  • Employees can only move their own training records, and only an admin or manager can approve a completed training.
  • Service credentials that can bypass row-level security never reach a browser: they are held server-side and used only in narrowly scoped operations.
  • Our own access to customer data is limited to what support requires, with no standing production access for routine work.

4. Application and upload security

  • Uploads are restricted by type and size, checked before storage, and stored under unguessable paths.
  • Where a scanner is configured, files are checked before they are recorded.
  • Certificate text and any AI-read dates are treated as suggestions for a human reviewer — they never change a record silently.
  • Dependencies are kept current, and security-relevant updates are applied promptly.

5. Infrastructure and sub-processors

We build on reputable providers: Supabase for the database, authentication, and file storage; Stripe for payments — card details go to Stripe directly and never touch our systems, which keeps PCI scope minimal; and Resend for transactional email. The current list, with their roles, is in our Data Processing Agreement.

6. Compliance

We handle personal data in line with the GDPR and provide a Data Processing Agreement for customers who need one. SOC 2 Type II is in progress — we are happy to complete your security questionnaire and share our current controls in the meantime.

7. Incident response

Suspected incidents are triaged as soon as they are reported or detected. Where customer data is affected, we contain the issue, then notify affected workspace admins as soon as we understand what happened and what they need to do — and we follow up with what we changed so it cannot recur. Our commitments on breach notification are in the DPA.

8. Backups and continuity

Production data is backed up by our database provider, and restores are tested as part of normal operations. Our retention commitments — including the window after a subscription ends — are described in the Privacy Policy.

9. Reporting a vulnerability

If you believe you have found a security problem, email safetytracker@xack.dev with enough detail to reproduce it. Please give us a reasonable chance to fix it before telling anyone else, do not access other customers’ data, and do not run disruptive tests — we will acknowledge your report, keep you updated, and credit you if you would like.

10. Contact

Security and privacy questions: safetytracker@xack.dev.