Control Catalog
Purpose
This page defines the structured set of security controls used within Scheol Security Lab.
The objective is to provide a consistent, reviewable and traceable control reference, supporting:
- risk treatment decisions
- control implementation tracking
- validation and monitoring activities
- audit and evidence generation
The catalog reflects controls that are actually implemented or planned, not an abstract or exhaustive framework.
Control Definition Model
Each control in the catalog is defined using a consistent structure.
Required Attributes
| Field | Description |
|---|---|
| Control ID | Unique identifier (C-XXX) |
| Control Name | Short descriptive name |
| Objective | What the control is intended to achieve |
| Type | Preventive / Detective / Corrective |
| Scope | Systems, zones or assets concerned |
| Implementation | High-level description of how the control is implemented |
| Related Risks | Link to associated risk entries |
| Validation Method | How effectiveness is verified |
| Status | Established / In Progress / Planned |
| Owner | Responsible role (Sec / Ops / Dev) |
Control Categories
To maintain readability and consistency, controls are grouped into logical categories.
1. Identity & Access Control
- authentication mechanisms
- privileged access management
- account lifecycle
2. Network & Exposure Control
- segmentation
- firewalling
- service exposure control
3. System Hardening
- baseline configurations
- patch management
- service minimization
4. Monitoring & Detection
- logging
- alerting
- detection logic
5. Backup & Recovery
- backup mechanisms
- restore validation
- data resilience
6. Governance & Documentation
- policy definition
- documentation practices
- traceability mechanisms
Control Granularity
Controls are intentionally defined at a practical level:
- not too high-level (e.g. “ensure security” → useless)
- not too technical (e.g. exact config commands → belongs elsewhere)
The goal is to describe controls in a way that is:
- understandable
- auditable
- linkable to risks and validation activities
Relationship with Risk Management
Each control in the catalog must be:
- derived from a risk treatment decision
- linked to one or more risk entries
- traceable to implementation and validation evidence
This ensures a consistent chain:
Risk → Control → Implementation → Validation → Evidence
Relationship with External Frameworks
The catalog is internally defined, but aligned with external references such as:
- ISO 27001
- NIST CSF
- GDPR
Mapping to these frameworks is handled separately in the Control Mapping section.
This avoids mixing:
- internal operational logic (this page)
- external compliance alignment (mapping page)
Current Maturity
At the current stage, the control catalog is considered in progress.
Established
- initial control structure and categorization
- definition of control attributes
- early identification of key controls linked to major risks
In Progress
- progressive population of the catalog with real controls
- alignment between controls and actual implementation
- linkage between controls and risk register entries
- definition of validation methods for each control
Planned / Next Phase
- full coverage of major risk areas with documented controls
- improved consistency across control definitions
- stronger linkage with monitoring and validation data
- preparation for audit-oriented traceability
This catalog is therefore expected to evolve as the lab matures and additional controls are implemented and validated.