Security

1. Purpose and Scope

1.1 Purpose

This Security Statement describes the technical and organisational security measures implemented by Ozler Tech Pty Ltd, trading as Ozler Care Solutions, to protect the confidentiality, integrity, and availability of Customer Data, personal information, and the Services.

1.2 Scope

This statement applies to:

• All Ozler Care products and services, including Skill2Care, OzlerShield, OzlerReady, OzlerSIRS, OzlerPolicy, OzlerPass, and associated APIs, web applications, and mobile applications;
• All infrastructure, systems, networks, and environments used to develop, test, deploy, and operate the Services;
• All personnel, including employees, contractors, sub-processors, and third-party service providers with access to Ozler systems or Customer Data;
• All Customer Data, personal information (as defined in the Privacy Act 1988 (Cth)), and Ozler proprietary information.

1.3 Regulatory Alignment

This statement is designed to satisfy or exceed the requirements of:

• Australian Privacy Principles (APPs), in particular APP 11 (Security of Personal Information);
• NDIS Quality and Safeguards Commission — Practice Standard on Information Management;
• Aged Care Quality Standards — Standard 8 (Organisational Governance);
• Australian Signals Directorate (ASD) Essential Eight Maturity Model — target Maturity Level Two;
• ISO/IEC 27001:2022 — as a guiding framework;
• SOC 2 Type II — Trust Services Criteria (certification pathway initiated);
• OWASP Application Security Verification Standard (ASVS) Level 2.

2. Security Governance

Ultimate accountability for information security rests with the Chief Executive Officer. Day-to-day security operations are managed by the designated Security Lead, who reports directly to the CEO. Ozler maintains internal security policies including: Information Security Policy, Acceptable Use Policy, Access Control Policy, Data Classification and Handling Policy, Incident Response Plan, Business Continuity and Disaster Recovery Plan, Vendor and Third-Party Risk Management Policy, Vulnerability Management Policy, Change Management Policy, Data Destruction and Retention Policy, Encryption Policy, and Physical Security Policy. All policies are reviewed at least annually.

All personnel complete security awareness training within 7 days of commencing engagement and annually thereafter. Developers complete secure coding training (OWASP Top 10) at onboarding and annually. Phishing simulation exercises are conducted quarterly.

3. Infrastructure Security

3.1 Cloud Hosting

All Services are hosted on Microsoft Azure in the Australia East (Sydney) region. Disaster recovery replication is configured to Australia Southeast (Melbourne). All Customer Data at rest is stored exclusively within Australia.

3.2 Network Security

• All application and database resources reside in private subnets within a dedicated Virtual Network. No database or application server has a public IP address.
• Azure Web Application Firewall (WAF) deployed on all public-facing endpoints with OWASP Core Rule Set, rate limiting, and geo-blocking rules.
• Azure DDoS Protection Standard on all public-facing resources.
• Administrative access exclusively via hardened bastion host with MFA and session recording.
• Production, staging, and development environments are logically isolated with no lateral movement.
• TLS 1.2 minimum on all endpoints; TLS 1.3 preferred. Managed certificates via Azure Front Door.

3.3 Infrastructure Hardening

• Minimal container base images with unnecessary packages removed. CIS Benchmark-hardened configurations.
• Container images scanned for vulnerabilities at build time. No root containers in production.
• Automated patching: critical/high within 14 days, medium within 30 days of vendor release.
• Immutable infrastructure: production deployments via Terraform. No manual changes to production.

4. Data Security

4.1 Data Classification

4.2 Encryption

Encryption at Rest

• Database: AES-256 encryption via Azure-managed or customer-managed keys (Azure Key Vault);
• Object storage (Azure Blob): server-side encryption with AES-256;
• File systems: AES-256 encryption on all managed disks;
• Backups: encrypted to the same standard as source data.

Encryption in Transit

• External: TLS 1.2+ on all endpoints. HSTS headers enforced. Certificate Transparency monitored.
• Internal service-to-service: TLS 1.2+ or mTLS for sensitive data flows.
• API: all endpoints require HTTPS. Plaintext HTTP connections rejected.
• Email: TLS opportunistic encryption. Sensitive notifications use link-back model (no PII in email body).

Key Management

• Azure Key Vault for encryption key lifecycle management.
• Customer-managed keys (CMK) available for enterprise customers.
• Automatic annual key rotation. Application-level secrets rotated at least every 90 days.
• No encryption keys stored in source code, configuration files, or environment variables in plaintext.

4.3 Data Isolation and Multi-Tenancy

The Services operate on a multi-tenant architecture with logical data isolation:

• Each Customer's data is logically isolated at the application and database levels using tenant identifiers enforced in every query.
• Row-Level Security (RLS) or equivalent database-level controls prevent cross-tenant data access.
• API authentication and authorisation enforce tenant-scoped access. No API endpoint returns data from another tenant.
• Enterprise customers may request dedicated database instances for physical data isolation.

4.4 Data Backup and Recovery

• Automated daily database backups retained for 30 days.
• Point-in-time recovery (PITR) enabled with 5-minute granularity.
• Backups stored in the same Azure region and encrypted at rest.
• Recovery testing conducted quarterly.
• Recovery Point Objective (RPO): 1 hour. Recovery Time Objective (RTO): 4 hours standard, 1 hour enterprise.

4.5 Data Destruction

When Customer Data is no longer required, it is securely destroyed via cryptographic erasure or logical deletion followed by physical overwrite within 90 days. Azure confirms physical media destruction per its SOC 2 controls. A written certificate of destruction is available upon request.

5. Application Security

5.1 Secure Development Lifecycle

• Threat modelling for all new features affecting data handling, authentication, or authorisation.
• All production code changes require peer review before merge.
• Static Application Security Testing (SAST) integrated into CI/CD. Builds fail on critical/high findings.
• Dynamic Application Security Testing (DAST) on staging before production deployment.
• Software Composition Analysis (SCA): critical CVEs patched within 48 hours.
• Secret scanning: pre-commit hooks and CI/CD checks.
• Automated CI/CD deployments. No manual deployments to production.

5.2 Authentication and Authorisation

• Azure AD B2C for all user authentication. SSO via SAML 2.0 / OIDC for enterprise.
• Mandatory MFA for all administrative and privileged accounts.
• Session management: server-side tokens, 30-minute idle timeout, Secure/HttpOnly/SameSite=Strict cookies.
• Role-Based Access Control (RBAC) with least-privilege defaults.
• API: OAuth 2.0 bearer tokens, 15-minute access tokens, 7-day revocable refresh tokens.
• Brute force protection: lockout after 10 failed attempts (30-minute cooldown).
• Password storage: bcrypt with cost factor ≥ 12.

5.3 API Security

• All APIs require authentication. No anonymous endpoints serve Customer Data.
• Rate limiting per-tenant and per-endpoint.
• Request size limits enforced (default 10MB).
• API versioning: deprecated versions supported for minimum 12 months.
• CORS: restrictive origin whitelisting. Wildcard origins never used in production.
• Webhook signatures: HMAC-SHA256 for integrity verification.

6. Access Control

All access to production systems is granted on the principle of least privilege. Administrative access requires MFA and is conducted via hardened bastion host with session recording. Just-in-time (JIT) elevated privileges are granted on-demand and automatically revoked. All administrative actions are logged to a tamper-evident audit trail.

Ozler personnel access Customer Data only when explicitly authorised by the Customer, required for operational obligations, or required by law. All Customer Data access is logged with identity, data accessed, time, and justification.

All employees and contractors with access to Customer Data undergo National Police Checks. All personnel sign confidentiality agreements. Access is revoked within 4 hours of termination. Quarterly access reviews are conducted.

7. Logging, Monitoring, and Detection

Application logs capture all authentication events, authorisation decisions, data access, data modification, and administrative actions. Infrastructure logs include Azure activity logs, network flow logs, and WAF logs. All logs are structured JSON, shipped to a centralised SIEM with write-once storage. Minimum 12 months online, 7 years archived.

Real-time monitoring with automated alerting for anomalous patterns. Uptime monitoring via synthetic checks every 60 seconds. 24/7 engineering on-call with defined escalation paths.

8. Vulnerability Management

• Automated infrastructure vulnerability scanning: weekly.
• Application vulnerability scanning (DAST): with every staging deployment.
• Container image scanning: at every build and weekly on running images.
• External penetration testing by independent third party: at least annually.
• Critical/high findings remediated within 14 days; medium within 30 days.

Ozler operates a responsible disclosure program. Security researchers may report vulnerabilities to security@ozlercare.com.au. We commit to acknowledging receipt within 2 business days and providing an initial assessment within 5 business days.

9. Incident Response

Ozler maintains a documented Incident Response Plan covering security incidents, data breaches, and service disruptions. Incidents are classified: Severity 1 (critical — data breach confirmed), Severity 2 (suspected breach), Severity 3 (policy violation), Severity 4 (informational). Containment actions are taken within 1 hour of Sev 1 classification. Blameless post-mortems are conducted within 5 business days.

Customer notification: Sev 1 within 24 hours, Sev 2 within 48 hours. Regulatory notification per the Notifiable Data Breaches scheme (Part IIIC, Privacy Act 1988).

10. Business Continuity and Disaster Recovery

• Multi-Availability Zone deployment across minimum 2 AZs within Australia East.
• Auto-scaling application tier.
• Database: Azure PostgreSQL Zone-Redundant HA with automatic failover.
• RPO: 1 hour (standard), 15 minutes (enterprise). RTO: 4 hours (standard), 1 hour (enterprise).
• Full DR test conducted annually.
• Target availability: 99.9% monthly uptime (standard), 99.95% (enterprise).

11. Third-Party and Vendor Security

All sub-processors are bound by Data Processing Agreements and assessed for security certifications, data handling practices, and breach notification capabilities before engagement. Australian data residency is required for Customer Data. Customers are notified at least 30 days before a new sub-processor is engaged.

12. Compliance and Assurance

Enterprise Customers may request SOC 2 reports (under NDA), penetration test executive summaries, submit security questionnaires, or conduct audits subject to mutually agreed scope and confidentiality protections.

13. Contact

Security Team: security@ozlercare.com.au · Privacy Officer: privacy@ozlercare.com.au · General: hello@ozlercare.com.au | 1300 OZ CARE · Address: Ozler Care Solutions, Melbourne VIC, Australia.