Practical cybersecurity from Northern Ireland
LinkedInYouTubeInstagram
NI Cyber Guy logo
NI CYBER GUYSecurity without the jargon
⚠ Flagged for a content rewrite before launch — Consolidated from 2 Tier 4 source pages (the-essential-role-of-a-soc-manager, the-ultimate-guide-to-becoming-a-successful-soc-analyst). Draws on sanitised TSM day-job experience per founder-profile.md rules — no employer name or identifying detail. Colin should review before publishing to confirm nothing crosses the sanitisation line.
Careers31 July 2026

Running Security as a One-Person Team: What the SOC Manager Guides Don't Tell You

Most articles about SOC managers assume you’re walking into an established team — analysts on shifts, an existing SIEM, a defined escalation path. Nobody writes the version where you are the security function: one person, a backlog of everything from identity to incident response, and roughly 60% of your week actually available for hands-on delivery once the meetings are accounted for.

That’s been my reality running security for a small organisation. It’s not the career-guide version of the job, and it teaches you things the big-team version doesn’t.

You don’t get to specialise — and that’s the useful part

In a large SOC, you can spend years going deep on one thing: detection engineering, threat intel, identity, whatever. As a team of one, every domain lands on your desk. Identity and access, endpoint hardening, SIEM implementation, ISO 27001 evidence gathering, incident response — it’s all yours, whether or not it’s your strongest area.

The upside nobody mentions: you end up with a genuinely practical, end-to-end view of how security actually fits together in a real organisation, instead of a narrow, deep view of one slice of it. When you’ve had to implement the SIEM yourself, you understand its limitations in a way someone who only ever used one someone else built never quite does.

The real skill is prioritisation, not tooling

The tools matter less than people assume. What matters more: knowing what genuinely needs doing this week versus what can wait, and being honest with yourself and your manager about the difference. With a fixed, small amount of real delivery time, saying yes to everything means finishing nothing properly.

That’s a harder skill than any certification teaches. It’s also the one that determines whether a one-person security function actually reduces risk or just produces the appearance of coverage.

Compliance work is not separate from “real” security work

A lot of career content treats governance and compliance (ISO 27001, audits, evidence collection) as the boring cousin of “real” technical security work like SIEM tuning or incident response. In practice, when you’re the one holding both, you stop seeing them as separate. The compliance framework is the thing that forces the technical work to actually get documented and repeatable, instead of living only in your head. Treating them as connected, not competing priorities, is one of the more useful mindset shifts from doing this role for real.

Metrics still matter, even alone

Even without a team to manage, tracking the same metrics a bigger SOC would care about — mean time to detect (MTTD) and mean time to respond (MTTR) — is worth doing. Not for a dashboard nobody looks at, but because they’re the clearest honest signal of whether the SIEM tuning and detection work you’re doing is actually improving anything, versus just generating more alerts to triage. When MTTD creeps up, that’s usually a sign detection coverage has a gap, not that you’re personally working slower — and that distinction changes what you fix.

Incident response as a team of one follows the same broad shape it would with a full SOC — detect, contain, eradicate, recover, review — but every stage is compressed onto one person’s judgement instead of being split across specialists. That’s higher pressure in the moment, but it also means there’s no handoff friction between the person who spotted the alert and the person deciding what to do about it. Automation earns its keep here more than almost anywhere else: anything that can be automated (initial triage rules, enrichment, routine containment steps) directly gives back hours that a bigger team would spread across multiple people.

SOC manager vs SOC analyst vs CISO — where the lines actually sit

These titles get used loosely, so it’s worth being precise. A SOC analyst is typically focused on the operational, hands-on work — monitoring, triage, initial response. A SOC manager owns the function as a whole: prioritisation, tooling decisions, reporting upward, and (in a bigger team) people management. A CISO sits above both, owning strategic risk decisions and answering to the board or senior leadership, usually with far less hands-on technical involvement day to day. In a one-person function, you’re doing all three jobs simultaneously, which is exactly why the prioritisation skill matters more here than in any single one of those roles individually.

If you’re weighing up becoming a SOC manager as a career step, the honest advice is: the technical skills that get you noticed as an analyst are necessary but not sufficient. What actually makes the jump work is the same stakeholder communication and prioritisation judgement this whole piece keeps coming back to — because the moment you’re accountable for the whole function, technical correctness stops being enough on its own.

What this role actually asks of you

  • Comfort with ambiguity. Nobody hands you a fully scoped SOC playbook. You build the playbook while also running the SOC.
  • Enough breadth to know what you don’t know. You can’t be deep everywhere — the skill is recognising which gaps are risky enough to need external help or upskilling, and which can wait.
  • Stakeholder communication that doesn’t assume technical literacy. Explaining risk and priority to people without a security background, clearly and without fear-mongering, is a daily requirement, not an occasional presentation skill.

Training yourself when there’s no one else to learn from

One thing nobody warns you about: in a full SOC, junior analysts learn partly by osmosis — sitting near people who’ve handled more incidents, picking up judgement calls informally. As a team of one, that mentorship structure doesn’t exist internally. You have to build it deliberately instead: external communities, vendor documentation, post-incident reviews you write for yourself even when no one else will read them, and treating every real incident as a forced training exercise since there’s no one else to hand the harder cases to.

Policy work benefits from the same discipline. It’s tempting, with limited time, to treat policy as a compliance checkbox — write it once, file it away. In practice, policies that were written under time pressure and never revisited tend to drift out of sync with what the organisation actually does, which becomes a liability the moment an auditor or an incident tests them. Building a habit of reviewing policy against reality on a fixed schedule, even a rough one, closes that gap before it becomes a problem during an audit or, worse, during an actual incident.

Final Thoughts

If you’re considering a security role at a smaller organisation where you’d be the whole function rather than joining an established team, don’t read it as a lesser version of the “real” SOC manager job. It’s a different, harder, and honestly more instructive one. Got questions? ping me on LinkedIn.