The assessment boundary for an IRAP assessment is the set of all system components, people, processes, and technologies to be evaluated as part of the assessment. It is defined by the IRAP assessor and agreed with the assessed entity’s delegate authority before substantive assessment work begins. The boundary must cover every applicable environment, document what is excluded and why, address data sovereignty and shared responsibility, and distinguish between what is being assessed and what the authorising officer will ultimately choose to authorise. Getting the boundary wrong at the start creates gaps that cannot be recovered cleanly at the reporting stage.
Stackform’s journey
James had spent the previous two weeks preparing Stackform’s system documentation. He had a list of what he thought the assessment would cover: the production environment, the application layer, and the database that stored OFFICIAL: Sensitive tenancy data for two Commonwealth clients. He brought this to the first working session with Cybernion’s assessor expecting it to be confirmed and signed off quickly. It was not.
The assessor asked about pre-production. James said it was a separate environment, not customer-facing. The assessor asked whether it held any real data for testing purposes. James paused. Some of it did. The assessor added it to the candidate scope list.
The assessor asked about the identity management system. James said it was a third-party service, already IRAP-assessed by the provider. The assessor said that was useful but the consumer’s configuration of that service, the access controls Stackform had applied and maintained, was still in scope. The prior assessment covered the provider’s responsibilities. It did not cover Stackform’s.
The assessor asked about privileged access. James described a jump server. The assessor asked what devices administrators used to connect to it. James named the corporate laptops. The assessor noted that if those devices had not been assessed separately, they would need to be addressed within this boundary, because a jump server does not contain the risk that comes from the underlying endpoint.
By the end of the session, the scope was considerably larger than James had anticipated. Not unmanageable, but not what he had written on his initial list.
Assessment Boundary vs Authorisation Boundary
These two terms are often used interchangeably by organisations preparing for IRAP. They are not the same.
The assessment boundary is everything the IRAP assessor will evaluate. It includes all system components and associated assessment objects: specifications, mechanisms, and activities.
The authorisation boundary is what the authorising officer chooses to authorise for operation within their organisation. It may match the assessment boundary exactly, or it may be a subset. An authorising officer might assess three services and choose to authorise two. What the authorisation boundary cannot do is exceed the assessment boundary. You cannot authorise something that has not been assessed.
Who defines the boundary and who agrees it
The IRAP assessor defines the assessment boundary. The assessed entity’s delegate authority agrees to it.
This is not the organisation presenting a scope and the assessor rubber-stamping it. The assessed entity may have a view, and that view is a useful starting point. The assessor’s responsibility is to validate whether that view is appropriate. If it is too narrow, the assessor must say so and document the reasoning.
The boundary can also change. As the assessment progresses and new information emerges, the assessor and delegate may need to revisit what has been included and excluded. This is expected and is not a sign that preparation was inadequate.
What an assessor must consider when defining scope
The IRAP Common Assessment Framework (CAF) identifies several dimensions the assessor must work through when determining what belongs inside the boundary.
- Environments: Production is the starting point but not the end point. Pre-production, test, and development environments each carry their own risk profile. If a non-production environment holds real data, or if its configuration materially affects the production system’s security posture, it warrants inclusion or explicit exclusion with justification.
- Data classification: The intended classification of data the system will store, process, or communicate determines the applicable ISM control set. For Stackform, that was OFFICIAL: Sensitive. The assessor used this to identify which controls applied and at what threshold.
- People, processes, technologies, and facilities: The boundary is not limited to servers and software. It includes the people who operate and administer the system and the processes they follow. Physical facilities relevant to system security are also in scope where applicable.
- End user computing devices: Where administrators connect to the system via privileged access, the devices they use are part of the security chain. A jump server provides some protection but does not eliminate the exposure created by a compromised endpoint. If those devices are not separately assessed, they sit inside this boundary.
- Third-party providers and shared responsibility: Where the system relies on services from a cloud or SaaS provider, the assessor maps out the shared responsibility model. Controls the provider is responsible for are addressed through the provider’s IRAP assessment, which the assessor will reference. Controls that sit with the consumer, including configuration, access management, and integration security, remain in scope for this assessment.
- Data sovereignty and offshore elements: The assessment report must address whether any data, including metadata, is processed, stored, or accessed outside Australia. This includes offshore staff with administrative access. Where these elements exist, the assessor must document them and address the applicable ISM controls.
Layering and what it means for Stackform
Stackform runs on a cloud infrastructure platform that holds an existing IRAP assessment. The identity provider used for single sign-on also has a current IRAP assessment report. These are relevant but they do not reduce Stackform’s scope to zero.
IRAP assessments can be layered. The cloud provider’s assessment covers the infrastructure layer and the provider’s responsibilities. A SaaS provider assessment, where one exists, covers the service layer. The consumer’s assessment, which is what Stackform is undertaking, covers the consumer’s responsibilities: how the system is configured, how access is managed, how data is handled, and how the consumer has implemented controls that sit in their part of the shared responsibility model.
The assessor reviewed the prior IRAP reports for the cloud and identity providers, noted the relevant findings, and documented what Stackform could rely on and what it could not. That reference work then shaped the scope of Stackform’s own control matrix.
Documenting Inclusions and Exclusions
A well-defined boundary requires both. Including something without explaining why it is in scope and excluding something without explaining why it is out of scope are both quality failures.
For every exclusion, the assessor documented the justification. The development environment that contained no real data and was isolated from production with no shared credentials was excluded on those grounds. The corporate network segment used only for internal business functions unrelated to the assessed system was excluded with an explanation of the segmentation controls in place. Each of these exclusions went into the assessment report so the authorising officer had a complete picture.
James found this discipline useful. It forced Stackform to be precise about what they were claiming was not in scope and why. In a few cases, reviewing the justification led to a decision to bring the component back in rather than try to defend the exclusion.
The Agreed Boundary
By the end of Stage 2, Stackform and the assessor had a documented, agreed IRAP assessment boundary. It covered the production environment, the pre-production environment where production data was present, the privileged access workstations, Stackform’s configuration of the cloud platform and identity provider, and the relevant people and processes. The development environment was excluded with documented justification.
That agreed IRAP assessment boundary became the reference point for every subsequent stage of the assessment. Control applicability, evidence gathering, sampling decisions, and the structure of the final report all flowed from it.
For now though, Stackform needed to collate all required documents and evidence for the assessment.
We cover that in How to Prepare for an IRAP Assessment.
Frequently Asked Questions (FAQs)
What is an IRAP assessment boundary?
The assessment boundary is all components of an information system to be evaluated as part of an IRAP assessment, including related specifications, mechanisms, and activities. It is defined by the IRAP assessor and agreed with the assessed entity’s delegate authority before assessment work begins.
How is the assessment boundary different from the authorisation boundary?
The assessment boundary is what the assessor evaluates. The authorisation boundary is what the authorising officer chooses to authorise for operation. The authorisation boundary may be equal to or smaller than the assessment boundary but cannot be larger. An organisation cannot authorise a system component that has not been assessed.
Can the assessment boundary change during the assessment?
Yes. The boundary may evolve as the assessor gains a more complete understanding of the system. The assessor is required to regularly review and validate the boundary with the assessed entity’s delegate throughout the assessment process.
Does an existing IRAP assessment of our cloud provider reduce our scope?
It reduces the scope of controls you are responsible for demonstrating, not the scope of the assessment itself. The provider’s assessment covers their responsibilities. Your consumer-layer assessment covers how you have configured and implemented services, managed access, and applied controls that sit on your side of the shared responsibility model.
What happens if something is excluded from the assessment boundary?
Exclusions must be documented with clear justification in the assessment report. A component cannot simply be omitted without explanation. The assessor must provide the rationale for the exclusion so the authorising officer can make an informed risk decision about whether they accept that boundary.
Sources:
- ASD IRAP Consumer Guide, July 2025
- IRAP Common Assessment Framework, April 2025
- Australian Government Security Classification System and Requirement 0109, PSPF 2025
The names of the organisations and individuals have been changed to protect their privacy. The situations described are based on real patterns observed across Australian government and enterprise environments.
Last updated: 05 June, 2026
Cybernion has helped multiple organisations with IRAP readiness and assessments.
Talk to us. We aren’t always chasing a transaction.