Data Processing Agreement

The provider organisation decides what participant/client information is entered and why, while AlliedSpace processes that information to provide, secure, support, and improve the software.

Provider organisations remain responsible for having authority or consent to enter participant information into AlliedSpace. A signed commercial agreement or order form controls where it states different processing, billing, or support terms.

Provider organisation admins are responsible for inviting authorised staff only, assigning client access appropriately, and removing access when a team member no longer needs AlliedSpace.

AlliedSpace processes information to provide authentication, organisation and team access controls, client workspaces, appointment visibility, funding tracking, case-note and document management, alerts, activity logs, optional AI SOAP drafting, support, and monitoring.

Potential data categories include user account details, organisation and team details, client profile information, appointments, health or support-related case notes entered by users, funding records, documents, activity logs, app feedback, data request metadata, and support context.

NDIS numbers and similar government identifiers are treated as provider-entered participant reference information only. They are not used as AlliedSpace account, user, organisation, or customer identifiers.

Current controls include Supabase Auth, required authenticator MFA, a 30-minute idle sign-out, organisation-level data separation, database-level Row Level Security, role/client access controls, private document storage, safe view/download activity logs, rate limits, security headers, monitoring sanitisation, AI input sanitisation, AI output checks, and owner-reviewed data request workflows.

Higher-risk participant workflows include collection notices or authority confirmations before users create, update, import, upload, transcribe, or use participant information in optional AI drafting workflows.

AlliedSpace uses Supabase for authentication, database, and private storage. The current database region is Sydney, Australia.

Application hosting, operational logs, account and walkthrough email delivery, document backup storage, optional AI SOAP drafting, and provider contact management are provided through subprocessors documented on the Subprocessors page.

Some subprocessors may process support, operational, AI, email, or contact-list data outside Australia. Region and retention caveats are tracked in the subprocessor register.

Database backup and recovery settings are managed through Supabase project controls. Document storage recovery is handled separately through private Cloudflare R2 backups. Current recovery expectations are documented through the backup, restore-drill, and disaster-recovery runbooks.

Full database restore is treated as a severe-incident recovery path because it can affect all workspaces. Individual provider or client recovery requests are reviewed for a safer selective recovery path where practical.

Backups may retain changed or deleted records for a limited period for resilience and recovery. Backup copies are not used for routine access or support browsing.

Organisation admins can submit access/correction, organisation data export, or workspace deletion requests for owner review. Incident and breach response is documented, including evidence preservation, affected-scope assessment, provider communication, and OAIC/NDB assessment where applicable.

AlliedSpace maintains a subprocessor register covering purpose, data categories, sensitive-data exposure, region/status context, retention caveats, and rollout decisions for services used with provider or participant-related information.

Current subprocessors are published on the Subprocessors page and include Supabase, Vercel, Resend, Stripe, Cloudflare, OpenAI, and Google Sheets for the purposes described there.