Group 3 · fields 47–75
Captures the severity and scope of the incident's effects — on services, end users, transactions, resources, finances, and reputation. These fields allow supervisors to assess and compare incident impacts across institutions and borders.
3.1 Severity Rating
The entity's own internal severity rating for this incident, using whatever severity framework the entity has in place. This is a free-text field to accommodate the wide variety of internal rating schemes used across different institutions.
Providing this alongside the standardised severity (field 48) gives the receiving authority context for how the entity itself assessed the incident relative to its own risk appetite and internal thresholds. It also helps supervisors calibrate the FIRE standardised scale against industry practice over time.
The overall severity of the incident assessed using the FIRE six-level standardised scale. This is the primary cross-institution severity comparator and is essential at every phase.
Accepted values: Nil, Negligible, Low, Medium, High, Extreme. See Severity Scale (Annex E) for descriptors and step-change transition criteria.
The standardised severity reflects an overall holistic assessment — it should be informed by the four dimensional impact scales (fields 69–72) but is not a mechanical average of them. Use your judgement, guided by the Annex E descriptors, to select the level that best represents the overall impact.
Update the severity rating at each phase as the situation develops and more information becomes available.
3.2 Affected Parties
Classification of the types of parties that were affected by the incident. An array allowing multiple types to be reported simultaneously. The accepted values are defined by the implementing authority and typically include categories such as retail customers, corporate clients, counterparties, third-party service providers, and financial market infrastructure.
Other legal entities — subsidiaries, affiliates, branches, counterparties, or third-party providers — that were materially affected by the incident. Each entry is a key-value pair identifying the entity (e.g., by name and LEI).
This field is critical for understanding the systemic reach of an incident beyond the reporting entity. Supervisors use it to coordinate with other authorities that may have regulatory responsibility for the affected entities.
Free-text narrative providing additional context on affected parties that is not captured by the structured fields above — for example, explaining why certain parties were affected, the nature of their involvement, or describing specific client or counterparty impacts in more detail.
3.3 Services and Resources
A container holding one or more service entries. Each service entry uses fields 53–67. Multiple services may be listed if the incident affected more than one distinct service or business function.
At least one service entry is expected from the Intermediate phase. If multiple services were affected, provide a separate entry for each significant service rather than combining them into one.
The name of the affected service — as the entity refers to it internally, or as it is known to customers. Examples: "Online Banking", "Payment Processing", "FX Trading Platform", "Card Services", "Core Banking System".
Be specific enough that the receiving authority can understand what capability was disrupted. Avoid generic terms like "IT systems" — name the actual service or application.
Classification of the service using ISO 20022 business area codes. This provides a standardised, machine-readable description of the type of financial service affected, enabling cross-institution analysis of which service categories are most frequently impacted.
Each entry is a key-value pair where the key identifies the classification scheme and the value is the specific code. Multiple entries may be needed if the service spans multiple ISO 20022 business areas.
An indication of whether the affected service has been designated as critical — for example, as a critical economic function, critical service under the entity's operational resilience framework, or critical financial market infrastructure. The specific designation framework is defined by the implementing authority.
This field helps supervisors rapidly identify whether an incident has affected services of heightened systemic importance.
The type of service disruption using the Annex F classification. Multiple types may apply — for example, a ransomware attack may involve both Availability Loss (Total) and Confidentiality Loss (Unauthorised Acquisition).
See Service Disruption Types (Annex F) for the full list. Select all applicable types for each service entry.
The total duration for which the service was unavailable or significantly degraded. For intermittent disruptions, this should be the cumulative total of downtime periods, not the elapsed time from first disruption to full restoration.
Express as an ISO 8601 duration (e.g., PT4H30M for 4 hours 30 minutes, P2DT6H for 2 days and 6 hours). At the Final phase this should be a confirmed figure; at Intermediate it may still be an estimate if the service is not yet fully restored.
The estimated number of end users (retail customers, corporate clients, etc.) who were affected by the disruption to this service. Use the best available estimate at the time of reporting — this can be refined in later reports.
Count unique users, not interactions or transactions. If some users were only partially affected (e.g., experienced degraded service rather than total loss), include them if the impact was material from the user's perspective.
The percentage of the entity's total end user base for this service that was affected. Expressed as a decimal percentage (e.g., 0.35 for 35%). Complements field 58 by providing a relative measure that is comparable across entities of different sizes.
The types of financial transactions that were affected — for example, payments, settlements, securities trades, foreign exchange transactions, or cash withdrawals. The accepted values are defined by the implementing authority.
The number of transactions affected by the incident. Count all transactions that failed, were delayed, or were otherwise materially disrupted during the incident window. Where exact counts are not immediately available, provide the best available estimate.
The affected transactions expressed as a percentage of the total number of transactions processed by the entity in the same period. Provides context for the scale of the disruption relative to normal activity.
The total monetary value of affected transactions, expressed in the report currency specified in field 6. This quantifies the economic throughput disrupted by the incident and is one of the key metrics for assessing financial impact severity.
A container holding one or more resource entries. Each resource entry uses fields 65–66. Multiple resources may be listed if the incident affected more than one distinct resource. The container is essential at Final — by this stage the entity should have identified the affected resources through its investigation.
The type of resource affected, using the Annex H classification. Select the most specific applicable type — for example, "Software" rather than just "Technology", or "Datastore" rather than just "Information".
See Resource Types (Annex H) for the full two-tier taxonomy with descriptions.
The security properties of the resource that were compromised, using the Annex I list. Multiple properties may apply — for example, an attack that encrypted data and prevented access would affect both Availability and Integrity.
Accepted values: Availability, Integrity, Confidentiality, Authenticity, Accountability, Non-repudiation, Reliability. See Resource Properties (Annex I) for definitions.
Free-text narrative providing additional context on affected services or resources not captured by the structured fields above. Use this to explain complex relationships between affected systems, describe cascading failures, or provide detail on specific resources that the structured fields cannot fully represent.
3.4 Impact
The actual, confirmed financial loss incurred by the entity as a direct result of the incident, expressed in the report currency (field 6). This is distinct from the financial impact scale (field 69) — this field captures a specific monetary amount, while field 69 captures a standardised ordinal rating.
Include direct costs (fraud losses, theft, write-offs) but not indirect costs such as incident response costs or reputational losses. Provide an estimate at Initial if an exact figure is not yet known — note in the description that it is an estimate and refine in subsequent reports.
The financial impact of the incident assessed on the FIRE six-level scale. See Financial Impact (Annex J) for level descriptions.
Accepted values: None, Insignificant, Minor, Moderate, Substantial, Severe. This is one of four impact dimensions that inform the overall standardised severity (field 48).
The operational impact of the incident assessed on the FIRE six-level scale. See Operational Impact (Annex K) for level descriptions.
Accepted values: None, Insignificant, Minor, Moderate, Substantial, Severe. Reflects the degree of disruption to the entity's ability to carry out its critical functions and services.
The reputational impact of the incident assessed on the FIRE six-level scale. See Reputational Impact (Annex L) for level descriptions.
Accepted values: None, Insignificant, Minor, Moderate, Substantial, Severe. This should reflect the actual or expected effect on the entity's public standing and client and counterparty relationships.
The external impact — on parties beyond the reporting entity — assessed on the FIRE six-level scale. See External Impact (Annex M) for level descriptions.
Accepted values: None, Insignificant, Minor, Moderate, Substantial, Severe. This dimension captures spillover effects on clients, counterparties, market participants, and the broader financial system — the key systemic risk indicator in the impact framework.
The geographic reach of the incident's impact. Accepted values are defined by the implementing authority but typically include: local (confined to a single site or city), national (affecting the entity's domestic operations broadly), and international (affecting operations or parties in more than one country).
Essential from Intermediate — by this stage the geographic reach should be understood even if it is still evolving. If the scope widened between reports, note this in the description.
If the geographic spread (field 73) is international, list the specific countries affected using ISO 3166-1 alpha-2 country codes. Include any country in which the entity's operations, clients, or counterparties were materially affected.
Free-text narrative on the overall impact of the incident — context that is not captured by the structured impact fields. Use this to explain why a particular impact rating was selected, to describe evolving impact estimates, or to note any unusual aspects of the impact profile that would help supervisors interpret the structured data.