C5.4 Common incident schema

FSB FIRE [27]

The fourth component requires that the organization keep one structured incident record, compatible with the supervisory exchange format, so that the loss base, the cyber log and the third-party incident register are views of a single object rather than three objects with three vocabularies. The format is the common incident reporting exchange finalized in 2025 [27], with its four sections following the life of an incident, who is reporting, what happened, how bad it was and how it was closed, and its three phases, initial, intermediate and final, which let a report go out before the facts are complete and be corrected afterward with the reporter's confidence attached.

The component reconciles three incident processes that in most organizations have grown up separately: the operational-risk loss capture, the security incident response and the vendor-management escalation. Each has its own form, its own severity scale and its own idea of when an incident is closed. A single record with a published taxonomy and validation rules ends the translation among them, and the framework's two additions from the quality tradition, the barrier that failed and the recurrence status, sit as extensions that leave the base record valid. Chapter 13 made the general case for formats; here the practical effect is that a payment failure caused by a supplier's software defect produces one record that the operations team, the security team and the third-party team all read.