Your organizational context: org chart, list of your information systems, and above all your certification scopes. A certification scope (ISO 27001, for example) almost always becomes a perimeter in its own right: it's often the most reliable starting point for framing your tree structure.

A clear view of what you need to secure: modeling works best when it starts from your security objectives (policies, risks to cover) rather than from your functional org chart. The two often overlap, but not always.

Someone who knows the organization as a whole: on a complex organization, a single person dedicated to Tenacy but not familiar with the overall structure is usually not enough to frame the modeling alone.

User rights: the rights of local pilots and contributors follow the tree structure. If you need to manage them according to a different logic than your main structure, a dedicated secondary tree lets you do so without duplicating your data.

Evaluation campaigns: a campaign, which lets you collect declarative responses from several perimeters on a shared framework, is launched at the scale of a single perimeter or grouping. To cover perimeters scattered across your tree in a single campaign, group them beforehand (via a grouping or a secondary tree).

Operational indicators: attached to measures, which are themselves attached to perimeters, their level of tracking detail depends on that of your split. If you want a key indicator per information system, each information system will benefit from being modeled as its own perimeter.

Security base: the security base groups together, for a perimeter, all the security measures expected in light of the policies and risks associated with it. The first time you declare a security base is often when the level of detail you actually need becomes clear. Picturing yourself building a security base before finalizing your tree is an excellent way to validate your granularity.

Via your security objectives: your policies (frameworks such as ISO 27001, NIS2, or your internal policies) and your risks are attached to perimeters. If your different entities are aiming for different levels of maturity or autonomy, this directly informs the split to favor.

Via your reporting: the granularity of your perimeters determines that of your dashboards. Thinking upfront about the reporting angles your leadership expects (by country, by business unit, by criticality level) helps you choose the right level of detail from the start.

Via your measures: identify your centralized measures (a group-wide EDR, a central IAM, a shared SOC, for example) versus your local measures. These centralized measures are generally carried by an "operator" perimeter, which acts on behalf of the other perimeters. This is what more mature organizations often call a "process owner", a term you'll also find in the ISO 27001 standard.

Each perimeter keeps the type chosen at creation (internal, supplier, or application). This is what guarantees the consistency of your security data over time, but it also means it's better to confirm that choice at creation, particularly for your operational points of application.

Combining two existing perimeters into one is done by migrating their objects, rather than through an automatic merge. This is an operation Tenacy walks you through step by step, but one that's simpler to avoid altogether by properly calibrating your initial granularity.

A grouping is emptied before it can be deleted: you need to move or reassign its perimeters and sub-groupings beforehand. This is also what guarantees that nothing gets silently lost during a reorganization.

The main tree structure is vertical, but nothing stops you from crossing it with other axes: both secondary trees and custom properties with filters let you represent a matrix organization without duplicating your data.

An internal perimeter uses up your license, suppliers and applications don't: one more criterion to factor in when deciding how to model an entity (see also the licensing section of Model my organization).

A grouping remains an analytical axis only: it structures your tree and your reporting, but doesn't carry any security object of its own. It's the internal perimeter that carries your policies, measures, and risks.

Organizations undergoing external growth or frequent reorganization: rather than modeling your entire structure at once, it's better to focus on 2 or 3 representative perimeters, run through your use cases on them, then industrialize once the method is validated. This progressive approach limits the rework needed if your organization keeps changing.

Organizations with field populations that are hard to centralize (industrial sites, OT environments): when the relevant population and data are managed in the field rather than by centralized support functions, a declarative evaluation or handling via supplier perimeters often works better than a full internal-perimeter model.

Organizations with a large number of perimeters (several dozen or more): a consistent ID hierarchy from the start makes bulk operations (import, export, data reprocessing) much easier down the line.

Organizations with a trend toward group-level centralization: if you expect more and more measures to be managed at group level and then offered to subsidiary perimeters, anticipate the "operator" perimeter that will carry these measures on behalf of the others as early as the modeling stage: this avoids having to reassign measures after the fact.