Security Policy

Technical and organisational measures for the protection of information assets.

1. Purpose and Scope

1.1 Purpose

This Security Policy (“Policy”) describes the technical and organisational security measures implemented by Ozler Tech Pty Ltd, trading as Ozler Care Solutions (“Ozler,” “we,” “our”), to protect the confidentiality, integrity, and availability of Customer Data, personal information, and the Services. This Policy forms part of our contractual commitments to Customers and supplements the Privacy Policy and Terms of Service.

1.2 Scope

This Policy applies to:

• All Ozler Care Solutions products and services, including OzlerShield, OzlerSIRS, OzlerReady, OzlerPolicy, Skill2Care, OzlerPass, OzlerScribe, 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 Policy 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) as it relates to information security;
• Australian Signals Directorate (ASD) Essential Eight Maturity Model — target Maturity Level Two;
• ISO/IEC 27001:2022 — as a guiding framework (formal certification planned for 2027);
• SOC 2 Type II — Trust Services Criteria (Security, Availability, Confidentiality) — certification pathway initiated;
• OWASP Application Security Verification Standard (ASVS) Level 2;
• Australian Government Information Security Manual (ISM) — where applicable to cloud-hosted SaaS.

2. Security Governance

2.1 Accountability

Ultimate accountability for information security rests with the Chief Executive Officer. Day-to-day security operations are managed by the designated Security Lead (or equivalent role). The Security Lead reports directly to the CEO and has authority to implement security controls, enforce compliance, and escalate risks.

2.2 Security Policies and Standards

Ozler maintains a suite of 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, or more frequently following a material security incident, significant change to the threat landscape, or regulatory amendment.

2.3 Risk Management

Ozler conducts formal information security risk assessments at least annually, and on an ad-hoc basis when material changes occur (e.g., new product launch, infrastructure migration, new sub-processor). Risk assessments follow a structured methodology aligned with ISO 31000 and produce a risk register with assigned owners, treatment plans, and review dates.

2.4 Security Training and Awareness

• All personnel complete security awareness training within 7 days of commencing engagement, and annually thereafter;
• Developers complete secure coding training (OWASP Top 10, injection prevention, authentication best practices) at onboarding and annually;
• Phishing simulation exercises are conducted quarterly;
• Security incident tabletop exercises are conducted at least bi-annually;
• Training records are maintained for audit purposes.

3. Infrastructure Security

3.1 Cloud Hosting

3.2 Network Security

• Virtual Private Cloud (VPC): all application and database resources reside in private subnets within a dedicated VPC. No database or application server has a public IP address;
• Security Groups and NACLs: inbound traffic restricted to HTTPS (443) and SSH (22, bastion host only). All other ports denied by default. Egress restricted to known-good destinations;
• Web Application Firewall (WAF): AWS WAF deployed on all public-facing endpoints with OWASP Core Rule Set, rate limiting, and geo-blocking rules;
• DDoS Protection: AWS Shield Standard on all resources; Shield Advanced on public-facing load balancers;
• Bastion / Jump Host: administrative access to production environments exclusively via hardened bastion host with MFA and session recording;
• Network segmentation: production, staging, and development environments are logically isolated. No lateral movement between environments;
• DNS: Amazon Route 53 with DNSSEC where supported by client resolvers;
• TLS Certificates: managed via AWS Certificate Manager (ACM) with automatic renewal. Minimum TLS 1.2; TLS 1.3 preferred.

3.3 Infrastructure Hardening

• Operating systems: minimal base images with unnecessary packages removed. CIS Benchmark-hardened configurations;
• Containers: images scanned for vulnerabilities at build time. No root containers in production;
• Patching: automated patching for OS-level vulnerabilities within 14 days of vendor release for critical/high severity, 30 days for medium;
• Immutable infrastructure: production deployments via Infrastructure as Code (Terraform or AWS CDK). No manual changes to production systems;
• Service mesh / API gateway: internal service-to-service communication authenticated and encrypted via mTLS where applicable.

4. Data Security

4.1 Data Classification

4.2 Encryption

Encryption at Rest: Database: AES-256 encryption via AWS RDS encryption (using AWS KMS customer-managed keys or AWS-managed keys); Object storage (S3): server-side encryption with AES-256 (SSE-S3) or AWS KMS (SSE-KMS) for CRITICAL-classified data; File systems (EBS): AES-256 encryption; Backups: encrypted to the same standard as source data; Voice recordings (OzlerScribe): encrypted with dedicated KMS key; access restricted to the originating Provider's tenant.

Encryption in Transit: External communications: TLS 1.2 minimum, TLS 1.3 preferred. HSTS headers enforced on all web endpoints. Certificate Transparency monitoring enabled; Internal service-to-service: TLS 1.2+ or mTLS for sensitive data flows; API communications: all API endpoints require HTTPS. Plaintext HTTP connections rejected; Email: TLS opportunistic encryption. Sensitive notifications do not contain personal information in email body.

Key Management: AWS Key Management Service (KMS) for encryption key lifecycle management; Customer-managed keys (CMK) available for enterprise customers requiring independent key control; Key rotation: automatic annual rotation for KMS keys. Application-level secrets rotated at least every 90 days; No encryption keys stored in source code, configuration files, or environment variables in plaintext. Secrets managed via AWS Secrets Manager or equivalent.

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;
• OzlerScribe voice recordings and transcriptions are stored in tenant-specific S3 prefixes with bucket policies preventing cross-tenant access;
• Enterprise customers may request dedicated database instances (at additional cost) 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 AWS region (ap-southeast-2) and encrypted at rest;
• Cross-region backup replication available for enterprise customers;
• Recovery testing conducted quarterly with documented recovery time results;
• Recovery Point Objective (RPO): 1 hour. Recovery Time Objective (RTO): 4 hours for standard; 1 hour for enterprise SLA.

4.5 Data Destruction

When Customer Data is no longer required (upon contract termination, expiry of retention periods, or Customer request):

• Database records: cryptographic erasure (deletion of encryption keys rendering data unrecoverable) or logical deletion followed by physical overwrite within 90 days;
• Object storage: S3 object deletion with bucket lifecycle policies. AWS confirms physical media destruction per AWS SOC 2 controls;
• Backups: expired according to retention schedule. No manual intervention required;
• Paper records: cross-cut shredded (DIN 66399 Level P-4 equivalent);
• Confirmation: upon request, Ozler will provide a written certificate of destruction.

5. Application Security

5.1 Secure Development Lifecycle (SDLC)

• Threat modelling conducted for all new features affecting data handling, authentication, or authorisation;
• Code review: all production code changes require peer review by at least one other developer before merge;
• Static Application Security Testing (SAST): automated scanning integrated into CI/CD pipeline. Builds fail on critical or high findings;
• Dynamic Application Security Testing (DAST): automated scanning of staging environments before production deployment;
• Software Composition Analysis (SCA): automated dependency vulnerability scanning. Critical CVEs patched within 48 hours of disclosure;
• Secret scanning: pre-commit hooks and CI/CD checks to prevent accidental commitment of credentials, API keys, or tokens;
• Deployment: automated CI/CD pipelines. No manual deployments to production. All deployments logged and auditable.

5.2 Authentication and Authorisation

• Authentication: email/password with enforced complexity (minimum 12 characters, NIST SP 800-63B compliant), or Single Sign-On (SSO) via SAML 2.0 / OpenID Connect for enterprise customers;
• Multi-Factor Authentication (MFA): mandatory for all administrative and privileged accounts. Supported factors: TOTP authenticator app, WebAuthn/FIDO2 hardware keys;
• Session management: server-side session tokens with configurable idle timeout (default 30 minutes). Secure, HttpOnly, SameSite=Strict cookies;
• Role-Based Access Control (RBAC): granular roles (Owner, Admin, Manager, Staff, Read-Only) with least-privilege defaults. Custom roles available for enterprise;
• API authentication: OAuth 2.0 bearer tokens with short-lived access tokens (15 minutes) and refresh tokens (7 days, revocable);
• Brute force protection: account lockout after 10 failed attempts (30-minute cooldown). Rate limiting on all authentication endpoints;
• Password storage: bcrypt with cost factor ≥ 12. No plaintext or reversibly encrypted passwords.

5.3 Input Validation and Output Encoding

• All user input validated server-side against expected types, lengths, and patterns. Client-side validation treated as UX only;
• Parameterised queries (prepared statements) used for all database interactions. No string concatenation in SQL;
• Output encoding: context-appropriate encoding (HTML, JavaScript, URL, CSS) applied to all dynamic content rendered in web pages;
• Content Security Policy (CSP) headers enforced with strict directives;
• File uploads: validated by file type, size, and content (magic byte verification). Uploaded files stored outside the web root and served via signed URLs with short expiry.

5.4 API Security

• All APIs require authentication. No anonymous endpoints serve Customer Data;
• Rate limiting applied per-tenant and per-endpoint to prevent abuse;
• Request size limits enforced (default 10MB, configurable for OzlerScribe voice uploads);
• API versioning: breaking changes introduced in new API versions. Deprecated versions supported for minimum 12 months;
• CORS: restrictive origin whitelisting. Wildcard origins (*) never used in production;
• Webhook signatures: all outbound webhooks signed with HMAC-SHA256 for integrity verification by recipients.

6. Access Control

6.1 Principle of Least Privilege

All access to production systems, databases, and Customer Data is granted on the principle of least privilege. Access is granted only when required for a legitimate business purpose and is revoked promptly when no longer needed.

6.2 Administrative Access

• Production infrastructure access restricted to designated SRE/DevOps personnel;
• All administrative access requires MFA and is conducted via hardened bastion host with session recording;
• Just-in-time (JIT) access: elevated privileges granted on-demand for a defined duration and automatically revoked;
• No persistent root or superuser credentials. Root account access requires dual authorisation (two-person rule);
• All administrative actions logged to a tamper-evident audit trail (AWS CloudTrail, centralised log management).

6.3 Customer Data Access by Ozler Personnel

Ozler personnel access Customer Data only when explicitly authorised by the Customer (e.g., support ticket requesting investigation), required to fulfil operational obligations (e.g., database maintenance, incident response), or required by law. All Customer Data access by Ozler personnel is logged with the identity of the accessor, the data accessed, the time, and the justification. These logs are retained for 12 months and available for Customer review upon request.

6.4 Personnel Security

• Background checks: all employees and contractors with access to Customer Data undergo National Police Checks before commencement;
• Confidentiality agreements: all personnel sign binding confidentiality and non-disclosure agreements;
• Onboarding: security training, acceptable use policy acknowledgment, and access provisioning within first 7 days;
• Offboarding: access revoked within 4 hours of termination. Equipment returned and wiped within 48 hours. Exit checklist completed and signed;
• Access reviews: quarterly review of all user access to production systems and Customer Data. Stale access revoked.

7. Logging, Monitoring, and Detection

7.1 Logging

• Application logs: all authentication events (success and failure), authorisation decisions, data access, data modification, and administrative actions;
• Infrastructure logs: AWS CloudTrail (API calls), VPC Flow Logs (network traffic), S3 access logs, RDS audit logs;
• WAF logs: all blocked and flagged requests;
• Log format: structured JSON with timestamp, actor, action, resource, outcome, and source IP;
• Log integrity: logs shipped to a centralised SIEM in a separate account. Write-once, append-only storage to prevent tampering;
• Log retention: minimum 12 months online, 7 years archived (compressed, encrypted).

7.2 Monitoring and Alerting

• Real-time monitoring of infrastructure health, application performance, and security events;
• Automated alerting for anomalous patterns: unusual login locations, bulk data export, privilege escalation, brute force attempts, and known attack signatures;
• Uptime monitoring: external synthetic checks every 60 seconds from multiple geographies;
• On-call rotation: 24/7 engineering on-call with defined escalation paths and response time SLAs.

7.3 Threat Detection

• AWS GuardDuty for automated threat detection across CloudTrail, VPC Flow Logs, and DNS logs;
• SIEM correlation rules for multi-vector attack detection;
• Regular threat intelligence review to update detection rules.

8. Vulnerability Management

8.1 Vulnerability Scanning

• Automated infrastructure vulnerability scanning: weekly;
• Automated application vulnerability scanning (DAST): with every staging deployment;
• Container image scanning: at every build and weekly on running images;
• Dependency scanning (SCA): on every code merge and daily scheduled scan;
• Cloud configuration scanning: continuous compliance monitoring against CIS AWS Benchmarks.

8.2 Penetration Testing

• External penetration testing by an independent, qualified third party: at least annually;
• Scope: all production web applications, APIs, and externally accessible infrastructure;
• Methodology: aligned with OWASP Testing Guide and PTES (Penetration Testing Execution Standard);
• Remediation: critical and high findings remediated within 14 days; medium within 30 days; low within 90 days;
• Re-test: critical and high findings re-tested to confirm remediation;
• Reports: executive summary available to enterprise customers under NDA upon request.

8.3 Responsible Disclosure

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; providing an initial assessment within 5 business days; keeping the reporter informed of remediation progress; and not pursuing legal action against reporters acting in good faith.

9. Incident Response

9.1 Incident Classification

• Severity 1 (Critical): data breach confirmed or likely, service outage;
• Severity 2 (High): suspected breach, significant vulnerability exploited;
• Severity 3 (Medium): policy violation, anomalous activity;
• Severity 4 (Low): informational, minor policy deviation.

9.2 Response Procedures

9.3 Customer Notification

• Severity 1: Customer notified within 24 hours of confirmation. Updates provided at least every 12 hours until resolution;
• Severity 2: Customer notified within 48 hours. Updates provided every 24 hours;
• Severity 3–4: included in the next scheduled security summary or upon Customer request.

Notification content includes: description of the incident, data types and approximate records affected, timeline, containment actions taken, recommended Customer actions, and Ozler's remediation plan.

9.4 Regulatory Notification

Where an incident constitutes an Eligible Data Breach under Part IIIC of the Privacy Act 1988 (Cth), Ozler will notify the Office of the Australian Information Commissioner (OAIC) and affected individuals in accordance with the Notifiable Data Breaches (NDB) scheme. Ozler will coordinate with affected Customers to enable them to meet their own notification obligations to their Workers and Care Recipients.

10. Business Continuity and Disaster Recovery

10.1 High Availability

• Multi-Availability Zone (Multi-AZ) deployment: application and database tiers deployed across at least two AZs within ap-southeast-2;
• Auto-scaling: application tier scales horizontally based on demand;
• Load balancing: AWS Application Load Balancer with health checks and automatic failover;
• Database: Amazon RDS Multi-AZ with automatic failover (typically under 60 seconds).

10.2 Disaster Recovery

• Recovery Point Objective (RPO): 1 hour (standard), 15 minutes (enterprise SLA);
• Recovery Time Objective (RTO): 4 hours (standard), 1 hour (enterprise SLA);
• Backup strategy: automated daily snapshots, continuous WAL archiving for PITR, encrypted backups;
• DR testing: full disaster recovery test conducted annually;
• Runbooks: documented step-by-step recovery procedures for all critical services.

10.3 Service Level Targets

11. Third-Party and Vendor Security

11.1 Vendor Risk Assessment

Before engaging any third-party service provider that will process, store, or have access to Customer Data or personal information, Ozler conducts a vendor security risk assessment including:

• Review of the vendor's security certifications (SOC 2, ISO 27001, IRAP, or equivalent);
• Assessment of data handling practices, encryption standards, and access controls;
• Evaluation of the vendor's incident response capabilities and breach notification commitments;
• Confirmation of data residency (Australian hosting required for Customer Data);
• Review of the vendor's sub-processor chain and notification obligations.

11.2 Contractual Controls

• All sub-processors are bound by Data Processing Agreements (DPAs) requiring them to process data only on Ozler's documented instructions;
• DPAs include confidentiality obligations, security requirements, breach notification timelines, audit rights, and data return/destruction obligations;
• Sub-processors must notify Ozler within 24 hours of any security incident affecting Ozler data.

11.3 Key Sub-Processors

Ozler maintains a current list of sub-processors. Key sub-processors include Amazon Web Services (AWS) for cloud infrastructure hosting (ap-southeast-2, Sydney, Australia). A full sub-processor list is available to enterprise customers under NDA upon request.

Contact

For security-related enquiries or to report a vulnerability: