Emergency incident response: [email protected]
GRC&Security

SIEM & SOC

Built a SOC supporting 900 enterprises.
Now we help you decide on yours.

The principals of GRC & Security established, operated and grew a Security Operations Centre to 900 enterprise customers until its acquisition. We use that experience to help leadership decide what to log, which SIEM to run, how to staff or source a SOC and where AI belongs in its procedures.

Four decisions that depend on each other

Logging, SIEM and SOC operations are among the largest recurring costs in a security budget, and most organizations decide on them one at a time. A SIEM is bought before anyone has agreed what must be logged, and a SOC is staffed before anyone knows how many alerts it will face. The organization then pays to store and process data that no requirement calls for, while records that an investigator or auditor needs are missing, and leadership has no clear view of what the spending buys.

We treat the 4 decisions as one line, in the order in which each constrains the next. What you must log determines what the SIEM ingests and what it costs. The SIEM and its detection content determine the alert volume that your SOC handles. The alert volume determines how many people you need, and how much of their routine work AI can take on. Each step ends with a baseline and measures, so that every decision can be reviewed against evidence.

  1. 1

    Logging requirements

    What must be recorded, kept and protected, and which obligation requires it.

  2. 2

    SIEM

    The platform that meets those requirements, starting with the one you already own.

  3. 3

    SOC operating model

    Establish, improve, bring in-house or outsource.

  4. 4

    AI in operations

    Routine work automated under governance you define.

900Enterprise customers supported by the SOC that our principals established, operated and grew until its acquisition.
90%+In our experience, using AI to pre-assess alerts often reduces the need for human review by more than 90%.
ZeroReseller arrangements, commissions or kickbacks from the vendors and service providers we evaluate. Our advice is vendor-neutral.

Step 1

Logging requirements and central log management

Most logging gaps surface during an incident or an audit, when it is too late to collect what was missed. We work out which systems must log, what each must record, how long records must be kept, who may read them and which standards or contracts impose each requirement.

The register draws on the same mapping as our unified framework. Each logging requirement traces back to the standards, regulations and contracts that impose it, so that one logging control answers all of them and an auditor can see why each record exists. The crosswalk shows how the mapping works.

We then design central log management around a central log facility (CLF) that collects from every source your standards and investigations depend on. The design covers source onboarding, time synchronization, integrity protection, retention tiers and access control, so that the records are complete, trustworthy and available when an investigator or auditor asks for them.

Log volume drives both storage and SIEM ingest cost, so the design also states what you can leave out. Collecting everything at full fidelity is rarely required and rarely affordable; the requirements register tells you which sources earn their cost.

What you receive

  • A logging requirements register that maps each log source and field to the standard, regulation, contract or investigation need that requires it, with retention period and access rights.
  • A CLF design covering collection, transport, storage tiers, retention, integrity and access, sized against your current and projected log volumes.
  • A gap assessment of current logging against the register, with a prioritized remediation plan.

The business case

Where the return comes from

  • Lower storage and SIEM ingest cost, because nothing is collected that no requirement calls for.
  • Records that are complete and available when an investigator or auditor asks for them.
  • One logging control that answers several standards, instead of separate evidence for each.

Costs and risks

  • The effort to inventory every source and map it to its requirements.
  • Cutting a source too aggressively removes evidence you later need, so every exclusion needs a recorded rationale.
  • Weak time synchronization or integrity protection makes records unusable as evidence.

Specific measures

  • Required log sources onboarded and reporting, against the register.
  • Log-related audit findings.
  • Ingest and storage volume and cost against the design.
  • Sources that have gone quiet or changed format.
  • Time to produce the records for an investigation or audit request.

Step 2

SIEM options, needs and alignment

A SIEM is only as useful as the requirements it was chosen against. With the logging requirements in place, the SIEM can be chosen, sized and tuned against them rather than against a vendor's feature list. We define the SIEM requirements before any product is considered: data volumes, retention, detection coverage, reporting obligations, integration with the tools you already run and the skills of the people who will operate it.

We then assess the options against those requirements, including the platform you already own. Many organizations are paying for a SIEM they use at a fraction of its capability, and the right answer is often to configure, tune and extend what is in place rather than replace it. Where replacement is justified, the requirements become the evaluation criteria and the acceptance tests.

As with our GRC and security software procurement work, our advice on tool selection is vendor-neutral. We hold no reseller or referral arrangements with SIEM vendors.

What you receive

  • A SIEM requirements specification covering ingest volume, retention, detection use cases, reporting, integrations and operating model.
  • An options assessment that scores candidate platforms, including your current one, against the specification and states the total cost drivers for each.
  • An alignment plan for the chosen platform: detection content to deploy, sources to onboard in order, and the measures that confirm that the requirements are met.

The business case

Where the return comes from

  • Avoiding a replacement you do not need, by getting more from the platform you already own.
  • Where replacement is justified, a platform chosen against your requirements rather than a vendor's feature list.
  • Detection content aligned to your own risks and obligations.

Costs and risks

  • Migration effort, and running 2 platforms in parallel during the transition.
  • Detection coverage lost during a migration if content and sources are not moved in a planned order.
  • Licence models that scale with ingest volume.
  • The skills needed to operate and tune the platform.

Specific measures

  • Detection use cases live against the specification.
  • Acceptance tests passed.
  • Licence utilization and ingest cost per GB.
  • Time to onboard a new log source.

Step 3

SOC operating model

Whether to build a SOC, fix the one you have, bring it in-house or hand it to a provider is a decision about cost, staffing, coverage and control. The cost drivers are the same in every case: analyst time per alert, false-positive volume, the number of people needed for 24x7 coverage once shifts, leave, training and turnover are counted, and licence and ingest costs that scale with log volume. The risk drivers are time to detect and time to respond, because both determine how far an incident spreads before anyone acts.

We set the options against your requirements, model where each one's return comes from and help you choose. Each engagement ends with a baseline and a set of measures, so that the decision can be reviewed against evidence rather than impressions.

Establish

You have no SOC, and monitoring obligations that you cannot yet evidence.

What we do: Scope, staffing, tooling, processes and metrics for a new SOC where none exists.

Return: Detection and response where there is none today.Main risk: Staffing cost and a long ramp to useful coverage.

Where the return comes from

  • Detection and response capability where there was none, which shortens time to detect and time to respond from the current state of finding out from a third party or from the damage.
  • Satisfying monitoring obligations in standards, regulations, cyber insurance and customer contracts that the organization currently cannot evidence.
  • Context: analysts who know your environment distinguish real anomalies from normal business faster than an outsider can.

Costs and risks

  • Staffing is the dominant cost. Continuous coverage needs several analysts per seat once shifts, leave, training and turnover are counted, and recruiting and retaining them is difficult.
  • SIEM licensing and ingest scale with log volume; an undisciplined onboarding plan inflates cost before it adds detection.
  • A new SOC takes time to reach useful detection coverage, and it carries the risk of building the wrong thing: too many alerts, too few people, and no process for what happens after an alert fires.

Specific measures: Shift coverage attained against the 24x7 plan, including vacancies, and ingest cost per GB against the sized design. See also the common measures.

Improve

You have a SOC, but alert volume, detection gaps or cost are limiting it.

What we do: Review detection coverage, escalation paths, shift model, tooling and reporting in an existing SOC, and fix what limits it.

Return: Lower cost per alert and fewer gaps, without adding staff.Main risk: Tuning that suppresses real events.

Where the return comes from

  • Lower cost per alert: tuning out false positives and consolidating duplicate alerts returns analyst hours without adding staff.
  • Closing detection gaps the current SOC does not know it has, which reduces time to detect for the attacks most likely to hit you.
  • Better use of the SIEM you already pay for, which postpones or avoids a replacement.
  • Reporting that gives management a defensible picture of what the SOC catches, misses and costs.

Costs and risks

  • Analyst and engineering time to retune detections and rebuild runbooks while continuing daily operations.
  • Tuning that is too aggressive suppresses real events; every suppression rule needs a documented rationale and a review date.
  • Improvements decay without an owner for detection content and metrics.

Specific measures: Alerts closed as benign per analyst shift, before and after tuning. See also the common measures.

Internalize

You outsource today and want control of detection, data and knowledge.

What we do: Plan and execute the transition from an outsourced service to your own team.

Return: A team that knows your business, at a cost you control.Main risk: Coverage gaps during transition, and analyst attrition.

Where the return comes from

  • Control over detection content, priorities and data: you decide what is monitored, and you keep the knowledge when staff change.
  • Context: an internal team learns the business, which lowers false positives and shortens investigation time compared with a provider working from a generic playbook.
  • Over time, a service fee that rises with log volume and asset count is replaced by a staffing and tooling cost you control.

Costs and risks

  • Hiring, training and retaining enough analysts for the coverage model you choose, with the attendant risk that attrition leaves gaps.
  • Tooling, licensing and engineering effort that the provider previously bundled into the fee.
  • A transition period in which coverage is at risk, particularly if the outgoing provider's exit terms are weak or the handover of detection content and historical data is incomplete.

Specific measures: Coverage continuity through the transition, week by week; time to detect and respond compared with the provider's attained figures, not its contractual targets; positions filled against plan and analyst retention. See also the common measures.

Outsource

You need 24x7 coverage without building a team to provide it.

What we do: Define the service you need, evaluate candidate partners and set the terms that you will hold them to.

Return: Continuous coverage for a predictable fee.Main risk: A contract you cannot evaluate or leave. Accountability stays with you.

Where the return comes from

  • Round-the-clock coverage without hiring the analysts that continuous shifts require.
  • Staffing and tooling cost converted into a predictable service fee, and the provider carries the recruitment, retention and training burden.
  • Access to detection content and threat intelligence developed across the provider's customer base.

Costs and risks

  • A provider knows your environment less well than your own staff, so false positives and escalations that your team must still investigate remain a cost on your side.
  • Weak scope definitions, SLAs that measure the wrong thing, and absent exit terms lock the organization into a service it cannot evaluate or leave.
  • Accountability for incidents stays with you regardless of the contract. The provider detects; your people still decide and act.

Specific measures: SLA attainment on time to acknowledge, triage and escalate, verified by sampling; service fee per monitored asset or per GB ingested, tracked against growth. See also the common measures.

How we help you choose

We build the comparison from your actual environment: the sources that must be monitored, the coverage model you need, the staff you can realistically hire and the contracts and standards that bind you. For each option we set out the cost drivers, the risks and the measures we track, so that the decision can be defended to a board, an auditor or an insurer.

For outsourcing we also run the partner evaluation: requirements, request for proposal, scoring, reference checks and contract terms covering scope, SLAs, reporting, data ownership and exit.

Step 4

AI in SOC operations

If you run your own SOC, the volume of logs and alerts is the constraint that drives everything else, and most of that volume is routine. AI can take on much of the routine at each stage of the pipeline, provided that the organization decides in advance what it may do alone, what it may only propose, and how its behaviour is tested and recorded. We design that pipeline and the governance around it, so that AI is used where it adds value and its running costs stay in proportion to that value.

  1. 1

    Ingestion and normalization

    AI parses, normalizes and labels log records as they arrive, including formats that a rule-based parser would reject or mis-map. It flags sources that have gone quiet or changed format, which is where silent coverage gaps begin. Analysts stop writing and maintaining parsers by hand and the CLF receives cleaner, more consistent data.

  2. 2

    Enrichment and correlation

    AI attaches context to each event: asset ownership and criticality, user role, known vulnerabilities, threat intelligence and recent activity on the same host or account. It groups related alerts into a single case so that one intrusion does not arrive as many unconnected tickets. The analyst opens one case with the context already assembled.

  3. 3

    Triage and prioritization

    AI scores each case against your environment and your detection priorities, suppresses patterns that have been confirmed as noise, and places the remainder in a ranked queue. This is where cost per alert falls and where the risk is highest, because a suppression rule that is wrong hides exactly what you need to see. Suppression is bounded: every rule has a rationale, an owner, a review date and a sample that an analyst periodically checks.

  4. 4

    Investigation support

    For each case that reaches an analyst, AI drafts a first-pass summary: what happened, in what order, on which assets, with which accounts, and which evidence supports each statement. It proposes the next queries to run and the related events to check. The analyst starts from a summary and verifies it, rather than reconstructing a timeline from raw records.

  5. 5

    Case and report drafting

    AI drafts case notes, closure rationales, incident reports and management summaries from the recorded evidence and analyst decisions. The analyst edits and signs. Documentation that was previously written at the end of a shift, or not at all, is complete and consistent, which matters when the regulator, insurer or lawyer asks for it.

What stays with analysts

AI prepares the case. The decisions that carry consequences stay with people:

  • Incident declaration: whether an event is an incident, and its severity.
  • Containment: authorizing isolation, account suspension and other response actions.
  • Closure: signing off each case and the rationale for closing it.
  • Oversight: reviewing samples of what AI suppressed or scored low.
  • Detection content: owning the rules, the tuning and the suppression list.

With routine triage handled, analyst time goes to the work that needs experience: active investigation, threat hunting and improving detection content.

AI shortens the path to these decisions; it does not take them.

How we govern it

  • Decision rights: a written matrix stating which actions AI may take alone, which it may only recommend, and which require an analyst, with the threshold for each.
  • Testing before deployment: every model, prompt or rule is tested against known-good and known-bad cases, including attack scenarios that resemble the noise it has been told to suppress.
  • Drift monitoring: suppression rates, score distributions and escalation rates are tracked, and a shift outside the expected band triggers review before it reaches an incident review.
  • Records: every automated decision, including what was suppressed and why, is logged so that you can show how triage behaved on any given day and correct it when it is wrong.
  • Human oversight: sampled review of automated decisions, with findings fed back into the rules and models.

It is the same governance discipline we apply to AI anywhere else in an organization.

The business case

Where the return comes from

  • Analyst and internal team time moves from routine triage to active investigation, security operations and threat hunting.
  • Time to detect and time to respond fall, because cases arrive correlated and summarized.
  • Documentation that management, auditors and insurers can follow.
  • AI running costs kept in proportion to the value they add: rules and filters handle what does not need judgement, a model sees only the events that do and only the fields relevant to the decision, and smaller models handle routine classification while larger ones are reserved for investigation and drafting.

Costs and risks

  • The engineering and governance effort to build and maintain the pipeline, and the discipline to keep testing it.
  • A suppression rule that is wrong hides exactly what you need to see.
  • Model behaviour that drifts over time.
  • AI usage costs that scale with log volume when every event, or every field, is sent to a model, and can grow faster than the analyst time they save.

Specific measures

  • Error rate found in sampled suppressions.
  • Proportion of first-pass summaries accepted without material correction.
  • Drift indicators within their expected bands, and the number of rules corrected as a result of review.
  • AI cost per alert and per case, and the share of events that reach a model.

Across all 4 steps

How you will know it worked

Each step above lists the measures specific to it. The measures below apply to all of them: we baseline them at the start of every engagement, set targets for them in the decision pack, and you can report against them from then on. Each group answers a different reader. Cost and risk give leadership and the board a view of what the spending buys; quality gives the SOC manager the evidence needed to argue for resources.

Cost

What the security operation costs to run. For the CIO, CTO and finance.

  • Cost per alert handled.
  • Analyst hours per incident.
  • Log ingest and storage cost per GB.
  • Total operating cost or service fee, tracked against growth.

Risk

How quickly and how completely threats are caught. For the CISO and the board.

  • Mean time to detect.
  • Mean time to respond, end to end, including internal response after escalation.
  • Coverage of required log sources and detection use cases against the requirements register.
  • Detection coverage against a defined set of attack techniques.

Quality

How well the SOC spends its time. For the SOC manager and analysts.

  • False-positive rate.
  • Escalation accuracy: the proportion of escalations that were real events requiring action.
  • Backlog age: alerts older than the triage target.
  • Suppression rate, with the error rate found in sampled suppressions.

How we work with you

Every engagement is scoped to the client. You can engage us in 3 ways.

Fixed-fee assessments

Best when: You have a specific question and need a known cost.

What you get: A defined scope, timeline and price, with deliverables such as a logging gap assessment, a SIEM options assessment or a SOC baseline.

Custom-scoped engagements

Best when: The work runs from requirements through decision to implementation.

What you get: A decision pack and implementation support, scoped and priced to your objectives.

On-demand retainer

Best when: Decisions, reviews and questions arise over time rather than all at once.

What you get: Hourly access to our principals, as and when you need it.

  1. 1

    Baseline

    Current logging, platform and operations, measured against the common measures.

  2. 2

    Requirements

    From your standards, contracts, risks and investigation needs.

  3. 3

    Options

    Cost drivers, risks and return for each option.

  4. 4

    Decision pack

    A recommendation leadership can defend to a board, an auditor or an insurer.

  5. 5

    Implementation support

    Optional: onboarding, tuning, partner transition and measurement.

What we need from your teams: read access to configurations and log samples, your current SIEM and SOC metrics, and time with the people who run them. We schedule interviews and data collection around operations.

Contact us

Talk to us about where your logging, SIEM or SOC stands today, and which of the measures above you can report on now.

Contact us