A conflict that cannot be removed is usually accepted and covered by a compensating control: a monthly review of vendor changes, a payment release in a second system, a signed risk acceptance. A mitigation control records that decision against the exact user (or role) and risk it applies to, so it travels with every analysis instead of living in a separate spreadsheet.
Each control does one of two things to its conflict:
| Excluded from analysis | Effect |
|---|---|
| No | The conflict is still analyzed and reported, labelled with the control type and ID. Use this to show the conflict and what covers it |
| Yes | The conflict is not raised at all. Use this for combinations formally accepted and signed off, so they stop reappearing as findings |
Labelling is usually the better choice. An auditor can see the conflict, the control and its identifier side by side, and the Overview can tell you how much of your exposure is covered and by what kind of control. Excluding hides the conflict from the result, although the execution log still records the controls the run was made with.
The mitigation control file
Controls live in one CSV file per analysis mode, chosen in the analysis criteria, not inside a data source. One file can therefore cover several systems.
| Column | Meaning |
|---|---|
System | The data source the control applies to. Must match the data source name exactly |
User ID (users mode) or Role (roles mode) | The account or role holding the conflict. In a cross-system analysis, the canonical name |
Risk | The ruleset's Access Risk ID |
Mitigation Control Type | Your own classification, for example Monitoring, Reconciliation, Risk acceptance. Empty reads as Whitelist |
Mitigation Control ID | The reference of the control in your control register |
Mitigation Control Comment | Free text: owner, frequency, approval reference |
Excluded from analysis | Yes or No, see above |
The default file names are USER_MITIGATION_CONTROL.csv and ROLE_MITIGATION_CONTROL.csv. The delimiter is detected from semicolon, tab, comma or pipe, and the file is written back with semicolons. Each pair carries one control: adding the same system, entity and risk again does not create a second row.
Control types are free text, and whatever values you use become the slices of the Overview. Pick a short, stable list and use it consistently, because it is what lets you answer "how many of our high risks are covered only by a risk acceptance?"
Enabling the criterion
The criterion is hidden by default. In Analysis, click the cog next to the criteria heading (Show/Hide criteria) and tick Mitigation Control. A Mitigation controls row appears in the criteria, with a button showing the number of controls loaded for the current mode.
The button offers:
- None: run without mitigation controls
- the selected file, when one is set
- Manage...: open the editor
Runs with and without controls are both available, and the Info tab and the signed execution log record which controls a run was made with. Comparing the two is a quick way to show how much of the exposure is mitigated rather than resolved.
Adding controls from a result
The fastest way to build the file is from the conflicts themselves:
- Run an analysis and open the Summary report
- Select the rows to mitigate, filtering first if useful (for example one risk owner's conflicts)
- Right-click and choose Add to mitigation controls
- The editor opens with the selected pairs added, system and risk already filled in
- Set the control type, ID and comment, and whether the pair is excluded from analysis
- Save
A pair that already has a control is not added twice.
The editor
Manage... opens a table of the controls for the current mode, which you can edit in place:
- Add row adds an empty control
- Paste a block copied from Excel: rows split on new lines, columns on tabs, and
Yes/Noare read in the exclusion column - Select several rows and right-click to set the system, the control type, or the exclusion flag on all of them at once
- Import reads an existing file, Save as... writes to a new one
- Rows with no system are flagged, with an option to fill them all with one system
Unsaved additions and deletions are counted above the table. Creating a new file while edits are pending asks for confirmation first.
Reading the result
When a run uses mitigation controls:
- The summary report carries two extra columns,
Mitigation Control TypeandMitigation Control ID, filled for every labelled conflict - The Overview adds a Conflicts by mitigation panel, splitting conflicts into mitigated and unmitigated and the mitigated ones by control type. Clicking a slice filters every other panel, so "unmitigated Critical conflicts in Finance" is two clicks
- The Info tab lists the controls the run was made with
Moving from risk exclusions
Earlier versions stored accepted risks as USER_RISK_EXCLUSION and ROLE_RISK_EXCLUSION files next to each data source, with two columns. Those files are still recognized. When one is found, MTC Skopos offers to convert it: each row becomes a mitigation control with its system set from the data source, type Whitelist and Excluded from analysis set to Yes, so behaviour does not change. The old file is renamed with a -deprecated suffix so it is not detected again.
A file with only the original columns can also be loaded directly, and reads the same way.
What it does not do
A mitigation control in MTC Skopos records which control covers which conflict. It does not schedule control execution, collect evidence that the control was performed, or run attestation campaigns. Keep that evidence in your controls process and reference it through the control ID.