Significant event (j)

This guidance explains when a failure of a system or process used to run a master trust may need to be reported as a significant event J. It covers the test for reporting, how to assess significant adverse effect, when and how to notify us, who has reporting duties, and examples using a red, amber and green traffic-light approach.

Published: 13 October 2026

What a significant event (j) (SEJ) is

A significant event (j) is a failure of the systems or processes used to run a master trust that has a significant adverse effect on the security or quality of data, or on service delivery.

In all circumstances, the test for whether something should be reported as an SEJ is that:

There is a system or process in place for the running of a scheme.
There has been a failure of that system or process.
The failure has had a significant adverse effect on:
- the security of data
- the quality of data
- service delivery

What constitutes significant adverse effect

Below is a non-exhaustive list of areas to consider when judging whether a failure of the systems or processes has had a significant adverse effect:

nature of the data or service involved
criticality to member outcomes
duration of the failure
one off event or part of a pattern
how many members were impacted
severity of effect
member detriment

When considering whether an event is an SEJ you should note that:

It is not necessary for all of the above areas to be engaged for an event to qualify as an SEJ. The factors connected to any single area may be severe enough to constitute a significant adverse effect.
There does not need to have been a significant adverse effect on the whole scheme.
There is no specific minimum number of members which must be impacted for an event to have had a significant adverse effect.
Relevant factors should also be considered for any cumulative effects, ie minor to moderate impact on multiple areas may combine to cause a significant adverse effect when viewed holistically.

Factors that are more likely to indicate significant adverse effect include:

The involvement of personal or sensitive data.
Services related to the processing of core financial transactions or statutory member communications.
The involvement of other key services (including but not limited to member feedback channels or other products or features required to be provided under statutory requirements).
Longer duration of event including a failing of internal controls to quickly identify and escalate the matter. A failing or issue which has persisted for a long period without being identified could create an additional or exacerbating factor as it may be indicative of another systems or process failure, such as failures relating to monitoring and oversight.
Where an incident is part of a series or pattern of events and the impact viewed cumulatively has a significant adverse effect.
A significant number of members were impacted.
Detriment to members, whether financial or non-financial.

Schemes should take a prudent approach when determining if there has been a significant adverse effect. We recommend keeping a clear audit trail of decisions about whether or not to report an event.

How many members were impacted – scale

In considering how many members were impacted, schemes often refer to the percentage of members affected as being the core consideration for whether an event should be reported to TPR. This includes judging how many members were impacted by comparing the number of members impacted to the scheme’s overall membership. This is not always the most useful or relevant metric to use. Best practice would be to consider how many members were impacted based on the actual number of members impacted.

How many members were impacted should also be considered on a cohort basis (such as by age, active or deferred, fund, employer, retirement stage, investment fund, vulnerability, or other).

Non-financial detriment

The failure to issue statutory communications can result in non-financial detriment as it leaves members unaware of their rights or choices, depriving them of the opportunity to make informed decisions about their pensions.

Non-financial detriment can also occur where data security is compromised, such as sending member communications to incorrect postal addresses. Such errors may increase members’ risk of suffering identity fraud or other financial harms. However, even without direct financial loss, it infringes on the members right to privacy and can cause non-financial detriment.

In some instances, a failing of systems or processes may have an initial positive impact on members’ pot values. For example, an incorrectly allocated life-styling approach may perform better than the ‘correct’ life-styling approach that should have been followed. In some instances, we are aware that schemes put members back into the position they would have been if they had been in the ‘correct’ lifestyle (or other investment choice). There is potential for such instances to cause non-financial detriment. This is because members may have received inaccurate information about their pot value whilst the error was outstanding, whether by logging into a member portal or through the annual benefit statement. Members receiving inaccurate information about their benefits has the potential to cause a significant adverse effect.

Some examples of non-financial detriment include:

having inadequate time to make a decision or an inability to make a decision
having inaccurate information upon which to make a decision
experiencing delayed or interrupted service
experiencing poor service
data rights and/or privacy infringements
administrative mistakes
access issues to online portals

Causes of significant events

Manual activities are part of a scheme’s systems and processes, therefore errors arising from human errors can constitute an SEJ. The key consideration is the effect on data security, data quality, or service delivery, rather than the root cause. Because manual processes carry a risk of human error, appropriate checks and controls should be in place to detect and correct errors promptly.

Some incidents which adversely affect the security or quality of data, or service delivery, may to some degree be caused by the failings of third-parties, such as an employer providing a large number of incorrect email or postal addresses. In this example, the scheme’s systems or processes should have included effective controls to identify, rectify and monitor such issues.

Fraud

Instances of fraud can qualify as an SEJ where the systems and processes of the scheme have failed, and the fraudulent event has had a significant adverse effect. Not all instances of fraud are reportable as SEJs but all instances of fraud should be reported in line with this industry report and our guidance on scams.

Regular review of patterns of events

A pattern of events which when viewed individually did not have a significant adverse effect, but viewed cumulatively, did cause significant adverse effect, would be an SEJ. To ensure such SEJs are identified, schemes should review all incidents regularly, including those that may have initially been considered green and amber events. Those reviews should consider operational resilience and scalability of systems and processes. We encourage taking a thematic approach in your analysis of your systems and processes failures in addition to addressing any particular incident. Conducting these regular reviews could take place using existing governance and monitoring processes or may require a bespoke process – schemes should use their judgement on how to identify patterns efficiently.

When considering if an event is part of a wider pattern of events, we expect schemes to take a broad and prudent view and look to connect similar incidents even where the specific facts of individual incidents may vary. For example, where one incident was a failure to send member communications and another incident was the late sending of member communications, this would form part of a pattern of failures in the general provision of timely member communications. In the same way, schemes should bear in mind the cumulative impact of multiple instances of trivial financial detriment.

Schemes should take a proportionate and reasonable approach to judging the appropriate timeframe over which to monitor for patterns. This is likely to vary depending on the nature of the event.

Once you become aware a pattern of events has occurred, which resulted in a significant adverse effect, you must report an SEJ as soon as reasonably practicable. We also encourage regular discussion of events which were not an SEJ with your supervisory team as part of an open and transparent relationship.

Use our traffic light system to help you decide what to notify us of

Our traffic light system, which includes illustrative examples, is designed to help you identify reportable SEJ instances. In all examples, you will need to assess whether a significant adverse effect has occurred. As soon as the person with a duty to report has the minimum information necessary to determine that an event has had a significant adverse effect, the obligation to report the event as an SEJ is triggered. Where an obligation to notify us arises, the red or amber rating of an event does not impact the timing of that obligation.

Red event

These are events which must be reported to us where there has been a significant adverse effect on the security or quality of data or on service delivery. You will need to apply all of the relevant factors including those detailed above in ‘What constitutes significant adverse effect’ to determine whether there has been a significant adverse effect on the security or quality of data or on service delivery. If you conclude a significant adverse effect has occurred, you must report the event to us.

Amber event

These are events where it is not clear whether a significant adverse effect has occurred because the facts available are less clear cut. To assist in making that determination, the context of the event should be considered, taking into account the non-exhaustive factors outlined below. If after consideration of the facts and circumstances, it is determined a significant adverse effect on the security or quality of data or service delivery has occurred, you must report the event to us.

Green event

These are events which do not have to be reported if there has not been a significant adverse effect on the security or quality of data or on service delivery.

Illustrative examples of red, amber and green events

The examples given below are illustrative and are not exhaustive. Any perceived lack of resemblance between an incident and the examples below should not be taken to mean that an incident is not an SEJ.

For ease of illustration, we have broadly categorised the examples as failures which have a significant adverse effect on security of data, quality of data, or service delivery. In practice, failures may have a significant adverse effect on a combination of those three categories. Likewise, in practice, the particular facts of an event may fall into a different category than suggested below.

Red event: This is an event that must be reported where there has been a significant adverse effect

Illustrative example of failures of the systems or processes used in running the scheme which have a significant adverse effect on the security of data:

A breach of cyber security resulting in the loss of the availability or control of your IT systems or an incident that results in unauthorised access to, or malicious software present on, your information and communication systems.

Illustrative examples of failures of the systems or processes used in running the scheme which have a significant adverse effect on the quality of data:

Corruption of member records or other incidents causing member data loss.
A failure in transition processes, onboarding processes, update processes or other events leading to significant inaccuracies or omissions in member records.

Illustrative examples of failures of the systems or processes used in running the scheme which have a significant adverse effect on service delivery:

Late issuance of or a failure to send member communications including but not limited to: basic scheme information, automatic enrolment and re-enrolment, opt-out rights, material alterations to basic scheme information, materially significant payment failures, black-out periods, or statutory member communications which directly impact member decision making.
A failure to conduct a consultation or obtain members consent in accordance with statutory requirements.
A failure to process core financial transactions into and/or out of the scheme.
A failure in controls resulting in members funds being invested outside of the range of permitted investments.
A failure in systems or processes leading to an unauthorised individual obtaining funds through fraud.
A failure in systems and processes involving ‘standing’ data which results in an investment fund being required to recalculate its unit price, restate/calculate its net asset value or restate its performance. Reference to ‘standing data’ in this context refers to core static information which is updated only when a fundamental attribute changes, and is used repeatedly in every valuation cycle. It includes but is not limited to data such as:
- fund identifier
- fund name
- legal structure
- fund domicile
- base currency
- fee schedule

Amber event: This is an event that is less clear cut, you will need to consider the context of the event to determine whether a significant adverse effect has occurred

Illustrative examples of failures of the systems or processes used in running the scheme which have a significant adverse effect on the security of data:

Member data was accessible to persons other than the member via the scheme app, website or other digital platform. Factors to consider when deciding whether to report include but are not limited to:
- nature of the data (the involvement of sensitive/ personal data would be more likely to be significant)
- whether data was in fact accessed (if not known at the time of reporting, or it is known that data was accessed, it would be more likely to be significant)
- how long the error persisted
- how many members were impacted
Data Protection Act breaches. Factors to consider when deciding whether to report include but are not limited to:
- nature of the data (the involvement of sensitive/ personal data would be more likely to be significant)
- how many members were impacted
Sending member communications containing personal and sensitive data to incorrect postal addresses where the scheme should reasonably have known that the addresses were incorrect (for example, if an employer had provided updated addresses or if the scheme’s system or process mixed up members and sent communications to the wrong members). Factors to consider when deciding whether to report include but are not limited to:
- nature of the data (the involvement of sensitive/ personal data would be more likely to be significant)
- amount of sensitive or personal data in the communications
- whether a bad actor may be able to access the member’s pension account using data in the communications
- likelihood of other communications having been sent to an incorrect address (if the incorrect address was a previous address, it is more likely that other communications may have been incorrectly sent to the previous address, increasing the risk to members which would make the event more likely to be significant)
- how many members were impacted

Illustrative examples of failures of the systems or processes used in running the scheme which have a significant adverse effect on data quality:

Inaccurate data relating to member benefits on a member app, website or other digital platform. Factors to consider when deciding whether to report include but are not limited to:
- degree of inaccuracy (if the difference in value between the correct member benefit and the shown member benefit was more than trivial such that it is plausible that member decision making was impacted this would be more likely to be significant)
- whether inaccurate data was in fact accessed (if not known at the time of reporting, or it is known that data was accessed, it would be more likely to be significant)
- how long the error persisted
- how many members were impacted
Inaccurate data relating to member benefits issued in postal member communications. Factors to consider when deciding whether to report include but are not limited to:
- degree of inaccuracy (if the difference in value between the correct member benefit and the shown member benefit was more than trivial such that it is plausible that member decision making was impacted this would be more likely to be significant)
- how many members were impacted

Illustrative examples of failures resulting in inaccurate member data where the scheme could reasonably have been expected to have accurate data:

where an employer or member provided updated data which was not promptly updated in the scheme records
where returned post was received by the scheme which was not recorded in the member record
where a bounce-back or other email error was received which was not recorded in the member record
where a data project identified inaccuracies in data
where two or more inconsistent records for a member existed and were not reconciled within a reasonable timeframe. This example does not refer to members holding multiple benefit entitlements in a scheme, rather, it relates to fragmented record keeping, for example, where member data is maintained across multiple systems or platforms, resulting in duplicate inconsistent records

We recognise that member data can deteriorate over time, however, where there is reason to believe that existing member data is inaccurate, we expect appropriate processes to be put in place to address inaccuracies. See our guidance Assessing member data quality for more on our expectations around maintaining member data quality. Factors to consider when deciding whether to report include but are not limited to:

nature of the data
how long the error persisted
how many members were impacted
the volume and nature of member communications issued during time which the error persisted

Illustrative examples of failures of the systems or processes used in running the scheme which have a significant adverse effect on service delivery:

A technology system outage which impacts the processing of core financial transactions or member channels of communication Factors to consider when deciding whether to report include but are not limited to:
- duration of impact
- range of services impacted
- member detriment
- scheme specific context of failings – prior proximity to a blackout or other transition may exacerbate the impact of the failing
- how many members were impacted
A failing against a service level agreement by the administrator or investment service provider. Factors to consider when deciding whether to report include but are not limited to:
- duration of failure
- severity of failure
- impact of failure
- single or multiple failures
- nature of service impacted
- how many members were impacted
- member detriment
A failure in systems or processes resulting in unanticipated or incorrect tax implications for members, including but not limited to, scenarios where unpaid tax may be clawed back from members. Factors to consider when deciding whether to report include but are not limited to:
- duration of failure
- how many members were impacted
- quantum involved
Late issuance of statutory member communications such as annual benefit statements. Factors to consider when deciding whether to report include but are not limited to:
- the length of the delay
- scheme or member circumstances (if there is time sensitive information about scheme or member circumstances or if the scheme has experienced poor performance/ other issues/ significant changes then this could be more likely to be significant)
- member profile (if impacted members were those nearer to retirement this could be more likely to be significant)
- market volatility (if there has been market volatility, this could be more likely to be significant depending on the type of member communication)
- how many members were impacted
An indication of material control failures identified by assurance reports from any source, eg internal audit reports, assurance framework reports, compliance reviews or external audits. Factors to consider when deciding whether to report include but are not limited to:
- impact of the control failure
- whether the impact of the control failure is potential or has materialised
- number of control failures identified by the report
- how long the failure persisted
- how many members were impacted
- severity of the impact
A failure resulting in member contributions not being invested as intended. Factors to consider when deciding whether to report include but are not limited to:
- impact of the error (if a positive impact would be left outstanding, this would not constitute a significant adverse effect)
- how long the error persisted
- member communications issued during time which the error persisted
- member activity during the time the error persisted (for example, if members retired, transferred out or received benefits at a lower value)
- how many members were impacted
A failure in systems and processes involving temporal data which results in an investment fund being required to recalculate its unit price, restate/calculate its net asset value or restate its performance. By ‘temporal data’ in this context, we mean data that changes daily or during the day, is time-stamped and effective for a particular valuation date and drives the day-to-day movement in net asset value. It includes but is not limited to:
- fund price
- exchange rate
- subscriptions
- redemptions
- units in issue
Factors to consider when deciding whether to report include but are not limited to:
- how long the data error persisted for
- magnitude of the error
- how many members were impacted
Incorrect fees or charges being applied to members in error. Factors to consider when deciding whether to report include but are not limited to:
- how long error persisted
- quantum of fee/ charge applied
- how many members impacted
- activity during the period where error persisted (eg any transfers out)

Green events: This is an event which is known not to have a significant adverse effect

Illustrative example of failure in the systems or processes of running the scheme which did not have a significant adverse effect on the security of data:

Singular instances of non-statutory member communications containing minimal personal data being sent to the wrong electronic or postal address.

Illustrative example of failure in the systems or processes of running the scheme which did not have a significant adverse effect on the quality of data:

Short term incidents resulting in member data (including but not limited to benefit data) being recorded incorrectly on the system, where it is known that members were never shown, notified of, or otherwise made aware of the incorrect information. No member decisions, transactions or other actions were taken, delayed or influenced while the data was incorrect, and no scheme actions, calculations, processing or other scheme processes were undertaken or affected on the basis of the incorrect data. The error was identified and corrected before any member interaction or processing occurred and therefore had no impact on members, benefits or scheme operations.

Illustrative examples of failures in the systems or processes of running the scheme which did not have a significant adverse effect on service delivery:

Extremely short term and singular unplanned service disruption to member portals or online services (which do not take place shortly before a black-out period) that were identified and remedied quickly and where:
- Alternative channels of communication with the scheme were available providing members with the same ease of access to information.
Unit price error or other temporal data error has resulted in trivial detriment and had no or minimal impact on fund performance which was identified quickly by systems, processes, controls and/ or checks as part of investment processing.
Systems or process failures leading to a permanent positive impact on member pot values where there was no non-financial detriment.
There was a one off, short-term failing against service level agreements by administrators or investment service providers that did not cause member detriment or impact service delivery.
Incident involving a short-term delay to the issuance of non-statutory member communications which do not directly impact member decision making.

When you need to notify us – timing and examples

You must notify us in writing of SEJs as soon as reasonably practicable. Paragraph 379 of Code of Practice 15 states that we expect SEJ notifications to be reported within one working day of you becoming aware of the failure. Those required to notify us of significant events should consider notifying us if they are unsure on whether to notify or not.

It is common for further information to be required following an SEJ. You should provide an update on a monthly basis using the update form. If there are any issues created by that timeframe, please discuss these with your supervisor. In some circumstances we may require updates more or less frequently than monthly.

It is not necessary to have established all of the facts before reporting an SEJ, such as the final number of members impacted. The knowledge of a single factor may be sufficient information to determine that an incident requires reporting. What is necessary is that you are aware that there has been an event involving a failure of systems or processes used for the running of the scheme, which has had a significant adverse effect on the security of data, quality of data or on service delivery. We recommend adopting a prudent approach to notification where limited facts are available and you should prioritise notifying us even if you don’t have the complete information of the event. Whilst we expect steps to identify the impact of the event to be taken promptly, such investigations should not delay the reporting of an SEJ.

If following further investigation, you identify that an event you initially reported has in fact not had a significant adverse effect on the security or quality of data or service delivery, then you can notify us that the event was not an SEJ. If we are in agreement there has not been a significant adverse effect on the security or quality of data or service delivery, we will acknowledge the update and close down our SEJ process.

We encourage early and open conversations with us about significant events. However, where the duty to notify us is triggered, you must notify us in writing. Below are scenario examples for illustration.

Scenario A

On Monday you become aware an event has taken place impacting the master trust. You do not have the complete facts, however the facts you have available show there has been a significant adverse effect. This means the obligation to notify us within one working day would start from Monday making it reportable by Tuesday.

Scenario B

On Monday you become aware an event has taken place impacting the master trust. The facts known at the time indicate that the event has not had a significant adverse effect nor is there an expectation that it could have a significant adverse effect. On Wednesday you are made aware of updated facts indicating the event has had a significant adverse effect. This means the obligation to notify us within one working day would start from Wednesday making it reportable by Thursday.

Scenario C

On Monday you become aware an event has taken place impacting the master trust. You are unsure if it is an SEJ because the available facts to date cannot determine if there has been a significant adverse effect. Further investigation is required and you should seek the minimum facts you need to determine if an SEJ has occurred. As soon as the minimum necessary facts to determine whether there has been significant adverse effect become available you should determine if the event is reportable. If you are unsure as to whether there has been significant adverse effect, it is good practice for you to inform us of the event with any available facts whilst you investigate further. This could take the form of an email – see below on ‘Investigating significant adverse effect’.

Investigating significant adverse effect

The time allowed for investigation before the notification obligation arises is the time taken to gather the minimum necessary information to determine that there has been a significant adverse effect on the quality or security of data or service delivery. The minimum necessary information does not need to be validated, audited or highly specific.

In practice, facts relating to SEJs can unfold over time. If you are unsure whether the available facts are sufficient to conclude that a significant adverse effect has occurred, it is good practice to inform us by email with the facts known at that stage, whilst you continue to investigate the event. Early engagement of this kind can help persons with a duty to report to meet the one day reporting obligation. If your subsequent investigation confirms that the event was an SEJ, we may treat the initial email as discharging your notification obligation. In most cases, providing such an initial email will simply be responded to with an acknowledgement and a request to be kept updated. We do not expect you to provide the formal notification form or provide the monthly update forms until you have determined whether a significant adverse effect has occurred.

Where an event occurs and it is not immediately apparent whether that event has affected your scheme, you are required to notify us as soon as you become aware your scheme has been affected and there has been a significant adverse effect on the quality or security of data or service delivery. In this event, we expect schemes to take prompt action to determine whether there has been a significant adverse effect involving their scheme and it would be good practice to notify us of the investigation by email.

Who must notify us

Read our guide setting out the full list of people with a reporting obligation.

In practice, the first people with a reporting obligation to become aware of an SEJ are often:

a person who manages the scheme administration services
a person who provides legal, financial or actuarial advice to the scheme; or
a scheme strategist

These people may become aware of an event before the trustee. When this occurs, those persons have an obligation to notify us within one working day from when they become aware an SEJ has occurred.

If a person with a duty to notify is aware of the event and has the necessary facts to determine that the event is an SEJ, notification should not be delayed because the trustee or other relevant body eg a subcommittee is unaware or it has not decided its view on the status of the event. If you wish the Trustee or other relevant body to determine whether an event is an SEJ, your escalation processes and lines of communication should be structured to meet the one-day notification expectation under the code.

Trustees should engage with their service providers about how relevant persons are trained about the significant event regime, how this aligns with breach of law reporting and requirements to report events to other regulators. Trustees should engage with their service providers to ensure that any decision making by service providers, including relevant escalation, is aligned with our guidance. This should include ensuring appropriate oversight and monitoring of events which were not deemed reportable. Relevant people with notification duties should receive regular training on how to discharge their reporting duties.

Dual regulation

We are aware that some SEJs may also trigger reporting requirements to bodies other than TPR. You should also ensure that all relevant persons understand that an event may need to be reported as an SE J in addition to any other reporting requirements to other regulators or agencies such as HMRC.

Where the provision of follow up information to TPR and another regulator or other body creates duplication of work or inefficiencies in your regulatory relationship management, please engage with your supervisor following your initial notification to agree when and how you will provide updates. Note this does not impact the timing of the initial notification which should be made as soon as reasonably practicable.

How to notify us

Notify us using our notification form.

Master trust significant event J: notification form PDF 318KB, 12 page(s): Published : October 2026

If there is more than one significant event and they are related, you should use one form to notify us. If the events are not related, you should use separate forms. Check what other significant events to notify us about.

If at the time of notification, you do not have the answers to some of the questions, please state ‘unknown at present – anticipate confirming by [estimated timescale]’.

Likewise, if a question is not applicable, please state ‘Not applicable – no further information to be supplied’.

After the initial notification, please continue providing monthly updates in the update form until all sections have been completed, rectification is complete, and any steps taken to prevent reoccurrence have been fully implemented, unless otherwise informed by your supervisor.

Master trust significant event J: update form PDF 319KB, 12 page(s): Published : October 2026

Breaches of law

Some events may constitute a breach of law and an SEJ. In such cases you are welcome to notify us using only one form and we encourage schemes to use the SEJ form to fulfil both notification requirements. Where relevant, please state within the form that the event also constitutes a breach of law and outline the breach of the relevant legislation.