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

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.

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 one assessment exercise across many targets at once: an internal campaign targets your perimeters, a third-party campaign targets your third parties. 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.

• Commitment — The delivery date an owner has actually promised for a piece of remediation work, and the record of the negotiation that produced it. Distinct from an ETA, which anyone can type in.

• 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.

• Data recipient — A party (internal team, external service, public body) that personal data is disclosed to as part of a processing.

• 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.

• Entity assessment — The actual review of an entity. Can trigger or be linked to an audit.

• 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.

• Finding — A single issue to be remediated — a non-compliance, an observation, a vulnerability found in a pentest. Usually collected in a findings binder, but can stand alone.

• Findings binder — A formal record collecting the issues raised by one review — an audit, a security review, a pentest, an external assessor's report — and driving them through to closure. Internally

• 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.

• Metric instance

• 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.

• Organisational objective — A documented strategic or operational goal of 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.

• Rating — A quick form outcome rule that classifies the answers to its scales into named levels, through a grid or rules: a DPIA's privacy risk crosses severity and likelihood. See .

• 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.

• Scenario selection — The risk scenarios kept by the Selection bar of a risk assessment. The scenario table, the matrices, the action plan and the exports all work on that subset. See .

• 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 requirement, control or risk treatment, with owners and an expiration date. See .

• 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 — A scheduled instance of a task definition, with a due date, a status (pending → in progress → completed/cancelled), and the evidence collected when the task ran. Internally a TaskNode.

• 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.

• Workflow — A small automation drawn on a canvas: a trigger, steps and wires. Runs inside CISO Assistant with the permissions of the user who published it, and only inside its domain. See .

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 Community vs PRO page on the intuitem website — 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.

Contributor seats

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.

• — the auditee surface used by external representatives, who also don't consume a seat.

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.

• Configuration — organisation setup, IAM, SSO, and customisation.

• — recorded demos and walkthroughs.

• — subscription tiers and what's included.

• — feature-by-feature comparison.

• — partner programme for integrators and resellers.

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 Excel format and authoring workflow.

Libraries are versioned. When you update a library from the Catalog, its new content is applied to all linked objects in the instance, including existing audits. Inspect the updated content before applying it. See and .

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.

Mental model

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 framework is a tree of requirement nodes. Most nodes are assessable — concrete requirements you evaluate one by one — while others act as section or chapter headings that organise the tree. Each assessable node becomes a inside an audit, carrying its own status, score, and evidence.

Frameworks can define a default scoring scale with a minimum score, a maximum score, and optional level descriptions. For example, a CMMI-style framework may use 0..5, while another framework may use 1..4 or 0..100.

An individual requirement node can override that default scale with its own min_score, max_score, and scores_definition_ref. These overrides are useful when a standard mixes different scoring shapes in the same tree: for example, a mostly maturity-based framework that also contains binary pass/fail requirements.

The override is resolved independently for each field:

• If a requirement defines min_score, that value is used; otherwise the audit-level minimum is used.

• If a requirement defines max_score, that value is used; otherwise the audit-level maximum is used.

• If a requirement defines scores_definition_ref, those labels (resolved from the framework's alternatives registry) are used; otherwise the audit-level labels are used when they fit the requirement's effective range.

Per-requirement label overrides go through a named alternatives registry declared on the framework alongside its default scale. Each requirement references an entry by name, keeping shared scales DRY and avoiding duplication on the node:

One-off scales that only apply to a single requirement are added as a new entry in the framework's alternatives registry and referenced by name, just like shared scales. The node always carries a reference, never inlined labels.

The audit copies the framework's scores_definition (default scale + alternatives) at creation, so per-requirement references resolve against the audit's own copy. This keeps the audit self-contained: customising the audit's scale later doesn't break references on its requirements.

Roll-ups keep mixed scales comparable. Average-based aggregation normalises each requirement score against its effective range before computing the parent or global score, then displays the result on the audit scale. Sum-based aggregation remains a raw weighted sum, so each requirement contributes its own effective maximum.

CISO Assistant ships with 100+ built-in frameworks covering most international standards and regulations. When none of them fits your needs, you can build your own — see or follow the .

A mapping (or crosswalk) is a directed graph linking the requirements of one framework to those of another, using the convention. Once a mapping is loaded, an existing audit can be projected onto the target framework — reusing requirement assessments where the mapping is strong, surfacing gaps where it isn't.

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 Understanding the IAM model; 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.

3. Some permissions are granted by a domain default role.

The combination of these three is what produces the most common "why am I seeing items from another domain here?" moment, which the last two sections explain and resolve.

The platform's primary scoping unit is the domain (see ). Almost every operational object you create carries a domain — that's what drives who can see it and how it rolls up in reports.

The list is long on purpose — to make the model concrete:

• Compliance: audits / compliance assessments, requirement assessments, evidences.

• Risk: risk assessments, risk scenarios, quantitative risk studies, EBIOS RM studies, business impact analyses, security exceptions.

• Operations: applied controls, policies, tasks, incidents, findings, findings binders, commitments.

• Assets: assets, contracts, entities, solutions, representatives.

A small number of objects don't carry a domain because they're either system-wide (the user catalogue, the role catalogue, instance settings) or imported from a library catalogue. Everything else lives inside a domain.

The domain hierarchy is not just for organising the UI — it actively shapes access. A role granted on a domain applies to every domain beneath it. Give a user the Analyst role on a parent domain, and they get analyst-level access to every sub-domain underneath, without re-assigning them at each level.

This is why the tree shape matters as much as the names: putting "France" and "Germany" under a "EMEA" parent isn't decorative — it's the lever that lets EMEA-level managers see across both without granting them individual roles per country.

Permissions only flow downward: a role on a sub-domain does not grant any access to the parent. If you need a role-holder to see across siblings, the role goes on the shared ancestor.

A third-party workspace — the folder holding a vendor's questionnaire, an enclave internally — is the one place where the tree deliberately stops conducting. Access granted there does not reach up: a representative with view rights on their workspace sees their questionnaire and nothing the domains above it share. That containment is what makes it safe to give an external party an account on your instance at all.

Each third party gets one workspace per domain. See .

The same inheritance also drives reporting: most dashboards and analytics roll up across a domain and its descendants, so a leadership-level view on the parent domain is automatically the consolidated view across its sub-tree.

Every domain has members: the people its own and its sub-domains' IAM groups grant roles to. A domain can carry a default role — and the default role is what the domain grants its members, on the domain itself (and only there: the grant is never recursive).

For example: if the EMEA domain has the Baseline reader default role, then a user granted any role on EMEA or EMEA/France through the IAM groups is a member of EMEA, and can view EMEA's catalog objects. The grant never extends downward: EMEA's default role gives nothing on EMEA/France — what members see there comes from their own roles.

By default, the global domain (the root) carries the Baseline reader default role, which grants view access to catalog objects. Everyone in the organization is a member under the root, so everyone can read the root-level catalog.

Some objects exist to be shared. Frameworks, threats, risk matrices, reference controls, and other catalogue-style items wouldn't be useful if they were trapped in a single domain — every team needs to be able to pull from the same shared library. That's why catalog objects (usually stored in the root domain) are viewable by everyone in the organization.

Who is not a member, and why: third parties hold their grants inside third-party workspaces, which are not the domain's groups; service accounts hold direct assignments — no group grants them anything, so they read exactly what their own assignment names. Neither ever receives anything from a default role.

The default role is a dial, not a law. In the enterprise edition, each domain's default role can be tuned: replaced by a narrower view-only role (a custom role listing exactly the object types this domain shares), or removed entirely — a domain with no default role shares nothing ambiently, and its members see exactly what their own roles grant. Removing the root domain's default role goes all the way: the instance then runs an explicit-grant policy, where nothing is ambient — even the catalog is visible only to those whose roles name it. It's one field on the domain, so tightening takes effect immediately and is just as easy to revert.

Configuring default roles is an enterprise capability. In the community edition, the default role exists only on the root domain, fixed to Baseline reader — it cannot be changed, and no other domain carries one.

Assessments routinely compose objects across the tree. Risk assessments reference applied controls, threats, and assets; audits reference applied controls and evidences; findings binders reference applied controls and the requirement assessments they remediate.

When you're working inside one assessment, the platform's selectors and pickers don't just show you what's in the assessment's own domain — they show you everything you have access to. So a risk scenario authored inside the France domain can pull in:

• A shared applied control attached to the EMEA parent domain (you can see it because of inheritance).

• A threat from the global library (you can see it because the root domain usually has a "baseline reader" default role).

• An asset attached to a sibling Germany domain (if your role gives you access there).

This is by design — composing across the organisation is the whole point of a centralised GRC platform — but it can be disorienting on day one. The rule is consistent: you see what you have access to, regardless of which domain you started on.

When you have access to many domains and you only want to think about one at a time, the platform exposes (PRO, default off). Focus mode scopes the entire application — every list, dashboard, count, and search — to a single domain and its sub-tree, hiding everything else for the rest of your session.

It does not grant or revoke permissions; it just filters the view. Use it when:

• You operate across many client domains and want to work on one at a time.

• Your organisation is large enough that the "all domains" view is overwhelming for day-to-day work.

• You're running a demo or an onboarding and want the rest of the workspace out of the way.

When focus is engaged, all the cross-domain composition described above is suppressed — you'll only see assets, controls, and assessments from the focused sub-tree. Clearing the focus restores the full cross-domain view.

• — domain hierarchy, IAM groups, restructuring, moving objects.

• — who gets assigned what.

• — full configuration-side deep dive (SSO, MFA, PATs, accounting).

• — the PRO tool for scoping back the view.

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.

• An optional team email — used as the default notification address; if not set, emails fan out to the leader, deputies, and members individually.

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.

• Risk scenarios are assigned to one or more actors.

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

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.

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.

• Aliases — cross-references to other identifiers when an advisory exists under multiple IDs.

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.

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.

• Superset — the SRC requirement contains (is broader 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, see for the Excel workflow using prepare_mapping_v2.py.

• — the UI flow for applying a mapping

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 — the lookup from each (probability × impact)

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 for the workbook fields and an example.

Expected outcome

• create your metrics in one form, from a library definition or from scratch

• record their values for each period, or compute them from other metrics

• create dashboards with builtin and custom metrics

Mental model

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: owner, target value, collection frequency (auto-stale logic kicks in when the latest sample exceeds the cadence + grace period). Samples are the values recorded against an instance; a metric with a collection frequency records one value per period (month, quarter, week…), and a new value for a period replaces the previous one. The definition also holds how a value reads: its direction (higher is better, lower is better, or none) and the decimals it is shown with. You rarely create a definition by hand: the creates it with the metric. 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

• Collection frequency: expected collection frequency, on which we add a grace period before toggling the metric to stale status

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.

A computed metric is an instance whose samples come from a formula rather than from people or integrations: a training coverage from the employees trained and the headcount, a click rate from the clicks and the people tested, a status level from a threshold on either. Nobody types its numbers in; the application computes them on the instance's collection frequency, and on demand with Refresh now.

• Start from the metrics you track. Pick metric instances, write a formula, name the result: the application creates the instance and its definition. See , or follow .

• The formula runs once per period. The instance's collection frequency cuts time into calendar periods, and each input contributes its latest sample in the period. The series is complete from the start and follows corrections to its inputs. See the .

• The result is a number or a level. A level metric returns one of an ordered list of texts, such as On track and Behind.

All of it is described in .

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.

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.

How it ties into the rest of the platform

• 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 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 — 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.

Adversary techniques — how an attacker acts, as catalogued by MITRE ATT&CK and ATLAS — are a separate catalogue. See .

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.

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.

• Translations — see below.

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

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 in progress, done, or skipped as you advance, and add notes.

• 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 .

A TTP catalog is a reference matrix of adversary behaviour: the tactics an attacker pursues (the why of a step, such as Initial Access or Exfiltration) and the techniques used to achieve them (the how, such as Phishing or Data Obfuscation). CISO Assistant ships MITRE ATT&CK and MITRE ATLAS as TTP catalogs.

A threat model is an attack sequence you build on top of one catalog. You pick the techniques that apply to your system, lay them out tactic by tactic, chain them into a graph, and link the result to the risk scenarios it justifies.

Techniques and threats

A threat and a technique answer different questions:

• A threat is what could happen: a source of harm such as "Ransomware" or "Loss of power". It's what a risk scenario materialises.

• A technique is how an adversary does it: a concrete, observed behaviour such as "Phishing" or "Exfiltration Over Web Service", catalogued with its tactics, platforms and mitigations.

Both can sit on the same EBIOS RM operational scenario: threats name the harm, techniques describe the attacker's operating mode.

A TTP catalog organises tactics in their published order. Each technique sits in one or more tactics; a sub-technique also points to its parent technique. A technique can list the reference controls (the catalog's mitigations) that address it. A threat model always draws on exactly one catalog, chosen at creation and locked afterwards; it optionally sequences that catalog's techniques into a graph, and optionally justifies one or more risk scenarios or quantitative risk scenarios. Separately, an EBIOS RM operational scenario can directly reference the techniques it uses, without going through a threat model.

Two control this area. Both are off by default.

• TTP catalogs (ttps) — shows TTP catalogs under Catalog in the sidebar, technique pages, and the Techniques field on operational scenarios.

• Threat modeling (threat_modeling) — shows Threat modeling under Risk in the sidebar and the Threat model field on risk scenarios and quantitative risk scenarios.

Threat models are built on a TTP catalog, so turn on both flags to use them.

TTP catalogs come from . Load one or more from the Libraries page:

Each library brings the catalog, its tactics, its techniques, and the mitigations as reference controls already linked to the techniques they address. When a newer version of a library drops a technique, the technique is marked deprecated rather than deleted, so existing links keep working; deprecated techniques are hidden from the matrix and from pickers.

Open TTP catalogs and pick a catalog to see it as a matrix: one column per tactic, in the publisher's order, with each technique listed under every tactic it belongs to. Techniques that have sub-techniques show a counter that expands them in place. Clicking a technique opens its detail page: description, tactics, parent technique, mitigations, and the groups (platforms, assets) it applies to.

Above the matrix, a search box filters by reference ID or name, and the catalog's filter chips, grouped by dimension (platform, asset, maturity), narrow the matrix further. Chips in the same dimension combine with OR; different dimensions combine with AND. A parent technique stays visible when only one of its sub-techniques matches. Clear filters resets everything.

With TTP catalogs enabled, the operational scenario form in workshop 4 gains a Techniques field next to Threats: "Adversary techniques (MITRE ATT&CK and other TTP catalogs) used in this operational scenario". The selected techniques are listed on the operational scenario page (or No technique when none is set) and in the EBIOS RM study report, each linking to its technique page.

Open Threat modeling in the sidebar and click Add threat model. Give it a name, choose its domain, and pick its TTP catalog. The catalog can't be changed later: "The catalog cannot be changed after creation."

The threat model page shows the usual details plus a read-only preview of the graph, with two actions: Select techniques and Edit graph. Both views share a Selection / Graph switch so you can move between them.

The Selection view is the catalog matrix in selection mode. Click the techniques that apply to highlight them, then Save; the header shows how many are selected. A selection is per cell: the same technique selected under two tactics is two separate steps, because a tactic changes what the technique means in the sequence.

The Graph view is an editor laid out in one lane per tactic, left to right in the catalog's order.

• Add techniques — drag them from the palette into a lane. A technique only drops into the lanes of tactics it belongs to.

• Connect steps — draw an edge from one node to another. Loops and backward edges are allowed, only self-loops and duplicates are refused.

• AND / OR — when a node gets a second incoming edge, an operator node is inserted in front of it, set to OR. Use Toggle AND / OR to switch it: "AND requires every incoming step; OR accepts any of them."

• Add a step — adds a custom node for a step the catalog doesn't cover.

Select a node to edit its context in the side panel: a Label, a Description, a Key step flag to highlight it, and links to the Assets it targets, the Applied controls that counter it, and the Vulnerabilities it exploits. Changes are kept locally until you click Save; Discard drops them.

With Threat modeling enabled, the risk scenario edit page has a Threat model field ("The attack sequence that justifies this scenario") and a button to create a new threat model on the spot. The risk scenario page then lists the linked threat model with a direct link to its graph. Quantitative risk scenarios have the same Threat model field.

Analysts and domain managers can create, edit and delete threat models in their domains; readers and approvers can view them. TTP catalogs, tactics and techniques are catalog objects: readable by every built-in role except third-party respondents, and loaded or updated through libraries.

A commitment is the delivery date someone promises for a piece of remediation work — and the record of how that promise was arrived at, and what happened to it.

Every GRC tool has a due date field. What it doesn't have is the difference between a date the analyst typed in and a date the owner agreed to. Commitments make that difference explicit, and keep the history of the negotiation instead of overwriting it.

Commitments are gated by the commitment_management feature flag, off by default.

Mental model

A commitment hangs off the object it is about — an applied control or a one-off task definition — and adds no fields to it. Each round of negotiation is one commitment row, so a renegotiated date does not erase the one it replaced. Two roles are in play: the owner, who is accountable for the object and therefore makes the promise, and the counterparty, who is anyone who isn't.

The steps between them, and who may take each one:

Two rules carry the intent of the model:

The owner cannot close their own commitment. Someone who both makes and confirms delivery of a promise is self-certifying. Fulfilment is a counterparty step, deliberately.

A third-party respondent is always the promising side. They can commit and decline; they can't sign off their own delivery.

When nothing is accountable for the object — no owner set — there are no sides, and anyone who can change the object can run the whole lifecycle. That's a deliberate escape hatch so an unassigned control doesn't deadlock.

Renegotiating doesn't overwrite the promised date. The current cycle is closed and a new one opens, carrying the previous committed date forward so a breach stays visible across the renegotiation. The panel shows Reopened n times and lists the closed cycles with the date each promised, who promised it, when, and the note that closed it.

This is the point of the whole feature: "the fix slipped three times and each time we heard about it after the date had passed" is a sentence a report can now support.

Neither is stored — both are read from the object every time it's displayed:

• Slipped — the object's own ETA is now later than the date that was promised. The work has moved; the promise hasn't been renegotiated.

• Breached — the promised date has passed and the commitment isn't fulfilled.

• On an applied control or a one-off task definition, as a Commitment panel with the available steps and the history.

• On the Commitments page under Governance — every promised date across controls and tasks in one table, filterable by state, domain, and who committed. Reading it needs the view commitment permission; taking a step needs Can take a commitment step.

Recurring task definitions have no commitment panel at all: a recurring definition is a template, not a single promise. Making a task recurrent while a commitment is still live is refused — resolve the commitment first.

The two look adjacent and aren't. A is a reviewer approving an object as it stands. A commitment is an owner promising a future date. One is a verdict on the present, the other a promise about the future, and an object can be subject to both.

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.

• Action plan — the Kanban view and the Control Plan grid both swimlane by status. A control sitting in

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.

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.

Mental model

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), rendered in words wherever it's displayed — Monthly, Every 3 months — rather than as the raw rule. 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.

Tasks come in two layers, mirroring the template → instance pattern used elsewhere in the platform:

• A task definition is the reusable spec — the title, description, assignee, expected evidence, and the recurrence rule (every Monday, the 1st of each month, every 90 days). It says what should happen and how often. Internally a TaskTemplate.

• A task occurrence is a single scheduled run produced from a definition — the actual row with a due date, a status (pending → in progress → completed / cancelled), and the evidence collected when the work was done. Internally a TaskNode.

A one-off task is just a definition that produces a single occurrence.

With enabled, a one-off definition can also carry a commitment — the delivery date its assignee has actually promised, tracked separately from the task date. Recurring definitions cannot: a recurring definition is a template, not a single promise.

1. Define. Create a task definition with the assignee, the cadence, and what's expected when the task runs.

2. Schedule. Occurrences are materialised from the recurrence rule. The platform creates them as their due dates come into view, so the list of upcoming work is always visible.

3. Work the occurrence. When a due date arrives, the assignee opens the occurrence, records what they did, attaches evidence, and marks it completed.

4. Iterate. Edit the definition to adjust the cadence, assignee, or expected evidence — existing occurrences keep their state; future occurrences pick up the change.

The point of tracking tasks inside the platform — rather than in a calendar or ticketing system — is so that the evidence of execution lives next to the rest of your compliance record. An auditor asking "show me proof of monthly backup testing" can be answered by pointing at the task and walking through the completed occurrences with their attached evidence.

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 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.

• Scope — the affected assets, the threats believed to be in play, the entities (third parties) involved.

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.

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 quick form is a short, standalone questionnaire that someone fills in without an audit behind it: a derogation request, a vendor review request, a pre-qualification, an intake form. A request is one filled copy of that form, submitted to someone who decides on it.

It answers "how does someone outside the security team ask us for something, and how do we decide and keep the record?" — the question that otherwise gets answered by email, a spreadsheet, or a ticketing tool that knows nothing about your controls.

The distinction from an audit matters. An audit measures an organisation against a framework, and every question hangs off a requirement. A quick form has no requirements, no assessable nodes and no compliance result — it has pages, questions, and an outcome.

Mental model

A quick form arrives from a library, like a framework or a risk matrix does. On its own it cannot be filled — it must first be published, which is what names the audience allowed to file it and the domain their requests land in. A publication is then surfaced to people through a portal tile, which is where they click to start. Someone in that audience files a request, answers it, and submits. The answers compute a score and fire outcomes, which classify the request. A reviewer decides. An accepted request can then produce a real governed object, with the link back to the request that caused it.

A form about an object, such as a vendor tiering form, takes a shorter route: it is started from that object, with no publication or portal, and when the form has an On accept setting, an accepted request writes its result back onto it.

Three places in the sidebar, and they are deliberately different audiences:

My requests is the only route back to an unfinished draft, and it is scoped by who you are rather than by domain permissions — a requester holds no role on the domain their request lands in.

A quick form sitting in the catalog cannot be filled by anyone. Publishing it is a separate, deliberate step, because the form says what is asked and the publication says who may ask and where it lands:

The same form can be published more than once — to different audiences, landing in different domains, with different reviewers. That is how one derogation form serves several business units without being copied.

Publishing is necessary but not sufficient: a publication becomes reachable when a portal tile points at it. My requests lists the portals you can ask from, not the publications themselves.

Audience membership is the authorisation here. It is not folder permissions: someone in the audience can file a request into a domain they otherwise cannot see, and they will still not see anything else in it.

A closed request carries a Resolution: Accepted, Rejected, Dropped (the requester withdrew it), or Closed automatically. Reject is the reviewer's act and drop is the requester's; neither substitutes for the other.

A reviewer can also send a request back to Draft, which returns it to the requester to change and resubmit.

Whoever submitted a request may not decide it, whatever permissions they hold. An analyst who files a derogation cannot approve their own derogation.

Two things follow:

• Deciding needs a specific permission, not merely write access to the domain. A reviewer who can edit everything in a domain still cannot decide a request they filed.

• Organisations too small to separate the two can turn on self-validation in the settings, which lifts the restriction deliberately rather than by accident.

The rule is anchored on who submitted the request, not who created the record — cloning and reassignment move authorship, and the check follows it.

Scores and outcomes are what separate a quick form from a web form that emails someone.

Each question can carry a score, and each form can carry outcome rules — expressions over the answers that classify the request when it is evaluated. All matching rules fire; a request can carry several outcomes at once.

Two ways to write a rule, both useful:

• On a specific answer — "personal data was ticked", "no compensating control is in place". Precise, and reads like the question it depends on.

• On a score — "anything above 100 needs a full assessment". One threshold to tune, instead of an enumeration that grows each time a choice is added. The score can be the form's, or a page's when each page measures something different (business impact on one, data exposure on another).

A rule can also compute a number instead of firing: an average, the higher of two page scores, a formula such as the EBIOS RM threat level. The value shows on the request, and later rules read it. That is how a form turns answers into one figure a decision can rest on.

Outcomes are what the rest of the platform reacts to. They drive which supervised actions a reviewer is offered, and they are the hook for turning an accepted request into a governed object or a change to an existing one.

Some forms rate the same thing several times: a DPIA rates the severity and the likelihood of each of its three risks. A scale names those ordered levels once, for example Negligible, Limited, Significant, Maximum, each with an optional description and number. A choice question on a scale gets the scale's levels as its choices, so every question measuring severity uses the same ones.

A rating is the third kind of outcome rule, next to Yes / no and Number. It classifies the answers to its scales, its dimensions, into named levels of its own:

• With two dimensions, a grid crosses them: one cell per pair of levels, like a risk matrix.

• With any number of dimensions, rules do: the first rule that holds gives the level, for example dims.severity.value * dims.likelihood.value >= 8.0.

Each page that answers every dimension is a point, rated on its own: a DPIA rates each of its risk pages. A question can also belong to a second stage, such as residual for the level once planned measures are in place, which gives a second point on the same page. Other rules read the highest level among the current points as values.RATING_ID, and the residual one as values.RATING_ID_residual.

In the library builder, scales are edited under Scales, and a question uses one by picking it in Choices. A rating is created by choosing Rating as an outcome rule's Result. It starts from the form's first two scales, which the builder adds when the form has fewer, and a grid of three levels, Low, Medium and High, to repaint. A dimension no question measures yet is flagged.

Some forms are about an object: a vendor tiering form is about a vendor, a DPIA about a processing. The form names that object in a subject question, and the request is then linked to it.

Such a form can say what an accepted request writes onto its subject, in its On accept setting:

A page of such a form can also show what the subject already records, read-only: a DPIA's data page shows the processing's personal data, data subjects and recipients. While the request is a draft, these reflect the object as it is; once submitted, as it stood then. The form then asks about what the record does not hold, instead of copying it.

Three things follow:

• It starts from the object. Assess tier on a vendor, or Run DPIA screening and Start DPIA on a processing, opens a request with the object filled in and locked. No publication or portal is needed.

• The reviewer sees the write before deciding. The request shows On accept, this will write and the value. The reviewer can override it, with a justification. If the vendor's tier came from another form, the request warns that accepting replaces it.

• No review when there is nothing to grant. When the submitter could make the change themselves and every scored question is answered, submitting applies the result at once and closes the request as accepted. A publication can require a review anyway, with Always require review.

When the result cannot be written — no subject, a tier missing from the scale, a permission missing, an object the form no longer applies to — nothing is written and the request goes to review with the reason.

and walk through the whole loop.

A ticketing tool stops at "approved". The point of filing a derogation request here is that an accepted one can become a security exception — a governed object with an expiry, an approver and a place in the register.

That conversion is done by a supervised action: a workflow the reviewer runs deliberately on a request they have read, rather than something that fires on its own. The outcomes decide which actions are offered; the reviewer chooses whether to run one.

Whatever is produced keeps a link back to the request that caused it, visible from both ends — the request shows what it produced, and the produced object shows where it came from.

Questions can ask for a file. Uploads are held on the answer, and a reviewer who wants to keep one can promote it to an evidence in the domain — so a document that mattered to a decision stops being an attachment on a request and becomes part of the record.

Quick forms are library content. There are two ways to get one:

• Import a library that contains one, from Libraries — the same route as a framework or a risk matrix.

• Build your own in the library builder: New quick form creates the draft and opens the editor. Pages, questions, choices, scores, conditions and outcome rules are all edited there, and the result is a library you can export and re-import elsewhere.

Because a form is library content, it is versioned like one. Re-importing a newer version updates the form in place — except for questions already answered by a request that has left draft. Those are kept deliberately: deleting them would rewrite the record a decision was made on.

Workflows automate what happens in CISO Assistant. A workflow reacts to something (a schedule, an object changing, an external system calling in, or you pressing a button), then runs a series of steps: read objects, create or update them, branch on a value, loop over a list, send an email, call an external system.

You build workflows visually, on a canvas. No code is involved, and everything a workflow does is bounded by the permissions of the person who published it.

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.