Organizing cybersecurity: centralized, federated or product-aligned

When an organization discusses how to structure cybersecurity, the conversation usually starts with the org chart: who the CISO reports to, how many people the team has, whether it sits under Technology or Risk. Those are fair questions, but they come too late. A different question should come first: where are day-to-day security decisions made, and who is accountable for them?

There is no structure that is right for every organization. There are three reference models, each with known strengths and risks, and one rule that applies to all of them: some functions always stay central, no matter how much of the rest is distributed. This article walks through the models, proposes what to centralize and what to distribute, and shows how to use NIST CSF 2.0 and the NICE Framework to assign roles without ambiguity.

Why structure matters

Structure sets three things that are hard to change later: how fast a security question gets answered, how consistent criteria are across teams, and how clear accountability is when something goes wrong. A structure that does not match how the organization delivers technology produces recognizable symptoms: review queues that slow projects down, exceptions nobody records, development teams that see security as red tape and security teams that are always stretched to the limit.

That last point matters. A central team that absorbs every review, every alert and every question ends up exhausted, and burnout is an operational risk in its own right. We cover it in detail in burnout in security teams.

Three organizational models

The three models differ in where security staff sit and who they report to. The diagram summarizes them.

Centralized

A single team under the CISO runs or approves every security activity: policy, vulnerability management, architecture reviews, monitoring and response. The strength is consistency: one set of criteria, one toolset, one risk register. The risk is the bottleneck. As the number of development teams grows, the central team turns into a queue and security starts to be seen as a brake.

It fits mid-sized organizations with few delivery teams, a single jurisdiction or regulation that demands strict traceability of every decision.

Federated

A small central team sets policy, the risk framework and standards, and each business unit, subsidiary or country has its own security team. That team reports in a solid line to its unit and in a functional line to the CISO. The strength is proximity to the business and to local regulation, which matters for groups operating across several Latin American countries or between Latin America and Spain. The risk is uneven standards: if the functional line is weak, each unit interprets the policy its own way.

It fits groups with subsidiaries, different regulatory regimes per country or units with their own budgets.

Product-aligned

Security is built into the product teams. Each team owns the security of what it builds and runs, supported by champions and by specialists who rotate across teams. The center sets guidance, maintains a shared security platform (code analysis, secrets management, secure templates) and keeps the functions that are never distributed. The strength is that security enters the delivery flow instead of being reviewed at the end. The risk is diluted accountability: if everyone is responsible and no one is accountable, cross-cutting risks end up without an owner.

It fits organizations that already work with stable product teams and an internal platform. If that is your case, this model builds on what we describe in the product operating model and platform engineering.

Comparing the three models

The table summarizes the criteria that weigh most in the decision. No model wins every row.

Criterion	Centralized	Federated	Product-aligned
Consistency of criteria	High	Medium; depends on the functional line	Medium; depends on guidance and platform
Speed of response to teams	Low as demand grows	Medium	High
Fit with local regulation	Low	High	Medium
Coordination cost	Low	High	Medium
Main risk	Bottleneck and burnout	Uneven standards across units	Diluted accountability
Prerequisite	Sufficient central budget	Shared policy and metrics	Stable product teams and an internal platform

In practice, many organizations combine models: federated across countries and product-aligned inside the digital unit, for example. Combining is fine, as long as the split of functions is written down.

What always stays central and what gets distributed

Whichever model you choose, we recommend keeping four functions at the center, because their value depends on there being a single version:

• Policy and standards. One security policy, one set of standards and a single exceptions process. Units can detail procedures, not rewrite the policy.
• Risk management. One risk register, one assessment methodology and a risk appetite approved by leadership. Without them you cannot give the board a consolidated view.
• Incident response. One plan, one escalation chain and single coordination for major incidents. Local teams execute, but an incident that spans units cannot have two commanders.
• Reference architecture. Approved patterns for identity, encryption, segmentation and logging. This is what lets distributed teams make fast decisions without reinventing controls.

What distributes well: applying controls in each system, fixing vulnerabilities, threat modeling for each product, first-pass change review and day-to-day access management. The rule of thumb: centralize what sets the criteria and distribute what applies them.

Security champions in development teams

A security champion is a member of a development or operations team who, without leaving their role, takes on an additional security responsibility: they know the guidance, spot risks early, route questions to the central team and spread good practice. Champions are what make the federated and product-aligned models viable without multiplying security headcount.

The OWASP Security Champions Guide sets out ten principles for these programs. Among them: start with a clear vision for the program, secure management support, nominate a dedicated person to coordinate it, build a community, reward the responsibility champions take on, invest in their development and anticipate personnel changes. We would add:

1. Allocate explicit time. A champion without hours reserved in the team's planning is a volunteer who will drop out in the first demanding quarter. For example, a fixed share of their capacity agreed with their manager.
2. Define what they decide and what they escalate. The champion can approve changes that follow the reference architecture; exceptions go to the center.
3. Provide tools, not just courses. Threat modeling templates, checklists by type of change and access to their product's findings.
4. Measure the program. How many teams have an active champion, vulnerability remediation time per team and questions resolved without escalation.

Roles and responsibilities with NIST CSF 2.0 and NICE

NIST CSF 2.0, published in February 2024, added the Govern function and, within it, the GV.RR category (roles, responsibilities and authorities). In short, its outcomes ask that organizational leadership be accountable for cybersecurity risk, that roles and authorities be established, communicated, understood and enforced, that resources be adequate for the strategy and that cybersecurity be part of human resources practices. We cover the full function in NIST CSF 2.0 and the Govern function.

GV.RR does not tell you which model to pick. It asks that, whichever you pick, responsibilities be written down and honored. A useful format is a RACI matrix per activity (policy, risk assessment, architecture review, vulnerability remediation, incident response) with one column per actor: CISO, central team, unit or product teams, champions and business owners.

To describe positions, the NICE Framework (NIST SP 800-181 Rev. 1) offers a common language built on task, knowledge and skill statements, grouped into work roles. Using it keeps "security analyst" from meaning different things in each unit and makes it easier to plan training and hiring.

How to choose and how to transition

We recommend deciding with four questions: how many delivery teams you have and how they work, how many regulatory jurisdictions apply, how mature your internal platform is and where your security queues are today. With those answers, the model is usually obvious.

Changing models does not happen overnight. A reasonable sequence: first lock in the four central functions and the responsibility matrix, then launch champions in the highest-risk teams and, only once guidance and platform work, move decisions to the teams. Before shifting formal responsibilities, validate the design with Risk, Compliance and Human Resources, because it affects reporting lines and regulatory obligations.