Back Up and Sharing

Data sharing ensures all individuals involved with an incident have the information needed to do their jobs and that team transitions are effective and efficient. Data is backed up to ensure the work of the GISS is not excessively impacted by computer failures or data corruption and to preserve the incident record.

As of 2019, posting incident data to the NIFC FTP is no longer required or necessary, and in 2021 the NIFC FTP site may no longer be available. Guidance and details will be forthcoming on a new location for incident data sharing; more than likely a FireNet solution will be the preferred option.

The National Incident Feature Service (NIFS) now serves as the official source for all incident data and should be updated daily. The NIFS is backed up and archived to EGP servers every few minutes.

Map Products should still be posted to the data sharing location identified after the NIFC FTP site is no longer available.

With the increase in the virtual incident response environment for those in the GISS role, the use of FireNet OneDrive has become an option for intra-incident data sharing.

GISS Workflow Diagram:  Back Up and Sharing

Click image to open larger in a new window

GIS Workflow, explained below

Back Up and Sharing – Repeat as Necessary

  1. Post digital map products to the NIFC FTP site nightly. Use QR codes  if desired.
  2. Back Up Incident Directory Structure.

Data Sharing Guidelines

“Data sharing” refers to the process of distributing data to other interested and authorized parties or agencies during an incident.

By the end of each operational period, at a minimum, the three primary Event Data Layers (Point, Line, and Polygon) should be updated in the National Event Feature Service.

Data are occasionally shared directly with other authorized users. The GISS should consult the Situation Unit Leader (SITL) with any question about whether a request for data should be fulfilled.

Any incoming team will need a copy of the incident data and working files. Often this data sharing is accomplished by copying the incident’s GIS subdirectory to an external hard drive, which the incoming team will keep. Good communication is needed between the outgoing GISS and the incoming and/or host agency GIS to ensure complete and useful incident data transfer.

Sensitive Data

Sensitive data include but are not limited to cultural and archeological resources, and/or sensitive, threatened, and endangered species and/or data subject to the Privacy Act (containing personally identifiable information). These data are usually obtained from the local agency and are returned to the agency at the end of the incident. Certain agencies may be more restrictive with sensitive data and even place extreme restrictions on their use. Adhere to agency requests while on the incident. A procedural document for the incident may be created in cooperation with the local unit and SITL to ensure the proper handling of sensitive data. Remove sensitive data from hardware that leaves the incident. The GISS should check with the SITL about how to label sensitive data on incident map products; maps containing these data are for incident operational purposes only and must not be shared or posted to public-facing FTP sites or websites. Do not collect or label sensitive data on web maps, in AGOL, or mobile devices unless there is a way to password protect this information. Sensitive data are not retained with the incident archive. Sensitive data should be flagged in some manner, to ensure that they are not shared or archived, or they should be kept in a specific folder, such as \base_data\SENSITIVE. Some data (e.g., IR data) may be considered sensitive or “For Official Use Only” on incidents where homes and structures are threatened. It is imperative the GISS communicate with the SITL and/or the Planning Section Chief and Incident Commander to ensure that only approved information is posted.


Print This Page


Page Last Modified / Reviewed: