Risk Register - Methodology
Purpose
The Risk Register defines how evaluated risks are formally recorded, tracked and maintained over time within Scheol Security Lab.
It acts as the governance and traceability layer of the risk management process.
Unlike Risk Modeling, it does not define how risks are evaluated, but how they are persisted, reviewed and followed up.
Role in the Security Model
The Risk Register is the operational output of the risk process.
It captures:
- evaluated risks
- their associated scenarios
- their current treatment status
- their evolution over time
- their relationship with controls and validation activities
It ensures risks remain visible and reviewable after initial analysis.
Register Structure
Each risk is documented as a standalone Markdown file:
- 'R-001.md'
- 'R-002.md'
- etc.
This supports:
- versioning
- traceability
- review history
- cross-referencing with scenarios and controls
Required Fields
Each risk entry must include:
| Field | Description |
|---|---|
| Risk ID | Unique identifier |
| Title | Clear risk description |
| Target Asset / Capability | Affected asset or function |
| Related Scenario | Linked threat scenario |
| Likelihood | Evaluated likelihood |
| Impact | Evaluated impact |
| Risk Level | Result from risk matrix |
| Treatment Decision | Accept / Mitigate / Transfer / Avoid |
| Treatment Rationale | Justification of decision |
| Owner / Review Role | Responsible role |
| Associated Controls | Related security controls |
| Residual Concerns | Remaining gaps or uncertainty |
| Last Review | Last update date |
| Next Review | Planned review date |
Usage in Scheol
The Risk Register is used to:
- track identified risks over time
- support control implementation decisions
- maintain visibility on residual exposure
- provide traceability for validation activities
- support structured review cycles
It is a living governance artefact, not a static inventory.
Relationship with Risk Modeling
Risk Modeling defines how risks are evaluated.
Risk Register defines how evaluated risks are stored and maintained.
Together they form a two-layer structure:
- Modeling = analytical layer
- Register = operational layer
Documentation Rules
- Each risk must reference at least one scenario
- Each risk must be linked to at least one asset or capability
- Treatment decisions must be explicitly justified
- Updates must be versioned when meaningful changes occur
Current Maturity
At the current stage, the Risk Register is partially established.
Established
- file-based structure
- naming convention (R-XXX)
- linkage to scenarios and assets
- basic lifecycle tracking logic
In Progress
- consistency of treatment documentation
- completeness across infrastructure domains
- alignment with controls and validation outputs
- improved review discipline
Planned
- full population of all relevant risks
- stronger integration with evidence and validation layers
- improved audit-oriented traceability