SOC, SIEM and SOAR explained: how they fit, and in-house vs managed SOC

What is a SOC?

A SOC is the function that monitors an organisation's networks, systems and applications for security events, decides which are real incidents, and leads the response. It is people and procedures first. The tools support them.

NIST SP 800-215 describes handling security alerts and threat intelligence feeds as part of the incident response process carried out by SOC members. A SOC usually triages alerts, investigates the ones that matter, contains incidents with the IT team, and reports to management and, where the law requires, to CERT-In. A SOC that runs around the clock needs enough trained analysts to cover every shift, holidays and leave. That staffing, not the software, is usually the largest cost.

What does a SIEM do?

A SIEM collects logs from many systems into one place, puts them into a common format and looks for patterns that point to an attack. NIST SP 800-92, the Guide to Computer Security Log Management, describes SIEM products as having log servers that analyse logs and database servers that store them.

NIST SP 800-92 describes two ways a SIEM collects logs. Agentless collection pulls or receives logs over the network without installing software on the source. Agent-based collection installs a small program on the source that filters and normalises logs before sending them. NIST notes SIEMs support many source types, including operating systems, security software, application servers and physical security devices such as badge readers. That last point matters for campuses and public buildings, where access-control and camera systems are log sources too.

The value is in correlation. One failed login means little. Failed logins across many accounts from one address, followed by a success and a large data transfer, is an incident. NIST SP 800-61 Revision 3 recommends using SIEM and SOAR tools to monitor log events continuously and to correlate related data from multiple sources.

What does SOAR add?

SOAR automates the repeatable steps of a response, so analysts spend time on judgment rather than copying data between tools. NIST SP 800-215 describes SOAR as a security strategy to automate the incident response process, with uses in threat detection and response, vulnerability prioritisation, compliance checks and security audits.

A SOAR platform runs playbooks: sequences of steps triggered by an alert. A playbook can look up an address in threat intelligence, pull the related logs, ask the firewall to block the address, disable a user account and open a case with the evidence attached. High-impact steps, such as isolating a server that runs a hospital system, should wait for a person to approve them. SOAR only works as well as its integrations, so every tool it must control needs a supported interface.

How do SOC, SIEM and SOAR fit together?

The SIEM finds and correlates events, SOAR runs the routine response, and the SOC team decides and acts on the rest. Logs flow from firewalls, servers, endpoints and applications into the SIEM. The SIEM raises alerts. SOAR enriches them and runs playbooks. Analysts investigate what remains and lead containment and recovery.

Should a SOC be in-house or managed?

It depends on whether the organisation can staff every shift and keep skilled analysts. NIST SP 800-61 Revision 3 lists three options for incident handlers: on staff, on contract (for example a SOC outsourced to an MSSP), or available when needed. It notes many organisations combine them, such as handling basic response in-house and bringing in outside help for some incidents.

Two Indian rules shape the contract. CERT-In's FAQ on its 2022 directions says any entity that notices a cyber incident must report it, and that the duty cannot be transferred by contract. So the contract must say who tells whom, and how fast, for the owner to meet the 6-hour deadline. Under the Digital Personal Data Protection Act, 2023, an MSSP that handles personal data in logs is a Data Processor, and section 8(2) requires a valid contract.

How does CERT-In's 180-day log rule affect SIEM sizing?

It sets the minimum retention the SIEM or its log store must hold. The CERT-In directions of 28 April 2022 require all covered entities, including Government organisations, to enable logs of all ICT systems and keep them securely for a rolling 180 days within Indian jurisdiction. For Central Government bodies, CERT-In's Guidelines on Information Security Practices for Government Entities, released on 30 June 2023, also ask for perimeter device and SIEM logs to be kept for a rolling 180 days, with perimeter and endpoint logs integrated into the SIEM.

Storage follows from four numbers: events per second (EPS) at peak and on average, average event size, days of retention, and the compression the product achieves. As a worked example with assumed inputs, not a benchmark, 2,000 EPS at 500 bytes per event is about 86 GB of raw log a day, or about 15.5 TB over 180 days before compression. Many designs keep recent weeks on fast searchable storage and the rest in cheaper archive that can still be restored and produced to CERT-In. Where logs record access to personal data, rule 6 of the DPDP Rules, 2025 asks for such logs to be kept for one year from May 2027, unless another law requires otherwise, so the longer period may apply.

Time matters as much as space. The CERT-In directions require clocks to be synchronised to National Informatics Centre (NIC) or National Physical Laboratory (NPL) time, and correlation across sources fails without it.

What should a SOC or SIEM tender specify?

A tender should specify what must be watched, how long evidence is kept, and how fast people respond, rather than only a licence count.

• An inventory of log sources, with peak and average EPS measured or estimated for each
• Retention: at least 180 days in India, with how much must be searchable online and how much may be archived
• The detection use cases and correlation rules to be delivered at go-live
• SOAR playbooks, with which steps need human approval
• Triage and escalation times that let the owner report to CERT-In within 6 hours
• Network Time Protocol (NTP) synchronisation to NIC or NPL time for every source
• Monthly reporting, and a named contact on both sides
• Exit terms: logs, rules and playbooks handed back in an open format

How Ahuva approaches security operations

Ahuva's cybersecurity scope covers SOC, SIEM and SOAR, alongside network, endpoint and application security, NGFW, IDS/IPS, WAF and zero-trust, and VAPT and compliance. Ahuva entered cybersecurity in 2025. It holds ISO 27001:2022 for information security management and ISO 20000-1:2018 for service management.