A pile of pen test reports, scan results and policies does not tell a regulator, a customer or your own board whether a system is secure enough, because nobody has said what "secure enough" means or how each piece of evidence supports it. A security assurance case fixes that. It is a structured argument, made of explicit claims, the reasoning that links them, and the evidence that backs each one, showing that a system meets its security requirements in a stated context. This guide explains what an assurance case is, the two main notations (GSN and the OMG Structured Assurance Case Metamodel, SACM), how to build one for a regulated product or an AI system, and the mistakes that turn it into paperwork. It is for product security leads, safety and security engineers, assurance assessors and teams preparing evidence for medical device, automotive, defence or AI regulators.
Key takeaways
- An assurance case is an argument, not a document dump: a top claim, sub-claims, the strategy that decomposes them, and evidence at the leaves, all in a stated context.
- Two notations dominate: Goal Structuring Notation (GSN, maintained by the SCSC Assurance Case Working Group) and OMG SACM, whose latest formal version is 2.3, adopted in October 2023.
- ISO/IEC/IEEE 15026-2:2022 sets requirements for the structure and terminology of assurance cases and is the neutral reference to cite when a contract asks for one.
- The value is in the weak spots it exposes: undeveloped claims, unstated assumptions and evidence that does not actually support the claim it sits under.
- AI systems are the new frontier: the UK AI Security Institute describes safety cases for frontier AI built from positive, negative and sociotechnical evidence, and the same structure works for AI security claims.
What it is
ISO/IEC/IEEE 15026-2 treats an assurance case as a defined artefact with its own structure and terminology. The OMG SACM specification describes it as a set of auditable claims, arguments and evidence that together support a claim that a system or service meets its requirements. The UK Ministry of Defence wording in Defence Standard 00-56, quoted by the AI Security Institute, says the same thing for safety: a structured argument, supported by a body of evidence, that a system is safe for a given application in a given environment. Replace "safe" with "secure" and you have a security assurance case.
Three ideas separate it from an ordinary compliance pack:
- Claims are specific and falsifiable: "Only authenticated, authorised clinicians can change infusion settings over the network" can be wrong. "The device is secure" cannot be argued.
- Reasoning is explicit: the case states why the sub-claims together imply the parent claim, for example "argued over every network interface identified in the threat model".
- Context bounds the claim: the operating environment, the threat model, the version under assessment and the assumptions (for example "the hospital network enforces segmentation") are written down, so a reader knows when the claim stops being true.
| Artefact | Answers | Relationship to the assurance case |
|---|---|---|
| Threat model | What can go wrong? | Supplies the threats the case must argue are mitigated, and the scope of the decomposition |
| Security requirements | What must be true? | Become the claims or sub-claims |
| Test reports, scans, pen tests, code review | What did we observe? | Evidence at the leaves (solutions) |
| Risk register | What risk remains and who accepted it? | Records residual risk the case argues is acceptable |
| System security plan or Statement of Applicability | Which controls are in place? | Control lists are evidence, not the argument |
| Assurance case | Why should anyone believe the system meets its security requirements? | Ties all of the above together |
For the threat analysis that feeds a case, see the Threat Modelling Guide and the Security Requirements and Abuse Cases Guide.
How it works
The building blocks
GSN, now at Version 3 of the community standard published by the SCSC GSN Standard Working Group, draws an argument as a tree of typed elements. SACM defines an equivalent metamodel and a UML profile, plus its own graphical notation, so modelling tools can store and exchange cases. The table shows the core GSN elements and their role.
| GSN element | Role | Security example |
|---|---|---|
| Goal | A claim to be supported | "Remote firmware update cannot install unsigned code" |
| Strategy | How a goal is broken into sub-goals | "Argue over each update path: OTA, USB service port, manufacturing line" |
| Solution | Evidence that directly supports a goal | Signature verification test report; code review of the bootloader |
| Context | Information that scopes a goal or strategy | Threat model version 2.1; device hardware revision C |
| Assumption | Something taken as true without argument | "The signing key is held in an HSM under dual control" |
| Justification | Why a strategy or goal is acceptable | "Update paths enumerated from the interface inventory" |
| Undeveloped marker | A goal not yet supported | Shows open work honestly instead of hiding it |
Claims, Arguments, Evidence (CAE) is a third, simpler notation with three node types, popular in UK safety practice. The AI Security Institute names both GSN and CAE as standard ways to structure incomplete arguments.
Building a case step by step
- Fix scope and context: the system and version, the operating environment, the threat model and the stakeholders who will rely on the case (regulator, customer, internal approval board).
- Write the top claim in words the reader cares about, for example "The connected infusion pump is acceptably secure against the threats in TM-2.1 when deployed per the security configuration guide".
- Choose decomposition strategies: by threat, by security property (confidentiality, integrity, availability), by lifecycle phase (design, build, operate) or by architectural component. Most good cases mix two: product claims by threat, process claims by lifecycle.
- Add a process leg: a sub-claim that the product was built by a competent, controlled process (secure development standard, supplier controls, vulnerability handling). Regulators often weight this heavily.
- Attach evidence only where it directly supports the leaf claim, recording the artefact ID, version and date so the case can be re-checked.
- Record assumptions and residual risk explicitly, with an owner for each assumption that must stay true in operation (for example the customer keeps segmentation in place).
- Challenge it: have someone outside the team look for defeaters, reasons a claim could be false despite the evidence, and either answer them or mark the goal as undeveloped.
- Keep it live: link the case to change control so a new release, a new vulnerability or a changed assumption triggers a review of the affected branch.
Choosing a notation and tooling
| Option | Best for | Trade-off |
|---|---|---|
| GSN | Safety and security cases in defence, rail, automotive and medical sectors; reviewers who expect diagrams | Large diagrams become hard to read; use modules and patterns |
| OMG SACM 2.3 | Model-based systems engineering shops that need machine-readable cases and tool interchange | Heavier to learn; fewer reviewers read the native notation |
| CAE | Smaller cases and teams new to argumentation | Less expressive for context and assumptions |
| Structured text (numbered claims in a document) | Small organisations, first attempts, procurement responses | Easy to hide weak links; keep the claim, argument, evidence discipline anyway |
Small versus large organisations: a start-up answering a hospital procurement questionnaire can write a ten-claim structured-text case in a week. A manufacturer filing with several regulators will want a modular GSN or SACM case held in a tool, with reusable modules for shared platforms and suppliers.
Why it matters
- Regulated products: regulators increasingly ask manufacturers to show their reasoning, not just their controls. The FDA's final premarket cybersecurity guidance (February 2026 edition, superseding the June 2025 version) addresses section 524B of the FD&C Act for cyber devices and the documentation FDA recommends in submissions; an assurance case is a clean way to organise that documentation. See the FDA Medical Device Cybersecurity Guide and the EU MDR Cybersecurity and MDCG 2019-16 Guide.
- Automotive and industrial: automotive cyber security engineering under ISO/SAE 21434 produces a cybersecurity case as a work product, and type approval under UNECE R155 expects the manufacturer to justify its risk treatment. See the Automotive Cybersecurity Guide and the UNECE R155 Cyber Security Management System Guide.
- AI systems: the AI Security Institute (renamed from the AI Safety Institute in February 2025) treats safety cases as the way to argue a frontier model is safe in a given deployment context, combining positive evidence (why a mitigation works), negative evidence (a well-incentivised red team failing to break it, provided the search was thorough) and sociotechnical evidence about the deployment and the developer. It publishes "safety case sketches" as partial building blocks. The same shape suits AI security claims such as "the agent cannot exfiltrate customer data through tool calls". See the AI Red Teaming Guide and the EU AI Act Conformity Assessment and Harmonised Standards Guide.
- Authorisation decisions: an authorising official approving a system under NIST SP 800-53 CA-6 is in effect accepting an argument. An explicit case makes the residual risk visible and helps a continuous authorisation model decide what to re-check.
Framework mapping
| Framework | Reference | How an assurance case supports it |
|---|---|---|
| ISO/IEC/IEEE 15026-2:2022 | Assurance case | Defines structure and terminology the case should follow |
| OMG SACM 2.3 | Metamodel and notation | Machine-readable representation and interchange |
| NIST SP 800-160 Vol. 1 Rev. 1 | Engineering Trustworthy Secure Systems | Systems security engineering context in which assurance evidence is produced |
| NIST SP 800-53 Rev. 5 | SA-8, SA-11, SA-15, SA-17 | Engineering principles, developer testing, development process and security architecture supply the evidence |
| NIST SP 800-53 Rev. 5 | CA-2, CA-6 | Control assessments feed evidence; authorisation accepts the argued residual risk |
| NIST CSF 2.0 | GV.OC-03, ID.IM-01, ID.IM-02 | Legal and regulatory requirements understood; improvements identified from evaluations, tests and exercises |
Common misconceptions
- "It is just a traceability matrix." A matrix links requirements to tests. A case also argues that the requirements are sufficient for the threat model and that each test actually demonstrates the claim, including its limits.
- "More evidence makes it stronger." Irrelevant evidence hides gaps. A clean pen test of the web portal says nothing about the Bluetooth service interface.
- "Write it at the end for the regulator." A case written after the fact rationalises what was built. Started at design, it drives which tests to run and which assumptions to engineer out.
- "Once approved, it is done." Every new vulnerability, dependency change or deployment change can falsify a leaf. A case not tied to change control decays within one release.
- "Assumptions are harmless footnotes." Many real compromises sit in assumptions, for example "the signing key is protected" or "service accounts have least privilege". Each assumption needs an owner and, ideally, its own evidence. For credential-related assumptions see the Audit Readiness for AI Agents and NHIs guide.
- "Red team found nothing, so the claim holds." Negative evidence counts only if the search was competent and well-scoped, which the AI Security Institute notes explicitly; record the red team's scope, time and incentives.
Measuring whether a case is useful
- Share of leaf goals with current evidence (dated within the release cycle).
- Number of undeveloped goals and open defeaters, trended down over releases.
- Assumptions with a named owner and a verification method.
- Time from a material change (release, new critical vulnerability) to review of the affected branch.
- Regulator or assessor questions per submission that the case already answered.
Related concepts
| Concept | How it relates |
|---|---|
| Safety case | Same structure for safety claims; combined safety and security cases must handle conflicts, such as fail-safe defaults that weaken security |
| Threat modelling | Main input that defines what the security claims must cover |
| SBOM and VEX | Evidence for supply chain sub-claims and for "known vulnerabilities are not exploitable" claims; see the SBOM Guide |
| Assurance reports (SOC 2, ISAE 3402) | Third-party evidence about a service organisation's controls, usable as evidence in a process leg |
| Continuous controls monitoring | Keeps evidence fresh; see the Audit Evidence and Continuous Controls Monitoring Guide |
| Systems security engineering | The engineering discipline that produces assurance evidence; see the NIST SP 800-160 Guide |
Practitioner checklist
- Write the top claim and its context (system version, environment, threat model version) before collecting any evidence.
- Choose GSN, SACM, CAE or structured text based on who will read the case and whether tools need to exchange it.
- Decompose product claims by threat or component and add a separate process leg for development and supplier controls.
- Attach only evidence that directly supports a leaf, with artefact ID, version and date.
- List every assumption with an owner and a way to verify it in operation.
- Mark unsupported goals as undeveloped rather than leaving them out.
- Run an independent challenge review looking for defeaters before submission.
- Link the case to change control and vulnerability handling so affected branches are re-reviewed.
- For AI systems, record red team scope and incentives alongside negative evidence.
Standards and references
- ISO: ISO/IEC/IEEE 15026-2:2022 Systems and software assurance, Part 2: Assurance case
- Object Management Group: Structured Assurance Case Metamodel (SACM)
- SCSC Assurance Case Working Group: GSN Community Standard
- SCSC: Goal Structuring Notation
- NIST: SP 800-160 Vol. 1 Rev. 1, Engineering Trustworthy Secure Systems
- US FDA: Cybersecurity in Medical Devices, Quality System Considerations and Content of Premarket Submissions
- UK AI Security Institute: Safety cases at AISI
Related NHI Mgmt Group resources: Audit, Assurance and Compliance Guide · Threat Modelling Guide · NIST SP 800-160 Guide · IEC 62443-4-1 and 4-2 Secure Product Development Guide