Security & trust

Built as if the record will be examined, because it will be

If something goes wrong at your event, your incident log stops being an operational tool and becomes evidence. SYNQE is engineered for that moment: a record that can be proven un-altered, access that can be proven appropriate, and data that can be proven separate.

Where your data lives

The questionnaire answers, up front

What a procurement or insurance review asks first, including the rows where the answer is "not yet".

Security and data-handling status
Item	Status	Detail
Operational data stored in AustraliaApplication and database on Google Cloud, Sydney (australia-southeast1). Incident records, jobs, logs, rosters and health information stay there.	Yes	Application and database on Google Cloud, Sydney (australia-southeast1). Incident records, jobs, logs, rosters and health information stay there.
Media stored in-regionPhotos, video, documents and site plans on Cloudflare R2, Oceania jurisdiction.	Yes	Photos, video, documents and site plans on Cloudflare R2, Oceania jurisdiction.
Encryption in transitEvery connection, including media, which is served through short-lived signed links.	Yes	Every connection, including media, which is served through short-lived signed links.
Penetration testingAt each development milestone. All critical and high findings remediated.	Yes	At each development milestone. All critical and high findings remediated.
Breach notificationTo affected customers without undue delay, and within 72 hours of us becoming aware (Terms §11.6).	Yes	To affected customers without undue delay, and within 72 hours of us becoming aware (Terms §11.6).
Data Processing AddendumStandard DPA available on request, executed where required (Terms §11.1).	Yes	Standard DPA available on request, executed where required (Terms §11.1).
ISO 27001 or SOC 2 certificationNeither is held. The controls on this page are real but not independently certified.	Not yet	Neither is held. The controls on this page are real but not independently certified.
Contractual uptime SLAThe standard Terms carry no uptime commitment. Ask if your procurement needs one.	Not yet	The standard Terms carry no uptime commitment. Ask if your procurement needs one.
Single sign-on (SSO)Accounts use SYNQE's own sign-in, with rate limiting and password-reuse prevention.	Not yet	Accounts use SYNQE's own sign-in, with rate limiting and password-reuse prevention.

Providers outside Australia

None of these receives your incident records. Each gets only what its job needs.

StripePayment processing · United States and other regions
ResendService, account and security email · United States
CARTOMap imagery · European Union
Browser push servicesPush notification delivery · Various
TwilioWhatsApp delivery, only if you enable it · United States
what3wordsThree-word addresses, only if you enable it · United Kingdom

One point of precision: stored in Australia isn't the same as beyond the reach of any foreign law. Google Cloud is a United States company, and data in its Australian region may in limited circumstances be subject to lawful access requests under laws that apply to it. Full detail is in the Privacy Policy.

Tamper-evident audit trail

If anyone alters the record, it shows

Every significant action is written to an append-only audit trail and cryptographically hash-chained: each entry includes a fingerprint of the entry before it. Change one historical record and every fingerprint after it stops matching.

How the chain holds

#0412

Job status changed → in_progress

prev: 9f2c…a1 · hash: 4d7e…b3

↓ links to

#0413

Media attached to job

prev: 4d7e…b3 · hash: c018…7f

Editing #0412 after the fact would change its hash, and #0413's recorded prev would no longer match. The break is detectable, and its position in the timeline is identifiable.

Append-only, actor-attributed

Entries are never edited or deleted in place. Every one records who acted, what changed, and when, in UTC, rendered in each viewer's local timezone.

Corrections are visible, not silent

Amendments, merges and soft-deletes are recorded as new events on top of the original. The first version of what someone logged at 22:47 remains readable.

Exports carry the proof

Evidence packs export as JSON, CSV and a formatted HTML record, with the chain intact, so a third party can verify integrity without access to the platform.

Audit trail, from the productOpen full size

SYNQE's Audit Logs & Chain of Custody screen, showing a live, hash-verified event feed with JSON, CSV and Export Report actions

Role-based access control

Six tiers, plus visibility rules on top

Access is granted by capability tier, then narrowed by department. A medical volunteer sees what medical needs to see; a client rep sees the picture and changes nothing.

TierCapability

Tier 1View-only: sees the operating picture, changes nothing. Never billable.

Tiers 2–5Graduated operational capability: from field logging, through job dispatch and assignment, up to event management and configuration.

Tier 6Org Admin: full control of the organisation, its events, users and settings.

All tiersDepartment-level visibility controls: scope what each user can see by the team they belong to.

ClearanceRestricted commander clearance for sensitive incidents, held separately from tier, so seniority alone doesn't grant it.

Exact per-tier capability names are documented in the platform admin guide and provided during onboarding.

Multi-tenancy

Separation by structure, not by policy

This matters most when you're a security firm working three competing promoters, or a venue hosting rival agencies in the same week.

Enforced at the database level

Tenant isolation is applied in the data layer, not left to application code to remember. A query that forgets to scope itself returns nothing, rather than someone else's incidents.

Your events, your history

Events, jobs, logs, media, users and configuration all belong to one organisation. Nothing is shared or pooled across tenants, including uploaded floor plans and location presets.

Media behind signed URLs

Photos and footage are served through short-lived signed links, not guessable public paths. A leaked URL expires; it doesn't become a permanent hole.

Our access to your data

What we can see, and how you'd know

Most vendors don't publish this. We think you should be able to read it before you sign anything.

Break-glass access

Support staff cannot browse into your organisation at will. Emergency access is explicit, time-boxed, and expires on its own. It is logged twice: on our platform audit trail and inside your organisation's own, where your admins can see it.

Analytics are aggregate-only

Platform usage reporting reads counts, byte totals and timestamps (active users, storage used, job and log volume). Never row-level content: no log text, job titles, names, locations or media. The restriction is enforced by an allowlist test on the query shape, not by convention.

Every read is attributed

Cross-organisation reads are audited and tied to a named actor. "The platform team" is never the answer to who looked at something.

Known residual: disclosed deliberately

Map tiles are still fetched from public tile servers. A tile provider can therefore observe an operator's IP address and the area of the map they are viewing. Tile requests carry no incident data, job content or user identity. We disclose this rather than describe our asset self-hosting as total.

Reviewing SYNQE for a procurement or insurance requirement?

Send us your security questionnaire. We'll complete it, and we'll tell you plainly where the answer is "not yet" rather than dressing it up.

Send us your questionnaire Explore features