Incident Closure

cause(s) identified

A container holding one or more cause entries. Each entry describes one identified root cause using fields 77–81. Multiple causes may be recorded — complex incidents often have more than one contributing root cause.

Even where a single cause is identified at Final, use the container structure. If no cause has been definitively identified by Final, provide the best assessment with a causal strength of "Possible" or "Suspected" (field 78) and explain in cause notes (field 81).

cause type

The root cause type using the FIRE two-tier Annex N taxonomy. Select the most specific Level 2 category that applies — for example, "Ransomware" rather than just "Malicious Acts", or "Software Failure" rather than just "Information System Failures".

If the cause spans more than one category, create separate cause container entries for each distinct cause. See Cause Types (Annex N) for the full taxonomy with descriptions.

causal strength

The entity's confidence level in the identified root cause. This acknowledges that in complex incidents, the root cause may not be established with certainty even at the time of the Final report.

Typical accepted values:

• Confirmed — the root cause has been verified through forensic investigation or other definitive means
• Probable — the root cause is the most likely explanation based on available evidence but has not been fully confirmed
• Suspected — the root cause is a plausible hypothesis, but significant uncertainty remains
• Possible — the root cause is one of several possible explanations under consideration

Do not omit this field simply because the cause is uncertain — an honest confidence assessment is more useful to supervisors than leaving it blank.

origin

Whether the root cause originated within the entity itself, at a direct outsourcing provider, or further up the supply chain. This dimension helps supervisors identify systemic vulnerabilities in third-party relationships and supply chains across the financial sector.

Accepted values:

• Internal — the cause originated within the entity's own organisation and systems
• Direct outsourcer — the cause originated at a provider directly contracted by the entity
• Supply chain — the cause originated at a provider further up the supply chain (a subcontractor or sub-outsourcer)

origin identity

If the origin (field 79) is a direct outsourcer or supply chain entity, identifies that entity using one or more key-value pairs (e.g., LEI, name, or other identifier). This allows supervisors to track which third parties are appearing as causal origins across multiple institution reports — an important tool for identifying systemic third-party risk.

Leave blank if the origin is Internal, or if the external entity's identity has not yet been confirmed.

cause notes

Free-text narrative on the root cause analysis — the "story" behind how and why the incident happened. Use this to explain the causal chain, provide technical detail that the structured cause type cannot capture, or describe the entity's root cause investigation methodology.

A good cause notes entry explains not just what the cause was but why it occurred — the underlying conditions (process gaps, misconfigurations, unpatched vulnerabilities, etc.) that allowed the root cause to have the impact it did. This is among the most valuable content for supervisors assessing systemic vulnerability patterns.

lesson(s) identified

A container holding one or more lesson entries. Each lesson uses fields 83–84. Lessons identified are essential at the Final phase — they demonstrate that the entity has reflected on the incident and identified actionable improvements.

At minimum, provide one lesson per significant root cause identified. Multiple lesson entries may be used if the incident revealed several distinct areas for improvement. Superficial or generic lessons (e.g., "train staff better") are less useful than specific, actionable findings tied to the specific failure modes identified.

lesson description

A description of the specific lesson identified from this incident. Effective lessons are:

• Specific — tied to a concrete failure or gap identified in this incident
• Actionable — pointing to a change that can actually be made
• Forward-looking — focused on preventing recurrence, not assigning blame

Examples: "Detection of lateral movement was delayed because EDR coverage did not extend to OT systems", "The change approval process did not require a security review for patches categorised as low-criticality".

remedial action(s)

The actions taken or formally committed to in order to address the vulnerabilities or gaps identified by the lessons. Each entry is a key-value pair, typically with the action description as the value and a status or owner as the key.

These are longer-term remediation actions — the short-term containment actions taken during the incident are captured in field 36 (actions taken). Remedial actions here should directly address the root cause and the lessons identified, with enough detail for the receiving authority to assess their adequacy and track their completion over time.

Where actions are not yet complete at the time of the Final report, note their planned completion date.

attachment method

Specifies how supplemental documentation supporting the report is being provided. Accepted values reflect the two available methods:

• Embedded — the file is included directly within the FIRE report package (field 87)
• By reference — the file is held separately and access instructions are provided in field 86

Supplemental documentation might include forensic investigation reports, timeline diagrams, root cause analysis presentations, or regulatory correspondence. Only include materials that genuinely add context beyond what the structured fields already capture.

attachment instructions

If the attachment method (field 85) is "by reference", provide the instructions or information needed for the receiving authority to access the supplemental documentation. This might include a secure file share URL, a reference to a regulatory portal, a contact for obtaining the materials, or an expected delivery method.

Ensure that the access method is appropriate for the sensitivity of the documentation and accessible to the receiving authority within the expected timeframe.

attachment embedded

One or more files embedded directly within the FIRE report, encoded for transmission. Used when field 85 (attachment method) is set to "Embedded".

The FIRE schema specifies the encoding format and file size limits for embedded attachments. For large files, the "by reference" method (field 85 + field 86) is generally preferable to avoid size constraints and to allow documents to be updated after the report is submitted.