Skip to main content

​
Own-Risk Assessment (ORA)

The ORA requirement derives from Article 28 of IORP II (EU 2016/2341) and is transposed in Irish law as Section 64AL of the Pensions Act 1990 (as inserted by the Pensions (Amendment) Act 2022, implementing S.I. 128/2021). Trustees must conduct and document an ORA at least every three years, or following any significant change in the scheme’s risk profile. The ORA is one of the most substantive governance deliverables under IORP II. It is the primary mechanism by which the trustee board demonstrates that it has conducted a thorough, forward-looking assessment of the risks the scheme faces — and that governance and investment decisions are informed by that assessment.
The Pensions Authority has published specific ORA guidance for trustees: Own Risk Assessment — Pensions Authority. Trustees should read this alongside Section 64AL of the Pensions Act and Article 28 of IORP II. PensionPortal.ai’s ORA workflow is structured to address every element of the Pensions Authority’s guidance.

​
What the ORA Must Cover

Article 28(2) IORP II specifies that the ORA must cover, at minimum:
  • The overall risk profile of the scheme, covering all material risks
  • The risk tolerance and risk appetite of the scheme
  • A forward-looking assessment of risks to members and beneficiaries
  • Both qualitative and, where appropriate, quantitative assessment of risks
  • The interdependency between different risk categories
  • Links to the investment strategy and funding strategy
  • The effectiveness of risk mitigation measures in place
The ORA must be conducted in a manner proportionate to the nature, scale, and complexity of the scheme. However, proportionality affects the depth of analysis — not whether the analysis is done.

​
ORA Methodology: What a Quality ORA Looks Like

A quality ORA is not a generic risk assessment. It is a scheme-specific, forward-looking document that demonstrates genuine trustee engagement with the risks facing the scheme and its members. The Pensions Authority can readily distinguish between a substantive ORA and a template document that has been minimally adapted.

​
How an ORA Differs from a Generic Risk Assessment

Generic Risk Assessment

A list of risks with likelihood and impact scores. Applies to any organisation. Does not reference the specific scheme’s investment strategy, funding position, membership profile, or sponsor. Could have been written without any knowledge of the scheme.

Compliant IORP II ORA

A forward-looking, scheme-specific analysis that links each risk to the scheme’s actual circumstances. References the scheme’s investment strategy, actuarial assumptions, sponsor covenant, membership profile, and governance arrangements. Demonstrates that the trustee board has actively considered each risk and the adequacy of existing controls.
Characteristics of a quality ORA:
  1. Scheme-specific data: The ORA references the scheme’s actual investment portfolio, funding level, membership profile, and sponsor financial position
  2. Forward-looking: The analysis considers how risks may evolve over the scheme’s time horizon — not just current conditions
  3. Integrated: The ORA links to the investment policy and (where applicable) the funding strategy, evidencing that risk appetite is reflected in strategic decisions
  4. Evidenced: Risk assessments are supported by data and analysis, not just assertions
  5. Board-owned: The ORA is formally presented to and discussed by the trustee board, with the discussion recorded in board minutes
  6. Actionable: Where risks are identified as elevated, the ORA specifies the actions the board will take, with owners and timelines

​
The 8 Risk Categories Trustees Should Consider

The following risk categories align with the Pensions Authority’s ORA guidance and the requirements of Article 28 IORP II. Every ORA should address each category, with the depth of analysis proportionate to the category’s materiality for the specific scheme.
The risk that investment returns are insufficient to meet the scheme’s objectives, including the risk of permanent capital loss. Trustees should assess: asset allocation and its alignment with risk appetite; concentration in any single asset class, sector, or geography; exposure to illiquid assets; currency risk; use of derivatives; and the appropriateness of the investment strategy given the scheme’s liability profile and time horizon.ORA questions: Is the current investment strategy consistent with the scheme’s risk appetite and liability profile? What is the maximum loss the scheme could sustain without jeopardising member benefits? How does the investment strategy perform under stress scenarios?
The risk that the scheme cannot meet cash flow requirements — contribution inflows, benefit payments, expense payments — without being forced to liquidate assets at unfavourable prices. Trustees should assess: the scheme’s cash flow profile; the liquidity of its investment portfolio; the adequacy of liquidity buffers; and the liquidity implications of any derivative positions.ORA questions: Can the scheme meet projected benefit payments over the next 12 months without forced asset sales? What is the scheme’s exposure to gating or suspension in illiquid fund investments?
The risk arising from lack of diversification — concentration in a single asset, issuer, counterparty, market, sector, or geographic region. Concentration risk amplifies losses when a concentrated position deteriorates.ORA questions: Is the scheme’s portfolio adequately diversified? Are there any single exposures (issuer, counterparty, fund) that represent a material proportion of scheme assets? How would the scheme’s funding position be affected by the failure of its largest single exposure?
The risk of loss from inadequate or failed internal processes, people, systems, or external events. For a pension scheme, this includes: errors in benefit administration; data quality failures; IT system outages; fraud; and the failure of key service providers. Operational risk is particularly relevant to OMAs and smaller schemes where governance resources are limited.ORA questions: Are there adequate controls over benefit administration processes? Is the scheme’s data accurate and secure? What would be the impact of the scheme administrator becoming unavailable? Are outsourced providers subject to adequate oversight?
Where the scheme uses insurance or other risk mitigation instruments (e.g., interest rate swaps, longevity swaps, insurance policies covering biometric risks), the ORA must assess the effectiveness of these mitigants, their cost, and any residual risks they do not cover. The ORA must also consider the credit risk of the counterparty providing the mitigation.ORA questions: Are existing risk mitigation instruments performing as expected? Is the cost of the mitigation proportionate to the risk being covered? What is the credit quality of the insurer or counterparty?
Environmental, social, and governance (ESG) factors can create financial risks that affect scheme asset values and liabilities. Climate-related risk is a particular focus for regulators. IORP II Article 30 requires the investment policy to address ESG risks. The ORA should assess how ESG risks are reflected in the investment strategy and whether they are adequately managed.ORA questions: How does the scheme’s investment portfolio perform under climate transition scenarios? Is the scheme exposed to stranded asset risk? How are ESG risks incorporated into manager selection and monitoring?
Trustees must consider risks that are not yet fully understood or that may materialise over the scheme’s time horizon. Current emerging risks include: cyber security threats to pension data; AI-related operational risks; geopolitical risks affecting investment markets; and regulatory change risk (new legislative requirements).ORA questions: What new risks have arisen since the last ORA? Are there horizon risks that could materially affect the scheme’s position? How is the scheme monitoring for emerging risk?
For schemes where the employer (sponsor) is expected to make ongoing contributions, the sponsor’s financial capacity to meet those obligations is a fundamental risk. Sponsor insolvency can leave members with a funding shortfall. Sponsor risk assessment should consider the sponsor’s financial position, industry exposure, and the diversification of the sponsor’s business.ORA questions: How financially strong is the sponsoring employer? How dependent is the scheme on sponsor contributions? What would be the impact on the scheme if the sponsor were to become insolvent? Is there a recovery plan in place?

​
ORA Documentation Requirements

The written ORA record must contain:
  1. Date of the ORA and the names of the trustees who participated in the process
  2. Scope confirmation: confirmation that all required risk categories were considered
  3. Scheme-specific data used as inputs (membership profile, funding level, investment portfolio summary, actuarial data as applicable)
  4. Risk assessment for each category: risk identification, likelihood/impact assessment, current controls, residual risk rating
  5. Forward-looking analysis: how each risk may evolve over the scheme’s time horizon
  6. Links to investment strategy and funding policy: evidence that the ORA informs strategic decisions
  7. Actions arising: where elevated risks are identified, specific actions assigned to named individuals with due dates
  8. Board sign-off: formal record of the trustee board’s review and approval of the ORA, including the date of board sign-off
  9. Version control: document version number, date, and history of previous ORA versions

​
Who Signs Off the ORA

The ORA must be formally reviewed and approved by the trustee board. While the Risk Management KFH leads the ORA process and drafts the report, the ORA is a board document — not a KFH deliverable. The board’s review and sign-off must be recorded in board meeting minutes, which form part of the compliance evidence trail. The ORA does not stand alone. It must be linked to:
  • The investment policy: risk appetite identified in the ORA must be reflected in the investment strategy
  • The risk management policy: the ORA methodology must be consistent with the documented risk management framework
  • The risk register: risks identified in the ORA should be captured in the scheme’s ongoing risk register, owned by the Risk Management KFH

​
The 3-Year Review Cycle and Trigger Events

Trustees must conduct a new ORA at least every three years. However, certain events require an earlier review regardless of when the last ORA was completed:
Trigger EventWhy It Matters
Significant change in investment strategyA new asset allocation or investment mandate changes the scheme’s risk profile materially
Major sponsor eventSponsor restructuring, ownership change, financial distress, or insolvency significantly changes sponsor risk
Material change in membership profileA large bulk transfer, scheme merger, or significant change in active/deferred/pensioner mix affects cash flow and liability profile
Significant funding level changeA material deterioration (or improvement) in the funding level alters the risk landscape
Regulatory changeNew legislative requirements may create compliance risk not captured in the existing ORA
Material operational failureA significant operational incident (fraud, data breach, administrator failure) triggers a reassessment of operational risk
Significant market eventAn extreme market event that affects the scheme’s investment portfolio may require an updated risk assessment
Trustees who complete an ORA and then experience a trigger event must conduct a fresh ORA — they cannot rely on the three-year cycle if circumstances have changed materially. The Pensions Authority will assess whether the ORA reflects the scheme’s current risk profile at the time of any supervisory review.

​
How PensionPortal.ai Automates ORA

PensionPortal.ai’s ORA workflow reduces the time and effort required to produce a compliant, board-ready ORA — while maintaining the quality and scheme-specificity that the Pensions Authority requires.
1

Data Import

Scheme data — membership statistics, funding level, investment portfolio summary, actuarial data — is imported directly into the ORA workflow. This ensures the ORA reflects the scheme’s actual position rather than generic assumptions.
2

Risk Category Assessment

The Risk Management KFH works through each of the 8 risk categories using the PensionPortal.ai structured assessment framework. Each category is assessed for likelihood, impact, and control effectiveness. The framework is aligned with the Pensions Authority’s ORA guidance.
3

AI-Assisted Narrative Generation

PensionPortal.ai generates a structured narrative draft for each risk category based on the assessment inputs. The AI-assisted narrative is a starting point — not a final document. Every section requires human review and editing by the KFH to reflect the specific circumstances of the scheme.
4

Human Review Gate

Before the ORA can proceed to the board sign-off stage, the Risk Management KFH must explicitly confirm that they have reviewed and approved each section of the ORA. This gate cannot be bypassed. PensionPortal.ai records the KFH’s review confirmation with a timestamp.
5

Board Presentation and Sign-Off

The completed ORA draft is formatted as a board-ready report and added to the board pack. The trustee board reviews the ORA at a formal board meeting. The board’s approval is recorded in PensionPortal.ai, creating a timestamped sign-off record that forms part of the compliance evidence trail.
6

Version Control and Evidence Storage

The signed-off ORA is stored in immutable version-controlled storage. Previous ORA versions are retained and accessible. The ORA is included in the scheme’s supervisory review evidence pack export.

​
Pensions Authority References

  • ORA Guidance for Trustees — Pensions Authority
  • Code of Practice for Trustees (Final), Section 6 — ORA requirements
  • IORP II Directive, Article 28: Own Risk Assessment
  • Pensions Act 1990, Section 64AL: Own Risk Assessment (as inserted by Pensions (Amendment) Act 2022)
  • S.I. 128/2021, Regulation 29: ORA implementation