Noru

Risk · A live register, and a number

A risk register fed by your systems, scored in money.

Not a spreadsheet you rebuild before the board meeting. Noru's register is written to by security findings, vendor posture, control drift and privacy assessments — scored, owned and tracked to treatment — and the risks that matter can be decomposed the Open FAIR way and simulated into an annual loss in currency.

Book a demoExplore the platform

The way this usually goes

The risk register is a spreadsheet someone refreshes the week before the board meeting, then forgets.

A 5×5 heatmap says a risk is red; it cannot say whether that is a 4% chance of losing 20 million or a 40% chance of losing 200 thousand.

Treatments get logged once and never followed to resolution, so residual risk is a subtraction rather than an outcome.

Where risks come from

A register fed by the systems, not the workshop.

A register is only as current as whatever writes to it. Noru's is written to by the security findings your scanners and cloud security services raise, the vendor register, control drift, privacy assessments and the assets your cloud sync discovers — each risk keeping the source it came from, so a re-sync updates the record instead of adding a duplicate.

8ways a risk enters the register, each keeping its source

Every risk carries an owner, a status and an audit trail

  • Security findings

    Vulnerabilities and misconfigurations from your scanners and from AWS Security Hub and GCP Security Command Center, each carrying its CVE and CVSS, linked to the risk it drives.

  • Vendor posture

    Inherent and residual scores from the vendor register, with the data categories, locations and identity-provider grants that sit beside them.

  • Control drift

    A control that stops passing between audits opens the risk it was mitigating, with the evidence that went missing named on the record.

  • Privacy assessments

    A DPIA that lands on high residual risk, or a transfer without a safeguard, links to the risk it creates with its processing activity attached.

  • Assets

    Every risk can point at the compute, database or repository it lives on — discovered by the cloud sync rather than typed in.

  • AI-inferred

    Risks Noru proposes from what it sees across findings and controls, held in their own status until a person accepts them.

  • External sync

    Risks synced from another system keep their source and external id, so a re-sync updates the record instead of duplicating it.

  • Entered by hand

    The workshop risk still exists. It just sits in the same register, with the same owner, treatments and audit trail as the rest.

Inherent and residual

Two matrices, one register.

Every risk is scored twice: likelihood and impact before treatment, and again after the treatments credited against it. The register draws both as matrices so the concentration is visible — and the shift between them is what the treatment plan actually bought. The matrix shows the scoring as owners entered it; it does not normalise their assumptions, and the page does not pretend it does.

  • Likelihood rare to certain, impact negligible to catastrophic, level derived
  • Residual is the post-treatment estimate of the same register, not a smaller one
  • Every risk links to the controls that mitigate it and the evidence behind them
Risk/Register
Live
Risk/Review queue
3 need review

Treatments tracked, not logged

Every treatment moves a number.

A treatment in Noru is not a note. It names an action, an owner, a due date and the likelihood and impact it is meant to reach, and it moves through planned, in progress and completed with the evidence item that proves it attached. Findings link to the risk they drive; risks the platform infers from them wait in their own status until a person accepts them.

  • Target likelihood and impact on the treatment, so residual is a stated goal
  • Security findings with CVE and CVSS linked to the risk, not filed beside it
  • Risk logs record who changed what and when, per risk

Quantified · Open FAIR

From a colour on a heatmap to a loss in money.

A 5×5 heatmap says a risk is red. It cannot say whether that is a 4% chance of losing 20 million or a 40% chance of losing 200 thousand, and those need different decisions. Noru's analysis engine decomposes a risk the way Open FAIR does — how often a loss event happens, and how much it costs when it does — takes calibrated ranges rather than point guesses, and simulates the year ten thousand times over.

Annualised loss exposurerisk

currency per year · loss event frequency × loss magnitude

  • Loss Event Frequency

    lef

    events per year

    ×

    • Threat Event Frequency

      tef

      events per year

      ×

      • Contact Frequency

        tef.contact_frequency

        contacts per year

      • Probability of Action

        tef.probability_of_action

        probability

    • Vulnerability

      vulnerability

      probability

      vs

      • Threat Capability

        vulnerability.threat_capability

        percentile

      • Resistance Strength

        vulnerability.resistance_strength

        percentile

  • Loss Magnitude

    lm

    currency per event

    • Productivity
    • Response
    • Replacement
    • Fines & judgments
    • Competitive advantage
    • Reputation

    +

    • Primary loss

      lm.primary

      currency

    • Secondary loss

      lm.secondary.magnitude

      currency

Three estimates, side by side

  • Analyst

    A calibrated 90% confidence range from the person who knows the system, fitted to a lognormal.

  • Evidence-derived

    A range derived from the open security findings and the control coverage the platform already holds.

  • AI-proposed

    A prior proposed from the scenario's context, returned as a suggestion an analyst confirms or replaces.

Distributions an estimate can carry

  • lognormal90
  • pert
  • poisson
  • beta
  • triangular
  • uniform
  • empirical

Plus the legacy 5×5 heatmap, registered as a method of its own so a register entry and a fully decomposed scenario land on one chart.

Reproducible runs

Same seed, same answer, a year later.

Every run records its seed, its iteration count, the engine version and a snapshot of every input, so the same inputs give the same numbers a year later and a board can ask what changed. Treatments declare which factor they move and by how much, so residual risk is a re-simulation rather than a subtraction — and the legacy heatmap is registered as a method of its own, so the register you have and the scenario you build land on one chart.

  • Immutable runs: seed, iterations, engine version and input snapshot on every one
  • Three estimates per factor — analyst, evidence-derived, AI-proposed — side by side
  • Portfolio exposure summed year by year, because the enterprise tail is not the sum of the scenario tails

A scenario is a register risk made specific: who the threat is, how they get in, and what the effect is. It keeps the risk's identity, owner and control links; what it adds is a place for numbers.

curl -X POST https://api.noru.tech/v1/risk-analysis/scenarios \  -H "Authorization: Bearer $NORU_API_KEY" \  -H "Content-Type: application/json" \  -d '{    "title": "Public bucket exposes customer exports",    "riskId": "NORU-RISK-42",    "assetId": "customer-exports",    "threatCommunity": "opportunistic external",    "threatVector": "misconfigured object ACL",    "effect": "confidentiality",    "currency": "EUR"  }'

Appetite as a curve

At most P% chance of losing X in a year.

Risk appetite is usually a sentence in a policy. Here it is a tolerance curve — at most this chance of losing at least that much in a year — anchored to something real, like the cyber insurance limit or the cash reserves. The portfolio's loss exceedance curve is evaluated against it, and the answer names the threshold that is breached and by how much, rather than a colour.

  • One active appetite curve per organisation, with the basis it is grounded in recorded
  • Evaluation names the breached threshold and the margin, per scenario and for the portfolio
  • Tornado analysis says which factor the answer is most sensitive to
Risk/Portfolio

Board-ready

Five reports, versioned on demand.

Reports read the register as it stands, and generating one stores a versioned snapshot with who generated it and when — so the pack the board saw in March is the pack that can be reopened in September, and the difference between them is a question the register can answer.

  • 01

    Risk Assessment Report

    The register as scored today: top risks, owners, inherent and residual.

  • 02

    Risk Treatment Plan Summary

    Every planned and in-progress treatment, with its target and its due date.

  • 03

    Compliance Review Summary

    Risks against the controls that mitigate them and the evidence behind those.

  • 04

    Corrective Actions Summary

    What was found, what was done about it, and what is still open.

  • 05

    Vendor Risk/Agreement Summary

    Third-party exposure and the agreements that bound it, from the vendor register.

Who it's for

One system, every stakeholder

Security & CISO

Risk scored off live signals from your stack, not a once-a-year workshop guess.

Compliance & GRC

A register auditors trust because every risk links to the controls and evidence behind it.

Risk owners

Treatments with an owner, a due date and a target score, moved through planned, in progress and completed with the evidence attached.

Leadership & board

An appetite stated as a curve, a portfolio loss exceedance curve evaluated against it, and versioned reports current the day you present them.

What's included

Platform modules working together

This solution runs on the same system of record as everything else — add modules later without re-platforming.

Risk Register

Know your risk before anyone asks

A live register linked to security findings, controls and treatments — not a yearly workshop artifact.

Security

Track every finding to resolution

Certificates, vulnerabilities and pen-test findings tracked to resolution and linked to risk.

Vendor Risk

See every vendor's posture

A vendor register with risk scoring, security questionnaires and evidence collected from responses.

Controls

Implement once, satisfy many

One control library, mapped across ISO 27001, SOC 2, GDPR and 30+ frameworks — the same evidence reused everywhere.

Works with

  • AWS
  • GCP
  • GitHub
  • Microsoft
  • Cloudflare
  • more

Book a demo

See it on your own data.

A walkthrough against your own findings, vendors and controls, with your questions answered by practitioners.

  • 45 minutes, tailored to the frameworks and use cases you care about
  • Answers from practitioners, not a sales script
  • Leave with a concrete rollout plan — or a clear no-fit

We respond within one business day. No mailing lists, no spam.

FAQ

Frequently asked questions

What security leads and risk owners ask before they retire the spreadsheet.

Talk to us

Where do risk scores come from?

Each risk carries inherent and residual likelihood and impact, and the inputs are live: security findings from your scanners and cloud security services, vendor assessments, control drift and privacy assessments write to the register, each risk keeping the source it came from. Risks Noru infers from those signals wait in their own status until a person accepts them.

How is this different from a risk spreadsheet?

A spreadsheet is a snapshot you maintain by hand. Noru's register is fed by your systems, links every risk to the controls and evidence behind it, gives every risk an owner and every treatment a due date and a target score, and keeps a log of who changed what — current by default.

Can it put a number on a risk, not just a colour?

Yes. A register risk can be made into a scenario and decomposed the Open FAIR way — loss event frequency and loss magnitude, down to contact frequency, probability of action, threat capability and resistance strength where you can defend it. Estimates are calibrated ranges fitted to distributions rather than point guesses, three estimate sources are shown side by side, and a seeded Monte Carlo run produces an annualised loss, a loss exceedance curve and an evaluation against your appetite curve. Every run records its seed, iterations, engine version and inputs, so it reproduces exactly.

Does it cover privacy and vendor risk too?

Yes. Privacy assessments link to the risks they raise, vendor risk scores feed the register from the vendor record, and AI systems in the AI register resolve to the vendor and asset records the register already points at — so exposure across security, privacy and third parties reads from one place.

Related solutions

Get certified · Stay certified

Agentic Compliance

Learn more

Vendors · TPRM

Third-Party Risk Management

Learn more