What is a Security Operations Centre?
A security operations centre (SOC) is the centralised team and technology function responsible for continuously monitoring, detecting, investigating, and responding to cybersecurity threats across an organisation's entire environment. It is the nervous system of a mature security programme: always active, processing signals from dozens of data sources, and escalating the subset of events that warrant human investigation or an automated response.
In practice, a SOC combines three elements: people (analysts, threat hunters, incident responders), processes (playbooks, escalation paths, communication protocols), and technology (SIEM, SOAR, endpoint detection, threat intelligence feeds). Remove any one of those three elements and the SOC degrades into either an alert-noise machine nobody trusts, or a team without the tools to act at speed.
The SOC concept originated in military signals intelligence and was adapted by the financial services and telecoms sectors in the late 1990s as internet-facing infrastructure became a primary attack surface. Traditional SOCs were built to protect enterprise networks: Windows workstations, Active Directory, perimeter firewalls, and corporate email. The model is mature, well-documented, and supported by a deep ecosystem of vendors and managed service providers.
Crypto firms inherit all of those risks. They also carry an entirely distinct set of risks that the traditional SOC model was never designed to address. Building a Web3-ready security operations centre requires understanding both layers.
Why Crypto Firms Need a SOC
The case for a SOC at a crypto firm rests on four structural realities that distinguish this sector from most other industries.
Irreversibility. When an attacker exfiltrates data from an enterprise network, the organisation has time to revoke credentials, patch systems, notify regulators, and contain the damage before financial harm is fully realised. In crypto, the transaction that moves funds out of a compromised wallet is final the moment it confirms on-chain. There is no chargeback mechanism, no fraud department to call, and no 72-hour window to freeze an account. The only way to prevent a loss is to detect and respond before the transaction is broadcast, or within the seconds before it confirms.
24/7 operations. Blockchain networks do not close at weekends. Attackers know this and deliberately execute exploits outside business hours when security teams are at minimum staffing. The Ronin Network hack in March 2022, which resulted in a loss of approximately $625 million, went undetected for six days. The Bybit exploit in February 2025, the largest single crypto theft on record at over $1.4 billion, was only discovered after the fact, when the anomalous outflows had already been completed. A SOC operating with 24/7 on-chain monitoring coverage would have flagged both events within minutes of the first anomalous transaction.
Exchange listing due diligence. Tier-1 centralised exchanges increasingly require evidence of security maturity as part of listing due diligence. Demonstrating a functioning SOC with documented processes, defined incident response times, and on-chain monitoring capability is a concrete differentiator when pursuing listings on major venues.
Regulatory pressure. The Digital Operational Resilience Act (DORA) requires financial entities, including crypto-asset service providers operating under MiCA, to implement continuous monitoring and detection capabilities. DORA Article 17 specifically mandates that firms have the ability to detect anomalous activities promptly. A SOC is the operational mechanism through which that requirement is met. For more on the DORA requirements applicable to crypto firms, see our guide to DORA compliance for crypto firms.
"Both the Bybit and Ronin hacks were detected only after the fact. An active SOC with on-chain alerting would have caught the anomalous transaction patterns within minutes of the first movement."
How a Crypto SOC Differs from a Traditional SOC
The fundamental SOC workflow, collect telemetry, correlate events, triage alerts, investigate, respond, is identical for crypto and traditional environments. The difference lies in the data sources and the domain knowledge required to interpret them.
A traditional enterprise SOC analyst understands Windows event log IDs, Active Directory lateral movement patterns, and common malware beaconing behaviour. A crypto SOC analyst needs all of that, plus the ability to read a smart contract event log, interpret an unusual sequence of on-chain function calls, recognise suspicious mempool activity around a liquidity pool, and understand the significance of a validator key access event.
The specific additions a crypto SOC must build into its monitoring programme include:
- On-chain event monitoring: Watching for anomalous smart contract interactions, large unexpected transfers, and admin function calls on key contracts.
- Mempool surveillance: Detecting front-running attempts, sandwich attacks, and unusually large pending transactions before they confirm.
- Cross-chain bridge transaction watching: Bridges represent concentrated value and have been the target of some of the largest hacks in the sector. Monitoring bridge inflows and outflows for anomalies is essential.
- Validator and node alert management: For proof-of-stake networks, monitoring validator key activity, uptime, and slashing events.
- Exchange API anomaly detection: Flagging unusual API call patterns that may indicate compromised API keys or automated malicious trading behaviour.
These requirements are additive. A crypto firm does not get to skip traditional security monitoring because it has on-chain monitoring. Attackers targeting crypto firms frequently compromise employee endpoints, escalate privileges through corporate infrastructure, and only then reach the wallet management systems or signing keys. Monitoring one layer while neglecting the other is not a security programme; it is a partial view that an attacker will exploit.
The Lazarus Group's approach to crypto firm targeting is instructive here: their intrusions typically begin with spear-phishing against employees, progress through internal network compromise, and only reach the cryptocurrency infrastructure after weeks of dwell time. A SOC monitoring only on-chain activity would see nothing until the final theft.
SOC Tiers and Functions
Most mature SOC models organise analysts into three tiers, each with a distinct role and a defined escalation path.
Tier 1: Alert Triage. Tier 1 analysts are the first line of response. Their primary function is to monitor the alert queue, apply initial triage logic, close obvious false positives, and escalate confirmed or suspected incidents to Tier 2. In a crypto context, Tier 1 analysts must be able to distinguish a routine large withdrawal from an anomalous one, and understand the difference between a normal smart contract upgrade event and an unexpected admin privilege change. The volume of on-chain data makes good triage logic, automated where possible, essential to prevent analyst burnout at this tier.
Tier 2: Investigation. Tier 2 analysts pick up escalated alerts and conduct deeper investigation. They correlate on-chain events with off-chain telemetry (endpoint activity, identity logs, network traffic), determine whether an incident is confirmed, establish its scope, and begin containment actions. In a crypto firm, containment may include initiating a wallet freeze, revoking API keys, escalating to the multisig governance process to pause a smart contract, or initiating the formal incident response plan. For more on building that plan, see our guide to incident response planning for crypto firms.
Tier 3: Threat Hunting and Forensics. Tier 3 represents the most senior function in the SOC. These analysts do not wait for alerts; they proactively hunt for indicators of compromise that automated detection has missed, conduct deep forensic analysis following an incident, produce threat intelligence, and tune detection rules to reduce false positives. In a Web3 context, Tier 3 work includes analysing on-chain address clusters to identify attacker infrastructure, reverse-engineering malicious smart contracts, and producing post-incident reports that drive governance improvements.
Smaller crypto firms, typically those with fewer than 100 staff, rarely have the internal resource to staff all three tiers in-house. The managed SOC model, discussed below, addresses this directly.
Data Sources and Tooling
A crypto SOC aggregates telemetry from a wider range of sources than a traditional enterprise SOC. The following categories are the minimum required for meaningful coverage.
On-Chain Analytics Feeds
Tools such as Chainalysis, Elliptic, and Forta provide real-time alerts on suspicious on-chain activity: interactions with sanctioned addresses, large anomalous outflows, bot activity on contracts, and known attacker address interactions. Forta, in particular, allows teams to deploy custom detection bots that fire alerts when specific smart contract conditions are met, functioning as a form of on-chain SIEM rule.
Node and RPC Endpoint Logs
Internal and third-party node logs provide visibility into who is querying the blockchain and with what frequency. Anomalous RPC call patterns can indicate reconnaissance or scripted attack activity.
SIEM
A security information and event management (SIEM) platform aggregates logs from across the traditional IT environment: endpoints, identity providers, cloud infrastructure, and network devices. Leading platforms include Splunk, Elastic Security, and Microsoft Sentinel. The SIEM is the correlation engine: it applies detection rules, identifies patterns across data sources, and generates the alert queue that analysts work from.
SOAR
A security orchestration, automation, and response (SOAR) platform automates repeatable response actions, freeing analysts from manual tasks. In a crypto context, SOAR playbooks might automatically revoke a compromised API key when a specific alert fires, or page the on-call incident commander when an on-chain alert above a defined threshold triggers.
Endpoint Detection and Response (EDR)
EDR tools monitor endpoints for malicious behaviour, providing visibility into the employee workstation and server layer. Given that most successful crypto heists begin with endpoint compromise, EDR coverage across all staff devices is non-negotiable. This is particularly important for staff who handle privileged access, such as wallet signers and admin key holders. See our coverage of privileged access management in crypto for the broader context.
Identity and Access Logs
Authentication logs, identity provider event streams, and access management system records provide the audit trail needed to detect credential-based attacks, insider threats, and privilege escalation.
Build vs Outsource
The decision to build an in-house SOC, outsource to a managed security service provider (MSSP), or operate a hybrid model depends on three variables: budget, internal talent availability, and the firm's risk profile.
In-house SOC. A fully in-house SOC with genuine 24/7 coverage requires a minimum of six to eight analysts (to cover shifts and avoid burnout), plus senior staff for Tier 2 and Tier 3 functions, a SOC manager, and a technology stack. The annual cost for a well-staffed in-house SOC in London or New York typically exceeds £1.5 million when salaries, tooling licences, and infrastructure are included. This is realistic for a large exchange or a well-capitalised DeFi protocol, but not for most firms in the 20 to 100 staff range.
Managed SOC (MSSP). A managed detection and response (MDR) provider or MSSP with documented Web3 experience offers 24/7 analyst coverage, a proven technology stack, and established playbooks for a monthly retainer that is typically a fraction of in-house costs. The trade-off is less control over detection logic and a reliance on the provider's knowledge of your specific environment. Vetting the provider's blockchain literacy before engagement is critical.
Hybrid model. The most practical option for most crypto firms in the 50 to 200 staff range is a hybrid: one or two in-house security leads who own the security programme, manage tooling, write detection rules specific to the firm's smart contract architecture, and act as the internal escalation point, supported by an MDR provider handling the 24/7 monitoring and alert triage. This approach combines domain-specific knowledge with continuous coverage without the cost of a full in-house team.
Key Metrics
A SOC that cannot measure its performance cannot improve it. The four standard SOC metrics apply directly to crypto environments, with additional crypto-specific additions.
Mean Time to Detect (MTTD) measures the average time between an attacker achieving initial access or executing a malicious action and the SOC generating a corresponding alert. For on-chain attacks, where funds can be moved and laundered within minutes, the target MTTD should be measured in seconds to minutes, not hours. The Bybit case illustrates the cost of a high MTTD precisely: by the time the anomalous outflows were identified, the entire loss had already occurred.
Mean Time to Respond (MTTR) measures the average time between an alert being raised and a meaningful containment action being taken. In a crypto context, a containment action might be pausing a smart contract, revoking API keys, or freezing a hot wallet. MTTR is directly constrained by the quality of playbooks, the authority granted to SOC analysts to act without waiting for approval chains, and the availability of automated response tooling.
False Positive Rate is the proportion of alerts that, upon investigation, turn out to be benign. A high false positive rate degrades analyst performance by creating alert fatigue, causing genuine threats to be missed in the noise. On-chain monitoring tools tend to generate significant alert volume, making false positive management a material concern for crypto SOCs.
Alert Volume is a leading indicator of SIEM and on-chain monitoring rule quality. Unsustainable alert volume (commonly defined as more alerts than the team can triage within a shift) indicates that detection rules need tuning.
On-Chain Anomaly Detection Latency is the crypto-specific addition: the time between an anomalous on-chain event occurring and an alert being raised in the SOC. This metric is distinct from MTTD because it isolates the performance of the on-chain monitoring layer specifically.
Regulatory Requirements
Two regulatory frameworks directly mandate continuous monitoring and detection capabilities for crypto firms operating in or serving clients in the European Union.
DORA (Regulation EU 2022/2554), which applies to financial entities including crypto-asset service providers under MiCA, mandates under Article 17 that firms implement mechanisms to promptly detect anomalous activities. Article 18 requires that ICT-related incidents are identified, classified, and logged. Article 19 establishes reporting timelines that presuppose a functioning detection capability: you cannot report an incident within the required timeframes if you lack the tooling to detect it promptly in the first place. Our detailed guide to DORA compliance for Web3 firms covers these requirements in full.
MiCA (Regulation EU 2023/1114) does not prescribe specific SOC requirements but requires crypto-asset service providers to maintain operational resilience and implement robust internal control mechanisms. A SOC is the primary operational control through which continuous monitoring, incident detection, and response capability are delivered. For firms pursuing a MiCA licence, a documented SOC capability strengthens the operational resilience section of the application. See our guide to MiCA compliance for the broader regulatory context.
Beyond European regulation, firms pursuing a SOC 2 Type II attestation, which is increasingly required by institutional counterparties, must demonstrate continuous monitoring of their security controls. A functioning SOC is the operational foundation for SOC 2 compliance in the security and availability trust service categories.
Firms that have not yet formalised their vulnerability management programme should address that alongside SOC implementation, as the two are complementary. Our guide to vulnerability management for Web3 covers the asset inventory and patch management processes that feed into SOC detection logic.
Frequently Asked Questions
What is a security operations centre?
A security operations centre (SOC) is a centralised team and technology function responsible for continuously monitoring, detecting, and responding to security threats. It combines people, processes, and tooling to provide around-the-clock visibility into an organisation's security posture, covering both traditional IT infrastructure and, for crypto firms, on-chain activity.
Why do crypto firms need a dedicated SOC?
Crypto firms operate 24/7 with irreversible on-chain transactions, meaning a delayed response to a breach can result in permanent and unrecoverable loss of funds. A SOC provides continuous monitoring of both on-chain activity and traditional IT infrastructure, enabling rapid detection and containment before losses escalate. The Bybit and Ronin hacks both demonstrate the cost of operating without this capability.
How does a crypto SOC differ from a traditional enterprise SOC?
A crypto SOC must monitor on-chain events, smart contract interactions, mempool activity, bridge transactions, and validator alerts in addition to traditional SIEM data sources such as endpoint telemetry, identity logs, and network traffic. It requires analysts with blockchain literacy and tooling such as Chainalysis, Elliptic, or Forta that traditional SOCs do not use.
Should a crypto firm build or outsource its SOC?
Firms with fewer than 50 staff typically lack the resources to operate a fully in-house SOC cost-effectively. A managed SOC (MSSP) with Web3 expertise, or a hybrid model combining an in-house security lead with a managed detection and response provider, is usually the most practical option for firms in the 20 to 100 staff range.
What metrics should a crypto SOC track?
The four core SOC metrics are mean time to detect (MTTD), mean time to respond (MTTR), false positive rate, and total alert volume. For crypto-specific operations, firms should also track on-chain anomaly detection latency and the number of high-severity smart contract events escalated per reporting period.