IT Data Integrity Risk

From Open Risk Manual

Definition

IT Data Integrity Risk is the risk that data stored and processed by IT systems are incomplete, inaccurate or inconsistent across different IT systems, for example as a result of weak or absent IT controls during the different phases of the IT data life cycle (i.e. designing the data architecture, building the data model and/or data dictionaries, verifying data inputs, controlling data extractions, transfers and processing, including rendered data outputs), impairing the ability of an institution to provide services and produce (risk) management and financial information in a correct and timely manner.[1]

Risk Sub-types

Dysfunctional data processing or handling

Due to system, communication and/or application errors or failures, or erroneously executed data extraction, transfer and load (ETL) process, data could be corrupted or lost.

Examples

  • IT system error in batch processing, causing incorrect balances in client’s bank accounts.
  • Wrongly executed queries.
  • Data loss due to data replication (backup) error.

Ill designed data validation controls in IT systems

Errors relating to missing or ineffective automated data input and acceptance controls (e.g. for used third party data), data transfer, processing and output controls in the ICT systems (e.g. input validity controls, data reconciliations).

Examples

  • Insufficient or invalid formatting/validation of data inputs in applications and/or user interfaces.
  • Absence of data reconciliation controls on produced outputs
  • Absence of controls on the executed data extraction processes (e.g. database queries) leading to erroneous data.
  • Use of faulty external data.

Ill controlled data changes in the production IT systems

Data errors introduced due to lack of controls on the correctness and justified nature of data manipulations performed in the production of ICT systems

Examples

  • Developers or database administrators directly accessing and changing the data in the production IT systems in a non-controlled way e.g. in the case of an IT incident.

Ill designed and/or managed data architecture, data flows, data models or data dictionaries

Ill managed data architectures, data models, data flows or data dictionaries may result in multiple versions of the same data across the IT systems, which are no longer consistent due to differently applied data models or data definitions, and/or differences in the underlying data generation and change process.

  • The existence of different customer databases per product or business unit with different data definitions and fields, resulting in unreconciled and difficult to compare an integrate customer data at the level of the whole financial institution or group.

Factors

An institution may be more exposed to IT data integrity risks

  • due to the complexity (e.g. as a result of mergers or acquisitions)
  • due to outdated nature of its IT systems
  • due to material changes to its IT systems and/or IT function (e.g. as a result of mergers, acquisitions, divestments or the replacement of its core IT systems)

Controls

The institution’s control framework should consider the risks associated with preserving the integrity of the data stored and processed by the IT systems, in particular

  • a policy that defines the roles and responsibilities for managing the integrity of the data in the IT systems
    • data architect
    • data officers responsible for data processing and usage
    • data custodians responsible for the safe custody, transport and storage of data
    • data owners/stewards responsible for the management and fitness of data elements – both the content and metadata and
  • a policy that provides guidance on which data are critical from a data integrity perspective and should be subject to specific IT controls or reviews (e.g. a compatibility check with the data architecture) in the different phases of IT data life cycle, including:
    • automated input validation controls
    • data transfer controls
    • reconciliations
  • a documented data architecture, data model and/or dictionary, that is validated with relevant business and IT stakeholders to support the needed data consistency across the IT systems and to make sure that the data architecture, data model and/or dictionary remain aligned with business and risk management needs;
  • a policy regarding the allowed usage of and reliance on End User Computing, in particular regarding the identification, registration and documentation of important end user computing solutions (e.g. when processing important data) and the expected security levels to prevent unauthorised modifications, both in the tool itself, as well as data stored in it;
  • documented exception handling processes to resolve identified IT data integrity issues in line with their criticality and sensitivity.

See Also

Supervised institutions that fall under the scope of the BCBS 239 principles for effective risk data aggregation and risk reporting should also review the risk reporting and data aggregation capabilities mandated therein

References

  1. EBA, Final Guidelines on ICT Risk Assessment under SREP