Our SOC watches the endpoints, accounts, email environments, networks and cloud services connected to it. Alerts from these sources are brought together in a SIEM and assessed by our analysts. Where action is needed, we act on procedures agreed and tested in advance. The monitoring runs all year round from inside the European Union.
Security sensors deliver alerts from endpoints, identity platforms, networks, email and cloud environments.
The SIEM brings those events together into one timeline per user and per
device, so a failed sign-in at midnight and an unusual process on a laptop
an hour later are read as one event rather than two.
The technology decides which alerts need attention. An analyst then
establishes what is actually happening, which systems or accounts are
involved and what the possible impact is.
Our SOC analysts work from Sofia, Varna and Stara Zagora. Those locations
are inside the European Union and one hour ahead of Amsterdam.
The SLA
Response within 15 minutes
The response time is set out in the agreement and measured against the records in the SIEM. You receive a report showing whether the agreed response time was met.
15 minutesThe clock starts when the SIEM classifies an alert at the highest priority and stops when an assigned analyst has picked the alert up and begun triage. The SLA covers the start of handling: how long a full investigation or containment takes depends on your environment and on the mandate you have given us.
When does the clock start?
As soon as the correlation rules in the SIEM classify the alert at the highest priority. It does not wait for you to notice anything, and it does not wait for you to call us.
When does the clock stop?
As soon as an assigned analyst has taken the alert, confirmed that it genuinely needs attention and begun triage. It is measured on pick-up and the start of triage, not on containment: how long containment takes depends on your IT estate and on the mandate you have given us.
Which alerts does it cover?
The priority levels set out in your service description. Lower-priority alerts are handled through the normal queue and included in the report, rather than being escalated in the middle of the night.
How is this demonstrated?
Every alert carries timestamps for when it was raised, when it was picked up, what was done and when it was closed. The SLA report is compiled directly from those records, so a missed target stays visible.
Coverage
What we monitor
Each SmartCyber level adds monitoring and data sources to what is already in place. Moving up to a higher level does not mean re-configuring the sources already connected.
Monitored signal sources and the SmartCyber level that includes them
Signal source
What it is watched for
Included from
Endpoints, laptops, desktops and servers
Ransomware behaviour, malware, misuse of credentials, unwanted persistence and unusual use of administrative tooling
Protect, as an add-on at Essential
Identity, directory and sign-ins
Atypical sign-ins, impossible travel, repeated multi-factor prompts, new administrator roles and dormant accounts being reused
Protect
Email
Phishing, impersonation of directors or suppliers, malicious attachments and links, and unwanted forwarding rules
Protect
Network, firewall, VPN and egress
Command-and-control traffic, scanning from inside the network, traffic to unusual destinations and atypical VPN sessions
Protect
Cloud workloads and tenants
Changes to configuration and permissions, new keys or service identities, and resources in unexpected regions
Advanced
Business SaaS services
Changes to roles, data sharing, unusual downloads and suspicious application connections
Advanced
SIEM correlation across all six sources, 24/7 cover and the 15-minute response time begin at SmartCyber Advanced. At Protect the sources are monitored individually and handled during office hours. Which sources are available depends on your technical environment, your licences and the connections the platform in question supports.
When something fires
From alert to response
Our SOC monitors your environment around the clock and acts immediately on an incident. Per organisation we agree in advance which measures we may take on our own authority and when we consult you first. Those agreements are recorded in writing, so no time is lost outside office hours.
01
Detect
The connected security systems flag behaviour that departs from the configured rules or from normal use in your organisation. That distinction matters: a script running at two in the morning is ordinary in a logistics operation and reason for a phone call in an accountancy practice.
02
Triage
An analyst checks the user, the device, the location, earlier events and the possible impact. Most alerts end here, with a record written and no interruption to you.
03
Contain
Where it falls inside the agreed mandate, the SOC can isolate a device, block an account, end a session or block a destination. Anything outside that is a call to your named contact, and that call comes at any hour.
04
Report and record
We record what was observed, when the alert started, who handled it and which actions were taken. Where the Cyberbeveiligingswet covers you, that same record is the source for the 24-hour early warning and the 72-hour notification. We draft them; you review and file, because the duty to notify stays with you.
05
Close
After the incident we verify the recovery, investigate the cause and adjust detection rules or security settings where needed. Closed incidents are discussed in the quarterly report, not filed away.
Who may authorise containment outside office hours is the one question you are better off settling before you need the answer. We ask it during onboarding and the answer goes into the contract.
What it does not do
What monitoring covers
Monitoring helps you recognise incidents sooner and act earlier. A SOC does
not prevent every incident. An intrusion caught during reconnaissance costs
a weekend of work. The same intrusion found after encryption costs a
quarter.
That is why we combine monitoring with preventive measures: patching,
multi-factor authentication, restricted access rights, hardened
configuration, mail filtering, and a backup somebody has actually restored
from. Those sit in the SmartCyber levels underneath the SOC.
The SOC can only watch sources it has been given access to, so the asset
register, a current overview of what you have under management, is the first
deliverable. And the SOC can only act on its own authority within the agreed
mandate. Missing data sources and limits on that mandate are recorded in
advance.
Build or buy
Your own SOC or ours
Which arrangement fits depends on your size, the expertise you already have in house, and your requirements for availability and reporting.
Running it in-house
Continuous cover needs roughly six analysts once shifts, leave, sickness and training are accounted for
Detection content ages. Rules written for last year's IT estate stop firing, and tuning has to be somebody's standing job
SIEM licensing and log retention are billed on volume, and that volume grows whether or not anyone is reading it
An in-house SOC also needs fixed procedures, training and staffing outside office hours
For some organisations this is still the right answer. Almost all of them are larger than the ones we work with.
Buying it as a service
You use our existing team, our processes and the agreed technology
Shift cover, holiday cover and escalation are our problem, and they arrive as one line on one contract
Detections are maintained centrally, so what is learned during one organisation's incident is running for another that same week
Your organisation keeps a say over priorities, escalation and the mandate for action
The honest limit: on day one we know your IT estate less well than your own people do. Closing that gap is what the first month is for.
Evidence
Reporting for audit and supervision
For relevant alerts we record the timestamps, the assessment and the actions taken. In a significant incident that produces a file which can be used for the statutory notification and the final report.
The alert record
Every alert raised, its severity, who picked it up, at what time, what they did and when it was closed. Retained for the period set in your contract.
Measures (b) and (f)
Incident handling, and assessing the effectiveness of your measures. Both have to be demonstrated rather than asserted, and an operational log does that where a policy document does not.
The quarterly report
The number of alerts and what they consisted of, response times against the SLA, recurring causes and open improvement points. Written to be read by a board.
What an insurer asks
Questions at renewal have become specific. Is there cover outside office hours, what is the agreed response time, how are accounts with elevated rights monitored. The report answers with data rather than intentions.
Your tuning history
Which detections were suppressed, which were added, and why. If the service ever moves elsewhere, that history goes with it.
Retention periods, the recipients and the reporting frequency are set out in the service description.
Starting the service
Your first weeks
Connecting the sensors takes days. Learning what normal looks like in your organisation takes longer.
01
Days 1 to 3: scope and access
We set the scope, check the access and map the systems, log sources, contacts and escalation routes. That inventory is where the surprises live: the server nobody owns, the tenant left over from a project, the administrator account three people share.
02
Days 3 to 7: connect and baseline
We connect the agreed sources and build a first picture of normal use. During this period the SOC can observe only, to avoid unwanted blocking.
03
Days 7 to 14: playbooks and mandate
We settle the response playbooks, record the mandate in writing, and test reachability and the technical actions with a controlled alert outside office hours, so the first real alert is not also the first rehearsal.
04
From week 3: regular monitoring
Regular monitoring starts and alert volume is at its highest, because everything unusual-but-normal in your organisation is unusual to us exactly once. Detection rules and thresholds are adjusted further on the basis of practice.
The cost of connecting and configuring is quoted separately in the proposal. IT estates spanning several countries or environments take longer, and we budget those per country rather than as a single figure.
Frequently asked
Frequently asked questions
Where does the monitoring take place?
In our delivery centers in Bulgaria: Sofia, Varna and Stara Zagora. The
client relationship and the CISO services sit in Amsterdam.
Bulgaria is a member state of the European Union, so the same GDPR
regime applies and the work runs under the same management systems. It
is one hour ahead of the Netherlands, which makes your working day and
ours the same working day. Nearshore, inside the EU and under the same
GDPR, rather than offshore.
You are a new company. Why would we trust your SOC?
Think Smart Europe is new. The engineering organisation behind it is
not.
Our parent organisation in Bulgaria has been registered since December
2019, employs the analysts and engineers who run the monitoring, and
holds the ISO 9001, ISO/IEC 20000-1, ISO 27001 and ISO 27701 management
systems this service is delivered under.
Can our current IT supplier stay?
Yes. The SOC can be set up as a separate monitoring and response layer
on top of the existing service. We read the telemetry, they keep the IT
estate running, and the split of duties is on paper before we start. It
does have to be clear who carries out which action during an incident.
Containment is where it gets difficult. If we isolate a device at two in
the morning, somebody has to be able to bring it back into use, and if
that is a party we have no working relationship with, the incident lasts
as long as their support process takes. That is a conversation between
the three of us, and we will ask for it.
What happens if the fifteen-minute response time is missed?
A miss stays visible in the SLA report. Every priority alert carries
timestamps for when it was raised and when it was picked up, and the
report is generated from those records.
Any service credits, and their limits, are set out in the agreement in
advance.
Does an agent have to be installed on every system?
For endpoints and servers an agent is usually needed. Behavioural
detection has to see the process; network telemetry alone will not show
credentials being taken out of memory. Identity platforms, email, cloud
environments and SaaS services we connect through APIs.
Where a system supports neither an agent nor a connection, such as
operational technology, legacy equipment or a system under a vendor's
own support contract, we establish which surrounding source can be used
and record the limitation. No green tick for something we cannot see.
Can we start with monitoring only?
You can, and sometimes the budget allows nothing else. Monitoring does
work better once preventive measures such as multi-factor
authentication, patch management and tested backups are in order.
Monitoring an IT estate without those measures produces a detailed
account of an incident you could have prevented. So we include missing
basic measures in the assessment, and the finding will be the same every
quarter until they are in place.
During a live incident
Call us during an incident
Containment comes first and the rest of this page can wait. If the Cyberbeveiligingswet covers you, the clock has been running since the moment you became aware, and no investigation stops it.
We map the security sources you already have, the response times you want and the mandate for incident response. You then receive a proposal covering the connection, the monitoring and the reporting.