Security

What we operate today

We run an information-security program ahead of formal ISO 27001 certification (which we’re pursuing, see the Compliance roadmap). The controls below are the operating reality today, not roadmap items.

• Encryption in transit. TLS 1.2+ enforced on every public endpoint. HSTS preload on this marketing site. Certificate management handled by our hosting and database providers.
• Encryption at rest. Postgres, Storage, and database backups all encrypted with provider- managed keys.
• Row-level security (RLS). Every user- data table in our managed Postgres database has RLS policies that enforce per-user / per-family / per- organisation data isolation. Regression-tested in CI; new tables ship with RLS-on by default.
• Access control. Production-system access is role-based and named. Engineering access requires approval from the founder team; quarterly access reviews; no shared credentials.
• Secret management. Production secrets live in encrypted env-var stores managed by our hosting and database providers. No secrets in code, in commit history, or in shared docs. Annual rotation cadence for long-lived secrets.
• Vulnerability management. Automated dependency scanning on every pull request. Weekly cycle for non-critical patches; same-day for critical CVEs in hot dependency paths.
• Backup + restore. Point-in-time recovery enabled at the database provider (Postgres WAL archiving + daily snapshots). Restore tested quarterly to a clean environment.
• Audit logging. Data-mutation operations logged with actor, timestamp, action, and target. Retention: 12 months hot, 24 months cold.

Incident response

We classify incidents into four severities, each with its own response timeline:

• SEV-1 (critical): data breach exposing user data; vulnerability under active exploit; platform- wide outage. 24/7 on-call response. Initial acknowledgement target: 1 hour.
• SEV-2 (high): regional outage; partial data unavailability; high-impact bug affecting many users; vulnerability discovered but not yet exploited. Response during business hours with after-hours pager escalation. Initial acknowledgement target: 4 hours.
• SEV-3 (medium): degraded performance; bug affecting some users; non-critical security finding. Business-hours response. Initial acknowledgement target: one business day.
• SEV-4 (low): minor bug; cosmetic issue; low-impact security finding. Standard ticket queue.

Detection sources

Incidents reach our incident response process through:

• Application crash + error telemetry (paging on volume spikes and severity thresholds).
• Database-platform alerts on database health, query performance, and authentication anomalies.
• Hosting-platform deployment failure alerts and synthetic uptime monitoring on critical endpoints.
• Customer reports via hello@crescender.com.au. Every email is read same-business-day; severe reports escalate immediately.
• Responsible disclosure reports from security researchers to security@crescender.com.au. Acknowledged within 1 business day.

Breach notification timelines

As an Australian company we operate under the Privacy Act 1988’s Notifiable Data Breaches (NDB) scheme. Any eligible data breach (unauthorised access to or disclosure of personal information likely to result in serious harm) triggers statutory notification obligations.

• Initial detection to assessment complete: 24 hours.
• Notify the Office of the Australian Information Commissioner (OAIC): as soon as practicable after confirming eligibility, targeting 72 hours.
• Notify affected users: in parallel with OAIC notification or within 24 hours after.
• Containment + remediation: immediate priority during the incident; verified complete before the incident is marked resolved.
• Public post-mortem: within 14 days of incident close.

For school-tier customers, we’ll notify the school IT contact in addition to affected users, schools have their own internal communication processes to run.

Data residency

All user data is stored in Australia, on globally recognised public cloud infrastructure. Backups stay in-region. Cross-region replicas are not currently used; we’ll announce any change here 30+ days in advance. The only category of sub-processor that may transit data globally is application diagnostics (crash telemetry, no PII). Full treatment on the Sub-processors page.

Past incidents

No eligible data breaches under the NDB scheme to date. Operational incidents (outages, bugs) tracked internally; public post-mortems for significant ones land here when they happen.

Reporting a security issue

Suspect a vulnerability? Email security@crescender.com.au with details. We respond within 1 business day. We don’t currently run a bug bounty programme, but we’ll publicly acknowledge researchers who report responsibly.