Separating Probabilistic Inference from Deterministic Governance in Cyber Risk Automation

Abstract

Risk registers remain static governance artefacts, manually maintained and weakly coupled to operational evidence. While organisations generate continuous security telemetry from vulnerability scanners, incident reports, and audit findings, this evidence is rarely synthesised into coherent, evolving risk structures. Existing approaches address fragments of the problem: SIEM systems correlate events but do not construct risk registers; GRC platforms manage risk documentation but depend on manual entry; and LLM applications assist with summarisation but introduce non-determinism incompatible with governance requirements. This paper presents a hybrid architecture that separates stochastic LLM-based extraction from deterministic risk correlation and aggregation. The system ingests heterogeneous evidence, extracts structured claims via schema-bounded LLM processing, and correlates events into stable risk trees using anchor-based tiered matching. All correlation and projection operations are deterministic and replayable. The contribution is an architectural design pattern for integrating probabilistic inference into governance systems without compromising auditability. The walkthroughs run on a reference prototype. Replaying the stored evidence three times rebuilt the same register state, and admission scores matched the values the rules predict. An injected malformed extraction was quarantined; the register did not change.

1. Introduction

1.1. Operational Problem Context

Modern organisations operate security functions across heterogeneous technology ecosystems, fragmented evidence sources and asynchronous reporting channels characterised by extensive and fragmented data sources. Technologies such as vulnerability scanners, endpoint detection systems, ticketing platforms, audit reports, and incident narratives continuously generate operational telemetry in distinct formats, at different cadences, and with varying degrees of structure or actionability. The operational reality is one of continuous, distributed evidence generation with no inherent mechanism for synthesis. The resulting fragmentation creates what might be described as a fog of war effect: decision-makers cannot see the full risk landscape, not because the evidence is absent but because it is scattered across incompatible systems, formats, and reporting cadences. Risks are accepted without full quantification, remediation is prioritised by visibility rather than severity, and resource allocation reflects organisational loudness over actual exposure. The cumulative effect is a degraded risk posture shaped less by detection failures than by the inability to assemble a coherent operational picture from the evidence already available [1].

Risk registers, however, remain largely static governance artefacts [2]. While they provide a structured framework for documenting, assessing, and tracking potential threats to business objectives, they are often stale. The information gathered reflects a point in time, and changes are often not reflected until the next update or a significant incident occurs. This structural disconnect produces key issues:

• Risk registers exhibit a lack of context, as most risk register implementations do not sufficiently capture interactions between multiple and diverse risk factors [2]. Related vulnerabilities, incidents, and audit findings are documented independently despite shared causes or dependencies.
• Fragmentation results in recurrence being obscured: business and operational teams often create parallel tracking systems, creating shadow risk management processes, leading to inefficiencies, conflicting priorities and a false picture of the organisation’s risk posture [3]. Persistent issues are repeatedly rediscovered rather than recognised as unresolved exposures.
• Registers fail to capture gradual change [4], as risk assessments at their best reflect a point in time state, allowing shifts in threat posture and control effectiveness to accumulate unnoticed between review cycles.

These failures are not entirely attributable to inadequate detection capabilities. Organisations possess extensive technologies for identifying vulnerabilities [5], logging events [6], and flagging anomalies [7]. Rather, the limitation is structural: the static nature of risk registers make them increasingly ineffectual at capturing dynamic, context-dependent threats, and manual data collection approaches further constrain responsiveness [2]. At their core, risk register deficiencies represent a failure to correlate, contextualise, and govern distributed evidence, rather than a failure to detect risk in the first place [8].

1.2. Limitations of Existing Approaches

Three categories of existing technologies address related parts of this problem, but none provide continuous, deterministic risk register construction from operational evidence.

Tools such as Security Information and Event Management (SIEM) and Security Orchestration, Automation and Response (SOAR) systems operate at the event level [6]. They aggregate logs, normalise formats, and apply correlation rules to detect patterns indicative of threats or policy violations with a general design objective of alerting on and responding to incidents requiring immediate action and orchestrating remediation workflows. The event-centric orientation, though valuable for operational security, does not lend itself well to risk governance. Traditional SIEM systems track incidents and alerts, not risk items [9]. They do not construct or maintain risk registers with the structured attributes governance requires: likelihood assessments, impact ratings, control mappings, and ownership assignments. The traceability they provide is incident-centric, terminating when an alert is resolved rather than persisting as a durable risk state.

Governance, Risk, and Compliance (GRC) platforms such as ServiceNow GRC and RSA Archer occupy the opposite end of the spectrum [10]. They provide workflow management for risk documentation, control tracking, and compliance reporting; however, their architecture assumes human-mediated data entry. Items are created, updated, and linked through manual processes or structured integrations with other business systems. These platforms increasingly incorporate natural language processing (NLP) and LLM features for parsing unstructured inputs, but ingestion remains workflow-triggered rather than continuous. Correlation across heterogeneous sources, where a vulnerability scan, an incident narrative, and an audit finding may reference the same underlying exposure, is not systematically supported, and such evidence linkage typically requires manual interpretation or custom rule development. The outcome is a governance tool optimised for managing risks already identified and articulated, not for discovering or correlating risks from raw operational data.

Recent applications of large language models assist with summarisation and triage, but their outputs are difficult to treat as authoritative inputs to governance artefacts [11,12]. Even where decoding is configured for repeatability, an output remains sensitive to the model version, the serving infrastructure, and prompt construction and cannot be reliably regenerated once a hosted model changes.

None of these approaches provides joint support for continuous evidence ingestion, deterministic correlation, and auditable risk register maintenance. This gap motivates the present work.

The scope of this paper is bounded and our contribution is architectural. We propose an integration model that keeps probabilistic inference separate from deterministic risk governance and formalise it as a design pattern for constructing risk registers continuously from heterogeneous operational evidence. The design targets the requirements and architectural properties set out in Section 3. Section 6 executes the design on a reference prototype and measures determinism under replay, duplicate suppression, correlation behaviour, failure containment, traceability, and processing cost. This paper does not evaluate the quality of the inference layer. Extraction accuracy, correlation precision against labelled ground truth, and behaviour at scale are empirical questions reserved for a companion study.

We posit that a probabilistic model may participate in a cyber risk governance pipeline without compromising it, provided every governance state transition remains deterministic and reconstructable from its source evidence; the executed walkthroughs test exactly that proposition.

This paper makes three contributions:

• A hybrid architecture separating stochastic LLM based extraction from deterministic, replayable risk correlation and aggregation.
• An anchor-based, tiered event correlation strategy that constructs stable risk graphs under partial, noisy, or delayed evidence.
• A criteria-based evaluation framework for cyber risk automation systems emphasising auditability, replayability, and governance over predictive accuracy.

2. Background and Related Work

2.1. Cyber Risk Registers

Risk registers are integral to organisational risk management [13]. They provide a structured framework for documenting, assessing, and tracking potential threats to business objectives and, ideally, capture interactions between threats, vulnerabilities, and business impacts across an organisation [13].

As part of a risk management framework, identified risks are documented through detailed schemas, mapping them to specific business functions, objectives or technical domains [14,15]. Identified risks undergo quantification, impact and likelihood assessments using standardised criteria to enable a consistent evaluation. The outputs of these assessments inform the development and application of control measures for risk treatment. The nature of business means there will be residual risks, with some being accepted, transferred or scheduled for revaluation, and effective risk management maintains continuous visibility into these outcomes.

While the above is a high-level overview of the nature and application of a risk register, operational implementations vary significantly across organisations based on factors like size, complexity, and resources and maturity [13].

The following is a high-level overview of some identified issues [2,4,16]:

• Obsolescence: The temporal nature of risk registers, with assessments typically being done quarterly or yearly, means the register will more often be outdated than not due to the kinetic nature of the cyber threat landscape.
• Subjectivity and bias: Reporting inconsistencies stemming from issues like accountability avoidance, conflicting priorities and a misalignment in understanding hamstring the reliability of risk registers.
• Complexity: The technical and specialised nature of cyber security creates a disconnect, and risks are not always communicated correctly or effectively, hindering the effectiveness of decision makers in addressing identified risks.

While risk registers remain essential tools for security governance, their current form requires evolution to address modern threat landscapes effectively. To address these limitations, there is a need for more adaptive and data-driven approaches.

Table 1. Comparative assessment of risk register approaches against identified limitations.

Criterion	Spreadsheet-Based Platforms	Traditional GRC Platforms	Workflow/Ticketing-Adapted Registers
Obsolescence	Stale between quarterly/annual review cycles	Stale between review cycles; updates require manual entry	Partial currency; tied to ticket state changes rather than risk reassessment
Subjectivity and bias	High; free-text fields and unconstrained scoring	Moderate; structured fields but scores remain human-assigned	Moderate; entries reflect ticket author’s framing and priorities
Complexity of communication	Manual reformatting required per audience	Templated reports with fixed structure; limited tailoring	Not designed for non-technical or executive consumption

contains a comparative analysis of different approaches and these issues. The comparative analysis is synthesised from the limitations discussed in the Cyber Risk Registers section and sources cited therein.

2.2. LLMs in Cybersecurity Operations

Large language models have seen rapid adoption in cybersecurity operations [17]. Major technology providers have integrated LLMs into security operations centres for alert analysis and summarisation, automating aspects of triage, condensing dense intelligence reports and generating actionable insights for analysts [12]. LLMs are deployed for cyber threat intelligence summarisation, reducing the effort required to parse and contextualise threat feeds. Ticket classification and routing, incident report generation, and compliance documentation have similarly benefited from LLM-assisted automation.

Despite these capabilities, LLMs exhibit limitations that constrain their applicability in governance contexts:

• Hallucination. LLMs generate outputs that appear plausible but are factually incorrect. In risk management, this manifests as fabricated relationships between unrelated risk factors, non-existent references, or blended analyses that seem coherent but are wrong [11].
• Non-repeatability. Sampling-based decoding is stochastic, and although greedy decoding at temperature zero can make individual calls repeatable, that repeatability is conditional. It holds only for a fixed model build, serving stack, and prompt, none of which a hosted deployment guarantees over time. Reproducibility for audit therefore cannot rest on the model call itself [18].
• Opacity. LLMs function as black-box systems. The reasoning behind a given output cannot be inspected or verified, making it difficult to establish accountability or trace errors to their source [19].

These characteristics have a direct implication: LLMs cannot serve as authoritative actors in governance systems. They may assist with extraction and summarisation, but their outputs cannot form the basis of auditable risk determinations without deterministic validation and control.

3. Design Requirements and Evaluation Criteria

The system design is derived from the limitations established in the preceding sections. Risk registers in current practice suffer from obsolescence, subjectivity, and communication complexity, while LLMs introduce hallucination, non-repeatability, and opacity. Any system that uses LLMs to maintain a risk register must address both sets of problems concurrently. Three properties follow: auditability, so that subjective entries and opaque model outputs can be inspected and challenged; repeatability, so that the register state can be reconstructed from evidence and stochastic model behaviour does not undermine reproducibility; and controlled operation, so that technical complexity and unbounded model inference do not propagate into governance artefact. These properties translate into five concrete design requirements:

• Determinism under replay. Given identical risk inputs, the system must produce semantically identical outputs. This property is essential for audit reconstruction and incident review. The risk register state at any historical point must be recoverable by replaying the evidence stream, with no dependence on execution order, global counters, or mutable external state.
• End-to-end traceability. Every risk register entry must trace to its source evidence through an unbroken chain: raw input to extracted claims, claims to synthesised events, events to correlated risk structures, and risk structures to register entries. Each significant data or risk management action is captured as a timestamped, contextualised event, enabling inspection at any point in the pipeline.
• Bounded inference scope. LLM-based extraction operates within explicit constraints. The system defines what the model may infer, what schema it must produce, and what validation it must pass. Extraction that falls outside these bounds is rejected or isolated rather than propagated. This prevents unbounded model behaviour from contaminating downstream governance artefacts.
• Human override and audit support. The system must degrade gracefully in the event of LLM failures or ambiguous results, always allowing for human override and annotation. Automated outputs are provisional until reviewed. Transparent, auditable change logs for all register entries and LLM-driven outputs enable retrospective validation and accountability assignment.
• Standards-aware risk representation. Risk register structures align with established frameworks. The system will automatically associate identified risks and controls with common audit and compliance standards such as ISO 27001 [14] clauses as a proof of concept, providing a common reference frame for compliance reporting and control mapping.

Table 2. Evaluation criteria, expected outcomes, and where each is demonstrated.

Criterion	Expected Outcome
Determinism under replay	Event fingerprinting and fixed tier rules (correlation and control mechanisms); the executed replays in Section 6 reproduced identical structure three times, exercised by Cases A and E.
End-to-end traceability	Event-driven capture of each action; the executed traceability walk in Section 6 resolves a register entry to its source excerpts.
Bounded inference scope	Schema validation at extraction; the executed Case D (the section Failure Containment and Degradation Behaviour) quarantines a malformed extraction with no graph or register mutation.
Human override and audit support	Provided by design (analyst override and audit-log facilities); not exercised in the walkthroughs.
Standards-aware representation	Risk-register projection emits control mappings and standards alignment (e.g., ISO 27001) as a proof of concept.

enumerates the requirements as expected outcomes and identifies how they are demonstrated.

4. Proposed Architecture

4.1. Architectural Overview

The system implements an event-driven architecture, with each significant data or risk management action captured as a timestamped, contextualised event. This enables auditability and traceability, and aligns with the objective of building a repeatable, experiment-friendly system.

The pipeline comprises five stages (see Figure 1 for a high-level overview):

• Evidence ingestion. Raw inputs arrive from heterogeneous sources: vulnerability scans, incident narratives, audit findings, support tickets, system logs with schema mapping applied for structured data and LLM pipelines for unstructured data.
• Claim extraction. Inputs are chunked and processed through a two-pass LLM pipeline, with the first extracting atomic claims from each chunk to preserve granular evidence and the second synthesising claims into candidate event outputs to enable cross-claim reasoning without fabricating new facts. Extraction is constrained: the model may not infer beyond explicit content, must produce schema-compliant output, and is rejected on validation failure.
• Event normalisation. Extracted events undergo anchor normalisation: hostnames, IPs, Common Vulnerabilities and Exposures (CVE) identifiers, and user references are canonicalized to prevent syntactic variation from causing spurious divergence.
• Deterministic correlation. Normalised events are correlated into risk trees using a tiered matching strategy. Correlation operates on shared anchors within defined temporal windows. No LLM inference occurs at this stage.
• Risk register projection. Correlated risk structures are projected into register entries with likelihood, impact, control mappings, and standards alignment.

LLMs are explicitly constrained to intermediate extraction. They provide pattern recognition, risk extraction, and categorisation services, but all outputs are schema-validated, bounded, and subject to deterministic downstream control. Final risk determination is never delegated to the model.

4.2. Correlation and Control Mechanisms

The mechanisms below operationalise the three properties established in Section 3. Each is presented with the property it primarily enforces.

• Event fingerprinting (repeatability). Each event receives a stable hash over event type, normalised anchors, and fixed time bucket. Identical inputs always produce identical hashes, guaranteeing idempotency and replay consistency.
• Anchor normalisation (repeatability). Hostnames, IPs, CVE identifiers, and user references are canonicalized before correlation. This prevents syntactic variation from causing spurious divergence.
• Tiered correlation (controlled operation). Tier 1: hard match via identical fingerprint. Tier 2: soft match via shared anchors within fixed temporal window. Tier 3: deterministic new tree allocation when no match exists.
• Bounded LLM scope (controlled operation and auditability). LLMs perform claim extraction and event synthesis only and all outputs undergo schema validation. Deterministic correlation and projection operate without involvement of the LLM.

Each ingest stores the parser’s extraction output once as structured data. Scoring, admission, correlation, and projection read only stored rows and can be re-invoked by the row identifier, so a replay re-executes these stages against the stored extraction without calling the model. Any historical register state can be rebuilt from the evidence store alone.

Event fingerprinting and tiered matching admit a compact statement, with e an admitted event, t(e) its timestamp, w the correlation window applied symmetrically on either side of t(e), and H a 64-bit hash:

• Fingerprint(e) = H(company, project, type(e), bucket(t(e), 5 min), sorted normalised anchors(e)), where bucket floors the timestamp to a five-minute boundary and t(e) falls back to ingest arrival when the event carries no timestamp.
• Tier 1: An already-graphed event with the same fingerprint reuses that event’s tree.
• Tier 2: Otherwise, the graphed event nearest in time to t(e), within w of it, that shares a normalised anchor supplies its tree, and the shared anchor type is recorded under the fixed priority hostname > ip > user > email > cve.
• Tier 3: Otherwise, a new tree is allocated under the event’s own identifier, so no global counter exists and replays reproduce identical assignments.

5. Materials and Methods: Reference Prototype

5.1. Prototype Scope

The system described in this paper is a research prototype developed to evaluate feasibility and demonstrate architectural properties. It is not positioned as a production deployment.

The prototype integrates LLM capabilities within a risk management framework to test whether continuous evidence ingestion, deterministic correlation, and auditable risk register construction can be achieved within a unified pipeline. The implementation is informed by standards such as ISO 27001 and the National Institute of Standards and Technology (NIST) Risk Management Framework (RMF) but does not claim full compliance with any regulatory framework.

The prototype’s architecture is modular, designed to handle structured and unstructured data at scale. It instantiates the event-driven architecture described above as a runnable artefact.

A PHP 8.5 service owns ingestion, normalisation, correlation, and projection, and a separate Python 3.13 service performs extraction. Both share one relational database (PostgreSQL 16), with a queue coordinating the asynchronous stages. There is no dedicated graph database. Entities, co-occurrence edges, and per-edge evidence counts live in ordinary relational tables, so correlation queries run in the same transactional store as the register they feed. An automated test suite covers the deterministic stages that Section 6 relies on.

The system is model-agnostic and can operate with any sufficiently capable LLM. For the implementation presented here, OpenAI’s GPT-4.1-mini was selected due to the company’s established application programming interface (API) ecosystem and the model’s practical availability at the time of development. The architecture permits swapping LLM providers with minimal modification.

Development followed an iterative framework, with core components built and refined in short cycles. Each iteration focused on a distinct module (ingestion, LLM integration, correlation, or reporting), with integration points established early to facilitate parallel workstreams. Validation relied on simulated data flows and scenario runs to test end-to-end system behaviour.

5.2. Core Components

The prototype comprises five components with separated responsibilities (see Figure 1 and Figure 2):

• Ingestion service. Accepts structured and unstructured inputs from heterogeneous sources including vulnerability scans, incident reports, audit findings, and operational logs. Applies schema mapping for structured data and dispatches unstructured data to the extraction pipeline.
• Claim extraction pipeline. Processes unstructured text through LLM-assisted parsing to extract atomic claims. Outputs are schema-validated and bounded before downstream processing.
• Event normalisation layer. Canonicalizes extracted claims into normalised events. Applies anchor normalisation to hostnames, users, IPs, and CVE identifiers to prevent syntactic variation from causing spurious divergence.
• Deterministic graph construction. Correlates normalised events into risk trees using tiered matching. Tier 1 matches on identical fingerprints, Tier 2 matches on shared anchors within fixed temporal windows, and Tier 3 allocates isolated trees when no match exists. No global counters results in no reassignment of existing nodes.
• Risk register projection. Projects correlated event trees into risk register entries with structured attributes: likelihood, impact, control mappings, ownership, and evidence linkage. Supports create, read, update, and delete (CRUD) operations, status tracking, and historical snapshots.

6. Results: Executed Multi-Source Walkthroughs

Figure 2 summarises the pipeline and the walkthrough cases. Every case below was executed on the reference prototype. A synthetic corpus covering the four source types was ingested into an initially empty register through the production pipeline, using GPT-4.1-mini as the extraction model and the prototype’s default 72 h soft-match window; the exact value is incidental here, since the cases that should correlate sit well inside it. Admission scores each event against fixed, configured quality rules. Events below a threshold are stored but quarantined and do not correlate. The expected admission decision, matching tier, and confidence prior for each case were recorded before the first run. The corpus, the run outputs, and the replay protocol are distributed with the paper (see the Data Availability Statement).

Replay behaved as Section 3 requires. After the live ingests completed, every derived state was cleared, and every stage re-ran from the persisted extraction output alone; the language model was not called again. Three consecutive replays produced identical state digests (SHA-256 prefix 5436c2f9) over events, trees, correlation reasons, register entries, and the entity graph. Each case’s admission score was computed in advance from the prototype’s configuration, and the scores the system produced at admission matched to five decimal places. Re-submitting the same corpus through the full ingest path also left the projected state unchanged. The extraction cache recognised the identical input and returned the same candidates without re-querying the model, and the insert constraint suppressed every duplicate. That outcome is a property of the deployed cache, and the replay guarantee operates outside the extraction layer. The cases are as follows:

• Case A: vulnerability scan (structured). The scan event was admitted with a confidence prior of 1.0; its CVE, hostname, and IP anchors were extracted and canonicalized, and a fingerprint was computed over event type, normalised anchors, and time bucket. Re-ingesting the identical scan left the register unchanged: the duplicate was suppressed at insert time by the fingerprint uniqueness constraint, so the hard-match tier operates at the storage boundary before the matcher runs.
• Case B: incident narrative (unstructured). The free-text ticket was parsed by the LLM-assisted extractor into a single event carrying hostname, IP, and account anchors and admitted with a prior of 1.0. It attached to Case A’s tree through a Tier 2 soft match, and the recorded correlation reason names the shared hostname as the matching anchor. Prior graph structure was not altered.
• Case C: audit finding (weak anchors). The finding carries no technical anchors, and the extractor returned none. It was admitted with a prior of 0.669, matching the configured anchor-strength penalty exactly, and Tier 3 allocation created an isolated tree. The governance-relevant risk is preserved without forcing a false correlation to unrelated events.
• Case D: malformed extraction. An extraction asserting a severity with no supporting summary, no timestamp, and no anchors was injected at the parser callback boundary. The section Failure Containment and Degradation Behaviour reports the outcome.
• Case E: delayed evidence arrival. The late note arrived last, two days after the events it describes. Its event time sits 49.75 h from Case A’s, inside the correlation window, so it attached to the existing tree on the shared hostname; arrival order did not matter because matching runs on event time. The tree’s earlier members kept their original correlation reasons, and Case C’s tree was untouched.

The runs also measured where the time goes. Live ingest-to-register latency ran between 9.6 and 13.7 s per document, almost all of it inside the hosted model call, and the cached duplicate completed in 5.0 s. The deterministic stages processed each event in 18.3 to 56.6 milliseconds at the median, and a full replay of the corpus took 152 to 224 milliseconds on commodity hardware. These absolute values primarily depend on the serving endpoint and the machine, not on the design. What carries across environments is the asymmetry: extraction pays for model inference, while every stage after storage is rule execution over stored rows, so replay stays cheap wherever it runs.

Failure Containment and Degradation Behaviour

Case D injected a malformed extraction at the parser callback boundary. The payload asserted a severity with no supporting summary and carried neither a timestamp nor anchors. The admission gate scored it 0.410 against a threshold of 0.6 and quarantined it. A quarantined event receives no fingerprint and never reaches the matcher, so no tree was created or joined. The projected register carried the same entries and values, since the admitted evidence set was unchanged. The invalid extraction is retained for audit and leaves the governance state untouched.

7. Discussion

Table 1 contrasted spreadsheet-based, GRC-based, and workflow-adapted registers against the identified limitations. Table 3 extends this comparison to LLM-assisted approaches in cyber risk and threat intelligence, which share the use of language models but address narrower problem scopes and do not address determinism or replayability.

Beyond these language-model approaches, the design also contrasts with the broader tool classes it is meant to complement. Security Information and Event Management and orchestration systems correlate events in real time but stop at the alert, constructing no durable risk record [6,9]. Governance, Risk, and Compliance platforms maintain structured risk documentation yet depend on manual entry and do not continuously ingest operational evidence [10]. Newer language-model work pushes automation into adjacent tasks, including formal verification and automated modelling [20] and generative-AI-assisted dynamic risk management [4]. Each, however, addresses a single stage. None maintains a continuously evolving register whose state transitions are deterministic, auditable, and replayable, which is the gap this architecture is designed to fill.

Table 3. Positioning relative to LLM-assisted approaches. ^a LLMs for CTI extraction [17]. ^b LLMs for mission-critical risk analysis [21]. ^c LLMs for cyber risk cost estimation [22]. Characterisations synthesised from sources cited in the LLMs in the Cybersecurity Operations section. Acronyms: RAG, retrieval-augmented generation; CTI, cyber threat intelligence.

Dimension	Approach A a	Approach B b	Approach C c	Proposed System
Scope	Threat intelligence extraction from forums	Risk identification in mission-critical contexts	Financial impact quantification	Continuous risk register construction across heterogeneous evidence
Role of LLM	Primary actor: extraction and classification	Primary actor: RAG-assisted analysis and recommendation	Primary actor: cost estimation	Bounded to extraction; excluded from correlation and projection
Determinism/replayability	Not addressed	Not addressed; outputs supplement expert judgement	Not addressed	Deterministic correlation; replayable from evidence stream
Coverage of full register lifecycle	No; CTI extraction only	Partial; risk identification	No; cost estimation only	Yes; ingestion through projection

Table 3. Positioning relative to LLM-assisted approaches. ^a LLMs for CTI extraction [17]. ^b LLMs for mission-critical risk analysis [21]. ^c LLMs for cyber risk cost estimation [22]. Characterisations synthesised from sources cited in the LLMs in the Cybersecurity Operations section. Acronyms: RAG, retrieval-augmented generation; CTI, cyber threat intelligence.

Dimension	Approach A a	Approach B b	Approach C c	Proposed System
Scope	Threat intelligence extraction from forums	Risk identification in mission-critical contexts	Financial impact quantification	Continuous risk register construction across heterogeneous evidence
Role of LLM	Primary actor: extraction and classification	Primary actor: RAG-assisted analysis and recommendation	Primary actor: cost estimation	Bounded to extraction; excluded from correlation and projection
Determinism/replayability	Not addressed	Not addressed; outputs supplement expert judgement	Not addressed	Deterministic correlation; replayable from evidence stream
Coverage of full register lifecycle	No; CTI extraction only	Partial; risk identification	No; cost estimation only	Yes; ingestion through projection

What this system ultimately demonstrates is that a risk register does not need to be a static, manually maintained artefact. It can change as evidence arrives, continuously, provided that inference and governance are kept structurally separate. In this design, LLMs are used only where they are hard to avoid, extracting structure from messy inputs while all correlation, attachment, and projection decisions remain deterministic and explicit. That separation is what makes the pipeline auditable and replayable, even when individual extractions are imperfect.

The separation also bears on AI governance regimes beyond cybersecurity, which now ask operators to show how a model output entered a consequential decision. An architecture that persists every model output and replays every decision from that record shows it by construction.

There is no attempt to measure extraction accuracy, optimise correlation quality, or claim improved risk prioritisation. The prototype has not been exercised over long organisational timelines, and dependence on external LLM services is an operational reality rather than a solved problem. These limits follow from the decision to prioritise control and traceability over adaptivity.

Even with those constraints, the practical effect is nontrivial. The register evolves as evidence accumulates, and when it changes, the reasons for that change are inspectable. For governance-heavy environments, which shift from periodic synthesis to continuous, explainable accumulation may matter more than marginal gains in detection or accuracy.

Deployed into an existing toolchain, the register does not replace adjacent tooling such as SIEM or GRC platforms. What it replaces is the manual assembly of the register itself, the reconciliation of scanner output, incident narratives, and audit findings that today fall between those tools. Detection tools supply its evidence, and its projected entries feed the GRC workflows where risks are treated and signed off. The cost that grows with document volume is the extraction call to the model, while the stages after storage remain cheap by comparison (Section 6), so extraction capacity sets the practical ceiling. The remaining constraint is trust. Analysts are asked to act on register entries no analyst wrote, and the per-entry trace back to source excerpts is what makes that acceptable.

8. Future Work

Several extensions follow naturally from this work. The most immediate is empirical evaluation using real organisational datasets, where evidence volume, noise, and latency are materially different from controlled examples. Longer-term deployment would also allow the analysis of risk drift over time: how trees evolve, stabilise, or fragment as evidence accumulates and controls change. Finally, the current design assumes a single extraction model. Introducing multi-model redundancy and explicit disagreement handling would allow stronger containment of extraction failures without relaxing deterministic control.

Evaluation on organisational datasets, comparative benchmarking against established GRC workflows, and long-term operational deployment would test the pattern where evidence volume, noise, and drift are real.

9. Conclusions

This paper argues that risk automation is primarily a structural systems problem rather than a prediction problem. The challenge is not identifying the “correct” risk but maintaining a coherent, auditable representation as heterogeneous evidence arrives over time. By constraining LLMs to extraction and enforcing deterministic correlation and projection rules, it is possible to integrate probabilistic inference without allowing it to dominate system behaviour. The result is a risk register that evolves continuously, remains replayable, and preserves governance trust even in the presence of imperfect automation.