Delivery model
What actually happens, from first call to steady state.
Security services are easy to describe vaguely. This page sets out the sequence, what each stage produces, and what we need from you at each point.
Onboarding
Five stages before anything is called covered.
Onboarding is a defined project with an end point, not an open-ended integration effort. You should always know which stage you are in and what it produces.
01 · Scoping
Understand the environment
What you run, what matters most, what you already have in place and where the real risk sits. This determines everything downstream — collecting from the wrong sources is the most common way monitoring programmes fail quietly.
02 · Design
Agree coverage and authority
Which systems are in scope, which severity levels get which response, who is contacted and in what order, and which containment actions we are pre-authorised to take without waiting for a decision.
03 · Connect
Establish telemetry
Log sources and security agents are connected, validated and checked for gaps. We confirm that what we expect to receive is actually arriving before anything is treated as covered.
04 · Tune
Baseline and tune
Every environment has legitimate activity that looks suspicious in isolation. The tuning period establishes what normal looks like for you, so detections mean something when they fire.
05 · Operate
Go live
Monitoring moves into steady-state operation, with regular reporting and a review cycle that revisits coverage as your environment changes.
How your SOC works
Six steps from connection to continuous improvement.
Onboarding is a defined sequence, not an open-ended project. Each step has an owner, an output and an agreed definition of done.
- 01
Connect
Security agents and log sources are connected to the monitoring platform. We agree scope, asset criticality and escalation paths before anything goes live.
- 02
Collect
Telemetry is collected from endpoints, servers, identity providers, applications and network infrastructure, then normalised into a common event model.
- 03
Detect
Detection rules and security analytics identify suspicious activity — authentication anomalies, privilege changes, malware behaviour, persistence and lateral movement.
- 04
Investigate
Analysts correlate related events, establish what actually happened, and determine whether the activity is benign, suspicious or a confirmed incident.
- 05
Respond
Confirmed incidents are classified and escalated through the agreed path, with containment and remediation actions coordinated against pre-approved playbooks.
- 06
Improve
Findings from incidents, hunts and offensive assessments feed back into detection content, so coverage improves against the attacks that matter to you.
How the SOC is built
From your estate to an incident you can act on.
Security telemetry moves through collection, analytics and detection before it ever reaches an analyst — and nothing reaches you until a human has established what it means.
Scroll the diagram horizontally to see the full flow.
Collected, not scraped
Telemetry is collected from sources you approve, over encrypted channels, at a depth agreed during scoping.
Correlated across sources
An identity event, an endpoint detection and a firewall log describe one story. They are only useful together.
Improved continuously
What incidents and offensive engagements reveal becomes new detection content, so coverage compounds.
Source types shown describe the customer-side systems telemetry is collected from. They do not imply vendor partnerships, certifications or endorsements.
What reaches you
Actionable incidents, not alert noise.
Everything between a raw event and your inbox is our work, not yours. By the time you are contacted, the activity has been detected, reviewed by an analyst, investigated and classified.
An alert-forwarding service moves the problem to you with extra steps. Your team still has to establish context, still has to investigate, and still has to decide — only now with less information than the tool that raised it.
A managed SOC absorbs that work. You receive a classified incident with evidence and a recommended course of action.
Event to notification
- 1
Security Event
Raw telemetry from your estate
- 2
Automated Detection
Analytics and detection rules
- 3
SOC Analyst Review
Human assessment of context
- 4
Investigation
Timeline and scope reconstruction
- 5
Incident Classification
Severity and impact assigned
Customer Notification
Actionable incident, with evidence
- 7
Response / Remediation
Containment and follow-through
Service levels
Scoped to your requirements, agreed in writing.
We don't publish a headline response time, because a number set before anyone has seen your environment isn't a commitment — it's a marketing figure. Service levels are defined against the dimensions below and written into the agreement.
Monitoring Coverage
Which systems, identities and environments are in scope, and at what depth.
Response Requirements
Target acknowledgement and escalation timelines for each severity level.
Operating Hours
Business-hours, extended-hours or continuous coverage, including 24/7 options.
Business Criticality
Which assets and processes justify the fastest response, and which do not.
Organisation Size
Endpoint and server counts, user population and rate of change.
Response Authority
Which containment actions we are pre-authorised to take on your behalf.
Coverage options include 24/7, scoped during onboarding.
Next step
Start with a scoping conversation.
Thirty minutes is usually enough to establish whether there is a fit, what shape an engagement would take, and what you'd need internally to support it.
- 1Tell us about your environment
- 2We scope what's actually needed
- 3You get a written assessment plan