Risk Register - Methodology
Purpose
The Risk Register is used to formally track and maintain all documented risk entries within Scheol Security Lab.
Its role is to centralise the output of the risk modeling process and provide a structured view of:
- what has been identified as a meaningful risk
- what asset or capability is concerned
- what scenario the risk is based on
- how the risk has been evaluated
- what treatment decision has been made
- what controls or follow-up actions are associated with it
The register therefore acts as a core traceability layer between risk reasoning, security decisions and later validation or review activities.
Documentation Logic
Each risk entry in the register represents an evaluated and reviewable risk situation, not a generic concern or isolated observation.
A valid risk entry should always be grounded in:
- a documented asset or capability
- a documented threat scenario
- a documented evaluation logic
- a documented treatment posture
This means the register is not intended to be a loose list of “security problems”, but a structured catalogue of risks that can be reviewed over time.
Register Structure
In Scheol, each identified risk is documented as an individual Markdown file using the R-00X.md naming convention.
This allows each risk to remain:
- individually reviewable
- versioned over time
- easy to cross-reference
- compatible with the broader documentation model of the lab
Expected Fields
Each risk entry should progressively include the following elements:
| Field | Description |
|---|---|
| Risk ID | Unique identifier (e.g. R-001) |
| Title | Short and explicit risk title |
| Target Asset / Capability | Link to the impacted asset, platform, information asset or business capability |
| Related Scenario | Link to the associated threat scenario (S-00X.md) |
| Likelihood | Qualitative likelihood assessment |
| Impact | Overall impact rating derived from the selected criteria |
| Risk Level | Resulting risk level based on the Risk Matrix |
| Treatment Decision | Accept, Mitigate, Transfer or Avoid |
| Treatment Rationale | Short justification for the chosen treatment posture |
| Owner / Review Role | Responsible role for follow-up or review |
| Associated Controls | Existing or planned safeguards related to the risk |
| Residual Concerns | Remaining uncertainty, gaps or limitations |
| References | Relevant documentation, framework references or linked pages |
| Last Review | Date of most recent review |
| Next Review | Planned review date |
This structure is intended to support both clarity and traceability.
How the Register Is Used
The Risk Register acts as the formal bridge between risk analysis and downstream documentation.
It is used to support:
- prioritisation and treatment decisions
- control mapping and implementation follow-up
- review of residual exposure
- evidence and traceability logic
- future audit-oriented review activities
It is therefore one of the main places where the lab’s governance posture becomes visible.
Documentation Conventions
To maintain consistency across the lab:
- each risk is documented as a separate Markdown file
- each risk must reference at least one related threat scenario
- each risk should remain linked to the relevant asset or capability
- significant updates should trigger a version increment
- minor wording or metadata changes should update
last_updated
Expected front matter includes:
titleversionlast_updatedownerreview_frequency
Relationship with Other Pages
The Risk Register should be read as part of the broader documentation chain:
- Context & Assets defines what matters
- Threat Scenario Modeling defines what could happen
- Risk Modeling defines how it is evaluated
- Risk Register defines how it is formally tracked over time
This layered structure is intentional and supports both readability and methodological coherence.
Current Maturity
At the current stage, the Risk Register in Scheol Security Lab is considered partially established.
Established
- overall register logic and file-based structure
- baseline linkage between assets, scenarios and risk entries
- naming convention and documentation expectations
- initial population of core risk entries
In Progress
- broader coverage across all implemented and planned components
- consistency of treatment rationale and review metadata
- stronger linkage between risk entries, controls and validation activities
- improved completeness and documentary quality across entries
Planned / Next Phase
- more complete population of the register across all major lab domains
- stronger support for evidence traceability and audit-oriented review
- improved linkage between treatment decisions and monitoring outcomes
- better integration with future governance and control mapping activities
This page is therefore expected to evolve as the risk model, infrastructure coverage and documentation maturity continue to grow.