ATF Mass Notification_PWS v04302026.pdf

Department of Justice (DOJ) Bureau of Alcohol, Tobacco, Firearms and Explosives (ATF)

Field Operations (FO) Special Operations Division (SOD)

Performance Work Statement (PWS)

ATF Mass Notification System

April 30, 2026

Mass Notification System

1. Background:

2. Organization:

ATF is a law enforcement organization. ATF’s unique responsibilities involve reducing violent crime, collecting revenue, and protecting the public. ATF enforces Federal laws and regulations relating to alcohol, tobacco, firearms, explosives, and arson by working directly and in cooperation with other government agencies to:

a) Suppress and prevent crime and violence through enforcement, regulation and community outreach;

b) Ensure fair and proper revenue collection;

c) Provide fair and effective industry regulation;

d) Support and assist Federal, State, Local and international law enforcement;

e) Provide innovative training programs in support of criminal and regulatory enforcement functions;

f) Help reduce the criminal use of firearms;

g) Provide for public safety by reducing the criminal misuse of explosives, combating arson, and remove safety hazards caused by improper and unsafe storage of explosive materials.

Within the broad mission and jurisdiction of ATF, three specific programs within the organization have a need to provide urgent and focused emergency and routine notifications. The are:

• Office of Field Operations, Special Operations Division, Emergency Support Section

• Office of Professional Responsibility and Security Operations, Security and

Emergency Programs Division, Emergency Management Branch

• Office of Intelligence Operations, Criminal Intelligence Division, Joint Support

Operations Center

The program offices have joined to specify and procure a new emergency notification system to replace the existing system which will be in an “end of life” condition and not supported after December 31, 2025. ATF desires to have the new system on-line by May 1, 2025. The current system is hosted internally by ATF inside the DOJ/ATF firewall and has been in use since 2005.

3. Objective/Purpose:

This procurement is for a replacement of an existing requirement for a FedRAMP Moderate software-as-a-service (SaaS) cloud operated mass notification system to be used by ATF to conduct law enforcement, regulatory and emergency management activities of ATF and the Department of Justice. This system must allow authorized personnel to send text, email and voice messages virtually instantaneously consistent with the public safety purpose of the notification which may include messages with life-safety implications where reliability is critical. These messages will be sent to Federal personnel employed by ATF, our interagency law enforcement partners as well as notifications to Federal Firearms Licensees (public). The system must be capable of sending push notifications without prior registration of the contacts receiving the messages.

This is conceived to be base + 4 option year contract with periods of performance of:

• Base Period

• Option Year 1

• Option Year 2

• Option Year 3

• Option Year 4

4. Vendor Qualifications:

4.1 Experienced mass notification vendor, with a history of multiple Federal, state and local government contracts, operating with an operating platform in a FedRAMP approved data center at minimum level of Moderate.

4.2 Eligible for small business set-aside.

5. Requirements:

The ATF Certification and Accreditations (C&As) process is aligned with the NIST SP800-64 “Security Consideration in the Information System Development Lifecycle”, October 2008; it follows the five lifecycle phases of Initiation, Development and Acquisition, Implementation, Operations and Maintenance and Disposition. This five-step lifecycle is closely aligned with ATF Handbook 7200.2B ATF System Life Cycle (SLC). The table Security Artifacts and Activities Per SLC Phase below shows a high-level list of security artifacts and activities due during each SLC Phase.

5.1.1. The proposed system must provide a web-based system in a Federal Risk and Authorization Program (FedRAMP) approved (see below for levels) environment that provides the ability to access the system via a secure, encrypted internet connection using a US government sanctioned encryption method. from any approved computer, tablet or smart phone in order to initiate alerts and notifications via any mode supported by the system.

5.1.2. The proposed system shall be fully hosted by the vendor in a FedRAMP environment certified at Moderate or above and shall only require an internet connected computer to send messages and operate the system. FedRAMP High certification may be given additional credit in solicitation evaluation provided that a risk-benefit evaluation of any features that may not operate in a high configuration determines those features are not required.

5.1.3. The proposer’s system shall have a robust hardware and a geographically dispersed components across the United States of America with failover mechanisms in place to ensure the ability to operate under all conditions and provide security and redundancy eliminating any single point of failure. The proposal shall document how this system provides this capability and ensures continued operation in the event of computer equipment failures, loss of utility power, natural disaster or intentionally caused human physical or virtual attack.

5.1.4. The proposer’s system will be required to comply with all Federal information technology operating and security requirements in place at the time the solicitation is awarded. In order to accept the system, the vendor will have to support ESS staff to complete the ATF Certification and Accreditations (C&As) process. This is aligned with the NIST SP800-64 “Security Consideration in the Information System Development Lifecycle”, October 2008; it follows the five lifecycle phases of Initiation, Development and Acquisition, Implementation, Operations and Maintenance and Disposition. This five-step lifecycle is closely aligned with ATF Handbook 7200.2B ATF System Life Cycle (SLC). This C&A process will determine if the system can be used to interact with ATF computers and process ATF information.

5.1.5. The proposed system must be capable of authenticating users to the vendor hosted system using government provided Personal Identity Verification (PIV) credentials.

5.1.6. Proposed system must be technically capable of allowing access to at least 75 users simultaneously and allowing the activation of all types of alerts and notifications (including GIS mapping alerts), database maintenance, system maintenance, report queries, or whatever duties their assigned security level allows without degrading system performance.

5.1.7. The proposed system must recognize administrators and authorized users and enforce their privileges based on system security settings in a customer configurable matrix:

5.1.8. The proposed system must have a customer editable matrix of common administrator, supervisor and users access tights so that the customer can create the privileges for at least five user-defined levels of access.

5.1.9. The proposed system must provide the ability to partition sections of the database to departments within ATF to share the notification components of the system but operate within their own segregated database environment to ensure integrity and confidentiality of their data.

5.1.10. The proposed system must have levels of segregation to accommodate a multi-department structure with multiple tiers within each department. A small number of administrators would have global access to manage the entire system, but most privileged users would be limited to their department and data structure.

5.1.11. The proposer shall describe how the conduct preventative maintenance and emergency maintenance and how that is managed to ensure the system has 100% availability.

5.2. Dailing Services

5.2.1. Must be capable of sending out multi-modal messages, at a minimum, via:

5.2.1.1. Landline (record voice or text to speech voice)

5.2.1.2. Cell phone (recorded voice or text to speech voice)

5.2.1.3. SMS Text Message (using pre-approved short or long codes provided by the vendor that are immediately available for use by ATF)

5.2.1.4. MMS Text Message (using pre-approved short or long codes provided by the vendor that are immediately available for use by ATF)

5.2.1.5. E-mail

5.2.1.6. VoIP

5.2.1.7. Social media

5.2.2. The proposer must describe how they operate their outgoing message infrastructure across all services. If a third-party service is used, they must provide the service level agreement(s) (SLAs) with any third-party vendors to describe how the third-party service operates and continuous operating ability is provided.

5.2.3. The proposed system should have the ability to detect local telephone company infrastructure limitations and adjust the volume of calls as needed to increase efficiency.

5.2.4. The proposer must describe how the proposer identifies requirements for, and executes, the throttling of calls, Include any provisions for on-going evaluation of throttling requirements beyond the initial deployment phase.

5.2.5. The proposer’s system should have ability to throttle calls based upon user designated priorities for notifications.

5.2.6. Proposer should describe in their proposal the speed of message delivery by providing an explanation of the capabilities of their system across the different modes of communications.

5.2.7. Proposer should propose various service level options at least one of which includes unlimited phone call-out minutes at one set fee regardless of the number of calls made or minutes used during the call, SMS text messages, and emails.

5.2.8. The proposed system shall allow customization of displayed caller ID number and readout for the outgoing calls based upon department within the notification system that is initiating the notification.

5.2.9. The proposed system must include a feature set that allows messages to be designated sensitive and only be able to be retrieved by the recipient after the enter PIN code assigned to their personal profile in the notification system.

5.2.10. The system must include a multi-step process to authenticate users before launching public messages that can be toggled on or off based on an individual users profile or in the permissions matrix. Further:

5.2.10.1. The system should include “fail-safe” features to prevent “unintended test” messages from being launched to the public.

5.2.10.2. The system must meet or exceed “public safety grade” security and reliability standards.

5.2.10.3. The system must be fully Section 508 compliant and ADA compliant.

5.3. Calling Database Management

5.3.1. The government will require at least two distinct databases be operated by the system. The proposer must describe in their proposal, including any cost associated with this requirement, the means for loading contact information into its system (automated upload/download capability accomplished with a simple comma delimited file, or other approved method, via direct entry into proposer’s system). This data transfer must occur in a secure, encrypted fashion in accordance with Department of Justice and ATF information security requirements. The data updated daily will be two separate databases:

5.3.2. ATF Employee data from the Microsoft Identity Management System. The data attributes may include the following based on the FedRAMP certification level of the data center:

5.3.2.1. First Name

5.3.2.2. Last Name

5.3.2.3. User ID (Employee ID)

5.3.2.4. Login Name (Employee ID)

5.3.2.5. Employee Type (Employee or Non-Employee)

5.3.2.6. Division

5.3.2.7. Email 1

5.3.2.8. Org Cide

5.3.2.9. Work Address

5.3.2.10. Zip Code

5.3.2.11. Cell Phone 1 (Government Cell Phone)

5.3.2.12. Cell Phone 2

5.3.2.13. Text Number 1 (Government Cell Phone)

5.3.2.14. Text Number 2

5.3.3. Federal Firearms Licensee data from the Firearms License System. The data attributes will include:

5.3.3.1. Premise Street Number and Name (single field)

5.3.3.2. Premise City

5.3.3.3. Premise State

5.3.3.4. Premise Zip Code

5.3.3.5. App County Name

5.3.3.6. App Voice Phone

5.3.3.7. App email

5.3.3.8. Responsible Party First Name

5.3.3.9. Responsible Party Last Name

5.3.3.10. Responsible Party GPS Coordinates

5.3.3.11. Responsible Party email

5.3.3.12. Dealer Class

5.3.4. The contact information database should have data import and export capabilities using industry standard formats and API’s (e.g. Excel, comma delimited, MS SQL, Active Directory, etc.).

5.3.5. The system must have error checking capability to manage data from all sources to prevent duplication of automatically imported records, but allow records entered manually to survive automatic updating.

5.3.6. Explain whether the proposer’s product allows administrative users to filter contacts by different characteristics, such as classification, opt out status, and those with at least one phone number, email, SMS device registered, etc.

5.4. User Management

5.4.1. The proposer’s system must have the ability to create customized rosters/lists of individuals who will be routinely or intermittently contacted.

5.4.2. Within the roster/lists it must be possible to set rules using if/then statements to manage device order, delays, and excluding or including devices and modes of notification by activation. For example, specifying that a notification is only to be sent to a given device if user does not respond within X number of minutes or only send on specific days and times.

5.4.3. The proposed system must include a secure web portal which allows individuals to register to receive notifications from the notification system after the receive an invite from the government and register with the self-registration portal that the government may offer to users of the self-registration portal. The portal should allow the registrant to:

5.4.3.1. Identify their location on a map, provide email and phone number in order to opt-in to various notifications the Government may choose offer, and;

5.4.3.2. Login to update their devices and manage their contact information and change their notification settings.

5.4.4. The proposed system could/should include a mobile application for public use.

The application should at a minimum allow the user to change their registration and opt in or out of notifications. Fully describe the function and all capabilities of the proposed mobile application. Fully disclose any cost to the public for download or use of the application including any required or optional in app purchases.

5.5. Message Creation and Delivery

5.5.1. Creating a notification in the system must intuitive, quick and easy and based on standard conventions and ergonomics of software design.

5.5.2. The system must have the capability of being activated by authorized users from a mobile phone application. Functionality to activate pre-developed notification sequences using a telephone (landline or cellular) using DTMF keys is also desired.

5.5.3. The system must be capable of sending out both emergency notifications and other notifications to users who have registered through the self-registration portal.

5.5.4. The system must have the ability to prioritize messages (i.e. High, Medium, and

Low). The proposer’s response shall describe how this feature functions and enables the system to execute multiple notification requests simultaneously (i.e.

different messages delivered to different groups of contacts at the same time) in the shortest period of time, maximizing system resources, and honoring the priority entered by the message creator.

5.5.5. Explain any impact execution of multiple notification requests may have on delivery times.

5.5.6. The system must have the ability to record live voice or send pre-recorded and/or uploaded voice files. The recording of live voice must be allowed either through a microphone attached to a computer device or a phone.

5.5.7. The must have a text-to-speech translation feature that provides clear and distinguishable speech.

5.5.8. The system must have the ability to create scenarios and store prepared messages to be initiated in the future.

5.5.9. The system must have the ability to provide for a two-way polling message capability that allows a response to be provided either from a list of choices designed into the notification or free text provided back to the notification software and compiled in a report.

5.5.10. For outgoing messages, the system must adapt its message delivery depending on detection of a human voice v. an automated answer device (such as an answering machine or fax machine) and appropriately tailor the delivery of the outgoing message as appropriate to deliver the notification message to an answering machine or voicemail or end the call if the line is not a capable of receiving the message.

5.5.11. The system shall provide written reports and screen dashboards for all notification sequences that the who the intended recipient was, the phone number used, unsuccessful delivery attempts, successful delivery, times of each attempt and the successful delivery and notations of technical failure factors known to the system.

5.5.12. The system must have the ability to terminate any message notification in progress.

5.5.13. The proposer shall explain any ability the system has to allow messages to expire if not successfully delivered to a recipient.

5.5.14. The system shall have the ability to schedule alerts/notifications and have daily, weekly, or monthly reoccurring alerts/notifications.

5.5.15. When used to notify rosters, the proposed system should:

5.5.15.1. Have the ability to query recipients regarding their availability and ETA using automated prompts.

5.5.15.2. Include the capability to create and customize queries.

5.5.15.3. Have the ability to view message responses in real time.

5.5.15.4. Be capable of capturing feedback from automatic prompts in comprehensive reports.

5.5.16. Proposer should specify (separately for text and voice) how many messages it can deliver per minute and per hour independently listing all priority levels if time delivery varies.

5.5.17. Explain any client priorities your system may have, for example, during a large scale event affecting a region or multi-state area.

5.5.18. Proposed system should include an Application Programming Interface (API) for integration with Facebook and Twitter to post notifications sent through the system.

5.5.19. Proposed system should include the ability to update multiple Facebook/Twitter pages by user designation.

5.5.20. Proposer should have a Memorandum of Agreement (MOA) with the Federal

Emergency Management Agency (FEMA) and the proposed system should provide integration to the FEMA Integrated Public Alert and Warning System (IPAWS) for the following functional categories:

5.5.20.1. Interop (COG-to-COG): Capability to exchange situation information between

Collaborative Operating Groups (COGs) via Common Alerting Protocol (CAP) and/or Emergency Data Exchange Language Distribution Element (EDXL-DE).

CAP 1.2 and EDXL-DE

5.5.20.2. Post NWEM: Non-weather emergency message (NWEM) authoring interface for the National Weather Service HazCollect system. CAP 1.2

5.5.20.3. Post EAS: Emergency Alert System (EAS) authoring interface. CAP 1.2 (d) Post

CMAS: Commercial Mobile Alert System (CMAS) authoring interface. CAP 1.2

5.5.20.4. Retrieve/Disseminate: System polls IPAWS-OPEN to retrieve and/or disseminate alerts CAP 1.2

5.5.21. The proposed system should include alert origination and dissemination tools compliant with Common Alerting Protocol (CAP) version 1.2 and additional requirements of the Organization for the Advancement of Structured Information Standards (OASIS) IPAWS Profile specification to work with all IPAWS alert dissemination systems.

5.5.22. Proposer should specifically detail if IPAWS is integrated into the application core or offered as a stand-alone application.

5.6. Mapping and Geographic Data Selection

5.6.1. The proposed system should include the use of a GIS mapping interface that allows the user to designate an area to be notified with the following functions at minimum:

5.6.1.1. Circle with a given radius

5.6.1.2. Predetermined geographic areas (zip code, evacuation zone, imported layer, etc.)

5.6.1.3. User-defined polygon

5.6.1.4. Buffer from selected feature

5.6.1.5. Multi-ringed buffer from site (1, 2, 3-mile radius, etc.)

5.6.1.6. Imported Images (i.e. plume model)

5.6.2. The proposal shall fully describe the mapping utilized and the geographic selection features which will be part of their solution.

5.6.3. The system must allow the user to select multiple contiguous or non-contiguous areas for notification.

5.6.4. The system must have the ability to import ESRI “shape” files and save these areas for future use. Please explain any limitations to such a feature including any data structure requirements such as datum.

5.6.5. The system must be able to add custom mapping layers.

5.6.6. The system must have the ability to designate specific addresses while determining a radius around these target areas.

5.6.7. The system must be easy for users to broaden notification area and re-launch a message to new selections and prior non-connects, but previous message recipients should not receive the same message again.

5.6.8. The system must have the ability to prioritize notifications closest to the event location and systematically expand outward.

5.6.9. The system must be able to geo-code all address data at entry. Please explain how the proposed solution can prevents Centroid geo-coding practices.

5.7. Monitoring and Reporting

5.7.1. The system shall provide real time monitoring of delivery results for all modes of transmission.

5.7.2. The system shall provide system reporting capabilities including:

5.7.2.1. Notification content

5.7.2.2. Recipient/Group list

5.7.2.3. Time of transmit by each device by each recipient

5.7.2.4. All attempts with specific results

5.7.2.5. Recipient responses

5.7.2.6. Summary of responses and time notification was closed.

5.7.3. The proposer must provide samples of their standard reports.

5.7.4. The system must have historical reporting available for all the above information for at least one year for viewing or upload to other reporting databases.

5.7.5. The system should provide verifiable confirmation that a contact has or has not been alerted, and confirmation as to the mode and time of contact acknowledgement.

5.7.6. The proposer shall describe its system’s ability to receive custom responses back from recipients of email, text, and voice messages; that is, allowing the recipient to send a response or reply message. Proposer should include information on how responses are collected, aggregated (if appropriate) and presented to the administrative user.

5.8. Cost, Maintenance, Training and Support

5.8.1. The government seeks to solicit for a base year contract with four additional option years for a total of five years.

5.8.2. Initial training must be provided at no additional cost. The proposer will provide a minimum of one training session on site for system administrators and a minimum of four webinar style training sessions for privileged users below the administrator level.

5.8.3. The proposer shall provide written training materials for each training participant and electronic copies of all materials shall be provided for future training purposes.

5.8.4. Proposers must supply examples of training materials and descriptions of the training sessions as part of their proposal response.

5.8.5. The proposer must provide 24-hour x7 days a week X 365 days a year technical support. These services should be provided at no additional cost to the Government.

5.8.6. The proposer must provide a written plan describing how they will release, update and maintain their system software. The proposer should identify the releases, updates and maintenance which are included in their proposal and any potential costs to maintain the system which are not included.

5.8.7. The proposals must include a pricing structure indicating the cost breakdown for all the included services offered. Any “options” that are offered, or have been shown during sales presentations using vendor demonstration software, will be included as a separate line and clearly indicated as an options.

5.8.8. Explain how you’re pricing is determined (population, registrations, contacts) and what is included in the proposed price.

5.8.9. Proposer should offer multiple usage options/levels at least one of which includes unlimited phone call-out minutes at one set fee regardless of the number of calls made or minutes used during the call, SMS text messages, and emails; please provide details.

5.9. Government Furnished Property/Equipment: No government furnished property or equipment is being provided.

6. Period of Performance: The Period of Performance will be for one (1) Base year with four (4) Option years. FAR 52.217-8, Option to Extend Services, is included in this requirement to provide an extension of up to six months. The Option to Extend Services clause may be exercised by the Contracting Officer at any time during the period of performance or to extend the period of performance.

7. Place of Performance: The place of performance shall be at the National Coordination Center at

99 New York Avenue, NE, Suite 2N-584, Washington, D.C. 20226.

8. Personnel Security: The nature and specific degree of background investigation or facility review will be determined by ATF’s Personnel Security Division (PSD) as required, depending upon the nature and degree of risk associated with the requirement and the position. All contractor personnel assigned to this contract must be cleared by ATF before commencing work or having access to government facilities or information. These agency specific ATF requirements are independent of National Security clearances and may increase the time to process individuals to be able to work inside ATF facilities or have access to ATF information. This must be factored into timelines for acquiring and on-boarding new personnel.

If required, contractors must undergo and receive a favorably adjudicated, Federal background investigation (BI) as determined by the position’s sensitivity designation. The BI is to determine the contractor’s suitability to access ATF information, information technology (IT) systems and/or unescorted access to facilities.

This investigation will be conducted by or under the auspices of the ATF, Personnel Security Division (PSD) and be performed under such standards PSD may establish. If a contractor has a current BI with another agency, PSD will follow reciprocity procedures for security; however, a review to determine the contractor’s compliance with all ATF agency specific requirements will be conducted prior to authorizing access to ATF information, IT systems, and/or unescorted access to facilities.

Failure to adhere to ATF’s conduct and integrity guidelines and/or follow DOJ’s and/or ATF’s agency-specific qualifications may result in immediate disqualification of the contractor. Additionally, failure to complete the required personnel security forms and have a BI favorably adjudicated will result in disqualification. ATF must determine a favorable adjudication of the BI prior to the contractor gaining access to ATF information, IT systems and/or unescorted access to ATF’s facilities.

The Contractor may be authorized access to ATF information, IT systems and/or unescorted access to facilities with an approved temporary eligibility (TE) while awaiting the completion of the full BI. The ATF Contracting Officer’s Representatives may request a TE only after advising and gaining the concurrence of the contractor. Should, at any time, suitability or security issues are developed that cannot be resolved or mitigated, the contractor will no longer be granted continued access to ATF information, IT systems, and/or unescorted access to any ATF facility and will be removed from the contract/task order.

Unless exempted by the CO, in writing, all email communications after contract award to complete work on this contract shall be transmitted via electronic mail (e- mail) using government accounts.

9. Organizational Conflict of Interest: Contractor and subcontractor personnel performing work under this requirement may receive, have access to or participate in the development of proprietary or source selection information (e.g., cost or pricing information, budget information or analyses, specifications, or work statements, etc.) or perform evaluation services which may create a current or subsequent Organizational Conflict of Interests (OCI) as defined in FAR Subpart 9.5. The contractor shall notify the CO immediately whenever it becomes aware that such access or participation may result in any actual or potential OCI and shall promptly submit a plan to the CO to avoid or mitigate any such OCI. The contractor’s mitigation plan will be determined to be acceptable solely at the discretion of the CO and in the event the CO unilaterally determines that any such OCI cannot be satisfactorily avoided or mitigated, the CO may affect other remedies as he or she deems necessary, including prohibiting the contractor from participation in subsequent contracted requirements which may be affected by the OCI.

10. Inspection and Acceptance:

11.1 Supplies or services delivered under this requirement shall be inspected and accepted by the respective COR. The Contractor shall only tender for acceptance those items that conform to the requirements of this requirement. The Government reserves the right to inspect or test any supplies or services that have been tendered for acceptance IAW the appropriate inspection and acceptance clause.

11.2 The basis for acceptance shall be compliance with the requirements, objectives and other terms and conditions set forth in this PWS.

11.3 Deliverable items rejected shall be corrected IAW the applicable clause(s) or PWS specifications.

11.4 The COR will review all draft and final deliverables` to ensure accuracy, functionality, completeness, professional quality, and overall compliance within the guidelines/requirements of the PWS. The Contractor shall ensure the accuracy and completeness of all deliverables.

Errors, misleading or unclear statements, incomplete or irrelevant information, and or excessive rhetoric, repetition, and “padding”, shall be considered deficiencies and shall be subject to correction by the Contractor, at no additional cost to the Government.

11.5 Unless otherwise indicated, the government will require seven (7) business days to review and comment on deliverables. If the deliverable does not meet the noted criteria, the Government will return it for correction.

11. System for Award Management (SAM): The selected contractor shall have an active registration in the SAM database prior to award in accordance with Federal Acquisition Regulation 52.204-7.