A small team should spend its first 90 days on four things: knowing what to watch, collecting the logs that matter, writing a handful of detections and rehearsing response. Month one is inventory and logging. Month two is detection and triage. Month three is response practice and measurement.
A SOC, security operations center, is the function that watches for threats and handles incidents. It may be one person with a rota and a shared inbox. Size matters less than rhythm and clear ownership. Safeguard focuses on the application and software supply chain side and does not replace SOC tooling or services, so this plan is vendor neutral.
What is the aim?
NIST's guidance on incident response, SP 800-61 Revision 3, places incident response inside a wider cybersecurity risk process, and NIST SP 800-53 control SI-4 asks organizations to monitor systems to detect attacks and indicators of potential attacks against objectives they define. So start with objectives: which three bad outcomes matter most? Examples: ransomware on file servers, theft of customer data, takeover of an administrator account. Everything in the plan serves those three.
Days 1 to 30: see what you have
Week 1: objectives and owners. Write the three outcomes. Name an incident lead and a backup. Agree how people reach you, and what hours you cover.
Week 2: inventory. List critical systems, identity providers, cloud accounts, endpoints and public services. An incomplete list is fine if you mark the gaps.
Weeks 3 and 4: collect logs. For each outcome, list the logs that would show it. Typical starting points: identity provider sign ins, cloud audit logs, endpoint alerts, email security events and key server logs. Switch on what exists before buying more. Check retention and time sync. Write down what you cannot see.
Deliverable at day 30: one page with objectives, asset list, log sources, gaps and owners.
Days 31 to 60: detect and triage
Week 5: pick detections. For each outcome, write two or three detections. Use MITRE ATT&CK, a knowledge base of adversary tactics and techniques, to find techniques relevant to your outcomes. Fewer, well understood detections beat hundreds of copied rules.
Week 6: triage rules. Write a short triage guide: what to check first, how to rank, when to escalate. Include a template for notes.
Weeks 7 and 8: tune. Review every alert. Label each real, harmless or unclear. Retire or fix noisy rules. Record changes with the reason.
Deliverable at day 60: a small set of tested detections, a triage guide and a log of tuning decisions.
Days 61 to 90: respond and measure
Week 9: response basics. Write one page per outcome: containment steps, who approves them, how to preserve evidence and who to inform. Agree which actions need approval, such as isolating a server.
Week 10: rehearse. Run a constructed scenario, for example a suspicious sign in for an administrator account. Time each step and find what blocks you.
Week 11: threat information. Subscribe to a few sources for the products you run, including CISA's Known Exploited Vulnerabilities catalog. Decide who reads them and what happens when a flaw affects you. NIST SP 800-150 describes how to take part in sharing relationships.
Week 12: measure and report. Pick a few numbers: log coverage of critical systems, alerts reviewed within target, time to contain in the rehearsal. Report them with the gaps and next quarter's plan.
What should you avoid?
- Buying a platform first. Tools help once you know your outcomes and log sources.
- Copying every rule. More rules mean more noise and more tuning.
- Skipping the rota. Detection without someone reading alerts is a logging exercise.
- Forgetting people. Name who is on call, and how they rest. Small teams burn out.
What about the software you build?
Add one item to week 2 and week 11: an inventory of the applications you ship, with their dependencies, and a way to learn when a dependency has a known exploited flaw. Runtime monitoring will not tell you which library to upgrade.
What to do
- Choose three outcomes that matter most and name an incident lead.
- Inventory critical systems and mark visibility gaps.
- Switch on the logs you already have, and check retention.
- Write two or three detections per outcome and tune weekly.
- Write response pages and agree who approves strong actions.
- Rehearse once, measure, and report the gaps.
Quick check
Do we need a SIEM on day one?
No. Start by collecting and reading the logs you already have for your three outcomes. Add a platform when volume or search needs outgrow what you do now.
Is 24 hour coverage required from the start?
Not necessarily. State your coverage hours honestly, plan how out of hours alerts reach someone, and decide whether a service is needed to cover the rest.
Sources
- NIST SP 800-61 Revision 3
- NIST SP 800-53 control SI-4, system monitoring
- NIST SP 800-150, cyber threat information sharing
- MITRE ATT&CK
- CISA Known Exploited Vulnerabilities catalog
Last reviewed: 18 October 2026.
