The Definitive Guide to what Cybersecurity Mesh Architecture (CSMA) should look like.

This is part 3 of a 3 part blog series about Data Mesh intended to educate and serve as a decision-making tool for security leaders rethinking their data strategy. You can read more in Part 1 and Part 2.

Reimagining CSMA: What Security Architecture Should Actually Look Like

Now that you fully understand Data Mesh (from part 1 of this series), what Cybersecurity Mesh Architecture is, and our take on how a federated-first Data Fabric can enable a proper Security Data Mesh (from part 2 of this series); let’s focus our attention on what CSMA will look like with Data Mesh principles applied. CSMA’s five layers aren’t inherently wrong – tool integration, analytics, identity, policy, and visibility are all necessary.

So what should security architecture actually look like? The good news: CSMA’s five layers aren’t wrong, just poorly organized. By applying Data Mesh principles, you can achieve the integration, analytics, and visibility CSMA promises (without the centralization bottleneck). But before reimagining the architecture, let’s talk about the organizational work required to make it real.

The Work Before the Work

Before you start on a Data Mesh project – or any security project – you need to collect information and build your own internal intelligence report. Gartner recommends as much too: “Use manual inventory or existing repositories to create an inventory of all your cybersecurity tools [and] enumerate the number of dashboards, analytics data lakes, security operations tools, and management consoles in the organization today.” This isn’t too far from what we do in Phase 1 of our own consultative SecDataOps Workshops, but it’s also important to find out who administers and owns all of those products, processes, and tools.

This ground truth will give you a roadmap of what to attack, because at the very least you will need a reorganization of personnel and prepare to take ownership and responsibility of your Domains. This can be hampered due to the “ownership” dynamics in virtually every tool-centric organization, not to mention the actual budgeting and cost considerations from both an operational and more strategic IT Financial Management perspective. In many ways, it may take even longer to prepare to align against the Domain Ownership and functional alignment that Data Mesh prescribes versus centralizing every tool into the five Layers of CSMA. 

Some of the very first questions you should ask include the following, but this list is not exhaustive nor in priority order.

Organizational Readiness

  • Do we have clear business and technical owners of every tool, process, and data source?
  • Can we organize our teams into functional domains (TVM, IAM, Cloud Security) rather than tool teams?
  • Can we, as an organization, agree on interoperability standards (like OCSF) and quality metrics (SLAs/SLOs)? 

Technical Capability

  • Do we have the skills to interact with data via APIs and orchestration? If not, where are the gaps?
  • What are our “sources of truth” for each security discipline, and do they support open standards?

Data Strategy

  • What data must we persist due to compliance (e.g., Entra ID audit logs beyond 30 days)?
  • What data can definitively stay in place behind native APIs vs. what needs centralization?

SecDataOps is hard in practice, and harder still with Data Mesh’s organizational transformation. After conducting your discovery and skills gap analysis, Domain teams must decide which tools to keep, consolidate, or migrate. This may require a SIEM modernization project, adoption of federated infrastructure like Query, or building self-service planes from scratch. Whatever path you choose, the federation of domain teams must agree on interoperability standards, data quality SLOs, and the self-service experiences needed for producers and consumers. Only then can you start building.

Data Mesh-Aligned CSMA Layers

Now, you’ve done all that in record time, how will the CMSA Layers look like in this new world?

Instead of SAIL (centralized analytics)

  • Functional Domains own their analysis as products: TVM Domain, Threat Intelligence Domain, Cloud Security Domain, etc.
  • Each Domain serves analysis from where data lives, using federated infrastructure, either consumed from a Data Fabric, a security data lakehouse, or some other repository the Domain is skilled in using.
  • Each Domain consumes resources to facilitate construction of their Data Product(s) via a Self-Service Data Infrastructure plane, such as the ability to build new Kafka brokers, Streamlit or PowerBI dashboards, create pipelines in their SDPP, kickoff SOAR pipelines, or otherwise.
  • Global OCSF standards ensure cross-domain queries work, but domains control their own models; any validation is automated throughout the environment.

Instead of IML (centralized asset inventory):

  • Infrastructure Services Domain owns asset inventory as a first-class data product, across all of the various ways assets are expected to be reported across your organization
  • They’re accountable for quality, freshness, deduplication – with SLOs consumers can rely on
  • Assets stay distributed (CMDB, cloud APIs, EDR) but served through unified OCSF schemas, agreed upon by the federation of Domains, either using a singular Event Class or multiple use-case aligned Event Classes.

Instead of IFL (centralized identity fabric):

  • Identity Services Domain owns identity/access data products
  • Operational identity policy may still be centralized (Zero Trust enforcement), but data about identity is owned and served by this domain
  • Authentication logs, privilege changes, access patterns become trustworthy Data Products

Instead of C3PM (centralized policy):

  • Federated Computational Governance replaces manual policy committees, and executes on all agreed upon interoperability standards
  • Operational security policies (DLP, firewall rules) can remain centralized and owned by the actual security subdisciplines, which may overlap with the Domain Team
  • Data governance policies (schema validation, SLOs) are encoded in the platform and automatically enforced
  • Domains set local policies within global constraints

​​Instead of ODL (centralized dashboard):

  • Self-Service Consumption through federated infrastructure that was previously built out
  • TVM team builds dashboards against their products, SOC builds theirs, executives build theirs
  • When one domain’s schema changes, only their consumers are affected – not the entire organization – and all schema changes can be accounted for by the usage of mutatable schemas (e.g., Apache Iceberg) or other agreed upon interoperability standards

This is CSMA with actual Data Mesh principles, but again, it is not an exhaustive list of examples or duties you will be expected to carry out as a Domain team. What you still get at the end of the day are integrated tools, shared information and intelligence, and unified visibility. What you avoid is the centralized bottleneck that is introduced from hub-and-spoke, tool-centric architectures such as CSMA 3.0 or otherwise. As long as you keep agreement with data quality and metrics, stick with interoperability and not centralization, and do not compromise on the accountability and rigor needed for Domain teams you are more than likely to succeed.

Finally, you need not do this all at once. After all of the ground work you do on discovery and preparation, you can simply identify one high-pain Domain – Pick AppSec, Cloud Security, IAM, or TVM; anywhere where data access is especially painful.

Closing Thoughts

We’ve shown you the problems with CSMA and explained Data Mesh and we’re here to help if you want it. While the critique was stabby at times, CSMA is not garbage nor is Data Mesh gospel, at the end of the day we’re just all trying to use data to enable our decision making across all of the jobs to be done under our departmental remits.

Is Data Mesh Right for Your Organization?

Data Mesh isn’t a silver bullet. It’s an organizational transformation that requires executive buy-in, cultural change, and sustained effort. Not every organization needs it, and not every organization is ready for it. Here’s how to assess if it makes sense for you:

You might benefit from Data Mesh if:

  • Your security org has 50+ people with distinct subdisciplines (TVM, IAM, Cloud Security, AppSec, SOC, etc.)
  • SecDataOps is consistently cited as a bottleneck for security operations
  • You have 10+ security tools and struggle to correlate data across them
  • Data engineering skills exist in pockets of your org, but aren’t centralized
  • Your SIEM costs are ballooning, but you still can’t answer basic questions quickly
  • Domain teams repeatedly request data that SecDataOps can’t deliver fast enough
  • Organizational culture supports accountability and cross-functional collaboration

You might NOT need Data Mesh if:

  • Your security org is <15 people with generalists wearing multiple hats
  • You have strong centralized SecDataOps with deep domain expertise across all areas
  • Your tool sprawl is minimal (you’ve successfully consolidated to 3-5 platforms)
  • Data questions are answered in minutes/hours, not days/weeks
  • Cultural resistance to decentralization is insurmountable in your org
  • Leadership won’t commit to multi-quarter organizational transformation
  • Your biggest pain points are operational (detection engineering, response) rather than data access

The middle ground: Federated infrastructure without full organizational transformation

You don’t need to fully commit to Data Mesh to benefit from its infrastructure patterns. Many organizations start by:

  • Implementing federated query infrastructure (like Query) to reduce centralization pain
  • Adopting OCSF for interoperability without mandating domain ownership
  • Building self-service consumption layers while keeping centralized production
  • Piloting domain ownership in one high-pain area (TVM, Cloud Security) before expanding

This “mesh-lite” approach gives you faster data access and reduced brittleness without requiring organizational restructuring. It’s a pragmatic first step that can evolve into full Data Mesh later if needed. Think of it as testing the waters before diving in.

Where to Start

Whether you pursue full Data Mesh, mesh-lite infrastructure, or stay with centralized architecture, here are pragmatic steps to improve your security data operations:

Immediate (This Quarter):

  • Audit your current state – Map where security data lives, who owns it, how it’s accessed, and where bottlenecks occur. Use the discovery questions from the previous section as a starting point.
  • Adopt OCSF – Even without Data Mesh, standardizing on OCSF improves future flexibility and reduces vendor lock-in. Start by mapping your most-used data sources to OCSF event classes.
  • Identify one high-pain domain – Pick TVM, IAM, Cloud Security, or AppSec where data access is especially painful. This becomes your pilot.

Near-term (6-12 Months): 

  • Pilot federated infrastructure: Test Query or similar tools (Cribl Search, Splunk Federated Search) on your high-pain domain to prove value. Measure time-to-answer before and after.
  • Define your first Data Product: Have one team own end-to-end accountability for serving data with SLOs. This doesn’t have to be perfect; it just needs to be better than what you have today.
  • Measure impact: Track time-to-answer, engineering costs, and consumer satisfaction before/after. Use this data to justify expansion (or course-correct).

Long-term (12-24 Months)

  • Expand domain ownership: Roll federated infrastructure and data product patterns to other domains based on pilot learnings.
  • Implement federated governance – Encode global standards (OCSF validation, data quality checks) into your platform. Make compliance automatic, not manual.
  • Build self-service planes: Create DIPP/DPDXP/DMSP infrastructure tailored to your security teams’ skill levels. Start simple and add sophistication as teams mature, but ensure you are meaningfully abstracting difficult away from less technical personas and consumers.

The key is incremental progress. Start with infrastructure that reduces pain, then evolve organizational patterns as you prove value. Every connection you make improves visibility and reduces operational overhead.

Let’s Talk About Your Architecture

At Query, we’ve helped dozens of security organizations rethink their data architecture – from Fortune 10 enterprises to high-growth startups. Sometimes that means Data Mesh, sometimes it means federated infrastructure without full organizational change, and sometimes it means optimizing what you already have.

We offer consultative Security Data Operations Assessments where we’ll:

  • Map your current data landscape and identify bottlenecks
  • Evaluate whether Data Mesh, “mesh-lite”, or optimized centralization makes sense for your org
  • Provide a roadmap tailored to your maturity, team skills, and budget constraints
  • Be honest about where Query fits (and most importantly, where it doesn’t)

We’re upfront: Data Mesh isn’t always the answer, and we won’t recommend infrastructure you don’t need. Our goal is to help you make informed decisions about security data operations, whether or not Query is part of the solution. We’ve turned away organizations where centralization actually made more sense, and we’ll do the same for you if that’s the right call.

Interested in a conversation? Request a Security Data Operations Assessment

Additional Resources

If you want to dive deeper into the concepts covered in this whitepaper:

Data Mesh Foundations:

OCSF and Interoperability:

Gartner CSMA Research:

Query Resources:

Conclusion

Security architecture is hard. Data architecture is hard. Doing both simultaneously while threat actors don’t take a break? Even harder.

CSMA attempts to address real problems – tool sprawl, fragmented visibility, inconsistent policies – but it prescribes centralization as the solution. Data Mesh offers an alternative path: domain ownership, federated infrastructure, and computational governance that scales with organizational complexity.

Neither approach is universally correct. Both require investment, cultural change, and sustained leadership commitment. The difference is whether you believe the solution to centralization bottlenecks is better centralization or intentional decentralization.

We’ve laid out the case for decentralization. We’ve shown what Data Mesh actually requires versus what CSMA delivers. Now it’s up to you to decide which path makes sense for your organization.

Whatever you choose, start small, measure impact, and iterate. Your future self will thank you.

If you’re considering your security data strategy and want to explore the benefits of a decentralized approach, reach out to us. SecDataOps savages are standing by…

Stay Dangerous.

This is part 3 of a 3 part blog series about Data Mesh intended to educate and serve as a decision-making tool for security leaders rethinking their data strategy. You can read more in Part 1 and Part 2.