Skip to main content

Improvement Workflow

Purpose​

This page defines how security improvements are identified, prioritised, implemented and tracked within Scheol Security Lab.

The objective is to ensure that security is not treated as a static state, but as a continuous, risk-driven process.

Core Principle​

Security evolves through controlled feedback loops, not one-time implementation

Improvements are driven by:

  • identified risks
  • control gaps
  • detection limitations
  • architectural constraints
  • audit observations

Improvement Sources​

Security improvements can originate from multiple inputs:

1. Risk Management​

  • new or updated risk entries
  • changes in likelihood or impact
  • emerging threat scenarios

2. Control Framework​

  • missing or weak controls
  • incomplete control coverage
  • inconsistencies between expected and implemented controls

3. Validation & Monitoring​

  • detection gaps
  • lack of visibility
  • ineffective monitoring coverage

4. Audit & Evidence​

  • missing or insufficient evidence
  • traceability gaps
  • audit observations or simulated findings

5. Architecture & Operations​

  • design limitations
  • exposure issues
  • operational constraints

Improvement Lifecycle​

Each improvement follows a structured lifecycle:

1. Identification​

  • issue, gap, or opportunity is identified
  • linked to a risk, control, or observation

2. Qualification​

  • assess impact on security posture
  • determine urgency and scope

3. Prioritisation​

  • based on:
    • risk level
    • exposure level
    • operational constraints

4. Decision​

  • improvement is:
    • accepted
    • postponed
    • rejected (with justification)

5. Implementation​

  • technical or organisational changes are applied
  • may involve architecture, controls, or monitoring

6. Validation​

  • verify that the improvement reduces risk or improves control effectiveness

7. Documentation Update​

  • update:
    • risk register
    • control status
    • architecture documentation
    • evidence records

Traceability Expectations​

Each improvement should be traceable across:

  • Risk → Control → Implementation → Validation → Evidence

Where applicable, improvements should reference:

  • risk entries (R-XXX)
  • decision records (ADR-XXX)
  • control framework elements
  • validation or monitoring results

Improvement Tracking​

Improvements are tracked through:

  • Security Debt Register (unresolved gaps)
  • Decision Records (ADR) for structural changes
  • Control Status for implementation tracking

This ensures visibility on:

  • what is pending
  • what is in progress
  • what has been resolved

Governance & Ownership​

  • Security Role (Sec)
    Responsible for identifying, prioritising and validating improvements

  • Operations Role (Ops)
    Responsible for implementing infrastructure-related improvements

  • Development Role (Dev)
    Responsible for application and automation-related improvements

Current Maturity​

At the current stage, continuous improvement is considered early-stage but structured.

Established​

  • identification of major security gaps
  • linkage between risks and improvement actions
  • initial use of decision records (ADR)

In Progress​

  • formalisation of improvement workflow
  • consistency in tracking improvements
  • better linkage across documentation layers

Planned / Next Phase​

  • systematic improvement tracking
  • measurable validation of improvements
  • integration with audit and evidence processes

This workflow is intended to progressively evolve into a repeatable and auditable improvement cycle.