IRAP is the gate into Australian Government SaaS spend.
Australian Government technology spend is significant, and an increasing share of it flows to SaaS. Commonwealth and state agencies have moved workloads away from on-premise systems and into managed services: collaboration, CRM, ITSM, analytics, identity, and more recently AI and automation tooling. Whenever those workloads touch PROTECTED data, the buying agency is bound by the Information Security Manual, and that forces a very specific set of expectations back onto the vendor.
The practical result: most Commonwealth and state tender documents for PROTECTED-touching SaaS now list a current IRAP report as a mandatory evaluation criterion. Not "desirable", not "preferred"; mandatory. Vendors without one are disqualified at shortlist.
The flow-down is expanding too. Defence primes, DISP members, and critical infrastructure operators under the SOCI Act increasingly pass IRAP expectations down to their SaaS suppliers. If you sell to a Defence integrator, an energy utility, or a Commonwealth-owned entity, you may need a PROTECTED IRAP report even if no agency signed your contract directly.
The commercial case is simple: without a current PROTECTED IRAP report, there is a tier of Australian Government SaaS revenue you cannot access. For some vendors that's a minor constraint. For SaaS companies targeting Australian Government as a core vertical, it's existential.
ISM controls are specific, prescriptive, and unforgiving.
PROTECTED is not a posture. It is a set of concrete ISM control requirements that apply to every component in scope: your application, your infrastructure, your identity plane, your logging, your support processes, and the people who can touch production. If you've been through SOC 2, ISO 27001, or HIPAA, the shape will feel familiar; the specifics are stricter and often awkwardly Australian.
The areas that catch SaaS vendors most often:
Each of these areas tends to produce multiple findings in a first-time assessment. None of them are technically hard in isolation. Collectively, they're six months of engineering work that doesn't show up on your product roadmap.
Most SaaS vendors underestimate by at least 2x on both dimensions.
Budget expectations for IRAP are distorted by the assessor fee being the only public number. The formal assessment is typically $80,000 to $250,000 for a PROTECTED SaaS system, depending on complexity and assessor firm. That's the visible line item. It is rarely the largest one.
The largest hidden cost is internal engineering time. Logging uplift, cryptography changes, identity rework, and the evidence base take serious senior engineering effort. Organisations that try to absorb it on top of product velocity tend to slip the timeline; those that carve out a dedicated squad usually land on schedule.
The second-largest hidden cost is the gap between Stage 1 and Stage 2. Findings from the design review must be remediated before the implementation review, usually in 6 to 12 weeks. Every week you're remediating is a week the assessor's clock is running and your engineers aren't building features.
The traps that don't show up in generic IRAP guidance.
Generic IRAP advice assumes a single-tenant, largely static system. Modern SaaS architecture is multi-tenant, rapidly deployed, and heavily dependent on third-party services. That combination creates failure modes the ISM and most assessors haven't fully modernised around.
- Multi-tenant isolation: Demonstrating that government and non-government tenants don't share plane, keys, or data is a recurring source of findings. Shared control planes, shared KMS keys, and cross-tenant admin tooling are hard to justify. Many SaaS vendors end up carving off a dedicated "gov cloud" environment to simplify the scope.
- Third-party subprocessors: Every Stripe, Twilio, Datadog, OpenAI, and Salesforce integration is a potential sovereignty and assessment issue. Each subprocessor needs to be mapped, assessed, and either brought in-scope, replaced, or explicitly excluded with a risk narrative the authorising authority will accept.
- Continuous deployment: Daily deploys are a feature commercially and a headache for ISM change-management controls. The fix is usually not slowing deployment; it's structuring change records, approvals, and evidence so they satisfy the control without throttling the release pipeline.
- Offshore SRE rotations: 24/7 support handed between US, EU, and APAC SRE teams works beautifully until the ISM asks who had access to production at 3am Canberra time. Personnel controls, MFA hardware key management, and privileged access workflows often need a clean-sheet redesign.
- AI features: LLM inference on customer data, RAG pipelines, model fine-tuning on government content. These create data-flow and sovereignty issues the ISM wasn't written for but that assessors are increasingly scrutinising. Expect to have to explicitly scope AI features in or out.
- Report ageing: IRAP reports are typically refreshed every 24 months. Fast-moving SaaS products drift quickly from the assessed baseline. Without a delta-assessment and change-governance discipline, your PROTECTED authority can lapse well before the formal re-assessment date.
Do ISO 27001 first. Usually.
There's no formal dependency between ISO 27001 and IRAP, but in practice the ordering matters. ISO 27001 forces you to build the governance structures, risk methodology, policy suite, asset register, and evidence discipline that an IRAP assessment will demand anyway. SaaS vendors who arrive at IRAP without an ISMS usually spend the first third of the programme building one anyway, just less deliberately.
A realistic sequence for most SaaS vendors:
- Months 1 to 6: Stand up an ISO 27001 ISMS. Gap assessment, policy suite, risk register, Statement of Applicability, internal audit. Pursue certification or operate the ISMS in parallel with IRAP readiness.
- Months 4 to 9: IRAP readiness gap assessment against ISM controls. Scope the system, choose classification target, identify architectural changes, prioritise the remediation roadmap.
- Months 6 to 12: Engineering uplift. Logging, cryptography, identity, evidence collection, change governance, personnel processes. This is where most of the budget goes.
- Months 12 to 15: Pre-assessment dry run. Engage an ASD-endorsed IRAP Assessor for Stage 1. Remediate findings.
- Months 15 to 18: Stage 2 implementation review. Security Assessment Report delivered. Authorising authority decision on the Authority to Operate.
Compressing this is possible for vendors with a mature security posture and deep engineering bench. Compressing it aggressively with neither tends to produce an assessment that reveals the gaps rather than closes them.
We get you ready. We don't do the assessment.
Cliffside is not an ASD-endorsed IRAP assessor firm. The ACSC endorses individual assessors, and we don't currently hold endorsed assessors on staff. What we do is the 90% of the programme that isn't the assessment: readiness, remediation, evidence construction, authorising authority liaison, and ongoing ISM alignment.
Our consultants have been ISO 27001 Lead Auditors since 2008, deliver Essential Eight assessments to Maturity Level 3, and have run security programmes for Commonwealth and state government clients. Most of our SaaS IRAP engagements start with a Lighthouse Assessment to map current controls against both ISO 27001 and the ISM, and honestly tell you whether your 9-month deadline is realistic.
When you're ready for the formal IRAP assessment, we help you shortlist and engage an ASD-endorsed assessor, brief them properly, and manage the assessment on your side. See our IRAP readiness and pre-assessment services for the full scope.