IRAP Compliance & Chaos: Why Your Authorisation Boundary Could Be The Most Expensive Line You Will Ever Draw

Are you a system engineer, business analyst, or audit professional who has just been told to prepare a system for an IRAP assessment?

If you have looked at a System Security Plan (SSP) template and felt immediately overwhelmed, you are not alone. The confusion usually stems from one fundamental missing piece: You haven’t drawn the line yet.

In the world of security compliance, managed services, outsourcing and complex control inheritance models, that line is called the System Authorisation Boundary.

In simple terms, this boundary defines the limits of what you are claiming to secure. It sets the scene for everything that follows such as control selection, implementation, monitoring, and the assessment itself.

Get this boundary wrong, and your audit scope will balloon faster than your cloud bill. Get it right, and you create a defensible, auditable, and commercially viable security perimeter.

What Exactly is a System Authorisation Boundary?

Think of your system as a box. Everything inside the box is your responsibility, you must implement, maintain, and evidence controls for it. Everything outside the box is someone else’s problem (or an acceptable risk).

A comprehensive boundary typically encompasses five key areas:

1. Technology: Servers, VMs, containers, APIs, applications, and middleware.
2. Data: The actual information (stored, processed, and transmitted) and its classification (e.g., PROTECTED).
3. Processes: Key workflows like patching, monitoring, incident response, and vulnerability management.
4. Cloud Services: The underlying compute, storage, databases, networks and services you consume.
5. People: End users, system admins, and support staff who touch the system.

The “Chaos” Factor: After completing countless IRAPs and ISM-based assessments, I can tell you that a poorly defined boundary is the #1 cause of stress. It leads to “surprise” findings where an assessor discovers a forgotten API or database, leaving your engineering team scrambling to retrofit security controls and update documentation mid-audit.

How to Define Your Boundary (The “ConOps” Method)

Don’t start with a SSP-A (a spreadsheet of 1000+ controls). Start with the purpose of the system.

The best place to capture this is in a System Concept of Operations (ConOps). This is a high-level document that tells the story of your system before you get bogged down in the technical weeds.

What Goes into a ConOps?

If you are drafting this document, ensure it covers these seven areas:

1. Document Overview: The intent of the artifact (supporting system authorisation/IRAP).
2. System Overview: A concise “elevator pitch” of what the system does and the business function it supports.
3. Roles and Responsibilities: Who is the System Owner? Who is the Authorising Officer? Who is on the hook for Incident Response?
4. Operational Environment: The business and technical context in which the system operates.
5. The Boundary Definition: A text-based definition of what is in-scope vs. out-of-scope. Crucially, this must reference a diagram with a clear red perimeter line.
6. Operational Scenarios: Day-to-day workflows. How do admins log in? How do users access data?
7. Interfaces & Connections: Every API, pipe, or portal that crosses your red line must be identified.

The 3 Most Expensive Boundary Mistakes

The most expensive system authorisation boundary mistakes when teams attempt to define a system boundary for the first time, often fall into one of three common traps.

1. Over-Scoping (“Just in Case”)

It is tempting to include your entire corporate network “just to be safe.” Do not do this. Including systems that have no impact on the security of the systems data simply increases your compliance burden. You will end up paying an assessor to review your corporate HR portal or internal Wi-Fi, identifying non-compliances that have nothing to do with the product you are trying to sell.

2. Under-Scoping (“The Toaster Approach”)

Conversely, trying to shrink your scope to the size of a toaster to avoid scrutiny will backfire. If an IRAP assessor discovers you have excluded critical dependencies (like your identity provider or a logging server), they will drag them back into scope. Since you haven’t prepared those components, you will likely face a wave of “Ineffective” or “No Visibility” findings.

3. Ignoring the Shared Responsibility Model

If you build on AWS, Azure, or Salesforce, you dramatically reduce your compliance footprint, but you don’t eliminate it. Caution: Just because you deploy on an IRAP-assessed cloud does not mean your system is automatically compliant. You must understand the “demarcation point”, what the Cloud Service Provider does for you, and what you must do for yourself.

Summary: Draw the Diagram

If there is one takeaway from this blog, it is this: If it’s not in a diagram, it cannot be authorised.

Draw a network diagram. Draw a data-flow diagram. If you are unsure, draw another one. A visual representation of your boundary is the fastest way to build trust with an assessor and reduce audit fatigue.

Ready to draw your line? Start by defining the boundary to stop the chaos before it starts.