What is a cybersecurity assurance framework?

A cybersecurity assurance framework is a structured way to establish, evidence and report that a system's security controls exist and operate as intended. Traditional frameworks such as NIST CSF 2.0, IEC 62443, SOC 2 and ISO/IEC 27001 organise that work around controls, clauses and assessment windows.

How does a Security Story differ from a framework score?

A score compresses evidence into a single verdict and discards the reasoning. A Security Story keeps the reasoning attached to signed evidence: every assertion declares whether it is a fact, inference, judgment, recommendation or preserved unknown, so a reader can dispute the interpretation without disputing the facts.

Does LRRK replace NIST CSF, IEC 62443 or SOC 2?

No. LRRK is a comprehension layer that sits alongside those programmes. Assertions cite the framework requirement they bear on, so an auditor can traverse from a signed passport event to the clause it evidences while the existing profile, target level or attestation stays intact.

Which cybersecurity assurance framework applies to cyber-physical systems?

IEC 62443 is the closest fit for industrial automation and control systems, with NIST CSF covering organisational functions. Neither carries per-device assurance history after commissioning, which is the gap a Product Security Passport fills for machines that sense, move and act.

How are negative or inconclusive results handled?

They are retained. 'Not established', 'rejected' and 'inconclusive' are recorded outcomes with method, scope and limitations attached, and preserved unknowns survive into the Passport so later evidence can close them rather than inherit an assumption.

How often is assurance evidence updated?

Continuously. Evidence is append-only and history is never rewritten; new device campaign results revise the interpretation, which is versioned, reviewable and attributable to a named human disposition rather than expiring on a certificate date.

Reference

Cybersecurity assurance frameworks, and what a Security Story addsA framework tells you which controls should exist. A Passport tells you what this machine has actually demonstrated, and when.

Teams researching a cybersecurity assurance framework are usually looking for a reporting methodology they can defend. NIST CSF, IEC 62443, SOC 2 and ISO/IEC 27001 each answer part of that need. None of them was designed to carry the continuous, per-device assurance history of a system that senses, moves, and acts. LRRK is the comprehension layer that sits alongside them.

§ 01

What each framework establishes — and where it stops

NIST CSF 2.0: Organisational function coverage — Govern, Identify, Protect, Detect, Respond, Recover.; Boundary — Describes what functions an organisation should perform. It does not carry per-device evidence, nor a record of what a specific fielded machine has actually demonstrated.
IEC 62443: Security levels and requirements for industrial automation and control systems.; Boundary — Scopes capability and target levels for products and zones. Conformance is point-in-time; drift after commissioning is outside the artefact.
SOC 2: Attested operating effectiveness of controls over a reporting period.; Boundary — Speaks about the vendor's control environment, not about the kinematic behaviour of the unit you installed last quarter.
ISO/IEC 27001: Management-system certification for information security.; Boundary — Certifies that a system for managing security exists and is maintained. It is not a claim about any single component's assurance history.

§ 02

From scores to stories

A score compresses evidence until the reasoning is gone. A Security Story keeps the reasoning attached to the evidence, so a reader can disagree with the interpretation without disputing the facts.

Unit of record: Framework: control, clause, or requirement satisfied.; Security Story: a Passport for one product or component, with an append-only chain of signed events.
Truth of a claim: Framework: pass / fail / partially implemented.; Security Story: every sentence declares whether it is a fact, inference, judgment, recommendation, or preserved unknown.
Negative results: Framework: usually absent from the report.; Security Story: 'not established', 'rejected', and 'inconclusive' are retained outcomes with method, scope and limitations attached.
Time: Framework: an assessment window, then an expiry date.; Security Story: continuous. New campaign evidence revises the interpretation; history is never rewritten.
Aggregation: Framework: a maturity tier or an overall opinion.; Security Story: no single number. Confidence describes the support behind an assertion, not how safe the subject is.

§ 03

How the model complements existing assurance programmes

Framework mapping stays intact: A Security Story does not replace your NIST CSF profile, 62443 target level, or SOC 2 report. Assertions cite the framework requirement they bear on, so an auditor can traverse from a signed event to the clause it evidences.
Evidence becomes owner-authorized: Device campaigns run under explicit owner authorization. What the lab learns is bound to a device identity, not to a questionnaire response.
Interpretation is revisable, evidence is not: Facts are append-only. The reading of those facts is versioned, reviewable, and attributable to a named human disposition.
Unknowns survive the report: Where a framework leaves a control 'not applicable', a Passport preserves the gap so that later evidence can close it rather than silently inherit an assumption.

§ 04

Common questions

What is a cybersecurity assurance framework?: A cybersecurity assurance framework is a structured way to establish, evidence and report that a system's security controls exist and operate as intended. Traditional frameworks such as NIST CSF 2.0, IEC 62443, SOC 2 and ISO/IEC 27001 organise that work around controls, clauses and assessment windows.
How does a Security Story differ from a framework score?: A score compresses evidence into a single verdict and discards the reasoning. A Security Story keeps the reasoning attached to signed evidence: every assertion declares whether it is a fact, inference, judgment, recommendation or preserved unknown, so a reader can dispute the interpretation without disputing the facts.
Does LRRK replace NIST CSF, IEC 62443 or SOC 2?: No. LRRK is a comprehension layer that sits alongside those programmes. Assertions cite the framework requirement they bear on, so an auditor can traverse from a signed passport event to the clause it evidences while the existing profile, target level or attestation stays intact.
Which cybersecurity assurance framework applies to cyber-physical systems?: IEC 62443 is the closest fit for industrial automation and control systems, with NIST CSF covering organisational functions. Neither carries per-device assurance history after commissioning, which is the gap a Product Security Passport fills for machines that sense, move and act.
How are negative or inconclusive results handled?: They are retained. 'Not established', 'rejected' and 'inconclusive' are recorded outcomes with method, scope and limitations attached, and preserved unknowns survive into the Passport so later evidence can close them rather than inherit an assumption.
How often is assurance evidence updated?: Continuously. Evidence is append-only and history is never rewritten; new device campaign results revise the interpretation, which is versioned, reviewable and attributable to a named human disposition rather than expiring on a certificate date.

§ 05

Where to read further

The assertion taxonomy, evidence outcomes and confidence bands behind every sentence are documented in the method reference. The archive itself shows the model applied to fielded machines.

Read the Security Story method →Browse the Assurance Atlas →Request an assessment →

Nothing on this page is a certification, approval, warranty, or guarantee of safety. This demonstration is a designed workflow, read-only and generated from fixtures.