Multi-Entity External Security: How to Structure Governance at Group Level

Subsidiaries, business units, acquisitions, regional divisions: each entity often has its own scope, users, and security resources. The central cybersecurity team remains responsible for the overall view, but still relies heavily on local teams to make changes to configurations and access rights.

This organizational model works as long as the group remains stable. It becomes much more complex when the organization needs to restructure, integrate a new entity, or redistribute resources.

Let’s take the example of a group that has just acquired a new company.

Its assets need to be integrated into the external security framework, accounts need to be created for the relevant teams, access scopes need to be defined, and the data belonging to this new organization must remain isolated from that of other subsidiaries.

On paper, none of this is particularly complex. In practice, when administration is entirely decentralized, each step can require specific requests, approvals, and manual intervention.

The same issue arises when a Pentest resource needs to be reassigned.

One subsidiary may no longer be using part of its quota, while another needs to launch a new campaign. If resources are siloed without a redistribution mechanism, the central team has to arbitrate between allocations that no longer reflect the group’s actual needs.

Another common scenario is when a user changes scope. They move from one subsidiary to another, join a cross-functional team, or take on group-level responsibilities. Their access rights must then evolve with their role, without giving them access to data belonging to organizations that are no longer within their scope.

These situations are common. It is their repetition that becomes problematic.

The main issue is not necessarily technical. It is organizational.

Every decision made by the central team translates into a series of actions that need to be carried out across different scopes. As a result, the time between “we’ve made the decision” and “it has actually been configured” can increase.

For the central team, this also creates a significant cognitive burden: tracking requests, reviewing access rights, monitoring available resources, following up with local teams, and ensuring that the configuration still reflects the group’s actual organizational structure.

As the number of entities increases, so does the risk of misalignment.

An acquisition may have been operational for several months without its external security scope being properly integrated. An employee may retain access rights they no longer need. A resource may remain unused within one organization while another organization needs it.

The challenge is therefore no longer simply to secure each entity, but to maintain consistent governance across all of them.

Centralized administration makes it possible to move the control point to the group level without removing the autonomy of individual organizations.

When a new subsidiary joins the scope, the central administrator can structure its environment, manage its users, and define the associated access rights without multiplying external interventions.

When a user moves to another organization, their scope can be reassigned directly. The objective is simple: access rights should follow the user’s role and organization rather than remain tied to an outdated configuration.

Resource management can also be handled at group level. When an organization does not use all of its allocated resources, they can be redistributed according to rules defined centrally. This gives the group greater flexibility without sacrificing control.

But centralization does not mean making everything visible to everyone.

In fact, this is one of the key principles of an architecture designed for large enterprises: strict data isolation by entity.

Each organization must retain its own scope, assets, users, and results, while the central administration team has the visibility and governance capabilities required to manage the group as a whole.

This separation also addresses a compliance requirement. In an NIS2 or DORA context, organizations must be able to demonstrate that they have control over their assets, access rights, and responsibilities. Clear isolation between entities makes this governance easier to demonstrate during an audit.

For a large organization, the question is ultimately not whether to choose between centralization and autonomy.

It is about building a model in which both can work together.

Local teams retain control over their operational scope. The central team, meanwhile, has an administrative level that enables it to manage organizations, users, and resources without systematically relying on external intervention.

This is precisely the role of the Patrowl Tenant Administrator: giving the central organization the ability to manage its portfolio of entities while ensuring strict isolation of data and scopes.

The challenge therefore goes beyond simply administering a platform. It is about moving from external security managed entity by entity to truly centralized management of the group’s external attack surface.

As organizations grow, transform, and acquire new entities, this capability becomes an essential lever for maintaining a consistent view of external exposure, without sacrificing the level of granularity required by local teams.