SIEM, SOC and incident response
Round-the-clock security monitoring for public offices and companies without their own on-call team. Logs from firewalls, servers and Active Directory end up in one place, and suspicious events are caught at night and at weekends too.
Why around the clock
A public office or company usually works about 8 hours on weekdays. Attacks such as ransomware or account takeovers often begin at night and at weekends, when nobody is watching.
The reporting deadlines in the Polish National Cybersecurity System Act (KSC) are short. Without 24/7 detection they pass before the organisation even learns about the incident. Full-time analysts on 24/7 shifts are usually beyond a public office's reach, and the act allows these tasks to be outsourced to an external company.
- 24 h
- early warning to CSIRT
- 72 h
- incident notification, and for personal data also to the data protection authority (UODO)
- 1 month
- final report with the root cause
What the service covers
Data
- Central loggingfrom Active Directory, servers, firewalls and e-mail, in one place and protected against tampering
- Retentionfor the required period, at least 2 years under KRI
Detection
- Incidentsdetecting and handling suspicious events around the clock
- Vulnerabilitiesup-to-date information on vulnerable systems and new threats to your infrastructure
- Suppliers and service engineersmonitoring remote sessions of external companies
- Insider misuseunusual use of privileges, bulk data browsing, sign-ins outside working hours
Response and reporting
- Notificationspreparing notifications and technical data for CSIRT and UODO
- Post-incident analysisestablishing the root cause for the final report
- Reports for managementregular summaries showing that the safeguards work
Tools
- WazuhSIEM and XDR for collecting and correlating events
- FortiAnalyzerlogs and reports from FortiGate firewalls
How a SOC helps meet the requirements
Each function maps to a specific requirement. This is useful when justifying the request to the director or in the procurement plan.
| Need | Legal basis |
|---|---|
| Detecting and handling incidents around the clock | KSC Act, security management system; NIS2 Article 21(2)(b) |
| Meeting reporting deadlines | KSC Act, reporting significant incidents to CSIRT; NIS2 Article 23; KRI § 20(2)(13) |
| Accountability and central logging | KRI § 21 |
| Vulnerability management | KRI § 20(2)(11); NIS2 Article 21(2)(e) |
| Evidence for audits | KRI § 20(2)(14) |
| Management oversight | NIS2 Article 20; duties of the head of the entity under the KSC Act |
| Supplier access control | NIS2 Article 21(2)(d); KRI § 20(2)(9) |
| Personal data protection | GDPR Articles 32 and 33; KRI § 20(2)(6) |
What a SOC does not cover
What stays with the organisation
- security management system documentation: policies, procedures, risk analysis, business continuity plan
- training for staff and management
- an internal incident response procedure with clearly split roles between the organisation and the provider
- registration in the KSC list and cooperation with the relevant CSIRT
An auditor will check both areas, so it is worth planning for this from the start.
What to watch for in the contract
- response times in line with the statutory 24 and 72 hour deadlines
- rules for access to logs after the contract ends
- a log retention period at least as long as the regulations require
- roles during an incident: who reports, who decides, who informs management
Other cybersecurity services
Considering an external SOC?
I can help estimate the scope and prepare the justification and procurement requirements.