SOC Design & Security Operations Architecture
The operating model for detection and response — telemetry planning, SIEM architecture, alert pipeline, case management, escalation paths and the playbooks that turn an alert into a decision rather than a notification nobody owns.
Verified Solvex Specialist
Verified by SolvexDirect specialist contact for Solvex engagements
What this means. An authorized Solvex administrator registered and approved this exact public identity. What it does not. Solvex has not inspected the account on the platform, and this is not the platform's own verification.
Solvex specialists never ask for your passwords, recovery phrases, one-time codes, or payments to a personal account. Work, scope and invoices are agreed in writing through the official channels on this site.
What's covered
- Target operating model: people, process and technology, sized to your reality
- Telemetry strategy — what to collect, what to skip, and what it costs
- SIEM and detection platform architecture
- Alert pipeline design: enrichment, correlation, deduplication and routing
- Incident workflow, severity model and escalation authority
- Case management and evidence-handling process
- Playbook development for your most probable incident types
- Detection coverage mapping against MITRE ATT&CK
- KPIs, retention policy and reporting cadence
What you receive
- SOC target operating model document
- Telemetry and log-source plan with cost implications stated
- SIEM architecture and data-flow design
- Incident workflow, severity matrix and escalation paths
- Playbooks for the incident types most likely in your environment
- ATT&CK coverage map showing current and target state
- Staged implementation roadmap
Evidence and reporting
How the work is kept honest- Evidence, frozen at issuanceFindings tie to something observed. When the report is issued, the evidence behind it is frozen in the same transaction and cannot be edited afterwards.
- A signed reportAn Ed25519 signature covers both the report content and the delivered file. Alter a byte of either and verification fails.
- Written scope firstAdvisory work runs to a written scope agreed before it starts, so what you receive is what was agreed.
Anyone holding a Solvex report can verify it publicly without seeing its contents.
Our boundaries
What this engagement does not do, stated before it starts.
- This is design and architecture — Solvex does not staff a 24/7 watch floor as part of it
- Platform licensing and infrastructure costs are yours and are not resold by us
- Implementation is a separate engagement unless explicitly included
- Detection coverage depends on telemetry you can actually collect and retain
How this engagement runs
- 01
Intake
Tell us the system, the goal and the constraints. If the work is not a good fit, we say so before anyone is invoiced.
- 02
Scope and authorization
Written scope and signed authorization before anything is touched. Security testing runs only against systems you own or are contractually entitled to have tested.
- 03
Investigation or build
Specialists matched to the work. Findings are proven by hand — scanner output is a lead, never a finding.
- 04
Evidence
Every finding ties to something observed. When a report is issued, its evidence is frozen in the same transaction, so what backed the report cannot change afterwards.
- 05
Delivery
A signed report: an Ed25519 signature over both the content and the file, with a short verification reference you can read down a phone.
- 06
Verification and retest
Anyone holding the report can verify it publicly without seeing its contents. Fixes are retested as part of the engagement — “fixed” means we confirmed it.
Questions we are asked
- Do we need our own SOC?
- Often not. Below a certain size, a well-designed alert pipeline into a small team with good playbooks and a competent MDR partner beats an under-resourced in-house SOC that cannot cover nights. Part of this engagement is telling you honestly which one your organisation is.
- Our SIEM costs are out of control. Can this help?
- Usually, and substantially. Most oversized SIEM bills come from ingesting everything because nobody decided what detection actually requires. Telemetry planning against real detection objectives frequently cuts volume while improving coverage.
- How long before the SOC is useful?
- The first genuinely useful detections typically land in weeks, not months, because a handful of high-value log sources carry most of the early value. Full coverage is a programme measured in quarters, and we sequence it so value arrives early rather than at the end.
Related services
SOC / Detection
SOC Maturity & Detection Coverage Assessment
An honest measurement of what your monitoring can actually see — telemetry gaps, alert quality, ATT&CK coverage, false-positive burden and triage reality — producing a picture of your true detection surface rather than your intended one.
SOC / Detection
Managed Detection Engineering & SOC Enablement
Detection-as-code delivered as an ongoing engineering practice — version-controlled Sigma and platform rules, telemetry onboarding, tuning against real alert data, and the lifecycle that stops detections rotting the moment the environment changes.
DFIR & Forensics
24/7 Incident Response Retainer
When an incident hits, every minute counts — and you don't want to be finding a responder then. A retainer gives you a pre-agreed expert team on standby, guaranteed response times, and people who already know your environment.