How a grid operator stops treating security advisories as loose PDFs
A Nordic energy operator's security team receives advisories, incident reports, and vendor bulletins from a dozen sources. KnowledgeHub ties each one to the specific assets and prior incidents it actually affects, with lineage back to the original notice.
The advisory backlog
Vendor bulletins, national CERT advisories, and internal incident reports arrive from a dozen directions, in a dozen formats. Each one, read on its own, is clear enough. What isn't clear without manual work is which of the operator's own assets, which substation, which control system, which vendor contract, a given advisory actually touches.
Analysts cross-reference by hand: read the advisory, check the asset inventory, check whether a similar issue came up before. Done for every bulletin, across every asset class, this doesn't scale to the volume that arrives in a given week. Triage becomes a judgement call about which advisories look serious enough to chase — a guess made under time pressure, with a thin record of why some were prioritised and others weren't.
Re-architecting the workflow
KnowledgeHub ingests advisories, bulletins, the asset inventory, and prior incident reports as they arrive, preserving lineage at the document level. A versioned ontology models the relationships between assets, vendors, known vulnerabilities, and prior incidents.
When a new advisory comes in, agents are given a bounded task: match it against the asset inventory and incident history, and surface which systems are plausibly exposed, with the supporting evidence attached. The agent doesn't decide the response. An analyst confirms exposure — or rules it out — before anything is logged as an action.
Inside the analyst's day
A new advisory lands from a national CERT, naming a vulnerability in a control system component. Before the analyst opens it, KnowledgeHub has already checked it against the asset inventory.
Two substations use the affected component. One had a related incident flagged eighteen months ago. The advisory arrives with this context attached, not just the bulletin text, but which assets are plausibly exposed and why.
The analyst's job is to confirm the match, not to go build it. Exposure confirmed, the response is prioritised against real assets rather than the advisory's own stated severity. The assessment, advisory, assets and reasoning, is logged with its full lineage.
What changed
Faster triage is the visible benefit. Exposure assessed against real assets, not advisory text alone, is the structural one.
The security team stopped reading every bulletin cold. Each one now arrives already checked against what the operator actually runs, so the team's attention goes to the advisories that matter to their specific infrastructure, not the ones that merely sound urgent.
When an auditor or a regulator asks how a given advisory was handled, the answer is a specific asset match and a timestamp.
Easy to start. Safe to stop.
The pilot runs at a fixed price: we map the workflow, deploy it in your environment and prove it on your own cases. Then you decide.
Fixed price · Fixed timeframe
- 01
Map the workflow
Two weeks with your people where we document what happens today, including the parts nobody wrote down.
- 02
Deploy in your environment
Inside your tenancy, on your data residency terms, with no exports and nothing leaving through the side door.
- 03
Prove it under audit
Controlled evaluation against your own cases with compliance and the process owner signing off before go-live.
- 04
Run in production
We stay on with retraining, reporting and ongoing oversight for as long as the workflow runs.
Fixed price, Fixed timeframe. 8–12 weeks pilot: Continue (Expand once you know it works) / Stop.