¶ Inheriting, Sharing and Re-using Lists and Items in Diri
Diri lets you reuse content across organisations and users, so that IT systems, vendors, treatments and other items are registered once and used everywhere they are needed. There are two ways to do it: inheritance, which offers items down the organisation tree, and sharing, which gives named organisations or people access to specific items. This page explains both and when to use which.
¶ Inheritance or sharing?
| Inheritance | Sharing | |
|---|---|---|
| Direction | Only downwards, from an organisation to all organisations below it | To any organisation or user in your organisation tree, also sideways |
| Who gets access | All sub-organisations | The organisations and people you name |
| How it is set | Toggles on the item itself | The Share action in the list |
| What recipients can do | See and use the item; change it only if modification is allowed | The permissions you give: Read, Create, Update, Delete |
| Best for | Common registers and libraries maintained centrally for a group | Collaboration on specific items, across departments or with individual users |
Nothing is ever shared or inherited outside your own organisation tree. Administrators of a parent organisation already see the content of the organisations below them, without sharing.
¶ Inheritance of items (recommended)
Inheritance is the core feature for reusing content across an organisation. Items created at a higher level become visible and usable in all sub-organisations, so a group can keep one central list of IT systems, vendors, assets, threats, vulnerabilities, treatments, business processes or processing activities.
Most forms have two inheritance settings, for example on an IT system:
- Allow child organizations to inherit this system (shown as Use inherited in lists) – the item is offered to every organisation below, including organisations created later.
- Allow child organizations to modify this system (shown as Can modify) – sub-organisations may also edit the item. Without it, the item is read-only below, and the form says that downstream editing is disabled.
An inherited treatment can still be used in a sub-organisation's risk assessments even when it cannot be modified there. Settings, type definitions (such as event types, categories, tags and asset types) and assessment templates are inherited through the organisation's inheritance settings. See Inheritance of settings and rights and Sharing templates.
Some content is never inherited: dependencies between IT systems, and customers. They always belong to one organisation.
¶ Share items with organisations or people
Sharing is available in most lists in Diri. You can share with whole organisations, with individual people, or both, and give each of them their own permissions.
- In the list, select one or more items with the checkbox on the left.
- Select Share in the table toolbar.
- Under Share with organization, select Add organization, choose the organisation and tick the permissions it should have: Read, Create, Update and/or Delete.
- Under Share with individuals, select Add person, enter the person's email and tick their permissions.
- Select Submit.
In the animation above, three IT systems are shared with a sub-organisation with Read rights. Users in that organisation can use the systems in their risk assessments and processing activities, but cannot edit, update or delete them.
¶ See who has access, change permissions and revoke access
To manage the access to an item that is already shared, select only that one item and select Share. The sharing panel lists the Users and Organizations that have access, with their current permissions.
- Change permissions: select the pen icon next to a user or organisation and tick or untick Read, Create, Update and Delete. The change applies immediately.
- Revoke access: select the trash can icon next to the user or organisation.
- Add more recipients: use Add organization or Add person and select Submit.
Whether you can change or revoke access depends on your role.
¶ Items shared with you
When an item has been shared with you, Diri shows Shared with you, with the organisation it comes from, who shared it, and what you can do with it.
¶ Use cases
¶ A central list of IT systems
Organisations with several sub-organisations or customers often keep one central list of IT systems. Inheriting or sharing it means you avoid entering the same data twice, other teams can reference the systems in their risk assessments and processing activities, and updates to a system are seen by everyone who uses it: one source of truth.
¶ Collaborating on a risk assessment
Risk assessments benefit from input across departments or from external experts. Share a risk assessment to let several stakeholders contribute to identifying, evaluating and treating risks, for example in cross-functional workshops, when involving consultants or advisors, or when asking management or security officers for review.
Sharing a risk assessment also shares what belongs to it: its events, causes and consequences, its treatments, and the assets, IT systems and privacy items it uses. Items added to the assessment later are shared too.
Tip: Use comments and tasks to coordinate input within the assessment.
¶ Reusing treatments
Treatments (actions or controls that reduce risk) can often be standardised. One treatment can be used in many risk assessments, and each assessment keeps its own status, responsible person and due date for it. The treatment's form lists where it is used under Applied in assessments. Sharing or inheriting treatments lets you apply the same controls across the organisation, for example an MFA roll-out or backup routines, and report on them consistently. See Treatments.
In the animation below, an administrator shares treatments directly with a user. The view then switches to that user, who applies the shared treatments in a risk assessment and adds several effects to one treatment.
Treatments suggested by pre-assessments work differently: they come from a central catalogue and are shared automatically by every record in the group that needs them. See Pre-assessments.
¶ Tasks across organisational levels
Tasks can be shared across organisational levels, so a task set at group level can be followed up in each organisation, with progress tracked locally. See Tasks.
¶ Policies and documents
Policies have their own Visibility setting: only you, the active organisation only, or the organisation and all sub-organisations below it. Attachments on a policy follow the policy. Documents linked as evidence for a framework control can be shared with the control owner or with sub-organisations from the control. See Policies and Files and attachments.
If you have questions or need help setting up sharing, contact support@cyrigo.com or your Cyrigo account manager.