How Chris is built and reviewed.

How is Chris built?

Cloud-native SaaS. Four-layer defence in depth. Edge (Vercel WAF and DDoS protection), Application (Next.js with server-side rendering, Zod input validation, CSRF protection, CSP headers), Database (Supabase PostgreSQL with Row Level Security on every table, SSL enforced, automated daily backups, point-in-time recovery), Authentication (Supabase Auth with bcrypt password hashing, JWT tokens, MFA via TOTP enforced for all data-access accounts).

How is data encrypted?

TLS 1.3 in transit on every connection. AES-256 at rest in the database, in backups, and in file storage. API keys and secrets stored in Vercel encrypted environment variables, never in source code. Keys rotated annually or on detection of compromise.

What integration with our systems is needed?

None during pilot. Chris runs standalone. No VPN. No on-premises components. No inbound connections to your network. Staff access via web browser and SMS links. APIs and MCP server connectors are scoped for Q3 2026 across the twelve named aged care source systems.

What data does Chris collect?

Names, work email addresses, mobile phone numbers (for SMS pulse delivery), role and team assignment, pulse survey responses (anonymous at the team level, aggregated for reporting), AI-generated coaching insights (visible to the individual leader only).

What does Chris explicitly not collect?

Financial or payroll data. Health or medical records. Government identifiers (Medicare, TFN, etc). Resident or client data. Passwords (handled entirely by the authentication provider, never seen by Chris). Biometric data.

Where is data stored?

All personally identifiable information is stored in Sydney, Australia on AWS ap-southeast-2 via Supabase. Database, authentication store, and file storage all in Sydney. Email delivery (Resend) is transient processing only with no PII stored. AI processing (Anthropic) receives aggregated team patterns only, no individual responses, no names, no contact details.

How do users authenticate?

Leaders, Org Admins, and Culture Crunch staff authenticate via email and password with MFA via TOTP enforced. Frontline team members access through single-use, time-limited SMS token links and do not hold persistent accounts or credentials.

How is access controlled?

Row Level Security policies at the database level mean each user can only access the rows authorised for their role, even if application-level checks were bypassed. Role-based access control adds a second layer at the application middleware. Four roles: Team Member, Leader, Org Admin, Culture Crunch Super Admin. Each role's data scope is documented and tested.

How are admin accounts managed?

Admin roles are distinct from standard user roles. All admin accounts have MFA enforced. Service role keys are restricted to server-side use only, following least privilege. No shared admin credentials. Each admin has their own account. Supabase audit logs capture admin actions. Admin access is reviewed quarterly.

What threat model has been assessed?

A risk assessment was completed as part of the review in February 2026. The main threat vectors identified: external attacks against web application endpoints (covered by WAF, input validation, RLS), authentication attacks such as brute force and credential stuffing (covered by MFA, rate limiting, account lockout), third-party vendor breach (covered by SOC 2 Type 2 certified vendors and minimal PII storage outside the primary database), AI model data leakage (covered by sending only aggregated, de-identified patterns to the AI engine).

What was the assigned risk rating?

MEDIUM. The reviewing provider noted explicitly that the actual risk sits below a typical MEDIUM-rated integration because of three factors: narrow data scope (names, phones, emails only), standalone architecture (no network touchpoints with the client), and SOC 2 Type 2 certified infrastructure throughout.

What threat modelling work is in progress?

A formal STRIDE threat model is scheduled for Q2 2026, alongside the first third-party penetration test. Findings from both will be shared with clients on request.

What happens if there is a security incident?

Eight-phase response framework. Detection (immediate). Triage and severity classification (under one hour). Containment (under four hours). Client notification including affected clients (within twenty-four hours of confirmed breach). OAIC notification under the Notifiable Data Breaches scheme (within seventy-two hours). Eradication (as required). Recovery (as required). Post-incident review and root cause analysis (within two weeks).

How are security events monitored?

Authentication events, API access logs, database audit logs, and application errors are captured by Supabase and Vercel. Anomaly detection runs on Supabase. Security alerts run on Vercel.

What centralised tooling is planned?

SIEM tooling and centralised logging are planned for H2 2026 as we scale beyond pilot.

How are vulnerabilities tracked?

Continuous dependency scanning via GitHub Dependabot with automated pull requests. npm audit on every build with deployment blocked on critical issues. Security-focused code review on every pull request. Static analysis via TypeScript and ESLint security rules.

What patching SLAs apply?

Critical and actively exploited: patched and deployed within four hours. High severity: within twenty-four hours. Medium: within seven days. Low: next release cycle. Vercel enables instant deployment and instant rollback, so a critical patch can move from code to production in under five minutes.

When is the first formal penetration test?

Q2 2026, with a named third-party. Coverage includes the OWASP Top 10, API endpoint security, and authentication and authorisation testing. Results will be shared with clients on request.

Who are the third-party vendors?

Vercel (hosting and edge, SOC 2 Type 2). Supabase (database, auth, storage, SOC 2 Type 2). Twilio (SMS delivery, SOC 2 Type 2 + ISO 27001 + PCI DSS). Anthropic (AI processing, SOC 2 Type 2 with zero-retention API policy). Resend (email delivery, SOC 2 Type 2 in progress, transient processing only with no PII stored).

How is vendor security verified?

SOC 2 Type 2 certification is a hard requirement for any vendor that handles data. Australian data residency required for PII storage. Data Processing Agreements in place where applicable. Breach notification obligations and data handling and deletion terms in every vendor contract.

What about Resend's in-progress SOC 2 status?

Resend handles transient email delivery only. Nothing is stored or persisted. Email bodies contain only notification text and links back to the platform, no survey responses or coaching content. If full SOC 2 Type 2 certification across all vendors is a procurement requirement, we can move to a certified alternative within pilot timelines.

What regulations does Chris comply with?

Privacy Act 1988 (Cth) compliant. All thirteen Australian Privacy Principles addressed. Notifiable Data Breaches scheme breach notification process established. Aligned with Aged Care Quality Standards, specifically Standard 7 (Human Resources) and Standard 8 (Organisational Governance). PCI-DSS, HIPAA, and GDPR are not applicable (no payment card data, no US health data, no EU data subjects anticipated).

How is data retained and disposed of?

Pulse responses retained for the duration of the contract plus twelve months. User accounts retained for the contract plus thirty days, then deleted and anonymised. Audit and access logs retained for twelve months. Database backups rolling seven days. Secure deletion on contract end with deletion confirmation provided on request.

How are user rights handled?

Privacy policy published at culturecrunch.io. Data collection notice provided at account creation. Access requests honoured. Deletion requests processed within thirty days.

What are the recovery objectives?

Application compromise: redeploy from Git in under five minutes, zero data loss. Database breach or corruption: restore from backup or point-in-time recovery in under one hour, data loss bounded by twenty-four hours at worst (minutes via PITR). Credential compromise: rotate keys and redeploy in under one hour, zero data loss. Complete infrastructure loss: redeploy to new provider and restore from database backup in under four hours.

How is the recovery plan tested?

Database restore test scheduled for 28 February 2026. Redeployment is tested regularly through normal release cycles. Formal Business Continuity Plan document targeted for completion 31 March 2026.

What backup coverage is in place?

Daily automated database backups with seven-day rolling retention. Continuous WAL-based point-in-time recovery with seven-day window. Application code in Git version control, indefinite retention. Configuration in Vercel environment snapshots, indefinite retention.