Cybersecurity
The technology domain this engagement operates — capabilities, architectures and the full picture.
Managed SOC
Detection and response as an operated service, not a console you inherit.
The operating model
A managed SOC takes the detection estate you have — or the one we build with you — and runs the operation on top of it: monitoring, triage, investigation, containment within agreed authority, and the tuning loop that keeps the whole thing worth reading. The technology pages describe what gets deployed; this page describes what it is like to be a client.
The honest framing is that a SOC is a staffing and process problem wearing a technology costume. Alerts arrive around the clock; judgement, authority and follow-through are what turn them into outcomes. That is what you are buying here, and the coverage window — business hours or continuous — is agreed at onboarding to match your risk, not asserted in a brochure.
The rhythm of the engagement
What actually happens — by day, by week, by month, by quarter. If a provider cannot describe this, they are selling a tool, not a service.
Daily
Alerts triaged as they arrive within the agreed coverage window; confirmed incidents worked to containment under the authority matrix; a same-day summary for anything that reached you.
Weekly
Tuning review: what fired, what was noise, which detections were adjusted and why. False-positive suppressions are logged, never silent.
Monthly
Service review with your named contact: incident narratives, detection coverage changes, open risks, and the actions each side owes.
Quarterly
Threat review against your sector and estate changes, a purple-team style exercise on one chosen scenario, and re-validation of the escalation contacts and authority matrix.
How escalation works
Severity definitions and response objectives are agreed at onboarding and written into the runbook — they are commitments made to you, not marketing figures published here.
Severity 1 — active compromise
Confirmed malicious activity with business impact. Immediate containment under pre-agreed authority; your named contacts engaged by phone, not ticket; a written timeline follows while the incident is still open.
Severity 2 — probable incident
Strong indicators without confirmed impact. Investigated ahead of all routine work; containment proposed to you before action unless the runbook pre-authorises it.
Severity 3 — suspicious, unconfirmed
Worked within the coverage window in arrival order; closed with a finding either way, because an alert closed without a reason is how blind spots are taught.
Onboarding, phase by phase
Sequenced so that value starts before the last phase finishes. Dates go into the plan we agree together; phases are what the plan is made of.
Access and telemetry
Read access to the detection estate, log source inventory, and the gap list — what we can see, what we cannot, and what that means until it changes.
Baseline and tuning
Two to four weeks of observing your normal before enforcement judgements: suppressing your own software's noise, learning the month-end shape, recording what 'quiet' looks like.
Runbook and authority
Escalation contacts, severity definitions, and the containment actions we may take without waking you — signed by both sides before the first enforced response.
Live operation
The rhythm above begins, and the first monthly review measures the onboarding itself: coverage achieved against the gap list from phase one.
What we run, and what stays yours
A managed engagement fails quietly when this table was never written. Ours is agreed before the service starts.
| Area | NexMena | You |
|---|---|---|
| Triage and investigation | Run end to end within the coverage window | Nothing routine — you hear about outcomes |
| Containment | Execute within the pre-agreed authority matrix | Decisions the matrix reserves: production shutdowns, legal escalation, ransom posture |
| Asset and identity truth | Consume and flag staleness | Own it — detection quality is capped by inventory quality, and only you know what exists |
| Risk acceptance | Recommend, with the evidence | Decide — accepting a risk is a business judgement no provider should make for you |
What you receive, and when
Reporting exists so you can judge the service without asking for a meeting.
- Same-day incident summaries for anything that reached escalation, written to be read by a manager, with the technical timeline attached for your engineers.
- The monthly service report: incidents, detection changes, coverage against the gap list, and the actions register — yours and ours, with ages.
- The quarterly threat review: what changed in your estate and your sector, what we adjusted because of it, and what we recommend next with the reasoning shown.
Questions we are asked
Is the coverage around the clock?
The coverage window is agreed at onboarding — continuous coverage and business-hours-with-on-call are both real options with honestly different costs. What we will not do is print a coverage claim on a website; it goes in the contract, where it is enforceable.
Whose tools does the SOC run on?
Yours by preference. An existing SIEM and EDR estate is an asset, and the onboarding gap list tells us whether it suffices. Where something is genuinely missing we say so with the reasoning, and the implementation is a separate, visible decision — never bundled in quietly.
Can you contain incidents without asking us first?
Only within the authority matrix signed at onboarding. Isolating a workstation showing a confirmed ransomware pattern is typically pre-authorised; shutting down a production server is typically reserved to you. The matrix is revisited quarterly because the right answer changes as trust builds.
What happens to alerts outside the coverage window?
If your window is not continuous, arrivals queue and are triaged at window open, with Severity 1 indicators promoted to the on-call path if you have taken that option. This is exactly the trade the coverage decision makes, and we would rather you make it with open eyes than discover it during an incident.
How is this different from your SOC service page?
The service page describes the delivery model in general. This page is the cybersecurity-specific engagement: the rhythm, escalation and ownership model above are what a security operations client actually signs. If you are comparing providers, compare these tables — not the technology lists.
What do we need to staff on our side?
One named contact with authority to make the reserved decisions, and engineering time to action remediations we cannot reach — patching we do not own, changes in your applications. A managed SOC removes the watching, not the owning.
Continue reading
Managed Services
The delivery model in general: how managed engagements work across every domain.
SOC
Start with an assessment
The fastest way to a useful answer is a short, scoped look at what you already have.