BDI Security Framework
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:
Participation
The framework enables participants - regardless of their maturity - to organize security coherently across roles, organizations, and technology boundaries.
Security
The framework covers the full scope of security including technical controls, behavioral practices, governance processes, and recommended operational workflows.
Responsibility and Trust
The framework focuses on the enforceable layer between participants, while outlining continued responsibilities once data enters internal domains where trust obligations apply.
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.
Without security, trust erodes. Without trust, security cannot scale.
Trust framework
is defined through governance agreements, roles, mandates, and ecosystem-wide business rules.
organizes trust between parties through business rules, governance, agreements, and audits.
Security framework
is the enforcement and operational execution of the trust agreements via protective and assurance mechanisms.
manages risks and prevents undesirable behavior through technical and organizational measures.
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 NIST Cybersecurity Framework (CSF) 2.0, 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
Functions as a living framework, continuously refined based on operational feedback and practical adoption
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.
Federated Applicability
CSF 2.0 is suitable for ecosystems of multiple, independent actors operating under a shared but non-centralized governance model.
Compatibility with Legal Standards
It allows integration and mapping with NIS2, ISO/IEC 27001/2, BIO (Baseline Informatiebeveiliging Overheid), GDPR / AVG, and other frameworks used for compliance or internal policy.
Operational and Strategic Usability
The structure supports practical use in day-to-day security operations as well as in board-level and governance contexts.
Role-based Extensibility
The framework is designed to be expanded with role-specific minimum requirements and example control sets.
Support for Staged Maturity
Built-in maturity levels and outcome-oriented design allow structured capability growth over time.
6. Structure of the Security Framework
This framework is organized around the six core functions of NIST CSF 2.0:
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.
Detect: Establish capabilities to identify the occurrence of cybersecurity events in real time or retrospectively.
Respond: Coordinate actions during and after a detected incident to contain impact and communicate effectively.
Recover: Maintain plans for restoring assets and services and improving future resilience.
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.
is aligned with the BDI agreement framework.
complements trust governance with enforceable security execution.
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 NIST SP 1301. They ensure that actors in similar roles apply comparable protection levels and contribute to ecosystem-wide assurance.
Detailed subcategories, required outcomes, and implementation examples per profile are maintained in the separate BDI Coherent Security implementation register.
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 BDI role maps to a BDI CSF Profile as follows:
Data owner
Data Provisioning Profile
Covers the provisioning of data or event access. Organizations implementing this profile might delegate responsibilities (but not accountability) to others.
Data Consumer
Data Access Requesting Profile
Covers the requesting of data or event access. Organizations implementing this profile might delegate responsibilities (but not accountability) to others.
Identity Provider, Identity Broker & Association Administrator
Trust Services Profile
Provides foundational trust services through authentication and federation for digital actors, and maintains oversight via registry, role, and mandate governance at the ecosystem level.
Data Service Provider
Policy Enforcement Profile
Executes technical implementation of data access and security policies defined by the Data Owner.
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
BDI acknowledges that many organizations, especially smaller ones, may outsource or delegate parts of their technical implementation to software vendors or ICT service providers.
Note that outsourcing does not shift 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.
Last updated