Security, Privacy & AI Governance — for Procurement
A single, evidence-based view of Housing Match's security controls, privacy framework, AI governance and compliance alignment. Every statement is supported by an implemented artefact; platform-managed controls are marked as attestation-pending. Designed to be shared during enterprise due diligence.
Security Overview
Defence-in-depth, evidence-based
Housing Match protects participant and provider information through layered controls: mandatory TOTP MFA for administrators, role-based access with provider-organisation scoping, private document storage with short-lived signed URLs, immutable audit logging, consent-gated access, and Australian SSE-S3 storage for clinical documents (SSE-KMS planned).
Security Controls
Key controls and their evidence
| Control | Evidence |
|---|---|
| TOTP MFA | MfaEnrollment entity (AES-GCM secret, replay counter, lockout); mfa* functions; MfaGate UI |
| Step-up auth | MfaSession.step_up_expires_at (~15m); HMAC-signed; mfaCheckGuard |
| Role-based access | ProviderProfile.organisation_admin_ids; setOrganisationAdmins; providerDataScope.js |
| Participant Row-Level Security | Participant.jsonc RLS policy — 6 read branches (admin / user_id / managed_by_user_id / created_by_id / consent_to_share / matching_consent); 34 backend functions use asServiceRole with own authz matrix; validated Aug 2026 |
| Immutable audit | AuditLog entity (28 action types); recordAuditEvent; queryAuditLog |
| Consent ledger | ConsentEvent append-only; recordConsentEvent; getConsentHistory |
| AU document storage | AustralianDocument (S3 ap-southeast-2, SSE-S3; SSE-KMS planned); presigned URLs only |
| Security headers | index.html: CSP, X-Content-Type-Options, X-Frame-Options, Referrer-Policy |
| AI de-identification | deidentifyForAI; ai_excluded flags; AustralianDocument.ai_excluded = true |
Authentication & MFA
Account protection
- TOTP MFA is mandatory for platform administrators and organisation administrators
- TOTP secrets encrypted at rest with AES-GCM; recovery codes stored as SHA-256 hashes
- TOTP replay protection via last_totp_counter; progressive lockout on failed attempts
- 15-minute step-up authentication window for highly-sensitive actions
- MFA sessions are HMAC-SHA256 signed; client-created or tampered sessions are rejected
- Registration requires OTP verification before a session is established
- Password reset requests return a generic success (no account enumeration)
Encryption
In transit and at rest
Application layer (verified): AES-GCM for TOTP secrets · SHA-256 for recovery codes · HMAC-SHA256 for MFA sessions · AWS SSE-S3 for Australian-stored clinical documents (SSE-KMS planned) · SHA-256 upload integrity hashes.
Transport layer: TLS for all connections (platform-managed). HSTS is enforced via the Content-Security-Policy upgrade-insecure-requests directive; a standalone Strict-Transport-Security header requires platform configuration.
Attestation pending: Database at-rest encryption and key management are platform-managed; confirmation requested from Base44.
Audit Logging
Who did what, when, and why
An immutable, append-only AuditLog records 28 action types with actor, role, organisation, purpose, IP and timestamp, including a deidentified flag for AI invocations. Consent is recorded in a separate append-only ConsentEvent ledger. Financial actions are recorded in RentalAuditLog.
Audit logs are written exclusively by server-side functions; application code cannot update or delete audit rows.
Backup & Recovery
Platform-managed
Backups are managed by the Base44 platform. A platform attestation confirming backup frequency, retention, and the last successful restore test has been requested and will be published here once received.
No app-level backup logic exists; restore-test evidence is a pre-approval requirement for clinical-data segments.
Business Continuity
Continuity and recovery planning
Business Continuity, Disaster Recovery and Incident Response Plans are documented and maintained, currently at version 1.1 pending founder approval. Formal RTO/RPO targets are documented as targets rather than evidenced commitments; no restore test, continuity exercise or incident response tabletop has been performed, and periodic testing remains planned but not yet evidenced.
BCP/DRP are draft governance documents pending publication and a documented restore test.
Privacy Policy
Versioned and auditable
The Privacy Policy is versioned via LegalDocumentVersion; each acceptance is recorded immutably via recordAgreementAcceptance (TermsAcceptance entity).
Data Residency
Where data is stored
| Data | Location |
|---|---|
| Application & database | Base44 platform (region attestation pending) |
| Clinical documents (files) | AWS S3, Sydney (ap-southeast-2), SSE-KMS — Australian residency |
| Document metadata & audit | Base44 (metadata only, never file contents) |
| AI compatibility assessment | Overseas LLM (de-identified data) |
| AI document extraction | Overseas LLM (raw documents, consent-gated, audited deidentified:false) |
| Transactional email | Resend (third-party) |
| Backups | Base44 platform-managed |
Australian Privacy Principles
APP alignment
- APP 3 — Collection: Only information relevant to housing, support and compatibility is collected; NDIS/Medicare numbers are not required for matching
- APP 6 — Use & disclosure: Disclosure is consent-gated; provider access recorded as ConsentEvent 'Provider Access Granted'
- APP 8 — Cross-border: Overseas AI processing is de-identified or consent-gated; sub-processor register maintained
- APP 11 — Security: MFA, RBAC, encryption, audit logging, private storage, signed URLs
- APP 12 — Access: Participants can view their profile; data-export feature is a roadmap item
- APP 13 — Correction: Profile editing and AI-extracted data review/undo (pre_update_snapshot)
- APP 14 — Open & transparent: This Trust Centre, Privacy Policy, and published sub-processor schedule (draft)
Consent Management
Immutable, event-based
Consent is recorded in an append-only ConsentEvent ledger — each grant, update, withdrawal, reconfirmation, provider access grant/revoke creates a permanent event. Authority type (Self/Guardian/Nominee/Administrator) and the legal version at the time are pinned to each event.
Current consent state is derived from the event history; a ConsentSetting cache mirrors it. Withdrawal is honoured and revokes provider access.
Data Retention
Policy and enforcement
A Data Retention Policy has been drafted defining retention periods by data category. AustralianDocument records carry retention_until and retention_category fields.
Automated retention enforcement and a data-export feature (APP 12) are roadmap items, not yet implemented.
Data Processing Agreement
Terms with processors
A Data Processing Agreement page is published at /dpa. A sub-processor register has been drafted (Base44, AWS, Google Analytics, LLM provider, Resend, Microsoft, GitHub) with several "terms to confirm" items open.
Signed DPAs with each sub-processor and the LLM provider no-training/retention/residency terms are pre-approval requirements.
AI Governance
Accountable, auditable AI
- AI processing is de-identified via deidentifyForAI where feasible
- Documents can be excluded from AI per document (ai_excluded flags)
- Australian-stored clinical documents are AI-disabled by default (ai_excluded = true)
- Every AI invocation is audited (AuditLog 'AI Invocation') with a deidentified flag
- AI Register and AI Impact Assessment are drafted governance artefacts (pending publication)
Human Oversight
AI is decision-support, not decision-maker
AI-extracted data is held for human review (ai_processing_status = Requires Review) and only applied after approval (ai_approved_by / ai_approved_at). A pre_update_snapshot enables "Undo AI Update". Providers review compatibility assessments and confirm placements — AI never makes placement decisions.
De-identification
Reducing PII in AI processing
Compatibility assessments use de-identified data (name, NDIS number, email, phone and DOB stripped) via deidentifyForAI; a testAIDeidentification function validates the pipeline. Audit entries use participant pseudonyms rather than names.
AI Limitations
Honest about what AI can and cannot do
AI may not capture every clinical nuance; extracted data must be verified against the source by a qualified professional. Compatibility scores are recommendations, not guarantees.
Transparency note: AI document extraction transmits raw clinical documents overseas to the LLM provider. This is consent-gated (explicit "Overseas AI Processing" consent) and logged as deidentified: false. Australian-stored clinical documents are AI-disabled and never sent for extraction.
Responsible AI Principles
Our commitments
- Human-in-the-loop: AI supports decisions; humans make them
- Consent-gated: overseas AI processing requires explicit, separate consent
- Transparent: every AI invocation is audited with a de-identification flag
- Controllable: participants and clinicians can exclude documents from AI
- Reversible: AI-applied data can be undone via pre_update_snapshot
- Bounded: Australian clinical documents are AI-disabled by default
ISO 27001 Alignment Summary
Alignment, not certification
| Control | Alignment evidence |
|---|---|
| A.5.1 — Policies | Information Security Policy, Access Control Policy drafted |
| A.5.15 — Access control | RBAC, organisation_admin_ids, providerDataScope |
| A.5.17 — Authentication | MFA mandatory for admins; TOTP with replay protection |
| A.5.34 — Privacy & PII | ConsentEvent ledger, de-identification, APP alignment |
| A.8.5 — Secure authentication | Step-up auth, HMAC-signed sessions, lockout |
| A.8.9 — Configuration management | Security response headers (CSP, frame, nosniff) |
| A.8.11 — Data masking | deidentifyForAI, pseudonymised audit |
| A.8.13 — Information backup | Platform-managed (attestation pending) |
| A.8.15 — Logging | AuditLog, ConsentEvent, RentalAuditLog |
| A.8.24 — Cryptography | AES-GCM, SHA-256, HMAC-SHA256, SSE-KMS |
| A.8.27 — Secure system architecture | Private storage, signed URLs, AI exclusion |
| A.8.29 — Security testing | Penetration test NOT yet completed |
Essential Eight Alignment Summary
ACSC mitigation strategies
| Strategy | Status |
|---|---|
| Application control | N/A — managed SaaS, no user code execution |
| Patch applications | Platform-managed (attestation pending) |
| Configure MS Office | N/A |
| User application hardening | Browser CSP and security headers implemented |
| Restrict admin privileges | MFA mandatory for admins; least-privilege RBAC |
| Patch operating systems | Platform-managed (attestation pending) |
| Multi-factor authentication | TOTP MFA mandatory for administrators |
| Regular backups | Platform-managed (attestation pending) |
Most strategies are platform-managed and attestation-pending; Housing Match directly implements MFA, admin privilege restriction, and browser hardening.
Security Roadmap
Planned improvements
- →Obtain Base44 platform attestation (hosting region, DB encryption, backups, monitoring, rate limiting, password/session policy)
- →Commission and remediate an independent penetration test
- →Perform and evidence a restore test (BCP/DR)
- →Publish Supplier/Sub-processor Schedule and AI Register
- →Implement data-export (APP 12) and automated retention enforcement
- →Add antivirus/malware scanning of uploads (third-party service)
- →Tighten CSP to nonces; configure HSTS at the platform edge
Penetration Testing Status
Independent assurance
No penetration test has been completed. Penetration testing is planned as a pre-approval requirement for hospital and government segments. Until a test is completed and remediated, Housing Match should not be relied upon for clinical-data workloads without compensating controls.
Security Contact
Questions and responsible disclosure
Information Security Manager — Final Recommendation
Recommendation: Conditional approval for NDIS/SDA/SIL providers and community housing. Not yet recommended for hospital clinical-data or government procurement until the evidence gaps below are closed.
Why conditional: Housing Match's application security and privacy design is strong — encrypted-at-rest MFA, HMAC-signed step-up sessions, immutable audit and consent ledgers, Australian SSE-S3 document storage (SSE-KMS planned) with AI disabled, and de-identified, human-reviewed AI processing. This is above sector-typical maturity and addresses the highest-severity risks.
Required before full approval:
- Obtain and publish the Base44 platform attestation (hosting region, DB encryption, backups, monitoring, rate limiting, password/session policy).
- Commission and remediate an independent penetration test.
- Perform and evidence a restore test (BCP/DR).
- Publish the Supplier/Sub-processor Schedule and AI Register (drafts exist).
- Implement data-export (APP 12) and automated retention enforcement.
- Execute signed DPAs and LLM provider no-training/retention/residency terms.
Full challenge review: src/docs/ENTERPRISE_TRUST_CENTRE_ISM_REVIEW.md