SOC vs CERT: What’s the Difference?

SOC vs CERT: What’s the Difference?

SOC vs CERT: What's the Difference?

A SOC detects. A CERT, however, responds. This distinction may sound technical, but it is entirely operational.

The confusion is widespread, and it suits many providers well. Many organisations believe they have full coverage because they have subscribed to a managed SOC. They discover otherwise, however, at the moment they need it most.

What Is a SOC and What Is a CERT?

A SOC (Security Operations Center) is an operational security centre responsible for continuously monitoring the information system, collecting security events and detecting abnormal behaviour. It qualifies alerts and identifies threats before they spread.

A CERT (Computer Emergency Response Team), sometimes referred to as a CSIRT (Computer Security Incident Response Team), is a team specialised in cybersecurity incident response. It intervenes once a threat is confirmed: containment, eradication, remediation, recovery and post-incident analysis. It limits damage, restores control and explains what happened.

These two functions are complementary by nature. However, they are frequently sold separately, sometimes without the client being clearly informed.

What Happens Concretely When the SOC Detects but the CERT Is Not There

It is 11 pm. The SOC issues a critical alert: lateral movement is detected across several workstations. The alert is qualified and the criticality level is high. As a result, the provider sends a notification.

And then? Without an integrated CERT, the response stops there. The organisation receives the information but is left alone to decide what to do, in what order, with what resources and within what timeframe. For an organisation without a dedicated security team, this scenario is catastrophic. Every minute without containment is a minute during which the attacker advances.

Key takeaway: a SOC without a CERT is a burglar alarm without intervention. It detects the intrusion. Stopping it, however, is another matter entirely.

What Does a CERT Actually Do During an Incident?

A CERT is not a helpdesk. Indeed, it is a team trained in incident analysis, risk assessment and forensic investigation, meaning the technical and legal reconstruction of the attack chain.

When an intrusion is suspected, the CERT is activated and begins by assessing the situation: available tools, indicators of compromise, attack indicators, exposed perimeter and potential impacts. It works directly with the IT department and the SOC to make the best use of available resources and take the appropriate containment decisions.

During the crisis, the CERT may recommend or deploy specific tools, isolate network segments, block compromised accounts and preserve digital evidence. This forensic preservation is critical: without it, it is impossible to precisely reconstruct the attack chain, identify the initial vulnerability and produce the regulatory report required by NIS2, DORA or GDPR.

After the crisis, the CERT’s work does not stop at the return to normal. It also includes an in-depth post-incident analysis, architecture recommendations to address the identified vulnerabilities, and a strengthening of the overall security posture. This lasting dimension is what distinguishes a genuine CERT from a simple emergency response team.

Concrete example: a ransomware attack detected at 2 am. The SOC alerts. The CERT intervenes immediately: isolation of encrypted machines, identification of the initial attack vector, blocking of accounts used by the attacker, preservation of logs for forensic analysis. By 8 am, management has a first incident report ready for regulatory notification. Without an integrated CERT, none of these elements are available within that timeframe.

SOC and CERT: What NIS2, DORA and GDPR Now Require

European regulatory frameworks no longer separate detection from response. They require both, simultaneously, with deadlines that make improvisation impossible.

NIS2 (EU Directive 2022/2555, full text EUR-Lex) requires essential and important entities to maintain both incident detection capability and documented incident response capability. Article 23 is explicit: entities must notify “without undue delay and in any event within 24 hours of becoming aware of the significant incident” with an early warning to the competent CSIRT, followed by a full notification within 72 hours and a final report within one month. Without an operational CERT able to qualify the incident and produce the required elements, meeting these deadlines is impossible for an unprepared organisation.

DORA (EU Regulation 2022/2554, full text EUR-Lex, applicable since January 2025) goes further for financial entities. Articles 9, 10 and 11 impose obligations of prevention, detection and response to ICT incidents respectively. Delegated Regulation 2025/301 specifies the timelines: the initial notification must be submitted “as soon as possible, but in any case within four hours of the classification of the incident as major”. An additional safeguard applies: this deadline cannot exceed 24 hours after detection, to prevent an entity from artificially delaying classification. A SOC alone, without an integrated CERT able to intervene immediately and produce the required documentation, cannot meet these commitments.

GDPR: the 72-hour obligation that applies to all

GDPR (EU Regulation 2016/679, CNIL notification obligations) requires any data controller to notify any personal data breach to the competent supervisory authority. Article 33 is precise: “without undue delay and, where feasible, not later than 72 hours after having become aware of it, unless the personal data breach is unlikely to result in a risk to the rights and freedoms of natural persons.” Without a CERT to qualify the breach, assess its exact scope and document the response, this obligation is practically impossible to honour within the deadline with the required elements.

Regulation
Notification deadline
Reference text
NIS2
24h (early warning), 72h (notification), 1 month (final report)
Article 23, EU Directive 2022/2555
DORA
4h after classification (max 24h after detection), 72h (intermediate report)
Articles 19-20, EU Regulation 2022/2554
GDPR
72h (supervisory authority)
Article 33, EU Regulation 2016/679

Why SOC and CERT Integration Changes Everything in an Incident

When the SOC and CERT are operated by the same team, on the same infrastructure and with the same tools, the processing chain is continuous. The analyst who detects the incident can therefore immediately trigger containment without handover delays, coordination meetings or information lost in the transfer.

This continuity has direct and measurable consequences. First, the time between detection and containment is reduced. Furthermore, digital evidence is preserved correctly from the first minutes, which conditions both the quality of the forensic analysis and the solidity of the regulatory report. Crisis communication is consequently managed by experts who have full context of the incident. As a result, regulatory notification obligations can be met within deadlines, with the required documentation.

Conversely, when the SOC and CERT are two distinct entities, the case transfer introduces delays, friction and risks of information loss. In a ransomware incident, those minutes matter more than anything else.

For an organisation subject to NIS2 or DORA, working with a provider whose SOC and CERT are genuinely integrated is therefore not an added comfort. It is an operational requirement that regulations make unavoidable.

Data sovereignty moreover remains a decisive criterion. A SOC and CERT operated 100% within Europe, with no extraterritorial subcontracting, ensures that the most sensitive data in your information system, including event logs and digital evidence collected during an incident, never transits through jurisdictions subject to extraterritorial legislation such as the US Cloud Act. For organisations subject to GDPR, this argument is indeed far from accessory.

The 5 Questions to Ask Your SOC Provider

Before signing, however, these five questions deserve a written and contractual answer.

  1. Does your offering include an operational CERT, or only detection and alerting?
  2. What are your contractual response time commitments by criticality level?
  3. Are your SOC and CERT teams integrated or two separate entities?
  4. Do you have forensic capability to reconstruct the attack chain and produce the regulatory reports required?
  5. Where are your analysts and infrastructure physically located?

A provider unable to answer these five questions precisely will not be able to support you effectively on the night of a real incident.

Your organisation has a SOC. But does it have a CERT ready to intervene outside business hours, with forensic capability and full regulatory support? The Stroople Managed SOC integrates an operational 24/7 CERT and contractual response commitments. Contact an expert to assess your current coverage.

To go further on what a managed SOC must cover and how to choose the right provider, read our complete guide: Managed SOC: What It Is, What It Must Cover and How to Choose

Managed SOC

Stroople Managed SOC 24/7 Offering

A managed solution for your cybersecurity that protects, detects and responds. 24/7.

Learn more

Share:

X
LinkedIn