Security and governance
Risk management
Security controls, risk assessment and treatment, threat advisories, and the information lifecycle.
Risk (Platform › Risk) is the register where security risks are assessed, treated and tied to the controls that mitigate them. This page describes the practice each part of the platform supports and where the data lives.
Risk assessment
A risk names an asset, a threat and the scenario that joins them. Each risk is scored two ways:
- Qualitative — likelihood (1–5) × impact (1–5) gives a score of 1–25 and a band: low (<5), medium (5–9), high (10–15), critical (16–25). Use this for every risk; it is enough to rank the register.
- Quantitative — when the loss can be priced, record the asset value, the exposure factor (the share of the asset one event destroys, 0–1) and the annualised rate of occurrence. The platform reports the single loss expectancy (
SLE = asset value × exposure factor) and the annualised loss expectancy (ALE = SLE × ARO). Compare a control's yearly cost with the ALE it removes before funding it.
Practice: assess the inherent risk first (no controls assumed), record the owner and a review date, and reassess on that date or when the threat, the asset or a control changes.
Risk treatment
Every risk carries one treatment:
| Treatment | Meaning | Record on the risk |
|---|---|---|
| Mitigate | Reduce likelihood or impact with controls | The linked controls and the residual scores |
| Transfer | Move the loss to another party (insurance, a contract) | The plan and the residual scores |
| Avoid | Stop the activity that carries the risk | The plan; close the risk when done |
| Accept | Carry the risk knowingly | The plan (who accepted, why); status accepted |
After treatment, set the residual likelihood and impact; the register shows both the inherent and residual band so the effect of the treatment is visible. A risk whose residual band is still high or critical needs another treatment or a documented acceptance by its owner.
Security controls
Controls are kept in one catalog so a control that mitigates several risks is recorded once. Each control has:
- a framework reference (for example ISO 27001 A.5.17, NIST CSF PR.AA-01, CIS 5.2) so audits map cleanly;
- a type — preventive (stops the event), detective (finds it), corrective (recovers from it); a risk is usually covered by one of each;
- a status — planned → implemented → verified → retired; only a verified control should lower a residual score;
- evidence — where the proof of operation lives (a ticket, a report, an audit log query).
Link a control to each risk it mitigates from the risk's detail. Platform controls you can cite as evidence: markings and classification, audit logging, human approval and sign-in and roles.
Threat intelligence
Two surfaces work together:
- Threat Intel (Analyze) looks up a CVE, an EDB-ID or an indicator (hash, IP, domain, URL) against the exploit index and reputation services. Put the identifier in the risk's threat reference so the lookup is one click from the risk.
- Advisories on the Risk surface are the records you keep: a vendor or CERT bulletin, an exploit release, an indicator seen in your environment — with a severity, a source and a publication date, raised against the risk it changes.
Practice: when an advisory arrives, find or file the risk it affects, raise its likelihood if the threat is now active, and review the linked controls' status.
Security and the information lifecycle
Data is protected at each stage with features that already exist on the platform:
| Stage | Platform feature |
|---|---|
| Create / collect | Sources with egress policies and encrypted credentials; markings applied at the dataset |
| Store | Markings and classification gate every read; row-level security on object types |
| Use / share | Roles and resource grants; human approval for sensitive actions; the audit log records who read what |
| Retain | Dataset retention policies (max age, max rows) and Data Lifetime policies on transaction history |
| Destroy | Retention purge and Data Lifetime apply; every purge is an audit event |
Data destruction
Destruction is scheduled, not ad hoc:
- Set a retention policy on the dataset branch (max age or max rows) or a Data Lifetime policy on its transaction history. Data Lifetime shows downstream dependents before it removes anything.
- Let the retention loop run, or trigger Purge now for an immediate, logged removal.
- The audit log holds the destruction record (
dataset:purge,retention:apply): the resource, the actor, the time and the rows removed. Export that entry when a certificate of destruction is required.
Backups and exports outside the platform are not covered by a purge; list them as an asset on the relevant risk and treat them separately.