Accountability sits with the business and technical owners of the underlying critical data elements, not just the reporting team. If ownership, lineage, and control evidence are split across silos, no one can defend the result with confidence. Under BCBS 239, the institution must be able to show both who owned the data and how the control chain was applied.
Why This Matters for Security Teams
Under BCBS 239, an unexplained report is not just a documentation gap; it is evidence that accountability, lineage, and control ownership are not operationalised end to end. The reporting layer may assemble the numbers, but it cannot vouch for the quality of the source data, transformation logic, or exception handling. That is why regulators expect traceability across the data chain, not confidence by assertion.
This is especially important when firms rely on fragmented controls across finance, risk, operations, and technology. If a number cannot be explained, the question is not only what changed, but who owned the change and who could prove the control was effective. NIST’s NIST Cybersecurity Framework 2.0 reinforces the same practical idea: governance and accountability must be explicit, measurable, and reviewable.
NHIMG research on the DeepSeek breach and the Schneider Electric credentials breach shows how quickly control failures become enterprise-wide issues when ownership is blurred across systems and teams. In practice, many security teams encounter broken explainability only after a regulator, audit committee, or incident review has already asked for proof they cannot assemble on demand.
How It Works in Practice
Accountability for an unexplained BCBS 239 report should be traced back to the owners of the critical data elements, the transformation controls, and the reporting process itself. That means assigning business ownership for the meaning of the data, technical ownership for the pipelines and rules, and control ownership for the evidence that the process ran as designed. The reporting team may coordinate the output, but it should not be the only accountable party.
In a mature operating model, each material field in the report should map to a lineage record showing source, transformation, validation, and exception resolution. Control evidence should demonstrate who approved changes, who reviewed reconciliations, and who accepted residual risk. This aligns with established governance practices in the NIST Cybersecurity Framework 2.0, where ownership and oversight are treated as core operational controls rather than after-the-fact paperwork.
Practitioners typically need three layers of evidence:
- Data ownership: named business and technical owners for each critical data element.
- Lineage and transformation: traceable logic from source system to final report.
- Control operation: approvals, reconciliations, exception logs, and remediation records.
Current guidance suggests that explainability should be built into the process design, not reconstructed after an issue arises. That is why BCBS 239 programs often fail when controls live in separate teams, spreadsheets, or ticket trails that do not converge into one defensible audit story.
Common Variations and Edge Cases
Tighter control over report explainability often increases coordination overhead, requiring organisations to balance resilience against speed of reporting. The tradeoff becomes more visible where data is sourced from multiple legal entities, regional platforms, or outsourced service providers. In those environments, there is no universal standard for this yet beyond disciplined governance, so firms should avoid assuming that a single report owner can absorb accountability for every upstream decision.
One common edge case is when the report is technically correct but cannot be explained because lineage is incomplete or stale. Another is when a control failure sits in a shared platform team, while the business owner assumes technology owns it and technology assumes the business signed off. That ambiguity is exactly what BCBS 239 is meant to expose. NHIMG’s research on the DeepSeek breach shows how quickly hidden dependencies can expand impact when control ownership is not clear.
Best practice is evolving, but institutions should treat unexplained outputs as an accountability failure, not merely a reporting defect. The practical test is simple: if a senior reviewer asks why the number is right, the organisation should be able to name the accountable owner, show the lineage, and present the control evidence without delay.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OC-03 | Clarifies organisational roles and accountability for governed processes. |
| NIST CSF 2.0 | ID.IM-01 | Supports tracking and documenting changes that affect report explainability. |
| NIST AI RMF | Govern function applies to accountability and traceability across automated decision processes. |
Assign named owners for critical data, lineage, and reporting controls, then verify accountability in governance reviews.
