Security & Sub-Processors

1. Australian Data Hosting

All core customer data — accounts, rosters, photographs and credential records — is stored and processed in Australia.

• Database, authentication and file storage: Supabase, AWS ap-southeast-2 (Sydney).
• Photo processing and wallet-pass signing: Google Cloud Run, australia-southeast1 (Sydney).

A small number of ancillary services (billing, email, wallet pass distribution, marketing analytics) operate outside Australia and handle only the minimum data needed for their function. Each is listed in section 10.

2. Encryption

• In transit: TLS 1.2 or higher on every connection. There are no plaintext endpoints.
• At rest: AES-256 for all stored data and files.
• Secrets: credentials for connected systems are held in an encrypted vault, never in application code or client bundles.

3. Organisation Data Isolation

CaptrID is multi-tenant. Every table carrying customer data is protected by database-level row-level security policies scoped to the organisation, so isolation is enforced by the database itself rather than by application code alone. Policy coverage is verified by an automated test suite that runs on every change and fails the build if a table is left unprotected.

4. Access Controls & Roles

Access is role-based, with four tiers: platform administrator, organisation administrator, coordinator, and capturer. Coordinator capabilities are configurable per organisation. Capturers can use the mobile capture app only and cannot reach the admin portal.

Administrative access to production is limited to authorised personnel, uses multi-factor authentication, and is reviewed quarterly.

5. Photo & File Security

Measure	Detail
Signed URLs	Photos are never served from permanent public links. Each URL is cryptographically signed and expires after a short period.
Organisation-scoped paths	Files are stored under organisation-specific paths, preventing cross-organisation access at the storage layer.
EXIF metadata stripping	GPS coordinates, device identifiers and other embedded metadata are removed automatically before storage.
Encrypted storage	All stored files are encrypted at rest (AES-256).
Server-side quality analysis	Each submitted photo is analysed in Australia to check image quality. This runs on our own engine — no third-party facial-recognition or vision service is used. See below.

Server-side photo processing

When a photo is submitted — whether captured in our app, uploaded, or imported — it is processed on our servers in Australia (Google Cloud Run, Sydney) to assess quality such as sharpness, lighting, resolution and framing, and, where your organisation chooses, to standardise it for printing.

This processing happens in memory. We retain the submitted photo and a quality score. We do not store facial landmarks, measurements, bounding boxes, or any face template, and this is enforced by an automated test rather than by policy alone.

Server-side face detection — whether a face is present, its size, centring and rough pose — runs only where your organisation has enabled it, and is off by default. It is never used for facial recognition, matching, verification or identification.

6. Audit Logging

Security-relevant actions are written to an immutable audit log. Records cannot be updated or deleted by ordinary users, including organisation administrators.

We deliberately do not record IP addresses or user-agent strings. Both were removed after a privacy review: neither had a use case that justified expanding the personal-data inventory.

7. Data Retention & Deletion

Organisations control how long session data — including photographs and personal records — is retained.

Retention option	Behaviour
Until export	Retained until the organisation exports it, then eligible for automatic deletion
30 / 60 / 90 days	Automatically purged after the configured period
Custom	The organisation sets a specific retention period
Indefinite	Retained until manually deleted

Retention enforcement runs daily. Organisations receive warning notifications 7 days and 1 day before data is due for automatic deletion, and a confirmation once it has been purged.

8. Individual Data Erasure

An organisation administrator can erase an individual entirely. Erasure removes the person's records and photographs across master lists and sessions, and revokes any digital wallet passes issued to them.

One boundary worth stating plainly. Where your organisation has enabled a write-back to one of its own systems — a photo pushed to your student management system, or a card number pushed to your print server — that copy sits on infrastructure you control, and our erasure cannot reach it. You will need to remove it there. We will tell you which downstream systems are affected when you raise an erasure request.

9. Authentication & Account Security

• Passwords are hashed (bcrypt) and never stored or logged in plaintext.
• A minimum length and complexity requirement is enforced, and longer passphrases are always permitted.
• Passwords are checked against known-breached credential lists at sign-up and change.
• Multi-factor authentication is available, and enforced for platform administrators.
• Password-reset and authentication endpoints are rate-limited.

10. Sub-Processors

These are the third parties we engage to deliver the service. We select them, they process customer data on our instructions, and each is bound by a data processing agreement. This is distinct from systems your organisation connects — see section 11.

11. Your Organisation's Own Connected Systems

Separately from the sub-processors above, your organisation may connect its own systems to CaptrID. These remain your services under your own agreements with those vendors. They are not our sub-processors — we do not select or instruct them, and we hold no contract with them on your behalf.

Systems we receive data from

Microsoft Entra ID, Airtable, Wonde, aXcelerate, SCIM 2.0 identity providers (such as Okta, PingOne, OneLogin or JumpCloud), and cloud storage for photo import (Microsoft OneDrive, Google Drive). Data flows into CaptrID; we disclose nothing to these systems.

Where a broker such as Wonde is used, your organisation authorises our access to your own data and can revoke it at any time.

Systems we send data to, on your instruction

Where you configure and enable it, we can write back to systems you operate:

• an approved photograph to your own student management system (such as aXcelerate);
• card numbers and the matching user identifier to your own print-management server (such as PaperCut), so issued cards work for secure print release.

Both are off by default. As noted in section 8, data written to these systems is outside our reach for erasure.

Our data processing agreement with you

The links in the table above are each provider's own data processing terms — evidence that the parties we engage are bound downstream. They are not the agreement between you and us.

We offer a customer data processing agreement covering the Article 28 / APP obligations that run from us to you: purpose and scope of processing, confidentiality, the sub-processor list and change notification above, the technical and organisational measures in sections 1–9, breach notification, and assistance with data subject requests and erasure.

It is published in full at captrid.com/dpa and is incorporated into our Terms of Service, so it applies to every customer without a separate signature. If your organisation requires a countersigned bilateral copy, or wants us to review its own DPA template, contact [email protected].

12. Changes to This Page

We will notify customer account administrators by email at least 30 days before any new sub-processor begins processing customer data, or before any material change to where data is processed, giving you a reasonable opportunity to object.

The same commitment applies to material changes to our Privacy Notice or Terms of Service: we will notify you in advance rather than relying on you noticing an updated date.

This page is the authoritative record of our current sub-processors.

13. Questions

Security or privacy questions, including due-diligence questionnaires and data processing agreements: [email protected].

Reporting a vulnerability

If you believe you have found a security vulnerability in CaptrID, please report it to [email protected]. We acknowledge within one business day (Mon–Fri, 09:00–17:00 AEST) and will keep you updated while we investigate.

Please do not access, modify or retain data belonging to any organisation or individual while testing. If you encounter customer data, stop and tell us. Our machine-readable contact details are published at /.well-known/security.txt (RFC 9116).

See also: Privacy Notice · Terms of Service · Data Deletion