The dependency analysis answers a simple question: what happens if this system goes down, or is compromised? You map what each IT system depends on: what it runs on, how users log in, and which systems it exchanges data with. Diri turns the answers into a criticality matrix that shows which systems are single points of failure, what stops if they fail, which suppliers you depend on most, and which risks you should register.
Open Vendors, Systems & Processes > Dependencies in the left-hand menu. The dependency analysis is available to all customers. It builds on your IT system register, so register your systems first. You need access to IT systems to open it; users who can see but not edit IT systems see the results but cannot record dependencies.
The page has five tabs: Start, Result, Dependency map, Personal data flow and Vendor concentration.
Dependencies can only link systems in the same organisation line (your organisation, its parents and its sub-organisations). Tick Include IT systems from sub-organisations to search those systems as well.
If your dependencies are already documented in a spreadsheet, use Import from Excel on the mapping page. Download the Excel template first: it contains an IT systems sheet with every valid system name, and the system columns are dropdowns fed by that list. Rows of type "other" need a note saying what the dependency is. See Bulk import.
The Result tab starts with a one-sentence verdict, for example how many systems are single points of failure and what stops if they fail. Below it is the Criticality matrix, an adaptation of NIST IR 8179:
The four regions say what to do: PROTECT AND BUILD REDUNDANCY, MONITOR, UNDERRATED? and OK. Systems without an importance rating are shown separately under Not rated; Diri never guesses a rating.
A system is flagged when at least one rule fires:
Each flagged system has actions such as Create risk, Set importance and Find a fallback. With Find a fallback you record which dependent systems could run degraded for a while, and how. A single point of failure stops being one as soon as one dependent can run degraded. Recorded fallbacks are listed under Documented fallbacks.
Improve the data quality lists systems with no importance rating or no vendor. Fixing them here updates the matrix immediately. Use Print summary for a printable dependency analysis, optionally with the detail appendix.
The Dependency map draws the systems left to right: a system sits to the right of what it depends on, and arrows point the way a failure travels. Click a system to see its findings, what it depends on, what stops without it, and its actions. Hover a system to trace its chain.
From a system in the result or the map, open What happens if … goes down?. Choose:
The simulation also lists the assets managed by the systems in reach.
Select Create risk on a flagged system or in a simulation. Diri drafts the cause, event and consequence for you, for example "Outage of Entra ID (login for 12 systems)". Under Where should the risk be recorded?, add it to a risk assessment that already covers the system, or select Create a new dependency risk assessment. Diri then opens the risk wizard with the built-in event type and consequence category pre-selected. See The risk assessment process.
The Vendor concentration tab shows which suppliers your operations depend on most. It combines the dependency map, the vendor registered on each IT system, the business processes they support, and the supplier security assessments.
Each supplier also shows what is known about its subcontractors. Shared subcontractors further up the supply chain are shown on the Subcontractors tab in Vendors, see Parties and customers.
The Personal data flow tab checks whether your record of processing activities matches where personal data actually moves between your systems. Each processing activity is compared with the dependency mapping, and you can add a missing system to an activity with Add to activity. If your organisation does not process personal data, you can skip this tab. See Data processing activities.