MaRisk at 8.2 – Requirements for “Changes to Operational Processes or Structures” of Banks

MaRisk at 8.2 – Requirements for “Changes to Operational Processes or Structures” of Banks

Background and objectives

Financial institutions must understand their business activities carried out and identify, monitor and control the associated risks. This also applies to changes resulting from the business and risk strategies. The “minimum requirements for risk management” (MaRisk) provide a corresponding adaptation process for this purpose according to AT 8.2 “Changes to operational processes or structures” in order to reasonably control the risks due to the lack of knowledge of the impacts of changes in the organisational structures.

In order to fulfil the minimum regulatory requirements, reporting duties and framework conditions, the financial institutions must implement corresponding regulations and processes in the form of organisational guidelines.

In the case of planned “changes to operational processes or structures”, an impact analysis of the planned changes must already be carried out prior to the implementation of essential changes in the structure and process organisation and in the IT systems. This requires the organization to continue to ensure the impacts of the planned changes on the control processes, the control intensity, as well as the functionality and effectiveness of the internal control systems (ICS) under the changed framework conditions. In addition to this need to respond reasonably to changes of the risk situation.

These projects require a suitable process model for quality and change management, with the associated committees, reporting and escalation processes. The objective of the changes in the planned framework (scope, quality, time and costs) are difficult to achieve and, from experience, the risk profile is negatively affected without a structured, ordered and comprehensible approach to the individual project phases. Unfortunately, this is often demonstrated in practice with IT (software) projects which often fail, only partly achieve the intended objective or require significantly more time and costs than was originally planned.

Impacts on the risk profile

For the implementation of software migration projects in a customer-specific system environment, essential changes in the IT applications and processes in question are frequently required to comply with the regulatory requirements under MaRisk AT 8.2. Additional detail will not be provided at this point on the changes of the specialist risk profile, the existing work processes and the control activities integrated. However, it is mandatory to take into account these above-mentioned requirements accordingly. Well-developed project management, ideally closely linked to the management processes of operational risks is helpful for this purpose and usually essential. In the case of planned changes of operational processes or structures, the risks primarily result from typical project environment risks.

Phase-oriented process model

The requirements with respect to a structured, comprehensible and documented approach were further specified by the “Banking Regulatory Requirements for IT Systems (BAIT)” of 3/11/2017 and the consultation draft 04-2018 “Insurance Regulatory Requirements for IT Systems (VAIT)” which has been in place since 13/3/2018. It is worth noting that these requirements are overall not new and have already been part of the established norms, standards and best practices and correlate with a professional approach.

Phase model for changes

Irrespective of the trigger and the type of change, the changes are carried out in the organisational structure in identical phases which are repeated in an iterative manner. The “three-phase model” for changes breaks down the project process into individual phases and delivers the rough structure for the project:

Phase I

  • Trigger (problem) – project idea
  • Analysis of task and solution(s) – preliminary study
  • Decision/resolution by management (rejection or approval with/without requirements) – project initialisation or non-implementation

Phase II

  • Specification – definition of requirements
  • Implementation – realisation
  • Testing – test
  • Activation – productive start-up

Phase III

  • Stabilisation – error correction, support in the introductory phase
  • Review – remaining work
  • Project completion – look back (“lessons learned”)

In case of comprehensive changes to the work processes, it is essential for the specialist departments to prepare in advance corresponding specialist concepts with the specialist requirements which should generally be obligatory. This is usually only successful with comprehensive support from IT application management and with the involvement of specialists in the form of work and time-intensive workshops. If a complete and understandable requirements specification is omitted, there is a very high risk that the projects fail or cannot be implemented within the desired framework (time, costs, scope and quality). In order to ensure the completeness and consistency of the specialist concepts, the requirements must be quality-assured from different points of view and with the involvement of the governance functions. In this case, the implementation sequence and the dependencies with other projects should be taken into account. Acceptance of the specialist concepts by the specialist departments should generally not be omitted. This applies equally to the IT technical concepts in order to provide a trusted and accepted basis for implementation.

Phase model for software development

When implementing a software migration project in a customer-specific system environment, it is very important to not only structure the project process, but also to consider the software development process with all associated phases as an integral part of the project.

The process of a phase-oriented software development project is outlined schematically below:

  • Phase I – Requirements analysis

  • Phase II – Design

  • Phase III – Implementation

  • Phase IV – Test and acceptance

  • Phase V – Delivery and production start

  • Phase VI – Stabilisation phase

Depending on the scope, structure and implementation approach, the individual phases are passed through repeatedly.

Test and acceptance of the system

Testing is an essential and major challenge in order to verify the completeness of the implementation of the solution and the correct processing functionality. These tasks are mainly bundled in one separate partial project and planned, executed, monitored and controlled based on a test concept which includes different test stages. In order to transparently and comprehensibly design the testing, all phases of the test process (test planning, execution, documentation, evaluation and reporting) should be depicted in a test management tool. The acceptance process based on defined criteria includes all test stages and regulates the requirements for the transition to the next test stage and for all test procedures. It is the proof that the functional and non-functional requirements have been fulfilled. The test execution is therefore necessarily carried out in separate system environments which are separated from the production environment. With regard to the test data used, requirements under data protection law must be observed.

A comprehensive test environment is usually provided for the final acceptance test. This environment includes all associated systems which will compromise the future production environment.

Learn More
Find out more on the new MaRisk here.
Learn More

Read more


With Q_PERIOR, you have a strong partner at your side.
We look forward to your challenge!