“We need to set up a CSIRT” usually arrives in organisations as a compliance line item. The result is typically a directive, an org chart and a few names. When a real incident arrives, that structure turns out not to work.
This article separates two questions: who the obligation covers, and how to build a team that is more than paperwork.
What a SOME is
SOME stands for Siber Olaylara Müdahale Ekibi — Cyber Incident Response Team. Its international equivalent is the CSIRT.
Its job is to detect, respond to, record and report cyber security incidents in the organisation. In Turkey the structure operates in three layers:
- USOM — the national coordination centre (TR-CERT). Issues national alerts and coordinates response.
- Sectoral SOME — sits within a sector’s regulator and coordinates the organisations in that sector.
- Corporate SOME — the organisation’s own team, managing incidents on its own systems.
Who is in scope
The regulation primarily targets public institutions and critical infrastructure operators. Critical infrastructure covers sectors such as energy, electronic communications, finance, transport, water management and health.
Private sector organisations outside that scope have no direct obligation to establish a SOME. Two points are commonly missed here, though:
First, suppliers serving critical infrastructure operators often meet equivalent obligations contractually. You may fall into scope through your customer even if not on your own account.
Second, the technical and administrative measures obligation under KVKK covers everyone processing personal data. Having no capability to detect and respond to a breach can be read as an inadequacy of measures. So even without the SOME label, the same capability is effectively required.
Whether your organisation falls in scope depends on your sector and your regulator. That assessment should be made with your legal and compliance function.
How to build one
1. Roles and authority
Before team size, what needs to be settled is roles:
- Who decides whether an event counts as an incident
- Who has authority to shut down or isolate a system
- Who handles communication with management and, where needed, externally
- Who performs the technical investigation
- Who takes over when those people cannot be reached
That last point is the one most often skipped. Incidents do not happen during office hours.
2. Classification and escalation
Not every incident warrants the same response. Without classification, either every alert becomes an emergency or a real incident gets handled like routine noise.
Three or four levels are enough in practice, and for each one it must be established: who is informed, how quickly response begins, and on whose decision it escalates.
3. Visibility
You cannot respond to what you cannot see. The minimum data sources for a CSIRT to function:
- Authentication and directory service (Active Directory) logs
- Endpoint telemetry
- Firewall and network flow records
- Logs from critical applications and databases
- DNS query records
These need to be collected centrally and retained long enough. Log retention directly determines how far back an undetected adversary can be investigated.
4. Procedures
Written steps for the most common incident types: ransomware, an account compromised through phishing, unauthorised access, data leakage, denial of service.
Every procedure should open with the same line: preserve the evidence. Take an image before rebuilding. Skip that step and the scope of the incident can never be established.
5. Exercises
Skip this and everything above remains an assumption.
In a table-top exercise a scenario is given and the team walks through its response step by step. Typical findings: the decision-maker was in fact undefined, a critical server logs nothing, restoring from backup takes far longer than assumed, the emergency contact list is out of date.
At least one exercise a year is what turns a CSIRT from a document into a capability.
The common mistake: confusing a CSIRT with an org chart
Writing a directive, naming a few people and filing the chart satisfies the obligation on paper. It does not work during a real incident.
Three things separate a working CSIRT from one that only exists on paper: the team has rehearsed what it will do, the necessary logs are already being collected, and decision authority has been granted in advance.
Training the team
The longest leg of building a CSIRT is team capability. normSight’s CSIRT / Incident Response training covers establishing this structure and managing an incident from detection through containment.
Programmes frequently taken alongside it: Digital Forensics for evidence collection and analysis, Malware Analysis for dissecting the malicious code, and Cyber Threat Hunting for proactively finding undetected adversaries.
How to manage the response window itself is covered in data breach notification.
This article is general information. The obligations your organisation is subject to depend on your sector and regulator; for a binding assessment consult your legal and compliance function.
- CSIRT
- SOME
- USOM
- incident response
- SOC
- Turkey