Good Practice Guide Reporting Security Incident
Good Practice Guide - Reporting Security Incident
50
In schemes with a large number of reports or with (partially) automated data processing it is
recommended to assign to each incident a unique ID number for the purposes of tracking concrete
cases and updating their status. It should be also said that not all schemes are using formal update
reports; some prefer ad hoc updates with the reporting parties. More on the functions of updates in
follow-up procedures will be said in section 5.3.1.
Concluding report. Most schemes run by bodies with a regulatory function do require an ex-post
report as the service provider's statement on the incident. Some rectification-focused schemes may be
limited to concluding reports only, but mostly the report will follow up on initial and/or update
reports. The concluding report should contain full information in all reporting files, including analysis
of the causes, and a summary of measures taken to remove the problem and prevent its re-occurrence
in the future. Some of this information may only be available ex post, and also the reporting parties
are more likely to assign human resources to detailed reporting after an incident has been solved than
during the incident response itself. Concluding report is usually requested within days to weeks from
the incident; sometimes the service providers are obliged to submit a draft within several days and the
final version later on. The concluding report may serve as a basis of ex-post analysis of individual
incidents, as described in section 6.1 below.
NORS
USA
expects first notification within 120 minutes from the incident, an Initial Report
draft concluding report
within 72 hours, and Final Communications Outage Report within 30
days from the incident.11
NPT [Norway] works with a threefold structure comprising the first report, optional updates,
and an optional post incident report. The first report is more of a headline-level notice to the
regulator, containing basic characteristics of the incident and estimation of consequences
based on the information available immediately after the event. The regulator may request
more information especially on sensitive incidents, or the operators may send updates
spontaneously. The regulator may request a post-incident report containing detailed
information; such reports are submitted after the incident has been solved.
FICORA
Finland
: The planned regulation requests first draft report within 1 hour from an
incident, followed by regular updates (including special statement on reason why the outage
hasn't been removed yet if the outage lasts longer than 3 hours), and a final detailed report
within one week. "The first draft reports contain mainly information on the impact to the
different telecom services (how many users are affected, what is the geographical area in
question) and expected time when the disruption is over. The detailed reports include
additional information,
...
e.g. the original reasons behind the incident (e.g. stormy weather),
the failed component in the network (e.g. DSLAM), description of how the incident was
recognized (e.g. through network management system), description
of
what steps were taken
to fix the problem, what was the time period of the service break, what kind of measures will
the telecom operator take to prevent the incident from happening again."
Periodical summary report. Finally for statistical purposes, information can be submitted in regular
intervals e.g., daily, weekly, monthly, quarterly or annually. Obviously, periodical reports can stand
separately from real-time reporting: they would arrive regularly irrespective of the priority or volume
11
Code of Federal Regulations, Title 47, Volume 1, Part 4, Sec. 4.5-4.9.