The Integrated BCM/BIA Data ModelFrom Distributed Data to Measurable Resilience

Business Continuity Management is often conducted using documents, spreadsheets, and individual interviews. However, the crucial data already exists – just distributed: Products and contribution margins in the ERP, assets in the EAM, IT services in the CMDB, roles in the HR system, contracts in procurement and legal, building information in facility management, and recovery values in tests or incident logs. An integrated BCM/BIA data model connects this information to form a reliable basis for decision-making.

The benefit does not come from having the largest possible database. It arises from the right relationships: Which product depends on which process? Which activity requires which people, buildings, IT services, OT assets, and suppliers? What recovery time is required, what is actually achieved – and what economic, legal, or societal impacts grow during a disruption?

This article develops an organisation-specific approach that integrates BCMBCM – Business Continuity Management
Management process for preparing for disruptions and for continuing and recovering prioritised services., BIABIA – Business Impact Analysis
Analysis of the time-dependent impacts of disruptions as a basis for priorities and recovery requirements., risk management, and performance measurement into a common data logic. It is explicitly not a universal ready-made model. Organisations differ in value creation, regulation, technology, terminology, and management logic. Ignoring these specifics reduces the very benefit that integration is supposed to create.

The core idea: The BIA evolves from a periodically completed questionnaire to a professionally responsible evaluation of a living relationship model. Automation provides facts and inconsistencies; the assessment of the maximum tolerable disruption remains a management decision.

Why an isolated BIA falls short

The Business Impact Analysis assesses the consequences of disruptions over time. It establishes priorities and recovery requirements. ISO/TS 22317:2021 describes as results, among other things, the prioritisation of products and services, the assessment of time-dependent impacts, the determination of the MTPDMTPD – Maximum Tolerable Period of Disruption
Period after which the impacts of a disruption exceed the tolerated level., the definition of RTORTO – Recovery Time Objective
Target time for resuming a prioritised activity or resource after a disruption. and, if applicable, RPORPO – Recovery Point Objective
Business-tolerable data loss, expressed as a point in the past to which data must be restored. as well as the identification of resources and dependencies.^[1]

In practice, these elements are often maintained separately. The business names a process and an RTO. IT maintains technical services and components. Procurement knows supply contracts and service levels. Human Resources knows positions, roles, and qualifications. Facility Management knows locations, spaces, and utilities. These views are each correct but incomplete on their own.

The consequences of separation are well-known:

• Recovery targets are assigned to applications without clearly knowing the supported business service.
• A „second supplier“ is considered redundancy, even though it uses the same sub-supply chain, region, logistics route, or platform.
• Substitutes are listed in organisational charts, but qualification, authorisation, shift availability, or geographical concentration remain unchecked.
• RTOs are documented without comparing them to measured actual recovery times.
• Products with high value contribution are not consistently linked with the technical and organisational dependencies that determine their deliverability.

The integrated data model does not automatically solve these problems. However, it makes them visible, verifiable, and decidable.

Normative framework: What is required – and what the model approach adds

ISO 22301:2019 is the international standard for a BCMSBCMS – Business Continuity Management System
Management system through which an organisation plans, operates, monitors, and continuously improves its BCM.. It requires a systematic management system that is planned, operated, monitored, reviewed, and continuously improved.^[2] ISO 22313:2020 explains the application and emphasises that the approach depends on the organisation’s environment and complexity.^[3] This context dependency is central to the data architecture.

ISO/TS 22317:2021 specifies the BIA process but explicitly does not prescribe a uniform procedure for all organisations. The choice of method should fit the size, sector, geographical environment, objectives, resources, and constraints.^[1] For supply chains, ISO/TS 22318:2021 extends the continuity perspective to supplier relationships and the continued provision of products, services, and resources.^[4] ISO/TS 22330:2018 addresses the preparation, support, and recovery of the workforce.^[5] ISO/TS 22331:2018 deals with the determination and selection of business continuity strategies.^[6]

For Germany, the BSI Standard 200-4 provides a detailed implementation system. It distinguishes between damage scenarios – i.e., impact categories of a process interruption – and failure scenarios, such as the failure of a building, personnel, service providers, or IT. It recommends organisation-specific defined damage categories and links BIA, target-actual comparison, risk analysis, performance review, and continuous improvement.^[7]

It is important to distinguish: The standards justify the need for analysis, prioritisation, resource and dependency consideration, and performance evaluation. The integrated data model proposed here is a possible technical and organisational implementation – not an additional normative obligation.

The architecture: five layers instead of a new data silo

1. Source systems: Keep facts where they originate

BCM should not become a parallel master data system for the entire organisation. Leading data should remain in their original systems as much as possible. The BCM model only takes over the attributes required for analysis and decision-making, their origin, and their current status.

For products, gross profit is often more indicative than mere revenue because it better approximates the contribution to covering fixed costs and results. However, it should not become the sole criticality metric: Legal obligations, safety, supply duties, customer trust, or irreversible consequential damage can make products with low financial contribution highly critical.

2. Interfaces and UIDs: Integration begins with identity

Technical transport can occur via APIsAPI – Application Programming Interface
Programming interface for the structured exchange of data or functions between systems., events, file imports, or ETLETL – Extract, Transform, Load
Procedure for extracting, rule-based transforming, and loading data from source to target systems. processes. The decisive factor is not the technology but the controlled meaning of the data. A process called „order processing“ in a BIA table, a similarly named service in the ERP, and an acronym in the CMDB are initially three data sets without assignment – even if people assume they mean the same thing.

Therefore, every relevant object needs a stable UIDUID – Unique Identifier
Permanent unique object identifier that keeps relationships stable even with renaming or system changes.. The UID does not replace the business designation; it ensures that renaming, reorganisations, or language variants do not destroy the relationship. Each object should include at least:

• UID, object type, and business designation,
• leading system and responsible role,
• validity period, last review, and data status,
• status – such as planned, active, phasing out, or decommissioned,
• confidentiality and access requirements,
• links to documents and evidence.

The integration layer must also document translations: Which field from which system is mapped to which BCM attribute? What unit applies? How are conflicts handled? Is an empty value interpreted as „not present,“ „not collected,“ or „not applicable“? Without these rules, integration appears precise but merely produces ambiguous results faster.

3. Semantic core model: Objects plus directed relationships

The core is not a form but a relationship model. A meaningful minimum structure includes:

• Products and services: What does the organisation deliver to customers, citizens, partners, or internal recipients?
• Processes and activities: What value-adding and supporting activities enable this service?
• Resources: What roles, information, business applications and IT services, machines or OT assets, buildings, and external services are needed?
• Dependencies: In what direction, strength, temporal sequence, and capacity do the relationships operate?
• Requirements and evidence: What time targets, minimum capacities, contracts, strategies, plans, exercises, and measurement results are associated?

A relationship should convey more than „A depends on B.“ Needed are, for example, dependency type, minimum capacity, lead time, substitutability, common cause of failure, validity, and evidence. Only then can it be verified whether two suppliers form genuine redundancy or merely two contracts refer to the same vulnerable source.

Time-dependent impacts: From a threshold to an impact curve

Impacts rarely grow linearly. An outage can initially be absorbed by inventory, buffers, or manual procedures and later escalate abruptly. In other cases, the greatest damage occurs immediately, such as when people are endangered, hard reporting deadlines are missed, or data loss is irreversible.

The data model should therefore not only store a criticality class but also impact values at organisation-specific time horizons – for example, 2 hours, 8 hours, 24 hours, 3 days, 7 days, and 30 days. Suitable impact dimensions include:

• Finance and liquidity,
• Law, regulation, and contract,
• Health, safety, and environment,
• Customers, citizens, or supply recipients,
• Reputation and strategic capability,
• Operational backlogs and recovery effort.

Thresholds must be calibrated specifically to the organisation. A blanket „damage greater than one million euros = very high“ can be existentially threatening for one company and insignificant for another. Financial thresholds can be aligned, for example, with risk-bearing capacity, results, liquidity, or gross profit. The article Financial Impact in Business Impact Analysis delves deeper into this derivation.

Connecting MTPD, RTO, RTA, and SLA correctly

The time metrics serve different functions:

• MTPDMTPD – Maximum Tolerable Period of Disruption
  Period after which the impacts of a disruption exceed the tolerated level.: The point in time after which the impacts of a disruption are no longer tolerable. This limit is derived from the impact development and the accepted tolerance level.
• RTORTO – Recovery Time Objective
  Target time for resuming a prioritised activity or resource after a disruption.: Target time for resuming a prioritised activity. It must lie within the MTPD and consider realistic safety margins.
• RPORPO – Recovery Point Objective
  Business-tolerable data loss, expressed as a point in the past to which data must be restored.: Business-tolerable data loss, expressed as a point in the past.
• RTARTA – Recovery Time Actual
  Actual recovery time achieved from a test, exercise, or real event.: Actual recovery time achieved from a test, exercise, or real event. The BSI approach uses it in the target-actual comparison in addition to the RTO.^[7]
• SLASLA – Service Level Agreement
  Contractual agreement on measurable performance characteristics of a service; not automatically identical to the business-required RTO.: Contractual performance commitment. It may coincide with the business RTO but does not have to.

The notation MTWDMTWD – organisation-specific time abbreviation
Not a uniformly used abbreviation; its local meaning must be clearly defined and assigned to a controlled time concept. is used in some organisations but is not a uniform guiding term in the ISO and BSI sources referenced here. Those who use MTWD internally should document the local definition and clearly map it to MTPD or another controlled term. Otherwise, seemingly identical time values are compared that express something different in business terms.

The strongest test point of the model is consistency across dependencies: If a process has an RTO of four hours, but a necessarily required external service is contractually restored only after eight hours, there is a demonstrable capability gap. The tool may mark this gap; acceptance, strategy, or investment is decided by the responsible leadership.

Suppliers: Substitutability instead of checkbox „Redundancy available“

Supplier relationships require more than name, contract number, and traffic light colour. For each procured product or service, at least the following should be recorded:

• Clearly described product or service and supported internal service,
• SLA, promised and proven recovery time, escalation path, and linked documents,
• Product or service complexity, qualification, and change effort,
• Substitutability within the required time and capacity,
• Alternative suppliers, including their actual independence,
• Locations, transport routes, critical sub-suppliers, and concentration risks,
• Inventory, range, replenishment time, and possible product alternatives.

Research on supply networks shows that disruptions can be propagated through input-output relationships and that the advantage of single or multi-sourcing depends on the risk context.^[8] „Two suppliers“ is therefore not yet a reliable strategy. What matters is whether the alternative is available in the same disruption, timely qualified, logistically accessible, and sufficient in quantity.

HR, IT, OT, buildings, and products: Criticality is relational

Roles and qualifications

For personnel resources, it is not about the blanket statement „employees required,“ but about role capability: Which role must be filled in minimum operation? What qualification, certification, authorisation, experience, language, or security clearance is required for this? How many role holders are needed per shift or location, and what equivalent substitute is provided?

At the resource level of the BIA, the required role should generally be recorded, not the name of a person. Role profiles can contain necessary skills, qualifications, certifications, authorisations, minimum staffing, and substitution requirements. The assignment of specific individuals remains – as far as operationally necessary – in the protected leading HR system and is not unnecessarily copied into the BCM/BIA model. This follows the principle of data minimisation and reduces the processing of personal data.

Business role requirements of the BIA are to be distinguished from governance responsibilities. Responsibilities such as process owner, approval, maintenance, or escalation are modelled separately and linked to the relevant objects. Personal health or private data do not belong in the BCM model unless there is a clear legal basis and documented necessity for it.

Model IT and OT separately

IT and OT should not be merged into a single resource category. The IT perspective begins with the business applications needed by the business and leads through IT services to platforms, networks, identities, databases, and infrastructure. The OT perspective begins with machines, production facilities, controls, and sensors and describes the OT services, operating parameters, and safe states required for them.

The separate views are connected where real dependencies exist: A machine may require a business application, an IT service, a network, or an identity service; conversely, an application may depend on data or states of production. Such IT-OT dependencies are modelled as directed relationships without equating IT and OT in business terms.

The CMDB is an important source for business applications, IT services, and technical relationships, but not automatically the truth about business criticality. EAM and OT-related systems provide additional information about machines, asset conditions, maintenance, and physical dependencies. The BIA justifies why and how quickly the supported service is needed. Both views must be connected through common identities and clearly assigned responsibilities.

Buildings and shared supply

An alternative location is only effective if access, workplaces, energy, telecommunications, special facilities, security requirements, and personnel availability match. The model should therefore also depict common causes of failure: two buildings on the same power node, two data centres in the same hazard zone, or multiple facilities with the same unavailable spare part.

Products and gross profit

Prioritisation sensibly begins with the products and services that fulfil the organisation’s purpose. Financial data from the ERP can make visible which gross profit is at risk over what period. Subsequently, it becomes traceable through the relationship structure which processes, roles, business applications and IT services, machines and OT services, buildings, and suppliers enable this value contribution. Thus, an abstract process criticality becomes an economically and operationally explainable decision.

Integrating risk management: Individual risks and systemic risks

BIA and risk analysis answer different questions. The BIA asks: What are the impacts of a disruption over time – regardless of its cause? The risk analysis asks: What uncertainties or events can affect objectives, how likely or plausible are they, and what controls are in place? ISO 31000:2018 emphasises that risk management should be focused on value creation and protection, integrated into the organisation, and adapted to its context.^[9]

In the integrated model, both views are connected through the same objects:

• Individual risk at object level: for example, probability of asset failure, supplier insolvency, or loss of a key qualification.
• Control and capability data: maintenance, inventory, redundancy, backup, contract, emergency procedures, tested RTA.
• Systemic risk: cascades, concentrations, and common causes of failure that only become visible from the network of dependencies.
• Impact context: time-dependent impacts and MTPD from the BIA.

A three-year researcher-practitioner collaboration with the city of Malmö developed a method to connect risk and vulnerability assessment with BIA. The authors highlight synergies but also emphasise the need to adapt the method to the needs and constraints of users.^[10] This supports the core idea of this article: Integration is sensible, standardisation without context is not.

Systemic risks cannot be adequately described as the sum of isolated traffic lights. A supplier may appear uncritical individually but become a concentration point as a common source for ten critical services. Conversely, a technically highly critical object may be well controlled systemically through effective alternatives, buffers, and rapid switching.

From analysis model to BCM strategy

ISO/TS 22317 places the BIA temporally before the selection of business continuity strategies.^[1] The data model provides a traceable transition for this:

1. Requirement: Product, service, or activity requires a certain minimum performance level within a defined time.
2. Current capability: Resources and dependencies currently provide a measured or reliably estimated recovery capability.
3. Gap: RTA, SLA, capacity, or substitution time fall short of the requirement.
4. Options: Avoid, reduce, transfer, provide, substitute, design redundantly, bridge manually, or consciously accept.
5. Decision: Selection based on effectiveness, feasibility, side effects, costs, and remaining risk.
6. Evidence: Plan, test, exercise, or real event updates the actual capability and closes the control loop.

Strategies are thus no longer just assigned to a process document. They affect specific nodes and relationships: additional inventory on a supply dependency, cross-training on a role gap, failover on an IT service, mobile technology on a facility, alternative space on a location, or a contractually secured capacity on an external service.

Governance and data quality: Who decides what?

An integrated model requires clear decision rights. Without governance, either central data maintenance arises, which is professionally overwhelmed, or distributed maintenance without common rules.

Data quality should not be abstractly described as „good“ or „bad.“ It can be checked for each attribute and relationship based on specific dimensions:

• Completeness: Are all prioritised products, activities, and essential resources recorded?
• Timeliness: Is the last professional confirmation within the specified interval?
• Consistency: Do RTO, RTA, SLA, capacity, and dependent time targets logically fit together?
• Uniqueness: Are there duplicates or competing identities?
• Verifiability: Are statements supported by contracts, tests, plans, or measurement data?
• Responsibility: Is an active role named for decision and maintenance?

Automated interfaces primarily improve timeliness and completeness. They do not replace professional definitions or approvals. For MTPD, tolerance thresholds, and accepted residual risks, human judgment remains indispensable.

Measuring BCM effectiveness: operational, economic, and organisational

ISO 22301 requires the monitoring, measurement, analysis, and evaluation of the management system.^[2] The integrated data model enables multi-level measurement that does not confuse activity with impact.

1. Operational effectiveness: Does the capability meet the requirement?

• Proportion of prioritised activities with fully linked resources and owners,
• Proportion of tests and events with RTA ≤ RTO,
• Maximum and median deviation between RTA and RTO,
• Proportion of critical supply relationships with proven substitution option,
• Proportion of critical roles with qualified, available substitute,
• Number of open single points of failure and age of measures,
• Data freshness, rule violations, and unresolved assignments.

A high level of documentation is only an early indicator. What matters is whether the organisation achieves the defined minimum performance level within the target time in exercises and events.

2. Economic effectiveness: How does BCM change the expected loss?

The economic view connects risk, time-dependent impacts, and costs. For a relevant disruption scenario, the expected loss can be modelled simply as the probability of occurrence multiplied by the impact integrated over the disruption duration. The economic impact of a strategy is then the difference between expected losses without and with the measure – minus implementation and operating costs.

Simplified decision logic:
BCM net benefit = avoided expected loss − annualised strategy and operating costs

This calculation is not an exact future value. However, it forces transparent assumptions: Which scenarios are considered? What probability or frequency is reliable? How does the impact develop over time? What uncertainty exists? What side effects does the measure produce? Where probability data is lacking, ranges and sensitivity analyses are more credible than false precision.

Research on resilience strategies distinguishes, for example, initial, maximum, and total performance loss over time. These metrics can react differently to the same strategy.^[11] An additional buffer can reduce the initial dip without accelerating long-term recovery. This is precisely why investment decisions should not be based on a single metric.

3. Organisational performance: How does performance change after the disruption?

Organisational resilience can be examined as the observed performance trajectory before, during, and after a stressor. At least one relevant performance metric, a reference trajectory, and a time window are required for this. Ilseven and Puranam show that the choice of counterfactual and observation window significantly influences the measurement.^[12]

Suitable outcome metrics can vary by organisation:

• Depth of performance dip,
• Time to minimum performance level and to normal level,
• Cumulative unperformed performance or „area“ of performance loss,
• Quality, safety, and obligation fulfilment during emergency operation,
• Backlog and catch-up effort after resumption,
• Learning and adaptation effect after the event.

Current research also warns against uncritically condensing organisational resilience into a universal score. A scoping review identified different measurement instruments and two dominant logics: context-sensitive diagnosis of resilience potentials and standardised benchmarking of organisational capabilities.^[13] For BCM, this means: A dashboard may condense, but it must keep the underlying times, impacts, dependencies, and evidence accessible.

Pragmatic introduction: start small, grow connectively

1. Define purpose and scope: Start with a product, service, or value chain, not with all company data.
2. Clarify terms and decision levels: What does product, process, activity, service, resource, MTPD, and RTA mean in this organisation?
3. Define minimal model: Only include objects, relationships, and attributes that support a specific BCM decision.
4. Assign sources and owners: For each attribute, define the leading system, responsible parties, update rule, and quality criterion.
5. Build UIDs and mapping: Initially for the chosen scope; leave duplicates and unresolved assignments visible.
6. Pilot BIA and target-actual comparison: Examine impact curves, time targets, and existing capabilities together.
7. Link strategies and measures: Each measure must trace back to a specific gap or risk exposure.
8. Learn through tests and events: Feed RTA, minimum performance, and real constraints back into the model.
9. Iteratively expand: Only add further products, dependency levels, and interfaces when benefits and responsibilities are clarified.

Such a pilot may be deliberately incomplete. Incompleteness is manageable if it is transparent. More dangerous is a model that appears comprehensive but whose data is outdated, contradictory, or not accountable.

Limits and typical misconceptions

• „Automated data is objective.“ It is only as reliable as definition, source, mapping, and timeliness.
• „The more data, the better.“ Each attribute generates maintenance effort. Without a decision purpose, it becomes data ballast.
• „The tool calculates the MTPD.“ It can visualise impacts and thresholds; the tolerance decision remains professional and managerial.
• „Redundancy is a number.“ Two dependent alternatives can have the same failure path.
• „RTO is recovery capability.“ RTO is the target, RTA or tested capability is the evidence.
• „A resilience score is enough.“ An overall score can obscure differences between preparation, response, recovery, and adaptation.

Conclusion: The data model is decision infrastructure

An organisation-specific integrated BCM/BIA data model connects existing data so that traceable priorities, capability gaps, and strategies emerge from it. It does not consolidate ERP, EAM, CMDB, HR, IT, OT, suppliers, buildings, products, and documents into a new monolith but creates a common semantic reference framework.

The real progress lies in three transitions:

1. from isolated lists to directed dependencies,
2. from target values to proven actual capability,
3. from BCM activity to measurable operational, economic, and organisational impact.

Thus, the BIA is not abolished nor fully automated. It is better prepared, more consistently updated, and more closely linked to real decisions. Technology provides transparency. Responsibility, tolerance, and strategy remain tasks of the organisation.

Glossary help: Technical terms with a question mark can be explained directly in the reading flow using a mouse, keyboard, or by tapping. The central NOVELEDGE glossary is maintained independently of this article.

References

The normative content is reproduced in essence; paid standards are not quoted verbatim. Scientific statements are limited to the accessible abstracts or full texts.

1. ISO/TS 22317:2021, Security and resilience — Business continuity management systems — Guidelines for business impact analysis. ISO Online Browsing Platform. To the first reference in the text.
2. ISO 22301:2019, Security and resilience — Business continuity management systems — Requirements, including Amendment 1:2024. Standard page at ISO. To the first reference in the text.
3. ISO 22313:2020, Security and resilience — Business continuity management systems — Guidance on the use of ISO 22301. Standard page at ISO. To the reference in the text.
4. ISO/TS 22318:2021, Security and resilience — Business continuity management systems — Guidelines for supply chain continuity management. Standard page at ISO. To the reference in the text.
5. ISO/TS 22330:2018, Security and resilience — Business continuity management systems — Guidelines for people aspects of business continuity. Standard page at ISO. To the reference in the text.
6. ISO/TS 22331:2018, Security and resilience — Business continuity management systems — Guidelines for business continuity strategy. Standard page at ISO. To the reference in the text.
7. Bundesamt für Sicherheit in der Informationstechnik (2023), BSI-Standard 200-4: Business Continuity Management. PDF at BSI. To the first reference in the text.
8. Birge, J. R.; Capponi, A.; Chen, P.-C. (2023), “Disruption and Rerouting in Supply Chain Networks”, Operations Research, 71(2), 750–767. DOI: 10.1287/opre.2022.2409. To the reference in the text.
9. ISO 31000:2018, Risk management — Guidelines. Standard page at ISO. To the reference in the text.
10. Hassel, H.; Cedergren, A. (2021), “Integrating risk assessment and business impact assessment in the public crisis management sector”, International Journal of Disaster Risk Reduction, 56, 102136. DOI: 10.1016/j.ijdrr.2021.102136. To the reference in the text.
11. Baghersad, M.; Zobel, C. W. (2022), “Organizational Resilience to Disruption Risks: Developing Metrics and Testing Effectiveness of Operational Strategies”, Risk Analysis, 42(3), 561–579. DOI: 10.1111/risa.13769. To the reference in the text.
12. Ilseven, E.; Puranam, P. (2021), “Measuring organizational resilience as a performance outcome”, Journal of Organization Design, 10, 127–137. DOI: 10.1007/s41469-021-00107-1. To the reference in the text.
13. Lo, H.-H.; Chuang, S. (2026), “A scoping review of organizational resilience measurement – instruments, indicators, and implications”, Safety Science, 196, 107114. DOI: 10.1016/j.ssci.2026.107114. To the reference in the text.