Perspective

The Federated SOC

Why the organisations that adopt a federated Security Operations Centre see it as the best thing to happen to security operations in a decade, and why the business case usually starts with the SIEM bill.

New to this? Start with the plain-language version.

1. What a federated SOC is

A traditional SOC is built around one idea: collect everything in one place, then analyse it there. Every log, from every system, in every country, is shipped into a single central SIEM, and a single central team watches it.

A federated SOC turns that around. Analysis moves to the data instead of the data moving to the analysis. Security telemetry stays where it is generated, in the region, the business unit, the cloud account or the subsidiary that owns it. Detection logic, standards and governance are defined once, centrally, and pushed out to every location. Only what matters, the alerts, the enriched findings and the high-value events, flows back to a central hub for correlation, case management and oversight.

A federated SOC is not the same as simply having several separate SOCs. Separate SOCs drift apart: different tools, different rules, different definitions of an incident, no shared picture. Federation keeps the common layer, meaning schema, detection content, severity model, playbooks and reporting, while letting the heavy lifting happen locally.

2. The problem it solves

The centralised model made sense when log volumes were modest and most systems lived in one or two data centres. Neither is true any more. Organisations operating across Asia Pacific typically face all of the following at once:

• Telemetry volume growing faster than budget. Cloud audit logs, endpoint telemetry, identity events, SaaS activity, network flows and DNS have each multiplied. Security data commonly grows year on year at a rate that no security budget matches.
• Ingest-based pricing. Most SIEM platforms charge, directly or indirectly, by the volume of data ingested or the compute used to process it. Every additional gigabyte costs money whether or not it ever contributes to a detection.
• The forced trade-off. Faced with that bill, teams start dropping data sources or shortening retention. Visibility is sacrificed to stay within budget, which is exactly backwards.
• Data movement costs. Shipping raw logs across regions and out of cloud providers incurs network egress charges and adds infrastructure that has to be built and maintained.
• Data residency and privacy rules. Raw security logs are full of personal information: user names, email addresses, IP addresses, device identifiers, sometimes message content. Moving them across borders brings legal obligations that differ country by country.
• A patchwork of acquired and regional tooling. Subsidiaries and acquisitions arrive with their own tools and teams. Forcing everything into one central platform is slow, expensive and politically difficult.
• A single point of failure. When the central pipeline or platform has a problem, the whole organisation goes blind at once.

A federated SOC addresses every one of these with a single architectural change.

3. How it works

The nodes

Each node is a place where telemetry is collected, stored and analysed close to where it is produced. A node might be a country operation, a cloud environment, a business unit, or an acquired company that keeps its existing security stack. Each node:

• stores its raw telemetry locally, usually in low-cost object storage or a data lake rather than premium SIEM storage;
• normalises events into the organisation's common schema as they arrive;
• runs the centrally managed detection rules against its own data, near real time;
• answers search queries from the hub on demand, returning results instead of raw data;
• forwards alerts, enriched findings and a small set of high-value event types to the hub.

The hub

The hub is the SOC's brain. It does the things that genuinely need a global view:

• Cross-node correlation: spotting the same attacker, credential or technique across countries and business units.
• Case management and incident command: one queue, one severity model, one record of every incident.
• Detection engineering: writing, testing, versioning and deploying detection content to every node as code.
• Threat intelligence: distributing indicators and hunting hypotheses to every node at once.
• Governance and reporting: coverage, performance and risk metrics for leadership and regulators, consistent across the whole organisation.

Federated search

The capability that makes federation practical is federated search: an analyst at the hub asks one question, the question is sent to every relevant node, each node runs it against its local data, and the results come back merged into one answer. The analyst sees one investigation. The data never had to move.

The routing layer

Between sources and destinations sits a telemetry pipeline that decides, event by event, where data goes: high-value security events to the SIEM, bulk telemetry to low-cost local storage, noise filtered or summarised, sensitive fields masked before anything crosses a border. This layer is where most of the cost control lives, and it can be changed without touching the sources.

4. Where the cost savings come from

This is the part that gets budget holders' attention. The savings are not one trick; they come from several independent sources that add together.

4.1 SIEM ingest and licensing

In most environments, a large share of telemetry by volume is high-volume, low-signal data: firewall and network flow records, DNS queries, verbose endpoint process events, load balancer and proxy logs, debug-level cloud logs. It is essential for investigations and hunting, but rarely fires a detection on its own.

In a centralised model, all of it is paid for at SIEM prices. In a federated model, it is stored and searched at the node at storage prices, and only the events that drive detections are sent to the SIEM. Because SIEM cost tracks ingest, reducing what the SIEM ingests reduces what the SIEM costs, roughly in proportion.

4.2 Storage tiering and retention

Premium SIEM storage is expensive per gigabyte retained. Object storage at the node is a small fraction of that. Federation lets an organisation keep hot, fast storage for recent high-value data and push everything else to cheap storage that remains searchable. Retention requirements of a year or more stop being a budget crisis.

4.3 Network egress and transport

Every gigabyte that does not leave its region is a gigabyte with no cross-region transfer or cloud egress charge, and no central collection infrastructure to size, run and patch. For organisations with heavy cloud usage across several regions, avoided egress alone can be material.

4.4 Avoided rip-and-replace

When a subsidiary or acquisition already has a working security stack, federation lets it join as a node. The alternative, migrating it onto the central platform, typically means new licences, months of engineering and a period of reduced visibility during the cutover. Federation turns a migration project into an integration project.

4.5 Fewer duplicated tools and teams

Organisations that have drifted into several independent SOCs pay for duplicated platforms, duplicated detection engineering and duplicated threat intelligence. Federation consolidates the expensive, specialised work at the hub, written once and used everywhere, while keeping local operations lean.

4.6 Staffing efficiency

A federated SOC across Asia Pacific time zones can run follow-the-sun coverage with analysts working local daytime hours, reducing reliance on night shifts and the premiums, fatigue and turnover that come with them. Analysts are also more productive when they work on higher-fidelity alerts (see section 6).

4.7 Compliance overhead

When raw personal data stays in-country by design, the legal work, transfer assessments and contractual mechanisms needed to move it across borders shrink dramatically. What crosses borders is a minimised, often pseudonymised, set of findings, which is far simpler to justify and document.

5. An illustrative cost model

The figures below are a worked example built on stated assumptions, not a benchmark. Your numbers will differ. The point is the shape of the result.

Assumptions. An organisation operating in five Asia Pacific countries generates 2,000 GB of security telemetry per day. On analysis, 30% of that volume is high-value data that drives detections (identity, endpoint alerts, privileged activity, critical cloud control-plane events, security tool alerts). The other 70% is bulk telemetry needed for investigation and hunting. Ninety days of hot retention and one year of searchable retention are required.

Under these assumptions, the SIEM line of the budget falls by roughly two thirds, before counting avoided egress, avoided migrations and staffing effects. Part of the saving is reinvested in node storage and the routing layer, but those cost a fraction of the SIEM capacity they replace.

The more important outcome sits in the bottom two rows. The organisation is not just paying less; it is seeing more, and it has removed a category of regulatory exposure.

Many organisations find their own high-value share is lower than 30%, which makes the saving larger. A data source inventory (see section 10) establishes the real figure in a few weeks.

6. Why the SIEM becomes more valuable, not less

A common first reaction is that federation sidelines the SIEM. The opposite is true. Federation lets the SIEM do what it is best at, and stops it being used as a very expensive log archive.

Signal, not noise

When the SIEM receives curated, normalised, high-value data instead of everything, correlation rules run against cleaner inputs. False positives fall, alerts carry more context, and analysts spend their time on real threats. The cost per useful alert, arguably the metric that matters most, drops sharply.

Better detections, written once

Detection-as-code at the hub means every rule is version-controlled, peer-reviewed, tested against sample data and deployed to every node at the same time. A new detection written in response to an incident in one country protects every country by the end of the day.

Coverage without compromise

Because bulk data no longer has to be justified at SIEM prices, data sources that were previously dropped can be switched back on and stored at the node. Visibility gaps close. Threat hunters get a year or more of history to search, not two weeks.

Faster investigations

With federated search, an analyst can pivot from a SIEM alert straight into the full raw telemetry at the relevant node, in one workflow, without waiting for data to be rehydrated or requesting it from a regional team.

A platform that scales with the business

New countries, new cloud accounts and new acquisitions join as nodes. SIEM cost grows with the amount of high-value data, not with the total size of the estate. Security operations stop being the bottleneck on expansion.

Resilience

Nodes continue detecting and storing locally if the link to the hub is interrupted, then forward queued findings when it returns. There is no single pipeline whose failure blinds the whole organisation.

7. Why it fits Japan and Asia Pacific so well

Federation is useful anywhere, but Asia Pacific has characteristics that make it unusually compelling.

A patchwork of privacy and data rules

Japan's Act on the Protection of Personal Information sets conditions on transferring personal information to third parties outside Japan. China's Personal Information Protection Law and data security rules impose localisation and security assessment requirements in many cases. Singapore's Personal Data Protection Act, Australia's Privacy Act, Korea's Personal Information Protection Act and India's Digital Personal Data Protection Act each add their own requirements. A centralised SOC has to satisfy all of these for every raw log it moves. A federated SOC keeps raw data in place and moves only minimised findings, which is a far easier position to defend in every jurisdiction.

Distance and time zones

The region spans from India to New Zealand. Central collection across those distances adds latency and transport cost. Time zones that make a single central team awkward make a follow-the-sun federated team natural.

Language and local context

Phishing lures, fraud patterns, business processes and regulators are local. Analysts at or near the node understand them in their own language and context. Federation keeps that local knowledge in the loop while giving it global tooling and support.

Group structures and subsidiaries

Many organisations in the region operate through group companies, joint ventures and acquired businesses with real operational independence. Federation respects that independence and still delivers group-wide visibility and consistent standards.

8. The people side

A federated SOC changes how security teams work, mostly for the better.

• Hub roles focus on specialised, high-leverage work: detection engineering, threat intelligence, incident command, platform engineering and metrics.
• Node roles focus on triage, local investigation, liaison with local IT and business teams, and local regulatory reporting.
• Career paths open up between nodes and the hub, which helps retain scarce talent.
• Clear ownership through a simple responsibility matrix defines who detects, who triages, who responds and who reports, at each severity level.

9. What it takes to get right

The benefits are real, and so are the conditions for achieving them. Organisations that succeed with federation invest in a few foundations up front.

• A common schema. Every node must normalise events to the same vendor-neutral data model, or federated search and shared detections fall apart.
• Detection-as-code discipline. Rules live in version control with testing and automated deployment. Hand-edited rules on individual nodes defeat the purpose.
• Deliberate routing decisions. The split between "goes to the SIEM" and "stays at the node" must be decided source by source, based on detection value, and reviewed as threats change.
• Query performance expectations. Searching bulk data at the node can be slower than searching hot SIEM storage. That is acceptable for hunting and investigation if the high-value, time-critical data is in the hub.
• Strong governance. Shared playbooks, a single severity model, and regular reviews of node health, coverage and detection performance keep the federation from drifting into separate SOCs.

10. A practical roadmap

1. Inventory and classify (weeks 1–6). List every data source by volume, detection value, retention need and residency constraint. This step alone usually reveals the size of the opportunity.
2. Define the common layer (weeks 4–10). Agree the schema, severity model, playbooks, responsibility matrix and detection-as-code workflow.
3. Pilot one node (months 2–4). Choose a region or cloud environment with high volume and clear residency needs. Stand up local storage, the routing layer and federated search, and connect it to the hub.
4. Re-route and measure (months 3–6). Move bulk telemetry for the pilot node out of the SIEM. Track ingest, alert quality and investigation times before and after.
5. Expand node by node (months 6–18). Add regions, clouds and subsidiaries in order of savings and risk. Each one is faster than the last.
6. Optimise continuously. Revisit routing decisions quarterly, retire unused data, and add detection coverage where the inventory shows gaps.

11. How to measure success

12. Common questions

Does federation mean replacing our SIEM?

No. In most cases the existing SIEM becomes the hub, or part of it. What changes is what it ingests.

Is it only for very large organisations?

The savings scale with data volume and geographic spread, so the case is strongest for organisations operating in several countries or clouds. Mid-sized organisations with significant cloud telemetry or strict residency needs often benefit too.

What about real-time detection on data that stays at the node?

Nodes run detections locally in near real time. Keeping data local does not mean leaving it unwatched.

Will regulators accept it?

Keeping raw personal data in its country of origin and transferring only minimised findings is generally easier to justify under Asia Pacific privacy regimes than moving everything to a central location. Specific obligations should be confirmed with legal counsel in each jurisdiction.

How long until savings appear?

Savings begin as soon as the first node's bulk telemetry is re-routed away from the SIEM, typically within the first few months.