When a company talks about "IT security," in most cases it thinks of an antivirus and a firewall. These are necessary tools, but they tell only the beginning of the story. A modern attack doesn't show up as a suspicious file in a folder: it arrives as a stolen credential used at 3 AM, as a silent lateral movement between two servers, as anomalous traffic heading to an address never seen before, or as a login to the company mailbox from a country where the company doesn't have a single employee.
To intercept events of this kind, you need something other than a product: you need a continuous process, staffed by people and fed by data. That is exactly what a managed cyber security service does, and its operational heart is the SOC — the Security Operations Center.
In this article we explain, without misleading jargon, how this chain works, from the moment a threat touches the corporate perimeter through to the response that neutralises it.
The five-step flow
The life cycle of a security event can be summed up in a simple sequence:
Threat detected → Internet → Cyber Security Service → SOC Analyst → Response
Every arrow in this diagram conceals specific technologies, skills and procedures. Let's look at them one at a time.
1. The perimeter: where the threat meets the company
It all starts at the internet connection. Incoming traffic passes through the perimeter firewall and the secure network switch, which apply the basic rules: what can come in, what can go out, to which destinations and on which ports.
Two components that are often underestimated also operate at this level:
- IDS/IPS (Intrusion Detection and Prevention System) — recognises known attack patterns and, in the case of the IPS, actively blocks them before they reach internal systems.
- Vulnerability Scanner — periodically analyses systems and applications looking for known vulnerabilities that have not yet been patched, turning security from reactive into preventive.
The vulnerabilities identified are then followed by the least visible and most decisive work: patching, that is, the regular application of security updates to systems and applications.
The perimeter alone is not enough. It filters out the noise, but it doesn't see what happens inside the network once an attacker has got in with legitimate credentials.
2. Collection: logs as the raw material
Every corporate device (servers, endpoints, firewalls, cloud applications, PLCs and OT systems in industrial environments) generates logs: traces of what has happened.
A Log Collector centralises these streams and normalises them, that is, translates them into a uniform format. Without this step, a security event would remain fragmented across ten different systems, invisible to anyone.
The Network Monitoring Server adds the traffic dimension: who talks to whom, when and at what volume.
It is often here that the weakest signals emerge, the ones no static rule would have intercepted.
A necessary aside: the invisible perimeter
There is a point where the classic scheme shows its limits. An attacker who gets in with valid credentials on Microsoft 365 or Google Workspace does not pass through the corporate firewall, does not generate anomalous traffic on the internal network and does not touch a single server in the machine room. They read the mail, download documents from SharePoint, set up an automatic forwarding rule and, quite simply, wait.
For most companies today, the perimeter no longer coincides with the firewall: it coincides with people's digital identities and with the cloud services they use every day. Monitoring that stops at the network leaves uncovered precisely the area where the largest share of credential-based attacks is concentrated.
This is why a modern monitoring service also collects identity and cloud environment logs.
At this point it is worth clearing up a very common misconception. The major cloud providers guarantee the security of the infrastructure (data centres, hardware, service continuity), but not the security of how that infrastructure is used.
Accounts, permissions, configurations and data remain the responsibility of the client company: this is the shared responsibility model. In fact, most incidents in cloud environments originate from exactly that: a configuration left open, an administrative account without MFA, a permission granted and never revoked.
Here too, though, technology alone is not enough: those logs need to be collected, correlated and read. And that is exactly what happens in the next step!
3. Correlation: the SIEM
Raw logs amount to millions of lines a day. No human being can read them.
The SIEM (Security Information and Event Management) is the engine that processes them: it applies correlation rules, behavioural models and thresholds to turn isolated events into meaningful alerts.
A concrete example: a successful login from Italy at 9 AM is not an event. A successful login from Italy at 9 AM plus one from the same account in another country at 9:12 AM constitute impossible travel, and become a priority alert. It is no coincidence that this signal comes from the cloud: events of this kind are read in the authentication logs of Microsoft 365 or Google Workspace, not in the firewall's.
4. Contextualisation: threat intelligence
The Threat Intel Server enriches every alert with external information: IP addresses known to be malicious, command and control domains, signatures of active ransomware campaigns, tactics associated with specific attack groups.
It's the difference between "anomalous connection to a foreign IP" and "connection to infrastructure traceable to a ransomware campaign active in the European manufacturing sector". The first is a doubt, the second is a decision.
5. The human factor: the SOC Analyst
This is where the element no technology can replace comes into play.
The SOC analyst receives the alerts, verifies them, distinguishes false positives from real incidents and establishes their severity. This is the triage process: without it, a team would receive hundreds of notifications a day and would end up ignoring them all. This is the phenomenon known as alert fatigue, one of the main causes of undetected incidents.
When the incident is confirmed, the analyst activates the coordinated response: isolating the compromised machine, blocking the credentials, updating the firewall rules, notifying the company contacts and, where applicable, starting the notification procedures.
Why the "as a Service" model makes sense for most companies
Building an in-house SOC means covering three shifts, seven days a week, with specialised staff, licensed technologies and continuous updating of skills. For the vast majority of Italian SMEs (and for many enterprise companies too!) it is an investment out of all proportion to the benefit.
The SOC as a Service model spreads those costs across multiple clients and offers in return:
- Genuine 24x7 coverage, including nights, weekends and public holidays (that is, exactly the time windows in which most attacks are concentrated!).
- Up-to-date expertise, because a team that analyses incidents across dozens of infrastructures sees patterns an in-house team would never come across.
- Measurable detection and response times, formalised in SLAs.
- Predictable costs, on a subscription basis, with no capital investment.
The regulatory context: NIS2 is not optional
For many Italian companies the issue has stopped being purely technical. The NIS2 Directive, transposed in Italy through Legislative Decree 138/2024, extends cyber security obligations to a far wider scope than in the past: manufacturing, energy, transport, waste management, food production, digital services and other sectors, including medium-sized organisations.
The obligations cover, among other things, risk management, business continuity, supply chain security and — a particularly relevant point — the notification of significant incidents within tight time windows, with an initial alert within 24 hours.
Meeting that deadline without continuous monitoring is, quite simply, too difficult: you cannot notify an incident within 24 hours if you only discover it three weeks later. Detection capability is no longer just a security best practice, it is a prerequisite for compliance.
Important note: the specific obligations vary depending on the sector and the classification of the entity. We always recommend a precise assessment of your own regulatory scope.
The six activities that define a serious service
Acronyms aside, a managed cyber security service is judged on what it does every day:
- Constant threat monitoring, without interruption
- Processing of security logs (network, system and cloud identity) through a SIEM
- Enrichment with up-to-date threat intelligence
- Verification and triage of alerts by human analysts
- Coordinated incident response, with defined procedures
- Regular patching and system updates
If a provider cannot explain how it carries out each of these six activities, and with what response times, it's worth digging deeper.
☁️ EETECH point of view
Our experience in technology consulting, in Italy and in India, has led us to a recurring observation: companies are not compromised because they lack tools, but because nobody looks at the data those tools already produce.
The firewall was there. The logs were there. The alert, in many cases, was generated. It's just that, at two in the morning on a Saturday, there was nobody there to read it.
Closing that gap — between installed technology and actual surveillance — is the real value of a managed cyber security service!
🚀 Want to know where your infrastructure's security stands?
Contact us for a preliminary assessment of your exposure level and your NIS2 compliance!