Hoop Cyber

About Hoop Cyber

https://www.hoopcyber.com

Posts by Hoop Cyber:

August 29 2026

SOC Fatigue, Revisited: How AI is Contributing to Burnout

Our earlier post on SOC burnout argued that analyst fatigue comes mainly from repetitive data work rather than the complexity of the threats themselves and made the case for automating the tedious layer of the job rather than the analyst. The industry research behind that argument was already a few years old even then.

A Ponemon Institute study run with Devo, surveying 554 IT and security practitioners at organisations with a SOC, found 65% had considered changing careers or leaving their job over burnout related pain points. A 2022 Tines survey of 468 US based analysts found 71% experiencing some level of burnout and 64% saying they were likely to switch jobs within the year. Both studies predate the current wave of AI tooling in the SOC, and I have not been able to find an equivalent large scale, independent study measuring burnout specifically among analysts working in AI assisted SOCs today. Over a year on from our last post, with AI tools now sitting inside a growing number of SOC workflows, it is worth asking what has changed, and what has not, while being honest that the comparison below is reasoned rather than measured.

What Changed When AI Arrived

The promise was straightforward. Hand the repetitive layers of the job, meaning data collection, enrichment, correlation and first pass triage, over to automation and AI tooling, and give analysts back time for the investigative work that drew them into the field. Where that promise has landed, teams report less time lost to manual data wrangling and faster first response on high confidence alerts. That is a genuine gain, and it matches what the earlier post predicted.

What is harder to find is solid, independently verified data on how much SOC wide burnout has fallen as a result. Vendor surveys report improvement, which is what you would expect from a survey run by a vendor selling the tool. Independent, large sample research on burnout specifically among analysts using AI assisted workflows is thinner than the marketing around it. Treat any single statistic on this topic, including ones from HOOP Cyber’s own earlier posts, as directional rather than settled, and measure your own team rather than relying on an industry average.

The New Sources of Fatigue

Removing one source of fatigue does not always mean removing fatigue itself. Teams using AI more heavily in triage report a different kind of tiredness taking its place.

Oversight fatigue is the most reported version. An analyst reviewing 50 AI generated triage decisions a day still must apply judgement to each one, and verifying a machine’s reasoning carries its own mental cost, even when the machine is usually right.

Confidence calibration is a related problem. Analysts need to build an accurate sense of when to trust a tool’s output and when to override it, and that sense takes months to develop. Until it does, teams report either over trusting the tool, which creates risk, or double checking everything, which recreates the manual workload the tool was meant to remove.

There is also a quieter concern around skills. If AI tools handle a growing share of first pass triage, junior analysts get fewer reps at the pattern recognition work that used to build expertise over their first 2 years. That is not fatigue in the traditional sense, but it is a workforce risk worth naming alongside it.

What to Measure Now

If your earlier burnout metrics were built around alert volume and false positive rate, add a second layer: time spent reviewing and correcting AI output, how often analysts override an AI recommendation and why, and how confident junior analysts report feeling in their own judgement compared with 6 months earlier. None of these need to be complicated to track, and they will tell you more about where fatigue has moved to than a repeat of the original burnout survey.

The tools have changed since the first post. The underlying question has not. Give analysts back time for the work that made them want to do this job in the first place, and keep checking whether that is happening, not assuming it is because the dashboard says alert volume is down.

Ready to Modernise?

HOOP Cyber helps security teams audit their data estate, design the routing and normalisation that sits behind it, and rebuild security operations around a data architecture they control. If you cannot currently produce the three pieces of information at the top of this article, that is where we would start. Get in touch via .

August 29 2026

Board Level Reporting for the SOC: What Metrics Should You Always Include?

Hoop Cyber Blogs, HOOP Latest News

Most SOC teams can produce a report full of numbers. Alert counts, mean time to detect, mean time to respond, ticket volumes, false positive rates. None of it means much to a board or an audit committee unless someone translates it first. Boards do not want to see your dashboard. They want to know whether the organisation is more exposed to risk than it was last quarter, what happened when something went wrong, and where money or people are needed to close a gap.

What the Board Is Actually Asking

A board question rarely sounds like a security question. “Are we secure” is really “has our exposure changed”, “what would a serious incident cost us” and “are we spending in the right places”. A SOC report built around operational metrics answers a different question: how busy was the team at the time? Both are valid, but only one belongs in a board pack.

Translating the Metrics You Already Have

You do not need new metrics to report to the board. You need a different framing of the ones your team already tracks.

Detection and response times work best as a trend, not a single figure. A board does not need your exact mean time to detect in minutes. It needs to know whether that time is moving in the right direction and what has driven the change, whether that is new tooling, a process fix or a headcount decision.

Alert volume and false positive rate translate into cost and capacity. Framed correctly, a high false positive rate is not a technical detail. It is a statement about how much of your security spend goes toward noise rather than genuine investigation, and what those costs are in analyst time.

Incident counts need a severity split and a policy comparison. A rising number of low severity incidents contained well within your target timeframes is a different story to a small number of high severity incidents that ran past your response targets. Boards care about the second far more than the first.

Coverage and visibility gaps translate into residual risk. If a part of the estate sits outside current monitoring, say so plainly and attach a cost to closing it. That is the kind of line that gets budget approved.

A Short Framework for Every Report

Every board report on security operations should answer 4 questions in this order: what changed since the last report, why it changed, what it costs if left unaddressed and what decision the board is being asked to make. If a slide or a paragraph does not answer one of those 4 questions, it is operational detail that belongs in a different meeting.

Resist Death by Dashboard

The instinct when asked to report upward is often to add more charts. Resist it. A board pack with 20 metrics gets skimmed. A board pack with 4 metrics, each tied to a decision, gets read and acted on. Build the report once, agree the format with your audit committee or board sponsor, and reuse the same structure every quarter. Consistency is what lets a board spot a genuine change rather than a formatting difference.

None of this replaces the operational reporting your SOC already does day to day. It sits alongside it, translated for a different audience with a different set of questions. Get that translation right once and the quarterly report becomes far less work to produce, not more.

August 29 2026

After NIS2 and DORA: What Comes Next?

Hoop Cyber Blogs, HOOP Latest News

NIS2 and DORA have dominated compliance conversations in security operations for 2 years. NIS2 has technically been enforceable law since October 2024 and DORA since January 2025, though both are still settling into practice. A third piece of regulation, the UK’s own Cyber Security and Resilience Bill, is close behind them, and the European Commission has now proposed changes to NIS2 itself. Here is where things stand, and what a security team should be doing about it.

DORA Has Moved from Applicable to Enforced

DORA became applicable in January 2025, giving financial entities and their ICT suppliers a defined rulebook for operational resilience. Through 2026, supervisors have shifted from checking that a framework exists to checking that it works. 2 requirements stand out for scrutiny. The Register of Information, the record every financial entity must keep of its ICT third party contracts, has its second annual submission due on 20 March 2026, and national regulators, including the Dutch central bank, have confirmed the reporting template is unchanged from the previous year, so there is no excuse for treating it as new work. Alongside that, incident reporting is under closer scrutiny, with entities expected to classify a major incident against DORA’s materiality criteria and produce a compliant initial report within hours rather than days.

Coverage of DORA readiness through 2026 has been inconsistent on exactly how many firms have reached full compliance, with different surveys reporting different figures and none of them a clear, verifiable primary source. Rather than repeat an industry wide number here, check your own status directly against the requirements and your national regulator’s published guidance.

NIS2 Enforcement Is Uneven, and Amendments Are Coming

NIS2’s own transposition deadline has already passed. Member states were required to transpose the directive into national law by 17 October 2024, and it replaced the original NIS Directive the following day. That does not mean enforcement is settled. Transposition and enforcement readiness have varied significantly by country, and reporting through 2026 continues to describe national authorities in several member states still building out registration, supervision and enforcement mechanisms nearly 2 years after the nominal deadline.

The bigger news for 2026 is not a new deadline but a proposed rewrite. On 20 January 2026 the European Commission proposed targeted amendments to NIS2 as part of its wider digital simplification package, alongside a related proposal for a new Cybersecurity Act. The amendments would let the Commission set harmonised technical requirements that member states could not add to nationally, introduce an EU wide cyber posture certification that could reduce duplicate audits, expand ENISA’s role in supervising cross border services, and narrow scope in places, including a new small mid cap category for entities under 750 employees and under 150 million euros turnover. The proposal is working through the ordinary legislative procedure, with Parliament and Council negotiation expected later in 2026 and a proposed 12-month transposition period once agreed. None of this is final. If it passes broadly as proposed, it will change what NIS2 compliance looks like in practice, not just when it applies.

The UK’s Own Version Is Close but Not Law Yet

The UK Cyber Security and Resilience Bill, the closest domestic equivalent to NIS2, has cleared every stage in the House of Commons and is now working through the House of Lords. As of late August 2026, it has completed its first and second reading in the Lords and moved into committee stage, with report stage, third reading and Royal Assent still to come. The Bill is not yet law. Once it receives Royal Assent, expect secondary legislation and codes of practice to follow before the detailed obligations, such as expanded scope to cover managed service providers and data centres, take effect. Organisations that wait for Royal Assent before starting work will be behind. The direction of the Bill is settled even if the exact commencement date is not.

What This Means for Your Security Data Strategy

Taken together, DORA, NIS2 and the UK Bill place 2 demands on the same security data infrastructure. Regulators want proof rather than assurance, meaning your logging, retention and incident classification need to produce evidence on demand rather than after the fact. And regulators increasingly hold management personally accountable, which pushes security data from an operational concern into a board level one.

The practical response is not to build 3 separate compliance programmes. It is to build a security data architecture that can answer any one of these frameworks’ questions from the same underlying data, tagged and retained in a way that supports whichever regulator asks first. That is a data architecture decision as much as a compliance one, and it is worth making before the next deadline arrives rather than after.

Ready to Modernise?

HOOP Cyber helps security teams audit their data estate, design the routing and normalisation that sits behind it, and rebuild security operations around a data architecture they control. If you cannot currently produce the three pieces of information at the top of this article, that is where we would start. Get in touch via .

August 11 2026

Volume Without Value – Part Three: Walking Into Renewal With Something To Say

Hoop Cyber Blogs, HOOP Latest News

Sorting out the data architecture changes the renewal conversation before it starts. Here is what is different, and how to tell whether the work delivered.

The first two parts of this series made an argument in two steps. Security data volume grows for reasons unconnected to risk, and no discount fixes that. The way out is to work out which data genuinely needs to sit in the most expensive tier and to route everything else deliberately.

This final part deals with what happens afterwards, which is where the commercial return actually shows up.

What Changes At The Table

Most SIEM renewals are conducted from a position of some weakness. The security team knows its volume is rising, knows it cannot easily predict next year’s figure, and knows that walking away would mean a migration nobody has budgeted for. Those three facts are visible to the other side of the table, and they shape the outcome.

When the data architecture work has been done first, all three change.

You know your baseline, because you have measured it rather than inferred it from an invoice. You know your growth drivers, because you have identified which sources are expanding and why. And critically, you know what proportion of your data genuinely needs to be in that platform at all, which means you can size the commitment honestly instead of buying headroom to cover an uncertainty you have not resolved.

The conversation stops being about the rate and starts being about the scope. That is a considerably better conversation to be having.

Portability Is The Real Bargaining Position

The most valuable outcome of this work is rarely the one anyone puts in the business case.

If security data lands first in storage you own, normalised to an open schema, and is then forwarded to the analytics platform, the platform becomes something closer to a replaceable layer. The cost of moving to a different tool falls, because the data no longer has to be extracted, converted and re-onboarded from a proprietary structure.

That is a genuine change in position, and it does not require you to be planning a move. The fact that a move is feasible is what alters the dynamic. Vendors price and behave differently when switching costs are low, and every security leader who has been through a renewal knows it.

I would be careful about overstating this. Migration is never free, detection content still has to be rebuilt or translated, and analysts still need retraining on a new interface. What changes is the order of magnitude, and the order of magnitude is what determines whether an alternative is credible enough to be discussed.

Measuring Whether It Worked

Cost per unit of data is the obvious measure and it is the wrong one. It rewards the behaviour you are trying to move away from, which is treating all security data as an undifferentiated commodity to be minimised.

A more useful set of measures would include the following.

Total cost of the security data estate, counting platform licensing, storage, egress and the engineering time to maintain it. Moving cost between line items is not a saving and this measure makes that visible.
Detection coverage against a recognised framework, measured before and after. If coverage has fallen, the saving was not a saving.
Number of sources declined or deferred on cost grounds over the period. If this figure has not moved towards zero, the underlying problem has not been solved.
Time to onboard a new source, from request to production detection. This is a good proxy for whether the architecture is actually working.
Analyst time spent on data wrangling during investigations, which is the benefit nobody forecasts and everybody notices.

The second of those is the one to insist on. It is entirely possible to cut the bill substantially and quietly reduce coverage at the same time, and the saving will be reported long before the gap is discovered.

The Twelve Month Picture

A year after this work is done properly, a few things tend to be true.

New data sources get connected on the basis of whether they are useful, because the marginal cost is known and modest. Detection engineers stop treating volume as a constraint on what they can write. The renewal conversation is scheduled rather than dreaded, and the number attached to it is one the security team produced rather than received.

The board level change is subtler. Security spending becomes explicable. A security leader who can account for what the organisation spends on its data estate, why, and what it buys, is in a materially different position when asking for anything else.

A Word Of Caution

This work is not a one off project that concludes. Data sources change, business applications get added, cloud estates expand, and an architecture that was correct in year one drifts if nobody is watching it.

The organisations that hold the gains are the ones that treat data routing as an ongoing operational discipline with an owner, a review cycle and a place on someone’s objectives. The ones that treat it as a cost reduction exercise find themselves having the same conversation three years later, having lost the institutional memory of why the decisions were made the first time.

The bill is the symptom that gets attention. The architecture underneath it is the thing worth fixing.

HOOP Cyber works with security teams on security operations architecture, security data engineering and the cost of running both. If the renewal is coming and the conversation has not started, it is not too early. Get in touch with us via .

August 11 2026

Volume Without Value – Part Two: Which Of Your Security Data Is Earning Its Place?

Hoop Cyber Blogs, HOOP Latest News

Cutting security data to save money is easy to do badly. Here is a method for working out what is actually earning its place, and where everything else should live instead.

Part one of this series argued that the growth in security data volume is being driven by ordinary organisational change rather than by any increase in risk, and that no amount of negotiation fixes an architectural problem. The obvious follow up question is which data you can move or stop paying premium rates for without opening a hole in your coverage.

The honest answer is that most organisations do not know, because the work required to find out has never been prioritised. It is not difficult work. It is simply nobody’s job.

Start With What You Cannot Currently See

Before any decision about tiering or filtering, you need three pieces of information that most teams cannot produce on request.

A mapping of every active detection rule to the data sources it depends on. Not the sources it was written against originally, the sources it queries today.
A record of which sources analysts have actually queried during investigations over a meaningful period. Ninety days is usually enough to see the pattern.
A list of every connected source with its current volume, its retention setting and the reason it was connected in the first place.

The third item is the one that produces the surprises. In most estates there are sources connected years ago for a project that has since concluded, sources duplicated because two teams onboarded the same platform, and sources nobody can now account for at all.

The Four Categories

Once you have that picture, every source and in many cases every field within a source falls into one of four groups.

Category	What it is	Where it belongs
Detection	Data that actively fires rules or feeds correlation logic	The searchable tier. This is what you are paying for and it is worth it
Investigation	Data analysts reach for during an incident but which triggers nothing on its own	Accessible storage with acceptable query latency. Rarely needs premium tier
Obligation	Data retained to satisfy a regulatory, contractual or audit requirement	Low cost durable storage with a documented retrieval path
Dormant	Data nobody has queried since it was connected	Question whether it should be collected at all

The distribution varies considerably between organisations, and I would be cautious of anyone quoting you a standard ratio. What is consistent is that the detection category is smaller than people expect, and the dormant category is larger.

Where The Data Should Go Instead

Moving data out of the premium tier only helps if it lands somewhere it remains usable. Cheap storage that renders data unqueryable in practice has not solved the problem, it has converted a cost problem into a capability problem and deferred the consequences to your next incident.

Two things determine whether the destination is any good.

The first is the format the data lands in. If it is written in a proprietary or tool specific structure, you have created a dependency that will outlast whichever platform prompted it. Open schemas exist for exactly this reason. The Open Cybersecurity Schema Framework has gathered meaningful support across the industry, and normalising to an open standard on the way in means the data remains readable regardless of what sits on top of it later.

The second is who owns the storage. Data held in your own cloud account, in a security data lake you control, behaves differently at renewal time from data held inside a vendor platform. That distinction matters commercially as well as technically, and part three of this series looks at why.

The Compliance Objection

The most frequent objection to any of this is that regulatory obligations require the data to be retained, so it cannot be touched.

Retention obligations generally specify how long data must be kept and how reliably it must be produced when requested. They very rarely specify that it must be instantly searchable in a premium analytics platform for the duration. Those are different requirements and conflating them is expensive.

What matters is that the retrieval path is documented, tested and defensible. An obligation satisfied by low cost durable storage with a proven restore process is satisfied. This is a point worth confirming with your own compliance function rather than taking on trust from a blog post, including mine, because the specifics vary by sector and by regulator.

Two Ways This Goes Wrong

The first failure is cutting a source that was quietly feeding several correlation rules. This is why the rule to source mapping comes before any decision rather than after it. Detection logic accumulates over years and the dependencies are rarely documented anywhere a procurement exercise would find them.

The second is subtler and more common. Teams reduce volume by dropping fields rather than sources, on the reasonable assumption that a partial record is better than none. Sometimes it is. But field level filtering breaks detections in ways that are much harder to spot than source level removal, because the rule still runs, still returns results and simply misses a subset of cases. A detection that fails loudly is a problem. A detection that fails quietly is a much worse one.

If you take one operational principle from this piece, make it this: change one thing at a time, record what you changed, and validate the affected detections before moving on.

What Changes When This Is Done Properly

The immediate result is a lower bill, which is what gets the project approved. The more durable result is that the security function regains control of a decision it had effectively outsourced to a licensing model.

Once data is being routed deliberately rather than by default, connecting a new source becomes an architectural decision with a known cost rather than a budget event. Teams stop declining coverage for financial reasons, which is the outcome that actually matters.

In part three we look at what all of this does to the renewal conversation, and how to measure whether the work delivered what it promised.

HOOP Cyber helps security teams audit their data estate, design the routing and normalisation that sits behind it, and rebuild security operations around a data architecture they control. If you cannot currently produce the three pieces of information at the top of this article, that is where we would start. Get in touch via .

August 11 2026

Volume Without Value – Part One: Volume Is Not Risk

Hoop Cyber Blogs, HOOP Latest News

Security data volume is growing for reasons that have almost nothing to do with how much risk your organisation is carrying. Understanding why is the first step to doing something about what you spend.

Ask a security leader what changed about their budget conversation over the last three years and the answer is rarely about a new category of threat. It is about volume. The line item that used to come up once a year at renewal now comes up every quarter, and the question has shifted from what the platform does to why it costs what it costs.

There is a structural reason for this, and it has very little to do with the risk the organisation is actually carrying.

How The Pricing Model Works Against You

Security information and event management platforms have historically been priced against the volume of data they take in. The specific commercial model varies by vendor, and several have introduced alternatives based on compute, workload or committed tiers rather than raw ingest. The dominant logic for a long period, though, has been simple: the more data you send, the more you pay.

That model was reasonable when the data sources were relatively stable. A finite set of firewalls, servers and directory services produced a predictable amount of log data, and the volume moved roughly in line with the size of the estate.

That is no longer the environment anyone is operating in.

What Is Actually Driving Your Volume Growth

When security data volume rises sharply, the cause is usually somewhere in the following list. None of these items represents an increase in the amount of risk the organisation faces.

Cloud migration. Control plane activity, flow logs and storage access logs generate a category of telemetry that simply did not exist in the equivalent on premises estate.
Verbose defaults. Modern platforms log more per event than their predecessors did, with richer context attached to each record. The event count may not have moved much. The bytes per event have.
Software as a service growth. Every new business application added over the last five years came with its own audit log, and security was rightly asked to monitor it.
Endpoint telemetry. Detection and response tooling produces a continuous stream of process, network and file activity rather than the periodic alerts that antivirus used to generate.
Identity as a monitored surface. Authentication, authorisation and privilege activity has become one of the highest volume sources in most estates, and one of the most valuable.
Retention obligations. Regulatory and contractual requirements often specify how long data must be kept, and organisations frequently satisfy that requirement by leaving everything in the platform it landed in.

Read that list again with a finance director in mind. Every item on it is the byproduct of the organisation working normally and modernising sensibly. Not one of them is a signal that the threat picture has worsened.

The cost curve and the risk curve have separated, and the commercial model still assumes they are the same line.

The Decision Nobody Wants To Be Making

The consequence is a category of decision that no security leader wants on their conscience. When a data source has to be dropped to stay inside a licence tier, the decision is being taken on price rather than on risk. The conversation may be framed in terms of value, but the constraint driving it is commercial.

The most common version of this is quiet, and that is what makes it dangerous. A source is not switched off in a meeting with minutes. It is simply never switched on. A new SaaS platform goes live, its audit log is assessed, the volume is judged unaffordable, and the source stays outside the monitored estate. Nothing is recorded as a risk acceptance because nothing was formally rejected.

There is no alert for a detection you never wrote. The gap does not surface in any dashboard, any coverage report or any board pack. It surfaces during an incident, when someone asks why there is no record of what happened between two points in a timeline.

Why A Better Discount Does Not Fix It

The instinctive response is to negotiate harder. Bring in procurement, run a competitive process, secure a better rate per unit.

That is worth doing, and it is not the answer. A discount changes the rate. It does not change the shape of the curve. If volume is growing at a rate the security function does not control, and it is, then a better unit price buys time rather than a solution. The same conversation returns at the next renewal with a larger number attached, and the negotiating position is weaker because the easy concessions have already been made.

The same applies to filtering at the edge as a standalone tactic. Dropping fields to reduce volume without a clear view of what those fields support is how organisations discover, eighteen months later, that a correlation rule has been silently returning nothing.

A Better Question

The question worth asking is not what the organisation should be paying per unit of data. It is which data needs to sit in the most expensive tier at all.

Most security estates contain data in at least four distinct categories: data that actively fires detections, data that analysts reach for during an investigation but which never triggers anything, data retained purely to satisfy a compliance obligation, and data that nobody has queried since it was first connected. Those four categories have very different value, very different access requirements and very different economics.

Almost no organisation prices them differently, because almost no organisation has separated them. Everything lands in the same place, is charged at the same rate and is retained on the same terms.

That is an architectural problem rather than a commercial one, which is why it cannot be negotiated away. It can, though, be designed away.

In part two we look at how to work out which of your data belongs in which category, and what to do with the three categories that do not need to be sitting where they currently are.

HOOP Cyber works with security teams to modernise security operations architecture and bring the cost of the security data estate back under control. If the volume conversation has become the whole conversation, we should talk.

July 22 2026

Identity Is the New Perimeter: Why Identity Telemetry Belongs in Your Security Data Lake

Hoop Cyber Blogs, HOOP Latest News

The old idea of a network perimeter has quietly dissolved. Cloud services, remote working, software as a service and a web of third parties mean the first thing an attacker reaches for is rarely a firewall. It is an identity.

The Perimeter Moved and Identity Took Its Place

There was a time when defending an organisation looked like defending a boundary. Everything trusted sat inside the walls, everything suspect sat outside, and the job was to police the line between them. That model has faded. Applications live in the cloud, people work from anywhere, data moves through services the security team does not own, and the neat boundary has been replaced by a sprawl of connections that no single wall could ever contain.

In that world identity has become the control plane. The credential, the token and the session are what grant access now, which is why modern attackers so often log in rather than break in. A valid identity is the master key, and it opens far more doors than any exploit.

Why Identity Is the Attacker’s Favourite Route

Credentials are cheap, plentiful and endlessly traded, and a login that uses real ones looks entirely legitimate to systems watching for something to break. That is the appeal. An attacker holding valid credentials does not trip the alarms tuned for intrusion, because from the outside their activity resembles an ordinary user going about their day.

From that foothold the same identity plane offers the routes onward. Moving sideways between systems, reaching for higher privileges, abusing the trust that applications place in one another, wearing down a person with repeated authentication prompts until they approve one out of fatigue. Each of these leans on identity, which is precisely why identity is where so many incidents now begin.

The Signals Identity Data Carries

The upside is that identity is noisy in a useful way. It produces a rich stream of signals for anyone able to read them together. Authentication logs show who signed in, from where and on what device. Multi factor events, conditional access decisions and token issuance reveal how access was granted and under what conditions. Directory changes and privilege grants show how the shape of access is shifting over time. Access logs from your software as a service estate extend the picture into the applications where the real work, and the real data, now lives.

Each of these sources tells part of a story. The value appears when they are read as one narrative rather than a set of disconnected fragments.

Why Identity Telemetry Often Sits in a Silo

In many organisations that is exactly what goes wrong. Identity logs live in one system, endpoint data in another, network data in a third, and each is watched, if at all, on its own terms. An identity led attack does not respect those boundaries. It begins with a login, touches an endpoint, moves across the network and reaches into a cloud application, and if those sources never meet, the pattern that would have given it away is never assembled.

Watching identity in isolation catches the obvious and misses the rest. The interesting signal is almost always in the relationship between an authentication event and what happened next somewhere else entirely.

Bringing Identity into the Security Data Lake

This is where a centralised, well-structured approach to security data changes what is possible. Bring identity events into the same foundation as everything else, normalised to a common standard such as the Open Cybersecurity Schema Framework, and a suspicious login stops being an isolated line in an isolated log. It becomes something you can correlate directly with the endpoint activity and network movement that followed it.

With identity, endpoint and network telemetry searchable together, detections and threat hunting can follow an attacker across the whole path rather than losing them at each boundary. The patterns that only reveal themselves when sources meet, the ones an identity attack depends on staying hidden, come into view.

What Good Looks Like

A mature approach starts by understanding normal. With a clear baseline of ordinary identity behaviour, the departures become obvious.

Sign ins that are geographically impossible, or that arrive from unexpected locations and unfamiliar devices.
Privileges being used in ways that do not fit the person or the role, or granted outside the usual process.
Dormant accounts springing back to life, or service accounts behaving like people.
Token and session anomalies that suggest a credential is being used by someone other than its owner.

Beyond the individual detections, the deeper gain is that identity context enriches every investigation. When an analyst can see, in one place, who an event belongs to and how that identity has behaved across the estate, they reach a sound conclusion far more quickly.

Put Identity at the Centre

If identity is where modern attacks begin, then identity data belongs at the heart of your security data strategy rather than parked in a silo of its own. Give it a place alongside your other sources, in a foundation built to correlate them, and you turn the attacker’s favourite route into one of your clearest sources of early warning.

HOOP Cyber helps organisations bring identity telemetry together with the rest of their security data in one centralised, searchable foundation, so identity led attacks have nowhere to hide. To talk through your approach, get in touch via .

July 22 2026

DORA Is Live: What Financial Services Teams Need From Their Logging And Monitoring

Hoop Cyber Blogs, HOOP Latest News

The Digital Operational Resilience Act is no longer on the horizon. It has applied since January 2025, regulators have moved from guidance to enforcement, and the question for many teams is whether their logging and monitoring could actually meet its demands under pressure.

DORA In Brief

DORA, formally Regulation (EU) 2022/2554, is the European Union’s dedicated framework for managing information and communication technology risk in the financial sector. Unlike a directive, a regulation applies directly across all member states without national transposition, so the core obligations are the same in every jurisdiction from the day it took effect. It reaches around twenty two thousand financial entities together with the ICT providers that serve them.

The framework rests on five pillars, covering ICT risk management, incident management and reporting, digital operational resilience testing, third party risk management and information sharing. Senior management carries accountabilities for all of it. Penalties are significant, reaching up to two percent of annual global turnover for financial entities, with higher exposure for the most serious breaches, and a separate regime for the critical providers the sector depends on.

Why UK Firms Are in Scope

A UK organisation cannot assume DORA is somebody else’s concern. For financial entities inside its scope, DORA takes the place of the general obligations that would otherwise apply, and its third-party provisions extend its reach well beyond the EU’s regulated firms. A UK business that provides ICT or security services to an EU financial entity is drawn in through the contracts, assessments and evidence its customers are now required to demand.

The point was underlined in late 2025 when European authorities named their first set of critical ICT third party providers, a list that included the major cloud and technology platforms the sector relies on, placing them under direct oversight. Financial entities must record their dependencies on such providers and assess the concentration risk that comes with them, and that scrutiny flows down the supply chain to everyone involved in delivering those services.

What DORA Demands from Your Logging and Monitoring

Beneath the legal language, a great deal of DORA depends on the quality of your operational data. Several obligations are difficult to imagine meeting without it.

Incident detection and the reporting clock set a demanding pace. For a major incident an initial notification is expected very quickly after classification, an intermediate report follows within days and a final report within one month. Hitting those windows relies on fast, dependable access to the logs needed to scope and reconstruct what happened.
Forensic evidence has to be preserved. DORA expects financial entities to reconstruct incidents in a defensible way, which means maintaining a clear chain of custody and audit trails that stand up to examination rather than a partial picture assembled after the fact.
Resilience testing generates data that has to be captured and acted on. The results of testing, including the more advanced threat led exercises, are only useful if the evidence is retained and the lessons feed back into your controls.
Third party risk has to be monitored, not just documented. Understanding the activity of the ICT providers you depend on is far easier when that activity is reflected in data you can actually see and search.
Retention must be long enough to investigate, report and prove. Evidence that has aged out before you need it leaves the same gap as evidence you never collected.

Where Financial Firms Fall Short

The common weaknesses look familiar. Log coverage is uneven, with important sources missing or trimmed to control cost, so the gaps only become visible when an incident lands in one of them. The data that is collected is slow to search, which turns a tight reporting deadline into a frantic hunt through disconnected systems. Because sources are not normalised to a shared format, correlating an identity event with a network event and an endpoint event becomes a manual exercise rather than a query.

Chain of custody is often the weakest point of all. Few teams can produce a clean, defensible account of who did what and when across the whole estate, which undermines both the reporting obligation and the forensic expectations that sit behind it. Reporting itself is frequently improvised under stress, assembled by hand at the very moment the team can least afford the distraction.

A Data Centric Path to Resilience

Financial entities that find DORA manageable tend to treat their security data as core infrastructure rather than a byproduct. That begins with centralising the relevant sources and normalising them to a common standard such as the Open Cybersecurity Schema Framework, so information from very different systems can be searched and correlated together.

On that foundation the pillars become far more tractable. Fast, federated search lets a team scope an incident within the reporting windows instead of racing them. Compliance dashboards turn resilience from an annual set piece into a state you can see at any moment. Audit ready trails capture defensible evidence as a natural output of normal operation. Third party telemetry brings the providers you depend on into the same picture as everything else. The shift is from scrambling to answer a question you cannot quickly resolve, to operating from a position where the answer is already in front of you.

A Practical Note on Scope

DORA is directly applicable, but the way it bites on any given organisation depends on your role in the financial ecosystem, your specific ICT dependencies and the guidance issued by the relevant authorities. Treat this as an orientation to what the regulation asks of your data and confirm your precise obligations with your supervisory authority and your own legal advisers. The data foundations described here support resilience whatever the detail of your position.

HOOP Cyber helps financial services organisations build the security data foundation that DORA now requires, from centralised collection and normalisation to fast incident scoping, audit ready evidence and compliance dashboards. To talk through your resilience, get in touch at .

July 22 2026

The Metrics That Actually Prove Your SOC Is Working

Hoop Cyber Blogs, HOOP Latest News

Every security team is asked the same question eventually, usually by someone holding a budget. How do we know this is working? Answering with a tally of alerts handled and tickets closed feels like an answer, but it measures effort rather than outcome, and the two are not the same thing.

The Difference Between Being Busy and Being Effective

It is easy to fill a report with numbers that look impressive and prove very little. Thousands of alerts triaged, hundreds of tickets resolved, a long list of tools in the stack. These describe how busy a team has been, not whether the organisation is any safer. A security function can be extremely busy and still be missing the things that matter, and a quiet one can be quietly excellent.

The metrics worth reporting are the ones that speak to outcomes. How quickly do we notice when something is wrong? How quickly do we deal with it? How much are we simply not seeing? And is any of this getting better over time?

Start With the Questions, Not the Numbers

Good measurement begins with the questions the metrics are meant to answer, not with whatever happens to be easy to count. When a metric exists only because a tool produces it, it tends to drift away from anything useful. When it exists to answer a real question about risk, it stays honest. A short, deliberate set of measures tied to clear questions will always serve you better than a crowded dashboard nobody trusts.

The Metrics That Really Matter

A handful of measures carry most of the weight, because each one maps to a stage of how an incident actually unfolds.

Mean time to detect is the gap between something going wrong and your team noticing. It is the single clearest indicator of how exposed you are, because everything an attacker does before you notice, they do unopposed.
Mean time to respond, or to contain, is the gap between noticing and stopping the spread. Fast detection means little if containment then takes days.
Dwell time captures the whole picture; the total period an attacker was present before being removed. It is the number that best reflects real risk to the business.
Mean time to acknowledge shows how quickly alerts are picked up and triaged, which exposes bottlenecks at the front of the process before they become response delays.
Detection coverage asks how much of what matters you can see, measured against the techniques you expect to face, and the data sources you have connected. Strong response times mean little if your coverage leaves whole areas dark.
Signal to noise, including the false positive rate, tells you whether your analysts are focused on real threats or worn-down chasing alerts that lead nowhere. A team drowning in noise will miss the signal that counts.

The Metrics That Mislead

Some numbers are worse than useless because they invite the wrong conclusion. Raw alert volume is a favourite, yet a rising count could mean better visibility or simply a noisier tool, and a falling one could mean improvement or a broken feed. Tickets closed rewards speed over quality. A tally of tools in the stack measures spend, not security.

There is also a trap in percentages drawn from small numbers. A move from one incident to two is a hundred percent increase, and a single good month can look like a transformation if you squint. When the underlying figures are small, a percentage can imply a trend that the data does not really support. It is more honest to show the absolute numbers alongside the percentage, and to treat an encouraging shift as an early signal to watch rather than a settled fact.

Why You Cannot Measure What You Cannot See

Every one of these metrics’ rests on the quality of your underlying data, which is the part most often overlooked. A blind spot flatters your figures in the cruellest way. If you never collect the logs from a given system, you will never detect the incident that starts there, and your mean time to detect will look wonderful precisely because it is measuring only the threats you were positioned to catch.

Honest metrics depend on honest coverage. When security data from across the estate is centralised and normalised to a common format, the numbers describe reality rather than the narrow slice you happened to be watching. Correlation across sources also sharpens the measures themselves, because an incident detected through one system and confirmed through another produces a truer account of detection and response than any single source could.

Turning Metrics into a Story the Board Understands

A number on its own rarely lands with a board. What lands is the trend and the meaning behind it. Detection times falling quarter on quarter, coverage extending into areas that were previously dark, dwell time shrinking as detection and response tighten. Set against the risk to the business and the cost of the operation, these tell a story that a non-specialist can follow and act on.

This is where a live view earns its place over an annual snapshot. Dashboards that reflect the current state at any moment turn measurement from a backward-looking report into an operational tool, one the team uses to steer, and the board uses to understand where things stand. The aim is not more numbers, it is a small set of trusted measures, shown in context, that answer the question everyone keeps asking.

Measure What Matters, Honestly

Proving a security operation works is less about the volume of activity and more about a few well-chosen measures, reported with care. Track how fast you detect and respond, be honest about what you cannot yet see, treat small numbers with the caution they deserve, and show the trend rather than a single figure. Do that and the next time someone asks whether this is working, you will have an answer built on outcomes rather than effort.

HOOP Cyber helps organisations build the data foundation that makes security metrics honest and meaningful, from centralised, normalised collection to live compliance and performance dashboards. To talk through measuring what matters, get in touch at .

July 10 2026

The Logs You Can Afford To Lose: A Practical Guide To Reviewing Your SIEM Ingest

Hoop Cyber Blogs, HOOP Latest News

Every security team has a SIEM bill that only ever seems to go up. More sources, more endpoints, more cloud services, and the ingest volume climbs month after month. The instinct is to keep everything, because nobody wants to be the person who dropped the one log that turned out to matter. That instinct is understandable. It is also the reason so many teams are paying a great deal for data they will never look at.

This post is a practical way to review what you are ingesting and decide, source by source, what earns its place. It is not an argument for blanket cuts. It is about knowing the security value of each log against what it costs you to keep, then making a deliberate choice rather than defaulting to everything.

Why Ingest Everything Became The Default

Three things push teams towards keeping it all. The first is pricing. Most traditional SIEM platforms charge by the volume you ingest, so the very thing you want, more visibility, is the thing that costs you more. Over time that quietly turns your detection strategy into a budgeting exercise.

The second is fear of the missing log. When an incident happens, the last thing anyone wants is to discover the relevant data was never collected. So sources get added and almost none get removed. The third is ownership. Ingest tends to grow because lots of people can add a source and nobody is responsible for reviewing whether it still belongs there. Left alone, the pipeline only ever gets bigger.

Start With What The Data Is Actually For

Before you judge any source, be clear on its purpose. Most logs serve one of a few jobs: real time detection, investigation during and after an incident, compliance and audit, or longer term threat hunting. A log that feeds an active detection rule is a very different thing from one you are keeping in the expensive tier just in case. Sorting your sources by purpose is the fastest way to see where money is going on data that no rule, report or analyst is actually using.

Score Each Source On Value And Cost

With purpose established, score each source on a few simple measures. You do not need a complex model, just honest answers.

Detection value. Does anything actually alert on this source, or does it simply sit there?
Investigation value. Would you genuinely reach for it during an incident, and how often have you in the past year?
Compliance requirement. Are you obliged to keep it, and for how long, or is that an assumption nobody has checked?
Volume and cost. How much of your bill does this one source represent?

Those answers point to one of four outcomes for each source: keep it in the hot, queryable tier where detection needs it, move it to cheaper storage for the long tail you might need later, reduce it by filtering or sampling before it lands, or drop it altogether. The point is that every source gets a decision rather than a free pass.

The Sources People Are Often Surprised To Be Paying For

I want to be careful not to make sweeping claims about your environment, because every estate is different. That said, a few patterns come up often enough to be worth checking. Verbose debug logging that was switched on during a project and never switched off. The same source feeding two tools and being paid for twice. High volume, low value telemetry sitting in the expensive tier when it rarely drives a detection. Development and test systems logging into the same platform as production. None of these are certainties, but each is worth a look when you run your review.

Where A Security Data Lake Changes The Maths

Here is the shift that matters most. The choice is not really keep versus delete. With a tiered approach you can keep the data and still lower the bill, by putting it in the right place. Detection grade data stays in the SIEM where it needs to be fast and queryable. The long tail that you keep for hunting or compliance moves to lower cost storage such as a security data lake, where it is still available when you need it but is not priced like live detection data.

This is the heart of a modern security data foundation. It lets you say yes to retention and yes to cost control at the same time, rather than trading one against the other. Done well, it is often where the largest and most sustainable savings come from, without giving up the visibility your team relies on.

One Thing Worth Protecting

There is a sensible caution to hold alongside all of this. Some sources look quiet right up until the day you need them. Authentication logs, records of privileged activity and the audit trail around your most sensitive systems may generate very little in the way of daily alerts, yet they are exactly what an investigator will ask for first when something goes wrong. When a source scores low on day to day detection but high on the what happens if we miss it test, that is usually a signal to keep it, even if you move it to cheaper storage. The aim of the review is to spend less on data that does nothing, not to quietly bin the records that would save you in an incident. A good review sharpens your visibility. It does not hollow it out.

A Review You Can Actually Run

Keep the process light so it actually happens. List your sources. Tag each one by purpose. Pull the volume and cost per source from your platform. Score them on the measures above. Make a keep, move, reduce or drop decision for each, and write down why. Then put a recurring review in the calendar, quarterly is usually enough, because ingest drifts and today’s sensible pipeline becomes next year’s bloated one if nobody looks again.

None of this needs to be a grand transformation programme. The teams that keep their SIEM costs under control are rarely the ones with the cleverest tooling. They are the ones who treat ingest as something to be reviewed on purpose, with a named owner and a regular slot, rather than something that simply grows in the background until the finance team asks a difficult question. A short honest review once a quarter will tell you more about your spend than any vendor dashboard, and it puts the decisions back where they belong, with you.

Get In Touch

If you would like a second pair of eyes on your ingest, or help designing a tiered approach that protects your visibility while lowering your bill, we would be happy to help. Email the HOOP Cyber team at and we will be glad to talk it through with you.