How the modules connect
Each module works on its own. Together they share inventory, evidence and judgement.
You can start with one. Each module you add connects with the ones you already have: what one produces, another uses without typing it again.
4 modules · 20 connections
- 1 → 0
- 2 → 4
- 3 → 12
- 4 → 20
Each new module connects with every module already there: what you enter once reaches more places without retyping it.
- Function
- No connection to other modules
- Connection
- The provider in the case
On mobile, the sky is summed up in one dot per module. Below, the connections between the modules switched on.
Active connections
The full sky
Each dot is a product function and each thread a connection: what one function produces, another uses without typing it again. Switch a module off and see what is lost.
The case, told from the screen
Your cloud provider goes down: from the notice to the on-time report, the continuity plan and the evidence, with every connection at work. Sample data.
What they share
Four modules on the same foundations
The connections work because all four modules work on the same things.
One inventory
Suppliers, processes, assets and systems are registered once. The cloud provider is the same one in the Register of Information, the BIA, the incident and the risk.
One evidence repository
Assessments, exercises and notifications are stored once, linked to the controls they prove. The auditor finds them in one place.
The same AI, with the same judgement
Across the four modules, the AI works the same way: it suggests and explains why, and who decided and when is recorded.
The AI proposes
A supplier’s criticality, an incident’s classification, the draft of a report.
A person decides
They accept, correct or discard it. Nothing goes out without their approval.
One access
One sign-in and the same roles across the four modules. Procurement, security, continuity and management see what concerns them, on the same information.
Every connection
The 20 connections between modules, where each piece of data comes from and where it goes. The same information as the sky, to read at a glance.
| From ↓ · To → | Third parties | Incidents | Continuity | Compliance |
|---|---|---|---|---|
| Third parties | No connections |
|
|
|
| Incidents |
| No connections |
|
|
| Continuity |
|
| No connections |
|
| Compliance | No connections | No connections |
| No connections |
From Third parties
- IncidentsOnboarding and criticality → TrackingThe affected supplier, with its criticality.
- IncidentsSupplier portal → Supplier noticesThe incident notice the supplier itself gives.
- IncidentsContinuous monitoring → Signal detectionThe list of monitored suppliers.
- ContinuityDORA Register of Information → DependenciesThe supplier’s criticality and how much each process depends on it.
- ContinuityDORA Register of Information → Exit plansThe criticality and what is already recorded about exiting the supplier.
- ContinuityFourth parties → ConcentrationEach supplier’s subcontractors.
- ComplianceAssessments → EvidenceApproved assessments, certifications and the Register of Information.
- ComplianceRisk score → Third-party risksThe risk of each critical supplier.
From Incidents
- Third partiesTracking → Supplier profileEach supplier’s incidents.
- ContinuityClassification → ActivationThe incident that activates the plan.
- ContinuityPost-incident report → BIAHow long the incident really lasted and what it hit.
- ComplianceNotifications → EvidenceNotifications sent, with their deadline met.
- ComplianceClassification → RisksMajor incidents, to review the risk.
From Continuity
- Third partiesExit plans → DORA Register of InformationThe approved exit plan and the critical processes the supplier supports.
- ComplianceTests and exercises → EvidenceTests and approved plans, as evidence for each control.
- ComplianceTests and exercises → Corrective actionsExercise findings, with their origin and due date.
- ComplianceProcess inventory → RisksCritical processes, with their criticality and RTO.
- IncidentsActivation → NotificationsThe crisis timeline and the affected processes, with their RTO.
- IncidentsBIA → ClassificationWhich processes are critical and how long they can hold.
From Compliance
- ContinuityRisks → StrategiesEach process’s inherent and residual risk.
The four modules
- Third partiesInventory, questionnaires and evidence
- IncidentsLogging and on-time reporting
- ContinuityBIA, plans and exercises
- ComplianceRisk, SoA and audits
You can start with one module
Each module works on its own. When you add the next one, it connects with what you already have registered.