National Wildfire Coordinating Group

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. Sharing through the official incident FireNet Team is also a common practice. Follow the guidance of the incident SITL for posting products.

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

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.
GIS Workflow, explained below

Figure 1. GISS Workflow Diagram: Back Up and Sharing
(click image to open larger)


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. These data are usually obtained from the local agency and are returned to the agency at the end of the incident.  Adhere to agency requests pertaining to these data 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 to ensure that they are not shared or archived. A ‘restricted’ folder is provided at the root of the GeoOps Folder Structure for storing sensitive data.

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: