integrated risk and control system guideline · 2019-11-24 · integrated risk and control...
TRANSCRIPT
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
Integrated Risk and Control System Guideline –v1.0, 24.04.2017 4
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
Integrated Risk and Control System Guideline –v1.0, 24.04.2017 5
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
Integrated Risk and Control System Guideline –v1.0, 24.04.2017 6
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
Integrated Risk and Control System Guideline –v1.0, 24.04.2017 7
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
Integrated Risk and Control System Guideline –v1.0, 24.04.2017 8
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
Integrated Risk and Control System Guideline –v1.0, 24.04.2017 9
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
Integrated Risk and Control System Guideline –v1.0, 24.04.2017 10
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
Integrated Risk and Control System Guideline –v1.0, 24.04.2017 11
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
Integrated Risk and Control System Guideline –v1.0, 24.04.2017 12
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
Integrated Risk and Control System Guideline - v1.0, 24.04.2017 13
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
Integrated Risk and Control System Guideline - v1.0, 24.04.2017 14
Integrated Risk and Control System Guideline –v1.0, 24.04.2017 15
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
Integrated Risk and Control System Guideline –v1.0, 24.04.2017 16
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
Integrated Risk and Control System Guideline –v1.0, 24.04.2017 17
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
Integrated Risk and Control System Guideline –v1.0, 24.04.2017 18
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
Integrated Risk and Control System Guideline –v1.0, 24.04.2017 19
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.
Integrated Risk and Control System Guideline - v1.0, 24.04.2017 20
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
Integrated Risk and Control System Guideline –v1.0, 24.04.2017 22
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
Integrated Risk and Control System Guideline –v1.0, 24.04.2017 23
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
Integrated Risk and Control System Guideline - v1.0, 24.04.2017 25
Integrated Risk and Control System Guideline –v1.0, 24.04.2017 26
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
Integrated Risk and Control System Guideline –v1.0, 24.04.2017 27
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.
Integrated Risk and Control System Guideline - v1.0, 24.04.2017 28
Integrated Risk and Control System Guideline –v1.0, 24.04.2017 29
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.
Integrated Risk and Control System Guideline –v1.0, 24.04.2017 30
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.
Integrated Risk and Control System Guideline - v1.0, 24.04.2017 31
Integrated Risk and Control System Guideline –v1.0, 24.04.2017 32
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
Integrated Risk and Control System Guideline –v1.0, 24.04.2017 33
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
Integrated Risk and Control System Guideline –v1.0, 24.04.2017 34
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
Integrated Risk and Control System Guideline –v1.0, 24.04.2017 35
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
Integrated Risk and Control System Guideline –v1.0, 24.04.2017 36
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
Integrated Risk and Control System Guideline –v1.0, 24.04.2017 37
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
Integrated Risk and Control System Guideline –v1.0, 24.04.2017 38
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
Integrated Risk and Control System Guideline –v1.0, 24.04.2017 39
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
Integrated Risk and Control System Guideline - v1.0, 24.04.2017 40
Integrated Risk and Control System Guideline –v1.0, 24.04.2017 41
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
Integrated Risk and Control System Guideline –v1.0, 24.04.2017 42
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
Integrated Risk and Control System Guideline –v1.0, 24.04.2017 43
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
Integrated Risk and Control System Guideline - v1.0, 24.04.2017 44
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.
Integrated Risk and Control System Guideline - v1.0, 24.04.2017 45
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.
Integrated Risk and Control System Guideline - v1.0, 24.04.2017 46
Integrated Risk and Control System Guideline –v1.0, 24.04.2017 47
(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
Integrated Risk and Control System Guideline –v1.0, 24.04.2017 48
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
Integrated Risk and Control System Guideline –v1.0, 24.04.2017 51
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
Integrated Risk and Control System Guideline –v1.0, 24.04.2017 53
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