Building a SOC from Scratch Guide: People, Process, Technology and First Year Plan

Most new SOCs fail not because they bought the wrong SIEM but because they started with the tool, before deciding what they must protect, what authority they have and which logs actually matter. This guide is for security leaders and the first engineers asked to stand up a security operations centre where none exists, or to replace an informal "someone watches the alerts" arrangement. It covers the mandate and charter, choosing an operating model, the first functions and roles, log source priorities including identity and service account logs, the first detections and processes, and a first-year roadmap with milestones. Staffing arithmetic and rotas are covered separately, and the mature-state view is in the SOC Guide; this page is about getting from nothing to a working, defensible first version.

Key takeaways

• Start with a charter, not a purchase order. MITRE's second strategy is to give the SOC the authority to do its job through an approved charter covering scope, functions and responsibilities.
• Scope to your threat profile. NCSC advises setting capability against an honest estimate of the attackers you face and monitoring critical assets first; starting small and maturing is acceptable.
• Authentication, security control and DNS logs first. These are NCSC's three must-have sources; identity provider, service principal and domain controller logs belong in the first wave.
• Hybrid is normal. Keep context-heavy functions such as triage of business-critical alerts and incident management in-house; buy what you need rarely or cannot staff.
• Measure from month one. Detection coverage, onboarded sources and time to triage give the SOC a story to tell its sponsor at the first annual review.

Mandate, charter and scope

MITRE's 11 Strategies of a World-Class Cybersecurity Operations Center (Knerler, Parker and Zimmerman, 2022) opens with two strategies that come before any technology: know what you are protecting and why, and give the SOC the authority to do its job. Without written authority, a new SOC discovers in its first serious incident that it cannot isolate a server, disable an account or demand logs from a business unit.

A workable charter, signed by an executive sponsor, states:

• Mission: detect, investigate and coordinate response to cyber security incidents affecting named parts of the organisation.
• Constituency and scope: which business units, environments (on-premises, cloud tenants, SaaS, OT) and subsidiaries are in scope, and which are explicitly out.
• Services: monitoring and triage, incident response, threat intelligence, detection content development, and any optional services such as vulnerability management.
• Authorities: what the SOC can do without asking (disable an account, isolate an endpoint, block a domain), what needs approval and from whom, and who can override.
• Hours and escalation: coverage hours, on-call arrangements and the escalation path to IT, legal, communications and the executive.
• Data handling: what data the SOC may collect, how long it keeps it and who can see it. NCSC's operating model guidance lists legal compliance, limits on collecting sensitive data and data retention among the operating principles to settle early.

NCSC's guidance on scoping is blunt: it is very difficult for a SOC to give the same level of monitoring to an entire IT estate, so prioritise by the impact of compromise on each system or service. A one-page list of the ten systems whose compromise would hurt most is the most useful input to every later decision.

Choosing an operating model

NCSC states there is no one-size-fits-all SOC. Its operating model guidance groups SOC functions into four pillars: informing the SOC (threat intelligence), developing capability (content development, engineering), detect and respond (triage, incident response, hunting) and supporting the SOC, and suggests keeping context-heavy functions in-house while outsourcing specialist or infrequently needed ones.

For a first SOC, hybrid is usually the pragmatic answer: an in-house lead, a detection engineer and analysts during business hours, with a provider covering nights and weekends. See the Co-Managed SOC and SOC-as-a-Service Guide and the MDR Guide for structuring that relationship, and the SOC Staffing and Shift Models Guide for team sizing and rotas.

First functions and roles

A new SOC cannot do everything at once. NCSC describes capability as cumulative: advanced functions such as hunting depend on the basics being in place. Build in this order.

Early roles are a SOC lead (owns the charter, metrics and stakeholders), at least one security engineer, analysts, and a named incident manager, which can be the lead in a small team. NCSC recommends against pigeonholing analysts and suggests rotating them through threat intelligence, content development and incident handling, which also helps retention. Team design and tiering are covered in the SOC Guide; career paths for analysts are in the SOC Analyst Career Guide.

Log source priorities

NCSC names three must-have log sources as quick wins before any systematic review: authentication logs, which give big red flags when attackers try to gain unauthorised access; security control logs from anti-malware, firewalls and access control changes; and DNS logs, which can reveal a device requesting a known-bad domain. After those, it recommends using threat modelling to select further application, host, network and cloud sources.

Microsoft Learn's event 4769 reference recommends monitoring for ticket encryption types other than 0x11 and 0x12 (the AES types); an RC4 (0x17) ticket requested for a service account is a classic Kerberoasting indicator. Retention and storage tiers are covered in the Log Management and Retention Guide, and the cloud control plane sources in the Cloud Logging and Audit Trail Guide.

Using threat modelling to choose the next sources

NCSC's threat modelling approach for log onboarding runs in six stages: map the components and data flows, identify the risks (using CIA or STRIDE), the likely actors, how each attack would happen (using ATT&CK techniques), the log sources that would reveal it, and the detections to build. Run it first for the top ten critical systems and repeat when systems or threats change.

Where identity fits

Most intrusions a new SOC will see involve an identity: a phished user, a stolen session token, or a service account whose credentials leaked. Service accounts, service principals and API keys deserve specific attention because they are often excluded from monitoring as "noisy system activity" when they are actually the easiest accounts to baseline. A service principal that signs in from one application, on a schedule, to one resource, should alert the moment it signs in from anywhere else.

The Okta support system breach of 2023 shows the cost of not watching non-human accounts: an attacker used a support service account whose credentials had been saved in an employee's personal browser profile, and customers detected the activity before the provider did. Build an inventory of service accounts early and feed it to the SIEM as a watchlist; see the Service Account Security Guide and the ITDR Guide.

Technology: the minimum viable stack

• SIEM or security data lake: central collection, search and correlation. Size licensing on the wave 1 and 2 sources above, not on "everything". See the SIEM Guide.
• EDR on all endpoints and servers: the highest-value telemetry and the main containment tool. See the EDR Guide.
• Case management: a ticketing or case system with dispositions, evidence and timelines; often part of the SIEM or SOAR.
• Automation: start with enrichment and notification, not automated containment. See the SOAR and Security Automation Guide.
• Secure the SOC itself: NCSC recommends segregating SOC data from the wider estate in a separate security domain, applying least privilege and auditing SOC actions. SOC administrator accounts are prime targets and should use phishing-resistant MFA from separate admin identities.

Choose tools by asking which detections and investigations they enable against your threat model, and whether your team can operate them. A powerful platform without an engineer to run it produces noise, not detection.

Processes and first detections

NIST SP 800-61 Rev. 3, published in April 2025, recasts incident response as a CSF 2.0 Community Profile, which makes it a good frame for a new SOC: preparation sits under Govern, Identify and Protect, and detection, response and recovery under Detect, Respond and Recover. The minimum process set for go-live is:

1. Incident response plan with severity levels, roles and escalation. Start from the Incident Response Plan Template.
2. Triage procedure with consistent dispositions. See the Alert Triage Guide.
3. Runbooks for the five to ten most likely scenarios: phishing, compromised user account, compromised service account or key, malware on endpoint, ransomware precursor, suspicious cloud admin activity. Use the SOC Runbook Template. NCSC warns that runbooks speed triage but can limit real investigation if followed mechanically.
4. Detection lifecycle: request, build, test, deploy, tune and review, with rules in version control. See the Detection Engineering Guide.
5. Log source health monitoring: alert when a priority source stops sending, because silence looks like safety.

NCSC describes four detection approaches: commercial tool detections, custom use-cases, data mining and threat hunting, in rising order of staff investment. A first SOC should switch on and tune vendor detections first, then write custom use-cases for gaps the threat model exposes, such as new privileged role assignments, MFA method changes, service principal credential additions and mass downloads from SharePoint or file servers. Keep alert volume low enough that every alert gets a proper look; the Alert Fatigue Reduction Guide covers tuning.

The first-year roadmap

Pilot each new source and detection before relying on it: run new rules in audit mode against a week of data, and confirm parsing with known test events before declaring a source onboarded. For rollback, keep a provider contract or internal fallback able to cover monitoring if an in-house function stalls, and keep detection rules versioned so a bad change can be reverted. The SOC Maturity Model gives the yardstick for the Q4 self-assessment.

Decision guidance by organisation size

• Small (a security team of one to three): buy 24/7 monitoring through MDR, keep incident management and the charter in-house, and spend internal time on log onboarding and identity hygiene.
• Mid-sized: hybrid with an in-house business-hours team; build custom detections in-house because they need business context.
• Large or highly regulated: plan for in-house 24/7 within two to three years, with specialist functions such as forensics or malware reverse engineering on retainer.

Measuring the new SOC

MITRE's tenth strategy is to measure performance to improve performance. Pick metrics that show progress against the roadmap and avoid vanity counts of alerts handled:

• Priority source coverage: share of wave 1 and 2 sources onboarded and healthy.
• Critical asset coverage: share of the top ten systems with logging and at least one tested detection.
• ATT&CK coverage: techniques relevant to your threat model with a tested detection.
• Mean time to triage and to contain for high-severity incidents.
• True positive rate per detection, to drive tuning.
• Exercise findings closed within the agreed period.

Definitions and reporting are in the Security Operations Metrics Guide.

Common failure patterns

• Tool first, mission later: a SIEM is bought and filled with every log available, the bill grows and nobody can say what it detects.
• No authority: the SOC finds a compromised account at midnight and cannot disable it without a business owner who is asleep.
• Excluding service accounts as noise: non-human identities are filtered out of identity monitoring, which is where attackers then operate, as the Okta support system breach illustrates.
• Silent log loss: a priority source stops sending after a firewall change and nobody notices for months.
• Provider as black box: the MDR provider escalates by email to a shared mailbox, and nobody owns the response.
• Single-person dependency: one engineer knows the SIEM; when they leave, detection content stops changing.

Framework mapping

Practitioner checklist

• Get a SOC charter signed that states scope, services, authorities, hours and data handling.
• List the ten systems whose compromise would hurt most and scope monitoring to them first.
• Choose an operating model; for most first SOCs, hybrid with defined provider handoffs.
• Onboard authentication, security control and DNS logs first, including service principal sign-ins and domain controller events.
• Build a service account and workload identity watchlist for the SIEM.
• Monitor log source health and alert on silence.
• Approve an incident response plan and runbooks for the top scenarios, then exercise them.
• Keep detection rules in version control and test them before and after changes.
• Report coverage and triage metrics to the sponsor quarterly and run a maturity self-assessment at year end.

Standards and references

• NCSC: Building a Security Operations Centre (SOC)
• NCSC: Building a SOC, Log sources
• MITRE: 11 Strategies of a World-Class Cybersecurity Operations Center
• NIST: SP 800-61 Rev. 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management
• NIST: Cybersecurity Framework 2.0
• NIST: SP 800-53 Rev. 5
• Microsoft Learn: Sign-in logs in Microsoft Entra ID
• Microsoft Learn: 4769(S, F) A Kerberos service ticket was requested

Related NHI Mgmt Group resources: SOC Guide · SOC Staffing and Shift Models Guide · Top 10 SOC Challenges · AI SOC Guide · SOC Maturity Model