Small SOC Operations: Running Detection With Two to Five Analysts

A security operations team of two to five analysts cannot run the detection programme of a large SOC at a smaller scale, because every hour spent on a noisy rule or a manual enrichment step is an hour nobody spends on the alerts that matter. Small teams succeed by owning a short list of detections, automating repetitive triage, and drawing a clear line with their managed detection and response (MDR) provider. This guide covers how to run that programme week to week: prioritising detections, managing the alert budget, deciding what to automate, splitting work with an MDR or MSSP, and measuring whether it works. It is for SOC leads and CISOs in small security teams, and assumes the coverage model is already chosen. For rota design and sizing, see the SOC Staffing and Shift Models Guide.

Source note: guidance below is summarised from the NCSC, CISA, NIST and MITRE pages listed in the references, as checked in November 2026; operating practices not attributed to them are NHI Mgmt Group recommendations. Confirm against the official text before relying on it.

Key takeaways

• Treat analyst hours as the scarcest resource. Set an alert budget the team can investigate properly and remove or rework rules that spend it without finding anything, as the NCSC advises when it says to be cautiously open to removing alerts with high false positive rates.
• Prioritise detections by your attack paths, not by rule count. Identity compromise, remote access abuse, endpoint execution and data leaving the estate are, in NHI Mgmt Group's view, the paths to cover first; build depth there before breadth anywhere else.
• Automate enrichment and evidence collection first, response second. Automatic lookups and case creation save time on every alert with little risk; automatic containment needs tested, narrow conditions and a named owner.
• Write the MDR split down in a responsibility matrix. The provider's authority to act, the escalation path, and who owns custom detections, tuning and identity-specific alerts must be explicit, or gaps appear at exactly the moment both sides assume the other is acting.
• Protect time for engineering. A small team that only works the queue never tunes, tests or improves; reserve a fixed share of each week for detection engineering and review, and defend it.

What makes a small SOC different

A SOC of two to five analysts is not a scaled-down tiered SOC. There is no separate tier 1 triage function, no dedicated threat intelligence analyst and usually no detection engineer: the same people triage, investigate, tune rules, run incidents and maintain the tools. The NCSC's SOC guidance accepts that a SOC cannot monitor the whole estate at the same depth, that it should focus on its most critical assets and their business context, and that it is fine to start with a lower capability and grow.

Three constraints shape everything else:

• Attention: a few people cannot sustain hundreds of alerts per day. Every rule has to justify the time it consumes.
• Single points of knowledge: if one analyst built the SIEM pipeline, leave or illness removes a capability. Documentation and pairing are operational controls.
• Breadth of tools: EDR, SIEM, email security, identity provider and cloud consoles each have their own alert queue. Consolidating where alerts land matters more than adding sources.

Of the NCSC's detection approaches, commercial tool detections (EDR, email, identity protection) carry most coverage because vendors keep them current. Custom detection use cases are written selectively, where the vendor rules do not see your environment's specific risks. Data mining and continuous hunting need skills and staff a team this size rarely has; time-boxed hunts on the top attack paths are the realistic form.

Prioritising detections: the short list

Start from how an attacker would reach your most important systems and data, then decide which steps you must see. The NCSC recommends threat modelling and attack trees to drive log source and detection decisions, and MITRE ATT&CK to check coverage. In NHI Mgmt Group's experience, the first detections for organisations without a large security team cluster around a handful of techniques. Adapt this starting list:

Rank candidate detections with three questions: how likely is this step in an attack on us, how much damage follows if we miss it, and how much analyst time will the rule cost each week? A detection that is likely, high impact and cheap (for example a new admin role grant) goes first. Noisy, low-impact detections wait. See the Detection Engineering Guide for the rule lifecycle.

Where identity fits

Identity logs give a small team the highest return per rule, in NHI Mgmt Group's view, because valid account abuse (ATT&CK T1078) is a common intrusion step and identity providers already produce rich, structured events. Include non-human identities: new credentials on an application, service principal sign-ins from unfamiliar addresses and dormant automation accounts becoming active are high-value, low-volume detections. See the Entra ID Sign-In and Audit Log Detection Guide and the Leaked Secret Validation Detection guide for specific signals.

Running the alert budget

An alert budget is the number of alerts the team can investigate properly in a working day, after protecting time for other work. Work it out from your own numbers: available analyst hours on queue duty, divided by the median handling time per alert. If two analysts each spend four hours a day on triage and the median alert takes 15 minutes, the budget is about 32 alerts a day. Above budget, alerts get closed uninvestigated, which is worse than having no rule.

The NCSC's tuning advice applies directly: review frequently firing alerts, feed triage findings back into rule logic, bound every allow-list entry by object and time to avoid perpetual exclusions, and do not assume a silent rule is broken; test it with simulated activity. For a small team, add these practices:

• Severity discipline: keep a small "page now" tier (for example confirmed credential compromise, ransomware behaviour, admin role grants out of hours) and send everything else to the working-hours queue.
• One queue: forward EDR, email, identity and cloud alerts into a single case queue so nothing is missed in a console nobody opened that day.
• Weekly noise review: list the five rules with the most alerts and the fewest true positives; for each decide whether to tune, downgrade to a report, or retire.
• Triage notes per rule: the NCSC suggests documenting which logs to check, which systems to examine and who to contact. Short notes let any analyst handle any alert, which removes single points of knowledge.
• Correlation: real attacks usually trip several detections, so group related low-severity alerts on one user or host into one case.

See the Alert Fatigue Reduction Guide and the Alert Triage Guide for deeper triage technique.

What to automate, and in what order

CISA and partner agencies' guidance on SIEM and SOAR implementation describes the value of these platforms as faster threat identification and automated, predefined responses to detected anomalies. For a small team the order of automation matters more than the platform. Automation can live in a SOAR product, SIEM playbooks, native EDR or identity response actions, or scheduled scripts; pick what the team can maintain.

Run every new response action in a reporting mode first: let it record what it would have done for two to four weeks, review every would-be action, then enable it for a pilot group before the whole estate. Keep a documented way to switch each automation off. The automation accounts themselves need least privilege and monitoring, because a SOAR or script account that can disable users or isolate hosts is a privileged non-human identity. See the SOAR and Security Automation Guide and SOAR platform integration security guide.

Splitting work with an MDR or MSSP

Most small teams use a provider for out-of-hours monitoring, endpoint alert triage or both. NIST SP 800-61 Rev. 3 recognises that incident response staff may be in-house, under contract or available when needed, and CSF 2.0 RS.MA-01 expects the incident response plan to be executed in coordination with relevant third parties once an incident is declared. The split works only when it is written down. A responsibility matrix (who is Responsible, Accountable, Consulted, Informed) is the simplest format.

The internal team keeps what needs business context: identity and SaaS detections, data access monitoring, insider risk signals, incident leadership and the decision to accept risk. The provider takes what benefits from scale and constant coverage: endpoint telemetry triage, known malware and commodity intrusion patterns, overnight first response. Treat the provider's accounts as third-party privileged access. See the MDR Guide, the Co-Managed SOC and SOC-as-a-Service Guide and, for evaluation, the MDR Buyer's Guide.

A weekly operating rhythm

A small team needs a fixed cadence so that engineering work is scheduled rather than squeezed in when the queue is quiet. NHI Mgmt Group recommends this pattern for three analysts:

• Daily: a 15-minute queue review (new, stalled and provider-escalated cases) and a log source health check.
• Weekly: the noise review above, one detection change shipped through test and peer review, and a short provider sync covering escalations, disputed closures and exclusion requests.
• Fortnightly: a time-boxed hunt of about half a day on one hypothesis from the priority list, for example service principals with new credentials in the last 30 days.
• Monthly: test a sample of detections with simulated activity, as the NCSC recommends, and review the register for rules past their review date.
• Quarterly: a tabletop exercise with IT operations and the provider, and a review of the responsibility matrix.

Rotate queue duty so each analyst has protected engineering time, written into the rota so it survives busy weeks.

Tooling choices for small teams

Fewer tools, better used, beats a broad stack nobody maintains. The decision is mainly about where detections run and who maintains the content.

• Native detections first: EDR, email security and identity protection features in products you already own often provide strong vendor-maintained detection. Turn them on and route them to the queue before buying more.
• Central log platform when correlation is needed: a SIEM or log platform earns its cost when you need to join identity, endpoint and cloud events, keep logs for investigations beyond product retention, or write custom detections. The joint guidance on SIEM and SOAR from CISA and ASD's ACSC stresses prioritising which logs to ingest so that critical sources are collected and cost stays manageable.
• No-cost options: CISA offers Logging Made Easy, a no-cost log management and protective monitoring capability for organisations with limited resources, originally developed by the UK NCSC. Check the current platform scope on CISA's service page and GitHub repository before planning around it.
• Portable detection content: writing custom rules in a vendor-neutral format such as Sigma and keeping them in version control makes a later change of SIEM or provider less painful. See the Sigma Rules Guide and the Detection as Code Guide.

Small vs larger small teams: with two analysts, lean heavily on the provider and on native detections, keep custom rules to a few dozen high-value identity and data rules, and automate only stages 1 to 3. With five, a part-time detection engineering role, a modest custom rule library and selected reversible containment become realistic.

Rolling out the programme

The sequence below is NHI Mgmt Group's recommended rollout.

1. Inventory alert sources and current volume: list every console that generates alerts, its daily volume and who looks at it today.
2. Agree the priority short list: map your top attack paths to the priority areas above and pick 15 to 30 detections to own properly.
3. Consolidate the queue: route alerts into one case system with severity, owner and due time.
4. Write triage notes: one short page per detection on the short list.
5. Agree the MDR responsibility matrix: include authority to act, escalation contacts and the never-isolate list. Test it with a simulated overnight alert.
6. Automate stages 1 to 3: case handling, enrichment and evidence collection.
7. Pilot containment: run one or two reversible actions in reporting mode, then for a pilot group, with a documented off switch. Roll back by disabling the action and reverting any account or host changes logged during the pilot.
8. Start the rhythm: daily, weekly and monthly reviews from the first month, so tuning becomes routine.

Measuring whether it works

Review a few decision-driving measures monthly:

• Alerts per analyst day against budget: sustained excess means tune or outsource more.
• True positive rate per rule: drives the noise review; rules near zero over a quarter are candidates for rework or retirement.
• Time to triage for high severity: from alert creation to an analyst or provider decision, split by business hours and out of hours.
• Coverage of the priority short list: share of priority detections that are enabled, documented and tested within the last 90 days.
• Protected engineering hours delivered: planned versus actual; a falling trend predicts declining detection quality.

Common failure patterns

• Turning on every vendor content pack: hundreds of rules generate more alerts than the team can read, and real incidents are closed in bulk with the noise.
• Assuming the MDR handles identity: many providers focus on endpoint telemetry. Without a written split, suspicious sign-ins and new application credentials sit unread in the identity provider. These alerts need an owner on both sides of the contract.
• Permanent exclusions: an exclusion added to quieten an incident is never removed, and attackers using the same path are invisible. Bound every exclusion by object and expiry.
• No source health monitoring: a forwarding agent breaks after an upgrade and nobody notices for weeks because a silent queue looks like a quiet week.
• Engineering time always deferred: the queue absorbs every hour, tuning stops and volume grows.

Framework mapping

Practitioner checklist

• Calculate a daily alert budget from analyst hours and median handling time, and track volume against it.
• Keep a register of 15 to 30 priority detections, each with an owner, data source, triage note and review date.
• Route every alert source into one case queue and monitor every source for silence.
• Run a weekly noise review of the top five noisiest rules and record the decision for each.
• Automate case handling, enrichment and evidence collection before any containment.
• Pilot each containment action in reporting mode, then a pilot group, with a documented off switch.
• Sign a written responsibility matrix with the MDR or MSSP, including authority to act and a never-isolate list.
• Bound every exclusion by object and expiry date and review them monthly.
• Protect engineering time in the rota and report planned versus delivered hours.

Standards and references

• NCSC: Building a Security Operations Centre (SOC)
• NCSC: Detection practices
• NIST: SP 800-61 Rev. 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management
• CISA: Guidance for SIEM and SOAR Implementation
• CISA and ASD's ACSC: Best Practices for Event Logging and Threat Detection
• CISA: Logging Made Easy
• MITRE: 11 Strategies of a World-Class Cybersecurity Operations Center
• NIST: Cybersecurity Framework 2.0

Related NHI Mgmt Group resources: Building a SOC from Scratch Guide · SOC Staffing and Shift Models Guide · MDR Guide · Detection Engineering Guide