Integrated Risk and Control System Guideline · 2019-11-24 · Integrated Risk and Control SystemGuideline –v1.0, 24.04.2017 5 1. Single harmonized IRCS framework established for

n Version 1.0

Effective: 01.05.2017

Integrated Risk and Control System Guideline <IRCSG>

Allianz Functional Rule

Classification: Internal ©Allianz SE 2017

Authorization

The content of this document has been reviewed and approved as follows:

Version Valid from

11.0 101 .05.2017

Authorized by

Group Center Head Authorization Date

ALZ.0001.0097.3440

ALZ.0001 .0097 .3441

Table of Contents

Chapter Content Page

A. Introduction 3

A.I. Rational and Scope of Application 3 A.II. Authorization and Updates 3

B. IRCS Concept & Princ iples 4

B.I. IRCS Concept 4

B.11. IRCS Principles 6

c. IRCS Process Requirements 11

C.I. Scoping 11 C.1.1 Scoping of reporting risks 12

C.1.2 Scoping of compliance risks 15 C.1.3 Scoping of other operational risks 16

C.11. Risk and Control Self Assessments 17 C.11.1 Preparing for RCSA workshops 18 C.11.2 Conducting RCSA workshops 19

C.111. Key Control Testing 21 C.111. 1 Test planning 21 C.111.2 Test performance 23

C.IV. Monitoring 26 C.IV.1 Key Risk Indicators 27

c.v. Issue Management 27 C.V.1 Sources of issues 28 C.V.2 Classification of issues 28 C.V.3 Remediation of issues 30

C.VI. Reporting 30 C.Vll. Documentation 30 C.Vll l. Special Considerations 31

C. V/11.1 IT Controls 31 C. V/11.2 System of Governance Assessment 35 C. V/11.3 Outsourcing 37

0. Roles and Responsibilities 38

D.I. 1st Line of Defense 38 D.11. 2na Line of Defense 40

D.111. Other Roles 42

Glossary and defin itions 44

Appendix A Risk Assessment Methodology 45

Appendix B IRCS Catalogue 53 Appendix C IRCS Scoping Flowchart 53

Integrated Risk and Control System Guideline - v1.0, 24.04.2017 2

Integrated Risk and Control System Guideline –v1.0, 24.04.2017 3

A. INTRODUCTION

A.I RATIONALE AND SCOPE OF APPLICATION

This Integrated Risk and Control System Guideline (‘Guideline’) establishes the core principles, as well as a set of minimum requirements, governing the Integrated Risk and Control System (‘IRCS’). This Guideline is a supplemental functional rule to the Allianz Standard for Operational Risk Management.

The IRCS is a risk management process by which OEs must ensure, through performance of a qualitative based analysis, that effective controls or other risk mitigation activities are in place for all significant operational risks.

This Guideline is mandatory for all operating entities (OE) of the Allianz Group.1

OE Boards of Management are requested to implement and ensure ongoing adherence to this Guideline within their company or area of responsibility, consistent with applicable legal or regulatory requirements. If this Guideline is in conflict with local laws or regulations, the local laws or regulations have priority. In this case, Group Risk should be immediately informed in order to agree on how the Guideline should be applied.

A.II AUTHORIZATION AND UPDATES

The Member of the Board of Management of Allianz SE in charge of H2 has the overall responsibility for risk management. Within H2, Group Risk – ORM & Policies is the owner of this Guideline and is responsible for maintaining and updating this document.

This Guideline will be reviewed at least once per year. All material changes require approval by the Allianz Group Chief Risk Officer.

This Guideline is available on the Allianz Connect Corporate Rules Book. It supersedes the Operational Risk and Control Self-Assessment Guideline, version 4.0, the ICOFR Policies & Procedures Manual, version 1.1, and the IT Risk Management Guideline, version 1.0.

1

The IRCS will be rolled-out to individual OEs over multiple years based upon a roll-out plan decided by the Allianz SE Board of Management. Each OE must continue to apply the existing Operational Risk and Control Self Assessment Guideline and ICOFR Policies & Procedures Manual until they are selected for IRCS implementation according to the roll-out plan.

The IT Risk Management Guideline is superseded by this Guideline and no longer applies, irrespective of whether or not the OE has completed IRCS implementation.

ALZ.0001.0097.3442


B. IRCS CONCEPT AND PRINCIPLES

B.I IRCS CONCEPT

Within an OE it is the responsibility of each individual to ensure that the operational risks related to their business activities are adequately controlled. For the most significant operational risks the 2

ndLine of Defense is additionally employed to ensure these individuals are adequately

meeting this responsibility. The IRCS is the framework by which this 2nd

Line of Defense oversight is executed.

Fundamental to the IRCS is the concept of an integrated approach. While there are several different sources of operational risks (e.g. Reporting risks, Compliance risks, IT risks) the process towards their management always follows the same basic formula; significantoperational risks must be identified, assessed and prioritized for improved management and it must be ensured that the controls underlying their management are effective. This is the basic premise behind establishing an integrated approach, which in turn provides the following benefits:

The ability to compare all types of operational risks using a single methodology, which supports intelligent decision making for the allocation of limited resources towards Internal Control System (ICS) improvements;

The use of a single common language when discussing the ICS with both business process owners and management, which reduces confusion and thereby improves their understanding of operational risk management; and

Encouragement of cross-functional collaboration between the 2nd

Lines of Defense, which allows these functions to report to management as one voice while still meeting their responsibilities to oversee the management of specific types of operational risks.

Ultimately an integrated approach provides a clearer view of the operational risk profile in a manner that is more efficient and leads to improved decision making.

The following graphic and accompanying explanatory text provides an overview of the IRCS framework of the Allianz Group.

ALZ.0001.0097.3443


1. Single harmonized IRCS framework established for the Allianz Group

One common framework is established by the 2nd

Line of Defense and other governance-oriented functions of Allianz SE (e.g. Group Operations Safeguarding, IT Risk & IT Security). The framework aligns Group requirements with respect to roles and responsibilities, timelines, scoping and risk assessment methodologies, control testing, the management of ICS weaknesses, documentation and reporting.

2. Integrated local scoping covering all types of operational risks

An integrated local scoping process is performed starting with a Group IRCS Catalogue in order to identify all significant operational risks faced by the OE. The IRCS Catalogue contains a list of the most common operational risks faced by a typical insurance entity, broken down by reporting risks, compliance risks and other operational risks (e.g. legal risks, IT risks). The scoping process also takes into account internal and external audit findings related to effectiveness of the ICS.

ALZ.0001.0097.3444


3. Mapping of significant operational risks to OE functions and internal and external service providers

The significant operational risks identified during local scoping are individually mapped to the respective business processes or service providers most likely to trigger an occurrence of the risk and/or a significant impact, which thereby identifies where it is most critical that effective internal controls are in place.

4. Integrated assessments performed by business function or process

Based on the scoping and mapping of risks to OE functions and service providers, workshops with the business are arranged and facilitated by the 2

ndLine of Defense functions. In the

context of an integrated approach the objective is to 1.) engage in cross-functional discussionsthat cover all of the operational risks of a given business area (e.g. function or process oriented) – 2.) while applying a singular approach towards assessing the significance of risks and the effectiveness of their current control environments, and 3.) for deciding upon whether improved management of certain risks is necessary.

5. IRCS results recorded in single system

IRCS results are recorded in a single Group-wide platform – the Operational Risk and Governance System (ORGS). This integrated system ensures all relevant stakeholders at the local level are able to easily access necessary information concerning their OE’s ICS, while also enabling central Group monitoring of the effectiveness of the ICS for the Allianz Group as a whole.

6. Harmonized ICS reporting to management

Harmonized ICS reports based on the outcome of the IRCS are provided to the Board of Management, Audit Committee and other appropriate management level bodies at both the OE and Allianz Group level. These reports are integrated in the sense that they cover the ICS for all operational risk types (e.g. reporting, compliance, IT) based on the input of all relevant 2nd

Line of Defense and other governance-oriented functions.

B.II IRCS PRINCIPLES

The following principles shall be observed throughout performance of the IRCS process.

1. Primary IRCS objective

The primary objective of the IRCS is to ensure that effective controls or other risk mitigation activities are in place for all significant operational risks.

Operational risks are present in essentially all of the processes and activities undertaken by OEs and may be broadly classified based on frequency and impact:

The primary responsibility for the identification and mitigation of operational risks, as well as for assessing whether mitigating controls are effectively designed and operating, resides with the

High FrequencyLow Impact

Not Applicable

Low FrequencyHigh Impact

Impact

Fre

qu

en

cy

ALZ.0001.0097.3445


risk and process owners of the business. In discharging these responsibilities, however, there are a number of considerations based on the nature of frequency and impact.

Low-Frequency, Low Impact: These operational risks are of no material significance on either an individual or cumulative loss impact basis and therefore not usually worth the cost and effort attributable to actively managing them.

High-Frequency, Low Impact: Given that these operational risks occur with a high degree of frequency there is typically a strong awareness of the risks combined with a regular and timely feedback loop on the effectiveness of controls and other risk mitigation activities. As such, risk and process owners tend to naturally move toward an optimization of operational loss reduction versus costs of further risk mitigation in order to minimize cumulative impacts. The primary exception to this rule is for Compliance risks, where a high frequency of Compliance breaches may not result in an impact until a point in time when they are detected.

Low-Frequency, High Impact: Although these operational risks do not occur frequently, their high impact means they are responsible for a relatively large share of total operational losses. Furthermore, these risks may be inadequately managed by risk and process owners due to:

A failure to identify the risk. Risk and process owners may not have any past experience with a given risk and therefore fail to identify it. Alternatively, risk and process owners may fail to recognize how internal or external changes have influenced the potential frequency or impact of a risk.

Insufficient incentives to manage the risk. Given the relatively low frequency and unpredictability of the risk, risk and process owners have little incentive to invest in further risk mitigation with an unknown, or potentially non-existent, return period. This weak incentive is combined with minimal feedback on the effectiveness of existing risk mitigation activities, if any, provided by internal loss events, further undermining risk management incentives.

Given the nature of low-frequency, high impact risks, it is necessary for an independent risk oversight function to establish a process by which they can ensure these risks are being adequately managed. For the Allianz Group, this process is the IRCS.

2. The IRCS follows a risk-based approach

The IRCS follows a risk-based approach to scoping in order to maximize the efficiency of utilized resources.

The IRCS has two general phases; the first phase is an initial implementation period, which is then followed by a second phase of annual updates. During the implementation phase the entirety of the OE’s processes are taken into consideration in order to identify where significantoperational risks might occur. Once these areas are identified both a control environment assessment and actual risk assessment are conducted.

Upon completion of the implementation phase a second phase of annual updates begins. The basis for this phase is the theory that, in the absence of any change, the results of the control environment and actual risk assessments should also remain unchanged. In reality, however, there is constant change taking place within an OE, as well as the occurrence of external events, that influence the operational risk profile and cause it to deviate from its previously assessed state (e.g. the introduction of new products, new systems or other similar projects, changes in laws or regulations, etc.). As such, the focus of the IRCS subsequent to the implementation phase is on identifying where such changes have occurred and ensuring that, in comparison to the most recent assessment, the associated risks are still mitigated to within implied risk tolerance thresholds.

The effect of this approach is that each annual IRCS cycle does not repeatedly focus on an assessment of, for example, the 100 operational risks with the largest potential financial impact, but is dynamic from year-to-year. This flexibility allows for a more efficient and targeted use of resources during performance of the IRCS.

ALZ.0001.0097.3446


3. A standard IRCS Catalogue helps ensure significant operational risks are identified and managed

A standard IRCS Catalogue established and maintained by Group Risk, in cooperation with other relevant Allianz SE functions, contains a list of risks to support OEs with the identification of their significant operational risks.

Although local differences in the operational risk profile of OEs certainly exist, there is also much overlap in operational risks faced by OEs across the Allianz Group. In order to support OEs with their local identification of significant operational risks and to ensure that risks are not overlooked a list of typical operational risks is provided in the form of a standardized Group IRCS Catalogue.

Beyond providing a list of typical operational risks, the IRCS Catalogue also establishes a Group-wide operational risk taxonomy. This shared risk taxonomy enables the aggregation of OE IRCS results for purposes of forming a view on the operational risk profile and effectiveness of the ICS for the Allianz Group as a whole.

4. Key control testing is an integral part of the IRCS

A circular feedback loop exists between the results of the control environment and actual risk assessments and the results of internal control testing.

Key control testing is one of the most important elements of ensuring an effective system of operational risk management. Although having controls in place is of utmost importance, there is no substitute for periodic control testing in order to ensure that key controls are located at the correct points in processes, are properly designed to mitigate the intended risks, and are effectively operating as designed.

The results of key control testing are an important input into the control environment assessment for each in-scope risk of the IRCS. Simultaneously, the results of the control environment assessment and actual risks assessments are used to help determine where control testing should be performed. In effect this is a two-way relationship, where both activities are dependent on steering each other.

5. Internal and external loss data supports the IRCS

OE and Allianz internal operational risk event data, as well as external loss data, support the identification and assessment of operational risk and control effectiveness.

Information regarding actual operational risk related losses, gains and near-misses that have occurred is recorded via the operational risk event capture process (OREC).2 This information is used to support and corroborate the identification and assessment of risks during the IRCSprocess, as well as the assessment of control effectiveness.

Where internal loss data alone is insufficient, reliance on external loss data should also be utilized for purposes of OE risk identification and assessment (i.e. loss data from other Allianz OEs as well as loss data from financial service companies outside the Allianz Group). When using external loss data professional judgment must be applied to bring it into an appropriate context for the OE.

6. IRCS supports the Scenario Analysis

Results of the RCSA support performance of the Scenario Analysis3, including the determination of Level 2 Risk Categories to be modelled and their corresponding parameters.

2

Refer to the Operational Risk Event Capture Guideline (ORECG)3

Only applicable to OEs within the scope of the Group internal model. Refer to the Allianz Guideline for Operational Risk Scenario Analysis (ScAG)

ALZ.0001.0097.3447


As an integral part of the Scenario Analysis, Risk Heatmaps aggregate information from various sources to identify which Level 2 Risk Categories should be represented in the calculation of operational risk capital. IRCS results are used as an input to the Risk Heatmaps and assist in the determination of specific parameters for the level 2 Risk Categories to be modelled. This determination may be performed on a purely qualitative basis or through a combination of qualitative and quantitative approaches.

7. IRCS supports the Top Risk Assessment

The IRCS is the key input towards the identification and assessment of operational risks within the Top Risk Assessment

4process.

Operational risks identified and assessed during the IRCS serve as the source of operational risk candidates for inclusion in the scope of the Top Risk Assessment. Despite this strong linkage and similarities in the execution of the processes (e.g. workshop based, qualitative assessment), there are distinct differences between the IRCS and Top Risk Assessmentprocesses.

Scope of risk categories: The Top Risk Assessment covers all risk categories, whereas the IRCS focuses exclusively on operational risks.

Scope threshold: The Top Risk Assessment scope is considered to be restricted by number of risks (e.g. 10-30), which is consistent with the intent to focus exclusively on the largest risks facing the OE. The IRCS, on the other hand, faces no such restrictions and presumably has a lower materiality threshold for scoping, resulting in a larger number of operational risks covered by the IRCS versus the Top Risk Assessment.

Risk management: The Top Risk Assessment primarily acts as a supplementary risk management process, building upon existing risk management processes in place for each risk category to identify a single set of overarching top risks. In contrast, the IRCSis the primary process for 2

ndLine of Defense oversight of the management of operational

risks. Risk ownership: Risks within the scope of the Top Risk Assessment must be owned by a

member of the board of management, whereas risks within the scope of the IRCS may be owned by management at a lower level of authority.

Risk assessment: The Top Risk Assessment considers lost business opportunities or future revenues when assessing risks since these are considered key elements of steering strategic business decisions. The IRCS does not consider these types of impacts within the risk assessment.

8. Operational risk tolerance is established by a risk response

Explicit risk tolerance thresholds are not established for each in-scope risk, but rather implied based on a chosen risk response.

For risks in-scope of the IRCS an implied risk tolerance is achieved by either accepting a risk as sufficiently mitigated based on effectiveness of the current control environment or electing to reduce the actual risk level through additional mitigation activities. For compliance risks, the risk tolerance decision is additionally driven by application of the Risk and Maturity Matrix. When a risk is accepted it is implied that the risk is currently managed to within the risk tolerance threshold – and vice versa when a risk is not accepted.

9. OE IRCS results steer Group-wide activity and enable a conclusion on Allianz Group ICS effectiveness

The IRCS results of individual OEs are used by the Allianz Group to help steer Group-wide initiatives related to operational risk management and to conclude on the effectiveness of the ICS for the Allianz Group as a whole.

Through analysis of OE IRCS results Group Risk, together with other relevant Allianz SE functions, is able to identify areas where further initiatives related to operational risk

4

Refer to the Allianz Standard for Top Risk Assessment (ASTRA)

ALZ.0001.0097.3448


management would be beneficial for the Group as a whole. Such initiatives include, but are not limited to:

Establishing on a one-off basis a Group-wide, deep-dive analysis or assessment of specific operational risks or controls for purposes of determining whether further steering action is desired;

Establishing common areas of potential control improvement where the Group should generate or facilitate the sharing of best-practices;

Identifying and sharing with OEs any inconsistencies between OE IRCS results that might indicate unidentified operational risks at the OE level.

Group-wide implementation of the IRCS furthermore supports fulfillment of regulatory requirements. In particular, these requirements call for:

A consistent implementation of the ICS across all OEs of the Allianz Group; and A periodic conclusion by Allianz SE on ICS effectiveness for the Allianz Group as a

whole.

ALZ.0001.0097.3449


C. IRCS PROCESS REQUIREMENTS

The various steps of the IRCS process may be categorized into three phases: the scoping phase, RCSA workshops phase and post (RCSA) workshop activities phase. Minimum requirements for the process activities within these phases are defined throughout the remainder of this section.

All of the IRCS process requirements described in this document must be performed at least

once per year, however, according to the risk-based approach principle it is not necessary that

every activity be performed every year for each in-scope risk and control.

The precise timing of the IRCS process is at the discretion of each OE subject to observation of

the following constraints:

Mid-February: Group deadline for documenting the outcome of the prior year-IRCS cycle in ORGS (e.g. risk assessment, control testing, action plans, etc.). See section 0Documentation

Late Q1 or early Q2: Group issuance of IRCS Catalogue for the current year IRCS cycle. See section C.I Scoping.

Late Q1 or early Q2: Group issuance of OE Scoping Templates for Reporting Risks. See section C.I.1.1 Group Generation of OE Scoping Templates.

C.I SCOPING

The objective of the scoping process is to identify all operational risks that may:

significantly impact the reliability of reporting;

significantly impact compliance with laws and regulations;

significantly impact the company reputation; or

result in a large financial loss or an adverse movement in the solvency position.

The basis for the scoping exercise shall be the Allianz Group IRCS Catalogue, which the Group

will provide to OEs each year in late Q1 or early Q2. The IRCS Catalogue contains a long list of

risks typically faced by OEs, broken down into the risk types of Reporting risks, Compliance

risks and Other Operational risks.

The long list of risks must be reduced to a short list of in-scope risks following an approach that

varies by risk type. These approaches are elaborated on in the following sections.

The short list of risks identified through the scoping process are referred to as “in-scope” 5 of the

IRCS and are subject to the IRCS processes described in sections C.II to 0.

5

In this context risks that are not “in-scope” does not mean the risks are not applicable or do not need to be managed by the OE. “In-scope” is interpreted to mean the risks are subject to the IRCS requirements established throughout the remainder of this Guideline.

ALZ.0001.0097.3450


Scoping Coverage

The entity coverage scope must be established prior to IRCS roll-out following alignment

between the Group and local Risk and Compliance functions – and in principle must cover the

operational risks of all legal entities comprising the OE. In general, unless a legal entity specific

scoping and risk assessment is explicitly required by law, the process may be performed at the

OE level. Each OE shall decide on the appropriate level of their organization to perform the

scoping while taking into account:

Whether a given legal entity has operative business and staff or is, for example, a pure holding entity;

The extent to which a given legal entity shares business processes with other legal entities comprising the OE;

The extent to which risk frequency, risk impact or key controls vary significantly between legal entities, even in cases where they share underlying processes.

The decision flowchart included as Appendix C shall be used to support determination of the

appropriate level for scoping based on the above considerations.

C.I.1 Scoping of Reporting Risks

The scoping of reporting risks must be conducted by Group Risk and the local risk and/or

finance function in accordance with the following four steps:

I.1.1 Group Generation of OE Scoping Templates

Note: the following process activities are performed centrally by Group Risk. No OE activities

are required.

On an annual basis in late Q1 or early Q2 Group Risk shall perform a central scoping exercise

to determine which account groups must be in scope for each OE. This determination is made

on the basis of obtaining adequate assurance that the Group IFRS financial statements and

Group MVBS are free of material misstatements.

The central scoping exercise shall consist of the following steps and result in Group Risk’s

generation of individual OE Scoping Templates.

ALZ.0001.0097.3451

1. Identify significant accounts

All individual accounts exceeding 3.75% of income before taxes at the consolidation unit level must be identified ("significant accounts"). In the event that income before taxes is negative or relatively small in comparison to the overall financial significance of the consolidation unit, an alternative threshold must be agreed upon between Group Risk and the impacted OE (e.g. 0.5% of gross written premiums).

2. Map each significant account to an account group

Each significant account must be assigned to an account group. Account groups should reflect how accounts are combined and presented within (IFRS) financial statements and accompanying disclosures.

3. Determine classes of transactions for each account group

Applicable classes of transactions must be determined for each account group. A class of transactions is a broadly defined accounting activity - representing one or more processes -that results in accounting entries impacting some or all accounts within a given account group.

4. Map classes of transactions to financial assertions

ALZ.0001 .0097.3452

Each class of transactions must be mapped to relevant financial assertions. Financial assertions provide an indication of where the accounts underlying each class of transactions are most susceptible to a misstatement.

Assertion Description

Existence or Assets or liabilities of the company exist at a given date and recorded transactions have occurrence occurred during a given period. In other Yo.Qrds, transactions are valid transactions of the

company.

Completeness All transactions and accounts that should be presented in the financial statements are included.

Valuation or Asset, liability, equity, revenue, and expense components have been included in the financial allocation statements at appropriate amounts. In other Yo.Qrds, transaction amounts are accurately

recorded and reported.

Rightsand Assets are the rights of the company and liabilities are obligations of the company at a given obligations date. In other Yo.Qrds, transactions are appropriately classified as assets and liabilities.

Presentation Particular components of the financial statements are properly described and disclosed as and disclosure required under IFRS / local GAAP.

5. Generation of OE Scoping Templates

For each OE that has at least one or more account groups in-scope per the central scoping exercise Group Risk must prepare an OE Scoping Template. Based on the above steps the OE Scoping Templates will be pre-populated with the account groups, classes of transactions and financial statement assertions relevant to the OE.

The OE Scoping Templates will be provided to OEs via email in late 0 1 or early Q2 of each year. If an OE does not have any in-scope account groups resulting from the Group Risk scoping exercise they will be correspondingly notified of this.

1.1.2 Identify significant classes of transactions


ALZ.0001 .0097.3453

For each OE receiving an OE Scoping Template the identified classes of transactions - or alternatively account groups - must be reduced to significant classes of transactions ("SCOTs") based on a qualitative analysis. A SCOT is a class of transactions that:

• is financially significant enough to trigger a material misstatement, and • has characteristics that make it relatively susceptible to triggering a significant

misstatement

The qualitative analysis used to identify SCOTs must consider the following factors. All qualitative criteria for the identification of SCOTs are included as filters in the OE Scoping Template.

Criteria Low Risk High Risk

Composition of Homogenous transactions, relatively Non-homogenous transactions, relatively low account high number of small value transactions number of high value transactions

Complexity of Relatively straightforward transaction Relatively complex transaction with many transaction with few processing steps between processing steps between initial transaction to

initial transaction to corresponding corresponding accounting entry accounting entry

Complexity of Simple accounting treatment, no Complex accounting treatment, requires accounting application of estimates or professional application of professional judgment and treatment judgment management estimates

Manual vs. Accounting entries based on interfaces Accounting entries are manually entered automated to other systems (e.g. claims payments,

processing premium collections)

Other risk factors Stable underlying process and systems, New processes or systems, recent changes in no evidence of control weaknesses (e.g. accounting treatment, evidence of control operational losses, audit findings) weaknesses

Other scoping No special requests to include in scope Requested to be included in scope per Group aspects scoping instructions or local parties (i.e. local

internal audit, external audit, risk, or finance departments)

Following professional judgment, classes of transactions that are material enough to trigger a significant misstatement, but are otherwise classified as low-risk. do not need to be considered SCOTs. However, as the accounts underlying a class of transactions become increasingly material (i.e. as a percent share of income before taxes), the significance of qualitative criteria towards deciding that a class of transactions is not a SCOT should be deemphasized.

In addition to the above, OEs may consider whether additional classes of transactions not included in the OE Scoping Template should be classified as SCOTs based on local judgment.

1.1.3 Ident ify in-scope risks for each s ignificant c lass of transactions

The risks that could trigger a significant misstatement must be identified for each SCOT, taking into account each SCOT's financial statement assertions. The most common risks are prepopulated in the IRCS Catalogue. If in-scope risks are identified that are not included in the Group-issued IRCS Catalogue the OE may add these to a localized version of the IRCS Catalogue.

1.1.4 Map in-scope risks to the Allianz Operating Model

Each in-scope risk must be mapped to the respective Allianz Operating Model (sub-)function where the risk could occur and corresponding risk owners identified. For risks that could occur in more than one (sub-)function ("transversal risks") professional judgment should be applied to determine all of the (sub-)functions where the risk might trigger a significant misstatement. A



suggested mapping of reporting risks to Allianz Operating Model (sub-)functions is pre-

populated into the IRCS Catalogue.

C.I.2 Scoping of Compliance Risks

The scoping of compliance risks must be conducted by the OE Compliance Function in

accordance with the following six steps:

I.2.1 Identify applicable Compliance risks

All Compliance risks the OE is exposed to must be identified, irrespective of the potential

materiality of the risk. The IRCS Catalogue is pre-populated with the typical Compliance risks

facing OEs. If Compliance risks are identified that are not included in the Group-issued IRCS

Catalogue OEs must add these to a localized version of the IRCS Catalogue following the risk

taxonomy used in the Group IRCS Catalogue.

I.2.2 Perform inherent risk assessment

All applicable compliance risks identified in Step 1 must be subject to an inherent risk

assessment following the methodology outlined in Appendix A.

The inherent risk assessment generates an overall inherent risk score for each risk of 1 (low) to

5 (very high) based on an assessment of each of the following:

occurrence probability rated on a 1-5 scale most likely financial impact rated on a 1-5 scale (inherent) reputational impact rated on a 1-5 scale

When conducting the inherent risk assessment OEs shall assume that internal controls are not

in place or have otherwise failed.

I.2.3 Perform Program Maturity assessment

A Program Maturity assessment must be performed by all OEs for all Compliance programs that

address the applicable risks identified in Step 1. An individual Program Maturity assessment

must be performed for all entities which submit a risk assessment. The Program Maturity

assessment is an assessment of the design and implementation status of each relevant Group

ALZ.0001.0097.3454


Compliance Program including Compliance Organization, the latter which is mandatory for all

OEs.

For each Group Compliance Program the Program Maturity assessment provides an overall

maturity score between 1 (ad hoc/initial) to 5 (optimized). The assessment is structured along

the five elements of each Compliance Program including Risk Assessment and Gap Analysis,

Policies and Procedures, Roles and Responsibilities, Awareness and Training, Monitoring,

Incidents and Reporting, which carry different weights towards the final assessment. The

Defined Level 3 Descriptions list the requirements of each Group Compliance Program.

The final Program Maturity score is plotted into a Risk & Maturity Matrix together with the

inherent risk assessment (taking the highest risk score for that level 1 risk) in order to generate

a risk-based view of the status of the Compliance Program and determine which programs

require further mitigation efforts.

I.2.4 Identify short-list of Compliance risks

The short list of Compliance risks with an overall inherent risk score of 3 or higher must be

discussed at the beginning of the RCSA workshops to determine whether they should also be

included in the final list of in-scope risks. All Compliance risks with an overall inherent risk score

of 4 or higher must be included in the final list of in-scope risks (see section C.II.2.1).

I.2.5 Map short list of Compliance risks to the Allianz Operating Model

Each in-scope Compliance risk, as well as risks with an overall inherent risks core of 3, must be

mapped to at least one respective Allianz Operating Model (sub-)function where the risk could

occur and corresponding risk owners identified. For Compliance risks that could occur in more

than one (sub-)function (“transversal risks”) professional judgment should be applied to

determine all of the (sub-)functions where the compliance risk might trigger a significant

Compliance failure. All Allianz Operating Model sub-functions are pre-populated into the IRCS

Catalogue.

I.2.6 Submit scoping results for expert challenge

An Expert challenge must be conducted with Group Compliance or the Compliance Standards

Committee member responsible for the respective OE and shall focus on the risk scoping, the

inherent risk assessment of the applicable risks, the Program Maturity rating of the applicable

Compliance Program, the Allianz Operating Model mapping and the Risk & Maturity Matrix

including any preliminary action plans arising out of the Risk & Maturity Matrix. Group

Compliance provides input to the CSC members in order to prepare them for the Expert

Challenge.

C.I.3 Scoping of Other Operational Risks

ALZ.0001.0097.3455


The scoping of other operational risks must be conducted by the OE Risk Function in

consultation with, where appropriate, other risk experts. The scoping must be performed in

accordance with the following two steps:

I.3.1 Identify in-scope other operational risks

In-scope risks must include all significant operational risks identified on an inherent risk basis.

As a starting point, significant operational risks should be roughly identified as those risks with

the potential to result in an operational loss, or trigger an economic loss in another risk category

(e.g. market risk, liquidity risk), that exceeds 3% of mid-term operating profit.6

In addition to materiality thresholds the following factors should also be considered during

scoping:

Group requirements or local regulatory requirements to have controls in place for certain risks (e.g. risk capital calculation, data quality)7; and

potential of the risk to have a significant reputational impact.

If in-scope risks are identified that are not included in the Group-issued IRCS Catalogue the OE

may add these to a localized version of the IRCS Catalogue.

I.3.2 Map in-scope other operational risks to the Allianz Operating Model

Each in-scope other operational risk must be mapped to the respective Allianz Operating Model

(sub-)function where the risk could occur and corresponding risk owners identified. For other

operational risks that could occur in more than one (sub-)function (“transversal risks”)

professional judgment should be applied to determine all of the (sub-)functions where the other

operational risk might trigger a significant operational loss. All Allianz Operating Model sub-

functions are pre-populated into the IRCS Catalogue.

C.II RISK AND CONTROL SELF ASSESSMENTS

The objective of the Risk and Control Self Assessments (RCSA) is to engage risk owners and

risk experts in the validation and assessment of all in-scope risks in order to form an opinion of

whether the existing control environment for these risks is sufficient.

The OE Risk Function, together with the support of other key functions as appropriate (e.g.

Compliance, Accounting), is responsible for organizing and facilitating the RCSA. This includes:

determining the number, nature and composition of RCSA workshops; scheduling the RCSA workshops; explaining to risk owners and risk experts their role in the IRCS and the requirements

they are responsible for fulfilling; supporting risk owners and risk experts with their risk assessments by gathering,

compiling and analyzing assessment relevant data prior to RCSA workshops; and

6

Based on the inherent risk impact, that is, without consideration of effectiveness of the existing control environment.7

The IRCS Catalogue indicates those risks that must be in-scope based on Group requirements (“mandatory risks”). If a

mandatory risk is not applicable the OE must consult with Group Risk prior to removing the mandatory risk from scope (“comply

or explain”).

ALZ.0001.0097.3456


challenging risk owners and risk experts in case of disagreement regarding in-scope risks, risk assessment results, determination of key controls or risk response.

C.II.1 Preparing for RCSA Workshops

II.1.1 Plan workshops

Workshop planning consists of identifying the number, nature and composition of RCSA

workshops required to cover all of the Allianz Operating Model (sub-)functions mapped to one or

more in-scope risks. The following should be considered:

number and nature: workshops should be organized at a level (e.g. function, department, process) detailed enough to effectively meet workshop objectives, but also broad enough to efficiently limit the total number of workshops; and

composition: besides the risk owner or risk expert, it should be considered what other stakeholders should be included in each workshop in order to ensure a quality workshop result (e.g. Compliance, IT security, data privacy officer)

Once the number, nature and composition of the workshops are defined the OE Risk Function is

responsible, together with the IRCS Officer, for scheduling the workshops with participants.

II.1.2 Gather data to support assessment

In order to support risk expert performance of the control environment effectiveness and actual

risk assessments described within section C.II.2.3 relevant data should be gathered, compiled

and analyzed in advance of the RCSA workshops. Such data should include, for example:

Internal and external operational loss events; Results of most recent control testing; Results provided by the Compliance and Risk Maturity matrix (for Compliance risks); Results of internal audits; and Results of third-party audits or reviews (e.g. external auditors, consultants or regulators).

The objective of data gathering is to generate a factual basis that can be used by risk owners

and risk experts as a starting point for the assessments. In addition data should also be used,

as appropriate, by the OE Risk and Compliance Functions to challenge the results of risk owner

and risk expert assessments. For Compliance risks and other operational risks a particular

emphasis should be placed on data supporting determination of the 1-in-20 Year impact as this

is typically the most challenging assessment dimension.

The data gathering for Compliance risks shall be performed by the OE Compliance Function,

while the data gathering for reporting risks and other operational risks shall be performed by the

OE Risk Function with support of other relevant subject matter experts.

ALZ.0001.0097.3457


C.II.2 Conducting RCSA Workshops

II.2.1 Validate risks in scope

The list of in-scope risks identified during the scoping phase should be validated with the corresponding risk owners and risk experts. In particular, it is important that risk owners and risk experts confirm:

the in-scope risks exist within their area of responsibility / they are the correct risk owners and risk experts8

the in-scope risks include all significant operational risks

If it is determined that significant operational risks are missing – or insignificant operational risks are included – the list of in-scope risks should be adjusted as appropriate.

In addition, specific to Compliance risks assessed during the scoping phase as having an overall inherent risk rating of 3, it shall be discussed whether the Compliance risks are significant enough to be considered in-scope for the IRCS. If they are considered significant they must be added to the list of in-scope risks and subjected to all IRCS requirements contained in this Guideline.

II.2.2 Identify key controls

Key controls must be identified for each in-scope risk by the corresponding risk owners and risk

experts. At a minimum, the single most critical control for each in-scope risk must be

considered a key control. However, depending on the importance of other controls towards

mitigating a given risk, risk owners and risk experts may identify more than one key control.

For some risks illustrative key controls have been defined by the Group (e.g. for Compliance

risks) and may be used as appropriate for the identification of key controls.

II.2.3 Perform assessments

All in-scope risks must be subject to a control environment effectiveness assessment and actual

risk assessment. Risk owners are responsible for deciding upon the assessments related to

their in-scope risks, however they should be supported with assessment performance by risk

experts and the risk and Compliance functions.

Assessment of each in-scope risk consists of up to three different assessment dimensions. The

exact number of required dimensions is dependent upon the operational risk type, as

established in the following table:

8

Ownership of the risk does not necessarily mean ownership of the controls in place to mitigate the risk

ALZ.0001.0097.3458

Required Assessment Dimensions by Operational Risk Type

Assessment Description of Assessment

••• Dimension Dimension

Control The effectiveness of the overall control x x Environment environment related to the risk. Rated Effectiveness on a scale from 1-5.

1-in-20 Year The largest expected operational loss x Impact over a 20 year period from a single occurrence of the given risk. Assessed as a specific value.

Reputational The expected, or typical, reputational x Impact consequences should the given risk occur. Rated on a scale from 1-5.

•For nsk capital calculation nsks only a control environment assessment is reqwred

The assessment of each required dimension must follow the methodology outlined in Appendix A.

11.2.4 Determine risk response

x

x

x

A risk response must be established for each in-scope risk. In effect, the risk response indicates whether the currently existing control environment sufficiently manages the given inscope risk to a desired tolerance level.

ALZ.0001.0097.3459

It is the responsibility of the risk owner to decide upon a risk response, however this decision may be challenged and escalated by the local risk function based on their risk oversight role. The one exception to this approach is the establishment of risk responses for Compliance risks. which are pre-determined based on the outcome of the inherent risk assessment and Program Maturitv assessment and reflected in the Risk and Maturity Matrix.

The options for responding to assessed risks are typically to either accept the risk as adequately mitigated or to take further action to reduce the occurrence probability and/or impact through a strengthening of the control environment.9

The following factors should be considered when establishing a risk response:

• the cost-benefit trade-off, whereby the expected reduction in operational losses should typically exceed the associated cost of strengthening the control environment; and

• compliance with laws and regulations or the potential impact of a given operational risk event on the Allianz Group reputation and other strategic priorities, such as the realization of business opportunities, in which case a positive cost-benefit trade-off based on a pure measurement of operational losses is not appropriate.

If a risk response of mitigate is selected a corresponding Issue must be created in accordance with the requirements at section 0.

9 . . . . Less common responses to assessed nsks, but not less acceptable, include transfemng nsk through, for example, the use of

insurance, or avoiding risk by ceasing performance of the associated activities that are the source of the risk itself.


ALZ.0001.0097.3460

C.111 KEY CONTROL TESTING

Scoping

·~====~ •---~

Test plannng - Test execution

0 ~~~~~~~~

0

The objective of key control testing is to ensure that the most important controls for mitigation of significant operational risks are effectively designed and operating. In this respect key controls do not only consist of control activities within a specific process ("process level controls"), but also Entity Level Controls and IT General Controls. All three of these key control types must be subject to testing and any identified deficiencies in control effectiveness must be documented and subject to a remediation plan.

C.111.1 Test Planning

A risk-based approach shall be applied in the planning and performance of control testing. In effect, this means considering the amount and quality of available testing resources when determining the order controls are tested, how frequently they are tested and who shall perform the testing.

A comprehensive test plan for all key controls subject to testing must be in place and regularly updated. For each key control the test plan should establish a testing schedule I testing frequency and who is responsible for test performance. Consistent with a risk-based approach, the test plan must be dynamic and allow for a re-prioritization based on changes in the operational risk profile or emerging evidence regarding the effectiveness of key controls (e.g. operational losses).

The OE Risk Function is responsible for maintaining and coordinating the test plan in consultation with other relevant stakeholders (e.g. Compliance, Audit, Actuarial, Accounting).

111.1.1 Identification of key contro ls subject to testing

The identification of key controls subject to testing depends on the key control type, as outlined in the following table.

~:~eControl Description Method of Identification

Entity Level Controls

Controls corresponding to key elements of the system of governance.

Supports establishment of the foundation for an effective ICS environment.

Integrated Risk and Control System Guideline -v1.0, 24.04.2017

A standard set of Entity Level Controls is established by Group Risk and must be applied, subject to appropriate local adjustments, by all OEs. Refer to section C.V/11.2.

A complete list of Entity Level Controls may be

found within ORGS or on Allianz Connect Ul!]JS penaing]

21


IT General Controls

Controls centered on the IT control

environment, IT access & authorization, IT

change management, IT project management

and IT operations.

Supports establishment and execution of

business objectives, policies and decisions

regarding the execution of the IT strategy, as

well as reliance on application controls that are

applied around specific business activities and

performed within IT applications.

Based on control objectives of the COBIT 5.0

framework issued by the Information Systems

Audit and Control Association (ISACA).

IT General Controls are determined based on:

The identification of significant applications

Consideration of which corresponding

control objectives of the COBIT 5.0

framework should be met to sufficiently

reduce risks related to significant

applications

Implementation of controls (i.e. “IT General

Controls”) that ensure achievement of the

COBIT 5 control objectives identified in the

previous step

Refer to section C.VIII.2. A list of illustrative IT

General Controls may be found within ORGS

or on Allianz Connect [link pending]

Process Level Controls

Controls embedded directly within business processes in order to prevent or detect the occurrence of a risk.

Key process level controls are identified by risk

owners and risk experts during performance of

the RCSA workshops. Refer to section

C.II.2.2.

III.1.2 Frequency of control testing

The testing frequency for each key control shall follow a risk-based approach.

The risk-based approach entails identifying which controls to test during any given IRCS cycle

based on indicators that controls may not be effective, as well as other risk-based

considerations. These include, but are not limited to:

the occurrence of operational losses or near misses; control weaknesses identified by internal audit or through other third-party audits or

reviews; changes in control design or underlying processes; the new implementation or upgrade of IT systems; changes in corresponding laws and regulations; changes in control performers; and complexity of the control and the length of time since the last control testing took place.

Overarching to these risk-based considerations is the significance of the operational risk the key

control mitigates, whereby the more significant the risk the more frequent testing of the

associated key controls should occur.

Irrespective of the risk-based approach, all key controls must be tested at least once every five

years. In addition, on an annual basis Group Risk may, in collaboration with other Allianz SE

functions, provide OEs with a list of areas that must be tested during the current IRCS cycle.

III.1.3 Eligible control testers

Any individual with adequate knowledge of control testing methodology and the business areas

they intend to test qualifies as an eligible control tester. The only exception is a control tester

must never be responsible for testing controls they personally perform.

When selecting testers OEs should consider the control testing experience and independence

of each control tester relative to the importance of the key controls they will test – higher quality

testing resources should be allocated to the testing of critical controls or controls suspected of

ALZ.0001.0097.3461


being deficient.10

For Entity Level Controls and IT General Controls only testers with a high

level of independence are allowed due the importance of these controls.

The following table summarizes the level of independence and qualification for eligible control

testers as well as which testers are allowed to test which key control types.

C.III.2 Test Performance

The following requirements must be observed with respect to the nature and extent of control

testing and the identification of internal control deficiencies.

III.2.1 Test of design effectiveness vs. test of operating effectiveness

The overall effectiveness of each key control must be determined based on both a test of its design effectiveness and test of its operating effectiveness.

Test of Design (TOD) – an assessment of whether controls are appropriately designed to effectively mitigate the given root causes of the risk. Controls may be executed exactly as intended (i.e. effectively operating), but if the design of the control is flawed a deficiency in design effectiveness exists.

Test of Operating Effectiveness (TOE) – an assessment of whether controls are effectively operating as designed. Controls may be designed to effectively mitigate the intended risk scenario, but if the control activities are not performed in accordance with the design a deficiency in the operating effectiveness exists.

For the Test of Design it is sufficient to rely on discussions with the control owner and review of control descriptions to reach a conclusion on effectiveness. Each OE may apply local discretion to decide exactly how and at which point of the IRCS process they wish to perform the Test of Design. Typical approaches include during the RCSA workshop, during a dedicated end-to-end process walkthrough or simultaneously during the Test of Operating Effectiveness.

For the Test of Operating Effectiveness a more extensive review of control performance is required, which is elaborated on in the following section concerning the nature and extent of control testing.

III.2.2 Nature and extent

The testing techniques used to perform Tests of Design and Tests of Operating Effectiveness

are referred to as the nature of control testing. These techniques include, from low to high in

order of their relative level of assurance, inquiry, observation, inspection, system query and re-

performance.

10

In this context, the same risk-based considerations as described for frequency of control testing within section C.III.1.2

should be applied.

Entity Level

Controls

IT General

Controls

Process Level

Controls

Higher level of independence and qualification

External audit / assurance x x x

Internal audit x x x

2nd Line of Defense / control-l ke functions x x

Cross-functional 1st Line of Defense x

Intra-functional 1st Line of Defense x

Lower level of independence and qualification

Allowed testers by key control type

Eligible testers

ALZ.0001.0097.3462

ALZ.0001.0097.3463

Testing Description Example Technique

Inquiry Evidence is obtained based on interviews, Interviewing employees involved in the process discussions, comments, questions, etc. to obtain an understanding of the control between the tester and the control owner, operation and to identify where major changes control performer, process OYo.fler, supervisor, in the process flow, system infrastructure or etc. Essentially, inquiry includes any written or control environment may have occurred since verbal communication made to the tester that the last test relates to the control or process under Interviewing a control performer responsible for consideration. a reconciliation control to ask specific

Inquiry alone may be rel ied upon to test questions such as how often he or she

design effectiveness, but must be performs the reconciliation, what are the follow-

combined with other testing techniques to up actions for any reconciling items, etc.

test operating effectiveness.

Observation Evidence is obtained based on watching Watching a process owner perform control individuals perform process and control activities related to claims processing, whereby activities. a specific claim is observed from the time it is

filed by the insured to the time the claim is entered into the payment system.

Inspection Evidence is obtained based on examining Reviewing bank reconciliations to ensure that records or documentation that demonstrate the the reconciliations were performed in a timely performance of control activities. manner and that all material reconciling items

were resolved or substantiated.

System Query Evidence is obtained based on techniques Ensuring that an IT application prevents a designed to ensure that automated controls claims specialist from processing claims within an IT application are operating as exceeding their approved threshold by expected. inputting a claim amount above this threshold

into their system.

Re-performance Evidence is obtained based on re.performing a Re-performing a supervisors monitoring of task control and comparing the results of the re- checklists completed by staff to determine performance with the results originally obtained whether the supervisor's claim that all tasks by the control performer. per the task checklists were completed in a

timely manner is accurate.

The extent of control testing refers to the number of control performances required to be tested in order to conclude on the operating effectiveness (i.e. sample size). Controls with a lower frequency require a smaller sample size, however the smaller the sample size the more thoroughly each item should be tested for evidence of operating effectiveness. This is achieved by using more persuasive testing techniques. such as inspection and re-performance.

The following table outlines the extent of control testing based on the frequency of control performance.

Frequency of control performance Minimum required sample size for test of operating effectiveness

Manual control, performed many times Atleast25 per day (i.e. recurring manual control)

Manual control, performed daily At least 15

Manual control, performed frequently but 25% of the number of occurrences over prior 12 month period, up to a less than daily maximum of 15

Manual control, performed weekly At least 5

Manual control, performed monthly Atleast2

Manual control, performed quarterly Atleast2

Manual control, performed semi-annually At least 1

Manual control, performed annually At least 1

Integrated Risk and Control System Guideline -v1.0, 24.04.2017 24

ALZ.0001 .0097.3464

Automated control (application control) At least one application of each programmed control (assumes application controls operate in an environment where the specific configuration, interfaces and system access controls are appropriately designed and subject to appropriate change control procedures (i.e. effective IT General Controls).

In addition to the above table the following considerations should be taken into account when determining the extent of testing:

• Test samples should mostly be selected from the preceding 12 month period, however for controls with a low frequency of performance it is acceptable to also select test samples from earlier periods.

• The above sample sizes are minimums. Following a risk-based approach (e.g. new controls, modified controls or controls that have historically had deficiencies or exceptions). it should be considered whether it is prudent to increase the sample size beyond the minimum in order to increase the amount of evidence obtained that the control is operating effectively.

• In the event that an insufficient sample size is available (e.g. no transaction occurred). only a Test of Design is possible and no Test of Operating Effectiveness is necessary.

111.2.3 Identification of key control defic ienc ies

During the Tests of Design the evaluator may notice the following exceptions:

• the control is not properly designed to detect or prevent the risk identified in a timely manner;

• the control is not being performed at the appropriate level and/or by the appropriate individuals within the OE;

• the information used in performing the control activity is unreliable and/or inaccurate; • the scope of the control is inadequate to meet the control objective; • insufficient evidence of control performance exists to allow for the monitoring of control

performance; and • risks that are in-scope of the RCSA do not have any mitigating controls.

In these cases there is strong evidence that a design deficiency exists. The tester should rely on professional judgment to make a final decision.

When performing Tests of Operating Effectiveness the tester may discover exceptions from prescribed control policies or procedures. In these cases. the existence of an exception does not necessarily imply that a deficiency exists, especially in the case of daily controls or nonrecurring controls that are performed more than daily. In many cases a proper response to identified exceptions is to increase the sample size in order to obtain further evidence.

The following rules must be followed to support testers with the determination of whether a deficiency in operating effectiveness exists:

Frequency of control performance Minimum required sample size for test of operating effectiveness

Manual control, performed many times per day (i.e. recurring manual control)

Manual control, performed daily

Manual control, performed frequently but less than daily

A single exception is not evidence of a control deficiency. If a single exception is found the evaluator should select another full sample and test If one or more exceptions are found in the second full sample then a deficiency exists.

If t'MJ or more exceptions are identified in the first full sample then there is no option to test a second sample; a control deficiency exists.

Depending on the size of the population, a single exception does not always imply a deficiency exists. If the perfonmance of the nonrecurring control is less frequent than a recurring daily control and more frequent than a recurring weekly control the evaluator should use judgment in whether or not



a second full sample should be drawn and tested.

Two or more deficiencies in the first full sample or one or more deficiencies

in the second sample are evidence of a deficiency.

Manual control, performed weekly or

monthly

A single exception is strong evidence of a deficiency, however the evaluator

should apply professional judgment in analyzing the nature of the deficiency

to determine the extent of the impact of control failure. In exceptional

circumstances a second full sample may be drawn and tested.

Two or more deficiencies in the first full sample or one or more deficiencies

in the second sample are evidence of a deficiency.

Manual control, performed quarterly,

semi-annually or annually

A single exception is evidence of a deficiency.

Automated control (application control) Any exceptions are definitive evidence of a deficiency.

The above rules are only a starting point for assessing operating exceptions and are not meant

to replace the need for testers to exercise professional judgment. Testers should also consider

the following qualitative factors:

Why the control failed? Was there an extreme circumstance, such as a sudden illness, behind the control failure or was it due to the neglect or incompetence of the control performer?

How extensive was the control failure? Were most of the control activities performed and only one control step, such as the preparer’s sign-off, missing? Or were no control steps performed?

Is it plausible that the control failure was an isolated incident? What is the history of operating effectiveness of the control? What is the history of other controls performed within the process or by the control performer? What is the attitude, or “tone”, of the department towards internal controls in general?

Based on the above factors and, where appropriate an increased sample size, the tester must

determine whether the exception was an isolated incident and conclude that all other evidence

points to an effectively operating control. If the exception is not deemed to be an isolated

incident then a deficiency exists.

If a key control deficiency is identified a corresponding Issue must be created in accordance

with the requirements at section 0.

C.IV MONITORING

The objective of monitoring is to identify significant new operational risks, or significant changes

in the actual risk level of in-scope risks, that emerge between regular performance of the IRCS

scoping and RCSA processes.

A process must be in place to identify these changes in the operational risk profile and, where

necessary, address them in a timely manner. This requirement may be met by periodic (e.g.

quarterly) reviews of:

ALZ.0001.0097.3465


operational losses, internal audit findings and control testing results; significant internal changes in the business model or systems, such as new or modified

processes, outsourcing arrangements, IT systems or products; and external changes in the business environment, such as changes in laws and regulations.

C.IV.1 Key Risk Indicators

An important part of risk monitoring is the establishment and regular tracking of Key Risk

Indicators (KRI). KRIs must be established for the top 5-10 risks in-scope of the IRCS. In this

context the top 5-10 risks shall be identified according to the 1-in-20 year impact or reputational

impact11

. Established KRIs should meet the following criteria:

The indicator is estimated regularly; The indicator is measured in a timely manner; The indicator reflects risk drivers and root causes of the risk; The indicator warns of a change in the risk profile before the underlying risk event

becomes acute; The indicator uses thresholds to determine the point when follow-up actions are

necessary; and The set of KRIs an OE is monitoring should be composed of internal and external metrics

(business environment and internal factors)

To create a link between the Operational Risk Event Capture process12 and KRIs it is necessary

to focus on indicators which track changes in the risk profile or the effectiveness of the control

environment. An analysis of actual losses and near misses will assist in identifying which KRIs

are best at providing an early warning and allowing timely action. Annual reviews of the

indicators and their associated thresholds must take place to ensure they remain aligned with

the dynamic of the business environment and the significant operational risks faced by the OE

at any point in time.

If a KRI breach occurs a corresponding Issue must be created in accordance with the

requirements at section 0.

C.V ISSUE MANAGEMENT

The objective of issue management is to remediate identified weaknesses in the ICS. Although

these weaknesses are identified through various sources and processes, the approach for

classifying and remediating them is universal.

11

For Legal and Compliance risks (e.g. anti-trust, sanctions and embargoes) there are often no suitable internal KRIs that meet

the defined criteria. In such cases it is appropriate to identify external metrics to serve as KRIs.12

Refer to the Allianz Operational Risk Event Capture Guideline

ALZ.0001.0097.3466

ALZ.0001.0097.3467

C.V.1 Sources of Issues

The following table outlines the originating source and nature of issues.

Source of issue Nature of issue

Performance of RCSA, risk response A given risk is considered insufficiently mitigated by the current control of "mitigate" environment, taking into account the cost-benefit trade-off of further

mitigating the risk as well as potential impacts of the given risk on

(section C.11.2.4) compliance with laws and regulations, preservation of the OE's reputation or achievement of strategic priorities.

Performance of control testing , A deficiency in the design or operating effectiveness of a key control is identification of control deficiency identified based on the performance of control testing.

(section C.111.2.3)

Performance of monitoring, breach of Sudden changes in the operational risk profile require remediation actions Key Risk Indicator outside of the normal scoping and RCSA processes.

(section C.IV.1)

Operational risk event capture, large Occurrence of a large operational loss exceeding EUR 1,000,000 is operational loss indicative of a key control failure or other type of deficiency in the control

environment for a high impact risk.

(see section B.111.3 of the Operational Risk Event Gapture Guideline,)

Compliance assurance activities Issues are identified during performance of Compliance assurance activities such as maturity assessments, onsite reviews (conducted by Regions, Group and Global Lines), spot checks and internal investigations

Internal or external audit findings Issues in the control environment are identified based on findings from internal or external audits or reviews.

Note: this is not meant to be a formal recording of all audit findings in ORGS, but rather the recording of significant /CS weaknesses identified during the

course of audit worl< performed - and communicated by the audit function to 'Z'd Une of Defense functions through collaborative exchanges.

C.V.2 Classification of Issues

All identified issues must be classified as L 1-L4 based on the following table. All local issues will be further classified by Allianz SE as F1-F4 based on Group materiality I impact thresholds.

When classifying issues OEs must consider whether an aggregation of similar or related issues collectively represent a more severe ICS weakness than the individual issues taken in isolation. Where this is the case the OE should combine the individual issues into a single issue of higher severity on the L 1-L4 scale.



ALZ.0001.0097.3468

Rating on OE level Quantitative scale Qualitative scale

I Potential

I economic ICOFR SCR Rating Description

impact/ level impact Regulatory Reputational Risk Nature of Findings

I probability

Relevant potentia l Source: Augmented

Rating from an OE impact/ probabilit y Source: AZ from KPMG

Perspective t hresholds for reporting Standard guid3nee

r isks

Could rosult in sic:nifteant d;,Qplinary •ction tak•n by• koy rquldlur. Pendlli~ dre ~~e. includi1lK the pult!nlidl ur m~ of license-. Very Hich •

Severe implications • Imposed fines. remediation costs and professional fttS St•k•holder

Under consideration (uternal audit. forensic accountine. etc.) could sie:nificantly Awareness: (Nea rly) Fi ndinc(s) rela trd to an

>5" IFRS Pre-tax exceed profits made or attempted to be made throueh the •II peopl•/ most ope.-ational or desicn of th! risk l\lll!S in

consolidation OESll ratio

\wonedoine,. important 1roups issue that may have a accordance with the > 10

L4 Group· s Ri sk unit net income Motcrio l • Extreme like:ihood of litiiotion bo:;cd on indultry trcnd3 offcctcd; reference sic:nifioont im~ on the a.nd occurance Weakness

percenta1e and/ or previous cases aeainst the OE or pttt Company. detailed descriptions r isk profile of OE or the Guideti~ a crit ical

probability> points,

• Material chanies are required as a resu1t of a in · Ratint: for development of OE or threat potentia l for

10% AFR> 10%

findin&fdecis ion of a re&tJlator to a broad cross-section of Reputabonal Risk• result in action taken by the entity's business

the OEs products and transactions, in terms of the OEs imp•ct table the supervisors.. exists from an

personnet and trainin& efforts. and in terms of the ors rT (reputational r isk overall perspective.

systems and processes. rotine of "51 • Extreme Gk.chood of lnvestc•tory actMty by a roeul•tor or other third party over the OE or a peer (e.c.. external monitor).

Substantial Could ••suit in major disciplinary •ction taken by• key

implk.at ions reculator. Hieh · St•keholder Findinn related to

• Imposed fines, remediation costs and professional ftt:s Awareness: Majority s ina:le

Under consideration (external audit. forensic a ccountine. etc.) could exceed profits of people/ si,cnificant incidents/processinc of th! risk lv!>es in

>1" IFRS Pre-tax OESll ratio

made or •tt•mpt.d to be made throueh the wronedoinc. numb!r of im1>0rtant errors with a material

accordance with the con.sol1dabon

>5 • Hieh likelihood of htoeat•on baud on ondustry tr•nds and/ or

croups aff«t!d; impact or mult iple

L3 Group· s Risk unit net Income Sfcnificant

percentaie previous cases aiainst the OE or peer Comp.any. reference drlaited processlnc errors with

Guideline a a nd occurance Deficiency points, • Sicniftcant chanies are required as a result of a descriptions in ·Ratin1 minor/~dium severe

considerable threat probabill!V >

AFR> 3" fir1dl<1e/dtcls ion of a reeularor to a broad cross-section of for R•putational Risk" impact for OE which

pot•ntial for th• 10% the OEs products and tran.saaions, in terms of the OEs

impact tabt• represent material entity's business personnel and traininc efforts, and in terms of the OE"s IT (reputational r isk systemic (desi&:nl exist from an overall

systems and processes. ratin& of •4•) issues/errors. per$~VC,

• Hich likefohood of lnvesticatory activity by a reeulator or other third p,arty over the OE or a peer (e.c~ external monitor).

Could result in disciplinary action taken by a key rerulator: The findlncs relat!d to Medium-weicht

• lmpcsed fines. remediation costs and professional fttS M!dium • Stak•holdu sinde incidents or

implicattons (external audit. foronslc •ccountinc. •tc.) could be equivalent Awareness: Larcer

processin& errors

to the profits made or att•mpt!d to be made throuJh th• number of (ope,.-ational

Under consideration wroncdoin.a. peopl•/ srnall numb!r

•ff«tiv•n•ss) with a of th• risk types In <l" IFRS Pre-tax OESll rotio

• Moderate h1r.elihood of litication bas!d on Industry trends of lmpcrtant 1roups major impact or

accorda11Ce with the consolidation >3 and/or previous cases aeainst the OE or peier Company. affected; reference

multiple proceslirc

u Group· s Risk unit net income Deficiency percentaee • Chanees are required as a result of a findln&/decis ion of a detailed descriptions

e rrors ;,•1ere identified Gt.1idtHM1 (rtaordltss of points,

rt1ulator to a broad cross-Retion of the oes products and in •Ratlnc for with 1 minor imptct for

collateral throat proba bil lty) AFR> 1.5" transactions, in terms of the OEs personnel and trainin& R•putational Risk" OE. No svst•mic (desill') pot•ntial for entity's

•fforts, and in terms of the OE's IT syst•ms and proc•sses. impact ta;bfe issues / errors were business exists from

• Moderate likelihood of lnve.tieatory activity by a rt1ulator (reputational r isk identified that have a an overall

or oth•r thi rd party ov•r the OE or a pttr <o.c. oxt•rnal ratlnc of "3") si~ificant Impact on

persPKtive. monitor).

tht" internal control systtm.

The findlncs relat!d to

Minor imolicaUons Unlikety to result in official c·ensure by a reculator.

Low · Stak•holder sincle incidents or

• IMl>OStd fi rltS. remtdia!ion costs and professional fffS AwartnHS: Small

proctssinl errors

Undtr consideration (e.xternal audit. forensic accountine.. ett.) are minor.

number of people/no (operational

<0.5" IFRS Pro- •Low likelihood of lit lcation baud on industrV tr•nds and/or effectiveness) with a of th• rosk types In OESll ratio

previous cases apinst the OE or Pffr Company. impcrtant croup

medtum imPKt or ta• accordance with the

consolidation fnconseque <3

•Minor chances art required as a result of a affected; reference

multiple processinc L1 Group"s Risk

unit ntt incoMt ntla l percenta1e

findl11e/dtcis ion of a reeulator to a broad cross-sect ion of dotall!d descriptions

! rrors ,•ttre l~tifitd Guideline a minor

(rt1ardl••s of points,

the OEs products and transactions, In ttrms of th• OEs in "Ratine for

with a minor impact for threat potentia l for probability) AFR< 1.5" personnel and tta1ninc efforts~ and in terms of the oe·s rT

R•putational Risk" OE. No •vst•mic (desicnl

entit{s business systems and processes.

impact tabl• issues / errors \".llert

exists from an • Very low likelihood of 1nvestie•tory activity by a roeulator or

(reputational r isk identofl•d that have a

overa1t pe.rsp«tive. other third party over the OE or a peer (e.a. external monitor).

ratlnc of ·1 ·and "2") material impact on the internal control system.


C.V.3 Remediation of Issues

A plan must be established for each issue outlining how the issue will be remediated (“action

plan”). Action plans shall include a description of the exact measures to be taken to address the

issue, a timeline for completion of the action plan and a designated action plan owner who is

responsible for either direct execution of the action plan or for ensuring its proper execution.

The extent and urgency of action plans should follow a risk-based approach, whereby the

significance of the underlying weakness in the ICS is considered when deciding upon what

remediation measures are appropriate and how quickly they must be implemented.

C.VI REPORTING

An integrated ICS report, which is based heavily on the results of the IRCS process, must be

reported to the OE Risk Committee or other appropriate Board of Management body at least

once a year. Integrated in this context means the report must contain an analysis of the ICS –

and a conclusion of its effectiveness – based on a joint view of the local risk, compliance, legal,

actuarial and audit functions. Additional ICS reporting by these functions outside of the

integrated ICS report should be avoided to the extent possible.

For OEs that prepare an Own Risk and Solvency Assessment (ORSA) Results Report the

section of the report related to effectiveness of the ICS may be leveraged to fulfill this

requirement.13

C.VII DOCUMENTATION

The objective of documentation is to ensure the key steps and outcomes of the IRCS are

properly recorded. A thorough set of documentation supports the following:

forms a basis for monitoring the ICS, including reporting on, prioritizing the management of, and tracking the remediation of ICS weaknesses;

13

Refer to the Allianz Standard for Own Risk and Solvency Assessment

ALZ.0001.0097.3469

• forms a basis for concluding on the overall effectiveness of the ICS as part of the ORSA; • provides an audit trail to support ICS related audits or reviews by internal auditors,

external auditors and regulators; and • enables Group monitoring of OE compliance with this Guideline.

The following table outlines where results arising from performance of the IRCS must be documented. In this respect, the primary tool for documentation of the IRCS is the Operational Risk and Governance System (ORGS).

ALZ.0001.0097.3470

Process results Reference within Where process results must this IRCS Guideline be documented

Final results of IRCS scoping (i.e. a risk object must be Section C.I ORGS - Risk Object created in ORGS for each risk identified as "in-scope")

Scoping: scoping coverage Section CI Excel or other local tool at OEs discretion

Scoping results: reporting risks Section C I. 1 /RCS Catalogue & OE Scoping Template

Compliance risks: inherent risk assessment Section C. 1.2.2 ORGS - Risk Object

Compliance risks: Program Maturity assessment Section C 1.2.3 ORGS - Program Maturity Object' •

Scoping results: Compliance risks Section C I. 2 /RCS Catalogue

Scoping results: other operational risks Section C 1.3 /RCS Catalogue

RCSA results: key controls Section C.11.2.2 ORGS - Control Object

RCSA results: control environment effectiveness Section C.11.2.3 ORGS - Risk Object assessment and risk assessment

RCSA results: risk responses Section C .11.2.4 ORGS - Risk Object

Results of key control testing Section C.111 ORGS - Control Object

Results of monitoring, including KRls and current KRI Section 0 ORGS - KRI Object values ORGS - KRI Value Object

Results regarding the management of issues related to Section 0 ORGS - Issue Object weaknesses in the ICS

ICS reporting to the OE Risk Committee or other Section CVI Documentation in OE reports -appropriate Board of Management body nature and extent at OE

discretion

C.Vlll SPECIAL CONSIDERATIONS

C.Vlll.1 IT Controls

Vlll.1.1 IT General Contro ls

The objective of IT General Controls (ITGC) is to provide a control framework surrounding both the delivery of IT services and the foundation of a strong overall IT control environment.

• ITGC related to delivery of IT services: To support the business processes, IT provides IT services, usually in the form of shared services to many business processes. Many of the development and operational IT processes are provided to the whole enterprise from one central unit and much of the IT infrastructure is provided as a common service (e.g.,

14 The ORGS - Program Maturity Object is currently not available in the ORGS production environment. Until this time, OEs

must document the Program Maturity assessment using the Excel workbook provided by Group Compliance.



networks, databases, operating systems and storage). The reliable operation of controls within these central IT processes/services is necessary to support the reliance that can be placed on application controls. For example, poor change management could jeopardize (by accident or deliberate act) the reliability of automated integrity checks.

ITGC related to the IT Control Environment: At the executive management level, business objectives are set, policies are established and decisions are made on how to deploy and manage the IT resources of the enterprise to execute the enterprise IT strategy. The overall approach to governance and control is established by the board and communicated throughout the enterprise. The IT control environment is directed by this top-level set of objectives and policies; this establishes the very important “tone at the top”.

The business system owner together with the IT system owner and the ISO must identify or implement ITGCs according to the following process:

Step 1: Create inventory of all IT Services

In order to determine which IT Services are critical OEs must first identify all IT Services in use within the business. This includes, but is not limited to:

Applications (e.g. SAP, ABS, ePac, OPUS, End-User-Computing15

, etc.); IT Infrastructure (e.g. Network, System Operations, Back-Up System, Voice over IP, etc.); IT Facilities (e.g. Data Center, Disaster Recovery Center, IT assets, etc.); and IT Outsourced Services/Shared Services (e.g. within Allianz Group, outside the Allianz

Group).

This inventory should typically be maintained and provided by the local IT function.

Step 2: Identify critical IT Services

Utilizing the inventory of critical IT Services, the local IT Function must engaged Accounting, Actuarial, and the Operational Safeguarding Function to identify which IT Services should be classified as critical according to following criteria:

Financial Reporting; Internet/External facing Application/Services (e.g. Customer Portal such as web or mobile

app, etc.); Data-Confidentiality, -Integrity and -Availability (CIA) principle while processing,

transferring and/or storage of data; and BCM (Business Continuity Management) - business critical applications identified during

the Business Impact Analysis (BIA).

Step 3: Identify COBIT 5 control objectives for each critical IT Service

For each critical IT Service OEs must identify which COBIT 5 control objectives should be fulfilled. In general these control objectives are broken down into the following five areas:

IT Control Environment Access and Authorization Change Management Project Management

15

End-User-Computing (EUC) is maintained within the business area

ALZ.0001.0097.3471


Operations

Step 4: Identify and/or implement ITGCs for each control objective identified in the previous step

For each COBIT 5 control objective mapped to one or more critical IT Service a corresponding ITGC designed to fulfill the control objective must be identified. If no suitable ITGC is in place the OE must implement a new control as appropriate.

With respect to COBIT 5 control objectives related to the IT control environment, it is typically the case that the corresponding ITGCs will cover all critical applications. For the other areas –i.e. access and authorization, change management, project management and operations – the OE must ensure that ITGCs in place cover the critical IT Services for which the COBIT 5 control objective underlying the ITGC has been mapped.

VIII.1.2 IT Application Controls

During identification of key controls as part of the RCSA workshops some key controls may be identified that qualify as IT application controls. IT application controls are conceptually synonymous with process level controls, which are controls embedded directly within business processes in order to prevent or detect the occurrence of a risk. However, due to their IT nature there are special considerations that must be taken into account, particularly with respect to control testing.

At the business process level, controls are applied around specific business activities. Some business controls are manual procedures, such as authorization for transactions, segregation of duties and manual reconciliations. However, many business processes are at least partially automated and integrated via IT applications. Controls that are performed within such IT applications, be they manual, automated or a combination of both, are known as IT application controls. The responsibility for the definition, implementation, maintenance, documentation, testing and management of business and application controls are within the responsibility of the business. However, the technical design, development and implementation of the automated portion of IT application controls require the involvement and support of the IT function.

IT application controls may be manual, automated or a combination of the two:

Manual: a purely manual control could be a job instruction stating that “… all manual data entry must be performed in the presence of a second person, ensuring via 4-eyes principle that correct numbers are entered….”.

Automated: A good example is programmed segregation of duties. For example, the system allows the payout of certain amounts only if the head of department has logged on and electronically signed-off the transfer. In such a case the control “segregation of duties” is fully automated and the transfer of cash is set on hold as long as the programmed requirements are not fulfilled. Further examples would be automated edit checks to verify the data input and automated accounting processes, such as automated calculations, account mappings, classifications, estimates and postings.

Combined: many application controls will be a combination of an automated and a manual element. An example is reconciliation reports that are automatically created, confronting information from different areas in the system. In order to complete the control, however, a manual check of the reconciliation report is needed and in case of a deviation corrective action is initiated by an individual.

In general, application controls consist of three broad categories:

Input controls: ensure the complete and accurate recording of authorized transactions; identify rejected, suspended, and duplicate items; and ensure proper re-submission of rejected and suspended items. An example of an input control would be front-end edits in a claims system which requires that a claim be linked to an in-force policy number prior to a claim being allowed to be entered into the claim administration system.

ALZ.0001.0097.3472


Processing controls: ensure the complete and accurate processing of authorized transactions. An example of a processing control is a control built into an underwriting system, which checks that premium rates are reasonable by assessing whether they fall within a pre-set range of amounts.

Output controls: ensure that a complete and accurate audit trail of the results of processing is reported to appropriate individuals for review. An example of output controls would be a control within a claims system which ensures that claims required to be reviewed by executives in the claims department are systematically brought to their attention.

VIII.1.2.1 User Acceptance Testing

As IT application controls rely on the integrity, accuracy, and reliability of the data from the relevant application it is important to rely on system functionality to ensure that the systems are properly processing transactions. Upon initial implementation of an application or following a modification to an application this should be accomplished via end-user acceptance testing.UAT relates to the testing of IT system applications to ensure that they are properly processing transactions.

User acceptance test relates to the testing of IT system applications to ensure that they are properly processing transactions.

Ultimately the User acceptance test should provide evidence that the system calculations, inputs, outputs and edits are deemed effective.

Test the functionalities, incl. changes in the IT application using sample transactions within a test environment, to confirm correctness. Following documents created by the business owners should support the UAT:

Test concept

Test cases, incl. test results

Approval for deployment into production environment

VIII.1.2.2 When a testing of all automatic key controls within an IT Application is required

For each for each IT application control that has been identified as a key control during the RCSA workshops the underlying IT application must be identified. It must then be determined if a full testing of those automatics controls is required:

No documentation exists for current applications and application controls that describe the implementation phase including requirements specification, testing (technical, functional, user acceptance), acceptance and deployment.

For applications that were implemented and documented according to best practice project management processes but are or became subject to missing, ineffective or failed IT General Controls..

In the absence of significant changes/impacts to the systems in scope, testing of automated key controls for critical applications must be performed at a minimum every three years.

VIII.1.2.3 ITGC in the context of outsourcing

When IT Services (incl. application development and maintenance) are outsourced to a service provider, the business owner need to agree with the service provider which controls will be performed at the service provider and document this in the contracts. Additionally it needs to be agreed that the service provider have to send an annual control effectiveness report to the business owner (retained organization).

The ITGC of monitoring access rights of the service provider employees, the UAT and testing the effectiveness of the IT Application Controls cannot be outsourced to the service provider and must remain at the business owner.

ALZ.0001.0097.3473


C.VIII.2 System of Governance Assessment

Allianz must have in place an effective System of Governance (SoG) which provides for a sound and prudent management of its worldwide business. According to the Allianz Group Governance and Control Policy, the System of Governance is defined as following:

Allianz decided to use the already well-established Entity Level Control Assessment (ELCA) as the adequate tool for the assessment of the effectiveness of the SoG. The existing ELCA control catalogue has been updated in light of the new SoG requirements and mapped to the specific SoG elements to assess the effectiveness of each element of the SoG.

Documenting and evaluating internal controls at the entity level does not by itself provide a complete perspective of the internal control effectiveness of an OE, however, the Group views the SoG assessment as one of the most critical and value-adding aspects of an ICS. The assessment of ELCA controls, particularly when weaknesses are identified, can have a significant impact on management’s overall assessment of the OE’s effectiveness of internal control. In addition, any weaknesses identified may also have substantial business implications.

Assessments concluding that ELCA controls are ineffective require careful consideration. Such assessments may be an indication of one or more significant issues in internal controls.

Further details on the ELCA controls are available on Allianz Connect (link pending).

VIII.2.1 Setting-up ELCA Controls

OE management must decide whether, as a result of having multiple control environments or several legal entities or business units, it is appropriate to perform multiple assessments within the OE. For example, OEs with their own sub-consolidation process (i.e. many OEs within the sub-Group) may need to complete more than one ELCA control assessment to obtain comfort and evidence concerning the effectiveness of the sub-Group’s overall SoG assessment. Depending on the local regulatory requirements and the OEs organizational structure a mixed approach could also be applicable, such as one overall control for a process that is performed on OE level (i.e. Code of Conduct) compared to controls that have to be in place on legal entity level (i.e. Committees).

If so, care needs to be taken to ensure that the responses to each of the management objectives does not present either an incomplete, inaccurate or perhaps conflicting portrayal of the entire internal control infrastructure. Central oversight on OE level has to be ensured.

OEs covered under the category “Internal Service Provider (ISP)” may be subject to the SoG assessment on a case by case basis as determined by Group Risk. If such a determination results in the need for an ISP company to perform an ELCA control assessment, Group Risk will inform the affected OE in a detailed and timely manner.

ALZ.0001.0097.3474


VIII.2.2 Predefined ELCA Controls

To achieve a consistent view of the System of Governance effectiveness across the Allianz Group a predefined set of ELCA controls has been developed that each OE must implement (see Allianz Connect (link pending). All ELCA controls and test results have to be recorded in ORGS locally.

Internal and external factors unique to a particular OE may give rise to additional controls within the SoG set up that should be considered beyond the minimums outlined in the Group SoG framework. Additionally, based on local circumstances, the implementation of some ELCA controls might not be possible. A comply or explain approach has to be applied.

Difficulties in implementing the predefined controls or the implementation of additional controls must be communicated to Group Risk and the Group Corporate Secretary.

VIII.2.3 Assessing adequacy and effectiveness of the System of Governance

Adequacy and effectiveness of the OE’s System of Governance are subject to a regular review. The review takes place regularly taking into account the OE risk profile, or ad-hoc, if extraordinary circumstances occur (such as in case of larger organizational or regulatory changes). It shall be based on a review plan and may focus on selected review areas.

The responsibility for the regular review (including assessment) lies jointly with the respective OE Board of Management. The coordination and performance of the process as well as the relevant documentation may be delegated, i.e. to the Governance and Control Committee (or equivalent).

The review consists of an adequacy review and an effectiveness review, i.e. it shall evaluate whether the Governance System is adequately designed and operating effectively.

The adequacy review (test of design) assesses whether the defined governance elements and assigned ELCA control elements are complete and appropriately designed to cover and match to the OE business model (proportionality considerations have to be taken into account when applying the above referred predefined ELCA controls). The regular assessment on the adequacy of the System of Governance shall take place once per year in two-staged approach, i.e. a sign-off from the respective ELCA control owner followed by an overarching sign-off in the Governance and Control Committee (or equivalent) for further evaluation by the Board of Management.

The effectiveness review (test of operating effectiveness) ensures that the governance elements and assigned ELCA controls are effectively operating as designed. A test of operating effectiveness has to be performed for each control with a minimum frequency of 5 years. Test of operating effectiveness is usually performed by Group Audit as well as by local Internal Audit in line with the provided testing scope and guidance. However, testing can also be performed by 2nd line functions e.g. in context of monitoring or quality assurance activities. Test results have to be documented in ORGS locally.

Besides the ELCA controls, the review of the System of Governance may utilize results from other control processes or findings, for example from:

Reports from Internal Audit, in particular regarding its assessment on (elements of) the System of Governance

Information of / findings from other functions, in particular key functions (e.g. own functional reviews, quarterly meetings of the key functions).

The Governance and Control Committee (or equivalent) consolidates the local test results to a single assessment result and provides the overall assessment (including a proposal on remediation measures, if applicable) to the local Board of Management for approval. The assessment result will be documented and communicated to Allianz Group via the Statement of Accountability process (in February of the following year).

ALZ.0001.0097.3475


VIII.2.4 Group-wide ELCA focus areas for testing purposes

The Group Governance and Control Committee may define certain ELCA focus areas for group-wide testing purposes on an annual basis in order to get a transversal feedback/ status on the effectiveness for these control elements. This discussion will take place in synch with the Group Audit annual planning activities to ensure that potential synergies can be leveraged. Incorporating these focus areas, each OE has to define their own annual testing scope, leveraging Internal Audit activities and adhering to the 5 year testing cycle.

C.VIII.3 Outsourcing

Outsourcing OEs retain the ultimate responsibility for identifying and managing risks relevant in outsourced activities or (sub-) processes. For ensuring proper risk oversight an OE must obtain an understanding of:

the risks when outsourcing a service; and interaction and relationship between key controls of the service provider and those of the

OE, respectively.

The business owner needs to consider the risk and respective control environment in an end-to-end-view, i.e. the full chain from the outsourcing OE via internal service provider to external service providers including further sub- providers.

VIII.3.1 Outsourcing risk assessment in project phase

A risk assessment has to be performed by the business owner in case of a new outsourcingarrangement as part of the due diligence and implementation phase of the project. The IRCS risk catalogue in ORGS supports the business owner in identifying potential risks for the planned outsourcing.

The assessment shall cover at least the following outsourcing related risks: IT supplier failure or non- IT supplier failure, unavailability of supplier, legal dispute because of unclear terms and conditions in contract. Other operational risks to be considered in an outsourcing risk assessment are related to, for example, data privacy and other compliance related risks and information security or IT risks (e.g. change management). Business owners shall invite the risk function and other subject matter experts, e.g. Compliance, information security officer, data protection officer, safeguarding function, to the RCSA workshops. Based on the risk assessment results business owners need to define and agree upon appropriate controls to be performed at the OE (retained organization) and at the service provider level. The root causes of the outsourced risks shall also be monitored by a set of key risk indicators (KRI) to be reported regularly by the service provider. Controls and KRIs agreed with the service provider must be part of the contract (SLA). The OE also needs to agree on a control effectiveness report provided on an annual basis by the service provider which shall also be part of the contract.

VIII.3.2 Ongoing outsourcing risk management

Business critical outsourcing contracts need to be identified by the business owner with the support of the legal and or outsourcing function in a first instance based on the outsourcing inventory maintained by the local outsourcing function. If a contract is classified as Group Outsourcing Policy relevant a risk assessment must be performed by the business owner/retained organization for each Group Outsourcing Policy relevant contract on a regular basis. If the risk landscape is changing, e.g. due to changes in services, changes in laws and regulation, the control inventory has to be adjusted accordingly and also changed in the contract. On top of the risk assessment a financial health-check has to be performed regularly ensuring the financial stability of the provider and can be seen as a control performed by the business owner (retained organization) to mitigate a potential unavailability of the supplier due to e.g., bankruptcy.

Please refer to the Group Outsourcing Policy and the Outsourcing Process Manual (provided by H4) for further guidance and details.

ALZ.0001.0097.3476


D. ROLES AND RESPONSIBILITIES

The IRCS requires the involvement of numerous individuals acting in many different roles. In

practice, many elements of the IRCS are not achieved based on the contribution of a single

individual or role, but rather involve the contribution of multiple parties spanning both the 1st

Line

of Defense and 2nd

Line of Defense. This type of cooperative collaboration leads to the best

outcomes by drawing upon the strengths and expertise of a group – and also allows the 2nd

Line

of Defense to dually act in both a support and oversight role. Despite this concept, a clear

owner must be established for each IRCS requirement to ensure complete execution and proper

accountability. The following table provides an outline of owners and contributors for each IRCS

requirement:

D.I 1st LINE OF DEFENSE

The key characteristic of 1st

Line of Defense roles is ownership of operational risk

management. This includes responsibility for identifying and assessing the risks, implementing

controls to mitigate the risks and taking action to better manage the risks if the existing control

environment is considered inadequate.

1st or 2nd

Line of

Defense

3rd Line of

Defense

IRCS

Officer

Risk

Owner

Action Plan

Owner

Risk

Function

Compliance

Function

Risk

Expert

Internal

Audit

Scoping

Reporting Risks R C

Compliance Risks R C

Other Operational Risks R C

RCSA

Workshop Planning C R C

Pre-Assessment

Reporting Risks C R

Compliance Risks C R

Other Operational Risks C R

RCSA Workshop

Validate Risks in Scope C A C C R

Perform Assessments C A C C R

Identify Key Controls C A C C R

Determine Risk Response C A C C R

Key Control Testing

Test Planning C R C C

Test Performance

Monitoring C Owner

Issue Management

Recording of Issues C C C R1 R1 C C

Classification of Issue C C R1 R1 C C

Remediation of Issue

Action Plan Design C A C R1 R1 C

Action Plan Execution A R I I

Reporting C R2 R2 C

Documentation C R C

1 Risk w i h respect to reporting and other operational risks, compliance w ith respect to compliance risks2 A joint ICS report should be prepared

RACI Matrix: R = Responsible, A = Accountable, C =Consulted, I = Informed

Requirements

1st Line of Defense 2nd Line of Defense

All parties are eligible control testers - see guidance at section C.III.1.3

ALZ.0001.0097.3477


Within the IRCS the 1st

Line of Defense roles are primarily conceptual in nature and not defined

by specific functions.16

The responsibilities described for these conceptual stakeholders

highlight the important roles that must be filled in order to properly own and manage operational

risks. In practice these roles are not always explicitly delineated between individuals, but are

rather realized such that a single individual may have responsibilities that correspond to two or

more roles.

D.I.1 IRCS Officer

IRCS Officers are individuals within the 1st

Line of Defense that are responsible, together with

the support of the 2nd

Line of Defense, for coordinating the implementation and execution of the

IRCS within their respective business area. An IRCS Officer must be assigned for each process

or function of the business.17

Overall the IRCS Officer must apply personal initiative to help drive a strong ICS within their

area of responsibility. Specifically, the IRCS Officer must play a central role with respect to the

following:

Supporting the planning of RCSA workshops; Supporting the testing of key controls coordinated by the 2

ndLine of Defense, often times

by acting as a control tester Coordinating and monitoring the resolution of ICS issues within their area of

responsibility, whether from control deficiencies, audit findings, KRI breaches or any other source;

Supporting IRCS reporting coordinated by the 2nd Line of Defense; Supporting fulfillment of IRCS documentation requirements; and Supporting performance of the Top Risk Assessment18

D.I.2 Risk Owners

Risk owners are management level individuals responsible for the business area whose

business objectives are most negatively impacted by a given risk and therefore strongly

incentivized to ensure that the risk is effectively managed. Risk Owners should have the

authority to decide upon and ensure effective implementation of risk mitigation activities,

including the strengthening or implementation of controls, and – if required – to secure

necessary funding in support of these objectives.

Risk owners may participate directly in the assessment of control environment effectiveness and

actual risk, as well as the selection of a risk response, KRIs and development of action plans, or

alternatively they may hand these responsibilities off to risk experts, process owners or other

appropriately qualified individuals. In either case, risk owners must concur with the final IRCS

results, including any proposed action plans and the assignment of action plan owners, and

ensure agreed-upon action plans are executed in a timely manner.

16

With the exception of the IRCS Officer, which must be a formally designated role17

As this requirement may require changes to organizational structures, job descriptions, workers council approval, etc. it is not

expected that a formally designated IRCS Officer is in place as of the effective date of this document. The formal designation of

IRCS Officers should be viewed as a target over the mid-term as the IRCS matures. However, it is fully expected upon IRCS

implementation that a clear IRCS Officer is (informally) designated for each area of the business and has adequate capacity to

fulfill all IRCS Officer responsibilities.18

Refer to the Allianz Standard for Top Risk Assessment

ALZ.0001.0097.3478

D.1.3 Action Plan Owners

Action plan owners are individuals responsible for ensuring that action plans are implemented. Action plan owners may or may not be risk owners or risk experts.

Action plan owners may or may not be directly involved in the development of action plans, but once they are assigned as owners they must ensure that the action plans are carried out. It is therefore important that these owners either possess a sufficient level of authority or have adequate management support.

D.1.4 Other 1st Line of Defense Roles

Role Description

ALZ.0001.0097.3479

Process Owners Process owners are individuals responsible for the design of a given process and are usually also responsible for ensuring execution of the process and achievement of process objectives. They may directly have authority to modify processes or alternatively derive this authority from risk owners.

Control Owners Control owners are individuals responsible for the design of controls and the monitoring of their performance. They may directly have authority to modify or implement controls or alternatively derive this authority from risk and/or process owners.

Control Performers Control performers are individuals responsible for the execution and documentation of control activities and upon whom the effective operation of a given control is primarily dependent.

KRI Owners KRI owners are individuals who support risk owners in defining the KRls and collecting and collating data for KRI monitoring on a regular basis.

D.11 2nd LINE OF DEFENSE

The key characteristics of 2"d Line of Defense roles is support and oversight of operational risk management. This includes faci litating the IRCS process in order to support the 1st Line of Defense with the management of their significant operational risks, as well as overseeing whether this management is adequate.

Based on its role as a challenger during the IRCS process, if the 2nd Line of Defense disagrees with the IRCS conclusions or actions of the 1st Line of Defense and the two parties cannot come to an agreement on how to proceed, the 2nd Line of Defense must escalate the matter to an appropriate management level body for resolution (e.g. OE Risk Committee).

D.11.1 OE Risk Function

The OE Risk Function is responsible for coordinating and faci litating the IRCS process throughout their respective Operating Entity (OE). These responsibilities include:

• Performing the scoping process for reporting risks and other operational risks (see section C. I);

• Ensuring 1st Line of Defense IRCS Officers have been assigned throughout the business (see section D.1.1 );

• Planning and organizing, in consultation with the IRCS Officers, the number, nature and composition of RCSA workshops required to cover all of the Allianz Operating Model (sub)functions mapped to one or more in-scope risks (see section C.11.1.1 );

• Gathering data related to in-scope reporting risks and other operational risks in preparation for the RCSA workshops (see section C.11.1.2);

• During the RCSA workshops (see section C .11.2): o Supporting the 1st Line of Defense by, for example, clarifying RCSA requirements and

assessment methodology or 1st Line of Defense IRCS roles and responsibilities; and



o Challenging the 1st

Line of Defense by ensuring any conclusions by risk owners and risk experts are properly substantiated or otherwise justified. This is applicable to the assessment of control environment effectiveness, the assessment of actual risk and the appropriateness of the chosen risk response, as well as the selection of key controls;

Establishing – together with internal audit, IRCS Officers and other 2nd

Line of Defense functions – a key control test plan that includes a testing schedule / testing frequency and who is responsible for test performance (see section C.III.1);

Monitoring execution of the control test plan (see section C.III.1); Monitoring, together with the IRCS Officers, significant new operational risks, or

significant changes in the actual risk level of in-scope risks, that emerge between regular performance of the IRCS scoping and RCSA processes, including the monitoring of KRIs (see section 0);

Generating, together with input from all IRCS stakeholders, a log of IRCS issues and action plans and tracking issue management by the 1

stLine of Defense, including

following up with the 1st

Line of Defense or escalating to the Risk Committee when action plans fail to be implemented within agreed upon timelines (see section 0);

Coordinating, together with the OE Compliance, Actuarial, Legal and Audit functions, an integrated ICS report to the OE Risk Committee or other appropriate Board of Management body at least once a year (see section C.VI); and

Ensuring, together with the IRCS Officers and the OE Compliance Function, that all IRCS documentation requirements are met (see section C.VII).

D.II.2 OE Compliance Function

The OE Compliance Function is responsible for coordinating and facilitating the IRCS process

with respect to all Compliance risks. These responsibilities include:

Performing the scoping process for Compliance risks (see section C.I.2); Gathering data related to in-scope Compliance risks in preparation for the RCSA

workshops (see section C.II.1.2); During the RCSA workshops (see section C.II.2):

o Supporting the 1st Line of Defense by, for example, clarifying RCSA requirements and assessment methodology or 1

stLine of Defense IRCS roles and responsibilities; and

o Challenging the 1st

Line of Defense by ensuring any conclusions by risk owners and risk experts are properly substantiated or otherwise justified. This is applicable to the assessment of control environment effectiveness, the assessment of actual risk and the appropriateness of the chosen risk response, as well as the selection of key controls;

Supporting the OE Risk Function with establishment of a key control test plan (see section C.III.1);

Serving as a control tester for Compliance key controls, where Compliance is not also the control performer (see section C.III.1.3);

With respect to issue management for Compliance risks, supporting the design of action plans and monitoring their execution (see section 0);

Reporting, together with the OE Risk Function and other relevant stakeholders, a summary of the results of the IRCS process to the OE Risk Committee or other appropriate Board of Management body at least once a year (see section C.VI); and

Supporting fulfillment of IRCS documentation requirements (see section C.VII).

D.II.3 Group Risk

Group Risk is responsible for establishing, together with Group Compliance and other Group

Subject Matter Experts, the Allianz Group IRCS Framework provided in this document.

In addition, Group Risk is responsible for:

Creating, maintaining and distributing the IRCS Catalogue to OEs on an annual basis. Analyzing OE IRCS results – in consultation with other Group Subject Matter Experts – in

order to identify internal control weaknesses where group-wide initiatives should be

ALZ.0001.0097.3480


targeted (e.g. best practice sharing, improvements in focused control areas, updates to Group requirements, allocation of additional resources, etc.). In conjunction with thisanalysis Group Risk is responsible for facilitating actions for these IRCS focus areas that must be addressed either by specific OEs or on a Group-wide basis.

Reporting on ICS effectiveness to the Allianz SE Supervisory Board, Allianz SE Board of Management and other appropriate committees/bodies, in coordination with other 2

ndand

3rd

Line of Defense functions. Monitoring OE compliance with IRCS requirements on a test basis. Possible forms of

monitoring include, but are not limited to:o Benchmark reviews of IRCS data;o Targeted requests for information; ando On-site visits and desk reviews.

D.II.4 Group Compliance

Group Compliance is responsible for:

Monitoring laws and regulations relating to the Compliance Risk categories that have cross jurisdictional impact and/or generate Compliance risks for the Holding;

Designing programs to manage/mitigate Compliance risks; Acting as Compliance control tester and local Compliance Program reviewer; Monitoring Compliance Program Implementation across the Group; Coordinating, monitoring and informing the Expert challenge executed by the Compliance

Standards Committee; Training direct reports and equipping the Compliance Standards Committee to train their

OEs on the Compliance risk assessment process integrated into the IRCS; Defining the Group Compliance Program maturity appetite; Collaborating with Group Risk to launch, coordinate, manage, monitor, review and refine

the IRCS; and Reporting on ICS effectiveness, with respect to Compliance risks, to the Allianz SE

Supervisory Board, Allianz SE Board of Management and other appropriate committees/bodies, in coordination with other 2nd and 3rd Line of Defense functions.

D.II.5 Group Subject Matter Experts

Group Subject Matter Experts are individuals at the holding level who possess expertise with

regards to one or more specific operational risks. This includes, for example, Group Legal and

Compliance, Group Actuarial, Group Accounting and Reporting, Group IT and Group

Operations Safeguarding (e.g. BCM, outsourcing, crisis management). Their responsibilities

under the IRCS framework include:

Supporting creation and maintenance of the IRCS Catalogue by providing input on significant operational risks within their area of expertise and, where appropriate, defining illustrative key controls for the risks

Supporting the analysis of IRCS results and, where necessary, the development and implementation of Group-wide initiatives towards improving the ICS.

D.III OTHER ROLES

D.III.1 Management Level Oversight of ICS

The Board of Management is ultimately responsible for ensuring an effective ICS is in place

throughout their OE. To support fulfillment of this responsibility the Board of Management – or

an appropriate Board of Management level committee – must be periodically informed of the

outcome of the IRCS, including any significant ICS weaknesses identified and action plans to

remediate them.

ALZ.0001.0097.3481


For remediation of major ICS weaknesses a decision from the Board of Management may be

necessary. For example, issue remediation may require project sponsorship, additional budget,

strategic decisions or consideration of other types of tangible business impacts.

D.III.2 Internal Audit

The OE Internal Audit Function is responsible for the testing of ELCA controls.19

In addition, the

work of the internal audit function is reflected in the IRCS as follows:

Insofar as the work of internal audit includes the testing of key controls, the results of this testing may be relied upon to fulfill IRCS key control testing requirements; and

Insofar as audit findings related to ICS weaknesses are identified during internal audits –whether related to control deficiencies or other issues – these weaknesses should be recorded and managed in accordance with IRCS Issue Management requirements.

D.III.3 Risk Experts

Risk experts are individuals whose responsibilities, professional background or experience

particularly qualify them as experts with respect to the identification and assessment of risks for

a given business area, process or risk type, as well as for the design of mitigation measures.

Risk experts are often employees closely associated to specific processes where a given risk

could occur, however they may also be employees with a broader oversight role for a given type

of operational risk (e.g. IT risk, Compliance risk).

Risk expert responsibilities include:

Participating in the identification and assessment of operational risks; Participating in the identification of key controls and the assessment of the overall control

environment; Participating in the selection of a risk response; Participating in the selection of KRIs; and Participating in the design of action plans.

D.III.4 Control Testers

Control testers are individuals responsible for assessing the design and operating effectiveness

of key controls and may be situated within the 1st, 2nd or 3rd Line of Defense. For key controls

required to be tested the identification of control testers is coordinated by the OE Risk Function

during establishment of the test plan. In principle it is expected that all IRCS stakeholders

contribute towards the testing of key controls. Refer to section C.III.1.3.

19

Refer also to the Allianz Group Governance and Control Policy

ALZ.0001.0097.3482

ALZ.0001 .0097.3483

Index of used terms and abbreviations

Abbreviation I Term Description

ELCA Entity Level Control Assessment

ICOFR Internal Control over Financial Reporting

ICS Internal Control System

ITGC IT General Controls

IRCS Integrated Risk and Control System

KRI Key Risk Indicator

OE Operating Entity

OREC Operational Risk Event Capture

ORGS Operational Risk and Governance System

ORM Operational Risk Management

RCSA Risk and Control Self-Assessment

ScA Scenario Analysis

SCOT Significant Class of Transactions

SoG System of Governance

Too Test of Design

ToE Test of Operating Effectiveness

TRA Top Risk Assessment


ALZ.0001 .0097.3484

APPENDIX A - RISK ASSESSMENT METHODOLOGY As described in the process section of this Guideline, the specific risk assessment requirements vary by operational risk type. In principle there are two types of assessments - an inherent risk assessment and an actual risk assessment.

The inherent risk assessment is performed by the 2"d Line of Defense during the scoping phase. A formal inherent risk assessment is only required for compliance risks. For reporting risks the inherent risk is implicitly reflected in the materiality thresholds used to identify significant accounts. For other operational risks the inherent risk is implicitly considered during the scoping phase, but does not require a formal assessment.

The actual risk assessment is performed by the 151 Line of Defense during the RCSA phase, together with the support of data gathered, compiled and analyzed by the 2"d Line of Defense.

The following table summarizes the required assessment dimensions by risk type.

Table A-1: Required Assessment Dimensions by Risk Type

Assess-Required Assessment Element by Operational Risk Type

mentType Assessment Dimension

E!!!mE!!mmmm Occurrence Probability x

Inherent Risk Most Likely Financial Impact x Assessment

(Inherent) Reputational Impact x Control Environment x x x Effectiveness

Actual Risk 1-in-20 Year Impact Assessment x x Reputational Impact x x

•For nsk capital calculation nsks only a control environment assessment is reqwred

INHERENT RISK ASSESSMENT

Inherent risk is the probability that a given risk will occur. and the potential impact of the risk, prior to consideration of any mitigating measures in place (i.e. assuming that controls are nonexistent, improperly designed or improperly executed). Although inherent risk assessments do not account for the current control environment, they should still represent plausible outcomes that take into consideration the general governance structures in place and the assumption that human behavior is rational.

Occurrence Probability

Occurrence probability must be rated using the 5 point scale provided in Table A-2.

Occurrence probability is expressed as the annual number occurrences of the given risk expected to result in a loss. The occurrence probability is assessed independent from, or without consideration of, the assessment of financial impacts. Although the occurrence probability only considers events resulting in a financial loss, it should be considered that there is a correlation between the frequency of Compliance breaches and the frequency of financial losses.


ALZ.0001 .0097.3485

Table A-2: Rating for Occurrence Probability

Description Occurrence Probability • · = •~-Loss as a result of the risk is estimated to occur only in exceptional circumstances.

Less than once • every ten years

Unlikely Loss as a result of the risk is estimated to occur relatively Once every five • infrequently. to ten years

Moderate • · = Loss as a result of the risk is estimated to occur occasionally.

Once every lV«> • to five years

Likely Loss as a result of the risk is estimated to occur regularly. Every one to lV«> • years

• Loss as a result of the risk is estimated to occur More than once a • frequently. year

Most Likely Financial Impact

Most likely financial impact must be rated using the 5 point scale provided in Table A-3.

Most likely financial impact is expressed as the most likely operational loss20 amount for an occurrence of the given risk that results in a loss. The most likely financial impact is assessed independent from, or without consideration of, the assessment of occurrence probabil ity. However, irrespective of this independent relationship between most likely financial impact and occurrence probability, it should be considered that the frequency of Compliance breaches - as opposed to Compliance related losses - influences the severity of the most likely financial impact.

The rating is determined by comparing the most likely financial impact to a base materiality.

• The base materiality is input into the Business Entity objects of ORGS and updated by Group Risk on an annual basis (in consultation with OEs).

• The default basis for materiality is the average midterm (i.e. three year) planned IFRS operating profit (before tax), however an alternative basis may be proposed by OEs to Group Risk.

• If an alternative basis is proposed, Group Risk will assess the appropriateness of the basis and provide the OE with a decision on whether the proposed basis will be accepted and input into ORGS.

Table A-3: Rating for most likely financial impact

Label Materiality basis

< 0.5 %

0.5% to3%

3% to7%

7% to 15%

> 15%

~ . . . . . . . . . . . . Operational loss in this context shall be interpreted to mean consistent with the descnpt1on of qualifying losses established in

the Operational Risk Event Capture Guideline.



(Inherent) Reputational Impact

The reputational impact on an inherent risk basis must be rated on a 5 point scale. The scale

and approach provided for this assessment should be based on the Reputational Risk

Assessment Matrix provided within the Actual Risk Assessment section of this appendix. The

distinction between the reputational assessment required as part of the inherent risk

assessment and the reputational risk assessment on an actual risk basis is the inherent risk-

based reputational risk assessment should not reflect the impact of the existing control

environment in place to mitigate the reputational risk.

Overall Inherent Risk Rating

An overall inherent risk score must be determined using the matrix provided in Table A-4.

The inherent impact rating should be determined by taking the highest of the most likely

financial impact and reputational impact ratings. For example, if the most likely financial impact

score is 3 and the reputational impact score is 2, then the 3 should be applied to the overall risk

rating table. If the financial impact score is 3 and the reputational impact score is 4, then the 4

should be applied to the overall risk rating table.

Table A-4: Rating for overall inherent risk

Risk Rating Occurrence probability

Impa

ct

1 2 3 4 5

1 very low very low very low very low low

2 very low very low low low moderate

3 low low moderate moderate high

4 moderate moderate high high very high

5 high high high very high very high

ALZ.0001.0097.3486


ACTUAL RISK ASSESSMENT

Actual risk is the probability that a given risk will occur, and the potential impact of the risk,

taking into consideration the current effectiveness of mitigating measures in place.

Control Environment Effectiveness

The effectiveness of the existing control environment must be rated based on21

the 5 point scale

provided in Table A-5.

Control environment effectiveness is expressed as the strength of the overall control

environment towards mitigation of the given risk. The primary indicator for the rating shall

be the design and operating effectiveness of controls in place, however, other factors that

influence the overall control environment should be considered as well, including:

Level of process formalization, stability and maturity; Sufficiency of staffing levels, skills and training; Existence, maintenance and adequacy of policies and procedures; Overall risk culture and risk awareness of employees; Quality and effectiveness of entity level controls, IT general controls; Quality of the control testing process and length of time since controls were last tested;

and Process and control complexity, including the nature and extent of professional judgment

and management involvement.

When making a determination of the design and operating effectiveness of controls in place all

existing information available should be considered to support any conclusions, including:

Operational loss events; Results of most recent control testing; Results provided by the Compliance and Risk Maturity matrix (for Compliance risks); Results of internal audits; and Results of third-party audits or reviews (e.g. external auditors, consultants or regulators).

21Use of the term “based-on” means it is not required that the exact, detailed rating matrix provided in Table A-5 be used during

the RCSA – OEs are free to apply a consolidated version of this rating matrix for purposes of the actual risk assessment.

However, any consolidated versions used must be based on a 1-5 scale and fully consistent with the Table in A-5.

ALZ.0001.0097.3487

Table A-5: Rating for Control Environment Effectiveness

Fair I Defined

The underlying process is new or highly unstable and not dearly defined. If some processes exist they are ad hoc and potentially incomplete.

The underlying process and controls exist but they are unstable, not clearly defined. incomplete and/or heavily dependent on manual execution or interven ion.

The underlying process and controls are fairly stable, clearly defined and complete but must occasionally be updated.

The underlying process and controls are stable, clearly defined, effective and complete. They are fully governed by documented policies and procedures.

The underlying process and controls are highly stable and well established in governing policies and procedures. Where possible, controls have been automated (i.e. system controls) to reduce the likelihood of control failure.

Risk owners do not acknowledge or understand their responsibility to mitigate opera ional risks. Insufficient staff is in place to property execute the process and controls, staff lacks he required level of skills and training, and/or high staff turnover exists.

Risk owners do not dearly understand their responsibility manage operational risks. although heir actions demonstrate that they actually do so bUt in an inconsistent manner. Insufficient staff is in place to property execute the process and controls. or sufficient staff is present. but a large portion of the staff is new, not ideally qualified or otherwise inexperienced. Moderate turnover exists and is a frequent obstade towards consistently being able to execute the underlying process and controls at an acceptable level of quality.

Risk owners are aware of their responsibility to mitigate operational risks, but perhaps do not, or are unable to, translate this awareness into decision making, process and control improvements, etc. as consistently as they would prefer. Sufficient staff exists to property execute he process and controls, but a number of staff are new, not ideally qualified or o herwise inexperienced. A number of process steps or key controls are dependent on single individuals and it would cause a minor disruption were one of these individuals to leave the team or otherwise be unavailable. Moderate turnover exists. but is for he most part manageable.

Risk owners dearly understand their responsibility to mitigate opera ional risks. They are able to consistently translate this awareness into decision making, process and control improvements. Sufficient staff exists to property execute the process and controls and staff is, With a few exceptions. well trained to carry out each other's responsibilities in the event that someone leaves the team or is otherwise unavailable. staff is adequately ualified and turnover is low.

Risk owners have a strong appreciation and understanding of their responsibility to mitigate opera ional risks and are able to demonstrate proactive instances of doing so. Sufficient staff exists to property execute the process and controls and staff is well trained to carry out eaeh other's responsibilities in the event that someone leaves the team or is otherwise unavailable. staff is highly qualified and turnover exceptionally low.

Integrated Risk and Control System Guideline - v1.0, 24.04.2017

No risk mitigation activities I controls are operating or existing. If some mitigation ac ivities occur they are ad hoc and incomplete. Operational losses occur on a regular basis.

There have been frequent risk mi iga ion activity I control failures, or the risk mitigation actiVities I controls are found to be unsatisfactOI)' or incomplete. Some controls may be in place, but are not continuously applied, or efficient. Associated Entity Level Controls and IT General Controls are incomplete or numerous deficiencies are known to exist. Control testing is either rarely performed or not performed at all. In general the quality of any control testing and/or independence of control testers is poor. Numerous and/or significant audit findings are present, or audit findings remain unresolved subsequent to the passing of any established remediation deadlines. Operational losses occur on a relative fr uent basis. Risk mitigation activities I controls are in place, and continuously applied, but there may be minor instances of risk mitigation activity I control failures. Some risk mi iga ion activities I controls may are well placed and efficient but are not able to automatically adjust to Changes in the environment. Associated Entily Level Controls and IT General Controls are established, but some minor deficiencies are known to exist. Control testing is performed, but not on a regular basis (e.g. the most recent control testing was more than 5 years ago). The quality of control testing varies between rigorous control testing by well qualified independent parties and self-assessment by individuals with a limited understanding of control testing. Audit findings are present, but limited in number or significance and established plans to remediate any findings are adhered to. o rational losses sometimes occur but not with an re ulari Risk mitigation activities I controls are effective, continuously applied and well placed with some relatively isolated instances of risk mitigation failures. Very few risk mitigation activities I controls are neither efficient nor able to automatically adjust to Changes in the environment. Controls are regularly tested. Entity Level Controls and IT General Controls are established, regularly tested and known to be effective. Recent audit results were indicative of a strong control environment, with very few findings, if any, related to the control environment. Operational losses rare occur.

Risk mitigation activities I controls are effective, continuously applied and well placed with extremely limited instances of risk mitigation activity I control failures. All risk mitigation activities I controls are efficient and able to automatically adjust to Changes in the environment. Entily Level Controls and IT General Controls are well established, regularly tested and known to be effective. Controls are regularly subject to independent, high.quality control tes ing covering both control design and opera ing effectiveness. Operational losses only occur on an excep ional basis or not at all .

ALZ.0001 .0097.3488

The basics of an adequate risk culture are not firmly and consistently embedded into the associated function.

Risk culture and risk awareness is embedded into the associated function. but some key aspects of the risk culture could be improved or gain broader acceptance.

Risk culture and awareness is well embedded into the associated function, although minor improvements might be made,

Risk culture and awareness is firmly embedded into the associated function

49

1-in-20 Year Impact

A 1-in-20 year impact must be assessed for each risk in-scope of the RCSA as a specific monetary value and then translated into a rating using the 5 point scale provided in Table A-6.

The 1-in-20 year impact is expressed as the largest expected operational loss22 over a 20 year period from a single occurrence of the given risk.

The rating is determined by comparing the 1-in-20 year impact to a base materiality.

• The base materiality is input into the Business Entity objects of ORGS and updated by Group Risk on an annual basis (in consultation with OEs).

• The default basis for materiality is the average midterm (i.e. three year) planned IFRS operating profit (before tax), however an alternative basis may be proposed by OEs to Group Risk.

ALZ.0001.0097.3489

• If an alternative basis is proposed, Group Risk will assess the appropriateness of the basis and provide the OE with a decision on whether the proposed basis will be accepted and input into ORGS.

Table A-6: Rating for 1-in-20 Year Impact

Label Materiality basis

< 0.5 %

0.5% to3%

3% to7%

7% to 15%

> 15%

Historical precedence in the form of internal and external loss data must be taken into account when determining the 1-in-20 year impact. In addition, other factors that drive the impact should be considered as well, for example laws concerning maximum penalties or fines, assumptions concerning the number and duration of employees, customers or systems impacted, etc.

While assessment of the 1-in-20 year impact should be performed on an actual (or residual) basis, it should also be assumed that the worst case over a 20 year period might involve a certain level of control failure. This should not be interpreted to mean a complete absence of controls, but rather, for example, a failure in one or two key controls with other mitigating controls or activities ultimately limiting the final impact.

22 . . . . . . . . . . . . Operational loss 1n this context shall be interpreted to mean consistent with the descnpt1on of quahfymg losses established m

the Operational Risk Event Capture Guideline.

Integrated Risk and Control System Guideline -v1.0, 24.04.2017 50


Reputational Impact

Reputational impact must be rated based on23

the 5 point scale provided in Table A-7.

In the context of the IRCS reputational impact is expressed as the expected impact to

stakeholder awareness following the occurrence of a reasonably severe scenario for the

given risk (i.e. a 1-in-20 year event).

Where the detailed rating matrix provided in Table in A-7 is applied the approach for generating

the overall reputational risk rating requires two steps. The first step is to perform a detailed

evaluation of awareness impacts for each the 6 stakeholder groups defined in the Reputational

Risk Assessment Matrix at Table x. The second step is to apply professional judgement, taking

into account the detailed evaluation results, to generate the overall 1-5 rating.

The assessment of reputational impact should be distinguished from costs directly attributable

to maintaining or restoring reputation after a boundary operational risk event, which should be

reflected in the assessment of expected financial impact.

23

Use of the term “based-on” means it is not required that the exact, detailed rating matrix provided in Table A-7 be used during

the RCSA – OEs are free to apply a consolidated version of this rating matrix for purposes of the actual risk assessment.

However, any consolidated versions used must be based on a 1-5 scale and fully consistent with the Table in A-7.

ALZ.0001.0097.3490

Table A-7: Rating for Reputational Impact

Small number of people/no important group affected

Larger number of people/small number of important groups affected

Majority of people/significant number of important groups affected

- Low level local or special media awareness (ind. limited web) - No cnange in analysts' recommendations

- National or special media awareness - No cnange in analysts' recommendations

- Long-term national/short-term international media awareness - Critical artides in national financial press - No cnange in analysts' recommendations

- Financial results are adversely affected by reputational event - Critical artides in international financial press - High shOrt-term na ional/intemational media awareness (cover stories) - A few analySts downgrade their recommendations. - AZ is removed from portfolios/investment universe by some specialized ESG-investors

- Repeated. very cri ical articles in international financial press - High long-term national/international media awareness (cover stories) - Many analysts reduce target prices and downgrade heir recommenda ions - AZ is removed from portfolios/investment universe by some important institutional investors

Integrated Risk and Control System Guideline - v1.0, 24.04.2017

- Low level local or special media awareness (ind. limited web) - No important customer/significant number of customers at riSI<

- Regional or special (ind. broader web) media awareness/impact on minor customer groups - Marginal impact on product quality - customers become aware of problem, but only small number of existingfnew customers at risk

- Long-term national/short-term international media awareness - Topic-related impact on sensitive customer groups - Some impact on product quality - Risk of significant lapses/loss of targeted new customers, as significant impact on customers

- Challenge on AZ brand/"Trust• - High short-term na ional/intema ional media awareness (cover stories) - High impact on product quality - Risk of large number of lapses I huge loss of targeted new customers

- High long-term national/international media awareness (cover stories) - Very high impact on product quality - Huge loss of "Trust" in AZ products across all important customer groups - Risk of very large number of lapses I very huge loss of targeted new customers

- campaign or heightened attention by minor/regional NGOs

- Some negative attention by international and highly influential NGOs

- campaign or heightened attention by a single international and highly influential NGO.

- campaign or heightened attention by a coalition of international and highly influential NGOs.

- Low level local or special (ind. limited web) media awareness - No impact on attractiveness of AZ for business partners

- Marginal impact on attractiveness of AZ for business partners

- Long-term national/short-term international media awareness - Topic-related impact on sensitive business partners - Some impact on attractiveness of AZ for business partners

- Significant loss of attractiveness of AZ for major business partners

- Significant loss of attractiveness of AZ for a significant number of business partners

ALZ.0001 .0097.34 91

- Strong non- - Moderate public criticism negative impact on by regulator or trusVmotiva ion of industry body certain groups of

employees

- Public criticism - Strong topic-by regulator or related impact on industry body trusVmotiva ion of

some sensitive staff

- Low-scale - Serious regulatory action challenge to trust

and motivation of majority of mid-management and staff

- High-scale - Huge loss in regulatory action confidence by mid-- Government management and action staff

52


APPENDIX B – IRCS Catalogue

The IRCS Catalogue is available on Allianz Connect (link pending) or by contacting any member of the Group Risk ORM & Policies Team.

APPENDIX C – IRCS Scoping Flowchart

The following decision flowchart shall be used to support determination of the appropriate level for scoping. Refer to section C.I Scoping

ALZ.0001.0097.3492

Document Information:

Document: Integrated Risk and Control System Guideline

Author(s): Group Risk - ORM & Policies Team

Contact Person(s): Claudia Meyer

Area of Application: Allianz Group

Amendments and Updates:

Version Date

1.0 24.04.2017

Reason for and Extent of Changes

First version of Guideline

Integrated Risk and Control System Guideline -v1.0, 24.04.2017

Author(s)

Maurice LeBlanc

ALZ.0001.0097.3493

54

Documents

Integrated Risk and Control System Guideline · 2019-11-24 · Integrated Risk and Control SystemGuideline –v1.0, 24.04.2017 5 1. Single harmonized IRCS framework established for