Traceability Matrix
Purpose
This page documents how security elements are linked across the lifecycle in the Scheol Security Lab.
The objective is to ensure that:
- every risk is addressed by one or more controls
- every control is implemented and documented
- every control is supported by evidence
- every control can be validated or monitored
This structure supports auditability, consistency, and security reasoning.
Traceability Logic
The lab follows a simplified traceability chain:
Risk → Control → Implementation → Evidence → Validation
Each step answers a key question:
| Element | Question Answered |
|---|---|
| Risk | What are we protecting against? |
| Control | What should be in place? |
| Implementation | How is it implemented? |
| Evidence | How do we prove it exists? |
| Validation | How do we know it works? |
Matrix Structure
The traceability matrix links key elements together in a structured way.
| Risk ID | Scenario | Control ID | Implementation | Evidence | Validation | Status |
|---|---|---|---|---|---|---|
| R-001 | S-001 | CTRL-AC-01 | SSH access restrictions | SSH config, logs | Brute-force detection test | In Progress |
| R-002 | S-002 | CTRL-NW-02 | Reverse proxy isolation | Nginx config | Exposure scan | Planned |
Usage Principles
The matrix is intended to:
- provide a high-level view of coverage
- identify missing links in the security chain
- support audit and review activities
It is not intended to:
- replace detailed documentation
- duplicate information already present in other sections
Each entry should remain concise and referential.
Linking Rules
To maintain consistency:
- Risk IDs must match entries in the Risk Register
- Scenarios must reference Threat Scenarios
- Control IDs must match the Control Framework
- Evidence should reference observable artefacts
- Validation should reference monitoring or testing activities
Broken or missing links indicate:
- incomplete implementation
- lack of evidence
- missing validation
Interpretation of Status
| Status | Meaning |
|---|---|
| Established | Fully implemented, evidenced and validated |
| In Progress | Partially implemented or missing evidence/validation |
| Planned | Not yet implemented |
This status reflects end-to-end completeness, not just implementation.
Known Limitations
At the current stage:
- the matrix is partial and manually maintained
- some links between controls, evidence and validation are incomplete
- validation activities are not systematically defined
- consistency across entries is still improving
The matrix should be considered a progressive tool, not a fully mature system.
Relationship with Other Sections
The traceability matrix connects:
- Risk Register → defines risks and scenarios
- Control Framework → defines expected controls
- Applied Architecture → describes implementation
- Evidence Model → defines proof structure
- Validation & Monitoring → provides effectiveness verification
It acts as the central linkage point across the documentation.
Current Maturity
At the current stage, traceability is considered early and partially implemented.
Established
- definition of a clear traceability chain (risk → control → evidence → validation)
- initial linkage between risks and controls
- early attempts to document implementation and evidence
In Progress
- extension of traceability across all major risks and controls
- improved consistency of identifiers and references
- gradual inclusion of evidence and validation elements
Planned / Next Phase
- broader and more consistent population of the matrix
- improved linkage with validation and monitoring activities
- stronger support for audit simulation and review scenarios
- reduction of manual inconsistencies
This page is expected to evolve into a central audit support artefact.