Depending on how your organization operates, some perimeters may be responsible for maintaining certain security measures and making them available to other perimeters.
In Tenacy, you can reflect this by implementing the measure on the perimeter responsible for it, then adding the other perimeters as beneficiaries. This way, Tenacy shows that the measure is present on those perimeters, even though they are not the ones managing it.
The place where you declare a beneficiary depends on the measure's status on the responsible perimeter.
Case 1: Add beneficiaries to a measure that is already implemented
If the measure is already implemented: from your responsible perimeter's security base, click the measure in question, then edit it to add one or more beneficiaries.
Measure already implemented: immediate effect for the beneficiary
If the measure is already implemented on the responsible perimeter at the moment you add a beneficiary, the effect is immediate. The beneficiary perimeter's security base then displays the measure with the status Implemented by [responsible perimeter]. The beneficiary doesn't need to take any action on their end: the measure counts as implemented for them, with a note indicating who actually manages it.
Case 2: Add beneficiaries to a measure that is not implemented
The measure is not implemented: beneficiaries are then added from the implementation action.
From the responsible perimeter's security base, click the measure in question, and navigate to its associated implementation action. In the action, go to the Beneficiaries tab to declare the perimeters concerned.
⚠️ A perimeter that is already a beneficiary of the measure, or already a beneficiary of an ongoing implementation action on this measure, appears greyed out in the selection list. This prevents creating a duplicate action or an inconsistency between perimeters.
Measure not implemented: the role of the implementation action
If the measure is not yet implemented, you can still declare beneficiaries as soon as the implementation action is created, without waiting for it to be completed. The status shown to the beneficiary then evolves in two stages:
While the implementation action is in progress (to be planned, planned, in progress, pending, or under review): each beneficiary perimeter sees the measure in its security base with the status Not implemented, the same status as the responsible perimeter's. The associated implementation action is also visible from the beneficiary's or beneficiaries' security base.
Once the implementation action is completed: the measure automatically moves to the Implemented status on the responsible perimeter, and to the status Implemented by [responsible perimeter] on each of the beneficiary perimeters declared on the action.
Case 3: Implement a measure locally, on several perimeters at once (from the catalog)
If you'd rather have each perimeter remain responsible for its own measure, without going through the responsible/beneficiary logic, you can implement the same measure independently on several perimeters in a single operation, from the catalog.
From the gear icon, open Catalog, then the Measures tab.
Hover over the measure you want to implement and click the Implement icon.
Associate the perimeter(s) concerned: you can select several at once. You can also define the recurring controls to associate at creation time (optional).
Click Create.
The measure is then implemented independently on each of the selected perimeters: each perimeter becomes responsible for its own instance of the measure, with its own efficiency, its own controls, and its own actions. Unlike the two previous cases, there is no beneficiary relationship here: nothing is reflected from one perimeter to another, each one manages its measure fully on its own.
⚠️ This screen doesn't show you whether the measure is already implemented on the perimeters you're selecting: you risk creating duplicates without realizing it. We recommend this method mainly during onboarding, to quickly populate the security base of several perimeters, rather than as an everyday practice once your security base is already in place.
Frequently Asked Questions
What's the difference between a responsible perimeter and a beneficiary perimeter?
The responsible perimeter actually implements and manages the measure, or the action leading to it. The beneficiary perimeter doesn't carry that responsibility: Tenacy simply reflects the measure's status in its own security base.
Does a beneficiary see the measure disappear from their security base while the implementation action is in progress?
No. It stays visible with the status Not implemented, along with the ongoing implementation action that explains this status.
Why are some perimeters greyed out when selecting beneficiaries?
A perimeter is greyed out and can't be selected if it's already a beneficiary of the measure, or already a beneficiary of an ongoing implementation action on that same measure, to avoid duplicates.
What's the difference between adding beneficiaries and implementing a measure locally on several perimeters?
Adding beneficiaries creates a dependency relationship: only one perimeter actually manages the measure, and the others only see its status reflected in their security base. Implementing locally on several perimeters, on the other hand, creates an independent instance of the measure on each one: each perimeter manages it and evolves it on its own, with no link between them.
🔎 To learn more, see: Understanding the concept of "security measure" in Tenacy and Implement a measure.