How many people do you need to run a SOC?

There is no single number. It depends on how many alerts you receive, how well your rules are tuned, which hours you need covered and how much of the work you hand to outside providers or automation. A small team can run effective security operations if it keeps its scope narrow, keeps its rules quiet and gets help for the hours and skills it cannot cover.

Should a small company use an MSSP or MDR?

Often yes, for some of the work. Outside providers are useful for nights, weekends and specialist skills. Keep decisions, business context and rule tuning in-house, so that the people who know the business stay in charge. Before signing, ask what evidence comes with each finding, what the provider may do on your systems without asking, and where your data goes.

What should a small security team monitor first?

Identity, internet-facing systems and the servers that hold your most important data. Those are where attacks usually start and where they do the most harm. Then check that each of those systems is sending the data you need, and keep checking. A silent machine raises no alerts.

Which security tasks are safe to automate?

Tasks that gather information or move work: threat intelligence lookups, adding owner and business context to alerts, creating tickets, sending notifications and grouping related alerts. Be careful with anything that changes systems, such as disabling accounts or blocking addresses. Keep a person’s approval in front of those actions and record who approved each one.

Can an AI analyst help a team of two or three?

Yes, as a first look. It can investigate alerts as they arrive and leave verdicts with evidence for people to review, so the team spends less time gathering context and more on decisions. It still needs good data, business context and people who review and correct it. Measure how often reviewers agree with its verdicts before relying on it.

Running security operations with a small team

How a small team can run security operations

A small security team runs operations well by choosing a narrow scope and doing it properly: watch the systems that matter most, collect the data those systems need, keep the rules quiet enough that each alert gets read, and write down how the work is done. Trying to watch everything equally with two to five people usually means watching nothing well.

Small teams also carry more than monitoring. The same people often handle vulnerability management, access reviews, supplier questionnaires and audits. Security operations has to fit around that, which is why the choices below are mostly about what not to do.

Start by writing down what the team is responsible for and what it is not. That page will save arguments later and makes it clear where outside help is needed.

What to monitor first

Begin with the systems whose compromise would hurt most and the routes attackers use most often to reach them. For most organisations that means identity, internet-facing systems and the servers that hold important data. List them, name an owner for each and write down what each one does for the business.

Then check that each of those systems is sending the data you need. A machine you mean to watch but that sends nothing is the most dangerous gap a small team can have, because it raises no alerts. Check this regularly, not once.

Identity: sign-ins, failures, new administrator rights and changes to privileged groups
Endpoints on important servers: process events with parent and command line
Internet-facing systems: web servers, VPNs and remote access gateways
Email: phishing reports and suspicious attachments
Cloud administration: changes to access, keys and logging settings
Backups: failures and deletions, because attackers go after them

Which machines are being watchedIllustrated example

web-07 quiet for 2 daysLikely cause: Elastic Agent stopped
pos-12 quiet for 6 hoursLikely cause: No route to Fleet
hr-files quiet for 1 dayLikely cause: Agent removed in an update
build-03 quiet for 3 daysLikely cause: New machine, no agent yet

A machine that stops sending logs raises no alert. armor360 lists the quiet ones with the likely cause, and adds missing Elastic integrations through Fleet once a person confirms.

How to tune noisy rules and set priorities

A small team cannot afford noise. If a rule fires many times a week on the same harmless activity, its alerts will be closed unread and the one real alert will go with them. Make tuning a standing task: each week, take the noisiest rules and decide whether each needs a narrow exception, a change to its logic or a move to a scheduled hunt.

Keep exceptions narrow, recorded and reviewed. Excluding one service account on three named servers is safe. Excluding a whole folder or all administrators is not. Before switching a rule on, check how often it would have fired on past data, so the team knows what it is taking on.

Set priorities by business impact, not only by rule severity. An alert on the server that runs payments matters more than the same alert on a test machine. Writing down which systems matter, once, lets everyone sort the queue the same way.

MSSP, MDR or in-house: which is right

Many small teams use outside help, and the choice is less about whether than about what. An MSSP typically runs and watches security tools for you and passes on alerts. An MDR provider usually goes further, investigating alerts on its own endpoint tooling and often taking agreed response actions. An in-house approach keeps the work and the knowledge inside the organisation.

The trade-offs are context and control. An outside provider gives you people at hours you cannot cover, but knows less about your business and may hand back alerts with little explanation. An in-house team knows the business but has limited hours and limited depth. Many teams mix the two: outside cover for nights and specialist work, in-house ownership of decisions, tuning and business context.

Whoever does the work, ask the same questions before you sign.

Which alerts will they investigate, and which will they pass straight to you?
What evidence comes with each finding?
What can they do on your systems without asking, and who agreed to that?
Where does your alert data go, and who can see it?
How do they learn about your business, and how do you correct them?
What happens to your rules, data and history if you leave?

What automation is safe for a small team

Automation helps a small team most when it gathers information and moves work, not when it changes systems. Looking up an address in threat intelligence, attaching the host’s owner to an alert, opening a ticket, sending an urgent finding to the on-call person and grouping related alerts are all low-risk. If they go wrong, the cost is a wasted minute.

Automated actions on systems are different. Disabling an account, blocking an address or isolating a machine on the wrong evidence can halt the business, and a small team may not notice quickly. If you automate actions at all, keep them few, narrow and tested, with a person approving each one, and record who approved what.

Safe to start with: enrichment, ticket creation, notifications, grouping related alerts, scheduled reports
Needs care: closing alerts automatically, even for known patterns
Needs a person’s approval: anything that changes accounts, networks or machines

How to document the work and avoid burnout

In a small team, knowledge lives in a few heads. When one person is on leave or leaves for good, the team loses more than a pair of hands. Write down the things people would otherwise rediscover: what each important system does and who owns it, why each rule exception exists, how to handle the alert types you see most, and who to call for what.

Burnout is a real risk when a few people carry the queue, the on-call phone and the project work together. Protect people deliberately. Keep the on-call threshold honest so that call-outs are rare and justified. Rotate the dull work. Leave time each week for tuning and improvement, because a team that only fights the queue never makes it smaller. And make it normal to say that the workload is too high, with evidence, before it causes a missed attack.

A simple weekly review helps with both: what came in, what was real, what was noisy, what was changed. Kept for a few months, it is also the clearest case you can make for more help or a different approach.

Where an AI analyst fits in a small team

An AI analyst is most useful to a small team as a first look. It investigates alerts as they arrive, gathers the evidence a person would gather and writes a verdict with its reasons. The team then spends its time reviewing verdicts and deciding, rather than collecting the same context again and again.

It works best with the same foundations described above. It needs the data to be arriving, it needs to be told what the important systems are, and it needs people to review its verdicts and correct it when it is wrong. It does not take the place of the team’s judgement or its knowledge of the business. It gives that judgement more time to work with.

Check the same things you would check with an outside provider: what evidence comes with each verdict, where the data goes, and what the tool can do on your systems without asking.

How armor360 approaches it

armor360 is an AI SOC analyst for in-house security teams, MSSPs and regulated organisations. It takes alerts from Elastic Security, Splunk, Microsoft Sentinel, CrowdStrike Falcon and Microsoft Defender, investigates each with cited evidence and hands a person a verdict to review. Corrections are remembered for later investigations, and the coverage view shows machines that stopped sending logs and the likely cause.

It takes no response actions: it recommends, and people decide and act. It can run fully on your own hardware, the AI included, at about $0.10 of compute per investigation (a running-cost estimate, not a price). Pricing is by quote, with no charge per person.