Introduction & design principles
OCDFThis framework's scope and design principles, built on NIST CSF 2.0.
Purpose
This framework describes what a Cyber Defence Center (CDC) must be able to do, whether that capability is a 24/7 department or two people in IT who also handle security, how to build those capabilities from zero, and how to measure maturity over time. It deliberately avoids naming commercial products: every capability can be met with open source, commercial, or hybrid tooling.
Terminology
The four terms below are the foundation; every other term the framework uses is explained in OCDF on one page.
- CDC — a Cyber Defence Center: the organisational capability that governs, prevents, detects, responds to and recovers from cyber threats. We use CDC and SOC (Security Operations Center) interchangeably; "CDC" emphasises that the capability is broader than monitoring alone. The term names the function, not a department or a size: if your organisation calls it the IT-security team, or it is part of one person's job, the framework still applies. Where the text says "the CDC", read "whoever does this work for you". The organisational form only matters in operating models and roles & competences, and the tiers say how much applies at your size.
- NIST CSF 2.0 — the NIST Cybersecurity Framework version 2.0, published February 2024, organised into six functions: Govern, Identify, Protect, Detect, Respond, Recover.
- CIA triad — Confidentiality, Integrity, Availability: the three classic security objectives that every control ultimately serves.
- Essential and important entities — the two categories of organisations in scope of the EU NIS2 Directive.
Scope boundary: IT, not OT/telco
This framework is written for enterprise IT security operations. OT/ICS environments, where availability and physical safety dominate and active scanning or host isolation can be hazardous, and telco core networks, separately regulated in most member states, require different technical approaches. Do not apply the PROTECT/DETECT/RESPOND content to those domains unadapted. The governance and maturity concepts transfer; the technical guidance does not. See About and the IT/OT interface.
Design principles
- Standards-first. The backbone is NIST CSF 2.0. Detection engineering references MITRE ATT&CK. Incident handling references NIST SP 800-61, the Dynamic Approach to Incident Response and FIRST/ENISA good practice. This maximises interoperability with auditors, regulators, and peer organisations.
- CIA as the design lens. Every capability in this framework states which legs of the CIA triad it protects, or that it is an enabler the others depend on, such as governance and exercises. For a technical control, if you cannot articulate what it does for Confidentiality, Integrity or Availability, question whether you need it.
- EU-regulation aware. Each function document contains an "EU regulatory hooks" section mapping capabilities to NIS2, DORA, GDPR and related obligations. The framework helps demonstrate compliance; it is not legal advice.
- People > Process > Technology, in that order. Most SOC failures are organisational, not technical. Governance and staffing come before tooling in every build sequence.
- Maturity is incremental. The framework defines four maturity levels; see the maturity model. Level 2 is achievable by a small team in months, not years.
- Vendor-neutral and open. No product names in normative text. Community contributions of tooling examples belong in non-normative appendices.
The greenfield build sequence
If you are building a CDC from the ground up, every function starts in the first 90 days, in its minimum form, and then matures in the order of its dependencies:
| Stream | First 90 days, the minimum | Then, to maturity | Framework docs |
|---|---|---|---|
| Mandate | Signed charter with containment authority; regulatory applicability register | Risk integration, multi-year budget, executive reporting | Govern |
| Visibility | Crown jewels agreed; priority log sources identified | Asset inventory accuracy, threat profile, risk assessment | Identify |
| Foundation controls | MFA, one tested offline backup, admin-path segmentation | Hardening, segmentation, data security | Protect |
| Detection | Identity, endpoint and email telemetry flowing, in-house or to a provider | Use-case lifecycle, coverage measurement, hunting | Detect |
| Response | IR plan v1, top playbooks, one reporting drill against the 24 h clock | Tested containment, forensics, management exercises | Respond |
| Resilience | Recovery priorities for the crown jewels | Tested restores against RTO, lessons-learned loop | Recover |
The reporting duty applies from the day an entity is in scope, so response and reporting cannot wait for detection to mature. The dependencies still shape the second column: you cannot detect what you cannot see, and you cannot measure coverage before detections exist. The week-by-week order is in Start here.
Dependency markers
A CDC delivers very little alone, and most stalled CDC programmes stall on another department, not on security work. To make that visible, every function document ends with an "External dependencies" table, and dependencies are classified consistently:
| Marker | Meaning | Handling rule |
|---|---|---|
| [GATE] | Gatekeeper. An external party holds formal decision authority: sign-off, approval, risk acceptance. The checkpoint is by design and cannot be worked around. | Pre-agree the decision criteria and a deputy, so the gate is fast at 03:00. A gate without pre-agreed criteria becomes a hard block at the worst moment. |
| [HARD] | Hard block. The capability cannot be delivered without another team's action or delivery: access, implementation, data, operation. | Name the owning team in the charter interfaces, agree an SLA, and define the escalation path through GOVERN when the SLA slips. |
| [SOFT] | Soft block. External input improves quality or speed, but the CDC can proceed with a degraded result and retrofit. | Proceed, log the debt as an ID-7 improvement item, and revisit. |
Two rules of use: first, every [HARD] on the critical path of the 90-day plan in Start here needs a named counterpart and an executive sponsor aware of it before week 1, because chasing access rights is the most common silent killer of new CDC timelines. Second, [GATE] entries belong in the charter, under authority §4 and interfaces §8, so the gatekeepers themselves have signed up to being gates.
How each function document is structured
Every function document, from Govern to Recover, follows the same layout:
- Objective — what the function achieves.
- Core capabilities — the concrete things your CDC must be able to do.
- CIA mapping — which triad objectives each capability serves.
- Roles & staffing — who does the work.
- Maturity criteria — a link to the function's scored criteria in the maturity self-assessment, the single source for them.
- EU regulatory hooks — relevant NIS2/DORA/GDPR articles and ENISA guidance.
- External dependencies — who outside the CDC this function depends on, marked [GATE]/[HARD]/[SOFT].
- Sources — credited references for that document.
Sections that make claims carry a source label, Law, Standard, Guidance, OCDF or Practitioner, so you can see whether a statement comes from legislation, a published standard, recognised guidance, this framework's own design, or the author's experience. See why trust this framework.
Attribution note
This framework references and builds on the NIST Cybersecurity Framework 2.0, NIST Special Publications, ENISA publications, MITRE ATT&CK®, and FIRST resources. Full credits: References & credits.
Open CDC Framework, licensed CC BY 4.0. Credits: References & credits.