Every customer has the core. The modules are built step by step and go on top. Read about the thought behind them, what they can do and how far they have come.
Controls, risks, assets and incidents must fit together before a regulation can be documented. If you already run an ISMS in another tool, you can skip this module.
A full ISMS: controls with evidence and four eyes, findings, risks with 5 × 5, assets, vendors and contracts, incidents, the management report and the auditor's access. The regulations, CTEM and Config build on it.
Today: Controls with evidence and four eyes, risks, incidents, assets and the management report run in the pilot.
- Controls with evidence, four eyes and findingsRunning in the pilotphase 11
- Risks with 5 × 5 and residual riskRunning in the pilotphase 16c
- Assets, systems and componentsRunning in the pilotphase 17b
- Incident registerRunning in the pilotphase 15
- Management report with locked versionsRunning in the pilotphase 16d
- Auditor access and audit packageRunning in the pilotphase 14a
- Policies and documentsPlanned on the roadmapphases 17e and 17f
- Common control framework across regulationsPlanned on the roadmapphase 19
Management decides in money. A risk that sits as a square in a 5 × 5 does not say what it costs.
Give a range for how often an event happens and what it costs, and FAIR works out the loss in a normal and a bad year, the portfolio and the return on a measure. Without ISMS, FAIR has its own simple risk list; with ISMS, the money sits on top of the risk register.
Today: Risk in money, the portfolio and measures run in the pilot.
- Risk in money with FAIRRunning in the pilotphase 18c
- Measures with cost and returnRunning in the pilotphase 18c
Threat matching
Running in the pilot
The vulnerability that matters most is the one that hits your own systems and is already exploited. It should work even if your ISMS lives elsewhere.
Your systems, components and versions are checked every hour against NVD, CISA's KEV list and EPSS, and each match gets a deadline by severity and appears in the daily brief. Without ISMS, the module has its own list of systems; with ISMS, a serious match becomes a finding on a control.
Today: Vulnerability matching against CVE, KEV and EPSS runs in the pilot.
- Systems, components and SBOMRunning in the pilotphase 17b
- Vulnerability matching against CVE, KEV and EPSSRunning in the pilotphase 18b
Financial entities must be able to show the supervisor that they meet DORA and its technical standards, requirement by requirement.
The requirements of the regulation and its eight technical standards become a control plan of narrow controls, each with an owner and a deadline. Major ICT incidents are classified and get their deadlines, and the register of information can be sent to e-Reg.
Today: The catalogue, the control plan, the incident deadlines and the register of information run in the pilot.
The requirements are worded in our own words and are still being reviewed.
Requires ISMS.
- Requirement catalogue with the technical standardsRunning in the pilotphase 12a
- Control plan with profile and templatesRunning in the pilotphase 13a
- Classification and deadlines for major ICT incidentsRunning in the pilotphase 15
- Register of information for e-RegRunning in the pilotphase 16a
NIS2
Planned on the roadmap
Essential and important entities must, under NIS2 and the Danish NIS2 act, notify quickly and show that management has approved the measures.
The module will work out whether you are an essential or important entity and keep your registration with the authority up to date. A significant incident gets three deadlines: early warning within 24 hours, notification within 72 hours and a final report within a month.
Requires ISMS.
- Requirement catalogue for NIS2 and the Danish NIS2 actPlanned on the roadmapphase 19
- Classification, registration and notificationPlanned on the roadmapphase 24f
Anyone who processes personal data must be able to show their records, answer data subjects on time and report a breach within 72 hours.
The module brings together the records of processing, data subject requests with their deadlines, impact assessments and processor agreements, and links them to your systems and vendors.
Today: An incident involving personal data gets the article 33 deadline. That runs in the pilot.
Requires ISMS.
- Breach deadline under article 33Running in the pilotphase 15
- Requirement catalogue with the articlesPlanned on the roadmapphase 19
- Records, requests, impact assessments and processor agreementsBeing builtphase 24e
AI Act
Planned on the roadmap
Companies that build or use AI need to know which systems they have, which role they play and which duties the risk class brings.
An AI inventory where each system gets a role and a risk class. The duties of the class become proposed controls, such as AI literacy and transparency.
Requires ISMS.
- Requirement catalogue for the AI ActPlanned on the roadmapphase 19
- AI inventory with role, risk class and dutiesPlanned on the roadmapphase 24g
CTEM
Planned on the roadmap
A setting changed since the last audit, and a finding nobody has looked at, are often what attackers find first.
Continuous threat exposure management: the module checks Microsoft 365, Entra ID and your cloud with read-only access, takes in your own scans and handles each finding.
Requires ISMS.
- Checks of Microsoft 365 and Entra IDPlanned on the roadmapphase 21a
- Checks of AWS, Azure, GCP and KubernetesPlanned on the roadmapphase 21b
- Remediation with recheckPlanned on the roadmapphase 21d
- Import of your own scansPlanned on the roadmapphase 21e
News about attacks and vulnerabilities comes from thousands of sources, and public sources know more about you than you think.
The module has two parts. Threat picture: Risk Signal's engine reads open sources, groups them into stories with a score and a trend, shows the ones that name your systems, vendors, domains or sector, and sends a daily brief. Digital footprint shows what public sources know about you: subdomains and certificates, mail security from DNS, open exposed services, accounts in known breaches and keys in public code. The footprint reads public sources and visits only your verified domains as an ordinary visitor would, and breach and scan data are shown only for domains you have verified.
Today: The threat picture runs in the pilot: the engine, the stories under Threats and the daily brief.
- Threat picture: the engine that reads the open sourcesRunning in the pilotphase 18a
- Threat picture: relevant stories and the daily briefRunning in the pilotphase 18b
- Digital footprint: subdomains and certificatesBeing builtphase 18f
- Digital footprint: verified domains, mail security, internet scans, accounts in known breaches and keys in public codeBeing builtphase 24i
- Digital footprint: DNS hygiene, reputation, visits to verified domains, look-alike domains and the vendors' footprintBeing builtphase 24l
When a ransomware group lists you or one of your vendors on its leak site, you should know before your customers do.
The module holds the ransomware groups' victim lists against your own organisation, your domains and your registered vendors, and shows look-alike domains. It only reads and keeps only metadata: name, date, group and source. We never see or show leaked files or credentials.
- You and your vendors on leak sitesBeing builtphase 24c
Config
Planned on the roadmap
Much of the modern cloud is described as code, and a flaw in the code becomes a flaw in every environment built from it.
The module scans Terraform and OpenTofu files through Trivy and finds resources outside the code. Risk Signal provides ready-made, secure OpenTofu modules for logging, MFA, encrypted storage and networks.
Requires ISMS.
- Scanning of Terraform and OpenTofu through TrivyPlanned on the roadmapphase 21c
- Secure OpenTofu modules from Risk SignalPlanned on the roadmapphase 24h
