This database is the IAEA’s information system on incidents of illicit trafficking and other unauthorized activities and events involving nuclear and other radioactive material outside of regulatory control.

The ITDB was established in 1995 to help participating States and selected international organizations to combat illicit nuclear trafficking and strengthen nuclear security. It facilitates information exchange and provides material that can be used to analyze patterns and trends, thereby helping identify potential security threats and vulnerabilities. The ITDB is also an essential component of the information platform supporting the IAEA’s Nuclear Security Plan 2022-2025.

The scope of the information provided through the database is broad. States are encouraged to report a variety of incidents, including those – whether successful, unsuccessful or thwarted – involving the illegal trade and movement of nuclear or other radioactive material across national borders.

The ITDB information also covers incidents involving the unauthorized acquisition – for instance through theft, supply, possession, use, transfer or disposal (intentional or unintentional) of nuclear and other radioactive material, with or without crossing international borders. Additionally, the ITDB includes information on the loss of material and the discovery of uncontrolled material, as well as incidents involving the intentional offering for sale of benign material that is purported to be nuclear or otherwise radioactive (in other words, scams).

Groupings of Incident Types

The ITDB’s Terms of Reference (ToR) require the ITDB to be an authoritative source of information for States and, when appropriate, the media. For this purpose, three groups (Groups I, II and III) are used in order to facilitate the analysis of incidents. Each group is related to Trafficking and Malicious Use.

• GROUP I - Confirmed or likely act of Trafficking/Malicious Use or Scam/Fraud (including attempts thereof). Incidents included are those for which sufficient information is provided in the reporting State’s Incident Notification Form (INF) to determine that the incident is, or is likely to be, connected, with Trafficking or Malicious Use.

• GROUP II - Undetermined act of Trafficking/Malicious Use (including attempts thereof). Incidents included are those for which there is insufficient information provided in the reporting State’s INF to determine that the incident is, or is likely to be, either connected or unconnected with Trafficking or Malicious Use.

• GROUP III - Confirmed or likely absence of an act of Trafficking/Malicious Use (including attempts thereof). Incidents included are those for which sufficient information is provided in the reporting States’ INF, to determine that the incident is not, or is unlikely to be, connected, with Trafficking or Malicious Use.

The State of Iowa requires any person manufacturing, storing, handling, transporting, or disposing of a hazardous substance to notify the Department of Natural Resources and local law enforcement of the occurrence of a hazardous condition.

Additionally, the State of Iowa requires a person storing, handling, transporting, or land-applying manure from a confinement feeding operation or storing, handling, transporting, or land-applying manure, process wastewater, open feedlot effluent, settled open feedlot effluent or settleable solids from an open feedlot operation who becomes aware of a release to notify the Department of Natural Resources.

This online database allows the public to view reported spill data in their communities.

Information Management and Security Incident Logs (does not contain Cyber Incidents).

This web map contains information about the locations of NOAA's National Ocean Service facilities across the country. In particular it depicts the locations of ONMS facilities and visitor centers. ONMS is keenly aware of the value of these facilities and is charged with their maintenance and safety. These facilities can be affected adversely by natural hazard and emergency incident events, so it is important for incident managers to understand where they are in relationship to the emergency events that are occurring.

ICS-209-PLUS is a new dataset mined from the public archive (1999–2014) of the U.S. National Incident Management System/Incident Command System Incident Status Summary Form (a total of 124,411 reports for 25,083 incidents, including 24,608 wildfires). This system captures detailed information on incident management costs, personnel, hazard characteristics, values at risk, fatalities, and structural damage. Most (98.5%) of the reports are fire-related, followed in decreasing order by other, hurricane, hazardous materials, flood, tornado, search and rescue, civil unrest, and winter storms. The archive, although publicly available, has been difficult to use due to multiple record formats, inconsistent free-form fields, and no bridge between individual reports and high-level incident analysis. This improved dataset and the open, reproducible methods used are described, including merging records across three versions of the system, cleaning and aligning with the current system, smoothing values across reports, and supporting incident-level analysis. This integrated record offers the opportunity to explore the daily progression of the most costly, damaging, and deadly events in the U.S., particularly for wildfires. Key metadata about the data are provided in JSON and CSV format. Resources in this dataset:Resource Title: All-hazards dataset mined from the US National Incident Management System 1999-2014 - data availability. File Name: Web Page, url: https://doi.org/10.1038/s41597-020-0403-0 Data files can be found linked in the "Data Records" section of the article.

Fire incidents, to be shared with state and federal governments for reporting. Supports resource allocation.

The National Incident-Based Reporting System (NIBRS) is a part of the Uniform Crime Reporting Program (UCR), administered by the Federal Bureau of Investigation (FBI). In the late 1970s, the law enforcement community called for a thorough evaluative study of the UCR with the objective of recommending an expanded and enhanced UCR program to meet law enforcement needs into the 21st century. The FBI fully concurred with the need for an updated program to meet contemporary needs and provided its support, formulating a comprehensive redesign effort. Following a multiyear study, a "Blueprint for the Future of the Uniform Crime Reporting Program" was developed. Using the "Blueprint," and in consultation with local and state law enforcement executives, the FBI formulated new guidelines for the Uniform Crime Reports. The National Incident-Based Reporting System (NIBRS) was implemented to meet these guidelines. NIBRS data are archived at ICPSR as 13 separate data files per year, which may be merged by using linkage variables. The data focus on a variety of aspects of a crime incident. Part 4, Administrative Segment, offers data on the incident, itself (date and time). Each crime incident is delineated by one administrative segment record. Also provided are Part 5, Offense Segment (offense type, location, weapon use, and bias motivation), Part 6, Property Segment (type of property loss, property description, property value, drug type and quantity), Part 7, Victim Segment (age, sex, race, ethnicity, and injuries), Part 8, Offender Segment (age, sex, and race), and Part 9, Arrestee Segment (arrest date, age, sex, race, and weapon use). The Batch Header Segment (Parts 1-3) separates and identifies individual police agencies by Originating Agency Identifier (ORI). Batch Header information, which is contained on three records for each ORI, includes agency name, geographic location, and population of the area. Part 10, Group B Arrest Report Segment, includes arrestee data for Group B crimes. Window Segments files (Parts 11-13) pertain to incidents for which the complete Group A Incident Report was not submitted to the FBI. In general, a Window Segment record will be generated if the incident occurred prior to January 1 of the previous year or if the incident occurred prior to when the agency started NIBRS reporting. As with the UCR, participation in NIBRS is voluntary on the part of law enforcement agencies. The data are not a representative sample of crime in the United States.

The Privacy Incident Management Software market is experiencing robust growth, projected to reach $2056 million by 2026, fueled by a Compound Annual Growth Rate (CAGR) of 6.4%. This expansion is driven by increasing data breaches, stringent data privacy regulations like GDPR and CCPA, and the growing awareness of the financial and reputational risks associated with data compromises. Businesses across all sectors are actively seeking solutions to streamline their incident response processes, manage legal obligations, and minimize the impact of privacy violations. The market is characterized by a diverse range of vendors, from established players like IBM and Microsoft to specialized providers such as OneTrust and RadarFirst. This competitive landscape fosters innovation and drives the development of more sophisticated and user-friendly software solutions. The increasing adoption of cloud-based solutions and the integration of AI and machine learning capabilities further contribute to market growth, offering better automation, faster incident detection, and more efficient remediation. The market's segmentation likely includes solutions based on deployment (cloud, on-premise), organization size (small, medium, large enterprises), and industry vertical (healthcare, finance, retail, etc.). While specific regional data is unavailable, North America and Europe are expected to dominate the market initially, given their advanced regulatory frameworks and high adoption of technology. However, Asia-Pacific and other regions are predicted to witness significant growth over the forecast period (2025-2033) due to increasing digitalization and stricter data privacy laws in these regions. The primary restraints to market growth might include high initial investment costs for software implementation and the need for specialized expertise in handling data breaches and incident management. Nevertheless, the overall market outlook remains positive, with continuous expansion expected throughout the forecast period.

The National Fire Incident Reporting System (NFIRS) is a reporting standard that fire departments use to uniformly report on the full range of their activities from fire to emergency medical services (EMS) to equipment involved in the response.

The Automated Safety Incident Surveillance and Tracking System (ASISTS) is a repository of Veterans Health Administration (VHA) employee accident data. Many types of accidents are captured, but the primary focus of the ASISTS database is to track and to report on employee exposures to blood borne pathogens through needlesticks, sharps and body fluids. Accident data is captured locally at medical centers using the Veterans Health Information Systems and Technology Architecture (VistA) ASISTS package. Federal Employee Compensation claims are transmitted electronically in order to provide efficient and timely submission to the Department of Labor, Office of Workers' Compensation Programs; and to ensure that the Occupational Safety and Health Administration's (OSHA) Log of Work-Related Injuries and Illnesses is maintained. On a daily basis the Federal Employee Compensation claims are transmitted by Electronic Data Interchange extraction. A weekly download of the accident reports are sent to the national database using MailMan messages. On a monthly basis, extracts are sent to the ASISTS central repository located at the Austin Information Technology Center. The VHA Support Service Center (VSSC) provides multiple customized reports on the VSSC Web portal available on the VA Intranet. The primary users of ASISTS include OSHA, VA Headquarters, the VISN Directors, and occupational safety and health professionals located at each VA medical facility.

Hazmat Incident Report Search tool allows users to search for incidents involving hazardous material while in transportation and export the results to a text file for further analysis.

This data ceased updating with the transition to a new records management system on 11/14/2023. Access to the updated data set has been added as of April 11, 2025 here: https://data.wprdc.org/dataset/monthly-criminal-activity-dashboard.

The Police Blotter Archive contains crime incident data after it has been validated and processed to meet Uniform Crime Reporting (UCR) standards, published on a nightly basis. This data validation process creates a data publishing delay of approximately thirty days. Users who require the most recent incident data should use the 30 Day Police Blotter. The 30 Day Police Blotter dataset contains more recent data, but has not yet been run through quality control and standardization procedures by the Police Bureau. All data is reported at the block/intersection level, with the exception of sex crimes, which are reported at the police zone level.

This dataset only contains information reported by City of Pittsburgh Police, and does not contain incidents that solely involve other police departments operating within the city (campus police, Port Authority, etc.)

More documentation is available in our Crime Data Guide.

Version 5 release notes:Adds 2020 dataVersion 4 release notes:Fix bug where most years had arrestee and property were incorrectly window arrestee and window property segments.Changes R files from .rda to .rds.Version 3 release notes:Adds 2019 dataVersion 2 release notes:Changes release notes description, does not change data.These data are the FBI's National Incident-Based Reporting System (NIBRS) data for years 1991-2018. NIBRS data are incident-level data that have highly detailed information for each crime that is reported to the police agency. This data has 10 segments. Each segment has different data about the crime. AdministrativeBasic information about the crime incident - this is basically metadata about the other segments for this crime. This includes the date of the crime, the number of offense segments, the number of victim segments, the number of offender segments, the number of arrestee segments, if the crime was cleared exceptionally and (if it was) what date it was cleared. ArresteeArrestee-level information for those who are arrested. This includes demographics (age, sex, race, ethnicity), the date of the arrest (can be different than the date of the crime), what weapon (if any) was used, and the outcome of the case if the arrestee was a juvenile. Group B Arrest ReportsArrestee-level information for those who are arrested for Group B crimes. This includes the same variables as the arrestee segment. OffenderOffender-level information for each offender. Includes offender demographics (age, sex, race, ethnicity).OffenseDetailed information about each crime. Includes the weapon used (if any), the location of the crime, if the offender was intoxicated (including drugs and alcohol), and what their bias motivation (if any) was (if there is one, this would be considered a hate crime). PropertyInformation about property involved in the crime (i.e. drugs or stolen property). This includes the value of the property, what type of the property it was, when it was recovered. For drugs, this includes the drug and its quantity. VictimVictim-level information for each victim of a crime. Includes victim demographics (age, sex, race, ethnicity), injury, and relationship to the offender(s).Window ArresteeWindows segments have the same columns as their non-window counterparts and are incidents that occurred prior to the year of data or prior to when the agency started reporting to NIBRS.Window Exceptional ClearanceWindows segments have the same columns as their non-window counterparts and are incidents that occurred prior to the year of data or prior to when the agency started reporting to NIBRS.Window PropertyWindows segments have the same columns as their non-window counterparts and are incidents that occurred prior to the year of data or prior to when the agency started reporting to NIBRS.Due to the large file size, each year is its own file. All segment headers are available except for the batch headers. What I did here was read the data into R and save it as R and Stata files. No other changes to the data were made. The data was downloaded as NIBRS Master Files for each year from the FBI's Crime Data Explorer website - https://crime-data-explorer.fr.cloud.gov/downloads-and-docs.

Data Set Information:

This is an event log of an incident management process extracted from data gathered from the audit system of an instance of the ServiceNowTM platform used by an IT company. The event log is enriched with data loaded from a relational database underlying a corresponding process-aware information system. Information was anonymized for privacy.

Number of instances: 141,712 events (24,918 incidents) Number of attributes: 36 attributes (1 case identifier, 1 state identifier, 32 descriptive attributes, 2 dependent variables)

Attribute Information:

1. number: incident identifier (24,918 different values);
2. incident state: eight levels controlling the incident management process transitions from opening until closing the case;
3. active: boolean attribute that shows whether the record is active or closed/canceled;
4. reassignment_count: number of times the incident has the group or the support analysts changed;
5. reopen_count: number of times the incident resolution was rejected by the caller;
6. sys_mod_count: number of incident updates until that moment;
7. made_sla: boolean attribute that shows whether the incident exceeded the target SLA;
8. caller_id: identifier of the user affected;
9. opened_by: identifier of the user who reported the incident;
10. opened_at: incident user opening date and time;
11. sys_created_by: identifier of the user who registered the incident;
12. sys_created_at: incident system creation date and time;
13. sys_updated_by: identifier of the user who updated the incident and generated the current log record;
14. sys_updated_at: incident system update date and time;
15. contact_type: categorical attribute that shows by what means the incident was reported;
16. location: identifier of the location of the place affected;
17. category: first-level description of the affected service;
18. subcategory: second-level description of the affected service (related to the first level description, i.e., to category);
19. u_symptom: description of the user perception about service availability;
20. cmdb_ci: (confirmation item) identifier used to report the affected item (not mandatory);
21. impact: description of the impact caused by the incident (values: 1–High; 2–Medium; 3–Low);
22. urgency: description of the urgency informed by the user for the incident resolution (values: 1–High; 2–Medium; 3–Low);
23. priority: calculated by the system based on 'impact' and 'urgency';
24. assignment_group: identifier of the support group in charge of the incident;
25. assigned_to: identifier of the user in charge of the incident;
26. knowledge: boolean attribute that shows whether a knowledge base document was used to resolve the incident;
27. u_priority_confirmation: boolean attribute that shows whether the priority field has been double-checked;
28. notify: categorical attribute that shows whether notifications were generated for the incident;
29. problem_id: identifier of the problem associated with the incident;
30. rfc: (request for change) identifier of the change request associated with the incident;
31. vendor: identifier of the vendor in charge of the incident;
32. caused_by: identifier of the RFC responsible by the incident;
33. close_code: identifier of the resolution of the incident;
34. resolved_by: identifier of the user who resolved the incident;
35. resolved_at: incident user resolution date and time (dependent variable);
36. closed_at: incident user close date and time (dependent variable).

Relevant Papers:

Amaral, C. A. L., Fantinato, M., Reijers, H. A., Peres, S. M., Enhancing Completion Time Prediction Through Attribute Selection. Proceedings of the 15th International Conference on Advanced Information Technologies for Management (AITM 2018) and 13th International Conference on Information Systems Management (ISM 2018), Revised Selected Papers – Lecture Notes in Business Information Processing, v. 346, pp. 3-23, 2019. [Web Link]

Amaral, C. A. L., Fantinato, M., Peres, S. M., Attribute Selection with Filter and Wrapper: An Application on Incident Management Process. Proceedings of the 14th Federated Conference on Computer Science and Information Systems (FedCSIS 2018), pp. 679-682, 2018. [Web Link]

Maita, A. R. C., Martins, L. C., Paz, C. R. L., Rafferty, L., Hung, P., Peres, S. M., Fantinato, M. A systematic mapping study of process mining. Enterprise Information Systems, v. 12, n. 5, pp. 505-549, 2018. [Web Link]

Citation Request:

Please cite this paper if you use this dataset: Amaral, C. A. L., Fantinato, M., Reijers, H. A., Peres, S. M., Enhancing Completion Time Prediction Through Attribute Selection. Proceedings of the 15th International Conference on Advanced Information Technologies for Management (AITM 2018) and 13th International Conference on Information Systems Management (ISM 2018), Revised Selected Papers – Lecture Notes in Business Information Processing, v. 346, pp. 3-23, 2019. [Web Link]

These data are part of NACJD's Fast Track Release and are distributed as they were received from the data depositor. The files have been zipped by NACJD for release, but not checked or processed except for the removal of direct identifiers. Users should refer to the accompanying readme file for a brief description of the files available with this collection and consult the investigator(s) if further information is needed. This research examined the reliability of the Federal Bureau of Investigation's National Incident-Based Reporting System (NIBRS) arrests data. Data on crime incidents, including data on whether an arrest was made or a summons issued, are collected from hundreds of law enforcement agencies (LEAs) across the country and then combined by the FBI into a national data set that is frequently used by researchers. This study compared arrest data in a sample of cases from NIBRS data files with arrest and summons data collected on the same cases directly from LEAs. The dataset consists of information collected from the Massachusetts NIBRS database combined with data from LEAs through a survey and includes data on arrests, summons, exceptional clearances, applicable statutes and offense names, arrest dates, and arrestees' sex, race, ethnicity and age for a sample of assault incidents between 2011 and 2013 from the NIBRS. The collection contains one SPSS data file (n=480; 32 variables). Qualitative data are not available as part of this collection.

Incident Reporting Log recording the near misses and incidents covering physical, personnel and information security occurrences.

The annual National Fire Incident Reporting System (NFIRS) Public Data Release files are provided by the U.S. Fire Administration’s (USFA) National Fire Data Center (NFDC). The NFIRS is a reporting standard that fire departments use to uniformly report on the full range of their activities, from fire to emergency medical services (EMS) to equipment involved in the response.NFIRS is the nation’s largest, national, annual database of fire incident information. NFIRS is a voluntary tool with two objectives: to help State and local governments develop fire reporting and analysis capability for their own use and to obtain data that can be used to more accurately assess and subsequently combat the fire problem at a national level.These datasets are for researchers and fire data analysts.Experience with fire data analysis and NFIRS data is recommended to properly use the NFIRS Public Data Release (PDR) datasets. Using raw NFIRS data as a count of fires and associated deaths, injuries and dollar loss is NOT a proper use of these datasets.FEMA's terms and conditions and citation requirements for datasets (API usage or file downloads) can be found on the OpenFEMA Terms and Conditions page: https://www.fema.gov/about/openfema/terms-conditions.For answers to Frequently Asked Questions (FAQs) about the OpenFEMA program, API, and publicly available datasets, please visit: https://www.fema.gov/about/openfema/faq.If you have media inquiries about this dataset, please email the FEMA Press Office at FEMA-Press-Office@fema.dhs.gov or call (202) 646-3272. For inquiries about FEMA's data and Open Government program, please email the OpenFEMA team at OpenFEMA@fema.dhs.gov.Please note that upon clicking any of the available downloadable NFIRS Public Data Release data sets hyperlinks, an automatic download of that year's data will commence. Download times will vary depending on the size of the file and your connection. Some of the compressed zip file sizes vary from 132 MB and can range up to 822MB. If you prefer to order the NFIRS public release data on CD or DVD, please visit the USFA’s Download fire data and data analysis tools web page. Below are the data years that are currently available:CD 1980-1998 - Fire Incidents (NFIRS version 4.1)CD 1999-2003 - All IncidentsCD 2004-2019 - Fire and Hazardous Materials IncidentsDVD 2014-2019 - All Incidents

This dataset comprises four text files (national_activity.csv, gacc_activity.csv, wildfire_activity.csv, resource_summary.csv) that represent four categories of wildfire information extracted from 3,124 Incident Management Situation Reports (IMSRs), spanning 15 years from 2007 to 2021. There is an Excel file (2007-2021-IMSR-1.06.xlsx) that contains corresponding information to the text files. The dataset was generated by IMSR-Tool version 1.06. Its source code is available at https://doi.org/10.5281/zenodo.8406263. You can download a user manual and a runnable version of this tool at https://github.com/thumit/IMSRtool/releases/tag/1.06. The dataset also includes an archive of 3,124 IMSR PDFs collected over the same 15-year period, which can be used as inputs for the tool. Additionally, two Excel files are provided (Technical-Validation-IMSR-1.05.xlsx and Technical-Validation-IMSR-1.06.xlsx), offering detailed information about the accuracy assessment for the two latest versions (1.05 and 1.06) of the IMSR data. The IMSR data version 1.05 can be found at https://doi.org/10.6084/m9.figshare.22773812.v1

Incident Reporting Software for Security Market Outlook

According to our latest research, the global incident reporting software for security market size reached USD 2.41 billion in 2024, exhibiting robust momentum driven by the growing demand for digital security solutions across various sectors. The market is projected to expand at a CAGR of 10.2% from 2025 to 2033, reaching an estimated USD 6.36 billion by 2033. This impressive growth is primarily attributed to the increasing complexity of security threats, the rising adoption of cloud-based solutions, and the need for real-time incident management and compliance across industries.

A significant growth factor for the incident reporting software for security market is the rapid evolution of security threats and the corresponding need for advanced, automated incident management systems. Organizations are facing increasingly sophisticated cyber and physical security challenges, necessitating a shift from traditional, manual reporting to digital platforms that enable real-time detection, response, and documentation. The proliferation of IoT devices and the expansion of digital infrastructures have further heightened the risk landscape, compelling enterprises to invest in comprehensive incident reporting software. These platforms not only streamline the process of capturing, tracking, and resolving security incidents but also enhance data accuracy and facilitate regulatory compliance, which is critical in highly regulated sectors such as finance, healthcare, and government.

Another crucial driver is the widespread adoption of cloud-based deployment models, which offer scalability, flexibility, and cost-efficiency. As organizations increasingly embrace remote work and distributed operations, cloud-based incident reporting software enables centralized management of security events across multiple locations. This capability is especially valuable for large enterprises with global footprints, as well as small and medium enterprises (SMEs) seeking affordable and easily deployable solutions. The integration of artificial intelligence (AI) and machine learning (ML) technologies into incident reporting systems is further propelling market growth by enabling predictive analytics, automated threat detection, and intelligent workflow automation. These advancements are transforming incident reporting from a reactive to a proactive function, allowing organizations to mitigate risks more effectively.

The regulatory landscape is also playing a pivotal role in shaping the incident reporting software for security market. Governments and industry bodies worldwide are imposing stringent data protection and security requirements, mandating timely and accurate reporting of security incidents. Compliance with regulations such as the General Data Protection Regulation (GDPR), Health Insurance Portability and Accountability Act (HIPAA), and various national cybersecurity laws is driving organizations to adopt specialized software solutions that ensure comprehensive documentation and audit trails. This trend is particularly pronounced in sectors such as healthcare, finance, and government, where failure to report incidents promptly can result in severe penalties and reputational damage. As a result, the demand for advanced incident reporting software is expected to remain strong across these verticals.

In the evolving landscape of incident reporting software, Responder Accountability Software is becoming increasingly important. This type of software ensures that all responders to an incident are accounted for and that their actions are documented in real-time. By integrating with existing incident management systems, Responder Accountability Software provides a comprehensive view of the incident response, allowing organizations to analyze the effectiveness of their response strategies and make data-driven improvements. This not only enhances the safety and security of the organization but also ensures compliance with industry regulations and standards. As organizations continue to face complex security challenges, the demand for such accountability solutions is expected to grow, offering a critical layer of transparency and oversight in incident management processes.

Regionally, North America continues to dominate the incident reporting software for security market, accounting for the largest share in 2024. This leadership position i

For up to date data starting in 2018, please go to the new dataset at: https://data.sfgov.org/d/wg3w-h783

As of May 2018, the feed from the legacy mainframe CABLE was discontinued. It was extremely prone to issues and caused many delays in data accessibility. The new dataset linked above comes from the Crime Data Warehouse, a more reliable data system maintained by the Police Department.

This data will undergo a minor update to conform more closely to the schema of the new dataset. We will post a change notice when that work is planned. This change will not include adding new fields or backfilling data. It is provided as is. We are keeping data from the two systems separate to make it transparent to data users that there were fundamental changes.