Security
Last updated: 9 June 2026
Rosteryholds health information about people with disability and older Australians: progress notes, medications, incidents, and the details of the workers who support them. This page describes the controls that protect it. Everything below is implemented, not planned — where something is on the roadmap it says so.
1. Tenant isolation
Every organisation’s data is separated at the database level, not in application code. Each table carrying organisation data has PostgreSQL Row Level Security with FORCE enabled and a policy that restricts every read and write to the organisation in the current session. The application connects as a non-superuser role, so it cannot bypass those policies even if a query were written incorrectly.
A check runs at every start-up and applies the policy to any table that has organisation data but no policy, so a new feature cannot ship without isolation by omission. All 238 such tables are covered.
2. Encryption
- In transit. TLS 1.2 and 1.3 only. TLS 1.0 and 1.1 are refused. HSTS is set for one year including subdomains, with preload.
- At rest. Particularly sensitive fields — tax file numbers, bank account details and progress-note content — are encrypted at the application layer with AES-256, separately from the database.
- Backups. Every database backup is encrypted with AES-256 before it is written to disk, and each one is verified by decrypting it and checking the archive.
3. Access control
- Roles built from individual permissions, not fixed tiers, and enforced server-side at the API. Hiding a menu item is not a permission.
- Two-factor authentication (TOTP) available on all accounts.
- Account lockout after repeated failed logins, with per-endpoint rate limiting on login, MFA and password reset.
- Revocable sessions. Tokens carry an identifier that can be blacklisted, and changing a password invalidates every session issued before it.
- Breached-password checking. New passwords are checked against the Have I Been Pwned corpus using the k-anonymity API — only the first five characters of a hash leave our server, never the password.
- No back door. Staff at Notion Tech Pty Ltd cannot view customer data from the platform. Administrative impersonation is disabled in the product.
4. Application security
- All database access uses parameterised queries.
- Input is validated server-side on every endpoint.
- Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy and Cross-Origin isolation headers are served on every response.
- File uploads are type- and size-restricted, stored outside the web root, and served only to an authenticated user whose organisation owns the file.
- Authentication uses bearer tokens rather than cookies, which removes cross-site request forgery as a class.
5. Payment controls
For plan managers who pay providers, a change to a provider’s bank details places that provider’s invoices on hold until the new account is verified, and the verification — who was called, on which number, from which source — is recorded. Payment release can require a different user from the one who entered the invoices, and can require a second factor.
6. Infrastructure
- Hosted in Sydney, Australia. Customer data does not leave the country except through the optional integrations named in our sub-processor list.
- The database is not reachable from the internet; it listens only on the local interface.
- A host firewall exposes only HTTP, HTTPS and SSH.
- SSH accepts keys only — password authentication is disabled — with post-quantum key exchange preferred.
- Automatic security updates are applied to the operating system.
- Intrusion prevention bans hosts that repeatedly fail authentication against SSH or the application.
7. Monitoring
- Authentication events, administrative actions and record access are written to audit logs retained with the account.
- File-integrity monitoring watches the files an intruder would need to change — authorised keys, SSH and web server configuration, sudoers — and alerts on any change.
- Service health, certificate expiry, disk capacity and backup freshness are checked continuously.
8. Backups and recovery
The database is backed up nightly. Each backup is encrypted, verified by decryption, checksummed, and retained for 30 days. Restores are tested rather than assumed.
9. Breach response
We are subject to the Notifiable Data Breaches scheme under Part IIIC of the Privacy Act 1988 (Cth). If we suspect an eligible data breach we assess it within 30 days, and where it is likely to result in serious harm we notify both the Office of the Australian Information Commissioner and the affected individuals as soon as practicable. Customers are notified without undue delay so they can meet their own obligations.
10. On the roadmap
Stated plainly rather than implied: an edge web application firewall and DDoS protection, off-site immutable backup replication, independent penetration testing, and ISO/IEC 27001 certification. We do not currently hold ISO 27001 or SOC 2 certification, and we would rather say so than let a badge imply otherwise.
11. Reporting a vulnerability
Email [email protected] with the details, or call +61 468 447 062 if it is being actively exploited. We will acknowledge within 2 business days. We do not pursue legal action against researchers who investigate in good faith, avoid privacy violations and data destruction, and give us reasonable time to fix an issue before disclosing it.
Security and compliance questions
The questions that come up during vendor assessment, answered directly.
How does Rostery keep each organisation data separate?
Every organisation data is isolated at the database level using PostgreSQL row-level security, forced on every table that carries an organisation id, so a query cannot return another provider records even if application code asks for them. Rostery own administrators cannot read tenant data, and impersonation is permanently disabled.
Is my data safe? Where is it stored?
Participant data is hosted in Australia and never moved offshore. It is encrypted with AES-256 at rest and TLS 1.2 or higher in transit, with older protocols refused. Particularly sensitive fields — tax file numbers, bank details and progress-note content — are encrypted at the application layer with a separate key, so they are not readable from the database alone. Every organisation is isolated at the database level using PostgreSQL row-level security with FORCE, so a query cannot return another provider's records even if application code asks for them. Audit logs are tamper-evident and retained, two-factor authentication is available on every account, and backups are encrypted, checksummed and verified by restoring them. We do not currently hold ISO 27001 or SOC 2 certification — our controls are mapped to those standards and we would rather say so than let a badge imply otherwise. Full control documentation is available under NDA.
Is participant data stored in Australia?
Rostery runs on Australian infrastructure and participant data stays within Australia. Backups are encrypted, checksummed and verified, connections use TLS 1.2 or higher with older protocols disabled, and new passwords are checked against known breach corpora before they can be set.
Does Rostery support multi-factor authentication?
Yes. Multi-factor authentication is available on every plan, and sessions are revoked immediately when a password changes rather than lasting until they expire. Administrators can also require a second factor before a payment batch is released.
Is Rostery NDIS Commission compliant?
Yes. Rostery is designed specifically for registered NDIS providers. It supports: PACE and legacy PRODA billing formats, all four NDIS funding types (agency, plan-managed, self-managed, and direct billing), NDIS Practice Standards documentation, incident reportability and Commission notification requirements, EVV for proof of service delivery, restrictive practices authorisation records, and worker screening clearance tracking. Our compliance team monitors NDIS Commission policy changes and updates the platform within 30 days of any regulatory change.
Is Rostery built for the NDIS price guide?
Yes. Rostery ships with the official NDIS Support Catalogue for 2025-26 loaded as the default price book, and every plan includes it. Line items are matched to support item numbers automatically when an invoice is read, and anything priced above the cap is flagged before it can be claimed.
Does Rostery support Support at Home and aged care?
Yes, through the Aged Care add-on at $349 per month. It covers Support at Home budgets, client contributions, statements, claiming, SIRS incident reporting and DEX reporting, running alongside NDIS service delivery in the same system rather than as a separate product.
Can Rostery generate NDIA claim files?
Yes. Rostery produces the NDIS bulk payment request file from approved invoices, validating each line against the price book and the participant remaining budget first, and records every claim result. Payments can be reconciled from a remittance file or recorded by hand when the file cannot be read.