If you provide cloud services, SaaS, managed technology, or outsourced ICT to Australian Government entities, security assurance can become an important part of winning and maintaining government work. A buyer may require evidence that your system or service has undergone an appropriate IRAP assessment before it can be considered for certain environments.
IRAP stands for the Infosec Registered Assessors Program, administered by the Australian Signals Directorate. ASD endorses qualified security professionals to independently assess systems against relevant controls in the Information Security Manual, together with applicable government security requirements such as the PSPF.
Importantly, organisations do not become IRAP certified. Instead, a system or service completes an IRAP assessment against an agreed scope and relevant controls. The assessor documents security findings to support risk decisions, while the Authorising Officer decides whether the system can operate.
This IRAP compliance guide explains the requirements, assessment stages, evidence, VAPT, reporting, and what follows once the assessment is complete.
Who Needs an IRAP Assessment? The Target Sectors
An IRAP assessment is not a universal requirement for every Australian business that stores confidential or sensitive data. The PSPF primarily sets protective security requirements for Australian Government entities. Private companies are more likely to encounter IRAP when they provide technology or services to government under procurement conditions, contracts, deeds, outsourcing arrangements, or other security requirements.
The type of system also affects who can conduct the security assessment. Systems classified SECRET or below can generally be assessed by an entity assessor or an IRAP assessor. However, outsourced ICT systems and cloud services at these classifications require an IRAP assessor. TOP SECRET systems, including outsourced services, are assessed by ASD assessors or their delegates.
1. Cloud Service Providers and Managed Service Providers
Cloud and managed service providers are among the businesses most likely to encounter IRAP requirements when serving Australian Government customers. This can include hyperscale cloud providers, hosting companies, infrastructure suppliers, managed service providers, and specialist platforms built for government use.
For 2026 procurement, PSPF Requirement 109 is especially relevant. Before an entity relies on a cloud provider, it needs assurance that the provider has undergone an IRAP assessment recently and that the assessment reflects the current ISM. The permitted assessment age is 24 months. The ISM applies a similar recurring assessment expectation to relevant outsourced cloud and managed services handling information up to SECRET.
A procurement team therefore needs more than a statement that a provider is “IRAP assessed.” It should establish:
- When the assessment was completed
- Which ISM release formed the basis of the assessment
- What systems and infrastructure were inside the assessment boundary
- Which individual cloud or managed services were examined
- What findings and recommendations appear in the assessment report
The scope matters because an assessment of one cloud environment does not automatically provide assurance for every application, workload, configuration, or service running on it. ASD specifically advises customers to review assessment reports to understand what was actually examined and whether that scope meets their security needs.
2. SaaS and Technology Vendors
SaaS providers, data platforms, government software suppliers, and other technology vendors can also face IRAP requirements when their services process, store, or communicate Australian Government information.
Using infrastructure that has already undergone an IRAP assessment can reduce the number of underlying controls a SaaS provider needs to implement directly. It does not remove responsibility for the controls that sit within the vendor’s own service boundary. ASD cloud guidance recognises this shared responsibility model and requires government cloud consumers to consider their own responsibilities alongside those of the cloud provider.
Depending on the architecture and agreed assessment scope, the SaaS layer may need evidence covering areas such as:
- Application security
- Separation between customer tenants
- Identity and access configuration
- Privileged administrator access
- API security
- Security logging
- Software development controls
- Handling and protection of government data
For vendors, defining these responsibility boundaries early can prevent assumptions that an underlying provider’s assessment also covers the application built on top of it.
3. Defence and Government Supply Chain Organisations
Defence contractors, ICT subcontractors, gateway operators, and companies further down a government supply chain should determine their obligations from the actual engagement rather than assuming that every supplier needs the same IRAP assessment.
The PSPF requires government entities to manage security risks arising from procurement and to include suitable security obligations in arrangements with service providers, contractors, and subcontractors. Separate requirements can also apply when government information or resources are shared outside government through a contract, deed, or similar arrangement.
Your assessment trigger can therefore depend on the service you provide, the information classification, the system architecture, applicable ISM controls, and the security clauses imposed by the government customer.
Step by Step: The IRAP Assessment Process
ASD structures an IRAP assessment into four formal stages, with preparation and remediation around them.
Stage 1: Plan and Prepare
The first stage establishes how the assessment will be conducted. Before evidence collection starts, the organisation and assessor need a common understanding of the objectives, applicable government frameworks, people involved, resources, timing, and expected outputs.
Preparation usually includes making relevant material and access available, such as architecture diagrams, security plans, risk documentation, system accounts, technical specialists, and previous assessment information. The assessor also determines which assessment methods and testing activities may be required.
Independence must be addressed before the engagement proceeds. The IRAP assessor submits an assessment engagement form through ASD’s Partner Portal, together with a Conflict of Interest declaration. The Common Assessment Framework requires that declaration at least seven business days before the assessment begins.
Agreeing on scope, responsibilities, milestones, and deliverables at this point can prevent confusion once technical assessment work starts.
Stage 2: Define the Assessment Boundary
Next, the assessor determines exactly which parts of the system will be examined. The assessment boundary can include applications, infrastructure, interfaces, people, operational processes, supporting technology, and external dependencies that influence the system’s security.
For a SaaS platform, that boundary might contain:
- Customer portal
- APIs
- Administrative console
- Identity provider
- Cloud environment
- CI/CD infrastructure
- Logging platform
- External services
The assessment boundary describes what the assessor examines. The authorisation boundary describes the system or collection of components that the Authorising Officer may ultimately approve for operation. The authorisation scope cannot extend beyond the relevant assessed coverage.
Layered IRAP Assessments and Shared Responsibility
Complex cloud services can involve several connected assessment layers. ASD’s framework illustrates this through three common levels:
- The cloud infrastructure provider supplies and secures the underlying platform.
- The SaaS provider operates its service above that infrastructure and can draw on relevant evidence from the provider beneath it where controls are genuinely inherited.
- The consuming government agency evaluates its own implementation, configurations, and responsibilities when considering the service for use.
Control inheritance therefore needs to be established rather than assumed. Evidence from a lower layer can support controls managed there, while the SaaS provider still needs evidence for the security responsibilities it owns.
Stage 3: Assess the Security Controls
At this point, the assessor tests what actually exists within the environment. Written policies can support the review, but documentation alone does not establish whether a control works as intended.
ASD’s framework allows assessors to examine evidence, interview relevant personnel, and test mechanisms or operational activities. Depending on the control, this can involve configuration settings, historical records, security testing results, system behaviour, or samples taken across the environment.
Useful evidence could include:
- Patch history showing that remediation timeframes are routinely achieved
- MFA settings demonstrating the configured protection
- Retained logs showing how long records remain available
- Account lifecycle records for starters, role changes, and departures
- Security test results together with evidence that identified issues were addressed
Stage 4: Produce the IRAP Assessment Report
Once assessment activities are complete, the assessor converts the evidence and conclusions into formal deliverables.
For a standard engagement, the principal outputs are the IRAP Security Assessment Report and Controls Matrix. Cloud engagements use the corresponding Cloud Security Assessment Report and Cloud Controls Matrix.
The report gives decision makers a broader view of the assessed environment. It records matters such as the scope, system characteristics, security strengths, identified weaknesses, limitations, control outcomes, and recommended remediation.
The controls matrix goes deeper into individual ISM controls. It captures implementation details, assessment methods, supporting evidence, responsibilities, and the assessor’s conclusion about control effectiveness.
These documents record assessment findings. They should not be presented as a certificate, approval, or permission for the system to operate.
What Happens After the Assessment? Authorisation
Completing the report does not finish the government’s risk decision. Findings may first require remediation, followed by consideration of any security risk that remains after treatment.
Under PSPF Requirement 0086, the Authorising Officer decides whether the remaining risk is acceptable before the technology system begins processing, storing, or communicating government information.
The practical sequence is therefore assessment, remediation where necessary, evaluation of residual risk, and then an authorisation decision.
The IRAP assessor contributes evidence and security findings to that decision. Responsibility for approving operation sits with the designated Authorising Officer, rather than with the assessor.
The Essential IRAP Readiness Checklist
IRAP readiness depends on whether you can support your security controls with credible evidence. A written policy may show intent, but stronger preparation demonstrates that the control exists, has been applied correctly, and continues to work during normal operations. ASD guidance places significant weight on the quality of evidence used to support conclusions about control effectiveness.
Before reviewing individual areas, consider 3 evidence questions:
- Existence: Is the required security control or process actually in place?
- Implementation: Has it been configured, deployed, or carried out as intended?
- Operation: Can records from normal activity show that it continues to function consistently?
Use the following IRAP assessment checklist to organise the evidence your team may need before the assessment.
IRAP Assessment Readiness Areas & Preparation Checklist
| Readiness area | What your organisation should prepare |
| System definition | Current System Security Plan, service description, system ownership information, and relevant control mapping |
| Architecture | Logical architecture, trust boundaries, network diagrams, major integrations, and relevant physical architecture |
| Data | Information classifications, data flows, processing locations, storage arrangements, and backup flows |
| Risk | Security risk assessment, current risk register, treatment decisions, risk acceptance records, and approvals |
| Governance | Security policies, assigned control owners, responsibilities, governance records, and relevant approvals |
| Identity and access | Authentication settings, privileged access records, access approvals, account reviews, and user lifecycle evidence |
| Hardening | Approved security baselines, configuration standards, technical settings, and configuration exports |
| Vulnerability management | Vulnerability scan results, patch records, remediation tickets, approved exceptions, and outstanding issue tracking |
| VAPT | Testing scope, methodology, identified vulnerabilities, remediation records, and retest results |
| Logging | Relevant log sources, monitoring coverage, alert rules, retention settings, and operational security event records |
| Incident response | Incident response plan, exercise results, previous incident records, lessons identified, and completed improvements |
| Backups | Backup requirements, technical configuration, restoration procedures, and recovery testing results |
| Change management | Change requests, approvals, implementation records, and evidence of security review for relevant changes |
| Secure development | Code review evidence, SAST, DAST, SCA results, development procedures, and applicable CI/CD security controls |
| Personnel | Onboarding records, access approvals, security awareness evidence, assigned responsibilities, and applicable vetting records |
| Physical security | Facility, equipment, hosting, and physical control evidence relevant to the assessed environment |
| Third parties | Supplier agreements, assurance material, subcontractor details, allocated responsibilities, and supporting evidence for inherited controls |
| Cloud | Relevant CSP assurance material, shared responsibility records, inherited control evidence, and controls retained by your organisation |
| Continuity | Business continuity arrangements, disaster recovery procedures, exercise results, and corrective action records |
| Ongoing assurance | Continuous monitoring records, outstanding security issues, remediation ownership, target dates, and current POA&M where applicable |
The Critical Role of VAPT in IRAP Compliance
Technical testing gives an assessor direct evidence of how security controls behave when exposed to realistic threats. For organisations working through IRAP compliance requirements, VAPT can reveal weaknesses that documentation and configuration reviews may not expose.
A penetration test can strengthen the technical evidence available during an IRAP assessment, but it cannot replace the assessment itself.
IRAP examines a much wider security environment. Depending on the controls in scope, the review can extend across governance, personnel security, physical protections, cryptography, identity management, operational security, incident response, secure development, and other relevant ISM areas.
VAPT serves a narrower technical purpose. It helps determine whether vulnerabilities can be discovered, validated, or exploited under realistic conditions. A well-scoped test can therefore provide useful evidence about the effectiveness of controls protecting applications, infrastructure, identities, and data.
2026 ISM VAPT Requirements
The September 2026 ISM introduced an important change for organisations planning their security testing schedule.
Under ISM 2118 Revision 1, vulnerability assessments and penetration tests need to take place at three points:
- Before a system enters service
- Before a significant change is introduced
- At least once every six months after deployment
This is the current ISM baseline as of September 2026. Older guidance referring to annual penetration testing should not be treated as the present requirement for this control.
A six month penetration testing cycle does not remove the need for regular vulnerability scanning. The ISM sets much shorter scanning intervals for several technology categories.
Vulnerability Scanning vs Vulnerability Assessment vs Penetration Testing
These activities serve different purposes within a security assurance program.
| Activity | Main purpose |
| Vulnerability scanning | Uses automated tools to identify known weaknesses, missing patches, and insecure conditions |
| Vulnerability assessment | Examines identified weaknesses more broadly to understand validity, exposure, and potential impact |
| Penetration testing | Uses controlled attack techniques to determine whether defined security objectives can be compromised |
| IRAP assessment | Independently examines applicable security controls and the evidence supporting their implementation and effectiveness |
ASD distinguishes penetration testing from broader vulnerability discovery by noting that penetration testing works toward defined attack objectives, such as gaining access to important systems or information.
The four activities therefore work together. One cannot be treated as a substitute for the others.
What Should an IRAP-Focused Penetration Test Cover?
For a SaaS platform or cloud service exposed to the internet, penetration testing should follow the real attack surface and system design rather than a standard list applied to every environment.
Depending on the architecture and threat profile, useful coverage may include:
- Public-facing infrastructure
- Authenticated and unauthenticated application functions
- APIs
- Login and session controls
- Horizontal privilege escalation
- Vertical privilege escalation
- Tenant separation
- Administrative interfaces
- Cloud configuration
- Identity and privilege pathways
- Exposed services
- Network segmentation
- Sensitive data flows
- Federated identity
- Security logging and detection visibility
- Relevant attack paths involving third party services
The final scope should reflect the system architecture, credible threats, sensitive assets, and the assessment boundary already established for the engagement.
From Finding to Assessor-Ready Evidence
A penetration test is more useful during an IRAP assessment when each finding has a clear record of what happened next.
Keep evidence of:
- The original vulnerability
- Remediation actions
- Proof of the fix
- Retest results
- Any approved residual risk
Navigating ASD’s Emerging Essentials Series
In June 2026, ASD opened consultation on a proposed Essentials series that would expand the current Essential Eight approach. The planned guidance is intended to provide prioritised, threat-informed mitigations drawn from the ISM and adapted to different technology environments.
The first proposed chapter, Essentials for enterprise IT, is expected to build on the existing Essential Eight, with additional Essentials guidance planned for other environments. For now, the Essential Eight remains available as current ASD guidance.
Organisations preparing for an IRAP assessment should therefore base their IRAP compliance requirements on the current ISM and applicable PSPF obligations rather than trying to anticipate an unfinished framework.
A mature readiness program should also focus on evidence, control effectiveness, and changing risk. That makes it easier to absorb future ASD updates without rebuilding the entire security program each time guidance changes.
Accelerating IRAP Readiness With Qualysec
Qualysec is a specialized penetration testing company that can support organisations preparing for an IRAP assessment by testing the technical systems included within their assessment scope.
Businesses searching for IRAP certification Australia should keep one distinction clear. Qualysec can provide technical security testing and supporting evidence, but the formal IRAP assessment must be carried out by an ASD endorsed IRAP assessor.
IRAP Focused Technical Security Testing
The testing scope can be aligned with the technologies and attack surfaces relevant to your environment. Depending on the system, Qualysec can assess:
- Web applications
- APIs
- Cloud environments
- Mobile applications
- External networks
- IoT systems
Testing is designed to uncover security weaknesses, validate their impact, and give your team clear technical findings that can support wider assessment preparation.
Creating Useful Technical Evidence
A useful VAPT report should help both security teams and developers understand what was found and what needs to change.
Qualysec reports can provide:
- Confirmed vulnerabilities
- Severity and risk context
- Reproduction details
- Supporting technical evidence
- Remediation recommendations
- Retest status
This gives your team a traceable record showing how technical weaknesses were identified, addressed, and checked again before the wider IRAP control assessment.
Remediation and Retesting Support
Finding a vulnerability is only part of the work. Qualysec also provides remediation guidance and retesting after fixes are applied. Retesting checks whether the original weakness has been resolved and gives development teams updated evidence of the result.
Addressing technical findings early can reduce avoidable open issues when the formal assessment begins and give your team clearer evidence for controls supported by penetration testing.
If technical findings are still open before the IRAP review, Qualysec can help verify the affected systems, support remediation, and retest completed fixes. Speak with Qualysec to plan testing around your assessment scope.
Conclusion
IRAP preparation is much easier when security records are maintained as part of normal operations instead of being collected only when an assessment is approaching. Keeping controls current, fixing weaknesses promptly, and retaining clear evidence also makes future reviews easier to handle.
The September 2026 ISM strengthens the need for ongoing assurance, including recurring security assessments and continuous monitoring of systems.
For organisations working with Australian Government systems, IRAP readiness should be treated as regular security work rather than a one-time compliance exercise.
FAQs
What is the difference between an IRAP Assessor and a Penetration Tester?
An IRAP assessor is an ASD endorsed professional who evaluates applicable security controls against government requirements. A penetration tester focuses on finding and validating technical vulnerabilities through security testing. Penetration testing may support an IRAP assessment, but it serves a different purpose.
How long does an IRAP assessment typically take?
There is no standard timeframe set by ASD. The duration depends on the system size, assessment scope, control coverage, evidence quality, technical complexity, and stakeholder availability. Well-prepared documentation and accessible evidence can help the assessment progress more efficiently.
Is an IRAP assessment a one-time certification or a recurring mandate?
An IRAP assessment is not a one-time certification. Requirements vary by system and service, while certain cloud providers, managed services, and gateways require reassessment at least every 24 months under the current ISM. Significant changes may also trigger further security review.
