Security

1. Our commitment

Security is a core part of how we build and operate AI systems. We apply security-by-design principles at every stage — from initial architecture through deployment and ongoing monitoring. This page describes the measures we take to protect our own systems, our clients' data, and the AI systems we build and run on behalf of clients.

We comply with the security obligations of the Privacy Act 1988 (Cth), including the obligation under APP 11 to take reasonable steps to protect personal information from misuse, interference, loss, and unauthorised access, modification, or disclosure.

2. Technical controls

Encryption

• All data transmitted to and from our services is encrypted in transit using TLS 1.2 or higher
• Sensitive data at rest (including personal information and client project data) is encrypted using AES-256 or equivalent
• Encryption keys are managed through dedicated key management services with strict access controls

Access control

• Role-based access control (RBAC) restricts access to data and systems on a least-privilege basis
• Multi-factor authentication (MFA) is required for all staff access to production environments and client data
• Access is reviewed quarterly and revoked promptly when staff or contractors disengage
• Privileged access is logged and auditable

Infrastructure

• We host on enterprise cloud infrastructure (AWS and/or Google Cloud) with regional data residency options available for clients requiring Australian data sovereignty
• Production environments are isolated from development and staging via separate network boundaries
• Automated vulnerability scanning is performed on all deployed services
• Dependencies are monitored for known vulnerabilities (CVEs) and patched promptly

Monitoring and logging

• Security events and system anomalies are monitored continuously
• Access logs, API call logs, and authentication events are retained for at least 90 days
• Alerting is configured for suspicious access patterns, failed authentication attempts, and unusual data exports

3. Organisational controls

• Security training: All Zimritech staff and contractors complete security awareness training before accessing client systems, and at least annually thereafter
• Confidentiality agreements: All staff, contractors, and subprocessors are bound by confidentiality obligations covering client data and project information
• Vendor assessment: Third-party tools and subprocessors are assessed for security posture before engagement. We favour services that hold recognised certifications (ISO 27001, SOC 2 Type II)
• Secure development: Development follows OWASP guidelines. Code changes are reviewed before deployment. Secrets are never committed to version control
• Incident response plan: We maintain a documented incident response procedure that is tested annually

4. AI system security

The AI systems we build for clients introduce unique security considerations that we address proactively:

Prompt injection and model manipulation

AI agents that accept external input are protected against prompt injection attacks through input sanitisation, system prompt hardening, and output validation layers.

Data minimisation in model training and inference

We design AI systems to operate on only the data necessary for the task. We avoid training or fine-tuning models on sensitive personal information unless explicitly agreed with the client and subject to appropriate safeguards.

Output safety

For client-facing AI agents and chatbots, we implement guardrails to detect and block harmful, misleading, or off-topic outputs. Outputs are monitored for quality and safety on an ongoing basis.

Third-party model providers

Where we integrate third-party language model APIs (e.g., Anthropic, OpenAI, Google), we use enterprise-tier agreements that include data processing addenda. We do not send personal information to model providers unless required for the agreed service and disclosed to the client.

5. Data breach response

Zimritech is subject to the Notifiable Data Breaches (NDB) scheme under Part IIIC of the Privacy Act 1988 (Cth). In the event of a data breach that is likely to result in serious harm:

1. Containment: We will take immediate steps to contain the breach and prevent further unauthorised access or disclosure.
2. Assessment: We will assess the nature and scope of the breach, the type of information involved, and the likely risk of harm to affected individuals.
3. Notification to OAIC: We will notify the Office of the Australian Information Commissioner (OAIC) as soon as practicable after becoming aware that a notifiable data breach has occurred.
4. Notification to individuals: We will notify affected individuals directly, or by public notification if direct contact is not reasonably practicable, providing details of the breach and recommended steps to reduce harm.
5. Client notification: Where a breach involves client data held on behalf of a client, we will notify the relevant client promptly to allow them to fulfil their own notification obligations.

We maintain a data breach register and conduct a post-incident review following any material security incident.

6. Responsible disclosure

We welcome reports of genuine security vulnerabilities in our website, products, or infrastructure. We are committed to working with security researchers in good faith.

How to report

Email security@zimritech.com.au with:

• A clear description of the vulnerability
• Steps to reproduce or a proof-of-concept (PoC)
• The potential impact as you understand it
• Your contact details (optional, but helpful for follow-up)

Our commitments

• We will acknowledge your report within 2 Australian business days
• We will keep you informed of our progress
• We will not pursue legal action against you if you have acted in good faith, have not accessed or exfiltrated data beyond what was necessary to demonstrate the vulnerability, and have not publicly disclosed the vulnerability before we have had a reasonable opportunity to remediate it (typically 90 days)
• We will give credit in our security acknowledgements if you wish

Out of scope

The following are outside the scope of our responsible disclosure program:

• Denial-of-service (DoS/DDoS) attacks
• Social engineering of Zimritech staff
• Physical attacks on our premises or staff
• Automated scanning that causes service disruption
• Vulnerabilities in third-party services we do not control

7. Client responsibilities

Security is a shared responsibility. To protect systems we build and manage together, we ask our clients to:

• Keep credentials, API keys, and access tokens issued for Zimritech-built systems confidential and rotate them if compromised
• Notify us promptly if you suspect unauthorised access to any system we manage on your behalf
• Ensure that your own staff who interact with Zimritech systems follow your organisation's security policies
• Inform us of any regulatory or compliance requirements relevant to data we handle on your behalf (e.g., health records, financial data) so we can apply appropriate controls

Specific security obligations for client engagements are documented in our Statement of Work and Data Processing Agreement for each project.

8. Contact