Post-implementation SOC. What does daily collaboration with a Security Operations Center look like?
The SOC service has been launched. Systems are streaming logs, analysts are monitoring the infrastructure around the clock, and the administrator can finally breathe a sigh of relief… right? Not necessarily. This is precisely where the phase begins that largely dictates the effectiveness of the entire service.
What does collaboration with a Security Operations Center actually look like in practice?
Why does detecting suspicious behavior not always indicate a breach, and what happens when a SOC analyst requires information that cannot be found within the monitoring stack?
In the third episode of the Perceptus cybersecurity podcast, Grzegorz Gąsiewski (Director of the SOC Department) and Łukasz Zajdel (Sales Director) dive into these issues, contrasting client expectations with the operational realities of daily 24/7 threat monitoring and incident response.
Procurement is only the beginning of the partnership
Decisions to partner with an external SOC are usually preceded by detailed negotiations regarding service scope, technical capabilities, response times (SLAs), and vendor accountability. The client outlines their expectations, the vendor defines their operational deliverables, and implementation begins.
At this stage, the first real challenge emerges: translating high-level sales agreements into functioning operational workflows.
Integrating log sources, establishing communication channels, transferring infrastructure documentation, and defining escalation trees demand close collaboration from both sides.
However, this process does not always move as smoothly as initially planned.
From a SOC standpoint, these bottlenecks carry tangible operational consequences. A lack of log visibility directly restricts threat detection capabilities. Similarly, incomplete knowledge of the network architecture makes it difficult to distinguish legitimate baseline activity from malicious behavior.
Launching a SOC is not a turn-key transaction; it is the beginning of a continuous process in which the vendor progressively learns the client’s operational environment while the client learns how to work alongside a 24/7 security team.
Suspicious activity detected. Is it automatically an incident?
Consider a scenario where an employee uploads a massive volume of data to an external cloud platform.
The monitoring system flags the abnormal outbound network transfer and triggers an alert. Are we witnessing an active data exfiltration attempt?
Not necessarily.
It could simply be a marketing specialist uploading high-resolution video assets to an external agency, or a system administrator executing a scheduled off-site backup. Nevertheless, the exact same technical pattern could indicate an adversary attempting to exfiltrate proprietary data.
This distinction illustrates the difference between automated anomaly detection and contextual security analysis. An alert merely signifies that an activity triggered pre-configured detection criteria; it rarely provides a definitive explanation for why it occurred.
A SOC analyst must evaluate contextual variables: inspecting the source and destination nodes, analyzing correlated telemetry, reviewing historical user behavior, and checking whether similar events have occurred in the past. While answers can often be found within aggregated log files, other scenarios require contacting the client’s internal IT administrator directly.
The SOC maintains visibility over technical telemetry, but it does not inherently know the internal business context. Without that context, even an accurately flagged anomaly can be misinterpreted.
Why doesn't the SOC forward every single alert to the client?
In a robustly monitored enterprise infrastructure, the volume of raw security events generated daily can be staggering. However, relatively few demand internal IT intervention. This highlights the operational gap between a basic log-forwarding tool and a managed service where analysts continuously vet and classify telemetry.
SOC analysts triage incoming alerts, correlate cross-platform data points, and filter out non-threatening anomalies – commonly known as false positives.
Because of this triage process, the client’s IT team isn’t forced to investigate every raw notification console trigger. However, false positives cannot simply be ignored or forgotten.
As Grzegorz explains, when a single detection rule repeatedly generates unhelpful alerts, it indicates that the underlying logic requires fine-tuning.
An overly sensitive rule floods the team with low-priority noise, causing alert fatigue. Conversely, overly aggressive exclusion filters risk blinding the system to genuine intrusion attempts.
Furthermore, a detection rule that performed flawlessly for months may begin generating excessive noise following an operating system update, a network re-configuration, or the deployment of new business software.
Consequently, continuous detection engineering and rule tuning represent ongoing, daily SOC responsibilities rather than a one-time onboarding task.
SOC vs. MDR: what is the difference in practice?
While both Managed Detection and Response (MDR) and Security Operations Center (SOC) services enhance organizational security postures, they differ fundamentally in monitoring depth, analytical scope, and technical containment capabilities. In the podcast, Grzegorz Gąsiewski breaks down these operational differences based on the service portfolios delivered by Perceptus:
| Operation area | SOC (Security Operations Center) | MDR (Managed Detection and Response) |
|---|---|---|
| Monitoring scope | Broad visibility across the entire IT estate, spanning diverse systems and data streams. | Focused primarily on protected endpoints, workloads, and servers running EDR/XDR agents. |
| Telemetry sources | Ingests logs from perimeter firewalls, network switches, Active Directory, cloud services, and security tools. | Deep telemetry and telemetry-driven detections originating mainly from endpoint EDR/XDR agents. |
| Threat analysis | Cross-system event correlation, infrastructure anomaly detection, and holistic incident scope assessment. | Deep-dive forensic inspection of suspicious processes, memory executions, and host behaviors. |
| Response capabilities | Focused on threat identification, triage, enrichment, and delivering actionable guidance to client IT teams. | Ability to execute direct containment actions on the host (e.g., network isolation, killing malicious processes). |
| Primary business value | Comprehensive operational visibility across complex, heterogeneous enterprise environments. | Granular host-level process visibility coupled with rapid containment of endpoint threats. |
SOC and MDR are not mutually exclusive or competing services. In mature defense architectures, they complement each other – merging broad infrastructure monitoring with deep, endpoint-level analysis and rapid automated response.
What should an organization prepare before launching a SOC?
The discussion highlights another widespread operational hurdle: an organization’s incomplete visibility into its own internal IT estate.
It is not uncommon for SOC analysts to observe unmapped communication pathways between network hosts only to find that internal administrators cannot identify the business purpose or owner of the underlying server.
In large, distributed enterprise environments – particularly those managed by lean IT departments – such visibility gaps are common. However, they introduce friction during active threat investigations.
To enable a SOC team to deliver optimal protection from day one, an organization should prepare:
An Updated Asset Inventory: Documenting critical applications, data repositories, system owners, and inter-dependencies.
Operational Baselines: Providing insight into standard operational routines, such as backup schedules, maintenance windows, and unusual business processes.
Streamlined Escalation Protocols: Designating primary emergency contacts, off-hours on-call rosters, and expected notification handling times.
Verified Telemetry Ingestion: Ensuring all target systems within the service scope are actively and reliably forwarding complete log files to the SOC collector.
Effective SOC operations demand mutual collaboration
Implementing a Security Operations Center does not automatically solve every cybersecurity challenge overnight.
While a SOC provides continous event monitoring, identifies anomalies, and shields internal administrators from overwhelming alert fatigue, it does not possess complete insight into a client’s daily business operations, nor does it maintain unrestricted authority to make every operational call independently.
Success requires high-fidelity data feeds, current system documentation, and reliable access to internal administrators who know the organization’s infrastructure.
This sentiment captures the essence of working with a managed SOC.
True security is never achieved by attempting to offload total responsibility to a third-party vendor. It is the product of an active operational partnership where both sides understand their respective roles, maintain clear lines of communication, and execute coordinated playbooks when real threats emerge.
Looking to enhance your cybersecurity?
Contact us!
Leave your details – we’ll call you back
Our specialist will get back to you no later than the next business day. You don’t have to fill in the message field, but a brief note about the topic you’re interested in will be a valuable hint for us.
