Managed Security

Security Operations (SOC)

Detection written and tested by people who run the attacks, alerts triaged by an engineer who knows your environment, and incident response when something is real.

Most security teams are not short of alerts. They are short of detections that fire on the technique rather than the tool, of someone with the context to tell a noisy admin script from a real intrusion, and of a plan for the first hour when it is real. Buying more telemetry does not fix any of that on its own.

We work inside the tools you already run: your SIEM, EDR, identity provider and cloud audit logs. Detections are written as code, versioned, and tested by executing the technique they are meant to catch before they go live. Alerts are triaged by engineers who also do offensive work, and an escalation arrives with the evidence, the likely scope and a recommended action rather than a rule name.

Usually, one of these is true

You have a SIEM or an EDR console full of alerts and nobody whose job it is to read them.
A penetration test or red team exercise went through without a single alert firing, and you want to know why.
A customer, an insurer or an auditor is asking how you detect and respond to incidents, and the honest answer is a shared inbox.
Something odd showed up in your logs, such as an unfamiliar OAuth grant or an admin login from a new country, and nobody can say whether it is an incident.

What we run

The work sits on your telemetry and your tools. Coverage hours, escalation contacts and the containment actions we may take without asking are written into the scope before monitoring starts.

Detection engineering. Rules written for your log sources in Sigma or your SIEM's own query language, kept in version control, and tested against the technique before they are deployed.
Telemetry and gaps. An audit of what you collect across endpoints, identity, cloud control planes and SaaS audit logs, mapped against MITRE ATT&CK to show what you could and could not see.
Alert triage. Each alert investigated against your baseline: who the user is, what the host does, whether the behaviour has been seen before. False positives go back into tuning rather than being closed and forgotten.
Incident response. Scoping, containment, evidence preservation, eradication and recovery, run with your team to a written plan. That includes resetting accounts, isolating hosts and revoking tokens, within the authority you have granted.
Threat hunting. Hunts run from a written hypothesis against your data, such as persistence in cloud IAM or unusual OAuth consents, on the assumption that a detection has already missed something.
Lessons into detection. After each incident or hunt, a written review of what happened and what should have caught it, with the new detection shipped before the review is closed.

How the service runs

It starts with your telemetry and your escalation rules, then settles into a routine of triage, tuning and hunting, reviewed on a cycle agreed in the scope.

Onboarding. We connect to your SIEM, EDR and log sources through scoped accounts, agree coverage hours and escalation contacts, and write down which response actions need your approval.
Baseline. We learn what normal looks like: admin accounts, service identities, deploy pipelines and known noisy jobs. Existing detections are mapped against ATT&CK and the blind spots listed.
Detection build. The highest-priority gaps are closed with new rules. Each is tested by running the technique in your environment or a mirror of it, and each ships with a triage note.
Triage and response. Alerts are worked by an engineer. A confirmed incident reaches your escalation contact within the hour of being confirmed, with the evidence, the scope and a recommended action.
Review and hunt. On the agreed cycle we review alert volumes, tuning changes and coverage, run hunts against the gaps that remain, and update the coverage map.

What you get

Detection repository. Every rule we write, in a repository in your organisation, with its ATT&CK mapping, the test that proves it fires and a triage note for whoever receives the alert.
Coverage map. A written map of which techniques your telemetry can see and which it cannot, for the security lead deciding what to log next.
Escalation reports. For each confirmed incident: the timeline, the evidence, the affected accounts and hosts, and the action we recommend, for the person on your escalation list.
Incident response playbooks. Written plans for your likely incidents, such as a leaked cloud key or a phished administrator, naming who decides what and which actions are pre-approved.
Post-incident reviews. A written account of each incident or hunt finding, what should have caught it, and the detection added as a result, for engineering leadership.

What we need from you

Read access to your SIEM or log platform, EDR console and identity provider, through accounts scoped to the work.
Cloud and SaaS audit logging switched on and retained, for example CloudTrail, Entra ID sign-in logs, Google Cloud audit logs and your identity provider's system log.
An escalation list: who to contact about a suspected intrusion, who can approve containment, and how to reach them outside office hours.
A list of crown-jewel systems, administrator accounts and service identities, so triage knows what matters most.
A written decision on which containment actions we may take without asking, such as disabling an account or isolating a laptop, and which always need your approval.

What we can show you

Detection from the attacking side. The engineers who write your detections spend the rest of their time on offensive engagements. They know which artefacts a technique really leaves, and they test each rule by running it.
No tier-one queue. The engineer who triages an alert is the one who escalates it and writes it up. No account manager in between, and no junior bench forwarding rule names.
Least-privilege by default. Our accounts in your tools are scoped to the work. Evidence pulled during an incident is encrypted, limited to the engineers on the engagement and covered by mutual NDA.
An incident can become a fix. One team runs testing, hardening and engineering. When an incident traces back to a misconfiguration or a missing control, the same people can close it without a hand-over.

Standards we work to

Detections are mapped to the technique catalogue your red team and auditors already use, and incident handling follows the public guidance an insurer or regulator will expect to see.

MITRE ATT&CK
Sigma
NIST SP 800-61 Rev. 3
NIST CSF 2.0 (Detect, Respond)
ISO/IEC 27035
NIST SP 800-92

Common questions

Do you provide round-the-clock monitoring?

No, and we would rather say so here than in the contract. Coverage hours are agreed in the scope, along with what happens outside them: which alerts go straight to your on-call engineer, and which containment runs automatically in your own EDR. If your risk needs a staffed overnight shift, we will tell you while we scope the work.

Do we need our own SIEM?

You need somewhere your logs land and can be queried, and it should be yours. We work in what you already run, whether that is a commercial SIEM, a cloud-native log service or an EDR console with search. If you have nothing yet, setting one up is scoped as separate platform work, and the result belongs to you.

Will you act on our systems during an incident, or only advise?

Both, within the authority you set during onboarding. Actions you pre-approve, such as disabling an account, revoking a session or isolating a host through your EDR, we take and then report. Anything else waits for a named person on your side to approve it.

How do you prove a detection works?

By running the technique it is meant to catch, in your environment where that is safe or in a mirror of it where it is not, then confirming the alert fires with the right context attached. The test is stored with the rule, so it can be rerun after a log source changes or the platform is upgraded.

We already have an MDR provider. Can you work alongside them?

Yes. Detection engineering, threat hunting and post-incident review can sit on top of an existing provider's monitoring, as can a review of why a test went unseen. We agree in writing who triages what, so an alert never sits between two parties.

Related services

Tell us about the system in the chat or on the contact page. Yaali, our AI agent, answers first and brings in an engineer.