Skip to main content

Documentation Approach

Purpose​

This page explains how Scheol Security Lab is documented, structured and maintained over time.

The objective is not to reproduce a formal enterprise documentation program, but to keep the lab coherent, reviewable and aligned with the actual state of the environment as it evolves.

The documentation is designed to support both security reasoning and technical traceability, while remaining honest about the project’s current maturity.

Core Documentation Logic​

Scheol is documented around a simple core chain:

Risk → Control → Validation → Evidence

This structure is used throughout the site to connect:

  • identified risks and exposure concerns,
  • architectural or governance decisions,
  • implemented or planned controls,
  • validation or monitoring activities,
  • and the evidence supporting those elements.

This logic helps keep the documentation consistent across both strategic and technical topics.

Documentation Structure​

The site is organized into the following main documentation areas:

  • Overview - project framing, maturity, roadmap and documentation principles
  • Governance & Risk - scope definition, threat scenarios, risk reasoning and decision logic
  • Applied Security Architecture - trust boundaries, segmentation, administrative access and exposure decisions
  • Control Framework - control definition, mapping, implementation status and residual gaps
  • Validation & Monitoring - review logic, observability and control verification activities
  • Audit & Evidence - traceability, supporting artifacts, decision records and review readiness
  • Continuous Improvement - open gaps, next-phase priorities and lessons learned
  • Technical Documentation - supporting technical references and implementation context

Each area contributes to the same documentary objective: keeping security reasoning, implementation choices and reviewability connected.

Documentation Status Model​

To avoid overstating maturity, the documentation distinguishes between three implementation states:

Established​

Used when a topic, decision or control is already implemented and sufficiently documented to reflect its current state with reasonable confidence.

In Progress​

Used when the topic is actively being structured, implemented or documented, but is not yet considered stable or complete.

Planned / Next Phase​

Used when the topic has been identified as relevant and is expected to be addressed later, but is not yet implemented or documented in a meaningful way.

This status model is intentionally simple and is used across the site to keep progress visible without creating artificial maturity claims.

Methodological Position​

Scheol is informed by a small set of reference approaches used as structuring influences, not as certification claims or strict implementation targets.

These include:

  • EBIOS RM for threat-scenario reasoning and qualitative risk structuring
  • ISO/IEC 27001 for governance-oriented control logic
  • NIST CSF for lifecycle and security function framing
  • GDPR-related considerations where personal data, traceability and security of processing are relevant

These references are used pragmatically to improve consistency, not to suggest formal compliance or organizational maturity that the lab does not claim to have.

Traceability Principle​

The documentation aims to keep each important security element traceable across multiple layers whenever relevant.

In practical terms, this means trying to connect:

  • a risk or concern
  • to a control or design decision
  • to a validation or review activity
  • to the evidence or documentation supporting it

Not every topic is fully traceable yet, but this remains a central documentation objective across the lab.

Ownership and Responsibility​

For documentation consistency, Scheol uses a simplified set of functional roles to represent ownership and responsibility within the lab.

These roles do not represent real teams, but are used to clarify who is responsible for a given topic, decision or implementation area.

The main roles used throughout the documentation are:

  • Security Role (Sec) - risk reasoning, control definition and governance-oriented documentation
  • Operations Role (Ops) - infrastructure operation, system maintenance and availability-related concerns
  • Development Role (Dev) - application-level configuration, automation and implementation-related changes when relevant

This simplified ownership model helps keep responsibilities understandable without overstating organizational complexity.

Documentation Maintenance​

Because the lab is still evolving, the documentation is expected to evolve with it.

Updates may occur when:

  • architecture decisions change,
  • new risks or control gaps are identified,
  • validation activities are added or refined,
  • or existing documentation is found to be incomplete, outdated or misleading.

The objective is not to keep the documentation artificially polished, but to keep it progressively more accurate, useful and defensible over time.