Security at MySafeSigns

How we protect your audit data, where it lives, and how to reach us about a security concern.

Last updated: 2026-04-28Owner: SymbioTeK Pty Ltd (ACN 694 230 334)

Overview

MySafeSigns is a mobile-first auditing tool for AS 1319-1994 safety-signage compliance. It runs in the browser. The audit data — photographs, GPS coordinates, site names, client names, auditor names, compliance findings — is stored on the auditor's device in the browser's IndexedDB. It does not leave the device unless the auditor exports a backup or invokes AI-assisted detection.

When the auditor invokes AI detection, only the captured sign photograph is transmitted to our cloud sub-processors. GPS coordinates, site/client/auditor names, notes and compliance findings are never transmitted to AI. This is the architectural property that makes MySafeSigns suitable for use at sites where location or identity information is sensitive.

Where each data class lives

Data	Location	Why
Audit photographs, GPS, site/client/auditor names, compliance findings, notes	Auditor's device (browser IndexedDB)	Default. Stays on device unless backup is exported.
Sign photograph (image only) — during AI detection	Anthropic Claude Vision API (United States), via our Supabase Edge Function proxy	Transmitted only when the auditor invokes AI detection. Other audit fields are not transmitted.
Account email, hashed password, credit balance, immutable transaction log	Supabase database — AWS Singapore (`ap-southeast-1`)	Authentication and credit tracking. No audit data stored here.
Edge Function compute (signed-webhook handler, vision-proxy, checkout)	AWS Sydney (`ap-southeast-2`)	Application logic for billing and AI proxying.
Card / payment details	Stripe Payments Australia Pty Ltd	Card data never reaches MySafeSigns servers; Stripe is PCI-DSS Level 1.

Sub-processors

The full sub-processor list, including data categories and links to each sub-processor's own compliance attestations, is at /security/sub-processors.html. We notify customers of any change with at least 30 days' notice — see the DPA template for details.

Controls in place

Stripe webhook signature verification — every Stripe webhook is verified with the platform-issued signing secret before any database write; unsigned or wrong-signature requests return HTTP 400.
Supabase Row-Level Security (forced) — every user-data table has RLS ENABLE and FORCE. Users can read only their own rows; only the server-side service role can write.
Browser security headers — HSTS (2 years, preload-eligible), Content-Security-Policy, X-Frame-Options DENY, Referrer-Policy, Permissions-Policy, X-Content-Type-Options nosniff.
Sub-resource integrity (SRI) — third-party JavaScript (Supabase SDK) is pinned to a specific version with a SHA-384 integrity hash. A compromised CDN cannot serve modified script.
Encrypted backups — exported backups can be sealed with AES-256-GCM using a passphrase; the key is derived via PBKDF2-SHA256 with 250,000 iterations.
GPS precision controls — auditors can downgrade or omit GPS coordinates in exported reports for sites where location is sensitive.
Origin allowlist — Supabase edge functions only accept cross-origin requests from MySafeSigns origins.
Fail-closed configuration — without the Stripe webhook signing secret in place, the webhook returns HTTP 500 rather than proceed unsigned.

The exhaustive list with verification steps is in the Security & Architecture White Paper. The summary above is intentionally short.

What we don't claim

We don't currently hold ISO 27001 or SOC 2 attestations. We have not been IRAP-assessed. We are a small Australian company; a sophisticated buyer should weigh that. The honest list of residual risks is in the white paper §10.

Notably:

Our AI sub-processor (Anthropic) is in the United States. Buyers with strict data-sovereignty requirements should evaluate this carefully.
The browser's IndexedDB store is not encrypted by our app. Device-level disk encryption (FileVault, iOS Data Protection, Android File-Based Encryption) is the user's responsibility.
Our hosting (Supabase database) is in AWS Singapore, not Australia. Edge function compute is in Sydney.

Reporting a security issue

If you believe you've found a security vulnerability, please email symbiotek@symbio-tek.com with:

A description of the issue and steps to reproduce.
The browser, OS, and app version (visible in the app's footer).
Whether you would like to be acknowledged in our security disclosures page.

Acknowledgement target: 1 business day.
Triage target: 5 business days for initial classification and severity.
Disclosure: Coordinated disclosure preferred. We commit to a public write-up after fix and a 30-day grace period.
Bug bounty: We do not currently run a paid bug-bounty program.

Machine-readable disclosure file: /.well-known/security.txt (RFC 9116).

For procurement teams: a Security & Architecture White Paper, a customer DPA template, the sub-processor list and a pre-filled CAIQ-Lite questionnaire are available below. Contact symbiotek@symbio-tek.com for any document not yet linked.

Documents

Document	Audience	Format
Privacy Policy	End users, regulators	HTML
Sub-processor list	Procurement, legal	HTML
Security & Architecture White Paper v1	IT security teams	Markdown
Customer DPA Template v1	Legal, contracts	Markdown (template — subject to per-customer review)
CAIQ-Lite v1 (pre-filled)	Procurement questionnaires	Markdown (CSA CAIQ v4 Lite)
Essential Eight Self-Assessment v1	ACSC-aware buyers	Markdown

Contact

General: symbiotek@symbio-tek.com
Security disclosures: symbiotek@symbio-tek.com (a dedicated security@ address is being set up; please use this in the meantime)
Mailing: SymbioTeK Pty Ltd, Australia. ACN 694 230 334.