SOC 2 Won't Clear an Australian Government Deal - What IRAP Actually Is for US SaaS

An Australian federal agency or government contractor drops 'IRAP' into a tender pack or security questionnaire. You already hold SOC 2 - maybe a Trust Center page that lists AWS or Azure as 'IRAP assessed' too. The instinctive reply is that your US attestation, or the hyperscaler's assessment, should clear the gate. For Australian Government information at OFFICIAL: Sensitive or above, that reply is wrong, and it can stall the deal while the buyer waits for an assessment you have not scoped yet.

This post is for growth SaaS founders, Heads of Sales, and lone compliance owners selling (or bidding) into Australian federal agencies and government contractors who suddenly see IRAP on a security pack - especially teams that already invested in SOC 2 and need a clear read on what else is required. If you are searching for how an IRAP assessment SaaS engagement actually works for a US vendor, the short version is below: what IRAP is, why SOC 2 and hyperscaler coverage do not substitute, when the ask shows up, and a practical playbook that keeps Trust Center language accurate.

Short answer: what is IRAP for a US SaaS?

IRAP is an assessment, not a certificate. Under Australia's Infosec Registered Assessors Program, an ASD-endorsed assessor evaluates one defined system against the Australian Signals Directorate Information Security Manual (ISM). The deliverables are a security assessment report and a controls matrix. There is no IRAP pass mark and no IRAP certificate. Each consuming agency's authorising officer decides whether to grant an authority to operate on that evidence (Cybernion, 21 Jun 2026 / updated 3 Jul 2026; Frontrow, 19 Jul 2026; ASD consumer framing those pieces summarise).

SOC 2 is a different artifact for a different buyer. It is a licensed CPA firm's attestation against the AICPA Trust Services Criteria - valuable for commercial diligence worldwide, including Australian private-sector buyers, but it does not replace an IRAP assessment when the Protective Security Policy Framework expects outsourced IT and cloud services that store, process, or communicate Australian Government information at OFFICIAL: Sensitive or above to be IRAP assessed before an agency uses them (Cybernion IRAP vs SOC 2, 3 Jul 2026).

When does IRAP hit a US SaaS deal?

The trigger is the data and the buyer, not your HQ country or headcount. Cybernion's SaaS/cloud framing (21 Jun 2026) is blunt: if the service stores, processes, or communicates Australian Government information at OFFICIAL: Sensitive or above, an agency cannot use it until it has been IRAP assessed. A ten-person startup on a single hyperscaler tenancy sits in the same obligation family as a large vendor. What changes is boundary size and evidence volume - not whether IRAP applies.

You typically see the ask when:

• An Australian federal agency (or a prime contractor feeding one) puts IRAP language in a tender or onboarding pack for a product that will hold government data at OFFICIAL: Sensitive, PROTECTED, or higher.
• Procurement or security reviewers ask whether a current IRAP assessment exists for your service and at what classification level.
• A buyer assumes your AWS/Azure/GCP 'IRAP assessed' badge means your SaaS is covered - and you need a clear shared-responsibility answer before the review stalls.

Not every Australian commercial deal needs IRAP. Plenty of private-sector Australian buyers stop at SOC 2, ISO 27001, or questionnaire packs. Do not invent a rule that 'every Aussie deal needs IRAP.' Treat the tender and the agency's classification decision as the source of truth for that opportunity.

IRAP vs SOC 2 (and why you cannot swap reports)

Cybernion's comparison (3 Jul 2026) is the clean table to keep in your AE playbook:

Can you reuse SOC 2 work for IRAP? In part. Policies, access reviews, change management, monitoring, and incident response habits reduce documentation wait time - which is where much IRAP prep cost lives. What you cannot do is hand the SOC 2 PDF to an agency that asked for IRAP and call it done. The ISM is more prescriptive, revised through the year, and carries Australian Government requirements the TSC does not address (Cybernion, 3 Jul 2026).

For the broader pattern of SOC 2 versus buyer questionnaires - and why a report alone rarely closes diligence - see SOC 2 vs security questionnaires.

Hyperscaler IRAP is not your SaaS IRAP

This is where US founders lose weeks. A hyperscaler's IRAP assessment covers its infrastructure layers - physical data centre, hardware, hypervisor - not your application, tenant configuration, identity model, data handling, or logging. Cybernion (21 Jun 2026) maps the shared-responsibility / Cloud Controls Matrix line clearly: AWS or Azure being assessed at PROTECTED does not make a SaaS built on it PROTECTED. You inherit what the platform owns; you still assess what you own.

Frontrow (19 Jul 2026) notes the same commercial implication for Microsoft 365 / Azure stacks: platform reports (for example Microsoft's March 2026 IRAP publications covering Azure, Microsoft 365, and Dynamics 365 up to PROTECTED) shrink your boundary to the layers you control - they do not erase the need for your own assessment when your product touches government data.

Classification, boundary, and the Essential Eight trap

Confirm the classification the buyer actually needs before you scope PROTECTED by default. Cybernion (21 Jun 2026) and Frontrow (19 Jul 2026) both stress that the owning agency sets classification; common commercial cloud scopes are OFFICIAL: Sensitive or PROTECTED. Overscoping adds clearance, physical, and network overhead you may never recover if buyers only need OFFICIAL: Sensitive.

Tighten the assessment boundary to the product or environment that touches government data. Scoping the entire platform when only one product path is in play inflates control count and cost (Cybernion, 21 Jun 2026). A defensible boundary is usually the cheapest decision you make - and you make it early.

Essential Eight Maturity Level 2 is a head start, not IRAP-ready. Frontrow (19 Jul 2026) is explicit: Essential Eight covers eight mitigation strategies; an IRAP assessment tests the much broader ISM catalogue (personnel security, system documentation, and more). Strong Essential Eight maturity helps; it does not substitute for an ISM-scoped gap assessment. This post does not deep-dive Essential Eight - treat it as readiness context only.

ASD publishes no fee schedule. Frontrow (19 Jul 2026) notes ASD recommends obtaining at least three quotes and that published price bands vary too widely to cite responsibly. Do not invent cost ranges here. Drivers that do move price: classification level, boundary size, documentation maturity, remediation mid-assessment, and architecture complexity.

Practical playbook for US SaaS (Workstreet framing)

1. Confirm classification with the buyer / agency - OFFICIAL: Sensitive vs PROTECTED (or higher) - before you brief an assessor.
2. Define a tight boundary around the systems, data flows, and environments that will hold Australian Government information.
3. Reuse SOC 2 evidence habits for documentation uplift (policies, access reviews, change, monitoring, IR), but plan a separate IRAP engagement with an ASD-endorsed assessor. Workstreet does not replace that assessor.
4. Put accurate language on your Trust Center - 'current IRAP assessment at [level]' with dates and scope notes - never 'IRAP certified.' ASD ceased certifying systems in 2020; assessors notice the myth (Cybernion, 21 Jun 2026; Frontrow, 19 Jul 2026). Packaging that language next to SOC 2 is the same Trust Center discipline covered in building trust with a company trust page.
5. Train AEs on the 24-month cloud reassessment expectation. PSPF requirement 0109 / ASD cloud guidance expect cloud services to have been assessed within the previous 24 months against the latest ISM at assessment time (Cybernion, 21 Jun 2026). Treat the gap between assessments as continuous posture work, not a rubber stamp.
6. Answer questionnaires with verifiable specifics - classification level, assessment date, assessor firm, boundary summary, and hyperscaler shared-responsibility note - not 'we are SOC 2, so we are fine.' SIG-style packs and custom AU government forms still need consistent answers; see SIG questionnaire for the broader questionnaire pattern.

How IRAP differs from Cyber Essentials, FedRAMP, and NIS2

Same extraterritorial-buyer family - different country and different artifact. Do not answer an Australian IRAP question with a US federal or UK/EU narrative.

Holding FedRAMP does not produce an IRAP report. Holding Cyber Essentials does not authorise Australian Government cloud use. Keep the stacks separate in RFPs and Trust Center tiles.

Soft next step

If Australian tenders and questionnaires are asking for IRAP while your team is still answering 'we have SOC 2' or 'our hyperscaler is IRAP assessed,' the first commercial fix is usually a scoped readiness plan plus accurate Trust Center and questionnaire language - then an engagement with an ASD-endorsed assessor when the buyer and classification justify it. Workstreet's primary help here is security questionnaire automation so classification, assessment date, boundary notes, and shared-responsibility wording stay consistent across AU government packs. For program ownership on uplift and AE enablement, a light vCISO lane can keep the work from landing on the founder the week before a tender closes. That is packaging and readiness help - not a claim that Workstreet issues IRAP assessments or that SOC 2 replaces IRAP for Australian Government buyers.