Skip to content

05 — IRAP Compliance: Architecture Requirements and Strategy

Research date: 2026-04-15

Security Classification Levels

  • OFFICIAL — Low business impact. Minimal controls beyond good practice.
  • OFFICIAL:Sensitive — Additional handling caveats. HR data with personal information of defence personnel almost always here.
  • PROTECTED — High business impact. Aggregated personnel data revealing capability/readiness may reach this level.

Recommendation: Target OFFICIAL:Sensitive, design for PROTECTED upgradeability. Downgrading controls is trivial; retrofitting is not.

ISM Controls for Web Applications

The ASD Information Security Manual contains ~870+ controls. Key groups for OFFICIAL:Sensitive/PROTECTED:

  • Web application security: Hardening, input validation, CSP, WAF
  • Cryptography: TLS 1.2+ mandatory, AES-256 at rest, HSM for key management at PROTECTED
  • Authentication: MFA mandatory, session management, credential storage
  • Access control: Least privilege, role separation, privileged access management
  • Audit logging: Comprehensive, tamper-evident, centralized, 7-year retention at PROTECTED
  • Network security: Segmentation, firewall rules, IDS/IPS
  • Vulnerability management: Patching within prescribed timeframes, penetration testing
  • Data recovery: Encrypted backups, tested restoration, geographically separated within Australia
  • Platform hardening: OS, database, web server baselines

Essential Eight Requirements

  • OFFICIAL: ML1 (basic implementation)
  • OFFICIAL:Sensitive: ML2 (consistent, some automation)
  • PROTECTED: ML3 (fully automated, hardened against sophisticated adversaries)

ML3 requires: Application control on all workstations/servers, automated patching within 48h for critical vulns, MFA with phishing-resistant tokens (FIDO2), privileged access with JIT, daily tested backups.

Data Sovereignty

Mandatory for OFFICIAL:Sensitive and above. ALL data must reside within Australia: - Primary databases - Backups - Logs and metadata - Transient data in caches, queues, CDN edge nodes - Queue messages and job data

Encryption Requirements

Layer Requirement
In transit TLS 1.2 minimum (1.3 preferred), perfect forward secrecy, no weak ciphers
At rest AES-256 for all persistent storage
Key management (PROTECTED) FIPS 140-2 Level 2+ HSM (AWS CloudHSM / Azure Dedicated HSM)
Key management (OFFICIAL:Sensitive) Managed KMS with Australian key residency
Backups Separate keys, independent rotation

Access Control

  • RBAC minimum, ABAC preferred for fine-grained control
  • Zero trust: verify every request, assume breach, least privilege
  • Privileged access: separate admin accounts, MFA, JIT elevation, session recording
  • Break-glass: documented, audited emergency access paths

Audit Logging

  • Log ALL: authentication events, authorization decisions, data access, modifications, admin actions, security events
  • Retention: 7 years at PROTECTED, minimum 2 years online
  • Immutability: Write-once storage (S3 Object Lock / Azure Immutable Blob)
  • Centralized: Separate hardened logging environment, SIEM integration

Multi-Tenancy Implications

  • Shared infrastructure between defence and non-defence is strongly discouraged at PROTECTED
  • Recommended: Separate database instances per defence tenant (not just schema separation)
  • Separate compute clusters or verified container/VM isolation
  • Defence tenants in isolated VPCs with no peering to non-defence
  • Practical approach: physically separate deployment stack for IRAP workloads

Hosting Options

IRAP-assessed at PROTECTED. Melbourne also available. No separate GovCloud in Australia — standard Sydney region carries assessment. Key services (EC2, RDS, S3, KMS, CloudHSM, CloudTrail, GuardDuty) all in-scope. Most commonly used for IRAP SaaS in Australia. Bedrock in Sydney gives you Claude.

Alternative: Azure Australia East/Central

IRAP-assessed at PROTECTED. Australia Central (Canberra) positioned for government workloads. Azure OpenAI available in Australian regions.

Google Cloud Sydney/Melbourne

IRAP-assessed at PROTECTED. Fewer government reference customers but technically viable.

Sovereign Cloud Providers

  • AUCloud — Built for government. PROTECTED-certified. 2-5x hyperscaler pricing.
  • Vault Cloud — Canberra-based, PROTECTED-certified.
  • Macquarie Technology GroupIRAP-assessed, government-grade physical security.

Sovereign clouds simplify compliance narrative. Defence clients more comfortable.

Not Viable

Fly.io, Render, Railway — no IRAP assessment, no sovereignty guarantees, no security frameworks.

Separate IRAP Version Strategy

Industry Standard: Separate Deployments

Common and expected. Nearly every SaaS vendor serving Australian government maintains separate deployment.

How Major Vendors Do It

  • Atlassian: Separate "Atlassian Government" environment
  • ServiceNow: Dedicated government instances, IRAP-assessed at PROTECTED
  • Salesforce: "Government Cloud Plus" — dedicated infrastructure, same application
  • Microsoft 365: Separate government tenancies with Australian data residency
  1. One codebase with feature flags for IRAP-specific controls (stricter sessions, mandatory MFA, restricted integrations, enhanced logging)
  2. Separate CI/CD pipeline with additional SAST/DAST, change management
  3. Separate infrastructure — dedicated VPC, database, logging, monitoring on AWS Sydney or sovereign cloud
  4. Separate operational processes — ISM-aligned change management, cleared personnel for admin

Feature Parity

IRAP version typically lags 1-4 weeks (rigorous change management). Some features permanently excluded (offshore data integrations, non-sovereign AI endpoints). Manageable with feature flags.

Cost

Item Range
Infrastructure 1.5-3x single deployment
Initial IRAP assessment \(150K-\)400K
Reassessment (every 1-2 years) \(80K-\)200K
Compliance staff \(200K-\)350K/year
Tooling (SIEM, scanning, pen testing) \(50K-\)100K/year
Total first-year additional \(500K-\)1M

Timeline

6-12 months preparation (gap analysis, remediation, documentation) + 2-4 months formal assessment. Total 9-18 months realistic.

IRAP + AI/LLM Considerations

Public APIs Are Not Allowed

Cannot use public Claude API or OpenAI API for IRAP workloads at OFFICIAL:Sensitive or above. Data sovereignty violation — prompts containing employee data inherit the data's classification.

Sovereign AI Options

Option Viability Notes
AWS Bedrock in Sydney Best path Claude models available. Runs within IRAP-assessed region. Data stays in your AWS account. No prompt/completion storage/logging by AWS.
Azure OpenAI in Australia East Viable GPT-4 etc in Australian regions. Same data sovereignty argument.
Google Vertex AI in Australia Viable Sydney region. Less mature LLM offerings.
Self-hosted models Most conservative Open-source LLMs on own infrastructure. Full control. Higher cost, lower capability.

Do AI Features Need Separate Assessment?

No separate assessment, but must be within scope. Assessor evaluates: data flows, processing, AI provider security posture, data leakage prevention. Using Bedrock/Azure OpenAI within assessed region inherits cloud provider's assessment.

Practical Approach

Design AI features to use AWS Bedrock (Claude via Sydney) or Azure OpenAI (Australia East). Feature flags route AI traffic differently between commercial and IRAP deployments. Commercial deployment can use direct Anthropic API; IRAP deployment uses Bedrock.

Real-World Examples

  • Employment Hero — Australian HR SaaS. IRAP-assessed, AWS Sydney. 12-18 months to assessment.
  • XeroIRAP-assessed for government financials. AWS Sydney.
  • TechnologyOne — Enterprise SaaS (including HR). IRAP-assessed at PROTECTED. Australian data centres.

Recommendations for Finnest

  1. Target OFFICIAL:Sensitive, design for PROTECTED
  2. AWS Sydney as primary hosting (strongest IRAP ecosystem + Bedrock for Claude)
  3. Single codebase, separate IRAP deployment behind feature flags
  4. Budget \(500K-\)1M first year for compliance
  5. Use AWS Bedrock for AI in IRAP deployment — no direct Anthropic API calls
  6. Start gap analysis now — 9-18 months to assessment readiness
  7. Engage IRAP assessor early for pre-architecture gap analysis

Sources

  • ISM Guidelines for Software Development March 2025 (cyber.gov.au)
  • Securing Software Supply Chain: ISM, IRAP, Essential Eight (chainguard.dev)
  • ASD IRAP Common Assessment Framework
  • AWS IRAP Assessment documentation
  • Azure Australia IRAP compliance
  • Employment Hero, TechnologyOne IRAP case studies