CISO Assistant — Product Documentation

CISO Assistant is an open-source GRC (Governance, Risk and Compliance) platform — a different take on cybersecurity posture management, built on a few load-bearing ideas:

• Explicitly decoupling compliance from security-operations implementation.

• Providing simplified tools for decision-making.

• Assessing a program, product, or whole organisation against standard frameworks.

• Letting you bring your own framework via a simplified DSL.

• Acting as a one-stop shop for the Governance, Risk, and Compliance layers.

• Introduction — design philosophy and vocabulary.

• Concepts — the central objects you work with: domains, perimeters, applied controls, assets, assessments, risks.

• Installation — getting CISO Assistant running.

• — recorded demos and walkthroughs.

• — subscription tiers and what's included.

• — feature-by-feature comparison.

CISO Assistant is built around a small set of design principles. A lot of object boundaries, naming choices, and workflow shapes only make sense once you have these in mind.

Applied controls at the centre

The applied control is the unifying object in CISO Assistant. Everything the organisation does to manage risk and prove compliance is captured as an applied control — a technical safeguard, an organisational process, a documented policy, a tested recovery plan. Once that's in place, the rest of the platform connects to it:

• An audit assesses requirements; each requirement assessment links to the applied controls that satisfy it.

• A risk scenario lowers its current and residual levels by attaching the applied controls in place and planned.

• A task records that an applied control was actually exercised on a given date and produces the evidence to prove it.

• Evidence lives on an applied control — and through it, substantiates every requirement and scenario the control supports.

• An incident response invokes applied controls; a vulnerability is mitigated by them; a policy is one.

Authoring an applied control once and reusing it across all the places it applies — instead of redoing the same work per audit, per risk study, per framework — is the productivity gain that justifies the whole architecture.

The corollary of putting applied controls at the centre is that everything around them must be decoupled, so that one applied control can serve many consumers without being rewritten for each:

• Security controls are decoupled from compliance requirements — a single applied control can satisfy many requirements across many frameworks.

• Risk assessments are decoupled from frameworks — the same risk scenario can inform multiple compliance audits.

• Assets are decoupled from threat scenarios — assets exist independently of any specific risk study and can be reused across them.

The payoff is reuse, end-to-end. One applied control answers many requirements. One assessment covers many frameworks. One asset participates in many scenarios. One evidence file substantiates everything the underlying control supports.

CISO Assistant ships in two editions:

• Community — the open-source edition, free to use, with the platform's core GRC capabilities. Self-hosted only.

• PRO — the commercial edition, built on top of Community, adding enterprise features (sub-domains, focus mode, advanced insights, custom roles, validation flows, and more) plus official support.

A full feature-by-feature comparison lives on the — we keep the matrix there so it stays in sync with pricing and release cycles. This page is here to explain the commercial concepts that intersect with the platform itself: contributor seats and where PRO runs.

PRO is licensed by contributor seats — the number of users in your instance who can actually make changes.

A user counts as a contributor as soon as they have any create / edit / delete permission anywhere in the platform — that is, any role that grants add_…, change_…, or delete_… rights. Concretely, the typical contributor is someone with the Analyst, Domain Manager, or Administrator role (or a custom role that confers similar write rights). Read-only users — anyone whose role only grants view_… permissions — do not consume a seat.

Two narrow categories of users are explicitly excluded from the seat count, even though they may perform meaningful work in the platform:

• Pure approvers — a user whose only write capability is signing off on a . In practice this is the built-in Approver role: its single write permission, change_validationflow, is registered as a non-seat permission. If the same user also holds any other write right (e.g. they're an Analyst who happens to be an approver too), the seat is still counted — being an approver doesn't subtract from the count, it just doesn't add one on its own.

• External third-party representatives — vendor-side users who log into the to fill in entity assessments. They are flagged as external (is_third_party) and are systematically excluded from the count regardless of which write permissions their role grants.

The intent behind the two exceptions is narrow: the seat count tracks internal contributors authoring and maintaining your GRC content, while sparing two patterns where counting would feel punitive — pure sign-off workflows, and external vendors who don't belong to your organisation in the first place.

The instance compares the number of contributors against the seat allowance carried by your license. The current count is visible from About CISO Assistant, opened via the three-dot menu next to your name in the sidebar footer — so you can see at any time how many seats are used and how many are available.

PRO is available on both deployment models, and the feature set is identical between them:

• On-premises — you host the platform on your own infrastructure (Linux VM, Kubernetes via the , or any of the deployment methods documented under ). Your data stays in your network. This is the right model when sovereignty, air-gapping, or strict residency requirements rule out a managed service.

• SaaS — intuitem hosts and operates a managed instance for you. No infrastructure to run, automatic upgrades, backups handled. The right model when you'd rather focus on the GRC programme than on running a Django application.

You can move between the two models — there's no architectural difference, and the data formats (domain exports, library YAML, audit exports) are stable across deployments.

For organisations that don't want to track individual seats — typically large enterprises, MSSPs, public-sector deployments, or any environment where contributor headcount fluctuates often — both the on-premises and SaaS editions are available with an unlimited plan. Under an unlimited plan, the platform doesn't enforce a seat count and you don't need to manage role assignments around license limits.

A SecNumCloud version is also available, with dedicated hosting under the highest available cloud-security qualification. It is offered in unlimited mode. See the for details.

• — current plan tiers and what each includes.

• — the full feature comparison.

• — the governance object whose approvers don't consume a seat.

A domain is a top-level container in CISO Assistant. It represents an organisational scope — a business unit, a subsidiary, or any boundary you want to manage access and reporting around.

Domains are the platform's primary mechanism for access control and reporting boundaries: a user's roles are granted on a domain, and most reports, dashboards, and audit roll-ups can be filtered by domain.

Building a hierarchy

A domain can have a parent domain (parent_folder internally) — that's how you build a tree of sub-domains beneath a top-level one. The hierarchy lets you mirror the shape of your organisation in the platform: a "Group" domain on top, "Region" or "Subsidiary" domains beneath, "Business unit" or "Programme" domains beneath those, and so on.

When a parent-child relationship is in place, two things follow:

• Permissions can flow downward. A user with a role on a parent domain can be configured to see and act on objects in its sub-domains, without re-assigning them at every level.

• Reporting can roll up. Dashboards and analytics aggregate across a domain and its descendants, so leadership-level views work the same way the org chart does.

The root is reserved for global, cross-organisation objects (built-in catalogues, the global library) — your own domains always live one level under it, even when no other hierarchy is in place.

Not every domain needs to be an IAM boundary. Sometimes you want a domain purely as an organisational container — a folder in the tree to group related work — without the platform spinning up the per-role user groups that come with a "real" scoping domain.

The Create IAM groups checkbox on the domain form controls this:

• On (default for new domains) — the platform auto-provisions one user group per role for the domain. Anyone who needs access to objects in this domain gets placed into one of those groups; the domain is a true IAM scope.

• Off — no user groups are created. The domain exists in the tree, can be picked from selectors, and can host objects, but it carries no scoping machinery of its own. Access flows from whatever parent domain it sits under.

Turn the flag off when you want sub-domains that are just structure — for example, breaking a "Subsidiary" domain into a "2025 audits" / "2026 audits" tree purely for organisation, without giving each year its own IAM surface. The setting is shown by the on-form help text: "IAM groups are used to assign roles to users."

The flag is not a one-way choice. You can flip it on a domain at any time — turning it on later provisions the per-role user groups, turning it off later removes them. So a domain you initially created as a pure folder can later become a real IAM scope (or vice versa) without recreating it or moving its content.

The hierarchy is not frozen at creation. Editing a domain lets you change its Parent domain (PRO), which moves the whole sub-tree — the domain itself and every domain beneath it — under the new parent. Use this to:

• Reorganise as your business changes (a programme becomes a subsidiary, two business units merge).

• Promote a sub-domain to top-level by setting its parent back to the root.

• Re-parent for IAM reasons (giving a parent role-holder access to a sub-tree that wasn't previously under them).

The platform prevents cycles — you can't move a domain under one of its own descendants — but everything else is reachable.

Almost every operational object in CISO Assistant is bound to a domain: assessments and audits, applied controls, evidences, risk scenarios, assets, tasks, policies, findings, incidents, exceptions, contracts, entities, and so on. The domain a record lives in is what drives who can see it and how it rolls up in reports.

Because reorganisations happen, the domain assignment is not permanent:

• One at a time — edit any object and pick a different Domain in the form. The platform re-evaluates IAM scoping on save, so the object disappears from one domain's views and appears in the other's.

• In bulk — for models that opt in to bulk operations, the toolbar exposes a Change folder action: select multiple rows in the table, choose the destination domain, and the move is applied across the selection in one go. Useful when reorganising a subsidiary into its own sub-tree, or pulling a programme's controls into a dedicated domain.

A handful of objects whose domain is forced by a parent (e.g. risk scenarios always inherit their risk assessment's domain) intentionally don't expose the batch Change folder action — moving the parent moves the children.

• — how users, teams, and entities get scoped to a domain

A glossary of the terms used in CISO Assistant. Where a user-facing term differs from the internal model name, both are given.

A

• Accreditation — Formal authorisation that a system, environment, or product has met security and compliance requirements. Captured as an object in project-management workflows, often required for go-live.

• Actor — The unifying handle for anyone who can own or be assigned work in CISO Assistant. An actor wraps exactly one of three underlying objects: a User, a Team, or an Entity. Auto-created when its underlying object is created — not managed directly. See Actors and teams.

• Applied control — The main building block of the action plan: a concrete action your team has implemented or will implement. It can be technical, organisational, a process, a policy, a piece of documentation — anything that materially changes risk or compliance posture. Applied controls are always defined by the organisation and can be attached to the global domain or to a specific domain. They may derive from a reference control for consistency, or be created independently.

• Asset — Anything of value worth protecting. Primary assets are core resources directly contributing to the organisation's main objectives (business processes, data, intellectual property). Supporting assets indirectly aid primary functions (IT systems, services, locations, people).

• Asset assessment — A per-asset row inside a business impact analysis, capturing recovery posture (documented, tested, targets met), associated controls, evidence, and the escalation thresholds that describe how impact grows over time.

• Assessment — Umbrella term covering audits (compliance work), risk assessments, business impact analyses, and entity assessments.

• Attack path — In EBIOS RM, the route an attacker may take from a starting point — through stakeholders or supporting assets — to reach a target objective.

• Audit — The evaluation of a perimeter against a framework, producing a per-requirement view of status, score, and evidence. Internally a ComplianceAssessment.

• Audit log — Append-only record of significant actions taken in the platform (creations, edits, permission changes, logins). PRO feature.

• Auditee mode — A read-only UX mode aimed at external assessors who need to inspect an audit without being granted full access to the platform. Gated by the auditee_mode feature flag.

• Business impact analysis (BIA) — A structured assessment of the operational, financial, and reputational impact of disruption to specific assets or business processes. Outputs feed into resilience planning.

• Campaign — An orchestration object for running many audits in parallel — for example, one audit per perimeter against the same framework. PRO feature.

• Catalog object — A reusable building block of CISO Assistant: framework, threat, risk matrix, reference control, mapping, security advisory, CWE. Catalog objects are packaged into libraries.

• Compliance assessment — Internal model name for an audit. See Audit.

• Dashboard — A configurable view of metrics and progress indicators, scoped to a perimeter or a domain.

• Data breach — In a privacy register, an incident affecting personal data, with notification status and response actions.

• Data contractor — A third party involved in a processing as data processor, sub-processor, or joint controller. Distinct from a generic supplier entity — captures the privacy-specific role.

• EBIOS RM — The French ANSSI risk-management method, supported natively in the platform as its own object graph (studies, feared events, stakeholders, strategic and operational scenarios, kill chains).

• Elementary action — In EBIOS RM, an atomic step an attacker can perform. Composed into operating modes.

• Entity — Scope of an external review — typically a vendor or third party.

• Feared event — In EBIOS RM, the undesirable outcome to be avoided on a primary asset — for example, a confidentiality breach of customer data.

• Filtering label — A free-form tag that can be attached to most objects for categorisation, filtering, and reporting.

• Findings assessment — A formal record tracking issues raised by an audit, a security review, or an external assessor, used to drive remediation through to closure.

• Generic collection — A flexible grouping object in project-management workflows: a "bag" of related items that doesn't fit a more specific schema.

• Incident — A security or operational event being investigated or tracked. Distinct from a risk (potential) or a vulnerability (weakness).

• Inherent risk — The natural risk level of a scenario without any applied controls. The top tier of CISO Assistant's three-tier model — useful for ranking scenarios by their underlying severity, independently of the mitigation already in place. Surfaced in the UI when the inherent_risk feature flag is on.

• Journey — An instance of a applied to a domain. Carries the scaffolded objects created at apply time and a step list with per-step statuses, notes, and completion timestamps. See .

• Journey step — One row of work inside a journey: a title, description, optional pointer to a target object or internal route, and a status (not started, in progress, done, skipped).

• Kill chain — In EBIOS RM, an ordered sequence of attacker steps culminating in the target objective.

• Library — Container object bundling one or more catalog objects (frameworks, matrices, threats, reference controls, mappings, security advisories).

• Managed document — A document tracked through a controlled lifecycle (draft, in-review, validated, published, deprecated) and pinned to a parent object such as a policy. Each iteration is a .

• Mapping — Based on the . Allows moving an assessment from framework A to framework B while reusing existing requirement assessments.

• Metric definition — A reusable specification for a measurable indicator (formula, target, unit, scope). Defined once, instantiated per perimeter.

• Operating mode — In EBIOS RM, a specific way an attacker can carry out an operational scenario, composed of elementary actions.

• Operational scenario — In EBIOS RM, the detailed "how" of a strategic scenario — the assets touched, the steps taken, and the techniques used.

• Organisational issue — A documented context element describing an internal or external problem affecting the organisation.

• Perimeter — A scoped subset of a domain that an audit or risk assessment applies to. Unlike a domain, a perimeter does not enforce role-based access control. Perimeters were previously called "Projects".

• Personal access token (PAT) — A long-lived authentication token a user can issue from their profile to authenticate API calls. Alternative to session-based login; used by scripts, integrations, the CLI, and the MCP server.

• Personal data — In a privacy register, any data referring to an identified or identifiable individual.

• Quantitative risk hypothesis — A parameter set (loss-event frequency, magnitude distribution) feeding a quantitative risk scenario.

• Quantitative risk scenario — A scenario inside a quantitative risk study, evaluated via Monte-Carlo simulation over loss distributions.

• Quantitative risk study — A risk study using quantitative methods rather than a risk matrix. Sibling to qualitative risk assessment and EBIOS RM.

• Recap — The roll-up view of a business impact analysis, aggregating asset assessments and their escalation thresholds into a single readout.

• Recovery target — A documented commitment for restoring an asset after disruption, typically a Recovery Time Objective (RTO) or Recovery Point Objective (RPO). Tracked on an asset assessment as "documented", "tested", and "targets met" flags.

• Reference control — A template for an applied control. Provided by frameworks via libraries, or defined locally. Optional but recommended for keeping applied controls consistent across the organisation.

• Security advisory — A catalogued security warning published by a vendor or CERT (e.g. CVE entries). Linked to vulnerabilities and affected assets.

• Security exception — A documented, time-bound deviation from a control or policy, approved through a workflow and tracked for review.

• Severity — The shared ordinal scale used to qualify vulnerabilities, incidents, and findings: undefined / info / low / medium / high / critical. Drives SLA escalation and visual emphasis in dashboards.

• Task definition — A reusable specification of a task: default assignee, owner, recurrence rule, expected evidence. Defining a task creates one or more task occurrences over time. Internally a TaskTemplate.

• Task node — Internal model name for a task occurrence. See Task occurrence.

• Task occurrence

• URN — Uniform Resource Name. A unique identifier used to link to catalog objects across libraries.

• User — A person with an account on the platform.

• User group — A combination of a role and a domain, on which you place users. Auto-created when a domain is created.

• Validation flow — A configurable approval workflow that mirrors an organisation's internal review or management-approval process — peer-review, sign-off by a security lead, formal acceptance by a steering committee. Attached to objects whose state changes warrant such review (e.g. risk acceptance, audit close-out), it captures the human approval step inside the platform rather than enforcing it as a hard technical gate.

• Vulnerability — A weakness in a system or process that could be exploited by a threat. Tracked with severity, status, and linked applied controls.

• Webhook endpoint — A registered URL CISO Assistant calls when configured events happen (e.g. an audit closed, an applied control updated). Used to notify external systems and trigger downstream automation.

A perimeter is an optional scope refinement an assessment or risk study can be attached to, inside a domain. Where a domain defines who owns the work and what they can see, a perimeter narrows the assessment to exactly what is being assessed — a product, a system, a process, a contract.

Perimeters are optional everywhere they appear: an assessment without a perimeter is scoped to its domain only. Use them when you need to track several distinct scopes inside the same domain, or to roll up assessments by scope rather than by domain.

When to use a domain vs a perimeter

The two concepts solve different problems — and the choice matters because it shapes both who can see what and how reports roll up.

• Use a domain (or a sub-domain) when the boundary needs to enforce IAM scoping or anchor reporting. Domains are where roles are granted, where permissions stop, and where dashboards aggregate. Pick a domain when different teams must have different levels of access, or when leadership wants to see one number per business unit / subsidiary / regulated entity.

• Use a perimeter when the boundary is purely logical, inside an already-scoped domain. Perimeters split the work into distinct named scopes — a product, a system, a process, a contract — so you can run separate audits or risk studies against each without spinning up extra IAM machinery. Everyone with access to the domain sees every perimeter inside it; there's no per-perimeter access control.

A useful mental check: "Do these two scopes need different people seeing them?" — if yes, they're domains (or sub-domains). "Do these two scopes need separate assessments but the same audience?" — they're perimeters.

Almost every object in CISO Assistant has an assignee — the applied control someone is responsible for, the audit a team is running, the contract a supplier signs. The platform represents all these counterparties through a single abstraction: the actor.

Mental model

The actor is a one-to-one wrapper that always points at exactly one of three concrete records — a user, a team, or an entity (the three dashed edges are exclusive: a database check constraint enforces XOR). Every Assigned to / authorship / approver field on the platform (applied control assignee, audit author, task assignee, contract counterparty…) holds an actor, so a single code path resolves notifications and access regardless of the underlying type. Teams aggregate users via leader, deputies, and members — assigning to a team fans out to every user in it.

An actor is the unifying handle for anyone who can be assigned to work in CISO Assistant. Every actor wraps exactly one of three concrete underlying objects:

• A user — a person with a platform account.

• A team — a named grouping of users for collaborative responsibility.

• An entity — an external party from the third-party register (typical for contracts and entity assessments).

The actor abstraction means the same Assigned to field on an applied control can hold a user, a team, or a supplier without the consuming code caring which it is. Notifications, emails, assignments, and reporting all go through the actor — they fan out to the right addresses regardless of the underlying type.

Actors are created automatically when their underlying object is created. You don't manage actors directly; you manage users, teams, and entities, and the actor records follow.

A team is a named grouping of users used for collaborative assignment — when the responsibility for something belongs to a working group rather than an individual.

A team has:

• A leader — a single user accountable for the team.

• Deputies — users who can act in the leader's place.

• Members — the broader group.

Teams are first-class targets for assignments and notification routing. When work is assigned to a team, anyone with the appropriate role in the team's domain can act on it.

These two are easy to confuse:

• A team is a collaborative group with members, a leader, and deputies. It's about who works together. Teams are voluntary, organisational, and can span any domain.

• A user group is a (role, domain) pair on which users get placed. It's about what permissions someone has where. User groups are auto-created when a domain is created — one per role per domain.

You join a team for collaboration. You're placed in a user group for access. Both can carry users; they answer different questions.

• Applied controls are assigned to one or more actors.

• Requirement assessments can be assigned to an actor for completion.

• Tasks are assigned to actors and notify them when due.

Because all of these use the same actor handle, an audit log that says "assignee changed from team A to user B" is unambiguous, and the platform can resolve notifications the same way everywhere.

• — where role-based access control happens

This page is the mental model for how access and visibility work in CISO Assistant. The full configuration-side deep-dive (SAML / OIDC / MFA / PATs / accounting) lives in ; this page focuses on the three things every user needs internalised before they can predict what they will and won't see on screen:

1. Almost everything is bound to a domain.

2. Permissions are inherited down the domain tree.

A framework is a normative body of requirements that audits are measured against — an industry standard (ISO/IEC 27001, NIST CSF, SOC 2), a regulation (NIS2, DORA, GDPR), a custom internal standard, or any other structured set of requirements.

In CISO Assistant, frameworks are shipped as YAML libraries and are the foundation of every audit.

A framework lives inside a loaded library and is read-only. It comprises a tree of requirement nodes — some assessable, some structural — linked parent-to-child via the self-loop. Creating an audit instantiates the framework: each assessable node becomes a requirement assessment inside the audit. Requirements can optionally suggest reference controls (templates for the applied controls that satisfy them), and a framework can be mapped to other frameworks for cross-walks.

A library is a bundled set of catalog objects — frameworks, threats, risk matrices, reference controls, mappings, security advisories, CWE entries — distributed as a YAML file.

Libraries are how content gets into CISO Assistant. They make the platform extensible: anything from a regulator's framework to a vendor's threat feed to your organisation's internal control catalogue is just another library.

Mental model

A library starts life as a stored record — its YAML is parsed and registered but contents stay inactive. Loading it materialises whatever catalog objects the YAML declares — any subset of framework, risk matrix, threats, reference controls, or mapping set (all dashed, all optional). A loaded library can also declare dependencies on other loaded libraries — for example, a framework library that ships its companion reference-control catalogue as a separate dependency.

A library can be in one of two states:

• Stored — the library is known to the instance but its content hasn't been activated yet. It's visible in the libraries store, ready to be loaded on demand.

• Loaded — the library is active. Its catalog objects show up across the platform: a loaded framework becomes available when creating an audit; a loaded threat appears in the threats list; loaded reference controls power autosuggestion.

A library typically contains a single primary object (for example, one framework) but may bundle related ones — a framework alongside its companion reference-control catalogue and its mapping to a sibling framework.

Library content is referenced by URN (Uniform Resource Name), an immutable identifier that survives renames and re-imports.

• Built-in libraries ship with the platform — over 100 frameworks plus the standard threat, matrix, and reference-control catalogues.

• Community libraries are contributed by the open-source community; see .

• Custom libraries can be built locally and loaded without sharing them, useful for internal frameworks or control sets.

See for the format.

Libraries are versioned. When a newer version is available, you can upgrade in place — your existing audits keep using the version they were created with until you migrate them explicitly. See and .

A mapping (also called a crosswalk) describes how the requirements of one framework relate to those of another. Once a mapping is loaded, an audit performed against the source framework can be projected onto the target framework — reusing the existing requirement assessments where the mapping is strong, surfacing gaps where it isn't.

Mappings are catalog objects: defined once as a YAML library, loaded into the platform, and applied on demand.

Mental model

A mapping set is the unit shipped by a library — it pins exactly one source framework and one target framework. Inside the set, each individual mapping connects one source requirement node to one target requirement node and carries a relationship type (equal / subset / superset / intersect / not_related). Applying the set to an audit projects the existing requirement assessments onto the target framework: full-coverage relationships (equal, superset) copy directly; partial-coverage (intersect, subset) require manual review.

Most organisations have to demonstrate compliance against multiple frameworks at once — ISO 27001 plus SOC 2 plus a sector-specific regulation, for instance. Without mappings, you re-assess the same control posture against every framework's requirement list, which is busywork. With mappings, you assess once and project.

A mapping is a directed graph linking assessable nodes of a source (SRC) framework to assessable nodes of a target (TGT) framework, using the convention from project.

Each relationship between a SRC node and a TGT node has a type, which is easiest to read as a set relation between what each requirement covers:

• No relationship — the two requirements are disjoint; nothing carries over.

• Equal — the two requirements are equivalent in scope and intent.

• Subset — the SRC requirement is contained within (narrower than) the TGT requirement.

The directionality matters: a mapping from A → B does not automatically imply B → A. Reverse mappings can be generated, but the relationship type usually inverts (a SRC subset becomes a TGT superset).

Once a mapping library is loaded, it can be applied to an existing audit:

1. Open the source audit.

2. Click Apply mapping and pick the target framework.

3. The platform creates a new audit on the target framework and copies over the requirement assessments where the mapping is strong (typically equal), leaving the rest to be assessed.

The apply-mapping feature can also clone an audit onto the same framework — useful for creating a new revision while keeping the previous one for history.

You don't need a direct mapping between every pair of frameworks. If the platform holds a mapping from A → B and another from B → C, it can chain them automatically to project an A audit onto C, using B as a pivot — even though no one ever authored an A → C crosswalk.

The mapping engine treats the loaded mapping sets as a directed graph of frameworks and searches for a path between your audit's framework and the target you pick. When you open an audit and choose Apply mapping, the list of available targets already includes every framework reachable through the graph — both directly mapped ones and those reachable only through one or more pivots. You select the destination; the chaining happens behind the scenes.

How the chain behaves:

• Coverage degrades to the weakest hop. Full-coverage relationships (equal, superset) chain cleanly. If any hop in the path is partial (subset, intersect), the projected result is marked partial and flagged for manual review — a chain is only as strong as its loosest link.

• The best path wins. When several pivots connect A to C, the engine keeps the path that successfully maps the most requirements, and records which intermediate framework(s) it went through so the projection is auditable.

This is what makes a modest set of crosswalks go a long way: a hub framework such as ISO 27001 or NIST CSF that is mapped to many others effectively becomes a translation pivot between all of them.

Many cross-walks ship as built-in or community libraries (ISO 27001 ↔ NIST CSF, SOC 2 ↔ ISO 27002, and so on). When none of them fits, you can author your own — see and the prepare_mapping_v2.py tool that scaffolds a mapping skeleton between two loaded frameworks.

A threat is a catalogued source of potential harm — a phenomenon, agent, or event that could compromise an asset, a business process, or a regulatory obligation.

Threats are reusable building blocks: a single threat (say, "Phishing") may appear in many risk scenarios, EBIOS RM operational scenarios, and applied control rationales without being duplicated.

When threats appear

• Risk scenarios — most qualitative risk scenarios name the threat that drives them.

• EBIOS RM operational scenarios — threats are mapped to attacker techniques in the kill chain.

• Vulnerability tracking — threats can be linked to vulnerabilities to express what could exploit this weakness.

• Applied controls — controls can declare which threats they address.

CISO Assistant ships with curated threat libraries based on common sources — MITRE ATT&CK, ENISA, the ISO 27005 illustrative threat catalogue, sector-specific catalogues. You can also create your own threats inside a domain, or contribute a custom threat library.

A risk assessment can be done without referencing threats — the platform doesn't force it. Naming the threat behind a scenario makes the analysis sharper, more reusable, and easier to map back to threat-intelligence feeds.

A risk matrix is a configurable lookup table that maps a (probability, impact) pair to a resulting risk level. It's what turns "likely × severe" into "critical" — the encoded judgement that lets a risk assessment be more than a free-form narrative.

Risk matrices are catalog objects: defined once, packaged into libraries, loaded into the platform, and reused across many risk assessments.

Mental model

A risk matrix is a JSON definition (probability axis, impact axis, risk levels, and the grid linking them) bundled in a library. Once a risk assessment is created against a matrix the binding is permanent — the FK uses on_delete=PROTECT — because switching matrices mid-assessment would silently change every risk level, which is what auditors don't want. Each risk scenario in the assessment reads its inherent, current, and residual risk levels from the same matrix's grid using the (probability, impact) pair the assessor sets at each tier.

A matrix has four pieces:

• Probability levels — the ordered scale used for likelihood (e.g. negligible, low, medium, high, very high).

• Impact levels — the ordered scale used for severity (financial, reputational, operational, or whatever scale the organisation uses).

• Risk levels — the resulting categories (e.g. low / medium / high / critical), usually colour-coded.

The grid is the substance of the matrix; the visual rendering (orientation, colours, layout) is handled by the UI based on the loaded matrix definition.

When a risk assessment is created, its risk matrix is captured and stays fixed for the lifetime of that assessment. Re-evaluating the same scenarios against a different matrix would silently change the risk levels under your feet, which is exactly what auditors don't want.

If you change matrices mid-programme, you create a new risk assessment against the new matrix and migrate the scenarios. The old assessment keeps its history; the new one starts clean against the new scale.

Each scenario in a risk assessment is evaluated three times against the chosen matrix:

• Inherent risk — what the risk would be with no controls.

• Current risk — what it is today given existing applied controls.

• Residual risk — what it will be once planned applied controls are implemented.

The matrix is the same for all three tiers; what changes is the (probability, impact) pair the assessor sets at each tier. See for how the three tiers are used.

Matrices ship as YAML libraries — the same format as frameworks, with _meta and _content sheets defining the probability/impact/risk axes and the grid. They are typically authored in Excel using the templates under tools/excel/matrix/ and converted to YAML.

Designing a matrix correctly — particularly the grid — is non-trivial. Start from one of the existing examples and adapt the levels and grid logic rather than building from scratch. See .

A journey is a guided, step-by-step workflow that walks a domain through a recognised process — getting an organisation ready for ISO 27001 certification, running a DORA readiness assessment, building out a privacy register, and so on.

Journeys remove the "what do I do first?" problem. Instead of staring at an empty domain and assembling the right libraries, assessments, and tasks by hand, you pick a journey, apply it to a domain, and start working through the prescribed steps.

Preset vs journey

Journeys come in two flavours of object that mirror the Framework → Audit pattern elsewhere in the platform:

• A preset is the template. It bundles a set of starter objects (typically an audit, a risk assessment, sometimes additional scaffolds) plus an ordered list of steps with descriptions and links into the platform. Presets are versioned and shipped via libraries; they can also be authored locally.

• A journey is an instance of a preset, materialised in a specific domain. Applying a preset creates the scaffolded objects in the chosen domain and copies the step list onto the journey so that step statuses can be tracked independently from any other journey.

The same preset can be applied to multiple domains and yields a distinct journey each time.

1. Browse the catalogue. The presets page lists everything available on the instance — library-backed presets shipped with CISO Assistant (ISO 27001 starter, DORA readiness, NIS2, sector-specific bundles, etc.) and any presets authored locally. Filter by region tag to narrow the list.

2. Apply to a domain. Pick a target domain (or create one on the fly). Optionally let the journey create the scaffolded objects for you and apply any feature flags the preset suggests.

3. Work the steps. Each step has a title, description, and either a target object (e.g. "open the SOA review for the ISO audit") or a target URL inside the platform. Mark steps as

• Scaffolded objects — the assessments and supporting records that get created when the preset is applied. Typical scaffolds include compliance assessments (with framework + implementation-group selection), risk assessments (with a chosen matrix), and occasionally task templates, perimeters, or entities.

• Steps — an ordered list of actions to perform. Each step can point at a scaffolded object (via a named reference resolved at apply time) or at a generic internal route such as the SOA results page. Steps carry translations so the workflow speaks the user's language.

• Feature flags — some presets enable optional features when applied (reports, sec-intel feeds, etc.), letting the journey come with a fully-configured environment.

Applying a preset requires permission to load libraries on the target domain. Viewing journeys and updating their step statuses follows the standard domain-scoped permission model — see .

The threat intelligence layer holds the catalogued knowledge CISO Assistant uses to prioritise vulnerabilities, qualify incidents, and connect operational findings to the wider security ecosystem. Today it covers security advisories, weakness catalogues, and a small set of public enrichment feeds; the surface is expected to grow significantly in upcoming releases.

Security advisories

A security advisory is a catalogued security warning published by a vendor, CERT, or standards body. CISO Assistant supports four sources today:

• CVE — the MITRE/NIST CVE Program identifiers (CVE-YYYY-NNNN).

• EUVD — the EU Vulnerability Database (post-NIS2 European equivalent).

• GHSA — GitHub Security Advisories.

• Other — for sources that don't fit the above.

Each advisory carries the usual identifying metadata (reference ID, published date, references) plus the bits that drive prioritisation:

• CVSS base score and CVSS vector — severity per the standard scoring system.

• EPSS score and EPSS percentile — probabilistic exploitation likelihood from FIRST.

• Active exploitation flag and the KEV date when the advisory landed on CISA's Known Exploited Vulnerabilities list.

Advisories are catalog objects: library-backed, root-folder-published, referenced from vulnerabilities and assets rather than re-created per scope.

The Common Weakness Enumeration is MITRE's catalogue of software-weakness categories — buffer overflows, missing authentication, improper input validation, and so on. Where a security advisory is "this specific vulnerability in this specific product", a CWE is "this class of flaw". CWEs are catalogued separately and tagged onto advisories and vulnerabilities to enable categorical analysis ("how many of our open vulns are credential-handling bugs?").

CWEs ship as their own catalog library; loading the CWE library makes the entries available across the platform.

A vulnerability in CISO Assistant is the organisation-specific record — "we have this exposed in our environment, here's the SLA". It links to:

• One or more security advisories — the upstream finding(s) it corresponds to.

• One or more CWEs — the weakness categories it belongs to.

This linkage is what lets enrichment feeds work end-to-end: advisories get scores from EPSS, exploitation status from KEV, and category mappings from NVD; vulnerabilities inherit that context via their advisory links and surface it in dashboards and SLA prioritisation. See .

Three public feeds enrich the catalogue when enabled — they keep the threat-intel layer current without manual data entry. Configuration is under :

• KEV feed — CISA's Known Exploited Vulnerabilities; flags advisories under active exploitation.

• EPSS feed — FIRST's Exploit Prediction Scoring System; attaches a probabilistic exploitation score.

• NVD enrichment — pulls extra metadata from the NIST National Vulnerability Database (CWE mappings, affected configurations, references).

Each feed is a separate flag and can be toggled independently. The platform stores feed status, network timeout, and last-update timestamps centrally.

The threat-intelligence surface is being expanded to cover full STIX-style threat intelligence — threat actors, attack patterns, indicators of compromise, campaigns, sightings — along with STIX 2.1 / TAXII / MISP / OpenCTI interop and DORA cyber-threat notification workflows. The objects on this page remain the entry point; new SDOs will sit alongside them.

Expected outcome

• define your metrics or import their definition

• instantiate them on your domains

• feed data to your metric instances

• create dashboards with builtin and custom metrics

A metric definition is the catalog template — qualitative (level) or quantitative (number with unit) — and can be shipped via a library. Each instance scopes one definition to a domain and carries the operational fields: assignee, target value, collection frequency (auto-stale logic kicks in when the latest sample exceeds the cadence + grace period). Samples are timestamped data points against an instance. Dashboards are independent of the metrology pipeline: they comprise widgets, and each widget either reads a custom metric instance, pulls from a builtin sample (a system-computed daily snapshot attached generically to any tracked object — assets, audits, projects, incidents, etc.), or just displays free text.

Consider metric definition as a template of your metric. It serves as the guideline of the actual metric instance that you will track accross your domains.

You will learn how to import off-the-shelf metrics definitions on CISO Assistant.

Click "Metric definitions".

Click here to proceed to the next menu.

You can also preview the content before importing it.

Click "Metric definitions" to revisit the main metrics page.

Click "Search..." to begin finding specific metrics.

You can now instantiate this metric as you see fit for your domains.

You can now instantiate this metric as needed across your domains. Keep in mind that you can also create your own metric definition directly without going through the library.

Metrics can be quantitative (number with unit) or qualitative (choices):

You can add your options during declaration or afterward:

The "higher is better" setting is used to indicate if the trend is a good thing or not.

The metric instance is the projection of the definition to a specific domain and it's what you'll be tracking.

Parameters:

• Metric definition (it will inherit its settings)

• Domain: the scope of this metric

• Status: lifecycle of the metric. The stale is specially interesting as the application will auto-toggle it according to the data freshness

This is the actual data of the metric instance on a given timestamp.

Keep in mind that you can add the data manually or through all the supported integrations (API, n8n, etc.). Note that data cannot be in the future.

Dashboards are the visual representation of the metrics and support:

• custom metrics instance (multiple charts)

• built-in metrics (multiple charts)

• markdown text widget

In edit mode, you can add different widgets, place and resize them as you see fit:

Once done, you can go back to view mode to see the result:

In addition to the custom metrics for your internal KPI and KRI, you can also include some of the built-in metrics tracked by the platform:

Those are updated on each change of your data and tracked as daily metrics.

An asset class answers "what kind of thing is this?" for an asset — a server, a business process, a set of personal data. Classes form a tree, so a class can be a refinement of a broader one, and an asset points at most one class.

CISO Assistant ships with a taxonomy derived from the CIS asset categories (Devices, Software, Data, Users, Network, Facilities, Documentation, Business Process, and their sub-classes). You can extend that tree with your own classes, and hide the shipped ones you don't use.

Why it exists

The class is deliberately separate from the domain an asset lives in and from its primary/supporting type. Those three answer different questions:

Keeping them apart means you can classify a supporting asset in one domain and a primary asset in another under the same class, and then read your whole estate by class regardless of who owns it.

A class refines a parent class, forming the taxonomy tree. An asset is classified by at most one class — the link is optional, so an unclassified asset is valid and stays fully usable. The domain still scopes the asset; classes are organisation-wide and carry no access control of their own.

The shipped classes are marked Builtin. They are re-created every time the platform starts, which is why they behave differently from classes you create:

• They cannot be renamed or deleted — a rename would be undone and a deletion would silently reappear on the next restart. The edit form states this: "Built-in classes are provided with the product: they can be hidden, but not renamed or deleted."

• They can be hidden. Clearing Visible removes a class from the picker used when classifying an asset, without touching any asset already classified under it. The form notes: "Hidden classes stay listed here but are no longer offered when classifying an asset."

Classes you create are yours entirely — rename, re-parent, hide, or delete them (see ). Creating a class under a built-in one is the intended way to extend the shipped taxonomy: the child is your own class, and the built-in parent stays untouched.

Hiding a class that still has visible sub-classes does not orphan them. The class remains in the picker as a non-selectable grouping row so its descendants keep a readable path.

In the sidebar under Extra → Asset classes.

The table lists Name, Parent class, Description, Translations, Visible and Builtin. Filters let you narrow to visible or built-in classes.

Use the add button on the Asset classes page. The form asks for:

• Name — free text.

• Description — optional.

• Parent class — optional. Leave it empty to create a top-level class. The picker is a tree, and it excludes the class you are editing along with everything beneath it, so a class can never become its own ancestor.

To add a child directly under an existing class, open that class and use the add button on its children table: the Parent class is filled in for you.

Built-in class names are translated by the interface itself and follow the language you are using. Classes you create are free text, so they need their own translations.

The Translations editor on the class form takes a Name and a Description per language. When you are using a language that has no entry, the class falls back to the name you typed when you created it. That fallback is why a class can look "untranslated": it means no entry exists for your current language, not that translation is unavailable.

Deleting a class also deletes every class beneath it. The confirmation dialog lists exactly what will go, so check it before confirming.

Assets classified under a deleted class are never deleted — they simply become unclassified. They keep every other property, and you can re-classify them afterwards.

On the asset form, the Class field is a searchable tree. Only visible classes are offered. Type to search across the whole taxonomy, or expand the tree to browse it; the selected class shows its full path so you can tell two same-named classes apart.

The Assets by class page turns the taxonomy into a way to navigate your estate. Reach it from the Assets page using the tree icon.

Each class shows a count of the assets beneath it, rolled up through the tree, so a parent class with no assets of its own still shows what its children hold. Expanding a class lists the assets classified directly in it; classes with no assets at all are hidden unless you clear Hide empty classes.

Assets with no class appear in a separate Unclassified group at the bottom — a useful starting point when you are working through a backlog of unclassified assets.

Only assets you are allowed to see are counted or listed, so the totals on this page are yours, not the whole database's.

Asset exports include an asset_class column holding the class's full path, with each level separated by / — for example assetClassDevices/assetClassEnterpriseAssets/assetClassServers.

The path is used rather than a display name because it is unambiguous (two classes may share a name under different parents) and stable across instances and languages. Imports accept the same format in an asset_class column, and also accept a bare class name when only one class in the tree carries it.

If an import names a class that does not exist, the asset is still imported — it simply arrives unclassified, and the row is reported as a warning.

Domain exports carry asset classes the same way. When you import a domain into another instance, any of your own classes that the target does not have are re-created, while built-in classes bind to the ones already there.

• — a different organisation-defined override

• — confidentiality labelling, not typology

An asset is anything of value worth protecting. Assets are first-class objects in CISO Assistant, decoupled from any specific risk study or audit, so the same asset can participate in many analyses without being duplicated.

Assets are always defined by the organisation and can be attached to the global domain or to a specific domain.

Mental model

The asset is a hub other surfaces point at: risk scenarios impact it, vulnerabilities affect it, incidents affect it, and a Business Impact Analysis assesses it (through an intermediate AssetAssessment row, one per asset in the BIA). The supports self-loop captures the primary/support hierarchy — a support asset is recorded as a child of its primary parent through parent_assets.

• Primary assets are core resources directly contributing to the organisation's main objectives — business processes, data, intellectual property.

• Supporting assets indirectly aid primary functions — IT systems, services, locations, people.

The distinction matters for risk work: scenarios typically express what can happen to a primary asset via which supporting assets are involved.

An applied control is the main building block of the action plan: the actual action your team has implemented or will implement to address a security need. It can be technical, organisational, a process, a policy, a piece of documentation — anything that materially changes risk or compliance posture.

A single applied control can satisfy any number of requirements across any number of frameworks — it's where what the framework asks meets what the organisation actually does.

Mental model

The applied control sits at the centre — anything that asks for action points to it; everything that proves the action took place hangs off it. Compliance work (requirement assessments), risk work (scenarios), follow-up work (findings), and operational maintenance (tasks — periodic reviews, evidence refresh, assignee rotation) all reference the same control, while evidences and protected assets accumulate on the other side. This is the decoupling principle made concrete: one applied control, many demand-side users.

Applied controls are fundamental for both compliance and remediation. They can derive from a reference control for consistency, or be created independently. They are always defined by the organisation and can be attached to the global domain or to a specific domain.

The status field is what turns an applied control from a static catalogue entry into a live, trackable piece of work. It's the single signal that drives roll-ups across audits, dashboards, action plans, and reporting — so it's worth understanding how it moves.

The target state of an applied control is Active, not Done. This is deliberate. A control is never finished in the way a project task is finished: a backup policy that's been written and approved still has to keep being followed, a firewall rule that's been deployed still has to keep being enforced, an access review that's been run still has to be run again next cycle. Reaching Active doesn't end the work — it starts the maintenance phase. The work shifts to keeping the control in Active, through periodic reviews, evidence refresh, and the that "maintain" it.

This is why the lifecycle has Active, Degraded, and Deprecated rather than Done. A control that's failing partially moves to Degraded (signal to act); a control that's no longer needed moves to Deprecated (retire with history intact). There's no terminal "done" state on purpose — the whole point of cybersecurity controls is that they're a continuous effort to stay in Active, not a checkbox you tick once.

The lifecycle runs through seven states:

Why the lifecycle matters across the platform:

• Risk model — Current risk uses controls in active (and partly degraded); residual risk also factors in controls in to_do / in_progress (the planned ones). Moving a control from to_do to active is what closes the gap between residual and current.

The transitions aren't enforced as a strict state machine — you can move a control between any two statuses — but staying within the lifecycle above makes audit trails and analytics meaningful.

Applied controls carry a structured cost field, so the financial weight of your security programme isn't a separate spreadsheet — it's attached to the controls themselves and rolled up wherever they appear (most notably on every ).

The platform models the build vs run distinction that controls actually carry in practice:

Each side accepts two inputs:

• Fixed cost — a money amount (hardware purchase, licence fee, contractor invoice).

• People days — a measure of internal effort. The platform converts this to money using the daily rate configured in General settings, so internal time is comparable with external spend.

From these inputs, the platform computes an annual cost for every control:

That single number is what feeds every roll-up — the action plan's budget overview, the per-assignee and per-domain breakdowns, the by-status / by-priority / by-CSF-function totals. Controls without a cost set contribute zero, so partial adoption of the financial tracking still works — you fill in numbers where you have them and the totals reflect what's known.

The annualised view matters because cybersecurity controls are continuous (see above). A capex-style "we paid €40k once" view doesn't compare well across controls; an "annual cost in steady state" view lets you put a single line per control on the budget and compare them like-for-like.

A reference control is a template for an applied control. Reference controls facilitate the creation of applied controls and help keep them consistent across the organisation.

They can be provided by security frameworks imported from a library, or you can create your own — in the global domain or in a specific domain. Reference controls are optional but recommended.

A policy is a specific type of applied control: a document describing what is expected from some part of your stakeholders. Putting your cybersecurity policies in CISO Assistant makes them readily available for audits, and lets you manage their lifecycle alongside the rest of your controls.

An incident is a security or operational event being investigated or responded to. CISO Assistant treats incidents as first-class objects so that detection, response, evidence, and the controls that should prevent recurrence all live in one place.

Incidents are deliberately distinct from related concepts:

• A risk scenario is a potential adverse event — the possibility.

• A vulnerability is a weakness that could be exploited — the gap.

• An incident is something that has actually happened and is being handled.

An incident lives in a domain and aggregates everything about the event: the assets it affected, the threats it's attributed to, the actors handling it, the applied controls invoked during response, and any task templates set up for follow-up work (post-mortem, control review). Timeline entries are the append-only log of what happened and when — detection, mitigation, observation, severity / status changes.

• Identifiers and classification — a name, an optional reference ID, the severity (critical / major / moderate / minor / low / unknown), and the status through its lifecycle.

• Timing — when it occurred, when it was reported, when it was resolved.

• Detection — internal vs external, optionally with a link to the source signal.

Incidents follow a five-state lifecycle:

new → ongoing → resolved → closed (or dismissed at any point if the event turns out not to be a real incident)

State transitions are recorded in the incident timeline, an append-only log of significant moments: detection, mitigation, free-form observation, severity changes, status changes. The timeline is what an auditor or a post-mortem author will read to reconstruct what happened.

For regulated tenants, CISO Assistant ships a DORA incident report — a structured form aligned with the Digital Operational Resilience Act notification requirements (initial, intermediate, and final reports). It draws from the underlying incident but adds the regulatory fields and timing that DORA prescribes.

Tasks are how CISO Assistant tracks the operational work that keeps controls effective: the weekly access review, the monthly backup test, the quarterly policy refresh, the one-off offboarding checklist. They are deliberately separate from applied controls — a control says what is done; a task says that someone has actually done it on a given date.

The task template is the definition — assignee, recurrence rule, expected evidence — and the task occurrence is the actual unit of work scheduled from it. The schedule is a JSON field describing the cadence (DAILY / WEEKLY / MONTHLY / YEARLY with the usual iCalendar refinements). Templates can be wired to many other objects — applied controls being the canonical one (the "maintains" semantics: this work keeps that control healthy) — and when an occurrence is completed, the evidence revision it produces is back-linked through task_node so the audit trail closes the loop.

A business impact analysis (BIA) measures the operational, financial, and reputational consequences of disrupting specific assets or business processes — the input to any serious resilience plan.

Where a risk assessment asks "what could go wrong?", a BIA asks "if it does, how bad is it, and how quickly does it become unacceptable?".

Mental model

A BIA is an assessment scoped to a perimeter. For each asset in scope, the platform captures:

• Asset assessment — the impact of disruption along one or more dimensions (financial, operational, regulatory, reputational).

• Escalation thresholds — the durations after which disruption becomes severe, critical, or unacceptable — often expressed as RTO (Recovery Time Objective) levels.

The output is a prioritised view of which assets your continuity plan must protect first.

• BIAs read from the asset inventory — assets are first-class objects, not BIA-private records.

• The criticality output can drive risk scenario prioritisation for the same assets.

• For organisations subject to DORA, BIA results feed into incident-reporting workflows.

A policy is a specific type of applied control: a document describing what is expected from some part of your stakeholders — an acceptable-use policy, a password policy, a data-classification policy, an incident-response procedure, anything that defines how things should be done.

Because policies are applied controls under the hood, they inherit the full applied-control machinery: they live in a domain, have an assignee and a status, link to the requirements they satisfy, and carry evidence.

Why give policies their own page

Policies are central to most compliance frameworks — almost every requirement expects a documented policy as part of the substantiating artifacts. Pulling policies onto a dedicated page lets you:

• Maintain the catalogue of published documents independently of the broader action plan.

• Track policy review and approval cycles separately from operational controls.

• Surface policies by domain when responding to audit requests or external reviews.

The Policies page in the platform is a filtered view of applied controls where the type is policy; everything you can do to an applied control, you can do to a policy.

Policies can come from either side of the divide:

• Author in CISO Assistant. Each policy can carry one or more managed documents — versioned documents tracked in-platform through a draft → in-review → validated → published → deprecated lifecycle. Useful when you want the policy text to live where the rest of the GRC programme lives, with revision history and approval workflow attached.

• Bring an existing document. If a policy already exists as a file, or lives in Confluence, SharePoint, or a DMS, its managed document can be uploaded (the file itself) or linked (a pointer to where it lives) — the same lifecycle, versioning, and links apply, without duplicating the source of truth.

Both paths are first-class — you can mix them across an organisation, or even across policies in the same domain. The applied-control machinery (assignee, status, linked requirements, evidence) is the same either way.

For policies authored in CISO Assistant, every change produces a new revision of the managed document rather than overwriting the previous text. Each revision carries:

• A monotonically increasing version number (v1, v2, …).

• A revision status (draft / in review / change requested / validated / published / deprecated).

• A timestamp, the actor who edited it, and the content at that point in time.

The full revision list is reachable from the version history sidebar on the document page — you can switch between revisions to read any past version exactly as it was published.

Two diff views help reviewers and approvers see what actually changed:

• Diff between two revisions — pick a "from" revision and a "to" revision in the history sidebar and the platform renders the textual differences between them. Useful for periodic reviews ("what changed between v3 and v6?") and for the approval workflow ("show me the delta the requester is asking me to validate").

• Edit diff (within a revision) — while a draft is being worked on, the platform also tracks the diff between the last loaded state and the current edits in the editor. This lets the author see exactly what they're about to commit before they save the increment.

The diff is computed on the document content itself — it's not a binary file diff, so it works well for the plain-text or Markdown policies typically authored in-platform. For policies attached as external files (PDF, DOCX, etc.), version history is preserved through evidence revisions, but the inline diff view is not available.

Policies have their own lifecycle — drafting, review, approval, publication, periodic review, retirement. The platform tracks these states through the standard applied-control status field and the supporting evidence on each policy entry. When authoring in-platform, the managed-document revision states (draft, in review, validated, published, deprecated) provide a finer-grained workflow on top.

A findings assessment — called Follow-up in the UI — tracks the issues raised by a review and drives their remediation through to closure. Findings can come from a CISO Assistant audit, an internal security review, a penetration test, an external assessor's report, or any other source.

It's the place where the action plan meets reality: each non-compliance, observation, or recommendation gets an assignee, a due date, and a status, and is followed all the way to "fixed".

Mental model

A findings assessment is an assessment scoped to a perimeter, in the same family as audits, risk assessments, and business impact analyses. Inside it sit individual findings, each with:

• A severity, often aligned with the assessor's severity scale.

• An assignee and a due date.

• A status from open → in progress → remediated → closed.

• One or more linked applied controls that address it.

The same findings model serves several sources:

• Audit findings — non-compliances or partial compliances raised during an audit, especially when extended results are enabled (minor / major nonconformity, observation, opportunity for improvement, good practice).

• External assessments — penetration-test reports, third-party security reviews, regulator inspections.

• Internal reviews — self-imposed checks outside the formal audit cycle.

Because the model is uniform, dashboards aggregate across sources: you can see all open findings due this quarter, across all reviews, without preselecting which kind of review they came from.

Findings link to applied controls — closing a finding usually means standing up or updating one or more controls. The link is many-to-many: a single control can close several findings, and a single finding can require several controls.

Document management lets you author, version, and publish documents — policies, procedures, charters, records, meeting minutes — directly inside CISO Assistant, so the text of your governance programme lives where the rest of your GRC data lives, with revision history and an approval workflow attached.

Documents can be authored in-platform (a Markdown editor with a draft → published lifecycle), uploaded (an existing PDF or file carried through the same lifecycle), or linked (a pointer to a document that lives in another system). Whatever the source, a document can be classified, linked to the objects it governs, and referenced by other documents.

Mental model

A document container is the language-independent identity of a document: it holds the document's type, its domain, its classification, and its links. Under it sit one managed document per language, and each managed document is a chain of document revisions — one per saved increment. A new document can be seeded from a template, classified with a level, reference other containers, and be linked to the objects it governs. Solid edges are always present; dashed edges are optional.

Every document has a Document type, used to group the reading catalogue and to scope the template picker. The built-in types are Policy, Procedure, Charter, Record, Meeting minutes, and Other.

A document's content comes from one of three sources, chosen when you create it:

• Authored — written in the in-platform Markdown editor (formatting toolbar, live preview, insert links to other documents). The published version is rendered to a PDF snapshot.

• Uploaded — an existing file (e.g. a signed PDF) attached to the document. It runs through the same lifecycle and version history, but is served as-is rather than rendered from Markdown.

• Linked — a pointer to a document that lives in another system (Confluence, SharePoint, a DMS, …). The document carries the URL through the same lifecycle; readers open it in place rather than reading content inside CISO Assistant.

All three share the same versioning, lifecycle, languages, classification, and links — they differ only in where the content lives.

Each language version moves through its own lifecycle — Draft → In review → Change requested → Validated → Published → Deprecated — and every saved change produces a new revision (v1, v2, …) rather than overwriting the previous text. The Version history sidebar lets you read any past revision and diff two of them.

The lifecycle, revision history, and diff mechanics are shared with policy documents and are described in detail under .

A single document can carry a version per language. One language is the default (used for the catalogue title and status); the others are translations. Each language version has its own lifecycle, so a French translation can still be in draft while the English original is published.

When you link one document to another from inside the editor (Link to document), CISO Assistant records the edge automatically. Each document then shows:

• References — the documents this one points to.

• Referenced by — the documents that point at this one.

These are computed from the content — there is no separate list to maintain, and they stay accurate as the text changes.

A document can be linked to one or more Policies, Applied controls, Task definitions, or Processings. The link is associative — it never changes the document's domain or publication state — and it is bi-directional: the linked object shows a Documents panel listing the documents attached to it.

This is how a policy or a control points at the document that describes it without duplicating the text. See .

A document can carry a Classification — a level from an scheme such as TLP. Once set, the level shows as a coloured badge on the reading catalogue, in the reader, and in the documents table, and it is stamped on every page of the document's exported PDF (for example TLP:AMBER). Classification is optional and independent of the document's type, domain, and lifecycle.

New authored documents can start from a document template — a reusable Markdown body, chosen in the editor's template picker. The picker only offers templates matching the document's type and language. See the .

The Documents page is a read-oriented catalogue: published documents shown as tiles, grouped by type, with search and type filters. It is the place to browse and read the published corpus, separate from the authoring workflow.

A risk assessment (also called a risk study) is a scenario-based evaluation of risk over a perimeter. CISO Assistant supports qualitative approaches (configurable risk matrices), quantitative approaches (Monte Carlo over loss distributions), and the structured EBIOS RM methodology.

The platform follows the ISO 27005 risk-management workflow.

Mental model

A risk assessment always lives inside a domain (the mandatory IAM scope) and is bound to one risk matrix that supplies the probability × impact scale (the matrix can be swapped later; existing scores are clamped to the new scale). A perimeter can optionally narrow the assessment to a specific service or process inside the domain. The assessment is composed of risk scenarios; each scenario links to the assets it impacts, the threats it materialises, and the applied controls that mitigate it (split between existing and planned to drive the three-tier risk model below).

A risk assessment encompasses three steps:

• Risk identification — defining the risk scenarios.

• Risk analysis — assessing probability, impact, and strength of knowledge for each scenario.

• Risk evaluation — done automatically based on the selected risk matrix.

In CISO Assistant, risk treatment is combined with the risk assessment rather than tracked as a separate phase.

Scenarios can be defined directly from the risk-assessment view or separately via the scenarios view. The same scenario can be reused across multiple studies.

CISO Assistant tracks three risk levels for each scenario, reflecting where the organisation stands along the treatment journey:

• Inherent risk — the natural level of the scenario without any controls in place. The starting point. Surfaced in the UI when the inherent_risk feature flag is on.

• Current risk — the level given the applied controls already in place. The state of risk today.

• Residual risk — the level expected once all planned

Each level has its own probability, impact, and overall level fields. The assessment's consistency check flags a scenario whose residual risk exceeds its current risk (on level, probability, or impact), and also flags a residual lowered below current when no applied control justifies the reduction.

Risk acceptance is when an organisation or individual decides to tolerate a certain level of risk without taking further action to reduce it. CISO Assistant provides a workflow to capture formal approval of risk acceptances by management — the approver must hold the Approver role.

For the formal definition, see .

Risk levels are calculated as a function of the probability and impact of a scenario, using a configurable risk matrix. Matrices are imported from libraries — pick one of the built-in matrices or define your own via a custom library.

Most organisations define an official matrix to be used for all risk assessments, but CISO Assistant lets you choose a different matrix per assessment when needed. The matrix can be changed after the assessment has been created. When you do, each scenario's existing probability and impact values are clamped to the new scale's bounds — a score that falls outside the new range is clipped to the nearest valid value, and unrated scenarios stay unrated. There is no proportional rescaling, so review the scenarios afterwards and correct any score that no longer reflects your intent.

A quantitative risk study evaluates risk in monetary terms — the expected annualised loss from each scenario — using probabilistic methods rather than a qualitative matrix.

It's the sibling of qualitative risk assessment and EBIOS RM: same problem (what could go wrong, how bad would it be), different lens (statistics rather than categories).

Mental model

A study is the container for one quantitative analysis. It comprises scenarios — each one a discrete risk being modelled — and each scenario comprises one or more hypotheses, typically one per risk stage (inherent / current / residual). The hypothesis carries the probability and impact distributions plus the applied controls it assumes are in place — split into existing / added / removed sets so the delta between stages is explicit. Scenarios reference the assets they impact and the vulnerabilities they exploit, mirroring the qualitative side of the platform.

Each scenario in the study is parametrised by one or more hypotheses:

• A loss-event frequency distribution — how often the bad thing happens per year, expressed as a distribution rather than a point estimate.

• A loss magnitude distribution — how much it costs when it happens, also as a distribution.

The platform runs Monte-Carlo simulation over those distributions and derives the loss exceedance curve (LEC) plus aggregate metrics: expected loss, value-at-risk, tail loss.

• You need to compare risk against budget — "should we spend €X on control Y?" becomes tractable when both sides are in euros.

• You need to talk to the board or finance about risk in the language they speak.

• You have enough data — or enough informed judgement — to bound the loss distributions.

Qualitative methods stay useful for everything else.

• — click walkthrough for running a study.

EBIOS RM (Expression des Besoins et Identification des Objectifs de Sécurité — Risk Manager) is the structured risk-management method published by the French national cybersecurity agency, ANSSI.

CISO Assistant supports EBIOS RM natively, with a dedicated object graph rather than forcing the method into a generic risk-assessment shape.

The five workshops

EBIOS RM organises a study around five workshops:

1. Scope and security baseline — define the studied system, its mission, and the regulations it must comply with.

2. Risk origins and target objectives — identify who might attack and what they want (the RO/TO couples).

3. Strategic scenarios — model attack paths through stakeholders to reach target objectives.

4. Operational scenarios — drop into technical detail: kill chains, attacker techniques, supporting assets touched.

5. Risk treatment — score residual risk and plan the action plan.

An EBIOS RM study lives in a domain (no perimeter — the study itself is the scope envelope). It unfolds through five workshops that produce, in order: feared events (undesirable outcomes on primary assets) and stakeholders in workshop 1; RO/TO couples (Risk Origin × Target Objective) in workshop 2; strategic scenarios showing high-level attack paths through stakeholders in workshop 3; and operational scenarios drilling into kill chains, operating modes, and elementary actions in workshop 4. Workshop 5 reuses the platform's standard objects — applied controls, evidence, residual risk — to treat both strategic and operational scenarios.

EBIOS RM scenarios sit alongside qualitative risk scenarios in the same risk register: both contribute to the residual-risk picture for a perimeter, and both can be treated with the same applied controls.

A vulnerability is a weakness in a system, process, or product that could be exploited to compromise confidentiality, integrity, or availability. CISO Assistant tracks vulnerabilities as first-class objects, separately from the incidents they may cause and the risk scenarios they feed into.

The vulnerability surface answers two operational questions: what's exposed and are we treating it fast enough?

Mental model

A vulnerability sits inside a domain and points outward at what it affects (assets) and what's treating it (applied controls). Threat-intel feeds enrich it asynchronously — KEV/NVD/EUVD feeds attach security advisories, NVD enrichment tags it with CWEs. The vulnerability SLA policy is a single platform-wide setting that maps severity to a deadline: when severity changes and no explicit due date has been set, the platform recomputes the due date from the policy.

• Identification — a name, an optional reference ID (typically a CVE), a description.

• Severity — the shared scale (undefined / info / low / medium / high / critical).

• Status — undefined, potential, exploitable, mitigated, fixed, not exploitable, unaffected.

Vulnerabilities are unusual in that the platform sets a due date automatically based on severity, via the . The flow:

1. A vulnerability is created (or its severity changes).

2. If no explicit due date is set, the SLA policy is applied — high severity gets a tighter deadline than medium, and so on.

3. The bulk "refresh due dates" action re-applies the policy across existing rows when the SLA configuration changes.

Explicit due dates the user (or an import) sets are preserved — the policy only fills in the blank.

Vulnerabilities don't live in isolation. CISO Assistant can pull from external feeds to enrich them automatically — see :

• KEV feed flags vulnerabilities confirmed exploited in the wild.

• EPSS feed attaches a probabilistic exploitation score.

• NVD enrichment pulls CWE mappings, affected configurations, and references.

These enrichments link a vulnerability to its security advisory and CWE entries, making severity triage less guesswork.

The status field captures where each vulnerability sits in that flow; the linked applied controls and security exceptions explain how it's being treated.

An audit is the evaluation of a perimeter against a framework. It produces a per-requirement view of status, score, evidence, and the applied controls that substantiate each requirement.

Because applied controls are decoupled from compliance requirements, a single set of controls can be evaluated against many frameworks in parallel without re-doing the work.

An audit always lives inside a domain (the mandatory IAM scope) and is assessed against one framework. A perimeter can optionally narrow the audit further — e.g. to a specific service or process inside the domain. On creation the platform spawns one requirement assessment per requirement in the framework — those rows are where status, score, and the supporting applied controls and evidences live.

A validation flow (labelled Validations in the sidebar) is the platform's structured sign-off workflow. It takes one or more objects — an audit, a risk assessment, a policy, a security exception, a contract, an accreditation — bundles them into a single request, and routes that request to a designated approver for a formal decision. The decision and its context are preserved as an audit trail.

It's the answer to "who approved this, when, and on what evidence?" — the question that comes up in every certification audit, every internal review, and every regulator visit.

Mental model

A requester submits a validation flow for one or more objects in their domain. The flow carries optional request notes, a validation deadline, and is routed to a designated approver. The approver moves the flow through a status machine ending in one of: Accepted, Rejected, Change requested, Revoked, Expired, or Dropped. The original objects remain unchanged — what's recorded is the validation flow itself, with the link back to whatever was up for approval.

There are two ways to start a flow, and they cover slightly different objects:

• From the Validations list — click +, then expand the More section to attach objects. The picker offers Audits, Risk assessments, Business impact analyses, Findings assessments (follow-ups), Security exceptions, Processings (privacy), Accreditations, and Contracts (third-party). You can mix several types in one flow when they belong to the same approval decision (e.g. "approve this audit and the related exceptions").

• From an object's own page — objects that carry a validation section let you submit the open object directly. This is the only way to route a Policy through a flow, and it's also available on audits, risk assessments, BIAs, follow-ups, exceptions, processings, accreditations, and contracts.

So the full set of objects that can go through a validation flow is: audits, risk assessments, business impact analyses, follow-ups, policies, security exceptions, processings, accreditations, and contracts.

The flow moves through a small state machine:

The status is the audit-trail field that gets cited in evidence reports — "policy v3 was Accepted by Jane Doe on 2026-03-12" is what makes the decision provable later.

Most ownership/assignment fields across the platform hold an actor (which can resolve to a user, a team, or an entity). The validation-flow approver is the deliberate exception: it's a foreign key to a User directly. Approval is a personal accountability act — "a named individual signed off" — and a team can't approve in the same way it can co-own work.

When the page surfaces validation flows, it wraps the user-only approver field so the team-broadening toggle still works: switching to "include team assignments" adds every team member's user ID into the approver filter, giving you a per-team queue without changing the underlying "one named user approves" semantics.

Each validation flow carries an optional, unique reference ID — useful when you need to cite the approval in external systems (a change-management ticket, a regulator submission, an internal governance record). The platform enforces uniqueness across the instance.

The pattern fits anywhere a decision needs formal, traceable sign-off:

• A policy moving from validated to published — the approver records that the document is fit for release.

• A security exception being granted — naming the risk-owner who accepted the residual risk.

• An audit's results being signed off before publication to stakeholders.

It is not the right tool for casual review or peer feedback — for those, use comments, the requirement-assessment review status, or a . Validation flows are explicitly heavy: they exist so that the approval is preserved as evidence.

• — typical objects routed through validation flows for publication

• — lighter-weight review/remediation tracking

• — formal risk acceptance is one of the most common reasons a validation flow is submitted

This tutorial guides you through managing minor nonconformities and major audit results within your audits

Go to your instance

1. Introduction

You will learn how to add extra attribute to your audit through extended result.

2. Open your audit

Click "ISO 27002 SOA" to access the relevant audit for managing audit results.

3. Enter Edit Mode

Click "Edit" to enable modifications on the selected audit.

4. Access More Options

Click "More" to reveal additional settings and options for the assessment.

5. Enable extended result

Click "on" to activate the desired feature or option within the assessment settings.

Click "Save" to apply and store the changes made to the audit.

Click "4.1 - Understanding the organization and its context" to examine specific requirements.

Select the appropriate category such as major nonconformity, minor nonconformity, observation, opportunity for improvement, or good practice.

Click the note stating "Major and minor nonconformities are only applicable when result is non-compliant or partially compliant." to understand criteria.

Click "Save" to store the additional nonconformity or observation details.

Click "Save" to finalize and save the observation or nonconformity information entered.

You have successfully managed minor nonconformities and major audit results by editing, documenting, and saving relevant audit details. This ensures accurate tracking and supports effective audit management for your organization.