Skip to main content

Viewing anomalies in a perimeter's security measures

The Anomalies view of your security base helps you detect measures that are implemented or under implementation redundantly on a perimeter.

On an internal perimeter, your security base can accumulate redundancies over time: the same measure implemented twice, a measure that is both implemented and still under implementation, or several implementations running in parallel. The "Anomalies" view gathers these situations so you can sort them out and keep a clean base.

How to access the "Anomalies" view?

From the left-hand menu, open Security bases, select the relevant policy and perimeter, then click Show anomalies in the 3-dot menu at the top right of your screen.

What anomalies are detected on measures?

The "Anomalies" view reviews the security base of a given perimeter and surfaces various redundancies:

  • Measures implemented several times: the same security measure appears as implemented more than once, either by the same perimeter, or by this perimeter together with another one.

  • Measures both implemented and under implementation: the measure is already considered in place, but an implementation action for it is still open.

  • Measures under multiple implementation: several implementation actions target the same measure in parallel.

How to read the Anomalies view?

The Anomalies view groups the detected redundancies by type (measure implemented several times, measure also implemented by another perimeter, and so on). Each row is read from left to right in two steps.

On the left, the catalog measure concerned by the anomaly: this is the reference proposed measure, identified by its code (for example TE022 "Awareness program").

To the right of "caused by", the elements of your base that create the redundancy: these are the measures actually present on the perimeter, all pointing back to this same catalog measure. An icon accompanies each one to indicate its nature (measure with no beneficiary, measure implemented by another perimeter, and so on).

In practical terms, a row such as TE022 "Awareness program" caused by TE022 and EX022 (in the screenshot above) means that your base contains two distinct implemented measures corresponding to the same catalog proposed measure: this is the duplication you need to arbitrate, by deciding which one to keep. To do so, you can review the details of both measures by searching for them in your base.

How to clean up your base from an anomaly?

When an anomaly is surfaced, the goal is to decide which version of the measure to keep. We recommend the following method:

  • Open two tabs side by side in your browser: one with the "Anomalies" window open, the other on the security base filtered on implemented measures.

  • Check whether any objects are attached to the measure concerned: actions or recurring tasks in progress. This reveals which measure work has already been engaged on, and therefore which is the most "alive" in Tenacy: that is usually the one to keep.

  • Ask yourself: is this process or tool already genuinely in place in my organization?

Depending on the answer, two cases arise:

  • This process or tool is already in place: keep the implemented measure. If needed, you can associate an improvement action with it to strengthen its efficiency.

  • This process or tool is not yet in place: keep the implementation action, which corresponds to the work still to be done.

⚠️ Before deleting a measure or an action, check that no action or recurring task in progress is attached to it. Deleting an item still linked to other objects may cause the associated tracking to be lost.


Frequently asked questions

Is the "Anomalies" view available on all perimeters?

No. The security base, and therefore the "Anomalies" view, only applies to internal perimeters. Supplier and application perimeters have no security measures.

Do I have to handle every anomaly immediately?

No. The "Anomalies" view is a control tool: the anomalies surfaced do not prevent the base from working. You can handle them at whatever pace suits you, during a review of your base for example.

What is the difference between an implementation action and an improvement action?

An implementation action puts in place a measure that is not yet in place. An improvement action applies to an already-implemented measure and aims to strengthen its efficiency. When handling an anomaly, you keep one or the other depending on whether the means is already in place.

Did this answer your question?