ISMS · CMDB · Risk
The ISMS that runs on your asset register.
Framework requirements, the asset register and the risk register share one data model. Adopt ISO 27001, NIS2 or DORA and run them on the same assets, controls and evidence — so an answer in one place is the same answer everywhere.
Built for regulated organisations in the EU — financial services, critical infrastructure and the suppliers inside their scope.
Requirements
94
Applicable
79
Covered
62
Open findings
4
| Requirement | Owner | Evidence | Status |
|---|---|---|---|
| A.5.1Policies for information security | Security | 3 items | Compliant |
| A.5.19Information security in supplier relationships | Procurement | 2 items | In progress |
| A.8.8Management of technical vulnerabilities | IT Ops | — | Evidence due |
| A.5.23Information security for cloud services | Security | 4 items | Compliant |
| CustomBoard reporting cadence — quarterly | CISO | 1 item | In progress |
Frameworks
Built for the regulations you are accountable for
Twelve frameworks ship as curated, versioned libraries — 833 requirements in all. Your tenant adopts a version, decides applicability per requirement and extends the record with its own requirements — nothing is copied by hand.
ISO 27001
ISO/IEC 27001:2022
Requirements for an information security management system, including Annex A controls.
- Annex A controls in the control library
- Applicability decided per requirement
- Assessment cycles and evidence recency
NIS2
Directive (EU) 2022/2555
Cybersecurity risk-management and reporting obligations for essential and important entities.
- Risk-management measures as adoptable requirements
- Asset and supplier context from the CMDB
- Reviews and approvals with an audit trail
DORA
Regulation (EU) 2022/2554
Digital operational resilience for financial entities and their ICT third-party providers.
- ICT risk management requirements mapped to controls
- Third-party ICT register linked to the CMDB
- Evidence and findings tracked per requirement
And nine more in the same library. GDPR · NIST CSF 2.0 · NIST SP 800-53 · SOC 2 · PCI DSS · ISO/IEC 42001 · EU AI Act · Cyber Resilience Act · HIPAA — each adopted, scoped and evidenced exactly the same way.
And your own requirements on the same footing. A requirement you write yourself is stored in the same shape as a framework's — same applicability decision, same evidence and recency rules, same findings, the same posture arithmetic. Not a note beside the standard: a row in the same table.
How it fits together
Requirements at the base. Assets and risks at the core.
Regulatory and internal requirements define scope; assets carry it; risks decide what you accept. One record — kept simple, automated, provable, governed.
How · the foundation
Requirements
Regulatory — DORA · NIS2 · ISO/IEC 27001 — and your own internal policies and standards
What
Assets
What we protect, who owns it, what it depends on
Why
Risks
What we fear to lose, at what cost, what we accept
one recordrequirements · assets · risks · evidence
- Simplify
- Automate
- Prove
- Govern
Who it serves
Built for the people who answer for it
Security runs the record daily, IT keeps it true, management shows the result — one record serves all three, and nobody re-types anything for a meeting.
For security leadership
Scope, applicability, controls, evidence with recency, findings — one defensible record, kept current as work happens. An audit becomes a read-out of the record, not a quarter spent assembling one.
For IT management
The asset register is the base, filled by directory sync and CSV import and kept honest by the data-quality workspace. Requirements and risks point at real systems — no second inventory to maintain.
For executive management
Posture derived from records, risk in money, owners and overdue reviews on a dashboard — and an executive summary report generated from the same record you would be audited against.
What is inside
Facts, not adjectives.
Every number below is a property of the platform as built — no customer metrics, no projections.
- 12frameworks in the libraryISO 27001 · NIS2 · DORA · GDPR · NIST CSF 2.0 · NIST SP 800-53 · SOC 2 · PCI DSS · ISO 42001 · EU AI Act · CRA · HIPAA
- 833requirements, version-pinnedpublished versions are immutable; your adoption pins one, and a successor arrives as a previewed transfer — never a silent rewrite
- 28asset typesacross 13 categories, in a validated hierarchy: asset → IT service → business solution, plus processes
- 1–25risk scoreCIS RAM-inspired 1–5 × 1–5, snapshotted per assessment; treatment plans and acceptances with an expiry
- 4-eyesper flow, on by defaultdocument approval · risk acceptance · asset retirement · audit sign-off — a submitter never approves their own step
- 4report types, built from the recordframework status, risk register, asset inventory and an executive summary — immutable snapshots, CSV and PDF
- 512API operations, all documentedeverything the UI does is a public REST API on one OpenAPI spec — and connectors sync data in on a schedule
- Everywrite leaves an audit eventimmutable, append-only audit log — separate from operational logs, per tenant, per actor
Product
Three core modules. One data model.
Compliance, CMDB and risk read the same assets, owners, controls and evidence — and audits, governance documents, third parties, files and reports sit on the same record. A change in one place is the same change everywhere.
Compliance management
Adopt a framework version. Decide what applies. Prove it with evidence.
Frameworks are published as immutable versions. Your tenant adopts one, marks applicability per requirement, maps controls and evidence — and posture is derived from that record, never typed in.
Applicability per requirement
Applicable or not, with a reason. Scope is explicit, reviewable and shows in every posture number.
Evidence with recency rules
Evidence records with up to 10 attachments, linkable to controls, requirements, assets and findings; recency revalidation flags what has gone stale.
Derived posture
A frozen snapshot of derived state — adoption, applicability, control coverage, evidence. Immutable once taken; not a scoring engine.
CMDB
The asset register everything else runs on.
Assets roll up into IT services, IT services into business solutions. Owners, criticality, environments and structural links live on the record — processes stay contextual, never orphaned.
Three-level hierarchy
Asset → IT service → business solution. Structural links are validated: no shortcuts, no orphans.
Ownership & criticality
Technical, business and team owners from your directory; criticality, environment and lifecycle on every record.
Topology explorer
Walk the structural graph from a business solution down to the servers it depends on — and back up when something fails.
Risk management
Risk decisions with the assets and controls behind them.
A register with structured assessment, treatment plans and formal acceptance, review reminders and a cost-of-risk view — every risk linked to what it threatens and what protects it.
Structured assessment
CIS RAM-inspired semi-quantitative method: likelihood 1–5 × impact 1–5, score 1–25, thresholds for accept / treat / escalate; the method version is snapshotted on every assessment.
Treatment & acceptance
Treatment plans with owners and dates; acceptance is a formal, approval-gated decision — submit, approve, revoke — with a decision log.
Cost of risk
Put a number on exposure and on treatment so prioritisation is a conversation about money, not adjectives.
How it works
From adoption to evidence in one continuous loop
- 01
Adopt a framework version
Pick ISO 27001, NIS2, DORA — or any of the twelve — from the published library. Adoption is pinned to a version; requirements become your tenant's scope, each with an applicability decision.
- 02
Map assets, owners and controls
Link requirements to controls, controls to assets from the CMDB, and everything to an accountable owner. Third parties and business solutions sit in the same graph.
- 03
Assess, collect evidence, remediate
Run assessments, attach evidence with recency rules, raise findings and drive them to closure. Posture is recomputed from that record — auditable end to end.
Security
Built to pass your security review
You evaluate vendors against procurement and security-review criteria. So do we. The platform is designed around tenant isolation, explicit authorization and an immutable audit record — and this website collects nothing it does not need.
Tenant isolation by design
22 services, one database schema each, no cross-service reads. Platform-scope authority never touches tenant data without an audited, time-bounded access session.
Every change audited
Every mutation appends an immutable audit event — actor, tenant, trace and correlation ids — kept apart from operational logs.
Explicit authorization
One authorization service decides every request across platform, tenant and delegated-access sessions; four-eyes approval per flow, on by default.
This website: no cookies
No trackers, no cookie banner. Demo requests are e-mailed to us; nothing personal is stored on the site itself.
See it on your own frameworks
A walkthrough on a workspace set up for your sector. No trial sign-up, no credit card.