Build a SOC

The order matters more than the speed

Every phase gate below exists because skipping it produces a SOC that cannot explain what it does or why. The most commonly skipped one is also the most expensive: technical requirements come after the operating model, not before it.

Phases: P0 – P6
Lean variant: 3 months
Hard gate: Model before tooling

The gate nobody wants to hold

A SOC that buys the platform first ends up defining its services as whatever the platform happens to do. It then discovers, at the first supervisory conversation, that it cannot explain why it monitors what it monitors — because the answer is “because that is what was easy to connect”.

Baseline intake

Understand the regulatory and policy landscape before designing anything.

Obtain the documents that regulate the organisation's cybersecurity activity
Obtain existing information security policy documents and procedures
Analyse them as the basis for the operating model

Deliverables: Document inventory and gap analysis
Gate to the next phase: The document baseline exists and has been read

Mandate and operating model

Define what the SOC is, what it answers for, and what it will deliver.

Draft the mandate, responsibilities and accountabilities
Define roles, groups and the organisational structure
Refine the services for the initial stage
Review the draft charter, job descriptions and incident management plan

Deliverables: Mandate; operating model; organisational structure; initial service catalogue
Gate to the next phase: A prepared and approved SOC model

Processes and policies

Turn the model into working procedures and defined roles.

Prepare the working processes, procedures and rules
Prepare the incident management procedure
Prepare the plan for cooperation with external institutions
Prepare the skills list, job descriptions and training plan

Deliverables: Incident management procedure; cooperation plan; skills list; training plan; the organisational document register
Gate to the next phase: The minimum viable document set is approved

Performance measurement

Make the SOC measurable before it goes live.

Define effectiveness and risk indicators with targets
Prepare the performance measurement procedure
Define the report audiences and their cadences

Deliverables: Internal and external metric sets; measurement procedure; audience map
Gate to the next phase: Metrics are defined and their data sources identified

Technical requirements

Derive tooling from committed services, not the other way round.

Select technical measures with regard to the services planned
Write requirements for the measures and the infrastructure

Deliverables: Technical measures specification; infrastructure requirements
Gate to the next phase: Requirements are written and traceable to services

Technical build and integrations

Stand up the platform and connect it to the wider ecosystem.

Build the log pipeline and confirm telemetry arrives
Establish threat-intelligence exchange with the national centre
Prepare the baseline correlation rule set

Deliverables: Working intelligence exchange; baseline rule set live
Gate to the next phase: Telemetry flows and baseline detections are in production

Detection scenarios, staged

Cover priority attack paths incrementally, proving each stage.

Identify the priority monitoring scenarios and their requirements
Implement the first scenario as the test case
Optimise for performance and accuracy, then implement the rest in tranches

Deliverables: Scenario catalogue; scenario one proven; subsequent tranches live
Gate to the next phase: Scenario one is proven before the rest begin

Lean variant

Three months, prioritised by capability weight

For a small SOC that must be operational quickly. This is not the phased programme compressed — it is a deliberately different sequence that buys the most protection per unit of effort.

Month	What gets done
Month 1	Risk assessment; business impact analysis; monitoring platform integrated and telemetry flowing; threat-intelligence exchange connected
Month 2	Response playbooks for the incidents you will actually see; intelligence feed tested end to end; staff briefed and instructed
Month 3	Automation of the repetitive actions; measurement against the agreed targets; optimisation of the intelligence and evaluation loop

Throughout: risk assessment, business impact analysis and three-layer monitoring — perimeter, workload, user — are the non-negotiable core.

Go-live

The documents without which you cannot demonstrate control

01Approved SOC mandate
02Cyber incident management plan, agreed with any provider involved
03Triage and escalation procedure with written trigger conditions
04Severity model, and separately the statutory significance test
05Log-source catalogue with collection status per required event class
06Detection catalogue with an owner and a response action per rule
07Evidence handling and chain-of-custody procedure
08Stakeholder notification procedure and contact matrix
09Performance measurement procedure with metric definitions
10Shift handover format and on-call rota
11The interface to business continuity: how an incident triggers the plan

Self-assessment

Where are you now?

Twenty-six questions across six dimensions. Answer them as they are, not as they are supposed to be — an honest baseline is the only kind you can improve from, and nothing here is sent anywhere.

Mandate & governance

0/12

A signed SOC mandate exists, approved by the management body.
In-scope and out-of-scope assets are written down and agreed with asset owners.
Containment authority is pre-authorised — the SOC may isolate a host without a meeting.
The mandate is reviewed at least annually and after major change.

Visibility & telemetry

0/12

An inventory of log sources exists and is reconciled against the asset inventory.
Log-source health is monitored — you are alerted when a source stops sending.
Retention meets the longest of legal, contractual and investigative need.
Time synchronisation and consistent timestamps are verified across sources.

Detection engineering

0/12

Detection coverage is mapped to a threat model, not just to vendor defaults.
Every detection rule has a documented response action or playbook.
False-positive rates are tracked per rule and drive a tuning backlog.
New detections are tested before they reach production alerting.

Incident response

0/15

A written triage procedure defines L1/L2/L3 and the escalation triggers between them.
Severity classification criteria are documented and applied consistently.
Playbooks exist for the incident types you actually see.
Evidence handling and chain of custody are defined before you need them.
Out-of-hours coverage is real — named people, tested contact paths.

Regulatory reporting

0/12

The significant-incident test is written down in operational language analysts can apply.
The 24h / 72h / one-month reporting path is rehearsed, with named submitters and a fallback.
Awareness time is recorded explicitly on every incident record.
Reports to the supervisory authority are drafted from templates, not from scratch.

Measurement & assurance

0/12

A monthly report reaches the management body with metrics, not just anecdotes.
MTTD and MTTR are measured from defined, auditable timestamps.
Post-incident reviews produce owned actions that get closed.
Detection efficacy is tested adversarially — purple team, atomic tests or exercises.

SOC build kit Environment onboarding kit First 90 days as SOC Officer