Organization module

The Organization module is where BCMLogic Next starts. Everything else builds on it.

Organizational structure

Model your actual legal and operational structure. Not a simplified version of it.

BCMLogic Next supports multi-entity organizations natively – holding companies, subsidiaries, branches, shared service centers, and cross-border structures. The organizational tree is not cosmetic. It is the axis along which risk, processes, assets, and dependencies are assigned, aggregated, and reported.

What it covers:

  • Multi-entity hierarchy: parent company, subsidiaries, branches, joint ventures – modeled as a live organizational tree
  • Role and ownership assignment at entity level: each process, asset, and vendor relationship is owned by a specific part of the structure
  • Cross-entity dependency mapping: shared IT services, centralized functions, inter-company agreements that create resilience dependencies

Process register

The process register in BCMLogic Next is the operational backbone of your BIA, risk assessment, and continuity planning. Every critical function identified under ISO 22301 or DORA Art. 11 is anchored to a process. Every process has an owner, a criticality classification, RTO and MTPD thresholds, and a dependency chain linking it to the assets and vendors that support it.

What it covers:

  • Structured process catalogue: business processes organized by entity, department, and criticality tier
  • BIA integration: RTO, RPO, MTPD, and minimum resource requirements defined at process level and fed directly into continuity plans
  • Dependency linking: each process connected to the ICT assets, services, and vendors it depends on – the data that feeds what-if analysis and the DORA Register of Information
  • Process ownership and review cadence: assigned owner, last review date, next review date – auditable
  • Criticality classification aligned with DORA Art. 11 (critical or important functions) and NIS2 Art. 21 essential service mapping

What-If Impact Analysis

  • "If this fails, what stops working?" - answered with data, not guesswork.

    What-If Impact Analysis is the analytical engine that sits on top of the organizational structure, process register, and asset register. It takes a failure scenario - an asset going down, a vendor becoming unavailable, an ICT service degrading - and traces its impact upward through the dependency chain to the critical functions that are affected.

    How it works:

    Select the affected element - an asset, vendor, ICT service, or process. Define the event type and degradation level, from partial impairment to full loss. The platform propagates the impact upward through the dependency graph and shows which critical functions are affected, by how much, and whether RTO or MTPD thresholds are breached.

    What the analysis produces:

    • Hierarchical impact list: the full path from the failed element to each affected critical function, color-coded by severity - green (minor), amber (RTO at risk), red (MTPD breached)
    • Dependency graph view: the same result visualized as a network - affected elements highlighted, unaffected nodes dimmed
    • MTPD breach counter: the single most important number - how many critical functions are in genuine jeopardy in this scenario
    • Exportable scenario report: structured output for tabletop exercise documentation, management review, or regulator presentation

    How impact propagates:

    Not every dependency transfers failure equally. BCMLogic Next models three dependency types: hard (no alternative - full impact transfer), degraded (partial transfer, approximately 50%), and redundant (alternative exists - minimal transfer, approximately 20%). If a process depends on multiple affected elements, the worst-case propagation applies - a deliberate conservative assumption. By default, unclassified dependencies are treated as hard. In risk analysis, overestimating impact is safer than missing it.

    Typical use cases:

    • Tabletop exercises under ISO 22301 - run a failure scenario without triggering a real incident
    • DORA Art. 29 concentration risk assessment - how many critical functions depend on a single ICT provider
    • Investment justification for redundancy - does a backup element actually protect the critical function, or does the dependency type mean it does not
    • Management review preparation - a specific number of functions at risk, not a generic "high risk" assessment