How to Build a Defensible SoA by Linking Architecture, Threats, Controls, Evidence, and Residual Risk

For many organisations, the Statement of Applicability is one of the last documents produced before an assessment. That is usually the first mistake. The second mistake is treating the Statement of Applicability, commonly called the SoA, as a compliance spreadsheet rather than the output of security engineering.

By the time an assessor reviews an ISM Statement of Applicability, the document already tells a story. It shows whether the organisation genuinely understands its system, threats, operational environment, and protection requirements, or whether the SoA was assembled retrospectively to satisfy governance expectations.

Weak SoAs tend to have the same symptoms. Controls are marked as applicable because someone inherited a baseline. Rationales are generic. Architecture is missing. Threats are implied but not explained. Non-applicable controls are avoided because teams fear scrutiny. The result is a document that appears complete but contains very little defensible reasoning.

That is not just a documentation problem. It is a systems engineering problem.

A mature SoA does not simply answer the question, “Which controls did we implement?” It answers a more important question: what conditions exist within this system that require protection, and what engineering decisions were made to address them?

That is a fundamentally different exercise.

What is an ISM Statement of Applicability?

An ISM Statement of Applicability is a document that explains which Australian Government Information Security Manual controls apply to a system, which controls do not apply, how applicable controls are implemented, and what evidence supports those decisions.

A strong SoA should not read like a simple control checklist. It should demonstrate clear traceability between the system’s architecture, assets, business functions, threat conditions, plausible loss events, protection objectives, applicability decisions, implementation evidence, and residual risk.

When that traceability is missing, the SoA becomes administrative theatre. It may look complete because every control has an answer, but it does not provide meaningful assurance. A defensible SoA must show not only what decisions were made, but why those decisions are appropriate for the system being assessed.

Quick Answer: What Makes a Good Statement of Applicability?

A good Statement of Applicability is defensible, contextual, and traceable.

It should explain:

• What the system does
• What assets the system protects
• What threat conditions are credible
• What loss events must be prevented
• Why each control is applicable or not applicable
• How each applicable control is implemented
• What evidence supports implementation
• What residual risk remains

The best SoAs are not the longest. They are the clearest.

Why Compliance-Driven SoAs Fail

Many organisations build the Statement of Applicability from the outside in. They begin with the ISM control catalogue, inherit a baseline, and then work backwards to justify exceptions. In that model, the system becomes secondary to the framework. Architecture is only discussed where it affects implementation scope, and threat modelling, if performed at all, is often disconnected from applicability decisions.

This creates the wrong sequence. Controls start driving the organisation’s understanding of the system, instead of system understanding driving control decisions. That is backwards.

A control is not applicable simply because it exists in the ISM. A control is applicable because a system performs a function within an operational environment, involves assets requiring protection, is exposed to credible threat conditions, and could produce consequences that matter. Without that reasoning chain, applicability becomes performative rather than defensible.

The difference between compliance thinking and engineering thinking is significant. Compliance thinking asks, “Have we addressed the control?” Engineering thinking asks, “What loss are we trying to prevent, and is this the right control to prevent it?”

That distinction matters because a defensible SoA is not built by proving that a control catalogue has been acknowledged. It is built by proving that control decisions are connected to the system’s architecture, threat exposure, protection needs, and residual risk.

Security Exists to Prevent Unacceptable Loss

Security is not the same thing as implementing controls. Controls are mechanisms. The objective is to prevent unacceptable loss.

This distinction matters because controls only have value when they reduce the likelihood or impact of a meaningful loss event. MFA, logging, network segmentation, encryption, and privileged access monitoring are not inherently valuable because they appear in a control catalogue. They are valuable because they help protect specific assets, functions, trust relationships, and business outcomes from credible threats.

Different systems therefore require different protection decisions. A public-facing SaaS platform handling sensitive government data has a very different risk profile from a disconnected industrial control environment. A software delivery pipeline has different trust assumptions from a records management system. An identity provider has different consequences of compromise from a low-sensitivity collaboration tool.

The problem with many Statements of Applicability is that they treat these environments as though they are broadly equivalent. The control catalogue is applied statically, rather than being interpreted through system context. That approach produces weak applicability decisions because it skips the engineering analysis that should come first.

Before deciding whether a control is applicable, the organisation must understand what assets exist within the system, what functions the system performs, where trust boundaries exist, which interfaces connect to external systems, which operational states are relevant, which users and services hold privileged capability, what could happen if the system behaves unintentionally, and what forms of adversity are credible.

Without those answers, control applicability is not evidence-based. It is guesswork.

How to Determine Whether an ISM Control is Applicable

Control applicability should be determined through system understanding, not template inheritance.

A practical decision path looks like this:

1. Identify the system function. What does the system do?
2. Identify assets. What information, services, identities, or capabilities require protection?
3. Identify the operating environment. Where does the system operate, and who interacts with it?
4. Identify trust boundaries. Where does control change hands between users, services, networks, vendors, or platforms?
5. Identify credible threats. What adversary behaviours are realistic?
6. Identify plausible loss events. What could go wrong, and why would it matter?
7. Define protection objectives. What security outcomes are required?
8. Map ISM controls. Which controls support those outcomes?
9. Document implementation. How are the controls implemented?
10. Record evidence and residual risk. What proves the claim, and what risk remains?

This process makes applicability defensible.

The Problem with Generic Applicability Rationales

Generic applicability rationales are one of the clearest indicators of a weak Statement of Applicability. They may appear technically correct on the surface, but they often fail to explain why a control matters in the context of the actual system.

For example, a rationale such as “applicable because privileged access exists within the environment” is not wrong, but it is operationally weak. It does not explain where privileged access exists, which systems are affected, which trust boundaries are crossed, what threat conditions are relevant, what attack paths are plausible, or what loss events the control is intended to prevent.

A stronger rationale would explain the relationship between privilege, architecture, threat, and consequence. For example, administrative access to cloud management planes may permit modification of identity federation, network segmentation, cryptographic configuration, and workload deployment. If those privileged identities are compromised, an attacker could alter system configuration, exfiltrate data, undermine integrity, or disrupt protected workloads.

The stronger rationale is defensible because it connects architecture, privilege, operational capability, threat behaviour, and business consequence. It shows that the control was selected for a specific protection need, not merely included because the control catalogue expected an answer.

What a Strong SoA Rationale Should Include

A strong applicability rationale should usually include five elements.

The rationale does not need to be long. It needs to be specific.

Non-Applicable Controls Are Not a Weakness

Many organisations are reluctant to mark controls as non-applicable because they assume absence will be interpreted as immaturity or poor security coverage. That fear is understandable, but misplaced. A carefully justified non-applicable decision is often stronger than marking a control as applicable without a clear technical reason.

If a system has no wireless capability, wireless-specific controls may genuinely be outside the system’s scope. If removable media cannot physically or logically interact with the environment, some removable media controls may not be relevant. If identity is fully federated and no local authentication domain exists, certain credential management requirements may apply differently or be inherited from another service.

The important question is not whether every control has been included. The important question is whether each applicability decision is technically coherent, supported by evidence, and aligned to the system’s actual architecture and operating model.

How to Justify Non-Applicable ISM Controls

A non-applicable rationale should explain why the control does not apply to the system’s architecture, operating model, or threat exposure.

Useful questions include:

• Does the capability addressed by the control exist in this system?
• Can the relevant interaction occur?
• Is the risk inherited from another system or provider?
• Is the control addressed through an equivalent mechanism?
• Is the system boundary defined clearly enough to support the decision?
• Is there evidence that the excluded function is absent?

A weak non-applicable rationale says:

Not applicable to this system.

A stronger rationale says:

Not applicable because the system does not provide wireless network access, does not contain wireless interfaces within the assessed boundary, and all administrative access occurs through managed wired networks and approved remote access pathways. Network diagrams and asset inventory confirm the absence of wireless infrastructure within scope.

That is the level of clarity assessors expect.

Architecture Determines Applicability

Security controls do not exist in isolation. They exist because architecture creates exposure.

A modern system is rarely a single application. It is usually a composition of:

• Identity systems
• Cloud platforms
• SaaS integrations
• APIs
• CI/CD pipelines
• Endpoint management systems
• Administrative planes
• Logging infrastructure
• Cryptographic services
• Human operators
• External dependencies
• Trust relationships

Each component and relationship can create exposure conditions.

For example:

• Centralised identity introduces federation risks.
• Remote administration introduces credential exposure risks.
• CI/CD introduces software supply chain risks.
• API integration introduces trust transitivity risks.
• Cloud orchestration introduces privilege escalation pathways.

The architecture creates the attack surface. The attack surface creates threat opportunities. Threat opportunities create protection needs. Protection needs create control applicability.

That chain should be visible throughout the SoA.

Why Data Flow Diagrams Matter for SoA Quality

Data flow diagrams are often treated as optional supporting material. They should not be.

A good data flow diagram helps explain:

• Where sensitive data enters the system
• Where data is stored, processed, and transmitted
• Which systems exchange information
• Where trust boundaries exist
• Which users and services initiate actions
• Where administrative control is exercised
• Which external dependencies affect security outcomes

Without this view, applicability decisions are often based on assumptions rather than evidence.

A defensible SoA should be supported by architecture diagrams, data flow diagrams, asset inventories, identity models, network diagrams, integration lists, and operating procedures.

The SoA should not invent system understanding. It should reflect it.

The Dangerous Illusion of Control Coverage

One of the most persistent myths in governance is that more controls always mean more security. They do not.

Every additional control introduces:

• Operational dependency
• Configuration state
• Maintenance burden
• Interoperability assumptions
• Failure conditions
• Assurance obligations

Controls implemented without architectural understanding can make systems brittle.

Common examples include:

• Endpoint controls breaking privileged administration workflows
• Excessive segmentation creating unmanaged bypass channels
• Overlapping monitoring platforms generating unactionable telemetry
• Identity overlays producing inconsistent trust decisions
• Compliance-driven logging generating more data than teams can use

More controls can create more complexity. More complexity can create more risk. A mature SoA recognises that each control is a design decision involving trade-offs between security, performance, maintainability, complexity, cost, and assurance.

Applicability is therefore not just a governance decision. It is an architectural decision.

Assurance Requires Traceability

The SoA is not only a compliance artefact. It is an assurance artefact. Assurance requires evidence capable of supporting claims about system trustworthiness.

Marking a control as applicable does not create assurance. Writing a policy does not create assurance. Copying a control rationale from another environment does not create assurance. Assurance comes from traceability.

A mature SoA should allow an assessor, architect, or security engineer to trace:

• An asset
• To a threat condition
• To a plausible loss event
• To a protection objective
• To a control decision
• To implementation evidence
• To residual risk

If that path cannot be followed, the organisation may still have documentation, but it does not have strong assurance.

A Practical SoA Traceability Model

The following model can be used to strengthen an ISM Statement of Applicability.

This kind of traceability is more useful than a large spreadsheet with generic comments.

ISM SoA Checklist

Use this checklist to improve the quality of an ISM Statement of Applicability.

System Understanding Checklist

• Define the system boundary.
• Identify business functions.
• Identify information assets.
• Document system components.
• Document external dependencies.
• Identify trust boundaries.
• Identify privileged users and services.
• Document operational states.
• Maintain current architecture diagrams.
• Maintain current data flow diagrams.

Applicability Decision Checklist

• Link each applicable control to a protection need.
• Explain the system condition that makes the control relevant.
• Document credible threat scenarios.
• Identify plausible loss events.
• Avoid generic rationales.
• Justify non-applicable controls clearly.
• Identify inherited controls.
• Identify equivalent or compensating controls.
• Record residual risk.

Evidence Checklist

• Link controls to implementation evidence.
• Use current screenshots, exports, policy records, logs, or configuration evidence.
• Record evidence owners.
• Identify evidence currency and review dates.
• Validate inherited control evidence from providers.
• Ensure evidence matches the assessed system boundary.

Review Checklist

• Review the SoA after architecture changes.
• Review after new integrations are added.
• Review after major threat changes.
• Review after incidents or near misses.
• Review after provider or shared responsibility changes.
• Review before assessment, not only during assessment.

Common Mistakes in ISM Statements of Applicability

The most common SoA mistakes are predictable.

Mistake 1: Starting with the Control Catalogue

The control catalogue matters, but it should not be the starting point. Start with system understanding, then map controls to protection needs.

Mistake 2: Using Generic Rationales

Generic rationales do not demonstrate understanding. They should be replaced with system-specific reasoning.

Mistake 3: Avoiding Non-Applicable Controls

Marking every control as applicable can be a sign of weak analysis. Non-applicable decisions are acceptable when technically justified.

Mistake 4: Ignoring Architecture

Controls derive meaning from architecture. Without architecture, applicability decisions are often speculative.

Mistake 5: Confusing Control Coverage with Assurance

A large control matrix does not prove security maturity. Traceability, evidence, and coherent reasoning matter more.

Mistake 6: Treating the SoA as a Late-Stage Artefact

The SoA should evolve with system design and operation. Producing it only before assessment leads to retrospective justification.

How to Build a Defensible SoA

A defensible SoA should be built progressively, not assembled at the end.

A practical workflow is:

1. Define the system boundary.
2. Build or validate architecture diagrams.
3. Build or validate data flow diagrams.
4. Identify assets and business functions.
5. Identify trust boundaries and external dependencies.
6. Perform threat modelling.
7. Identify plausible loss events.
8. Define protection objectives.
9. Map ISM controls to protection objectives.
10. Determine applicability and non-applicability.
11. Document implementation details.
12. Link evidence.
13. Record residual risk.
14. Review with system owners, architects, security engineers, and governance stakeholders.
15. Maintain the SoA as the system changes.

This workflow makes the SoA an output of engineering, not a last-minute compliance exercise.

Common Questions About ISM Statements of Applicability

What is the purpose of a Statement of Applicability?

The purpose of a Statement of Applicability is to document which controls apply to a system, why they apply, how they are implemented, what evidence supports them, and what residual risk remains.

Is an SoA just a compliance spreadsheet?

No. A spreadsheet may be the format, but the SoA should be an assurance artefact. It should demonstrate traceability between system understanding, threats, protection needs, control decisions, evidence, and residual risk.

Why do assessors care about SoA rationales?

Assessors care about rationales because they reveal whether the organisation understands its system and its risks. Generic rationales suggest the SoA was produced for compliance rather than assurance.

Can ISM controls be marked as non-applicable?

Yes. Controls can be marked as non-applicable when the decision is technically justified. The rationale should explain why the control does not apply to the system boundary, architecture, operating model, or threat exposure.

What evidence should support an SoA?

Evidence may include architecture diagrams, data flow diagrams, asset inventories, access reviews, configuration exports, policy documents, screenshots, logs, monitoring records, test results, and provider assurance reports.

How often should an SoA be reviewed?

An SoA should be reviewed whenever the system changes materially. This includes architecture changes, new integrations, new external dependencies, major threat changes, new control implementations, incidents, or assessment preparation.

Moving Beyond Spreadsheet Compliance

The future of ISM implementation maturity will not be determined by who can produce the largest governance repository. It will be determined by who can produce coherent security engineering.

The Statement of Applicability sits at the intersection of architecture, systems engineering, threat modelling, operational design, and assurance. Treating it as a late-stage spreadsheet fundamentally misunderstands its purpose.

A well-engineered SoA is a narrative that explains how the organisation understands its systems, threats, operational realities, and protection obligations. That narrative should emerge naturally from system understanding, not from template inheritance.

The best SoAs do not simply show that controls exist. They show why controls matter. That is the difference between paperwork and assurance.