This article is for anyone new to Tenacy who wants to understand what a security measure is, its different statuses, and the difference between a private measure and a measure shared across multiple perimeters.
What is a security measure?
Software, processes, teams that help secure a perimeter. It is the pivot element in Tenacy, linking objects together, particularly in the context of multi-compliance.
On a given perimeter, a security measure can have the following statuses:
To be handled: you have not yet indicated whether the measure is implemented on your perimeter.
Not implemented: it does not yet exist in your organization.
Not implemented, with action: the measure is being implemented. An implementation action (the task created specifically to put the measure in place) has been launched, but the measure is not yet effective.
Implemented: it is already in place in your organization.
How is a security measure implemented and shared across perimeters?
A security measure is always implemented by a single perimeter, called the operating perimeter. Depending on your needs, it may only benefit that perimeter, or it may also benefit one or more other perimeters, called beneficiary perimeters.
The operating perimeter is the only beneficiary of the measure
For a chosen policy, each perimeter concerned can implement and operate its own measure, entirely independently. In this case, each perimeter will have:
its own security measure
its own recurring tasks (the periodic controls associated with the measure)
and will collect its own metrics (the figures that feed the measure's tracking)
The operating perimeter implements the measure for beneficiary perimeters
It is also possible for a single perimeter to implement one measure, which one or more other perimeters then benefit from. In this case:
a single measure is created for all the perimeters concerned
the operating perimeter is responsible for implementing it, for itself and the others, or only for the others
each metric is collected by default, for all beneficiary perimeters
💡 A perimeter can be the operator of a measure for other perimeters without being a beneficiary of it itself: simply remove that perimeter from the list of beneficiaries, in the operating perimeter's security base.
In the example below, Vichy is the operator of the measure: it implements it, and collects the recurring tasks and metrics, for the beneficiary perimeters of Vichy (itself) and Tijuana.
Collecting metrics locally for each beneficiary perimeter
A possible nuance when several perimeters benefit from the same measure: metrics can be collected locally, for each beneficiary perimeter, rather than once for everyone.
⚠️ From the catalog, this option is directly available when implementing the measure. If you implement the measure from the security base, you then need to go to the metrics linked to the indicator to associate the desired beneficiary perimeters.
To do this, check the "Collect value for each perimeter" box when implementing the measure from the catalog (Cog wheel icon > Catalog > Measures tab > hover over the measure > "shield" icon at the end of the row to implement). Metrics are then collected separately for each beneficiary perimeter, while still being attached to the same measure.
💡 Example: the Group operates an awareness measure that several subsidiaries benefit from. By enabling local collection, each subsidiary fills in its own metrics to get data specific to its own perimeter, while still benefiting from the same measure. The measure's operations score then combines all the collected metrics, but a dashboard can still break down the figures by subsidiary.
💡 For collection, there are two options: either each beneficiary perimeter collects on its own, or a single perimeter (for example Lyon) stays in charge of collecting for everyone.
Frequently asked questions
Can a perimeter be the operator of a measure without being a beneficiary?
Yes. A perimeter can implement a measure for other beneficiary perimeters without being a beneficiary of that measure itself.
How do I choose who collects the metrics when several perimeters benefit from the same measure?
By default, a single metric is collected by the operating perimeter for all beneficiary perimeters. By checking the "Collect metrics for each perimeter" box, each beneficiary perimeter collects its own.
If beneficiary perimeters collect their metrics locally, does each one get its own score?
No. The measure's operations score combines all metrics collected across all beneficiary perimeters. A dashboard, however, can break down the figures for each perimeter.