¶ Settings in Diri
Diri comes with settings you can adapt to your own security policies and guidelines, such as your risk matrix, information classification levels and review cycles. Many organisations already have defined levels for probability and consequence, data classification and revision times in a security policy or guideline; the settings are where you put these into Diri.
Settings are managed by administrators. Other users see the effect of the settings throughout Diri, for example as the levels they can choose in a risk assessment.
¶ Finding the settings
Click Settings in the Administration part of the left-hand menu. The settings menu on the left is divided into two groups, and has a search field at the top:
- General – settings that apply to the organisation as a whole.
- Risk assessment settings – one group per module (Operational risk, Cyber security, Privacy and Compliance), with the settings used in risk assessments in that module. Only the modules your organisation has, and that your role includes, are shown.
Remember to save. Unsaved changes are highlighted, and Diri warns you if you try to leave the page before saving.
¶ Settings in sub-organisations
Settings are stored per organisation, and can be inherited from the organisation above. If the settings you see are inherited, a notice at the top says which organisation they come from:
- If modification is not allowed, the settings are read-only. Change them in the organisation they come from.
- If modification is allowed, you can change them – but the change is saved on the organisation they come from and applies to every organisation inheriting from it, not only yours.
See What is offered to the organisations below for how to set this up. Data still aggregates correctly upwards, even if sub-organisations use different risk matrices.
¶ General settings
| Setting | What it does |
|---|---|
| Currency | The currency cost estimates are shown in, for example in treatments and treatment plans, and whether the currency symbol is placed before or after the amount. It applies to every module. |
| Tags | Your own tags for categorising records. Tags are added to sub-organisations if Inherit is switched on. See Tags. |
| Framework tags | Tags from the frameworks available to your organisation. |
| Asset classification | The levels used to rate the confidentiality, integrity and availability of information assets. See below. |
| Framework status visibility | Whether everyone in the organisation can see which frameworks are active and how far along they are, or only administrators and users you grant framework access. People always see controls they own and controls that require a policy or task assigned to them. An organisation above you can restrict this; you can then only restrict it further. |
| Control review cycle | How long a control attestation stays valid before the framework control must be reviewed again. Individual controls can have a shorter cycle. See Controls and evidence. |
| Notification defaults | The notification preferences new users get when they are added to this organisation. The defaults are also copied to new sub-organisations created below it. Users can still change their own preferences under My Account. |
¶ Asset classification
Asset evaluation is the cornerstone of the risk assessment, as it helps determine which assets need protection. Information classification is a central part of the asset evaluation, and is done with the so-called CIA levels: Confidentiality, Integrity and Availability. These levels should match your organisation's data classification policy, and they are a direct input to the consequence estimate in your risk assessments.
Enter the number of levels (between 3 and 6) for each of confidentiality, integrity and availability, and name each level. You can also describe each level; users can read the descriptions when they classify assets. The scale applies to every module.
If the modules currently hold different values, Diri tells you so. Saving applies the values shown to every module.
¶ Risk assessment settings (per module)
Each module has its own risk assessment settings, so, for example, the risk matrix can differ between the privacy, cyber security and operational risk modules. Open the module under Risk assessment settings to see its settings:
| Setting | Modules | What it does |
|---|---|---|
| Risk matrix settings / Risk matrix thresholds | All | The probability and impact levels and risk thresholds, and the risk acceptance threshold. See below. |
| Asset types | Operational risk, Cyber security | The asset types available for assets in the module. Switch on Inherit to make an asset type available to sub-organisations. Asset types created by the system exist in all organisations and cannot be inherited. |
| Consequence categories | All | Categories for the consequence side of the bowtie, for example financial loss or data breach. Used in risk assessments and on the dashboard. |
| Threat categories | All | Categories used to group threats in risk assessments and on the dashboard. |
| Vulnerability categories | All | Categories used to group vulnerabilities in risk assessments and on the dashboard. |
| Event types | All | Types for the unwanted event at the centre of the bowtie, for example unauthorised access or service disruption. |
| Revision time | All | How long a signed risk assessment is valid before it must be reassessed. |
¶ The risk matrix
The probability and impact levels are central in risk assessment and reporting. They decide the levels users can choose when they assess the probability of a cause and the impact of a consequence, and they form the Y-axis (probability) and X-axis (impact) of the risk matrix on the dashboard and in reports.
In the risk matrix settings you can:
- Set the number of probability and impact levels (between 3 and 6 of each).
- Rename each level and describe it. Users can read the level descriptions while assessing risk.
- Adjust the threshold values for each level, and the colours and value ranges for the risk levels.
The settings are stored on the current organisation and can be inherited by the organisations below. Sub-organisations can have their own levels if they are allowed to modify inherited settings, and the data still aggregates into the dashboard at higher levels.
¶ Risk acceptance threshold
On the same page you set where your organisation stops accepting risk. Switch on Use an acceptance threshold and set the threshold. A risk scores the mean of its probability and consequence on the same 0–100 scale as the matrix; risks up to the threshold count as accepted, and anything above it counts as unacceptable and is reported as such in the treatment plan and the risk registry. You can also leave the threshold switched off. See Risk acceptance.
¶ Type definitions
Consequence categories, threat categories, vulnerability categories and event types are the options users choose from in risk assessments, and they are used to group data on the dashboard and in reports.
- Click Add consequence category, Add event type and so on to add an option, and edit or delete existing ones in the list.
- Options that are in use in risk assessments cannot be deleted.
- Cyber security organisations get a predefined library of ISO 27005 threat and vulnerability categories. You can add your own categories alongside them.
- Items marked Built in come with Diri and are the same in every organisation: the event types Unavailable IT system and Compromised IT system, and the consequence categories Loss of availability and Loss of confidentiality and integrity. They cannot be renamed, deleted or stop being inherited. The dependency analysis uses them when it creates a risk from a system that goes down or is compromised.
- Items inherited from an organisation above are read-only and are edited in the organisation where they were created.
The threats and vulnerabilities themselves are registers in each module's menu group (Threats and Vulnerabilities), not settings. See Libraries and categories and Shared assets, threats and vulnerabilities.
¶ Revision time
Revision time defines how long a signed risk assessment is valid before it must be reassessed, for example 12 months for an annual review. Set an Amount and a Time unit (hours, days, months or years). The review date is shown on the dashboard and in the annual wheel, and owners are notified when the review is approaching or has expired. See Signing and review.
¶ Modules
In Diri, features are organised into modules: Cyber security, Operational risk, Privacy and Governance & Compliance. Your subscription determines which modules your organisation has, and the modules apply to the whole organisation tree. Some areas, such as vendors, IT systems and the dependency analysis, are shared between modules.
Users see the modules that belong to their role. If you open a feature that is not part of your subscription, Diri shows “Module not enabled”. To add a module, contact support@cyrigo.com.