Summary

The BDI provides security measures based on ISO 27001. This is an internationally recognized standard for establishing, implementing, maintaining, and continually improving an Information Security Management System (ISMS).

In essence, ISO 27001 provides a framework for organizations to establish a robust and comprehensive information security management system that helps them protect their valuable assets and infrastructure. This page contains a breakdown of the key measures it encompasses.

Purpose of this building block

1. Information Security Policy:

• Foundation: The cornerstone of the ISMS.

• Scope: Defines the organization's commitment to information security, outlining its scope, objectives, and responsibilities.

• Key Elements:

2. Risk Assessment and Treatment:

• Identification: Identifying potential threats to information assets (e.g., cyberattacks, natural disasters, human error).

• Analysis: Evaluating the likelihood and impact of these threats.

• Treatment: Implementing controls to mitigate identified risks. This can involve:

3. Control Implementation:

• Selecting Controls: Choosing appropriate security controls from Annex A of ISO 27001. These controls address a wide range of security areas, including:

  • Access Control: Restricting access to information based on need-to-know principles.

  • Physical Security: Protecting physical assets such as servers, data centers, and mobile devices.

4. Monitoring, Measurement, Analysis, and Improvement:

• Internal Audits: Conducting regular internal audits to assess the effectiveness of the ISMS.

• Management Reviews: Conducting periodic reviews by management to evaluate the overall performance of the ISMS and identify areas for improvement.

• Corrective and Preventive Actions: Implementing corrective actions to address identified nonconformities and preventive actions to prevent future problems.

Key Benefits of Implementing ISO 27001:

• Enhanced security posture: Reduces the risk of data breaches, cyber attacks, and other security incidents.

• Increased customer trust: Demonstrates a commitment to data protection and security.

• Improved operational efficiency: Streamlines security processes and reduces the costs associated with security incidents.

1. Introduction

The BDI Security Framework defines a structured approach to cybersecurity within BDI’s federated, many-to-many architecture. The framework provides the following functionality:

2. Security in relation to Trust

It is important to note the difference between security and trust. Trust serves as the foundation for recognition and mandate within the BDI, while security safeguards these relationships by ensuring systems execute them safely. The current building block focuses on the Security framework. The table below highlights the distinct focus of the Trust and Security frameworks.

While the domains Trust and Security are closely related and mutually reinforcing, a deliberate distinction should be made. The agreements and business rules defined in the trust framework influence the security architecture, but the Security framework focuses purely on the execution and assurance side.

For enforcement across internal and external domains, see “Delegated Implementation vs. Retained Accountability.”

3. Purpose

The BDI Security Framework delivers a common reference model for coordinated security across distributed actors. It is based on , providing coordinated, outcome-oriented security guidelines. The security framework ensures the protection of digital interactions between independent actors.

3.1 Features of the BDI Security Framework

The framework

• Aligns with BDI's federated, role-based architectural model

• Supports multi-party risk governance across diverse maturity levels

• Will be extended with minimum requirements per role and example implementation controls

See “Profiles and Risk Assessment” and “Roles and Profiles: Separation and Mapping” for current definitions and mappings.

4. Enforcement and local implementation autonomy

The BDI Security Framework is neither a compliance baseline nor a certification mechanism. Instead, it acts as a practical guide, while the actual enforcement decisions remain the responsibility of each association or federation.

• Associations may mandate profiles or specific requirements.

• Additional controls may be applied depending on risk classification.

• Coordination with the agreement framework ensures that trust enforcement and security execution remain aligned.

This model preserves interoperability while allowing flexibility in local adoption and scaling.

5. Why NIST CSF 2.0?

This security framework is built on NIST CSF 2.0 to meet the operational realities and governance needs of BDI. Rather than introducing a new model, the framework intentionally leverages an established and adaptable framework that aligns with existing organizational practices.

6. Structure of the Security Framework

This framework is organized around the six core functions of :

• Govern: Establish and monitor cybersecurity risk governance, accountability, and strategic alignment.

• Identify: Develop an understanding of assets, systems, data, and risks across the ecosystem.

• Protect: Implement safeguards to ensure service continuity, data protection, and access control.

Each function is further elaborated per profile with relevant subcategories, implementation tiers, and control examples. These are provided as part of the Coherent Security Register, which can be found at the end of this page.

Role-specific mappings and associated responsibilities are elaborated in “Roles and Profiles: Separation and Mapping".

7. Scope

This security framework provides a common foundation for cybersecurity across the BDI ecosystem, enabling secure, scalable, and trust-based data interaction between independent participants. The system

• focuses on the enforceable interface between participants in the BDI ecosystem (roles, systems, interfaces).

• extends into internal domains only where trust agreements impose obligations on processing or safeguarding received data.

• allows for enforceable controls if trust agreements call for it.

8. Design principles and capabilities

The design principles and capabilities of the security framework are specified as follows:

• Covers technical controls, governance processes, behavioral practices, and/or operational workflows

• Provides a role-based structure with minimum and maturity-based requirements, enabling capability growth over time

• Supports interoperable and auditable trust decisions across organizations, using a shared language of controls

9. Security profiles and risk assessment

Profiles define the minimum set of security outcomes required to fulfill responsibilities associated with BDI Security Framework Profiles. They represent coherent bundles of responsibilities aligned to ecosystem needs.

Each association implementing BDI must assess whether the “Minimum” Profile requirements are sufficient for their respective use cases, based on risk classification (e.g., information sensitivity or business impact). A practical approach is to use classification schemes such as CIA (Confidentiality, Integrity, Availability). If risks exceed the Minimum baseline, additional controls should be selected.

Profiles are based on real-world usage scenarios. For guidance on creating and using profiles, please refer to . They ensure that actors in similar roles apply comparable protection levels and contribute to ecosystem-wide assurance.

10. BDI roles and profiles: separation and mapping

Profiles do not define what technology to use. They define the responsibilities of a role, regardless of implementation. For BDI-specific implementation examples, refer to the Coherent Security Register documentation (See the attached document at the bottom of this page).

Each maps to a BDI CSF Profile as follows:

An organization may assume multiple roles and thus implement multiple profiles. The security requirements that follow depend on which profiles are fulfilled.

11. Delegated implementation vs. retained accountability

Each profile assigns accountability for meeting its associated security outcomes. Delegated responsibilities must be traceable, enforced contractually if needed, and auditable where required. This allows vendors and partners to understand what is expected of them, even if they are not directly bound by trust agreements.