IRAP Assessment Preparation

Preparing for Your First IRAP Assessment: A Practical Checklist

Tech Blaze Consulting | February 2026 | 12 min read

Having conducted IRAP assessments for government agencies, defence industry participants, and critical infrastructure entities across Australia, the single biggest determinant of a smooth assessment is preparation. The organisations that invest in genuine readiness — not just documentation, but evidence, governance, and technical maturity — are the ones that achieve their target security posture without costly reassessments.

This article provides the practical checklist I wish every organisation had before their first engagement with an IRAP assessor. It is drawn directly from the patterns I see repeatedly: the gaps that delay assessments, the documentation that is always incomplete, and the technical controls that look good on paper but fall apart under scrutiny.

If you are preparing for your first IRAP assessment — or your last one did not go as well as you hoped — this is your starting point.

What an IRAP Assessment Actually Involves

An IRAP assessment is an independent evaluation of your ICT system against the Australian Government Information Security Manual (ISM). It is not a penetration test. It is not a vulnerability scan. It is a structured, control-by-control assessment of whether your system is fit for purpose at the required security classification level — typically PROTECTED, OFFICIAL:Sensitive, or in some cases SECRET.

The assessment is conducted by an ASD-endorsed IRAP assessor who evaluates your system against the applicable ISM controls, documents findings in a Security Assessment Report (SAR), and provides a recommendation on the system's suitability for processing, storing, and communicating government data at the target classification.

The assessment typically involves two stages: Stage 1 covers documentation review and assessment planning; Stage 2 covers technical validation, evidence collection, and testing. Both stages require your active participation.

Key point: The assessor is evaluating the system as it operates today, not as it is described in your documentation. If there is a gap between your documentation and your actual configuration, the assessor will find it. Configuration drift is the single most common source of findings.

Documentation Requirements: The Foundation

Your documentation is the first thing the assessor will request, and it sets the tone for the entire assessment. Incomplete or outdated documentation is the most common reason assessments stall or require additional time.

The System Security Plan (SSP)

The SSP is the cornerstone document. It describes your system — its architecture, components, users, data flows, interconnections, and the security controls implemented to protect it. Per ISM-0041, the SSP must be approved by the system's authorising officer and reviewed at least annually, or after significant changes.

Common SSP deficiencies I encounter:

Stale architecture diagrams — the system has evolved but the SSP still describes last year's design. Cloud migrations, new integrations, and decommissioned components are frequently missing.
Missing data flows — the SSP describes infrastructure but not how data actually moves through the system, particularly to external parties or cloud services.
Generic control descriptions — control implementations described as "we use encryption" without specifying algorithms, key lengths, certificate management, or protocol versions.
No system boundary definition — unclear what is in scope and what is not. This is particularly problematic for cloud and hybrid systems.

Statement of Applicability (SoA)

The SoA is your mapping of every ISM control to your system. For each control, you must state whether it is applicable, how it is implemented, or why it has been excluded. The ISM contains over 800 controls — your SoA should address every one relevant to your classification level.

The most common mistake is treating the SoA as a tick-box exercise. An assessor can tell immediately when someone has copied generic responses across multiple controls. Each implementation statement must be specific to your system.

Security Risk Management Plan (SRMP)

The SRMP documents your risk identification, risk treatment decisions, and residual risk acceptance. Per ISM-0038 and ISM-0039, security risks must be formally assessed and documented. The assessor will examine whether your risk treatments are proportionate and whether residual risks have been formally accepted by an appropriate authority.

Standard Operating Procedures (SOPs)

SOPs demonstrate that your security controls are not just designed but operational. The assessor will look for documented procedures covering access provisioning and de-provisioning, change management, incident response, backup and restoration, patching and vulnerability management, and media handling and sanitisation. Having a policy without a corresponding procedure is a common gap.

Technical Prerequisites: What the Assessor Will Validate

Documentation describes intent. Technical validation confirms reality. The assessor will examine your actual system configuration, not just your written descriptions.

Essential Eight Maturity

For most PROTECTED-level systems, the ISM expects Essential Eight controls to be implemented at a minimum of Maturity Level Two, and increasingly, Level Three is the expectation. The assessor will validate each of the eight strategies against the maturity model requirements — not just that you have the tools, but that they are configured correctly and producing the expected outcomes.

I regularly see organisations that have deployed application control software but have not tuned the rulesets, or have patching tools that report compliance but have not actually applied critical patches within the required timeframes. Tools are not controls. Configuration is what matters.

Network Segmentation and Architecture

ISM controls around network segmentation (ISM-1181, ISM-1577, ISM-0529) are among the most technically significant. The assessor will validate that security domains are properly segmented, that traffic between zones is controlled and monitored, that gateways are configured according to the ISM's gateway requirements, and that your architecture diagram matches the actual network topology. If you are operating a cross-domain solution or connecting to government networks, the segmentation requirements are particularly rigorous.

Logging and Monitoring

Centralised event logging is a non-negotiable requirement. Per ISM-0580 and related controls, you must be collecting security-relevant events from all in-scope systems, retaining them for at least 18 months (seven years for some classifications), and demonstrating that someone is actually reviewing them. A SIEM that collects logs but generates no alerts and has no documented triage process will be flagged. The assessor will ask to see sample alerts, escalation records, and evidence that your monitoring is operational — not just deployed.

Encryption and Key Management

For PROTECTED systems, the ISM prescribes specific cryptographic requirements. ASD Approved Cryptographic Algorithms (AACA) must be used for data at rest and in transit. TLS 1.2 as a minimum, with TLS 1.3 preferred. Key management must be documented, including key generation, distribution, storage, rotation, and destruction. Self-signed certificates in production are a finding. Expired certificates are a finding. Certificate management that relies on individuals remembering renewal dates is a finding.

Governance Requirements: The Human Side

Technical controls are only as strong as the governance that supports them. The assessor will evaluate whether your organisation has the structures, roles, and processes to sustain security over time.

Security Roles and Responsibilities

The ISM requires clearly defined security roles — a CISO or equivalent (ISM-0714), system owners, and an authorising officer who formally accepts the residual risk of operating the system. The assessor will verify that these roles are filled, that the individuals understand their responsibilities, and that there is evidence of active governance — security committee minutes, risk review records, and documented approvals.

Incident Response

An incident response plan must exist, be current, and have been tested. Per ISM-0043, the plan should cover detection, analysis, containment, eradication, and recovery. The assessor will look for evidence that the plan has been exercised — tabletop exercises, simulation results, or records of actual incident handling. An incident response plan that has never been tested provides limited assurance.

Change Management

Every change to the assessed system must go through a documented change management process that includes security impact assessment. The assessor will sample recent changes and verify that they were approved, that security impacts were considered, and that documentation was updated accordingly. Undocumented changes discovered during the assessment are a significant finding because they indicate that the system may have drifted from its assessed state.

Common Pitfalls: What Derails Assessments

After years of conducting IRAP assessments, these are the patterns that consistently cause delays, additional costs, or unfavourable findings:

Configuration Drift

The documentation says one thing; the system does another. This happens naturally over time as changes accumulate. The fix is to conduct a pre-assessment configuration review — compare your SSP descriptions against actual system state at least four weeks before the assessment begins.

Lack of Evidence

Telling the assessor you patch within 48 hours is not evidence. Showing them patching reports with timestamps is. Every control implementation claim must be backed by verifiable evidence: screenshots, reports, log extracts, configuration exports, or policy documents with approval signatures.

Incomplete Scope Definition

If you cannot clearly articulate what is in scope and what is not, the assessment cannot begin meaningfully. This is especially problematic for cloud and hybrid environments where the shared responsibility model means some controls are your responsibility and some are the cloud provider's. Define the boundary before the assessor arrives.

Treating the Assessment as a Point-in-Time Event

An IRAP assessment evaluates your security posture at the time of assessment, but the expectation is that controls are sustained over time. If the assessor sees evidence that controls were rushed into place the week before the assessment, that undermines confidence. Sustainable, business-as-usual security is what the assessment is looking for.

No Pre-Assessment Readiness Check

The most successful assessments I conduct are the ones where the organisation has done an internal readiness review first — or engaged us for an IRAP readiness assessment — before the formal assessment begins. This identifies and remediates gaps on your timeline, not the assessor's.

IRAP Assessment Preparation Checklist

Use this checklist to assess your readiness before engaging an IRAP assessor. Each item represents a common assessment prerequisite.

Documentation

System Security Plan (SSP) is current, complete, and accurately reflects the system as-built Statement of Applicability (SoA) maps every ISM control to your system with justified inclusions and exclusions Security Risk Management Plan (SRMP) documents identified risks, risk treatments, and residual risk acceptance Standard Operating Procedures (SOPs) exist for all security-relevant processes: access management, change management, incident response, backup and recovery Network architecture diagrams are current and show all trust boundaries, data flows, and external connections Asset register covers all hardware, software, and cloud services in scope Data flow diagrams document the movement of classified or sensitive data through the system Incident response plan has been tested within the last 12 months

Technical Controls

Essential Eight maturity assessment completed with evidence for the target maturity level Network segmentation implemented and documented between security domains and to external networks Centralised logging operational with minimum 18 months retention for security events (ISM-0580) Vulnerability scanning conducted within the last 30 days with remediation evidence for critical findings Multi-factor authentication enforced for all privileged access and remote access Encryption at rest and in transit configured per ISM requirements for the data classification level Hardening benchmarks applied to all operating systems and documented against ISM controls Backup and recovery procedures tested with documented recovery point and recovery time objectives

Governance

Chief Information Security Officer (CISO) or equivalent role formally appointed with documented responsibilities Security governance framework documented with clear escalation paths and reporting lines Change management process includes security impact assessments for all changes to in-scope systems Personnel security — all users with access to the system hold appropriate clearances or have been vetted per the security classification Third-party and supply chain risks assessed for all external service providers with access to the system Security awareness training delivered to all system users within the last 12 months with attendance records Continuous monitoring strategy documented covering vulnerability management, log review, and threat intelligence

What to Expect During the Assessment

Understanding the assessment process helps you prepare your team and allocate the right resources.

Stage 1: Documentation Review and Scoping

The assessor reviews your SSP, SoA, SRMP, and supporting documentation. An assessment plan is developed, and the scope is agreed. This stage identifies documentation gaps early. Allow two to four weeks for Stage 1, depending on system complexity.

Stage 2: Technical Assessment

The assessor validates controls through evidence collection, configuration review, interviews with key personnel, and technical testing. You will need to provide system access, demonstrate controls in operation, and supply evidence artefacts. Duration depends on scope but typically runs two to six weeks.

Security Assessment Report (SAR)

The assessor produces a SAR documenting all findings, the assessed maturity or compliance of each control, and an overall recommendation. Findings are typically categorised by severity, and a remediation plan may be provided for any gaps identified.

Post-Assessment

The authorising officer reviews the SAR and makes a risk-based decision on system operation. Any findings requiring remediation should be addressed within agreed timeframes. A Plan of Action and Milestones (POA&M) may be required for residual findings.

Practical tip: Assign a dedicated point of contact for the assessment — someone who has authority to grant access, gather evidence, and coordinate responses from technical teams. Assessments stall when the assessor is waiting for information from multiple people with no single coordinator.

Tech Blaze Consulting

Canberra, ACT

About the Author

Tech Blaze Consulting is a Canberra-based cybersecurity consultancy specialising in IRAP assessments, Essential Eight maturity assessments, and security advisory for government and defence industry clients. Founded by an endorsed IRAP assessor with over 20 years of GRC experience.

When you engage Tech Blaze, you work directly with the assessor — no account managers, no junior analysts, no handoffs.

Learn More About Us Back to All Articles

Related Services and Resources

This article is general guidance only and does not constitute formal security advice. Organisations should engage a qualified IRAP assessor for advice specific to their system and classification requirements.

Ready to Prepare for Your IRAP Assessment?

Whether you need a readiness check before your first IRAP assessment or a full assessment engagement, we can help you get there with confidence.

Get in Touch