NIS2 · LT Cybersecurity Law · NKSC
A SOC is not a tool.
It is an accountable function.
The SOC Officer is the person who answers for it — for what the SOC watches, what it misses, how fast it responds, and what the organisation can prove when a supervisory authority asks. This site sets that job out procedurally: the mandate that grants the authority, the cadence that runs the week, the procedure that runs an incident, and the evidence that closes the loop.
- 24 / 72 h
- Statutory clockEarly warning within 24 hours of awareness, notification within 72. The SOC Officer owns the timestamp that starts it.
- 10
- Measure areasNIS2 Art. 21 sets ten baseline risk-management areas. Detection, handling and continuity land on the SOC.
- L1 → L3
- Escalation spineTriage, investigation, deep analysis. Every gate between them is a written trigger, not a judgement call.
- Personal
- LiabilityManagement bodies approve the measures and can be held liable for failing to. Your evidence trail is their defence.
Deadlines and article references are summarised from the NIS2 Directive. See the full compliance mapping.
The role
Five functions, one signature
Every SOC does roughly the same five things. What makes someone the SOC Officer is that each one has their name against it.
- F01
Detection & analysis
Continuous monitoring and correlation of security events, primary triage, and proactive hunting for what the rules did not catch.
- Monitor and correlate security events across the estate
- Primary alert triage (L1–L2) and false-positive filtering
- Proactive threat hunting against hypotheses, not alerts
- F02
Incident response
Registering, classifying and prioritising incidents; deep investigation and forensics; containment, eradication and coordinated recovery.
- Register, classify and prioritise every incident
- Deep investigation and digital forensics (L2–L3)
- Contain and eradicate the threat, then coordinate restoration
- F03
Compliance & accountability
Statutory incident notification, periodic reporting to the management body, and standing ready for internal and external audit.
- Notify the national authority within the statutory deadlines
- Produce periodic reports on security posture, incidents and KPIs
- Participate in internal and external security audits
- F04
Security improvement
Turning every incident and every false positive into a change: tuned detections, closed gaps, and security requirements on new systems.
- Create and continuously tune detection rules and scenarios
- Issue remediation recommendations to system owners
- Contribute security requirements to new IT solutions
- F05
Knowledge management
Threat intelligence that changes what you look for, and documentation good enough that the SOC survives the departure of any one analyst.
- Collect, analyse and apply threat intelligence
- Document procedures (SOPs) and response playbooks
- Maintain the shift handover and on-call knowledge base
Operating rhythm
The job is a cadence, not a queue
A SOC that only reacts is a ticket queue with a security label. What makes it a function is a rhythm that runs whether or not anything is burning — and that rhythm is the SOC Officer's to hold.
Per shift
L1 / shift lead- Handover: open incidents, watch items, environment changes in flight
- Confirm detection and log-source health dashboards are green
- Work the alert queue to the agreed triage time target
- Escalate against written triggers, not against workload
- Record the handover before leaving — no verbal-only transfers
Daily
SOC Officer- Review incidents opened, escalated and closed in the last 24 hours
- Check ageing: anything past its severity-linked response target
- Confirm no log source has silently stopped reporting
- Clear the escalation decisions that need your authority
Weekly
SOC Officer- Tuning review: top noisy rules, and what will be done about each
- Detection backlog grooming against current threat intelligence
- Open recommendations to system owners — chase what has slipped
- Rota and coverage check for the coming two weeks
Monthly
SOC Officer- Issue the management report: posture, incidents, KPIs, risks
- Review MTTD and MTTR trends and explain any movement
- Close out post-incident review actions that are now due
- Review coverage changes: new systems onboarded, sources retired
Quarterly
SOC Officer + CISO- Exercise: table-top or technical, with a written result
- Efficacy test — does the detection stack still catch what it claims?
- Review the SOC's own risks: key-person, capacity, tooling contract
- Refresh the threat model and re-prioritise the detection roadmap
Annually
Management body- Re-approve the SOC mandate, scope and delegated authority
- Reassess the effectiveness of the risk-management measures
- Confirm management-body cybersecurity training is current
- Review staffing, competency matrix and succession for each tier
Why the cadence matters more than the tooling
Supervisory review does not ask which platform you bought. It asks who decided what to monitor, when they last checked that it was still arriving, what the measured detection and response times were, and who was told. Each of those answers is produced by a recurring activity — or it does not exist.
Incident procedure
From event to evidence
The escalation spine of a SOC: an event is registered, triaged, escalated only against written triggers, and closed with a decision that is recorded either way — including the decision that it was nothing.
The gate most SOCs get wrong
Closing a false positive is not the end of the step. If the rule produced it, the rule owes you a change — a tuning ticket, a suppression with an expiry, or an accepted exception with a name against it. Otherwise the same alert costs you the same analyst minutes next week.
- 1
Register the event
L1Automatically or manually, into the incident management system. Enough data must be captured for later analysis: time, source, indicators, and the raw alert. - 2
Triage
L1Establish significance and truth. Is it an obvious false positive? Can it be resolved by an existing playbook? Both answers are recorded. - 3
Close, or escalate
L1Unfounded events are closed — and assessed for whether the detection rule needs work. Anything else escalates to L2. - 4
Initial incident assessment
L2Deeper analysis: context, threat vectors, systems affected. The false-positive question is asked again where L1 could not answer it definitively. - 5
Investigate or escalate to L3
L2 → L3Where scope, persistence or forensic depth exceeds L2, escalation to L3 is triggered — against a written condition, not a feeling. - 6
Notify and contain
SOC OfficerStakeholder notification runs in parallel with containment. The awareness timestamp is fixed here, and the regulatory clock starts. - 7
Close, tune, learn
L2 / L3The incident closes with a documented outcome, detection rules are improved, and actions from the review are assigned owners and dates.
Instruction & help kits
Things you can actually run today
Each kit is a working procedure — checklists that keep state, templates you can copy into your own document set, and reference tables you can put in front of an auditor.
- Leadership
First 90 days as SOC Officer
A sequenced plan for taking over a SOC: what to establish in week one, what to measure by day 30, and what must be signed by day 90.
Open kit - Governance
SOC mandate builder
The section-by-section skeleton of a formal SOC charter — authorities, scope boundary, reporting line, review triggers — plus the approval checklist.
Open kit - Incident
Triage & escalation kit
The L1/L2/L3 decision gates, the severity model, mandatory intake fields, and the escalation triggers written so an analyst can apply them at 03:00.
Open kit - Compliance
Regulatory notification kit
The significant-incident test in operational language, the 24h / 72h / one-month submission pack, and the notification clock.
Open kit - Compliance
Monthly report & KPI kit
A complete report table of contents, the KPI catalogue with definitions and targets, and the production procedure that gets it out on time.
Open kit - Operations
Shift & handover kit
Start-of-shift verification, the handover record that survives an audit, on-call rules, and the escalation contact matrix.
Open kit
Regulatory footing
Two texts define the floor
NIS2 sets the European baseline for risk-management measures, incident reporting and management-body accountability. The Lithuanian Cybersecurity Law transposes it and adds the national machinery — the register of cybersecurity subjects, the organisational and technical requirements, and the reporting path through NKSC.
Art. 20 — Governance
Management bodies approve the measures, oversee implementation, and must be trained. The SOC Officer supplies what they approve and the proof they oversaw it.
Art. 21 — Measures
Ten baseline areas including incident handling, business continuity, and the effectiveness assessment of the measures themselves.
Art. 23 — Reporting
Early warning, notification, optional intermediate report, final report. Deadlines run from awareness.
LT law — National layer
Registration as a cybersecurity subject, the organisational and technical requirements, and the appointed person responsible for cybersecurity.
Start where the accountability starts.
Without a signed mandate, a SOC has responsibility without authority — it can see a compromised host and still need permission to isolate it. Everything else on this site assumes that document exists.