BCBS 239 asks systemically important banks to prove that their risk data is accurate, complete, timely and protected, and much of that proof depends on controls the security and technology functions own. The Basel Committee on Banking Supervision published its Principles for effective risk data aggregation and risk reporting on 9 January 2013, after the financial crisis that began in 2007 showed that many banks could not aggregate risk exposures fully, quickly and accurately. More than a decade later supervisors still treat it as unfinished work: the Committee's November 2023 progress report on 31 global systemically important banks (G-SIBs) found banks at different stages of alignment, and the European Central Bank (ECB) published a dedicated supervisory guide in May 2024. This guide explains the 14 principles in practical terms for CISOs, security architects and technology risk leads in banks, and shows where data integrity, access control, resilience and machine identity controls provide the evidence supervisors ask for. For the wider regulatory landscape, see the Financial Services Cyber Regulation Map.
Key takeaways
- It is a data integrity standard as much as a risk standard. The principles say controls around risk data should be as robust as those for accounting data, and define integrity as freedom from unauthorised alteration.
- Resilience is written in. Principle 2 requires aggregation to work in stress as well as normal times and to be part of business continuity planning, so a cyber incident that stops risk reporting is a BCBS 239 problem.
- Lineage and data quality are now examined in detail. The ECB expects complete, current lineage at data attribute level for key risk indicators and their critical data elements, which depends on reliable logging and change control.
- Manual workarounds and spreadsheets are a known weak point. Both the principles and the ECB guide expect end-user computing to be inventoried, controlled with audit trails and reduced over time.
- Pipelines run on non-human identities. Extract, transform and load jobs, reporting tools and data platform connectors hold credentials that can alter risk data, so they need owners, least privilege and monitoring.
What BCBS 239 is and who it applies to
BCBS 239 is the informal name for the Basel Committee's January 2013 principles (Basel publication number 239). It is a supervisory standard, not a law: national supervisors give it effect through their own supervisory expectations.
- Scope: the principles are addressed first to systemically important banks, at banking group and solo level. National supervisors may apply them more widely, in proportion to a bank's size and complexity.
- G-SIBs: banks designated as G-SIBs in November 2011 or November 2012 were expected to comply by January 2016. Banks designated later are expected to comply within three years of designation.
- D-SIBs: the Committee strongly suggests supervisors apply the principles to domestic systemically important banks three years after their designation.
- Outsourcing: the principles also apply to processes that have been outsourced, so cloud data platforms and managed reporting services are in scope.
- Euro area: the ECB Guide on effective risk data aggregation and risk reporting (May 2024) sets out its expectations for banks it supervises, covering internal risk reports, published financial reports and supervisory reports such as FINREP, COREP and Pillar 3, plus key internal models and key risk indicators.
Requirements and supervisory practice differ by jurisdiction. Confirm the expectations that apply to your bank with your supervisor's own publications.
The 14 principles at a glance
| Area | Principle | What it means in practice | Security and technology contribution |
|---|---|---|---|
| I. Overarching governance and infrastructure | 1. Governance | Board-approved framework, fully documented, independently validated | Policies on confidentiality, integrity and availability of risk data |
| 2. Data architecture and IT infrastructure | Integrated taxonomies, owners across the data lifecycle, continuity in stress | Business continuity, resilience, architecture and change control | |
| II. Risk data aggregation capabilities | 3. Accuracy and integrity | Reconciliation with source systems, single authoritative source, controlled manual processes | Integrity controls, access control, audit trails, end-user computing controls |
| 4. Completeness | All material risk data across the group | Asset and data inventories, coverage of shadow data stores | |
| 5. Timeliness | Rapid aggregation of critical risks in stress | Recovery objectives for data platforms; unauthorised access listed as a time-critical operational indicator | |
| 6. Adaptability | Ad hoc and supervisory requests, drill-downs | Secure self-service access without broad standing privileges | |
| III. Risk reporting practices | 7. Accuracy | Reports reconciled and validated, validation rule inventory, exception reporting | Integrity monitoring of reporting layers |
| 8. Comprehensiveness | All material risks covered | Cyber and ICT risk reported alongside other risks | |
| 9. Clarity and usefulness | Reports fit for the reader | Clear cyber risk metrics for the board | |
| 10. Frequency | Frequency matches the risk | Reliable scheduling and monitoring of reporting jobs | |
| 11. Distribution | Reports reach the right people while keeping confidentiality | Access control and data loss prevention for risk reports | |
| IV. Supervisory review, tools and cooperation | 12. Review | Supervisors review compliance | Evidence packs: logs, access reviews, test results |
| 13. Remedial actions and supervisory measures | Supervisors can require remediation | Tracked remediation of control gaps | |
| 14. Home/host cooperation | Supervisors cooperate across borders | Consistent group-wide controls |
Where security controls carry the principles
Integrity and access control (Principles 1, 3 and 7)
The principles say "Controls surrounding risk data should be as robust as those applicable to accounting data", expect governance to include policies on data confidentiality, integrity and availability, and define integrity as freedom from unauthorised alteration. In practice that means:
- Least privilege on risk data stores: write access to risk data warehouses, data lakes and reporting marts limited to defined pipelines and named roles, with quarterly access reviews.
- Separation of duties: people who build transformation logic do not also approve its release or alter production data directly.
- Change control: transformation code, mappings and validation rules held in version control, peer reviewed and deployed through a controlled pipeline.
- Tamper evidence: audit logs of data changes and administrative actions retained and protected from the administrators they record.
Resilience (Principles 2 and 5)
Principle 2 asks that aggregation capabilities be given direct consideration in business continuity planning and subject to a business impact analysis. Principle 5 expects banks to produce aggregated data for critical risks rapidly in stress or crisis, naming large corporate credit, counterparty credit, trading exposures, liquidity indicators and time-critical operational indicators such as unauthorised access. A ransomware attack on the data platform during market stress is exactly that scenario. Set recovery time and recovery point objectives for risk data platforms, keep isolated backups, and rehearse producing the critical risk reports from recovered systems. See the Cyber Recovery Vault Guide.
Lineage and data quality (Principles 2, 3 and 7)
The ECB expects lineage that is complete and up to date at data attribute level, tracing data from capture through extraction, transformation and loading for key risk indicators and their critical data elements. It also expects a register of data quality issues with severity, root cause, quantified impact, assigned responsibilities and remediation deadline. Lineage tools depend on accurate pipeline logs and metadata, so logging gaps become lineage gaps. See Data lineage, data quality and data contracts as security controls.
End-user computing (Principle 3)
The principles expect every aggregation process, including manual ones, to be documented, with manual workarounds justified, their criticality to accuracy stated and actions proposed to reduce their impact. The ECB adds that end-user computing applications should be inventoried and covered by data quality policies, that manual workarounds need controls such as the four-eyes principle and audit trails, and that manual processes should be replaced over time by audit-trailed, IT-controlled environments. Security teams can help by discovering spreadsheets and desktop databases that feed risk reports, and by enforcing storage locations with versioning and access logging.
Distribution (Principle 11)
Risk reports are among the most sensitive documents a bank produces. Apply data classification, restrict distribution lists, and monitor for exfiltration. See the Data Classification Guide.
Where identity fits: the machine identities behind risk data
Most risk data never passes through a human hand between source system and report. Scheduled jobs, integration platforms, business intelligence tools and cloud data services move and transform it using service accounts, API keys and cloud roles. Each of these can alter risk data, so each is an integrity control point.
- Inventory: list every non-human identity with write access to risk data stores, with a business owner and the pipeline it serves.
- Scope: grant write access only to the tables or datasets a job maintains; read-only identities for reporting tools.
- Credentials: store secrets in a vault, prefer short-lived tokens or workload identity federation, and rotate static keys on a defined schedule.
- Monitoring: alert when a pipeline identity is used interactively, from a new location, or outside its schedule.
See the Non-Human Identity (NHI) Guide.
Building a BCBS 239 security work plan
- Agree scope with the chief data office: obtain the list of in-scope reports, key risk indicators and critical data elements, and the systems that produce them.
- Map the data flows: from source systems through pipelines to reporting layers, including outsourced and cloud components and end-user computing.
- Assess controls per hop: access control, change control, logging, encryption, backup and recovery for each system and pipeline identity.
- Close the highest-impact gaps first: typically broad write access, unowned service accounts, untested recovery and uncontrolled spreadsheets on critical data elements.
- Test under stress: include risk report production in business continuity and cyber exercises, timing how long critical reports take from recovered systems.
- Feed the evidence: provide access reviews, change records, recovery test results and data quality issue links to the independent validation function and internal audit.
- Report cyber risk properly: make sure ICT and cyber risk is itself aggregated accurately and reported to the board. See the Board Cyber Risk Reporting Guide.
Decision guidance: a G-SIB with a large remediation programme should embed a security architect in the BCBS 239 programme and align control testing with independent validation. A smaller bank that its supervisor expects to follow the principles proportionately can focus on the critical data elements behind its key risk indicators and on recovery testing of the reporting platform.
Detection and measurement
| Metric | Why it matters |
|---|---|
| Share of in-scope pipeline identities with an owner, least-privilege scope and rotated credentials | Integrity of automated aggregation |
| Privileged write access to risk data stores reviewed in the last quarter | Accuracy and integrity (Principle 3) |
| End-user computing tools on critical data elements that are inventoried and under access logging | Manual workaround control |
| Measured time to produce critical risk reports from recovered systems | Timeliness in stress (Principle 5) |
| Data quality issues caused by unauthorised or uncontrolled change | Shows whether change control is working |
| Lineage coverage gaps traced to missing pipeline logs | Logging supports lineage |
Monitor for direct database changes outside release pipelines, interactive use of pipeline identities, large exports of risk reports, and failed or late scheduled reporting jobs.
Framework mapping
| BCBS 239 theme | NIST CSF 2.0 | NIST SP 800-53 Rev 5 | Related EU rule |
|---|---|---|---|
| Governance (P1) | GV.RM-01, GV.OV-01 | PM-23 | ECB guide section 3.1 |
| Architecture and continuity (P2, P5) | PR.DS-11, PR.PS-01 | CP-2 | DORA ICT risk management and resilience testing |
| Accuracy and integrity (P3, P7) | PR.DS-01, PR.DS-02, PR.DS-10 | SI-7, AU-10, AC-6 | ECB guide section 3.5 |
| Completeness and inventories (P4) | ID.AM-07 | PM-23 | ECB guide section 3.2 |
| Outsourced processes | GV.SC-07 | SR-3 | DORA ICT third-party risk |
See the DORA Guide for the EU ICT risk rules that sit alongside these expectations for in-scope banks.
Common failure patterns
- Treating BCBS 239 as a data office project only: security controls that supervisors expect to see are missing from the programme plan and evidence.
- Shared service accounts in pipelines: one account with write access across the warehouse makes every job a single point of integrity failure.
- Recovery plans that stop at infrastructure: systems come back, but nobody has tested whether critical risk reports can be produced on time from them.
- Uncontrolled spreadsheets on critical data: a manual adjustment file on a shared drive, with no versioning or access logging, feeds a board report.
- Logs that do not support lineage: pipeline runs are not logged consistently, so attribute-level lineage cannot be evidenced.
- Cyber risk outside the risk reports: cyber and ICT risk metrics are reported separately and never reconciled into the group risk picture.
Practitioner checklist
- Obtain the in-scope reports, key risk indicators and critical data elements from the chief data office.
- Map data flows end to end, including cloud, outsourced and end-user computing components.
- Restrict write access to risk data stores to named pipelines and roles, reviewed quarterly.
- Put transformation code, mappings and validation rules under version and change control.
- Inventory pipeline service accounts, keys and roles; assign owners, scope and rotation.
- Protect audit logs of data and administrative changes from the people they record.
- Include risk report production in business continuity and cyber recovery exercises, with timings.
- Discover and control spreadsheets and desktop tools feeding critical data elements.
- Supply security evidence to independent validation and internal audit on a regular cycle.
Standards and references
- Basel Committee on Banking Supervision: Principles for effective risk data aggregation and risk reporting
- Basel Committee on Banking Supervision: Principles for effective risk data aggregation and risk reporting (full text)
- Basel Committee on Banking Supervision: Progress in adopting the Principles for effective risk data aggregation and risk reporting
- European Central Bank: Guide on effective risk data aggregation and risk reporting
- EUR-Lex: Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA)
- NIST: Cybersecurity Framework 2.0
Related NHI Mgmt Group resources: Financial Services Cyber Regulation Map · Banking Cybersecurity Programme Guide · Data lineage, data quality and data contracts as security controls · Key Risk Indicators for Cyber Risk Guide. This guide summarises the BCBS 239 principles and related supervisory guidance and is not legal advice.