Defence Lab
what we protect.
PeopleCode & deliveryInfrastructure & cloudDevicesOfficesGovernance & compliance All 18 servicesopen the full list → platforms. vendors. blog. about us. book a consultation

Security Operations Center (SOC)

Managed detection and response

The detection function, run by a team small enough to answer you and deep enough to do the engineering.

If you are comparing suppliers rather than deciding whether to monitor at all, three things are worth checking on every proposal in front of you. This page answers those three.

  • How long a detection takes to reach a human
  • Who decides about your environment
  • What you can show your board

Situation

Five ways this usually starts

The tool is rarely the problem. What is missing is somebody whose job it is to run it.

We bought a system and it makes a lot of noise. We turned the emails off.

Detections get switched off to keep the volume down, and then nobody is certain what is no longer covered.

We have the software but I do not know if it is working.

The licence is paid and the agents are deployed. Which machines are missing is the part nobody can answer.

We cannot have someone awake all night.

If nobody is assigned to overnight alerts, an incident waits until the next working day. Those hours are a staffing question before they are a technology one.

If something happened, I do not think we would know.

No central logging, no EDR, nothing watching. The cheapest version of this work to start, not the most expensive: there is no bad tuning to undo first.

Our customer asked whether we monitor around the clock.

DORA, PCI DSS and ISO 27001 each ask for part of this. Which applies to you depends on your organisation; what we provide is the detection, the handling and the record behind it.

If a SOC is already in place, the question is usually covering what it does not: the hours, the depth of investigation, the root-cause work.

Book a consultation

Cost

The case you will have to make internally, and what belongs in it

Three parts of the same picture. Switch between where you are today, staffing it yourselves, and running it with us.

The tooling

What the spend has been buying

Coverage unmeasured

Licences are paid and agents are deployed. Which assets they actually cover is a guess.

The rota

What makes round-the-clock expensive

Nobody assigned overnight

Alerts that arrive out of hours wait for the next working day.

The board

What you can show for the money

Spend, not outcome

You can show what was spent. What it bought is harder to put on a page.

The spend has usually happened already. What is unclear is what it has been buying. We reconcile coverage against your asset list first, so the gap becomes a number you can put in a slide rather than a guess.

The rota is what makes round-the-clock expensive, not the tooling. The figure usually quoted for staffing it internally is eight to twelve analysts, before anyone has looked at a single alert. One line in a budget also survives a review better than headcount does, and you can start at the tier covering the hours that carry the most risk rather than defend the whole clock in one meeting.

We will talk about the numbers with you, not around them. If a figure on a proposal is not measured or written into a contract, we will say which it is.

Difference

How quickly a detection reaches a person who can decide

Nothing waits in a queue before a person sees it. Scripts gather the evidence, AI prepares the first assessment and names what is missing, and the engineer who opens the case starts from that rather than from a raw alert. The platform we monitor on was chosen for the same reason: where notification lags the incident, a fast connection moves a great deal of data inside the gap.

A small team decides faster than a large one. You are likely also comparing us with operations of hundreds or thousands of staff, whose scale and accumulated incident experience we do not claim. What they do not have is a short path from your alert to the engineer who can act on it, or AI through the whole pipeline rather than piloted in one corner of it.

The rules are written here and changed after incidents. An engineer reviews the gap, updates the detection or playbook and tests the change before it goes live; where a lesson applies to other environments we protect, we adapt it there too.

An engineer decides on your alerts, and says why. Severity, next action, and the reasoning, to your team. The alerts that do not become incidents are closed with their reason recorded and accounted for in your reporting.

Method

How an alert is handled, from the rule firing to the message in your channel

An alert goes through five steps. The picture shows who does each one, and what the same step looks like handled by hand.

With us

Fires on the platform

The detection rule fires, and automated context gathering begins the moment it does.

By hand

Lands in a queue

The alert joins the others in a console or an inbox and waits there until somebody picks it up.

Automated context gathering begins the moment the alert fires. Response times for each severity are written into your contract.

Tiers

Coverage and response times rise with the tier

What changes between the tiers is the coverage window, the breadth of detection, and how much tuning and reporting is included.

TierCoverageDetectionTuning and reporting
Tier 1CoverageBusiness hoursDetectionA core detection setTuning and reportingMonthly reporting
Tier 2CoverageExtended hoursDetectionA wider detection setTuning and reportingWeekly reporting and regular tuning
Tier 3CoverageRound-the-clock coverDetectionDetection mapped across the attack lifecycleTuning and reportingRoot-cause analysis
Tier 4CoverageRound-the-clock cover with a dedicated teamDetectionContinuous tuningTuning and reportingIncident records and evidence exports for the frameworks you report against

The hours your tier covers, the response time for each severity, and what applies outside those hours are set in your contract.

Add-onsThreat intelligence monitoringDASTManaged Security Gate for CI/CD

Your data

What reaches the AI, and what does not

  • Identifiers removed before anything reaches the AI. Scripts strip identifying fields and the AI reads only what they have prepared, the same for anything an engineer sends by hand. The result is pseudonymised rather than anonymous: log data can rarely be reduced to the point where re-identification is impossible, and we would rather say so.
  • Processed in the EU. Collection, analysis and storage.
  • Not used to train models. Yours or a provider’s.
  • Kept for an agreed period. The length is set in your contract, because how far back you need to be able to investigate is your decision rather than our default.

The full detail (sub-processors, retention, where each part of the processing runs) is in the data processing agreement, on request.

Next step

Tell us what you are already collecting

One call about what you already run.

  • Endpoints and servers
  • Which EDR, if any
  • The log sources to watch
  • Your cloud footprint
  • An acceptable response to a critical alert
  • Whether we may isolate a host on your behalf

Then the preparation period: sources connected, response boundaries agreed, detections tuned against your real traffic. It runs in weeks rather than days. You come out of it with an agreed source list, escalation contacts and a written record of the gaps that remain.

Book a consultation