Comprehensive security architecture, authentication and authorisation controls, data encryption, NDIS-specific data protection requirements, audit logging, infrastructure security, backup and disaster recovery, compliance standards, vulnerability management, and incident response procedures.
NDSS CRM handles highly sensitive personal information including NDIS participant health records, disability diagnoses, behaviour support plans, financial data, and staff employment records. The platform is designed with a defence-in-depth security architecture that implements multiple overlapping layers of protection. A breach of any single layer does not compromise the entire system.
The security model is built to satisfy the requirements of the Australian Privacy Act 1988, the Australian Privacy Principles (APPs), the NDIS Quality and Safeguards Commission standards, and industry best practices aligned with ISO 27001 and the OWASP Top 10.
NDSS CRM operates on a shared responsibility model between the platform (Newdawn Support Services engineering team), the infrastructure providers (Supabase / Oracle, Vercel), and the organisation deploying the platform.
| Responsibility Area | NDSS CRM Platform | Infrastructure Provider | Organisation |
|---|---|---|---|
| Application code security | Yes | - | - |
| Authentication and authorisation | Yes | Partial (Supabase / Oracle Auth) | - |
| Data encryption at rest | - | Yes (Supabase / Oracle) | - |
| Data encryption in transit | Yes (TLS config) | Yes (certificates) | - |
| Network security and DDoS | - | Yes (Vercel/Supabase / Oracle) | - |
| User account management | Yes (tooling) | - | Yes (admin actions) |
| Password policy enforcement | Yes (code-level) | - | Yes (user compliance) |
| Physical security of data centres | - | Yes | - |
| Staff security training | Yes (documentation) | - | Yes (delivery) |
| Incident response coordination | Yes | Yes | Yes |
Authentication is the first line of defence. NDSS CRM uses Supabase / Oracle Auth as the identity provider, with additional application-level security controls layered on top. Every user interaction with the platform begins with identity verification.
All passwords are processed using the following security measures:
HttpOnly, Secure, SameSite=Strict, and Path=/ attributes.Cross-Site Request Forgery protection is implemented using the synchronizer token pattern. Every form and state-changing request includes a CSRF token that is validated server-side. The CSRF token is generated per session and rotated on every authentication event. API requests authenticated via Bearer tokens in the Authorization header are exempt from CSRF checks (as they are not susceptible to CSRF attacks).
NDSS CRM implements a comprehensive RBAC system with 24 distinct roles. Authorisation is enforced at three levels: route-level middleware, component-level rendering, and database-level Row Level Security (RLS) policies.
Every page and API route is protected by Next.js middleware that verifies the user's role against the required permissions for that route.
// src/middleware.ts - Route protection implementation
import { NextResponse } from 'next/server';
import type { NextRequest } from 'next/server';
import { verifyToken, getRolePermissions } from '@/lib/auth';
const routePermissions: Record<string, string[]> = {
'/dashboard': ['*'], // All authenticated roles
'/clients': ['master_admin', 'administrator', 'service_coordinator', 'support_worker', 'intake'],
'/staff': ['master_admin', 'administrator', 'hr_manager'],
'/finance': ['master_admin', 'administrator', 'finance'],
'/compliance': ['master_admin', 'administrator', 'compliance_officer'],
'/admin/settings': ['master_admin', 'administrator'],
'/admin/users': ['master_admin'],
};
export function middleware(request: NextRequest) {
const token = request.cookies.get('access_token')?.value;
if (!token) {
return NextResponse.redirect(new URL('/auth/login', request.url));
}
const decoded = verifyToken(token);
if (!decoded) {
return NextResponse.redirect(new URL('/auth/login', request.url));
}
const path = request.nextUrl.pathname;
const allowedRoles = routePermissions[path];
if (allowedRoles && !allowedRoles.includes('*') && !allowedRoles.includes(decoded.role)) {
return NextResponse.redirect(new URL('/unauthorized', request.url));
}
return NextResponse.next();
}
Supabase / Oracle RLS policies provide a final layer of authorisation directly at the database level. Even if application-level checks were bypassed, RLS ensures users can only access data their role permits.
-- RLS policy: Support workers can only view their own assigned clients
CREATE POLICY "support_worker_client_access" ON clients
FOR SELECT
USING (
auth.role() = 'master_admin'
OR auth.role() = 'administrator'
OR (
auth.role() = 'support_worker'
AND id IN (
SELECT client_id FROM shift_assignments
WHERE staff_id = auth.uid()
AND status IN ('scheduled', 'in_progress')
)
)
);
-- RLS policy: Finance role can view all invoices but only edit own drafts
CREATE POLICY "finance_invoice_update" ON invoices
FOR UPDATE
USING (
auth.role() = 'master_admin'
OR (
auth.role() = 'finance'
AND (status = 'draft' OR status = 'pending')
)
);
| Access Level | Roles | Scope |
|---|---|---|
| Full Access | master_admin | All modules, all data, system configuration |
| Administrative | administrator | All modules, all data (except system config) |
| Departmental | finance, hr_manager, compliance_officer | Full access within department scope |
| Operational | service_coordinator, intake, allocation_rostering | Assigned clients/staff within region |
| Clinical | behaviour_support, occupational_therapist, speech_pathologist, psychologist, nurse | Assigned clients, clinical records only |
| Frontline | support_worker, team_leader | Assigned shifts and client interactions |
| Limited | client_portal, family_carer | Own records, linked participant only |
All data stored in the Supabase / Oracle PostgreSQL database is encrypted at rest using AES-256 encryption. This includes all tables, indexes, backups, and write-ahead logs (WAL). The encryption is managed by the Supabase / Oracle infrastructure and uses AWS Key Management Service (KMS) for key storage and rotation.
In addition to full-disk encryption, specific columns containing highly sensitive personally identifiable information (PII) are encrypted at the application level before storage:
| Table | Encrypted Columns | Algorithm | Reason |
|---|---|---|---|
clients | tax_file_number, medicare_number | AES-256-GCM | Australian tax and health identifiers |
clients | medical_conditions, medications | AES-256-GCM | Protected health information |
staff | bank_account_bsb, bank_account_number | AES-256-GCM | Financial payment details |
staff | tax_file_number | AES-256-GCM | Australian tax identifier |
behaviour_support_plans | restrictive_practices | AES-256-GCM | Highly sensitive clinical data |
incident_reports | detailed_description | AES-256-GCM | May contain sensitive participant details |
TLS_AES_256_GCM_SHA384TLS_CHACHA20_POLY1305_SHA256TLS_AES_128_GCM_SHA256max-age=31536000; includeSubDomains; preload.Application-level encryption keys used for column-level encryption are stored as environment variables in Vercel and are never committed to source control. Keys are rotated annually, and re-encryption of all affected columns is performed during the maintenance window.
NDSS CRM is designed specifically for the Australian NDIS sector and must comply with the data protection requirements imposed by the NDIS Act 2013, the Privacy Act 1988, and the Australian Privacy Principles (APPs). This section describes how the platform addresses each relevant principle.
| APP | Title | NDSS CRM Implementation |
|---|---|---|
| APP 1 | Open and transparent management | Privacy policy accessible via Client Portal. Data handling procedures documented in this manual. |
| APP 2 | Anonymity and pseudonymity | Not applicable - NDIS service delivery requires identification of participants. |
| APP 3 | Collection of solicited information | Platform only collects information necessary for service delivery. Required fields are clearly marked. Optional fields are documented. |
| APP 4 | Dealing with unsolicited information | Import validation rejects fields not in the approved schema. Admins can purge unsolicited data. |
| APP 5 | Notification of collection | Consent forms and collection notices built into intake workflow. Client Portal displays data collection statements. |
| APP 6 | Use or disclosure | RBAC restricts data access to authorised purposes. Audit logging tracks all data access events. |
| APP 7 | Direct marketing | Platform does not support marketing functionality. No participant data is used for marketing. |
| APP 8 | Cross-border disclosure | All data is stored within Australian data centres (Sydney region, ap-southeast-2). No cross-border transfer. |
| APP 9 | Government identifiers | NDIS numbers and Medicare numbers are stored with column-level encryption and restricted access. |
| APP 10 | Quality of personal information | Validation rules enforce data quality. Duplicate detection prevents redundant records. |
| APP 11 | Security of personal information | Multi-layer encryption, RBAC, audit logging, and vulnerability management as described throughout this chapter. |
| APP 12 | Access to personal information | Participants can view their records via Client Portal. Data export available in CSV format. |
| APP 13 | Correction of personal information | Participants can request corrections via Client Portal. Correction history is maintained in audit log. |
master_admin.The platform implements data minimisation principles by only collecting and displaying information that is necessary for the specific function being performed. For example, support workers viewing a shift assignment see only the client's name, address, service type, and relevant care notes - they do not see financial data, full medical history, or other participants' records.
All API request bodies are validated against strict Zod schemas before processing. Zod is a TypeScript-first schema validation library that provides compile-time type safety and runtime validation. Every API endpoint defines a request schema that specifies required fields, data types, value ranges, string patterns, and custom validation rules.
// Example: Client creation validation schema
import { z } from 'zod';
export const createClientSchema = z.object({
firstName: z.string()
.min(1, 'First name is required')
.max(100, 'First name must be 100 characters or fewer')
.regex(/^[a-zA-Z\s'-]+$/, 'First name contains invalid characters'),
lastName: z.string()
.min(1, 'Last name is required')
.max(100),
ndisNumber: z.string()
.regex(/^\d{9}$/, 'NDIS number must be exactly 9 digits'),
dateOfBirth: z.string()
.regex(/^\d{4}-\d{2}-\d{2}$/, 'Date must be in YYYY-MM-DD format')
.refine((val) => {
const dob = new Date(val);
return dob < new Date();
}, 'Date of birth must be in the past'),
primaryDisability: z.string().min(1),
email: z.string().email().optional(),
phone: z.string()
.regex(/^\+61\d{9}$/, 'Australian phone number required (+61XXXXXXXXX)')
.optional(),
region: z.enum(['NSW', 'VIC', 'QLD', 'WA', 'SA', 'TAS', 'ACT', 'NT']),
});
NDSS CRM uses parameterised queries exclusively for all database interactions. The platform never constructs SQL queries through string concatenation. The Supabase / Oracle client library enforces parameterised queries by default, and the Python service layer uses psycopg2 parameterised queries. The PHP layer uses Laravel's Eloquent ORM with prepared statements.
psycopg2 parameterised execution (cursor.execute(query, params)).Content-Security-Policy:
default-src 'self';
script-src 'self' 'nonce-{random}';
style-src 'self' 'unsafe-inline';
img-src 'self' data: https://supabase.co;
connect-src 'self' https://*.supabase.co wss://*.supabase.co;
frame-ancestors 'none';
base-uri 'self';
form-action 'self';
X-Content-Type-Options: nosniff, X-Frame-Options: DENY, and Referrer-Policy: strict-origin-when-cross-origin headers are set on all responses.NDSS CRM maintains a comprehensive, immutable audit trail that records every significant action performed within the platform. The audit log is a critical compliance requirement for NDIS providers and serves as the primary forensic tool for security investigations.
The following categories of events are captured in the audit log:
| Category | Events Logged |
|---|---|
| Authentication | Login success, login failure, logout, password change, password reset request, session timeout, account lockout, account unlock |
| User Management | User created, user updated, role changed, user deactivated, user reactivated, user deleted |
| Client Records | Client created, client updated (with field-level diff), client archived, client restored, NDIS plan updated, goal created/updated/completed |
| Staff Records | Staff created, staff updated, qualification added/removed, certification expiry updated, availability changed |
| Shifts | Shift created, shift updated, shift cancelled, shift assigned, clock-in, clock-out, progress note submitted |
| Finance | Invoice created, invoice submitted, invoice approved, invoice rejected, invoice voided, payment recorded, budget adjusted |
| Incidents | Incident reported, status changed, investigation notes added, corrective action assigned, incident closed |
| Data Access | Sensitive record viewed (PII fields), report generated, data exported, bulk data accessed |
| System | Settings changed, role permissions modified, webhook configured, integration connected/disconnected, maintenance mode toggled |
{
"id": "aud-001-uuid",
"timestamp": "2025-01-20T14:30:22.456Z",
"userId": "s001-uuid",
"userEmail": "l.chen@newdawnsupport.com.au",
"userRole": "service_coordinator",
"action": "client.update",
"resourceType": "client",
"resourceId": "c001-uuid",
"changes": {
"phone": { "from": "+61400111222", "to": "+61400555666" },
"riskLevel": { "from": "medium", "to": "low" }
},
"ipAddress": "203.0.113.42",
"userAgent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) ...",
"sessionId": "sess-abc123"
}
master_admin.master_admin and compliance_officer roles.ap-southeast-2 (Sydney, Australia) region to ensure all data remains within Australian borders.| Control | Implementation | Purpose |
|---|---|---|
| WAF (Web Application Firewall) | Vercel Edge WAF rules | Block known attack patterns, OWASP Top 10 |
| DDoS Protection | Vercel + Cloudflare integration | Automatic detection and mitigation |
| IP Allowlisting | Supabase / Oracle connection policies | Restrict direct DB access to known IPs |
| API Gateway | Next.js middleware | Request validation, rate limiting, auth |
| Internal Service Communication | mTLS between services | Authenticated, encrypted inter-service calls |
| DNS Security | DNSSEC enabled | Prevent DNS spoofing attacks |
| Backup Type | Frequency | Retention | Storage Location |
|---|---|---|---|
| Automated Daily Backup | Every 24 hours at 02:00 AEST | 30 days | Supabase / Oracle automated backups (ap-southeast-2) |
| Point-in-Time Recovery (PITR) | Continuous WAL archiving | 7 days | Supabase / Oracle WAL archive (ap-southeast-2) |
| Weekly Full Backup | Every Sunday at 01:00 AEST | 90 days | Encrypted S3 bucket (ap-southeast-2) |
| Monthly Archival Backup | 1st of each month at 00:00 AEST | 7 years | AWS S3 Glacier (ap-southeast-2) |
| File Storage Backup | Every 24 hours | 30 days | S3 cross-region replication |
| Metric | Target | Description |
|---|---|---|
| Recovery Time Objective (RTO) | 4 hours | Maximum acceptable time to restore full platform functionality after a disaster event |
| Recovery Point Objective (RPO) | 1 hour | Maximum acceptable data loss measured in time (achieved via PITR with continuous WAL archiving) |
| Service Level Objective (SLO) | 99.9% uptime | Target availability measured monthly (maximum 43 minutes of downtime per month) |
Backup restoration is tested quarterly. Each test involves restoring the most recent daily backup to a separate, isolated environment, running the full automated test suite against the restored data, and verifying data integrity checksums. Results are documented and reviewed by the engineering team. Any failures trigger an immediate investigation and remediation.
NDSS CRM supports compliance with the NDIS Practice Standards through the following platform features:
| NDIS Practice Standard | NDSS CRM Feature |
|---|---|
| Rights and Responsibilities | Service agreements module, consent management, complaint tracking |
| Person-Centred Supports | Individual goal tracking, progress notes, care plan management, participant feedback collection |
| Provision of Supports | Rostering and shift management, staff qualifications tracking, continuity of care reporting |
| Support Provision Environment | SIL property management, safety checklists, environmental risk assessments |
| Information Management | Encrypted data storage, RBAC, audit logging, data retention policies, backup procedures |
| Feedback and Complaints | Complaint intake forms, investigation workflows, resolution tracking, trend analysis |
| Incident Management | Incident reporting module, severity classification, investigation workflows, NDIS Commission notifications |
| Human Resource Management | Worker screening verification, qualification tracking, training records, performance management |
| Continuity of Supports | Succession planning tools, transition documentation, handover reports |
| Restrictive Practices | Authorisation tracking, behaviour support plan management, reporting to Commission |
NDSS CRM complies with the Privacy Act 1988 and all 13 Australian Privacy Principles as detailed in Section 20.5. The platform is designed to handle personal information in accordance with the Act's requirements for collection, use, disclosure, storage, access, and correction of personal information.
While NDSS CRM does not currently hold ISO 27001 certification, the platform's security controls are designed in alignment with ISO 27001 Annex A controls. The following control domains are addressed:
NDSS CRM uses automated dependency scanning to identify known vulnerabilities in third-party packages across all three technology stacks:
| Stack | Tool | Frequency | Action |
|---|---|---|---|
| Next.js / TypeScript | npm audit, GitHub Dependabot | On every pull request + daily automated scan | Critical/High: patch within 24 hours. Medium: patch within 7 days. |
| Python | pip-audit, Safety DB | On every pull request + daily automated scan | Same patching SLA as above. |
| PHP | composer audit, Roave Security Advisories | On every pull request + daily automated scan | Same patching SLA as above. |
eslint-plugin-security plugin is configured to detect common security anti-patterns in TypeScript code.External penetration testing is conducted annually by an independent, CREST-accredited security firm. The testing scope includes:
Findings are classified by severity (Critical, High, Medium, Low, Informational) and remediated according to the following SLAs:
| Severity | Remediation SLA | Verification |
|---|---|---|
| Critical | 24 hours | Re-test by security firm within 48 hours |
| High | 7 days | Re-test by security firm within 14 days |
| Medium | 30 days | Internal verification, included in next pen test |
| Low | 90 days | Included in next pen test |
| Informational | Best effort | Tracked in backlog |
This section describes the security incident response plan for NDSS CRM. A security incident is defined as any event that compromises or threatens to compromise the confidentiality, integrity, or availability of the platform or its data.
| Severity | Definition | Examples | Response Time |
|---|---|---|---|
| P1 - Critical | Active data breach, full service outage, or compromise of participant PII | Database exfiltration, ransomware, authentication bypass | Immediate (within 15 minutes) |
| P2 - High | Attempted breach, partial service outage, or vulnerability actively being exploited | Brute force attack, SQL injection attempt detected, single service failure | Within 1 hour |
| P3 - Medium | Security policy violation, suspicious activity, or vulnerability discovered | Unauthorised access attempt, new CVE in dependency, configuration drift | Within 4 hours |
| P4 - Low | Minor policy deviation or informational security event | Failed login spikes, non-critical vulnerability, audit finding | Within 24 hours |
Phase 1: Detection and Identification
Phase 2: Containment
Phase 3: Eradication
Phase 4: Recovery
Phase 5: Post-Incident Review
In the event of a data breach involving personal information, NDSS CRM follows the mandatory notification requirements set out in the Notifiable Data Breaches (NDB) scheme under Part IIIC of the Privacy Act 1988:
| Notification Recipient | Timeframe | Content Required |
|---|---|---|
| Office of the Australian Information Commissioner (OAIC) | Within 30 days of becoming aware (or as soon as practicable) | Nature of breach, types of information involved, recommended steps for affected individuals |
| NDIS Quality and Safeguards Commission | Within 24 hours for incidents involving participant harm | Incident details, affected participants, immediate actions taken |
| Affected Individuals | As soon as practicable after notifying OAIC | Description of breach, types of information involved, recommended protective steps |
| Organisation Administrators | Immediately upon confirmation | Full incident details, impact assessment, remediation timeline |
For security incidents requiring immediate attention, contact the Newdawn Support Services Security Team at security@newdawnsupport.com.au or call the 24/7 security hotline at 1800 NDSS SEC (1800 637 773).