Assurance Cases Are Not Paperwork: Why Safety and Security Need One Argument, Not Two

A few years ago, in a nuclear supply chain program, I watched two reviews happen for the same system in the same week. One was a safety review. One was a cybersecurity review. Different rooms, different slide decks, different people, different vocabulary. Both teams were good. Both reviews passed. \ What nobody checked was whether the access control change the security team had just approved — restricting a maintenance interface to reduce attack surface — was the same interface the safety case relied on for an operator to intervene during an abnormal transient. \ It wasn't a disaster. It was caught, eventually, by someone who happened to sit in both rooms. But "eventually, by someone who happened to" is not a control. It's luck wearing a lanyard. \ That gap — between a safety argument and a security argument that both describe the same system but don't know about each other — is the subject of this article. What an assurance case actually is It's worth being precise here, because "assurance case" gets used loosely. \ An assurance case, in the tradition that runs through Tim Kelly's and Ibrahim Habli's work on Goal Structuring Notation and safety cases, is not a document that describes a system. It's a structured argument that a specific claim (the system is acceptably safe to operate in its intended context) is supported by evidence , connected through an explicit argument structure that shows why the evidence supports the claim — not just that the evidence exists. \ This matters because it changes what "the case" actually is. It isn't the PDF. The PDF is a rendering. The case is the graph: claim → sub-claims → strategies → evidence, with the reasoning between each layer made explicit enough that a reviewer can challenge it. \ Security assurance has converged on something structurally identical, even where the vocabulary differs — threat models, security claims, mitigations, verification evidence. The argument shape is the same. The graphs are usually just drawn separately, by different teams, using different tools, referencing different artefacts. Why the split happens — and why it's structural, not accidental. The separation between safety and security assurance isn't laziness. It comes from real structural causes, and naming them is the first step to addressing them. \ Different lifecycle timing. Safety requirements are typically derived early, from hazard analysis tied to the system's intended function. Security requirements have historically arrived later — sometimes as a response to a specific threat model exercise, sometimes as a retrofit once connectivity was added that nobody originally planned for. By the time security analysis starts, the safety architecture is often already frozen. \ Different ownership. Safety engineering usually reports through a chief engineer or systems engineering function with deep roots in domain standards — SAE ARP4754A/B for aircraft systems development, ARP4761 for the safety assessment process, IEC 61508 and IEC 61513 in the nuclear and process industries, DO-178C for airborne software. Security reporting lines often sit in IT or a dedicated cybersecurity function, governed by a different standards stack — IEC 62443 in industrial contexts, ISO/IEC 27001 more broadly. Two reporting lines rarely produce one argument voluntarily. \ Different evidence types. Safety evidence tends to be analytical and test-based: FMEA, fault trees, verification test results, and simulation. Security evidence is often a mix of design review, penetration testing, configuration baselines, and access logs. Neither team is naturally equipped to evaluate the other's evidence, so each treats the other's domain as "out of scope, assumed handled." \ Different change cadence. Safety-critical configurations are baselined and change slowly, under formal configuration management. Security postures — patches, access policies, network segmentation — change continuously, often outside the engineering change process entirely. \ None of these causes is wrong on its own terms. But stacked together, they guarantee that the two arguments will drift apart, and that the drift will be invisible until something forces both arguments to be read together — an audit, an incident, or a near-miss like the one I described. The research is already pointing this way. This isn't a fringe concern. A recent systematic literature review by Grechi, Oliveira, and Braga on model-driven safety and security co-analysis makes the point directly: connected systems require safety and cybersecurity assurance to be considered together, not as parallel disciplines that meet only at the end. The review surveys a growing body of model-based approaches that attempt exactly this — shared models from which both safety and security arguments can be derived and kept consistent. \ On the assurance case side specifically, Wei and colleagues' ACCESS framework is one of the more concrete contributions: a model-based approach to assurance-case-centric engineering of safety-critical systems, where the assurance case links to heterogeneous engineering artefacts and can be evaluated automatically — not just at design time, but at runtime, as the system's actual behaviour generates new evidence or invalidates old claims. \ What both of these have in common is a shift in framing: the assurance case stops being an artefact produced after engineering, summarizing it for an auditor, and becomes a structure that's connected to engineering — to the same models, the same requirements, the same configuration baselines that drive the rest of the digital thread. \ That reframing is the practical hinge for everything that follows. The Shared Substrate: One Digital Thread, Two Arguments If safety and security cases are going to share a model rather than just a subject, they need a shared substrate to build on. That substrate already exists in most regulated engineering organisations, in some form — it's the digital thread: the connected graph of requirements, design, implementation, verification, and configuration that (ideally) already underpins certification evidence. \ Gotel and Finkelstein's foundational work on the requirements traceability problem is relevant here for a reason that's easy to miss: traceability isn't difficult because linking artefacts is technically hard. It's difficult because meaningful relationships have to survive change across stakeholders who don't share context. That's exactly the failure mode that separates safety and security cases — each side maintains its own traceability, rooted in its own requirements set, and the relationships between the two sets are never made explicit. \ Abdel-Aty and Negri's review of the digital thread for smart manufacturing frames the digital thread as something that spans the full product lifecycle — technologies, roles, functions, and infrastructure together. A safety-security co-engineering approach doesn't need a new infrastructure layer. It needs the existing digital thread to carry both safety and security claims, evidence, and hazard/threat items as first-class objects in the same graph — not as annotations bolted onto a safety-only or security-only model. A Practical Framework Here's the sequence I'd use to move an organization from "two cases, one subject" toward "one argument, shared substrate." It assumes a digital thread already exists in some form — even an imperfect one. If it doesn't, that's a prerequisite, not a shortcut to skip. Step 1: Build a single hazard-and-threat register Most organizations have a hazard log and a threat model, maintained separately, often in different tools, by different teams. The first step is not to merge the tools. It's to merge the register — a single list of undesirable system-level outcomes, each tagged with whether it arises from a safety hazard, a security threat, or both. Many entries will turn out to be both: an undesirable outcome (loss of control, unsafe state, unauthorized actuation) that can be reached via a component failure or a malicious action. \ This register becomes the root of the shared argument. Everything downstream — requirements, design decisions, evidence — traces back to entries in this register, regardless of which discipline originally identified them. Step 2: Extend the traceability backbone to carry both claim types In a conventional digital thread, the chain runs requirement → design → implementation → verification → approval. Extending this for co-engineering means each node in that chain can carry two kinds of claims attached to the same object : a safety claim ("this interlock prevents the actuator from energizing outside the safe envelope") and a security claim ("this interlock cannot be bypassed via the maintenance network"). \ The key discipline is that these claims live on the same object — not on parallel safety and security copies of the object. If an engineer changes the object, both claims are visible, and both need re-verification or re-justification as part of the same change. Step 3: Use one argument notation, extended for security Goal Structuring Notation already has reasonably mature extensions for security arguments. The point isn't to mandate a specific notation — it's to mandate that safety and security arguments use a shared structure that a single reviewer can read end to end, rather than two documents that use different argument logics and have to be mentally cross-referenced. \ In practice, this means: top-level claim is "the system is acceptably safe and secure for its intended operational context," and the argument decomposes into safety sub-claims and security sub-claims that are visibly siblings — not separate trees with separate roots. Step 4: Make evidence conflicts visible, not resolved by silence This is the step that actually catches the failure mode I described at the start. Once safety and security claims sit on the same objects, conflicts become visible automatically: a security mitigation that restricts access to an interface the safety case relies on for manual intervention; a safety design choice (fail-safe defaults, redundant pathways) that increases the security attack surface; a logging requirement for security auditability that creates a timing constraint a safety function can't tolerate. \ These conflicts are not failures of the framework — they're the framework working. The failure mode in the old approach wasn't that conflicts existed; it's that nobody could see them until very late, if at all. Surfacing them early turns them into design trade-offs with an owner and a decision record, instead of incidents. Step 5: Joint review gates, not sequential sign-off If safety review happens, then separately security review happens, then someone assumes both are compatible — that's the sequential model that produces the gap. A joint gate doesn't mean merging the teams. It means the review agenda includes the shared claims and any flagged conflicts from Step 4, with both disciplines in the room, before either side signs off independently on their portion. Step 6: Establish decision rights for safety-security trade-offs Weill and Ross's framing of IT governance as decision rights and accountability applies directly here, just applied to a different kind of decision. When a safety requirement and a security requirement genuinely conflict — and they sometimes do — someone needs the authority to decide, and that decision needs to be recorded as part of the assurance case itself, with its rationale, not buried in a meeting note. Without this, conflicts surfaced in Step 4 just became permanently open items that nobody owns. Where AI changes the picture — and where it doesn't. AI-assisted engineering tools are now part of this picture, and they raise the stakes in two distinct ways. \ First, AI components inside the system being assured are themselves system elements that need claims and evidence — not a separate "AI ethics" appendix. ISO/IEC 42001 frames this as a management system question: establishing, implementing, and continually improving how AI is governed across its lifecycle. NIST's AI Risk Management Framework frames it as a risk to individuals, organizations, and society. \ Translated into assurance-case terms: if an AI component contributes to a function with safety or security implications, its behavior needs claims, its training and validation data need to be traceable evidence, and its failure modes need to be in the hazard-and-threat register from Step 1 — not treated as a black box that's "out of scope" for both the safety and security cases, the same way each discipline once treated the other's domain. \ Second — and this is the part that connects back to the digital thread argument — AI tools used to assist engineering (search, summarization, drafting, anomaly detection across the digital thread) are only as trustworthy as the traceability they sit on top of. A model connected to a fragmented set of safety-only and security-only artefacts will, at best, miss the relationships between them. \ A model connected to a shared substrate where safety and security claims live on the same objects can plausibly help surface exactly the kind of cross-discipline conflict that Step 4 is designed to catch — flagging, for instance, that a proposed security change touches an object with an active safety claim attached. \ That's a meaningful capability. But it's downstream of the architecture, not a substitute for it. AI doesn't fix a fragmented assurance landscape; it inherits the fragmentation, faithfully, and at speed. The Reframe The cost of running separate safety and security cases was never really the duplicated paperwork. Two documents instead of one is an inconvenience. The real cost is structural: the places where safety and security claims interact — and in any sufficiently connected system, they always interact somewhere — are exactly the places neither case is designed to see. \ As systems become more connected, more software-defined, and increasingly touched by AI at both the product level and the engineering-process level, the number of these interaction points doesn't shrink. It grows, and it grows faster than manual cross-referencing between two independent cases can keep up with. \ The organizations that will handle this well aren't the ones with the most detailed safety case or the most rigorous security case. They're the ones that stopped asking whether they have both, and started asking whether their safety and security arguments are claims about the same model — traceable, connected, and reviewable as one structure, with conflicts surfaced by design rather than discovered by luck. \