In an industry that is never short of announcements, genuinely transformative moments can be easy to miss. The news that HOOP Cyber, one of the UK’s most innovative specialist security data operations firms, has joined the FSP Consulting Services Group, is one that deserves to be heard clearly.
To explore what it means, Lisa Ventura MBE FCIIS sat down with Simon Johnson, CEO and Founder of HOOP Cyber, for a wide-ranging conversation about the partnership, the rationale behind it, and what lies ahead for customers and the broader industry.
The Problem HOOP Cyber Was Built to Solve
When Simon Johnson founded HOOP Cyber three years ago, he had a clear and pressing problem in his sights. Having spent years working across security operations, SIEM, and threat intelligence, he had seen the same challenge play out time and again at organisations of all sizes: security data volumes had grown exponentially, but the tools and architectures used to manage them had not kept pace.
“My SIEM was fantastic and it was great ten years ago when I had 100 gigabytes of data, but now I’ve got two or three terabytes of data a day and I’m struggling.”- Simon Johnson, CEO and Founder, HOOP Cyber.
For many security teams, what had once been a quick and efficient way to interrogate data had become, in Simon’s words, “a genuine data engineering millstone around the neck.” Storing, querying, and drawing insight from vast quantities of security data had become slower, more complex, and significantly more costly.
HOOP Cyber was built specifically to address this reality, developing a set of approaches centred on what the firm calls modernised security operations. At its core is the conviction that cybersecurity is, fundamentally, a data problem. The company’s flagship offering, HOOP Lake, powered by Amazon Security Lake, transforms the way security teams can stream, store, search, enrich, and comply across their entire estate of security events, using standardised schemas such as OCSF and natural language query capabilities to make security data genuinely accessible and actionable.
Why FSP? Why Now?
Simon spoke candidly about the journey that led him here, and the qualities that made FSP the right partner at the right moment.
As HOOP Cyber grew, it found itself working with some very large customers. Delivering outstanding outcomes at that scale required significant capacity and capability that, as a focused specialist firm, was not easy to build alone. Simon began actively exploring how to deliver at the pace and scale his clients needed, while preserving the values and culture that had made HOOP Cyber distinctive.
FSP Consulting Services Group is a 450-person cyber consulting business headquartered in Reading, UK. It has earned a strong industry reputation not only for technical excellence across enterprise transformation and cyber security, but also for being recognised as an outstanding place to work, a quality that Simon found was lived out genuinely by the people he encountered day to day.
“Culture is absolutely key to any successful environment. I think I definitely felt like the culture is a perfect fit.” – Simon Johnson, CEO and Founder, HOOP Cyber.
Beyond the culture question, FSP offered the capacity and multi-domain capability to take HOOP Cyber’s work further than it could travel alone. Where HOOP had historically operated within the specific domain of security operations, FSP opens the door to a broader set of disciplines including data engineering, AI adoption, and enterprise transformation, creating a proposition that can support clients across and beyond the CISO’s remit.
What This Means for Existing Customers
For those already working with HOOP Cyber, the message from Simon is very reassuring. The core focus remains unchanged: building modernised security operations with a data-centric approach. What changes is the scale at which HOOP can deliver, and the breadth of expertise it can bring to bear.
Key Points for Existing HOOP Cyber Clients:
The same specialist focus on security data operations and SIEM modernisation continues
Delivery can now happen at significantly greater scale, backed by a 450-person consultancy
Clients gain access to FSP’s broader capabilities across cyber, data engineering, and AI adoption
Services extend across the UK and, in time, across EMEA and the US
FSP’s vendor-agnostic approach means clients receive the right solution for their specific environment
As Simon put it simply, for existing clients it is “nothing changes. Hopefully it’s only just a bit more of the same good stuff.” The expanded platform means that HOOP Cyber can now help clients not only with the technical mechanics of managing security data, but also with how they securely adopt AI, understand the business case and return on investment behind AI investments, and navigate the intersection of data, security, and digital transformation.
The AWS Partnership: A Strategic Differentiator
One of the most significant aspects of HOOP Cyber’s heritage that it carries into the FSP Group is its strategic partnership with Amazon Web Services. This is, in Simon’s view, one of the most compelling elements of the combined offering.
AWS has been a strong advocate for HOOP Cyber’s growth, particularly in the areas of security data modernisation and Amazon Security Lake. FSP, for its part, had been looking to deepen its AWS capabilities to serve the many clients who have substantial investments in AWS environments or who run SaaS applications within AWS infrastructure.
The result is a focused ambition: to build a world-class AWS partnership that can offer FSP clients a completely new level of experience around the adoption of AWS solutions, cloud migrations, and the broader AWS ecosystem. It is a natural extension of the data-centric security work HOOP Cyber has always done, now with the scale and reach of a larger enterprise consultancy behind it.
The Future of Security Data Operations
The conversation with Lisa Ventura MBE FCIIS closed with a forward-looking question: what does the future of security data operations actually look like? Simon offered a grounded and thoughtful perspective, shaped by years of working at the coalface of the problem.
The fundamental challenge will not change. Security remains a data problem. The questions that will increasingly preoccupy security teams are architectural and strategic: should data be centralised or left distributed? How can data lake solutions such as Amazon Security Lake enable aggregation without the cost and complexity of traditional approaches? How can open schemas like OCSF make data simpler and faster to query? Can federated search and query capabilities decouple data storage from data interrogation?
“It’s critical to be able to have access to the right data, to ask that data the right question at the right time.” – Simon Johnson, CEO and Founder, HOOP Cyber.
AI will inevitably play an increasingly prominent role, and Simon acknowledged this candidly, noting that the industry will “continue to see a splattering of AI here, there, and everywhere.” Detection as code, doing more with less, and smarter automation are themes that will persist. But underneath all of it, the data problem endures, and that is precisely where HOOP Cyber and FSP are focused.
A Purposeful, People-Centred Approach
Throughout the conversation not only the strategic logic of the partnership emphasised, but also the spirit in which it had been forged. This is a combination built on shared values, a genuine alignment of culture, and a belief that the best outcomes for clients come from organisations where people are genuinely invested in each other’s success.
As Lisa observed in closing, this is precisely the kind of purposeful, people-centred approach to cybersecurity that the industry needs considerably more of. The joining of HOOP Cyber and FSP Consulting Services Group is not simply a corporate transaction; it is a signal of intent, and one that the security data operations space would do well to pay close attention to.
Find Out More
Whether you are an existing HOOP Cyber client, a prospective partner, or simply following the evolution of security data operations, this is a chapter worth watching closely.
We’re thrilled to announce that HOOP Cyber has joined FSP Consulting Services Group, an award winning enterprise transformation and cyber security consultancy. This marks an exciting evolution for our team, our technology, and most importantly, the value we deliver to our clients.
Why This Matters
Since launching HOOP Cyber, we’ve been on a mission to solve the security data challenge. We’ve helped organisations modernise their security operations through Amazon Security Lake, transform unwieldy SIEM costs into efficient data lake architectures, and build automated data pipelines that give security analysts time to think rather than just time to react.
Joining FSP accelerates everything we’ve been building. FSP’s comprehensive capabilities across cyber security, cloud, data, and AI complement our specialist security data operations expertise. Their awardwinning culture and numerous #1 and top rankings by Best CompaniesTM and Great Place to WorkTM ,aligns perfectly with our commitment to building sustainable, people centred security operations.
What This Means for Our Clients
If you’re a HOOP Cyber client, you’ll continue to work with the team you know whilst gaining access to FSP’s broader portfolio of services. Need help with broader cyber strategy alongside your security data lake implementation? FSP’s Virtual CISO and Cyber Strategy teams can help. Looking to integrate your security data operations with wider cloud transformation initiatives? FSP’s cloud and platform engineering expertise is now available to you. Want managed services to support your security operations long-term? FSP’s comprehensive managed services portfolio has you covered.
Your HOOP Cyber projects continue uninterrupted, with the same expertise and dedication you’ve experienced, now backed by FSP’s extensive resources and capabilities.
What This Means for Our Partners
Our strategic partnerships with AWS, Query, Tenzir, Cyware, Tines, DataBee, and Silent Push remain central to how we deliver value. These partnerships become even stronger within FSP’s broader technology ecosystem, creating new opportunities for integrated solutions that address the full spectrum of security and digital transformation challenges.
What This Means for Our Team
For the HOOP Cyber team, joining FSP means joining an organisation that genuinely lives its values of “people first, purpose led, performance driven”. FSP’s investment in professional development through the FSP Academy, their commitment to work-life balance, and their recognition as a world-class workplace creates an environment where our team can continue to grow, innovate, and deliver exceptional outcomes for clients.
Looking Forward
The security landscape continues to evolve rapidly. Data volumes are exploding, threats are becoming more sophisticated, and organisations need security operations that are both effective and sustainable. By combining HOOP Cyber’s specialist security data operations expertise with FSP’s comprehensive capabilities, we’re better positioned than ever to help organisations navigate these challenges.
We remain committed to the principles that have guided HOOP Cyber from the start: solving real problems with pragmatic solutions, respecting the humans who operate security systems, and building architectures that are sustainable, cost-effective, and genuinely improve security outcomes.
Thank you to our clients, partners, and supporters who have been part of the HOOP Cyber journey so far. We’re excited about this next chapter and the enhanced value we can deliver together with FSP.
For any questions about what this means for your projects or partnerships, please reach out to us at the usual contact details. We’re here, we’re excited, and we’re ready to do even better work together.
The UK Cyber Security and Resilience Bill has received a huge amount of commentary since its introduction. Much of that coverage, understandably, has focused on the broad strokes: expanded regulatory scope, new incident reporting obligations, and the extension of oversight to managed service providers and digital supply chains. This all matters, but for the security engineers and architects who must translate policy into working infrastructure, the questions that matter most are considerably more specific.
How long do we need to retain logs? What does a compliant audit trail actually look like? And what does this mean for how we build and operate our SIEM or data lake architecture going forward?
Those are the questions this post addresses. The Bill has not yet received Royal Assent, and some details remain subject to secondary legislation and regulatory guidance. Even so, the direction of travel is clear enough to start making informed architectural decisions now.
The Reporting Obligation and What It Implies for Log Availability
The Bill introduces mandatory incident reporting requirements for in-scope organisations, with initial notification timelines that are expected to be considerably shorter than current NIS Regulations thresholds. Early indicators suggest a 24-hour initial reporting window is likely for significant incidents, with a more detailed follow-up report to follow within 72 hours.
This matters for your SIEM in a very practical way. A 24-hour clock starts ticking from the point an incident is identified, not from the point it began. That means your ability to reconstruct an accurate timeline of events quickly is not a nice-to-have. It is a compliance requirement.
If your current log pipeline involves any significant ingestion lag, delayed normalisation, or gaps in source coverage, those gaps will become visible the moment you try to produce a credible incident narrative under time pressure. Your SIEM needs to be able to answer the question: what happened, when, and across which systems? And it needs to answer that question within hours, not days.
Log Retention: Moving Beyond the 90-Day Default
Many organisations currently retain hot logs for 90 days as a rough industry baseline, with varying approaches to cold or archival storage beyond that. The Bill, alongside likely guidance from the National Cyber Security Centre and the relevant sector regulators, is expected to push this considerably further for in-scope entities.
A 12-month minimum for core security telemetry is widely anticipated, with some regulated sectors likely to face longer obligations. This aligns with patterns already visible in NIS2 across the EU and in FCA expectations for financial services firms, and it would be reasonable to design your architecture around that assumption.
The architectural implication is straightforward but significant. Retaining 12 months of logs at SIEM licensing costs is prohibitively expensive for most organisations. The answer is tiered storage: hot data in your SIEM for active detection and investigation, warm data in a data lake or object storage layer for the medium term, and cold archival for the longer tail. The key is ensuring that data in the warm and cold tiers remains searchable and retrievable within a defined SLA, because a regulator asking for logs from seven months ago will not accept “we need two weeks to restore those from tape” as a satisfactory response.
Audit Trails: Integrity, Not Just Availability
There is an important distinction between having logs and having audit trails. Logs are raw telemetry. Audit trails are structured, tamper-evident records of events that carry evidentiary weight. The Bill’s emphasis on accountability and demonstrable resilience points firmly toward the latter.
For your SIEM architecture, this means thinking seriously about log integrity. Can you demonstrate that a log record has not been altered since it was written? Do you have hash verification or write-once storage for your most sensitive telemetry? Is your audit logging covering not just endpoint and network events, but privileged access, configuration changes, and administrative actions within your security tooling itself?
The categories of events that are likely to receive explicit regulatory attention include:
Authentication events, including failed attempts, MFA bypass, and privilege escalation
Changes to access controls, group membership, and identity configurations
Data exfiltration indicators, including large file transfers and cloud egress anomalies
Changes to security tooling configuration, including your SIEM itself
Network boundary events from firewalls, proxies, and DNS logs
If these categories are not comprehensively covered in your current log sources, now is the time to address those gaps rather than after Royal Assent.
Data Lake Architecture: Opportunity or Obligation?
The growing move toward security data lakes, whether built on platforms such as Snowflake, Databricks, Microsoft Sentinel with ADX, or open-source alternatives, is not purely a cost optimisation story. In the context of the Bill, it is also a compliance enabler.
A well-designed data lake gives you the ability to retain far greater volumes of telemetry at lower cost, run retrospective threat hunting across extended time windows, and produce structured evidence in response to regulatory enquiries. These are precisely the capabilities that the Bill’s reporting and accountability obligations will require.
However, the architecture only delivers on that promise if the data is properly structured at ingestion. Logs dumped into object storage without schema normalisation or indexing are not audit trails. They are a compliance liability dressed up as a solution. Invest in your data pipeline: consistent schemas, reliable timestamps, clear source attribution, and documented retention policies with access controls that reflect their regulatory purpose.
Managed Service Providers: A Specific Consideration
One of the more significant expansions in the Bill is the explicit inclusion of managed service providers and digital supply chain operators. If your organisation operates as an MSP, or if you rely on one to manage any part of your security infrastructure including your SIEM, you need to understand what this means contractually and operationally.
If you are a customer of an MSP: your contracts should specify who owns the log data, what retention obligations apply, and under what circumstances you can retrieve data for regulatory purposes. Data sovereignty and portability clauses matter more than they may have done previously.
If you are an MSP: you will likely be in scope for reporting obligations directly, and you will need to demonstrate that your own monitoring and audit capabilities meet the standard expected of critical infrastructure providers. Multi-tenant SIEM architectures in particular need careful review to ensure log isolation, customer data portability, and incident scoping are all functioning correctly.
Preparing Now, Before Royal Assent
The Bill is still progressing through Parliament, and secondary legislation will fill in many of the specific thresholds and technical requirements. But the core obligations around incident reporting speed, log retention duration, audit trail integrity, and supply chain accountability are sufficiently clear that waiting for final text before acting becomes a risk.
The organisations that will find compliance most straightforward are those that use this period to review their log source coverage, validate their retention architecture, and stress-test their ability to produce structured evidence under time pressure. That work has value regardless of the final regulatory detail.
Ready To Find Out More?
If you would like to talk through what the Bill means for your specific SIEM architecture or log management strategy, get in touch with the HOOP Cyber team via . We work with organisations across sectors to build detection and response capabilities that are operationally effective and built for the regulatory environment ahead.
Maturity models have always had a complicated relationship with operational reality. At their best, they give security leaders a shared language for describing where they are and a credible map of where they need to go. At their worst, they become a compliance checklist that mistakes the presence of tools for the presence of capability. In 2026, with AI now embedded across the detection and response landscape, the gap between the two has never been wider.
The traditional maturity conversation, built around frameworks like the SOC-CMM or adapted versions of the CMMI, was designed for a world of manual analyst workflows, perimeter-based thinking, and relatively predictable threat actor tooling. That world no longer exists. Adversaries are using AI to accelerate reconnaissance, generate convincing phishing content at scale, and adapt malware faster than signature-based detection can follow. The security operations function that is not actively incorporating AI into its own workflows is not standing still. It is falling behind.
This piece offers a practical framework for CISOs seeking to benchmark their SecOps function against a definition of maturity that reflects the current threat and technology environment. It is not a vendor checklist. It is a strategic lens.
Why the Old Models Need Updating
Classic SecOps maturity frameworks typically measured progress along axes like process documentation, technology coverage, and analyst capability. A Level 1 organisation was reactive and largely undocumented. A Level 5 organisation had optimised, continuously improving processes with full visibility across the estate.
The problem is not that these dimensions are wrong. It is that they are incomplete. They say nothing about how intelligence is operationalised, how alert triage decisions are made, how human cognitive load is managed at scale, or how the security function responds when the volume and velocity of threats exceeds what human analysts can process without assistance.
For a CISO benchmarking their organisation in 2026, the relevant questions are not just “do we have a SIEM?” or “are our playbooks documented?” They are: how effectively are we using AI to reduce analyst toil? How well does our automation distinguish between genuine threats and noise? And critically, where does human judgement remain essential, and are we protecting the conditions that allow that judgement to function well?
A Revised Maturity Model: Five Levels Redefined
The framework below defines five maturity levels across four dimensions: detection capability, response capability, AI integration, and human factors. The final dimension is one that conventional models consistently overlook, and it is increasingly the differentiator between organisations that realise the value of their AI investment and those that do not.
Level 1: Reactive
At the base level, log collection is inconsistent and alerts are reviewed manually on demand rather than continuously monitored. Incident response is entirely ad hoc, with no documented playbooks and no clear escalation paths. AI and automation play no meaningful role; tools may be present but are not operationalised. Analysts are overwhelmed, fatigue is endemic, and turnover is high. The function is consuming resource without generating reliable security outcomes.
Level 2: Defined
A SIEM is in place and standard use cases have been deployed, but the false positive rate remains high and detection logic has not been meaningfully tuned to the organisation’s specific environment. Response playbooks exist on paper, but execution is largely manual and escalation paths remain unclear. Automation is limited to basic alerting rules within the SIEM. Workload is beginning to be managed, and some skills development is planned, but the function is still largely reactive in practice.
Level 3: Integrated
Telemetry coverage is broad and threat intelligence feeds have been operationalised. Detection logic is tuned and generating fewer false positives. Documented runbooks are supported by partial automation, and mean time to respond is improving measurably. AI-assisted triage is in place, SOAR has been deployed, and analyst time is increasingly focused on higher-value investigative work rather than manual alert processing. Workload is managed more deliberately, some specialisation is emerging within the team, and trust in automated tooling is beginning to develop.
Level 4: AI-Augmented
Behavioural and anomaly-based detection models are tuned to the organisation’s environment and generating a low false positive rate. Automated containment handles known threat patterns, with human oversight reserved for complex or ambiguous cases. AI is integrated across detection, triage, and response, with feedback loops in place to continuously improve model performance. Analysts are focused on work that genuinely requires human judgement. Cognitive load is actively managed, and the team understands and can interrogate the AI tooling they work alongside.
Level 5: Adaptive
Detection capability improves continuously, with adversarial simulation informing model tuning and full visibility across the attack surface. Response is near-autonomous within defined parameters, with human decision-making reserved for novel or high-impact scenarios that require contextual judgement. AI is treated as a strategic capability, with explainability and bias monitoring in place and a mature governance model governing its use. The function attracts and retains strong talent, maintains a clear model for human-AI collaboration, and develops skills continuously in response to the evolving threat landscape.
The Human Factors Dimension: What the Models Miss
Every SecOps function, regardless of how sophisticated its tooling, ultimately depends on human beings making good decisions under pressure. The AI augmentation conversation has, in many organisations, focused almost exclusively on reducing the burden on analysts. That is necessary but insufficient.
The organisations that score highest on genuine maturity in 2026 are those that have thought carefully about the conditions under which their analysts perform well, not just the tools those analysts are given. That means addressing alert fatigue not just through better filtering, but through workload design. It means ensuring that the move toward automation does not erode the deep investigative skills that are essential when novel threats appear. And it means building psychological safety into the SOC culture so that analysts feel able to escalate uncertainty rather than resolving it by closing tickets.
This is not a soft concern. Organisations that neglect the human factors dimension will find that their AI investment underperforms, because the feedback loops that make AI models improve over time depend on skilled humans correcting, refining, and contextualising automated outputs.
Where Most Organisations Actually Are
Based on conversations across sectors, the honest picture is that the majority of UK enterprises currently sit between Level 2 and Level 3 on this framework. They have a SIEM. They have some playbooks. They are beginning to deploy SOAR or AI-assisted triage tooling. But their detection logic is still generating significant noise, their automation coverage is patchy, and their AI deployments are often pilot projects that have not yet been fully operationalised.
The gap between Level 3 and Level 4 is where genuine strategic investment is required. It is not primarily a technology gap. Organisations at Level 3 typically have adequate tooling. The gap is in data quality, process maturity, and the organisational confidence to trust automated decision-making in defined scenarios. Building that confidence requires transparency in how AI models reach conclusions, governance frameworks that define the boundaries of autonomous action, and a track record of measured, low-stakes automation that earns trust incrementally.
Practical Steps for CISOs Benchmarking Their Function
For a CISO seeking to use this framework practically, the starting point is an honest assessment across all four dimensions: detection, response, AI integration, and human factors. The temptation is to score the function at its highest-performing dimension. The more useful approach is to identify the dimension where the lowest score sits, because that is almost always the constraint that limits overall maturity.
A few questions worth working through with your team:
If a novel threat actor technique appeared in your environment today, how long before it would generate an alert? How long before an analyst would act on it?
What percentage of your alerts are closed by automation without analyst review? Of those, what proportion are genuinely benign versus suppressed because the signal was too noisy to manage?
Can your analysts explain how your AI-assisted triage tooling reaches its conclusions? Do they trust it? Do they have a mechanism for flagging when it appears to be wrong?
When did someone last deliberately test your detection capability using realistic adversary simulation? What did you learn?
The answers to these questions will tell you more about your actual maturity position than any tool inventory.
The Strategic Ambition: Good Is Not Static
The most important characteristic of a Level 5 SecOps function is not any specific technology or process. It is the ability to adapt continuously. The threat landscape in 2026 is not what it was in 2023, and it will not be what it is now by 2028. AI-driven attacks are becoming more sophisticated. The regulatory environment is becoming more demanding. The attack surface, spanning cloud, OT, supply chain, and identity, continues to expand.
A mature SecOps function is one that learns. It updates its detection logic when adversary techniques evolve. It revises its response playbooks when post-incident reviews identify gaps. It invests in analyst capability as the skills required for effective human-AI collaboration shift over time. And it governs its AI tools with the same rigour it applies to any other critical operational system.
That is what good looks like. Not a fixed destination, but a demonstrated capacity to keep up, and occasionally get ahead.
Ready To Find Out More?
If you would like to work through where your organisation sits on this framework, or to explore what a realistic roadmap toward Level 4 capability looks like for your specific environment and constraints, get in touch with the HOOP Cyber team via . We work with organisations across sectors to build detection and response capabilities that are operationally effective and built for the regulatory environment ahead.
For organisations operating at scale, Amazon Security Lake presents both an opportunity and a challenge. The opportunity is centralised security visibility across vast, distributed infrastructure. The challenge is architecting that visibility in ways that respect organisational boundaries, regulatory requirements, and operational realities.
Single-account Security Lake implementations work well for small organisations with straightforward requirements. But global enterprises face complexities that demand thoughtful architectural decisions: multiple AWS accounts managed through AWS Organisations, operations spanning numerous geographic regions, data sovereignty requirements that prohibit cross-border data movement, and diverse business units with different security maturity levels and compliance obligations.
This article explores proven design patterns for multi-account Security Lake architectures, drawing from real-world implementations across financial services, healthcare, and technology sectors.
Understanding Multi-Account Complexity
Before diving into specific patterns, it’s worth understanding why multi-account architectures matter and what unique challenges they introduce.
Most large organisations adopt multi-account strategies for good reasons. Account boundaries provide security isolation, limiting blast radius when credentials are compromised. They enable separate billing and cost allocation across business units or projects. They allow different compliance postures, with highly regulated workloads in tightly controlled accounts whilst development environments operate with greater flexibility. They support organisational structure, mapping accounts to business units, geographic regions, or operational functions.
When overlaying Security Lake on this multi-account reality, several questions immediately arise. Where should security data be stored? Who should have access to which data? How do you balance centralised visibility with data sovereignty requirements? How do you manage costs when data volumes vary dramatically across accounts? How do you handle accounts that join or leave the organisation?
These aren’t merely technical questions. They involve organisational politics, regulatory compliance, operational procedures, and long-term strategic considerations.
Core Architectural Patterns
Based on extensive field experience, four primary patterns have emerged for multi-account Security Lake deployments. Each addresses different organisational requirements and makes different trade-offs.
Pattern 1: Centralised Security Lake
In this pattern, all security data from all accounts flows to a single Security Lake instance in a dedicated security account. This creates a single source of truth for security data across the organisation.
The centralised pattern offers significant advantages. Security teams gain unified visibility across all accounts from a single query interface. It provides simplified operational management with one Security Lake instance to monitor and maintain. Cross-account investigations become straightforward when all data resides in one location. Cost management is simplified through centralised billing and easier application of lifecycle policies.
However, centralisation introduces challenges. Data sovereignty requirements may prohibit moving certain data to a central region. Blast radius increases, as a compromise of the security account affects all security data. Network data transfer costs can become significant when moving large volumes across regions. Compliance complexity increases when mixing data with different regulatory requirements.
This pattern suits organisations with relatively homogeneous compliance requirements, operations concentrated in one or two geographic regions, and strong central security teams with broad authority across the organisation.
Pattern 2: Regional Security Lakes with Federated Querying
For organisations operating globally with strict data residency requirements, regional Security Lakes provide a better fit. Security data remains in the region where it was generated, with federated querying enabling cross-regional analysis when needed.
This pattern addresses critical requirements for global organisations. Data sovereignty compliance is maintained by keeping data within required geographic boundaries. It provides regulatory isolation where different regions may have different compliance obligations. Network costs are reduced by avoiding unnecessary cross-region data transfer. Blast radius is limited, as compromise of one regional Security Lake doesn’t affect others.
The trade-offs involve increased operational complexity from managing multiple Security Lake instances. Cross-regional investigations require federated querying capabilities rather than simple SQL. Cost visibility becomes more complex with billing split across multiple regions. Ensuring consistency in data retention, access policies, and integration configurations across regions requires careful orchestration.
This pattern is essential for organisations with operations spanning multiple regulatory jurisdictions, particularly those subject to GDPR, data localisation laws in China or Russia, or strict data residency requirements in healthcare and financial services.
Pattern 3: Delegated Security Lakes per Business Unit
Some large organisations operate with highly autonomous business units that maintain separate security teams and tools. In this pattern, each business unit manages its own Security Lake instance, with optional data sharing to a central security team.
This pattern provides business unit autonomy, allowing independent security operations and tool selection. It enables clear cost allocation with each unit bearing its own Security Lake costs. Access control is simplified within business unit boundaries. It supports different security maturity levels where advanced units can implement sophisticated detections whilst others start with basics.
However, it introduces enterprise-wide visibility challenges requiring coordination across multiple teams. Duplication of effort occurs as each unit potentially reimplements similar integrations and detections. Compliance verification becomes complex when auditors need to review multiple independent implementations. Knowledge sharing suffers when security teams operate in silos.
This pattern suits large conglomerates with diverse business portfolios, organisations that have grown through acquisition where business units retain operational independence, and federated operating models where business units have profit and loss responsibility.
Pattern 4: Hybrid Architecture
Most large organisations ultimately implement a hybrid approach that combines elements of the patterns above. A typical hybrid might include regional Security Lakes for data sovereignty compliance, centralised replication of specific high-value data sources for enterprise-wide threat hunting, and business unit autonomy for tool selection with standardised data sharing.
Hybrid architectures match the messy reality of large organisations but require sophisticated design to avoid creating a complicated mess rather than an elegant solution. Success requires clear principles for deciding what data goes where, well-defined interfaces for data sharing and federated querying, strong governance to prevent architecture drift over time, and robust automation to manage complexity without overwhelming operations teams.
Design Considerations for Multi-Account Deployments
Regardless of which pattern you adopt, several design considerations apply across multi-account Security Lake architectures.
Access Control and Permissions
Multi-account environments complicate access control significantly. You must decide how to structure cross-account access, typically using AWS Organisations service control policies to establish baseline permissions, cross-account IAM roles for Security Lake access from centralised security tools, resource-based policies on Security Lake S3 buckets for granular access control, and AWS Lake Formation for fine-grained data access permissions.
Implement least privilege rigorously. Just because data flows to a central Security Lake doesn’t mean everyone in the security organisation should access all data. Consider implementing separate query roles for different teams, data masking for sensitive fields like personally identifiable information, and time-based access controls for particularly sensitive data sources.
Cost Allocation and Chargebacks
With security data flowing from multiple accounts, cost allocation becomes critical for accountability and budgeting. Implement tagging strategies that identify data sources by account, business unit, application, and environment. Use AWS Cost Explorer to track costs by tag and establish chargeback mechanisms if business units are responsible for their security data costs.
Consider implementing quotas or cost controls to prevent runaway spending. A misconfigured source generating excessive events can quickly inflate costs. Automated alerts when costs exceed thresholds provide early warning before month-end surprises.
Data Retention and Lifecycle Management
Different data types and regulatory requirements demand different retention periods. CloudTrail management events might require seven-year retention for compliance, whilst VPC Flow Logs might only need 90 days for operational analysis. Network connection logs from development environments might warrant 30 days, whilst production logs require a year.
Implement lifecycle policies that automatically transition data to cheaper storage classes based on age and importance. Recent data stays in S3 Standard for fast query access. Data older than 90 days moves to S3 Infrequent Access. Data older than a year moves to Glacier for long-term compliance retention.
Tag data at ingestion with appropriate retention requirements and use automation to apply lifecycle policies consistently across accounts and regions.
Data Quality and Consistency
With data flowing from numerous sources across many accounts, ensuring consistent data quality becomes challenging. Implement schema validation at ingestion to catch format changes before they cause downstream issues. Monitor for data freshness to detect when sources stop sending events. Track event volumes to identify unexpected increases or decreases. Validate OCSF compliance to ensure consistent normalisation across sources.
Consider creating a data quality dashboard that provides visibility into ingestion health across all accounts and sources. This operational visibility is critical for maintaining trust in Security Lake as the authoritative security data platform.
Real-World Implementation Example
Consider a global financial services firm with operations in North America, Europe, and Asia-Pacific. They operate over 300 AWS accounts across development, staging, and production environments for multiple business units.
Their regulatory requirements include GDPR in Europe, requiring EU data to remain in EU regions, APAC data localisation laws in several countries, and PCI-DSS for payment card data requiring specific controls. Their organisational structure includes a central security operations centre with 24/7 coverage, regional security teams in each major geography, and business unit security leaders with varying technical sophistication.
Their implemented architecture uses regional Security Lakes in eu-west-1, us-east-1, and ap-southeast-1 to address data sovereignty. It includes selective replication of critical alerts and high-value events to a central security account for threat hunting. Business units maintain autonomy for tool selection but must implement standard OCSF data sharing. It features automated data classification at ingestion to enforce appropriate retention and access controls.
Implementation followed a phased approach. Phase 1 established the regional Security Lake infrastructure and onboarded AWS native sources. Phase 2 integrated third-party security tools using standardised OCSF transformations. Phase 3 implemented federated querying across regional instances for cross-border investigations. Phase 4 deployed automated compliance reporting and cost chargeback mechanisms.
Key success factors included executive sponsorship from the Chief Information Security Officer who resolved cross-business-unit conflicts. They used standardised infrastructure as code templates for consistent deployment across regions. A centre of excellence provided guidance and shared best practices across business units. Phased rollout allowed learning from early deployments before full-scale implementation.
The results after twelve months showed 40% reduction in security data costs compared to previous multi-SIEM architecture, mean time to detect cross-account threats decreased from days to hours, compliance audit preparation time reduced by 60%, and security team satisfaction improved significantly due to unified data access.
Governance and Operating Model
Technical architecture alone doesn’t ensure success. Multi-account Security Lake deployments require thoughtful governance and clear operating models.
Establish a Security Lake Centre of Excellence responsible for architecture standards, providing reusable integration templates and guidance, reviewing new source integrations for quality and compliance, and managing the roadmap for shared capabilities.
Define clear data ownership where account owners are responsible for data quality from their sources, regional security teams own regional Security Lake operations, the central security team owns cross-regional analytics and threat intelligence, and business unit leaders approve access to their data by other teams.
Implement change management processes for architectural changes that affect multiple accounts, new data source integrations that might impact costs or performance, modifications to retention policies, and access control changes.
Create feedback mechanisms including regular architecture review meetings, incident retrospectives that identify gaps in data coverage, cost review sessions that identify optimisation opportunities, and user feedback forums where analysts can request new data sources or capabilities.
Migration Considerations
For organisations with existing security data infrastructure, migrating to a multi-account Security Lake architecture requires careful planning.
Start with a clear understanding of current state: inventory all security data sources across accounts, document existing access patterns and user workflows, identify compliance requirements by data type and geography, and quantify current costs for security data storage and analysis.
Develop the target architecture using one of the patterns discussed, with explicit design decisions documented and rationale captured. Create a phased migration plan that starts with AWS native sources in a pilot account group, then expands to additional accounts while monitoring performance and costs. Integrate third-party sources using lessons from pilot phase, and finally decommission legacy infrastructure once Security Lake proves sufficient.
Plan for the hybrid state where both old and new systems operate in parallel. This might last months or even years in large organisations. Ensure analysts have access to both systems during transition. Develop runbooks that specify which system to query for different time ranges or data types.
Measure success through operational metrics like mean time to detect and respond, compliance metrics such as audit findings and remediation time, cost metrics including total cost of ownership and cost per gigabyte, and user satisfaction from security analysts and investigators.
Common Pitfalls and How to Avoid Them
Multi-account architectures introduce failure modes that don’t exist in simpler deployments.
Avoid over-centralisation by respecting data sovereignty requirements even when technically possible to centralise. Compliance violations can result in significant fines. Don’t under-centralise either, where excessive fragmentation makes cross-account investigations impractical. Find the right balance for your organisation’s requirements.
Don’t neglect cost controls. Multi-account environments can hide runaway spending until it’s too late. Implement monitoring and alerting early. Avoid inconsistent configurations where each account implements Security Lake differently. Use infrastructure as code and automation to enforce consistency.
Don’t underestimate the operational complexity of running multiple Security Lake instances. Ensure you have the team skills and capacity before implementing distributed patterns. Avoid ignoring the change management and communication required when deploying across multiple business units. Technical excellence alone doesn’t guarantee adoption.
Future-Proofing Your Architecture
Security Lake is evolving rapidly, with AWS adding new capabilities regularly. Design your multi-account architecture with flexibility for future enhancements.
Build on open standards, particularly OCSF, to avoid proprietary lock-in that complicates future migrations. Implement abstraction layers so that changes in underlying AWS services don’t require rewriting all your integrations and analytics. Use infrastructure as code so that architecture updates can be rolled out consistently across accounts and regions.
Stay engaged with the Security Lake roadmap and AWS announcements. Plan for upcoming capabilities that might simplify your architecture or provide new functionality. Regularly review your architecture as your organisation evolves, as mergers and acquisitions might require accommodating new accounts, and geographic expansion might require new regional instances.
Conclusion
Multi-account Security Lake architectures require more sophisticated design than single-account deployments, but they’re essential for organisations operating at scale. The patterns and considerations discussed here provide a framework for making informed architectural decisions that balance visibility, compliance, cost, and operational complexity.
The organisations succeeding with multi-account Security Lake implementations share common characteristics: clear architectural principles that guide design decisions, strong governance that prevents architecture drift, automation that makes complexity manageable, and phased implementation that allows learning and adjustment.
Most importantly, they recognise that architecture is a means to an end. The goal isn’t an elegant diagram but effective security operations that detect and respond to threats faster than adversaries can operate.
Ready to Design Your Multi-Account Security Lake Architecture?
At HOOP Cyber, we’ve designed and implemented Security Lake architectures for global enterprises across industries. Our team understands the regulatory, operational, and technical complexities of multi-account deployments.
Whether you’re planning a greenfield implementation or migrating from existing infrastructure, we can help design an architecture that meets your requirements whilst avoiding common pitfalls.
Contact HOOP Cyber at to discuss your multi-account Security Lake requirements and learn how we can support your implementation.
Amazon Security Lake has transformed how organisations centralise and analyse security data from AWS services. With native integrations for CloudTrail, VPC Flow Logs, Route 53, and other AWS sources, getting started with Security Lake is straightforward. However, the real value emerges when you extend beyond AWS’s native ecosystem to include third-party security tools, on-premises infrastructure, and custom applications.
This guide provides a practical walkthrough for security teams looking to onboard custom sources into Security Lake, addressing the technical challenges, architectural decisions, and operational considerations that matter in production environments.
Understanding the Custom Source Integration Challenge
Most organisations operate heterogeneous security stacks that generate valuable telemetry from sources Amazon Security Lake doesn’t natively support. These might include:
Third-party security platforms such as endpoint detection and response (EDR) solutions, network detection and response (NDR) tools, or cloud access security brokers (CASBs). On-premises infrastructure including legacy SIEM platforms, firewalls, intrusion detection systems, or proxy servers. Custom applications and services that generate security-relevant events but lack standard integration paths. SaaS applications outside the AWS ecosystem such as Microsoft 365, Google Workspace, or Salesforce.
Without these sources, your Security Lake provides incomplete visibility, undermining the core value proposition of centralised security data analysis. The challenge is bringing these disparate sources into Security Lake whilst maintaining data quality, ensuring proper normalisation to OCSF, and avoiding the operational overhead that plagued traditional SIEM implementations.
The OCSF Normalisation Imperative
Before diving into integration mechanics, it’s crucial to understand why normalisation matters. The Open Cybersecurity Schema Framework (OCSF) provides a vendor-agnostic taxonomy for security events. When you normalise third-party data to OCSF at the point of ingestion, you enable:
Cross-source correlation: Query across AWS CloudTrail and your EDR platform using unified field names and data structures. Tool interoperability: Any OCSF-aware security tool can consume your Security Lake data without custom parsers. Future-proof architecture: Adding new sources or switching vendors becomes dramatically simpler when everything speaks the same language. Query efficiency: Normalised schemas enable query optimisations that reduce costs and improve performance.
The investment in proper normalisation at ingestion pays dividends throughout the data lifecycle. Conversely, storing raw logs and normalising at query time creates ongoing operational friction and inflated costs.
Integration Architecture Patterns
There are three primary architectural patterns for custom source integration, each suited to different scenarios:
Pattern 1: Direct API Push
In this pattern, the source system pushes data directly to Security Lake using AWS APIs. This works well when:
The source system supports webhook or API-based event forwarding. Event volumes are moderate and predictable. You require near real-time data ingestion. The source provides structured data that can be transformed to OCSF with reasonable effort.
Implementation involves configuring the source to send events to an AWS Lambda function or API Gateway endpoint, which transforms the data to OCSF format and writes to the Security Lake S3 bucket with appropriate partitioning.
Pattern 2: Agent-Based Collection
For sources that don’t support push mechanisms, agent-based collection provides a reliable alternative. Deploy collection agents that:
Poll source systems on configurable intervals. Buffer events locally to handle network interruptions. Transform data to OCSF before transmission. Support backpressure and rate limiting to prevent overwhelming sources.
This pattern suits on-premises infrastructure, legacy systems, or sources with unreliable connectivity. The trade-off is additional infrastructure to manage and potential for higher latency.
Pattern 3: Streaming Pipeline
For high-volume sources or scenarios requiring complex enrichment, a streaming pipeline architecture provides the necessary throughput and flexibility. This typically involves:
Initial ingestion to a Kinesis Data Stream or Kafka cluster. Stream processing using Kinesis Data Analytics, AWS Lambda, or Apache Flink for transformation and enrichment. Writing normalised events to Security Lake with partitioning optimised for query patterns.
This pattern handles the highest event volumes and supports sophisticated processing logic, but requires more architectural complexity and operational expertise.
Step-by-Step Implementation Guide
Let’s walk through integrating a third-party EDR platform into Security Lake using the direct API push pattern, as it represents the most common integration scenario.
Step 1: Define Your Data Requirements
Before writing any code, clearly define what data you need and how it maps to OCSF. For an EDR platform, you might prioritise:
Process execution events (OCSF class 1007). Network connection events (OCSF class 4001). File activity events (OCSF class 4010). Authentication events (OCSF class 3002).
Document the source data schema and create explicit mappings to OCSF fields. This mapping document becomes your integration contract and ensures consistency across your team.
Step 2: Set Up the Ingestion Infrastructure
Create an API Gateway endpoint to receive events from your EDR platform. Configure a Lambda function as the backend processor. Ensure the Lambda execution role has permissions to write to your Security Lake S3 bucket with the prefix format: aws/REGION/ACCOUNTID/ext/SOURCE_NAME/.
Implement proper error handling, logging to CloudWatch, and dead letter queues for events that fail processing. Production implementations should include retry logic and circuit breakers to handle transient failures gracefully.
Step 3: Implement OCSF Transformation
The transformation logic is where integration quality is determined. For each event type, implement a transformation function that:
Extracts relevant fields from the source event. Maps them to the appropriate OCSF class and attributes. Enriches with contextual information such as asset criticality or threat intelligence. Validates the resulting OCSF event against the schema. Handles missing or malformed data gracefully with appropriate defaults.
Avoid the temptation to include every field from the source. Focus on fields that provide investigative value or support specific detection use cases. Unnecessary fields inflate storage costs and query complexity without adding value.
Step 4: Implement Partitioning Strategy
Security Lake uses Hive-style partitioning with the structure: region=REGION/accountId=ACCOUNTID/eventDay=YYYYMMDD/. When writing events, ensure your Lambda function:
Calculates the correct partition based on the event timestamp (not ingestion time). Creates partition directories if they don’t exist. Writes events in Parquet format with appropriate compression. Batches events when possible to reduce S3 API costs and improve write efficiency.
Proper partitioning is critical for query performance and cost optimisation. Queries that filter by date can skip entire partitions, dramatically reducing the data scanned and associated costs.
Step 5: Configure the Source System
With the ingestion infrastructure in place, configure your EDR platform to forward events to your API Gateway endpoint. Key considerations include:
Event filtering: Only forward events you’ve decided to ingest to avoid processing overhead. Batch size: Larger batches improve efficiency but increase retry complexity. Authentication: Implement API key validation or mutual TLS to prevent unauthorised submissions. Rate limiting: Protect your ingestion endpoint from overwhelming your processing capacity.
Start with a subset of endpoints or event types to validate the integration before expanding to full production scale.
Step 6: Validate Data Quality
Before declaring the integration complete, thoroughly validate data quality:
Schema compliance: Verify that all required OCSF fields are populated correctly. Field mapping accuracy: Spot-check that source fields map to the intended OCSF attributes. Timestamp handling: Ensure event times reflect when events occurred, not when they were ingested. Completeness: Confirm that event volumes match expectations and no data is being silently dropped.
Query the integrated data in Security Lake using Athena to verify that the partitioning is working correctly and that queries return expected results. This validation step prevents discovering data quality issues weeks later when they’ve undermined detection logic.
Step 7: Implement Monitoring and Alerting
Production integrations require observability to detect and resolve issues quickly:
Monitor Lambda execution metrics including invocation count, error rate, duration, and throttles. Track S3 write operations to detect ingestion interruptions. Alert on data freshness to identify when events stop flowing. Monitor transformation error rates and review failed events regularly.
Include integration health in your operational dashboards alongside native AWS source metrics. Custom integrations shouldn’t be second-class citizens in your observability strategy.
Advanced Considerations
Data Enrichment at Ingestion
Consider enriching events during transformation with additional context:
Asset criticality: Tag events from critical systems to prioritise investigations. Threat intelligence: Enrich with indicators of compromise to accelerate detection. User context: Add department, role, or other attributes to support access analytics. Geolocation: Enrich IP addresses with geographic information for anomaly detection.
Enrichment at ingestion is more efficient than enriching at query time, particularly when the same enrichment would be repeated across many queries.
Handling Schema Evolution
Source systems evolve, adding new fields or changing data formats. Plan for schema evolution by:
Versioning your transformation logic to support multiple source schema versions. Implementing schema validation to detect unexpected changes. Designing transformations to degrade gracefully when optional fields are missing. Maintaining backwards compatibility when updating OCSF mappings.
A robust integration anticipates change rather than assuming static schemas.
Multi-Region Considerations
For global deployments, decide whether to:
Replicate all data to a primary region for centralised analysis. Maintain regional Security Lake instances with federated querying. Hybrid approach with regional storage and selected replication based on data sensitivity or compliance requirements.
Data sovereignty requirements often dictate architecture, particularly in regulated industries or when operating in jurisdictions with strict data residency rules.
Cost Optimisation
Custom source integration introduces costs that require active management:
Lambda invocation costs: Batch events when possible to reduce function executions. S3 storage costs: Implement lifecycle policies to transition older data to cheaper storage classes. S3 API costs: Minimise PUT operations through batching and efficient partitioning. Data transfer costs: For on-premises sources, compression reduces network transfer costs.
Monitor integration costs alongside security value to ensure positive ROI. Not every event type justifies the cost of ingestion, storage, and analysis.
Common Integration Pitfalls to Avoid
Having implemented numerous custom integrations, we’ve observed recurring mistakes:
Incomplete OCSF mapping: Failing to populate required fields creates downstream query problems. Ignoring timezone handling: Inconsistent timezone treatment causes temporal correlation failures. Over-collecting data: Ingesting high-volume, low-value events inflates costs without improving security posture. Inadequate error handling: Silent failures allow data gaps to persist undetected. Neglecting partition pruning: Poor partitioning design makes queries expensive and slow.
Learning from others’ mistakes is cheaper than making them yourself.
Real-World Example: EDR Integration
Consider a practical example integrating CrowdStrike Falcon with Security Lake. Falcon provides rich endpoint telemetry but uses its own event schema. The integration approach:
Leverage Falcon’s Event Streams API to receive events via HTTP push. Deploy a Lambda function that transforms Falcon’s DetectionSummaryEvent to OCSF Detection Finding (class 2004). Enrich with host criticality from your CMDB during transformation. Partition by event date and write to Security Lake in OCSF-compliant Parquet format.
This integration enables querying Falcon detections alongside AWS GuardDuty findings and CloudTrail events using unified OCSF fields, dramatically simplifying cross-platform investigations.
Moving Beyond Native Sources
Custom source integration transforms Security Lake from an AWS-centric data repository into a comprehensive security data platform. The investment in proper integration architecture, OCSF normalisation, and operational excellence pays dividends through:
Comprehensive visibility across your entire security stack, not just AWS services. Simplified vendor evaluation and switching when data normalisation eliminates lock-in. Improved detection accuracy through cross-platform correlation. Reduced operational overhead compared to maintaining multiple data silos.
The organisations gaining maximum value from Security Lake are those that view it as a unifying data layer for all security telemetry, regardless of source. With proper integration practices, Security Lake becomes the foundation for truly data-centric security operations.
Ready to Extend Your Security Lake?
At HOOP Cyber, we specialise in custom source integrations that maintain data quality whilst optimising costs. Our team of ex-Splunk engineers and AWS security specialists has integrated hundreds of third-party sources into Security Lake for clients across industries.
Whether you’re integrating a single critical source or building a comprehensive multi-source architecture, we can help design, implement, and operate integrations that deliver long-term value.
Contact HOOP Cyber at to discuss your custom integration requirements and learn how we can accelerate your Security Lake adoption
As we approach 2026, the cyber security landscape stands at a critical juncture. Several pivotal trends are emerging that will reshape how organisations defend themselves against evolving threats. The convergence of cloud adoption, exponential data growth, and economic pressures is forcing a fundamental rethinking of security operations architecture. Here are the key predictions for how the industry will evolve in 2026.
The End of Traditional SIEM Economics
2026 will mark the point where traditional SIEM economics become unsustainable for a majority of organisations. The exponential growth in security data volumes, driven by cloud adoption, remote work, and increasingly sophisticated logging requirements, will force a reckoning for security teams still operating on legacy platforms.
Industry case studies are already demonstrating 50% or greater cost reductions when organisations modernise their security data architecture. Traditional SIEMs that charge based on data ingestion volume simply cannot scale economically when organisations need to ingest petabytes of security telemetry to maintain adequate visibility.
Expect a significant acceleration in migration towards data lake architectures, particularly Amazon Security Lake, where organisations can store vast amounts of security data cost-effectively whilst maintaining the flexibility to query it with multiple analytics tools. This separation of storage from compute represents a fundamental shift in security operations economics.
OCSF Becomes the Default Standard for Security Data
The Open Cybersecurity Schema Framework (OCSF) will transition from an emerging standard to the default expectation for security data normalisation in 2026. Organisations implementing OCSF-based architectures are already demonstrating dramatic operational benefits: faster query times, improved detection accuracy, and seamless tool integration.
Security vendors will face increasing pressure from customers to support OCSF natively. Organisations will no longer accept the burden of custom parsers and proprietary data formats that lock them into specific vendor ecosystems. OCSF support will become a key criterion in security tool procurement decisions throughout 2026.
This standardisation will also enable true federated security, where organisations can query across multiple data repositories using a unified schema. This approach will transition from innovative edge case to standard practice.
The Rise of Natural Language Security Queries
Natural language interfaces for security data will move from novelty to necessity in 2026. The development of natural language search capabilities for security lakes reflects a broader industry recognition that traditional query languages create unnecessary barriers to effective threat hunting.
By the end of 2026, security analysts will routinely ask questions in plain English rather than crafting complex queries in DQL, KQL, or SQL. This democratisation of security data access will enable junior analysts to conduct investigations that previously required expert-level knowledge, addressing the persistent skills shortage in cyber security.
Natural language queries will also be optimised automatically for cost efficiency, helping organisations remain within free query tiers whilst maintaining investigative effectiveness. This represents a significant shift from current practices where poorly constructed queries can generate substantial unexpected costs.
Automated Compliance Becomes Built-In, Not Bolted-On
2026 will be the year when automated compliance reporting transitions from an afterthought to a fundamental architectural requirement. Organisations implementing real-time compliance dashboards built on enriched security data streams are demonstrating the feasibility of this approach.
Organisations will increasingly demand security architectures where compliance frameworks (NIST, MITRE ATT&CK, ISO 27001, NIS2) are automatically mapped at the point of data ingestion. Rather than conducting periodic compliance exercises that require significant manual effort, security teams will maintain continuous compliance visibility through automated categorisation and enrichment.
This shift will be particularly pronounced in heavily regulated sectors and in response to emerging legislation like the UK’s Cyber Security and Resilience Bill. Organisations that fail to implement automated compliance capabilities will find themselves at a significant operational disadvantage.
The Maturity of Autonomous Security Operations
2026 will see autonomous security operations move from theoretical possibility to practical reality for specific use cases. The maturity of automation platforms and SOAR technologies is reaching a point where meaningful automation becomes achievable.
The industry doesn’t foresee fully autonomous SOCs by 2026, but organisations will routinely automate entire investigation and response workflows for well-understood threat patterns. This will free senior analysts to focus on novel threats and strategic security initiatives rather than processing repetitive alerts.
The most significant progress in autonomous operations will occur around:
Automated enrichment of alerts with contextual information from multiple sources
Intelligent routing of alerts based on threat severity and organisational impact
Automated containment actions for specific threat types with defined risk profiles
Self-healing security configurations that respond to detected vulnerabilities
The key enabler will be the availability of comprehensive, normalised security data that automation platforms can reliably query and act upon.
Federated Security Data Becomes the New Normal
2026 will mark the mainstream adoption of federated security architectures, where organisations query across multiple data repositories rather than centralising everything in a single platform. The technical feasibility and operational advantages of this approach are becoming increasingly evident.
Enterprises will increasingly maintain different data stores optimised for different purposes: hot data lakes for active investigations, warm storage for threat hunting, and cold storage for compliance and historical analysis. Rather than forcing all data into a single system, organisations will query across these repositories using unified interfaces.
This federated approach addresses several persistent challenges: reducing costs by matching storage tiers to data access patterns, improving query performance by distributing workloads, and enabling organisations to adopt best-of-breed tools without complex data migration projects.
Intelligence-Led Security Becomes Standard Practice
2026 will see threat intelligence transition from a specialised capability to a foundational element of security operations. The integration of intelligence providers with security data platforms is enabling enrichment at scale.
Organisations will routinely enrich security data with threat intelligence, asset context, user behaviour baselines, and business impact information at the point of ingestion rather than at query time. This “shift-left” approach to enrichment will dramatically improve detection accuracy and reduce investigation times.
Expect increasing sophistication in how organisations consume threat intelligence, moving beyond simple indicator matching to contextual risk scoring that considers the specific threat landscape facing each organisation. Intelligence feeds will be evaluated based on their relevance to the organisation’s actual attack surface rather than their comprehensiveness.
2026 will be the year when cloud-native security architecture transitions from best practice to basic requirement. The advantages of security solutions designed for cloud environments from the ground up are becoming impossible to ignore.
Organisations will increasingly demand security solutions that are designed for cloud environments from the ground up, rather than on-premises tools retrofitted for cloud deployment. This includes native integration with cloud services, consumption-based pricing models, and architectures that can scale elastically based on demand.
Expect particular growth in serverless security data processing, where organisations can handle massive data volumes without managing infrastructure. This approach will transition from innovative edge case to standard practice across the industry.
The Convergence of SecOps and DevSecOps
2026 will see accelerated convergence between security operations and development security. The integration of security into CI/CD pipelines and the emphasis on “security as code” approaches are reaching maturity.
Security teams will increasingly adopt development practices: version-controlled detection rules, automated testing before deployment, infrastructure as code for security tooling, and continuous delivery pipelines for security updates. Conversely, development teams will take greater responsibility for the security of what they build, with security operations providing the data and tools necessary for developers to make informed security decisions.
This convergence will be enabled by common data platforms that both security and development teams can access, breaking down traditional silos that have hindered effective collaboration.
The Data Problem Finally Gets Solved
Perhaps the most significant prediction for 2026 is that the industry will finally acknowledge and address security as fundamentally a data problem. This understanding is maturing across the market as organisations grapple with exponential data growth.
Organisations will stop viewing security tools in isolation and instead focus on building robust security data architectures that can support multiple tools and use cases. This means investing in data normalisation, enrichment, storage optimisation, and query capabilities as primary concerns, with specific security tools selected based on how well they integrate with the underlying data platform.
This shift will be driven by economic realities (unsustainable costs of traditional approaches), regulatory requirements (increasing data governance obligations), and operational necessities (the need to detect and respond to threats faster than adversaries can operate).
Preparing for 2026: Key Recommendations
Based on these predictions, organisations should prioritise several key initiatives in preparation for 2026:
First, conduct a thorough assessment of current security data architecture with honest evaluation of scalability and cost sustainability. Many organisations are closer to an economic breaking point than they realise.
Second, begin planning migration to modern data lake architectures, particularly evaluating Amazon Security Lake for its native OCSF support and cloud-native design. This doesn’t require immediate wholesale replacement of existing tools but rather establishing a foundation for gradual modernisation.
Third, implement data normalisation and enrichment at ingestion points rather than query time. This investment pays immediate dividends in reduced costs and improved analyst productivity.
Fourth, evaluate security tools based on their ability to work with open standards and common data platforms rather than their proprietary capabilities. Lock-in to vendor-specific formats becomes an increasingly expensive liability.
Fifth, begin training security teams on modern data engineering practices. The security analysts of 2026 will need to understand data architecture and query optimisation in addition to traditional security skills.
Final Thoughts
These predictions for 2026 paint a picture of an industry undergoing fundamental transformation. The shift from tool-centric to data-centric security operations represents more than incremental improvement. It’s a necessary evolution to address the scale, complexity, and economic realities of modern cyber security.
Organisations that recognise security as fundamentally a data problem and invest accordingly will find themselves well-positioned for 2026 and beyond. Those that continue with traditional approaches will face increasing costs, decreasing effectiveness, and mounting operational challenges.
The good news is that the technology and frameworks necessary for this transformation already exist. Amazon Security Lake, OCSF, modern automation platforms, and cloud-native architectures provide a proven path forward. What’s required now is organisational commitment to modernisation and willingness to challenge assumptions about how security operations should function.
Organisations that embrace data-centric security don’t just reduce costs. They improve detection capabilities, accelerate incident response, and build more resilient security operations. These aren’t predictions about some distant future. They’re observations about changes already underway that will reach critical mass in 2026.
The question isn’t whether your organisation will adopt these approaches. It’s whether you’ll lead the transformation or scramble to catch up once the tipping point arrives.
Ready to enchance your security operations? At HOOP Cyber, we work with partners across the ecosystem to help organisations harness the power of Amazon Security Lake, unify their data and strengthen security outcomes. Contact us today via .
How a Global Enterprise Solved Multi-Region Compliance and Splunk Cost Challenges with HOOP Lake Architecture and Query Federated Search
When Cloud Growth Outpaces Your SIEM
Security teams today face a fundamental paradox: the more your infrastructure grows, the more security telemetry you generate, and the more your SIEM costs spiral out of control. For one global enterprise operating across 16 AWS regions, this challenge became critical.
Operating in a heavily regulated industry, they needed to keep security data in local regions to meet compliance requirements. Their SOC relied on Splunk Cloud as their primary platform, but it had limited visibility into their vast, distributed AWS infrastructure. The cost of ingesting the massive volumes of CloudTrail, Route 53, VPC Flow Logs, AWS WAF, and EKS audit logs into Splunk wasn’t just expensive, it was unsustainable.
This is where the power of a data-centric approach to security operations comes into play.
The HOOP Lake Approach: Cyber Security as a Data Problem
At HOOP Cyber, we’ve always maintained that cyber security is fundamentally a data problem. The traditional approach of centralising everything into expensive SIEMs made sense in simpler times, but modern cloud architectures demand a different strategy.
This enterprise adopted Amazon Security Lake to collect and store their security telemetry across all 16 regions in OCSF (Open Cybersecurity Schema Framework) format, the same standard that powers HOOP Lake. But collection alone doesn’t solve the problem. The real challenge was making that data accessible, searchable, and actionable for their security analysts without breaking the bank.
Their requirements were clear:
Compliance-first: Data must stay in local international regions
Analyst-friendly: Security teams needed interactive console access, not manual SQL queries
Federated operations: Single searches across authorised regions and sources
Detection automation: Apply existing detection logic to distributed data
Cost predictability: Escape the unpredictable data volume licensing trap
The Solution: HOOP Lake Architecture + Query Federated Search
The winning architecture leveraged the core principles of the HOOP Lake methodology combined with Query’s federated search capabilities:
Stream: Normalising to OCSF at Point of Ingestion
The customer was already collecting logs from their AWS services into Security Lake in OCSF format. This normalisation at the point of ingestion is crucial, it’s the foundation that makes federated search possible. HOOP Lake’s streaming approach automatically receives log information from data sources and transforms it into optimised, enriched OCSF format, creating a unified data model across disparate sources.
Store: Efficient, Distributed Data Lakes
Rather than centralising everything into Splunk, the data remained distributed across 16 Security Lake instances in compressed Parquet format. This approach delivered massive cost savings whilst maintaining compliance requirements. The HOOP Lake store principle focuses on keeping data in a high-performance format with automatic compression, leveraging Parquet tables for optimal performance.
Search: Federated Access Across the Mesh
Here’s where Query’s federated search capability integrated seamlessly with the HOOP Lake architecture. Query enabled analysts to search across all nine sources (three data types across three POC regions) from within their familiar Splunk console using the | queryai command. The searches ran in parallel across distributed sources, with Query automatically breaking down, distributing, normalising, and collating results.
Enrich: Context at Point of Query
The OCSF normalisation meant that an IP address appearing in CloudTrail, Route 53, and VPC Flow Logs could be searched as a unified entity. Query’s natural language to optimised query translation aligned perfectly with HOOP Lake’s orchestration principles, where data flows are manipulated based on unique requirements without rewriting code.
Comply: Real-Time Visibility Across Regions
With data properly normalised and federated search in place, the SOC gained real-time visibility across their entire 16-region estate. Dashboards and detections could run directly against distributed data, maintaining the compliance posture whilst dramatically improving operational efficiency.
The Results: Extended Visibility Without Breaking the Budget
The POC validation demonstrated compelling outcomes that align with HOOP Lake’s core principles:
Cost Transformation
Avoided Splunk’s unpredictable data volume licensing
Leveraged low-cost Security Lake storage + pay-per-query Athena
Query licensing based on connector count, not data volume
Massive savings on data ingestion and indexing
Operational Excellence
Analysts maintained familiar Splunk workflows with minimal changes
Extended visibility to massive Security Lake datasets across 8 event classes
Federated detections running on distributed data without centralisation
Faster investigation and hunting cycles with unified entity searches
Future-Proof Architecture
Scalable to additional AWS regions and data sources
Path to gradually transition from ingest-heavy SIEM to federated mesh
Foundation for onboarding third-party and custom sources
Built on open standards (OCSF) preventing vendor lock-in
Why This Architecture Works: The HOOP Lake Difference
This success story demonstrates several principles that are core to the HOOP Lake methodology:
Data-Centric Foundation: By normalising to OCSF at point of ingestion and storing in efficient formats, the architecture created a unified data fabric that multiple tools could leverage.
Federated Operations: Rather than centralising everything, the architecture kept data distributed whilst making it accessible, meeting both compliance and cost requirements.
Tool Flexibility: Analysts could continue using Splunk whilst Query provided federated access to Security Lake. This pragmatic approach meant no disruptive tool replacements.
Standards-Based: Commitment to OCSF ensured interoperability and prevented vendor lock-in, giving the organisation freedom to evolve their architecture over time.
Cost Optimisation: By separating storage from compute and using federated search, the organisation escaped the “ingest tax” whilst actually expanding visibility.
The Broader Lesson: Rethinking Security Data Architecture
This case study isn’t just about one enterprise solving their Splunk cost problem. It represents a fundamental shift in how security operations should think about data architecture in cloud-native environments:
Old Model: Centralise everything → Index into expensive SIEM → Pay exponentially as data grows
New Model: Normalise at source → Store in efficient lakes → Federate search across sources → Pay predictably for compute
The HOOP Lake approach, powered by Amazon Security Lake and enabled by partners like Query, represents this new paradigm. It’s about building a security data mesh that scales with your cloud infrastructure without scaling your costs proportionally.
Ready to Transform Your Security Operations?
If you’re facing similar challenges (multi-region compliance requirements, exploding SIEM costs, or limited visibility into cloud infrastructure), the HOOP Lake approach combined with Query federated search offers a proven path forward.
HOOP Cyber specialises in:
Amazon Security Lake architecture and implementation
OCSF data normalisation and enrichment
SecOps architecture modernisation
SIEM optimisation and cost reduction
Data source mapping and integration
Whether you’re looking to extend your existing SIEM with federated search capabilities, migrate to a data mesh architecture, or optimise your current security data operations, HOOP Cyber brings deep expertise in building scalable, cost-effective security data architectures on AWS.
Today marks a watershed moment for UK cyber security. The government has introduced the Cyber Security and Resilience Bill to Parliament, representing the most significant overhaul of our nation’s cyber defences since 2018. For organisations managing critical infrastructure and essential services, this represents a fundamental shift in how we approach cyber resilience, incident reporting, and data management.
Why Now?
Devastating cyber-attacks on London hospitals postponed over 10,000 outpatient appointments, whilst breaches at the Ministry of Defence, British Library, and Royal Mail exposed critical vulnerabilities. This year alone the amount of cyber-attacks aimed at UK infrastructure has gone through the roof, and these aren’t isolated incidents. They’re symptoms of an accelerating threat landscape that our existing regulations, inherited from the EU’s 2018 NIS Directive, simply weren’t designed to handle.
The National Cyber Security Centre has been unequivocal: hostile states and state-sponsored actors are ramping up their attacks on UK infrastructure. When the NCSC CEO warns that providers of essential services “cannot afford to ignore these threats”, it’s not hyperbole. It’s a call to action that this new Bill finally addresses.
What’s Changing?
The Cyber Security and Resilience Bill introduces three fundamental shifts that will reshape how organisations approach their cybersecurity posture.
First, the scope is expanding dramatically. Managed IT service providers will be regulated for the first time, recognising that these companies sit at the heart of our digital supply chains. If you’re providing IT management, help desk support, or cyber security services to organisations like the NHS, you’ll now fall under the regulatory framework. Data centres are also being brought into scope, reflecting their new status as critical national infrastructure.
Second, regulators are getting teeth. They’ll have powers to proactively investigate potential vulnerabilities rather than simply responding to incidents after they occur. Cost recovery mechanisms will provide the resources needed for effective oversight. This isn’t regulation for regulation’s sake. It’s about ensuring that essential cyber safety measures are actually being implemented, not just documented in policies that gather dust.
Third, and perhaps most significant for data operations teams, incident reporting requirements are being substantially enhanced. Organisations will need to report a wider range of incidents, including ransomware attacks where they’ve been held to ransom. The government needs better data on cyber threats to build an accurate picture of the threat landscape, and that data starts with your reporting.
The Data Challenge
The Bill doesn’t just require you to report more incidents. It fundamentally changes what you need to know about your environment, how quickly you need to know it, and how you demonstrate compliance to regulators who now have proactive investigation powers.
If a managed service provider you rely on suffers a breach, you need to understand the impact immediately. Which systems did they touch? What data might be compromised? Can you demonstrate adequate visibility into your supply chain risks? These aren’t questions you can answer by trawling through disparate log files or waiting for manual reports.
The reality is that effective compliance with the new Bill requires a step change in how organisations handle their cybersecurity data. You need the ability to normalise data from multiple sources, enrich it with regulatory context, and generate compliance metrics in real time. When regulators come calling, and they will, you need to demonstrate not just that you knew about an incident, but that you understood its significance and responded appropriately.
Real-Time Compliance in Practice
The Bill’s focus on proactive investigation and enhanced reporting creates an environment where real-time compliance isn’t a luxury. It’s table stakes. Organisations need to move beyond periodic assessments and manual compliance checks to continuous monitoring and automated reporting capabilities.
This means transforming raw security event data into actionable intelligence that maps directly to regulatory requirements. When the Bill mandates reporting specific types of incidents, your data infrastructure should be automatically categorising events against those criteria. When regulators request evidence of your cybersecurity posture, you should be able to generate dashboards that show your compliance status across NIST or MITRE frameworks without scrambling to compile information from multiple sources.
The Bill also introduces the concept of a Statement of Strategic Priorities that the Secretary of State will publish for regulators. This creates a unified set of objectives and expectations across sectors. For organisations operating in multiple regulated sectors, this standardisation is welcome. However, it also means your compliance approach needs to be flexible enough to adapt as those priorities evolve.
The Economic Imperative
Cyber-attacks cost the UK an estimated £27 billion annually, with businesses losing around £87 billion between 2015 and 2019. The government has made it clear that enhanced cyber security is an essential pillar of economic growth. You cannot have growth without stability, and you cannot have stability without national security. For businesses, cyber resilience isn’t a cost centre. It’s a competitive advantage and a prerequisite for attracting investment.
What Happens Next?
The Bill is now beginning its journey through Parliament. It will be scrutinised, debated, and refined through multiple readings in both houses before receiving Royal Assent. The government has indicated it will work with key stakeholders throughout this process.
For organisations in scope, or likely to be brought into scope through the expanded remit, the time to prepare is now. Don’t wait for the Bill to become law to assess your cybersecurity data infrastructure. Ask yourself whether you can currently answer the questions regulators will be asking. Can you demonstrate continuous compliance? Can you report incidents with the detail and speed the new requirements will demand? Can you prove you understand and manage your supply chain risks?
The Cyber Security and Resilience Bill represents a once-in-a-generation opportunity to strengthen the UK’s cyber defences. For organisations willing to rise to the challenge, it’s also an opportunity to transform reactive security operations into proactive, data-driven cyber resilience. The question isn’t whether you’ll need to adapt. It’s whether you’ll be ready when the regulations take effect.
The clock is ticking. The threats aren’t waiting. Neither should you.
Ready to transform your cyber posture? Contact us today via to discover how our intelligent data processing platform can reduce your costs whilst enhancing your security posture.
Threat hunting today has evolved from a reactive exercise into a proactive discipline that can mean the difference between detecting an intrusion early and discovering a breach months after the fact. With security data lakes now centralising telemetry from across your entire estate, the challenge is no longer about having enough data but rather knowing which queries will surface the threats that matter.
At the heart of effective threat hunting lies the ability to ask the right questions of your data. Whether you are leveraging Amazon Security Lake, building your own data lake infrastructure, or working with normalised schemas like OCSF, certain queries consistently prove their value in detecting sophisticated threats. This article explores ten essential threat hunting queries that every security operations team should be running regularly against their security lake.
Why Query-Based Threat Hunting Matters
Before diving into specific queries, it is worth understanding why this approach is so powerful. Security data lakes aggregate vast quantities of telemetry from endpoints, networks, cloud services, and applications. This creates an opportunity to correlate events across traditionally siloed data sources, but only if you know what patterns to look for.
Effective queries serve multiple purposes. They establish baselines of normal behaviour, identify anomalies that warrant investigation, uncover indicators of compromise that might otherwise remain hidden, and provide evidence for incident response and forensics. The queries we outline here have been selected based on their proven ability to detect real-world attack techniques mapped to the MITRE ATT&CK framework.
Unusual Outbound DNS Queries
DNS remains a favourite vector for attackers to exfiltrate data or to establish command and control channels. This query identifies DNS requests to newly registered domains, domains with suspicious characteristics, or an unusual volume of requests from a single source.
Look for DNS queries to domains registered within the last 30 days, requests containing excessive subdomain lengths (often used in DNS tunnelling), or endpoints making significantly more DNS queries than their baseline. These patterns frequently indicate data exfiltration or malware beaconing.
Authentication Anomalies Across Multiple Sources
Credential compromise remains one of the most common initial access vectors. This query correlates authentication events from multiple sources, including on-premises Active Directory, cloud identity providers, and VPN concentrators, to identify suspicious patterns.
Focus on failed authentication attempts followed by successful logins from different geographic locations, authentications occurring outside normal business hours for specific users, or lateral movement patterns where credentials are being reused across multiple systems in rapid succession. The power of this query lies in its ability to correlate identity events across your entire estate.
Rare Process Executions
Attackers often use uncommon or living-off-the-land binaries (LOLBins) to evade detection. This query establishes a baseline of process executions across your endpoints and flags processes that are statistically rare.
Examine processes that have executed on fewer than one per cent of your endpoints, binaries running from unusual locations such as temp directories or user profiles, or legitimate system tools being invoked with suspicious command line arguments. This approach is particularly effective at catching fileless attacks and post-exploitation activities.
Privileged Account Activity Outside Normal Patterns
Administrator and service accounts represent high-value targets. This query tracks the behaviour of privileged accounts and alerts when they deviate from established patterns.
Monitor for privileged accounts accessing resources they have never touched before, service accounts authenticating interactively when they should only be used programmatically, or admin accounts performing actions outside their typical schedule. Many advanced persistent threat actors spend weeks studying normal operations before making their move, so baseline deviations are critical indicators.
Lateral Movement via Administrative Shares
Once inside a network, attackers often move laterally using Windows administrative shares. This query identifies suspicious SMB activity that could indicate lateral movement.
Look for accounts accessing admin shares across multiple systems within short timeframes, unusual source-destination pairs based on your network architecture, or file transfers over SMB that do not match typical administrative activities. When enriched with asset criticality data, this query becomes even more powerful at prioritising threats.
Cloud Resource Modifications
As organisations increasingly rely on cloud infrastructure, attackers target cloud resources for persistence and data access. This query monitors for unauthorised or suspicious changes to cloud configurations.
Track security group modifications that open new ingress rules, changes to IAM policies that grant excessive permissions, or the creation of new users or roles outside change management windows. Pay particular attention to modifications made from unusual geographic locations or by accounts that do not typically perform administrative actions.
Data Staging Activities
Before exfiltration, attackers often stage large quantities of data in staging directories. This query identifies unusual data aggregation patterns that could indicate preparation for theft.
Monitor for the creation of archive files (ZIP, RAR, 7z) outside normal backup schedules, unusual amounts of data being copied to external storage locations, or rapid access to numerous sensitive files by a single account. The key is understanding what normal data handling looks like in your organisation.
Suspicious PowerShell and Command Line Activity
PowerShell and other scripting languages are frequently weaponised by attackers for various post-exploitation activities. This query examines command line telemetry for indicators of malicious scripting.
Focus on obfuscated command lines using base64 encoding or unusual character patterns, scripts attempting to download content from the internet, or the invocation of methods commonly used in attack frameworks. When combined with process ancestry information, this query can map out entire attack chains.
Anomalous Network Traffic Patterns
Even with encrypted connections, traffic metadata can reveal malicious behaviour. This query analyses network flow data for patterns inconsistent with normal operations.
Identify unusual port combinations, connections to IP addresses with poor reputations or associated with threat intelligence feeds, or traffic volume spikes from endpoints that do not normally generate significant network activity. Beaconing patterns, where connections occur at regular intervals, are particularly indicative of command-and-control traffic.
Indicators of Persistence Mechanisms
Attackers establish persistence to maintain access even after system reboots. This query hunts for common persistence techniques.
You should ensure you examine new scheduled tasks or cron jobs, modifications to registry run keys or startup folders, or the creation of new services. Additionally, look for changes to authentication mechanisms such as the addition of SSH keys or modifications to PAM configurations. Persistence mechanisms often provide the best evidence of compromise, as they must survive reboots to be effective.
Implementing These Queries in Your Environment
The value of these queries lies not just in their individual capability, but in how they work together to provide comprehensive coverage of attack techniques. When implementing them, consider the following best practices.
Firstly, tune each query to your environment. Generic queries will generate excessive false positives, so invest time in understanding your baselines. Secondly, automate where possible. These queries should run continuously, with results feeding into your SOAR platform or alerting systems. Thirdly, enrich your data. Threat intelligence feeds, asset criticality information, and user context all make these queries more effective.
Finally, document your findings. When a query identifies a genuine threat, record the indicators and refine the query to catch variations of the same technique. Threat hunting is an iterative process that improves with each investigation.
Conclusion
Effective threat hunting requires both the right data and the right questions to ask of that data. Security data lakes provide unprecedented visibility into your security posture, but only if you actively interrogate that data with purposeful queries. The ten queries outlined here represent a solid foundation for any threat hunting programme, covering initial access, lateral movement, persistence, and exfiltration across both on-premises and cloud environments.
As threats evolve, so too must your queries. Treat these as starting points rather than static rules, continuously refining them based on emerging threats, changes in your environment, and lessons learned from each investigation. When implemented consistently and tuned appropriately, these queries will significantly enhance your organisation’s ability to detect and respond to advanced threats before they cause significant harm.
Ready to transform your cyber posture? Contact us today via to discover how our intelligent data processing platform can reduce your costs whilst enhancing your security posture.
