Security & compliance

We build systems that handle sensitive data. That means we need to understand your compliance obligations before we write a line of code, and architect accordingly.

This page covers the regulatory and security frameworks we work within, how we approach data protection, and the deployment options that can reduce your compliance overhead. Where a project requires formal certification, audit, or testing, we scope that into the engagement so you know the cost and timeline upfront.

Regulatory awareness

Australian enterprise and government procurement teams have specific security expectations. We know what those are, and we know how to meet them. Here are the frameworks we most commonly encounter.

ASD Essential Eight

The Australian Signals Directorate’s Essential Eight is the practical baseline for information security in Australia. It covers application control, patching, macro restrictions, user application hardening, admin privilege management, multi-factor authentication, regular backups, and Microsoft Office macro settings.

We understand the Essential Eight maturity model and can walk your team through how a proposed architecture maps to it. For engagements where formal alignment is required, we scope that into the project.

ISO 27001:2022

ISO 27001 is the international standard for information security management systems. It’s widely recognised across Australian government and enterprise, and often the preferred certification for regulated industries including finance, insurance and healthcare.

Our development practices are informed by the ISO 27001:2022 control set, covering areas like access management, change control, incident response, and vendor assessment. For engagements that require formal ISO certification, we can scope that into the project timeline using compliance automation platforms like Vanta or Drata, which reduce the preparation overhead significantly.

SOC 2

SOC 2 is an attestation framework common in the technology sector, particularly for SaaS and cloud-hosted services. A Type 1 report validates the design of security controls at a point in time. A Type 2 report validates their effectiveness over a six-to-twelve month observation period.

Where an engagement requires SOC 2 attestation, we use compliance automation tooling to monitor security controls across cloud infrastructure, identity management and code deployment pipelines. This keeps audit preparation efficient and reduces the impact on your project timeline.

APRA CPS 234 and CPS 230

If you’re regulated by APRA (banks, insurers, superannuation funds), CPS 234 sets specific requirements for information security capability, incident management and testing, including the requirement that information assets managed by third parties are subject to the same controls as internal assets.

CPS 230 (commenced July 2025) extends this to operational risk management and material service providers. If you classify our work as supporting a critical operation, we understand the contractual and security obligations that flow down to us as a vendor, and we can structure the engagement to meet them.

Privacy Act 1988 and the OAIC

We work within the Australian Privacy Principles under the Privacy Act 1988 (Cth), including the Notifiable Data Breaches (NDB) scheme administered by the Office of the Australian Information Commissioner (OAIC). We also track the ongoing Privacy Act reform programme, including the 2024 amendments introducing a statutory tort for serious invasion of privacy and expanded OAIC enforcement powers.

If your engagement requires a formal Privacy Impact Assessment (PIA), we can coordinate that through our legal advisors. See our privacy policy for full details on how we handle personal information.

Cyber Security Act 2024

Australia’s first standalone cyber security legislation commenced in May 2025. It introduces mandatory ransomware payment reporting for entities with turnover above $3M and establishes a Cyber Incident Review Board. For engagements where these obligations apply, we factor them into incident response planning and system design.

SOCI Act (critical infrastructure)

If your organisation operates in one of the eleven critical infrastructure sectors (energy, health, financial services, data storage, telecommunications, and others), your software vendors may fall within scope of the Security of Critical Infrastructure Act. We understand these flow-down requirements and can structure engagements accordingly.

IRAP (government engagements)

For Australian Government contracts, we understand the IRAP (Information Security Registered Assessors Program) assessment process. Where we deploy into a client’s cloud environment hosted on AWS or Azure in Australian regions, the engagement can inherit the provider’s IRAP certification, limiting the assessment scope to the application layer. This significantly reduces cost and lead time compared to a full independent assessment.

Industry-specific and emerging frameworks

Depending on your sector, additional frameworks may apply. These are the ones we encounter most often beyond the standards above:

• My Health Records Act 2012: applies to clinical software that connects to the national My Health Record system. We understand the conformance assessment requirements set by the Australian Digital Health Agency.
• DISP (Defence Industry Security Program): for organisations in the defence supply chain. DISP members must achieve Essential Eight Maturity Level 2 across ICT systems used to correspond with Defence. We can structure engagements to meet DISP security requirements.
• State and territory privacy legislation:Queensland’s Information Privacy Act 2009, Victoria’s Privacy and Data Protection Act 2014, NSW’s PPIP Act 1998, and the ACT’s Information Privacy Act 2014 each supplement the federal Privacy Act for state government data. Western Australia passed its own Privacy and Responsible Information Sharing Act in early 2025. If you’re a state agency or handle state government data, we factor the relevant legislation into the engagement.
• PCI DSS: if your system processes, stores, or transmits payment card data, PCI DSS compliance is mandatory. We understand the requirements and can architect payment flows to minimise your PCI scope, including tokenisation and third-party payment gateway integration that keeps card data off your infrastructure entirely.
• Consumer Data Right (CDR):Australia’s open data framework, administered by the ACCC, currently applies to banking and energy with telecommunications expanding. If your engagement involves CDR-designated data sharing, we can structure the build to meet the CDR rules and accreditation requirements.
• AML/CTF Act (AUSTRAC): systems that touch financial transactions may trigger reporting obligations under the Anti-Money Laundering and Counter-Terrorism Financing Act. We understand how these obligations affect system design, including transaction monitoring, record-keeping, and suspicious matter reporting requirements.
• SMB1001 (CyberCert):a tiered cybersecurity certification designed for Australian small and medium businesses, with five levels from Bronze through Diamond. It’s gaining traction as a recognised baseline in Australian procurement, and we see it as a practical stepping stone alongside the larger international frameworks.

How we approach data protection

When building for clients who handle sensitive data, these are the controls we apply. For projects with specific regulatory requirements, additional controls are scoped and costed as part of the engagement.

Encryption

Client data is encrypted in transit (TLS 1.2 or higher) and at rest (AES-256). Database connections, API calls and file transfers use encrypted channels.

Access control

Client engagements use least-privilege access across all environments. Multi-factor authentication is enforced. Production environments are isolated from development and staging, and access is reviewed regularly.

Code and deployment

For client builds, all code changes go through peer review before reaching production. CI/CD pipelines include automated vulnerability scanning, and production deployments require documented approval. No one pushes directly to production from a local machine.

Vendor assessment

We assess the security posture of third-party services before including them in a client project. Where we rely on cloud providers, AI APIs or data services, we verify their SOC 2 reports or equivalent certifications as part of the engagement.

Penetration testing

For production deployments that handle sensitive data, we include independent penetration testing as part of the project scope. This is conducted by third-party security firms, with results and remediation evidence provided to your team.

Deployment options

Not every engagement requires the same architecture. We offer flexible deployment models so you can choose the level of data custody that fits your compliance requirements. In many cases, the right deployment model can reduce or eliminate the need for expensive formal audits entirely.

In-situ deployment (inside your walls)

We deploy our code into your existing cloud environment: your AWS account, your Azure tenant, your GCP project. The data never leaves your perimeter. Your existing security certifications cover the infrastructure, and we operate as a software provider rather than a data processor. This is often the fastest path to satisfying your security team.

Managed compliant hosting

For organisations that want us to operate the platform, we can host on SOC 2 Type 2 compliant infrastructure with continuous monitoring, intrusion detection and audit logging built in. All data resides in Australian regions (Sydney or Melbourne). This adds a managed hosting component to the project quote.

Synthetic data during build

During development and testing, we work with synthetic or de-identified data that mirrors the structure and behaviour of your real data without containing any actual personal or sensitive information. Production data is only introduced at the point of deployment into a secured environment. This keeps the build phase entirely out of compliance scope.

Data privacy vaults

For engagements where sensitive fields (personal identifiers, financial records, health data) need additional isolation, we can route that data through a dedicated privacy vault. Your application only ever handles tokenised references, keeping the sensitive material out of scope for most audit controls.

Data residency

Many Australian organisations, particularly in finance, insurance and government, require that data stays on Australian soil. All managed hosting deployments use Australian cloud regions (AWS ap-southeast-2 Sydney or Azure Australia East). We can confirm in writing that no data egresses to offshore infrastructure.

Questions

If your procurement or security team wants to understand how we would approach a specific compliance requirement for a proposed engagement, contact us at admin@ardorlabs.dev.

We’re happy to join a call with your information security team, work through vendor security questionnaires, or scope out exactly what compliance adds to your project so there are no surprises.

Last updated: 1 April 2026