SOC and MDR as a service make sense when an organization needs 24x7 detection and response but lacks the scale to keep a mature team in-house. The provider delivers continuous monitoring, triage and containment; the company keeps the business context and the final decision. The choice depends on maturity, volume and total cost.
Few security-operations topics cause as much confusion as the difference between building an internal SOC, hiring a managed SOC, or subscribing to an MDR service. All three answer the same problem — seeing and containing an attack before it becomes an incident — but start from very different assumptions about cost, scale and maturity. This piece separates the concepts and shows how to decide without getting stuck on vendor labels.
What are SOC and MDR as a service?
A SOC (Security Operations Center) is the function of monitoring, detecting and responding to threats continuously; MDR (Managed Detection and Response) is a service that delivers that function from the outside, combining technology, telemetry and on-call analysts. In practice, a SOC can be internal, outsourced or hybrid — MDR is one way to outsource it, focused on active detection and response, not just on collecting alerts.
The distinction that matters most is not the name, but what each arrangement covers:
- Internal SOC — the organization builds the team, operates the tooling (SIEM, EDR, log analysis) and responds to incidents with its own staff.
- Managed SOC (classic MSSP) — a third party monitors the tooling and forwards alerts, but response usually stays on the client side. It becomes a ticket factory when triage is weak.
- MDR — the provider not only detects but drives the response: isolates an endpoint, blocks an account, contains the threat and then hands over the context. It is the evolution of the managed model aimed at shrinking the time between alert and containment.
The most common blind spot is buying a service that only generates alerts and expecting from it the maturity of one that also responds. Detection without response hands the hard work back to whoever lacked the team to do it.
When does buying make more sense than building in-house?
Buying SOC or MDR as a service makes sense when the cost and time of building the capability in-house outweigh the value of holding it under direct control. A mature in-house SOC requires 24x7 shifts, which in practice means hiring six to eight analysts just to cover the schedule without fatigue, plus detection engineering, platform management and talent retention — a cost surface few companies outside the financial sector sustain alone.
Signs that the as-a-service model tends to pay off:
- The operation needs 24x7 coverage and the volume does not justify a full internal team. Attacks do not respect business hours; a team that only covers the day leaves the most-exploited window uncovered.
- Mature detection engineering is missing. Buying a SIEM is easy; writing, tuning and maintaining useful detection rules is the real work, and it is where most internal SOCs stall.
- Analyst churn erodes the capability. Security operations suffer from high turnover; a provider spreads that risk across many clients.
- The company needs to stand up the capability fast, driven by a regulatory or contractual requirement or a recent incident, without waiting the months an internal build takes.
- The total cost of in-house does not add up. Once you sum people, platforms, training and opportunity cost, the as-a-service model often delivers more maturity per unit invested in the early stages.
On the other hand, building (or keeping) the internal SOC makes sense when the business context is highly specific, when there is a regulatory constraint on where telemetry may be processed, or when the organization has already reached enough scale for the in-house team to come out cheaper than the service. In most cases the winning design is hybrid: the provider sustains the continuous work and the on-call shifts, and a lean internal team keeps the context, decides on higher-impact actions and governs the vendor.
Outsourced SOC/MDR or internal team: how to compare?
An honest comparison looks at total cost, time to maturity, coverage and control — not just the subscription price. The table below summarizes the structural differences between the two extremes; the hybrid model, in practice the most adopted, combines the columns according to risk.
| Criterion | Internal SOC | SOC/MDR as a service |
|---|---|---|
| Time to operate with maturity | Months to years | Weeks |
| 24x7 coverage | Requires 6 to 8 analysts on shifts | Included in the service |
| Detection engineering | Depends on hiring and retention | Shared across clients |
| Upfront cost | High (people + platform) | Predictable subscription |
| Business context | Maximum (team is internal) | Must be transferred to the provider |
| Control over response | Total | Defined by contract and SLA |
| Where telemetry is processed | Under direct control | Depends on the provider's model |
| Main risk | Churn and slow maturity | Dependence and black box |
No column is a universal winner. The mistake is to compare only the service's monthly fee against an analyst's salary — the real math includes the shifts that guarantee coverage, the platform, ongoing training and the time until the operation actually detects something relevant.
What to demand from a SOC/MDR provider?
Demand operational transparency, contracted response and ownership of your data — without those three pillars the service becomes a black box you can neither audit nor take with you. A provider's quality lies less in the marketing and more in what it will put in writing. The minimum checklist before signing:
- Detection and response SLAs, not just availability. Ask for the average time to triage and to containment, and what happens when it is missed. "Platform uptime" protects no one.
- Technique coverage mapped in MITRE ATT&CK. A serious provider shows which tactics and techniques it detects and where the gaps are, rather than promising to detect "everything".
- Active response defined. Make clear what the provider may do on its own (isolate an endpoint, block an account) and what requires approval. Ambiguity here costs precious minutes during an incident.
- Actionable, regionalized threat intelligence. Generic intelligence generates noise; what matters is contextualized for your sector and for the threat landscape that actually hits operations in Brazil and Latin America.
- Co-managed model with no lock-in. You must retain access to the raw data, the detection rules and the history. If leaving the contract means losing everything, the switching cost becomes a cage.
- Data ownership and residency. Define by contract where telemetry is stored and processed and who can access it — critical for LGPD and for data under sector regulation.
- Reports that support decisions, not vanity. Metrics on response time, incidents contained and coverage evolution are worth more than an alert count.
- Integration with your response process. The provider must fit into your incident response plan and your channels, not impose an isolated flow no one internally follows.
How does SOC/MDR connect to compliance and regulation?
Continuous detection and response are, increasingly, a regulatory requirement — not just good practice. Institutions under financial-sector supervision must demonstrate the ability to monitor and respond to cyber incidents; the BACEN/CMN resolutions on cybersecurity, including 4.893, set requirements for policy, detection and incident reporting that a SOC/MDR helps sustain. The same applies to payment operations and to anyone processing data under the LGPD, where detection time directly influences the ability to contain the leak and to report within the deadline.
A well-designed detection service feeds the rest of the security program. It provides monitoring evidence for ISO 27001 readiness audits, sustains the incident-response requirements demanded by PCI DSS, and reinforces personal-data governance in LGPD adequacy work. For organizations with European exposure, the same controls speak to the incident-reporting obligations of the NIS2 directive. The SOC is not an operational island — it is the layer that produces living evidence that the standards' controls actually work day to day.
How Berghem does it
Berghem treats detection and response as a capability that must be intelligent, not just continuous. The starting point of our threat intelligence and detection service is not the volume of alerts, but each client's threat model: which adversaries have a reason to attack that operation, which techniques they use, and where a failure would have the greatest business impact. From there, detection engineering is tuned to what matters — because a dashboard that screams at every event is a dashboard the team learns to ignore.
The work rests on three principles. The first is regionalized intelligence: we map techniques in MITRE ATT&CK and prioritize the threats that actually hit operations in Brazil and Latin America, rather than importing generic scenarios. The second is integration with the rest of the security program — detection speaks to the Red Team exercises that validate whether controls really fire, to the network pentest and the cloud pentest that shrink the monitored surface, and to the compliance track when a standard is in play. The third is transparency: you keep access to the context, the rules and the evidence, with no black box.
We are an information security company in São Paulo, and the service connects to the portfolio as risk justifies, from API pentest to Open Finance security. Every engagement prioritizes business impact over an alert count, with recognized methodology sustaining each step.
Frequently asked questions
What is the difference between a managed SOC and MDR?
A classic managed SOC monitors your tooling and forwards alerts, leaving the response to you; MDR goes further and drives the containment — isolates an endpoint, blocks an account, contains the threat — before handing over the context. The practical difference is the time between alert and action: MDR closes that gap.
Does SOC as a service replace the internal security team?
It does not replace, it complements. The provider sustains the 24x7 shifts and detection engineering that demand scale, but the business context, the decisions on higher-impact actions and the governance of the vendor itself must stay on the organization's side. The most effective design tends to be hybrid.
How do you avoid lock-in to an MDR provider?
Define in the contract, before signing, that you keep access to the raw data, the detection rules and the incident history, plus data residency compatible with the LGPD. Require that the telemetry and detections be exportable. If ending the contract means losing everything, the switching cost becomes a cage.
To design detection and response tuned to your threat model, explore Berghem's threat intelligence and detection service.