Proactive engagement / 01
A deep technical assessment of the Security Operations Center, service by service. What each one actually delivers, and where investment would change the outcome.
Most SOC reviews stop at documentation, at compliance with a regulatory framework such as FINMA or SAMA, or at a reading of high-level process definitions. They establish that something exists on paper. They do not establish whether it works. A team can pass an audit every year and still be unable to say which of its services would hold up on the day it matters.
This engagement examines the design, the execution and the operational reality of each SOC service, to determine how effectively it delivers protection and value. It is not a maturity checklist. It is a technical assessment carried out at configuration level, by someone who has run incidents in environments like yours.
The objective is not the score. It is that the people accountable for security leave the engagement able to state three things: where each service stands today, what risk the discovered gaps actually carry, and how to close them so the money already committed to security returns more than it does now. Precise enough to take to a board, and to defend once you are there.
These are different questions, and almost every SOC review answers only the first. A policy can be current, a tool can be licensed, a process can be documented, and the service built from them can still fail the first time an adversary tests it. The gap between the two is where this assessment lives. Against a determined actor a service has to be built for resilience, and no single SOC service should be a point of failure for the whole defense.
People, process, technology, and SOAR where it is in play, are each judged by one question: what outcome does this service produce. A component is not assessed for existing. It is assessed for what it contributes to the service that depends on it.
A set of documents speaks volumes in the right hands. The people reading them have built and run these services over decades, so the distance between what a document claims and what the service does is visible on the page.
All of the security documentation, from governance down to technical standards, playbooks and the reports written after real incidents. Every log source, and the logic behind each use case in log management and threat detection.
How every service is measured
All four are weighted, and not equally. Strategy and execution carry the most, because a service has to be well-defined and consistently delivered before anything else about it matters.
01
Whether the business requirement was read correctly and turned into a service with a stated mandate and objectives. Then roles and responsibilities, and the operating model that decides what the team does itself and what it makes sense to send outside.
Processes carry the most weight here, then tool selection, because a service is designed before it is bought. Design covers the delivery and operating models, and knowing which parts of the standard guidance, NIST Special Publications among them, are worth adopting and how to adapt them to this environment. Weighted near the top with execution: a service nobody has defined cannot be delivered consistently, and everything measured afterwards inherits that ambiguity.
02
What actually gets done, past the processes and the documentation. Tools decide part of it: whether their features match the objectives, and how much of their potential is genuinely used rather than licensed. SOAR belongs here, an enabler across hunting, response and log management, and the mature teams are the ones getting the most from it. Skills decide the rest: a tool is an enabler only in the right hands.
The heaviest of the four. The subject is what the team produced: playbooks, standards, incident documentation, the quality of the lessons learned. Coverage is the other half: effort aimed at what matters, not at what is easy. Retention that cannot support a hunt or an investigation. Offensive testing aimed at Active Directory while the crown jewels go untouched. Hunts that duplicate monitoring instead of the threats nobody is detecting.
03
How much the wider defense actually gains from this service. The test is balance. It fails when nobody consumes what it produces: hunting that never reaches incident response, investigations that yield no lessons. It fails just as surely when it over-delivers: logs nobody queries, intelligence nobody reads, tools nobody opens.
Cross-team alignment, responsiveness and automation are what make that balance possible. It shows up in the handovers: detection to response, response to recovery, the SOC to the business. Much of what looks like a detection failure turns out to be a handover nobody owned. Weighted lower, deliberately, and not because it matters less in a mature program: it is a lagging indicator, meaningful only once strategy and execution exist.
04
If you cannot measure a service you cannot improve it. So the question is what gets measured, who reads it, and whether any of it changes a decision. A count of closed alerts says nothing about whether the right ones were closed. A metric nobody acts on is reporting rather than feedback.
Metrics have to be relevant and insightful enough to show patterns and trends, and they belong at every step of the value delivery chain, covering tools, processes and people. Weighted lowest of the four because good metrics tend to follow from good design, so their contribution to the overall picture is more limited than the other three dimensions.
Every service is scored on all four axes, forty judgments in total, and those roll up into the two lines below. Maturity is where the service is today. Capability is what it could reach with the people, process and tooling already in place, without buying anything.
How an engagement runs
Read it left to right. The first three steps collect what is actually there, over about a week. The fourth turns it into scores and a report, and takes three. The fifth closes what the first four found, and it is a separate decision you make once you have seen the findings.
Sector-relevant threat actors, attack patterns and abuse scenarios are identified first, so the evaluation is anchored to what the organization will actually face.
Everything scored later is scored against this, not against a generic model.
Full-spectrum review of the documentation the SOC actually uses, alongside configuration-level validation of the key controls: logging, EDR, SIEM and incident management tooling.
This is the step that separates this engagement from a document review.
Deep-dive discussions with technical and functional owners to establish how each service delivers value and how it interacts with the business.
Analysts usually know exactly where the weaknesses are. The interviews are where that gets written down.
Every service is scored on all four axes and compiled into executive and technical reports, with a prioritized capability uplift roadmap.
Mapped to the applicable regulatory framework where one applies.
Documentation is developed against the findings, then explained through structured walkthroughs so service owners can apply it and evolve it.
Deliverables are designed to support Level 4 maturity: optimized, well-integrated operations.
What you receive
Every score states what was observed, what it supports, and the confidence attached to it. Where the evidence does not settle a question, that is written down.
Phase three
An assessment that ends at a report puts the hardest part back on the team that was already short of time. Phase three writes the material and runs the sessions with the teams who have to implement it, so the change actually holds.
The list above is indicative. What gets written is decided by what the assessment found, not by a fixed catalog.
Who this is for
Regulatory mapping
Scoping starts with a conversation, not a questionnaire. If a SOC assessment is the wrong instrument for the question you actually have, the consultant says so on the call.
The method, in the open
NEXT / RELATED SERVICE
Compromise AssessmentWhen the question is whether the gaps have already been used.
NEXT / SCOPING
EngageDescribe the situation. The call is with the consultant who would run the assessment, not a salesperson.
