We prepare Australian organisations, and the suppliers that handle government information, for IRAP assessments. That means working out what has to be done before an assessment is worth starting, and then getting it done.
years providing security services in Australia and overseas
CREST ANZ approved company
Our client relationships commonly run ten to twenty years, and the longest has run for more than twenty.
Separation of duties is our standard baseline: We do not review a system that we built.
The assessment itself is carried out by a separate ASD-endorsed assessor. ASD’s independence rules require that separation, and where an organisation has real remediation ahead of it, the larger share of the work is in getting ready.
We have been doing information security work in Australia for 26 years. Our governance, risk and compliance practice covers ISO 27001, PCI DSS, the ACSC Essential Eight (soon to be replaced with the Essentials), CIS 18 and cyber maturity reviews, so the control sets an IRAP assessment works against are ones we work with every week in other frameworks. Evidence you have already built for ISO 27001 or the Essential Eight is rarely wasted.
Readiness work starts with working out what your system needs before it is ready to be assessed. Depending on where you start, the work includes:
When the system is ready, a separate ASD-endorsed assessor assesses it.
There are three important constraints that you should consider at the start of your compliance project: Firstly, assessors can only assess what is implemented, not what is planned; a plan is never a control. Secondly, the assessor will want to see what you have done so creating a document that just restates an ISM control will be counted as poor evidence. And finally, the assessor will want to see the evidence that proves the effectiveness of your controls, which documentation on its own does not provide. In summary then, your readiness work is only complete when you have controls that are fully implemented and for which you can demonstrate or otherwise provide evidence of effectiveness.
Our IRAP case study describes an 18-month program for a national provider of government services. The program was run in stages, where two dotSec experts worked with between four and eight of the client’s staff, at sites in Brisbane.
The gap analysis covered requirements from the Privacy Act, the PSPF and the ISM.
The program then implemented the relevant controls from the ISM and the PSPF. dotSec observed towards the middle of the project calendar that there were opportunities for improving how the project was managed, particularly as regards the timely delivery of material updates and changes. We took a more active role in running the project, set weekly progress updates, and involved the client’s executive. The program finished on time and on budget.
A separate assessor carried out the IRAP assessment. We did no assessment work on it. The government accepted the assessment report, and the department approved the system to operate, without issue.
ASD publishes a baseline preparation checklist in the IRAP Consumer Guide. Your assessor will give you a more specific list for your project
Agree the basics with your assessor
Have the documentation current and approved
Have the supporting evidence ready
Ask your assessor for an initial evidence list early, using the system security plan annex as the guide, and start collecting against it before the assessment begins. Prioritise evidence you can demonstrate over evidence you can only describe, for the reasons set out under What counts as evidence below.
ASD grades the evidence an assessor is given on four levels, and the grade determines what the assessor is able to conclude about a control:
1. Excellent. The assessor observes or tests the control operating first-hand. For example, the assessor tries to launch an application that policy says is blocked, and watches application control block it, rather than reading a document saying it would be blocked.
2. Good. The assessor reviews the live technical configuration through the system’s own interface and can see that it would enforce the expected policy.
3. Fair. The assessor is shown second-hand evidence, such as a copy or a screenshot of a configuration.
4. Poor. The assessor is given a policy document that restates the ISM control, or verbal confirmation that something is in place. Length does not rescue this. A twenty-page policy restating a control is still poor evidence.
Where an assessor cannot get adequate visibility of a control, the outcome is recorded as “no visibility”, and ASD notes that an authorising officer may reasonably treat that as ineffective from a risk perspective. A control you cannot evidence can be scored against you, much as a control you never implemented would be. so prepare to show controls working in a live system, not to describe them in a document.
An IRAP assessor has to be independent of the system they assess. Under ASD’s rules, an assessor cannot have contributed to the design or implementation of that system, and ASD names the disqualifying activities specifically: Drafting the system’s documentation, conducting an initial gap assessment, providing design recommendations, or holding a material interest. The rule applies regardless of separate reporting lines, different offices, or how long ago the earlier work was done; and it extends to corporate affiliates.
All of which is just normal separation of duties:
If a conflict emerges mid-assessment, ASD can require the assessor to disengage, transfer the assessment, or cease it altogether, and ASD carries none of the resulting cost. It is cheaper to settle this during scoping.
IRAP is the Infosec Registered Assessors Program, administered by the Australian Signals Directorate. ASD endorses individual assessors. Those assessors evaluate systems against the controls in the Information Security Manual (ISM) and produce an assessment report and a security controls matrix.
The program exists so that Australian government entities, and the suppliers that handle government information, can get an independent view of whether a system’s security controls are implemented and effective. Under the Protective Security Policy Framework, outsourced information technology systems, cloud services and gateways up to SECRET must be assessed by an ASD-endorsed IRAP assessor.
There are three things that IRAP assessment is not: It is not a process for certifying systems, it is is not an authority to operate, and it is not a maturity assessment since IRAP has no levels. Let’s look at those in more detail:
No. There is no certificate for ASD to issue. ASD endorses assessors; assessors assess systems.
So what do you end up with as the result of an IRAP assessment? An assessment report and a security controls matrix. Those go into an authorisation package, and an authorising officer inside the government entity whose information the system will handle uses that package to decide whether to grant an authority to operate. If granted, that authority is what lets the system handle government data. ASD issues no certificate, approval or authorisation for any system. Its role ends at endorsing the assessor.
If you have been told a product or platform is “IRAP certified”, the best case is that an assessment was completed. To be sure, ask which system was assessed, at what classification, and for the report and the matrix.
ASD’s IRAP policy and procedures (s6.2.6) states that publishing claims of IRAP or ASD certification, accreditation, endorsement, registration or authorisation to operate “is a misrepresentation of IRAP’s role, and will result in ASD requesting the immediate removal or recall of misleading statements”. If your website or collateral says “IRAP certified”, expect ASD to ask you to take the claim down.
No. The assessment produces findings, but the decision on whether or not to accept the residual risk and authorise the system is the responsibility of an authorising officer (normally the accountable authority or chief information security officer, or their delegate) of the government entity whose information the system will handle.
If a service provider owns and runs the system, the provider does not authorise it. Their government customer does, and only for use within that customer’s organisation. One assessment can therefore support several separate authorisation decisions, one per government customer, which is why ASD wants providers to hand over the report and the controls matrix rather than a summary letter. Each authorising officer runs their own decision on the same evidence, and they may authorise a narrower set of services than the assessment covered.
Under ASD’s rules, an IRAP assessor does not recommend for or against authorising a system, and does not rate risks on the organisation’s behalf. Deciding what level of risk is acceptable is the organisation’s job.
Trick question: There are none! What people usually mean when they say “levels” is the security classification of the information a system handles. Under the PSPF, the classifications can be OFFICIAL, OFFICIAL: Sensitive, PROTECTED, SECRET and TOP SECRET, and the classification drives which ISM controls apply.
IRAP assessors work up to SECRET. ASD’s own assessors assess TOP SECRET systems, with the Director-General of ASD as the authorising officer. If your system is TOP SECRET, assessment work is done directly by ASD rather than to an IRAP assessor.
If you are a service provider selling to government, ASD publishes the approved wording for describing a completed assessment:
“[Organisation] has completed an IRAP assessment for [System] against the Information Security Manual’s [Classification] level controls.”
The first condition for using that wording is to clearly list the specific services or system that were assessed. Secondly, you must not state or imply that your services are certified, authorised or approved by ASD, by IRAP or by the Australian Government, or claim certification or approval at a classification level. As an example, “PROTECTED certified” is the kind of thing to avoid.
Some providers offer prospective customers only a letter confirming that an assessment happened. That is not what ASD expects, and it is not enough for a buyer to make a risk decision on. Ask for the assessment report and the security controls matrix. Under PSPF Requirement 0043, government entities providing outsourced services must provide their IRAP assessment reports to the entities consuming or considering those services.
An IRAP assessment produces two artefacts:
ASD tells consumers to insist on both:
The report and matrix are part of the authorisation package, which is the set of documents an authorising officer uses to decide whether to authorise a system to operate.
At a minimum ASD expects that package to contain:
This is relevant to your readiness work for two reasons: Firstly, the assessment is one input among several, so an assessment on its own does not get a system authorised. Secondly, most of the other documents are yours to produce rather than your assessor’s, which is why they appear in the preparation checklist above and why they are part of readiness work.
Where a system is being sold to government, prospective buyers should receive the assessment report and matrix as a minimum, so they can make their own risk-based decision about the service.
ASD’s IRAP Common Assessment Framework sets out four stages that every IRAP assessment follows. Readiness work happens before stage 1.
Stage 1: Plan and prepare. Engagement planning, agreeing dates and milestones, identifying what access and evidence will be needed, and registering the engagement with ASD. The assessor must submit an assessment record and conflict of interest declaration to ASD at least seven business days before the assessment starts, whether or not a conflict exists. That is a hard gate, so an assessment cannot begin at a few days’ notice.
Stage 2: Define the assessment boundary. The assessor defines what is in scope and agrees it with your system owner, or whoever in your organisation holds delegated authority to sign off scope. This is where most of the argument happens in a hosted environment, and two terms are worth separating. The assessment boundary is everything the assessor examines. The authorisation boundary is everything the authorising officer signs off for operation. The authorisation boundary cannot be larger than the assessment boundary. That single rule is why a provider’s platform assessment does not cover your system: Your system was never inside the boundary that was assessed.
Stage 3: Assess the controls. The assessor collects and reviews evidence, examining, interviewing and testing to determine whether each applicable control is effective. Evidence quality drives what can be concluded. A policy document that restates an ISM control is weak evidence; a tested configuration is strong. Where an assessor cannot get adequate visibility of a control, that limitation goes in the report rather than being glossed over.
Stage 4: Produce the report. The assessor produces the assessment report and controls matrix, covering the boundary, the findings, the limitations that affected the assessment, and recommendations. Those recommendations are about controls, never about authorisation. The assessor describes the outcome a control needs to achieve rather than prescribing an implementation, so the decision about how to achieve it stays with you.
We manage AWS-hosted (we’re also a PCI DSS-compliant service-provider) services for clients under SLA. We can prepare systems hosted on cloud infrastructure and SaaS platforms, as well as hybrid arrangements where part of the environment is on-premises and part is not.
ASD describes IRAP assessments in cloud environments as layered:
While layer is relevant to you? That will depend on what you run. If you sell a SaaS product to government, you are at Layer 2 and your customer is Layer 3. If you are a government entity adopting someone else’s service, you are Layer 3.
Of course, there are exceptions and the stack is not always three-deep: Where there is no SaaS provider in the middle, there may be only two layers, and where a government entity resells a service to other government entities there may be four.
Major cloud and SaaS providers have probably had their platforms assessed. That covers their layer under the shared responsibility model. It says nothing about the layer above. Whoever owns that layer needs their own assessment of it, and each assessment report has to set out the shared responsibility model explicitly.
An IRAP assessment report is required to address data sovereignty, offshore equipment and staff, and any information, including metadata, held outside Australia. If part of your support model, offshore backup replication or telemetry, the assessor will examine and document it.
ASD’s IRAP Common Assessment Framework gives two examples of recommendations to consumers on data sovereignty: Firstly, a lockbox mechanism that stops provider administrators reaching your data without explicit authorisation. Secondly, a region lock that stops data leaving Australia.
An IRAP assessment describes a system at one point in time, and there are three things that can make it out of date: The use-by date, the ISM, and changes to your system.
The use-by date. Under PSPF 15.2, requirement 0109, cloud service providers must have had an IRAP assessment within the previous 24 months, against the ISM current at the time of assessment. That requirement is written for cloud service providers. If you are not a cloud service provider, confirm the expected reassessment cycle with the authorising officer for your system rather than assuming 24 months applies to you.
The ISM. The ISM is revised regularly, and assessors must use the latest release available when an assessment begins. A revision does not retrospectively invalidate an assessment already completed, but it does move the baseline that your next assessment will be measured against, and a long-running assessment may need a delta against the newer release before it concludes.
Your system. It’s possible that you may not need a full reassessment when a system changes materially. Depending on what has changed, the output may be a delta report, an addendum to the existing report, or a new assessment. Keep an eye on major system changes so that you are not overtaken by requirements and, for ongoing security work between assessments, see our vCISO services.
We do not publish a price for IRAP work, not because it’s special, secret sauce, but because such publication would be misleading or meaningless. You see, the scope of readiness work is driven by your System Security Plan Annex (SSP-A), which records the ISM controls that apply to your system and how each one is implemented. It is the system owner’s document, though we can prepare it with you as part of a readiness exercise. The classification of the information your system will handle (which your government customer determines) sets the baseline ISM controls. Your risk assessment then tailors them, and the authorising officer of the government entity you are contracting with approves the selection.
Until the SSP-A exists, nobody knows how many controls are in scope, how many systems and interfaces are involved, or how much of the environment is inherited from a platform assessment rather than yours to demonstrate. Those variables can change the effort by a factor of several, so a number quoted before the SSP-A exists is a guess, and you are the one who pays for it when the guess is wrong.
What we do instead of making up numbers: We scope against your SSP-A and your environment, then quote so you know the cost before the work starts.
If you need an indicative range for internal planning before scoping is complete, ask us and we will give you one, along with the relevant assumptions and caveats. If you do not have an SSP-A yet, we can start there. Remember: If we prepare your SSP-A, your assessment must be done by endorsed assessor, as set out under Independence above.
The program in our case study ran 18 months across more than 400 controls. A single well-bounded cloud system with a short SSP-A is a far smaller piece of work.
This is a bit of an aside, but people ask so… IRAP and ISO 27001 are different. ISO 27001 certifies a management system: It says you have a functioning ISMS with the processes to manage information security risk. An IRAP assessment examines a specific system against a specific control set. Existing ISO 27001 certification can help your IRAP program, because the governance and documentation are probably relevant, but ISO 27001 does not substitute for an assessment.
IRAP and FedRAMP are national equivalents in intent, not interchangeable in practice. FedRAMP is the United States authorisation program for cloud services used by US federal agencies. IRAP is the Australian assessment program against the ISM. FedRAMP authorisation does not transfer to Australian requirements, and Australian government entities will expect assessment against the ISM.
And finally, the ISM and the Essential Eight: These are different in scope. The Essential Eight (transitioning to the ASD Essentials) is a prioritised subset of mitigation strategies, useful as an uplift target. The ISM is a full control set.
Our client relationships commonly run ten to twenty years, and the longest has run for more than twenty. That is the part of our track record we point to first. We have been assessing and defending Australian systems for 26 years and we have a range of qualifications:
To be endorsed by ASD, an assessor must hold qualifications from both of ASD’s two categories: Category A (CISSP, CISM or GSLC) and Category B (CISA, PCI QSA or CRISC). They need a minimum of five years working with the ISM and PSPF, a security clearance, and a pass in ASD’s IRAP course and examination. Endorsement is renewed on a rolling 24-month cycle, and renewal requires submitting completed assessments to ASD for quality assurance review. Category B is the same control-testing discipline our PCI DSS practice works in daily.
IRAP assessors are not permitted to sign terms or non-disclosure agreements that would prevent ASD obtaining copies of assessment artefacts for quality assurance. If your standard NDA has a blanket bar on disclosure to third parties, your contracting team will need to add a carve-out for ASD’s quality assurance process before your assessment starts.
We are not the right choice if you want someone to tell you a system is fine or to give you a fixed-price quote without an assessment of scope. Readiness work has to hold up in front of an independent assessor, and we take our responsibility in that area most seriously.
We use the term “IRAP readiness work” to refer to the work that needs to be done before a system can be reasonably presented for an IRAP assessment: Establishing the SSP-A, a gap assessment against the applicable ISM controls, security architecture and design, remediation, testing, and preparing the documentation and evidence the assessor will ask for.
No, and that is not a dotSec quirk. Under ASD’s independence rules no assessor can do both on the same system, because contributing to it, including by drafting documentation, running an initial gap assessment or providing design recommendations, disqualifies them regardless of reporting lines or elapsed time. Another ASD-endorsed assessor can, and routinely does, assess a system that someone else prepared.
It depends on the gap between where your system is and what the SOA requires. The program in our case study ran for 18 months, in stages, across more than 400 controls. A well-bounded system with a narrow SOA takes far less.
Agree timelines, scope and the assessment boundary with your assessor, sort out access and any clearance checks, and make sure the right people are available during the assessment window. Then get your documentation current and approved, and collect the supporting evidence: Configurations, test results, logs, scan results, patching and backup restoration history. Ask your assessor for an initial evidence list early and work against it. ASD publishes a baseline checklist in the IRAP Consumer Guide.
The kind you can demonstrate rather than describe. ASD grades evidence from excellent, where the assessor tests the control first-hand, down to poor, which includes a policy document that simply restates the ISM control. Where an assessor cannot get adequate visibility of a control, it is recorded as “no visibility”, and an authorising officer may treat that much as they would treat a control you never implemented.
The system owner, which for a system you run means: You. The SSP-A records the ISM controls that apply to your system, based on the classification of the information it handles and your risk assessment, and how each control is implemented. The authorising officer of the government entity whose information the system will handle approves the selection of controls. We can prepare it with you, in which case your assessment goes to another ASD-endorsed assessor.
No. That is a normal starting position, and preparing it is the first job of readiness work.
An IRAP assessment is an independent evaluation of a system’s security controls against the Information Security Manual, carried out by an assessor endorsed by the Australian Signals Directorate. It produces an assessment report and a security controls matrix describing what was assessed, what was found, and what risks remain.
No. There is no IRAP certificate for a system, because there is nothing for ASD to issue. ASD endorses assessors; assessors assess systems. ASD’s policy is explicit that publishing claims of IRAP certification, accreditation or authorisation misrepresents the program, and ASD will ask for such statements to be removed.
ASD publishes approved wording: “[Organisation] has completed an IRAP assessment for [System] against the Information Security Manual’s [Classification] level controls.” List the specific services assessed. Do not claim certification, authorisation or approval by ASD, IRAP or the Australian Government, and do not claim it at a classification level either. “PROTECTED certified” is the form to avoid.
An authorising officer, normally the accountable authority or chief information security officer, or their delegate, of the government entity whose information the system will handle. The assessor supplies the findings and the evidence trail behind them; the authorising officer accepts the residual risk and grants the authority to operate. Assessors do not recommend for or against authorisation.
Because the authorisation is about their information, not your property. You own and run the system; the authority to operate covers the government entity’s use of it for their data. If you sell to several government customers, each one’s authorising officer makes their own decision, which is why ASD expects you to give prospective customers the assessment report and controls matrix rather than a letter. An authorising officer can also authorise a narrower set of your services than the assessment covered.
There are none. The relevant variable is the security classification of the information the system handles: OFFICIAL, OFFICIAL: Sensitive, PROTECTED, SECRET or TOP SECRET. IRAP assessors work up to SECRET. TOP SECRET systems go to ASD’s own assessors.
An IRAP assessment report and a security controls matrix. ASD’s guidance is to make sure you have both: The report supports the authorisation decision, the matrix gives your technical staff the control-by-control detail, including how responsibility splits between you and any external provider. Those two documents then form part of an authorisation package, alongside your system security plan, incident response plan, continuous monitoring plan and, where one applies, a plan of action and milestones. What ultimately lets the system run is the authorising officer’s decision on that package, not the assessment on its own.
It depends on the Statement of Applicability and the size and complexity of the system in scope. We do not publish a figure, because a number quoted before scoping is a guess. Once your SOA and environment are known, we quote fixed price or capped time and materials. The assessment is quoted separately by the assessor.
Because the number would not mean anything yet. The SOA determines which controls are in scope, and the architecture determines how much of the environment is yours to demonstrate rather than inherited from a platform assessment. If you need an indicative range for internal planning before scoping is complete, ask us and we will give you one, with the assumptions stated plainly.
There are two periods to plan for: Firstly, before the assessment starts, your assessor must lodge an assessment record and conflict of interest declaration with ASD at least seven business days beforehand, so nothing can begin at short notice. Secondly, once the assessment is under way, ASD lists scope, system complexity, the availability of your people and evidence, and the assessor’s familiarity with the environment as what drives its duration. The readiness work before the assessment usually takes longer than the assessment itself.
Almost always, yes, for the layer you own. ASD treats cloud assessments as layered: The infrastructure provider, then any SaaS provider built on it, then the government entity consuming the service. A platform assessment covers the provider’s layer under the shared responsibility model, not the layer above it. Whether your layer needs a full IRAP assessment or something narrower depends on the classification of the data, which layer you occupy, and what the authorising officer requires. That is a scoping conversation.
Yes. We can prepare systems on cloud infrastructure and SaaS platforms, including AWS and Azure, and hybrid environments, and we manage AWS-hosted services for clients under SLA. Defining the boundary between inherited and system-specific controls is part of the work.
Under PSPF 15.2, requirement 0109, cloud service providers must have had an IRAP assessment within the previous 24 months against the ISM current at the time of assessment. That requirement is written for cloud service providers, so if you are not one, confirm the expected cycle with your authorising officer rather than assuming 24 months. Separately, where a system changes materially between assessments, the output may be a delta report, an addendum or a new assessment.
It helps. The governance, documentation and risk-management practices carry over. It does not replace an assessment, because ISO 27001 certifies a management system while IRAP assesses a specific system against the ISM.
Talk to our team about your environment. If you already have a SSP-A, our team will start from that point; if you don’t yet have one, we will determine what is required.
