Replacement Notification System

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.

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.
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.  
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.
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. The proposed system must be capable of authenticating users to the vendor hosted system using government provided Personal Identity Verification (PIV) credentials.   
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. 
7. The proposed system must recognize administrators and authorized users and enforce their privileges based on system security settings in a customer configurable matrix:
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. 
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.  
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. 

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

2. Dailing Services

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

• Landline (record voice or text to speech voice)
• Cell phone (recorded voice or text to speech voice)
• SMS Text Message (using pre-approved short or long codes provided by the vendor that are immediately available for use by ATF)
• MMS Text Message (using pre-approved short or long codes provided by the vendor that are immediately available for use by ATF)
• E-mail
• VoIP
• Social media

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. 

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.

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. The proposer’s system should have ability to throttle calls based upon user designated priorities for notifications. 

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. 

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.

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.

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. 

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: 

• • The system should include “fail-safe” features to prevent “unintended test” messages from being launched to the public.
  • The system must meet or exceed “public safety grade” security and reliability standards.
  • The system must be fully Section 508 compliant and ADA compliant.

3.           Calling Database Management

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:

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:

•               First Name
•               Last Name
•               User ID (Employee ID)
•               Login Name (Employee ID)
•               Employee Type (Employee or Non-Employee)
•               Division
•               Email 1
•               Org Code
•               Work Address
•               Zip Code
•               Cell Phone 1 (Government Cell Phone)
  • Cell Phone 2
  •               Text Number 1 (Government Cell Phone)
  •                Text Number 2

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

•               Premise Street Number and Name (single field)
•               Premise City
•               Premise State
•               Premise Zip Code
•               App County Name
•               App Voice Phone
•               App email
•               Responsible Party First Name
•               Responsible Party Last Name
•               Responsible Party GPS Coordinates
•               Responsible Party email
•               Dealer Class

1. 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.).
2. 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.
3. 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. 

4.           User Management

1. The proposer’s system must have the ability to create customized rosters/lists of individuals who will be routinely or intermittently contacted.
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.
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:

• 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;
• Login to update their devices and manage their contact information and change their notification settings.
• 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.           Message Creation and Delivery

1. Creating a notification in the system must intuitive, quick and easy and based on standard conventions and ergonomics of software design. 
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. 
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.
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. Explain any impact execution of multiple notification requests may have on delivery times.
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. 
7. The must have a text-to-speech translation feature that provides clear and distinguishable speech. 
8. The system must have the ability to create scenarios and store prepared messages to be initiated in the future.
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.
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.
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.
12. The system must have the ability to terminate any message notification in progress.
13. The proposer shall explain any ability the system has to allow messages to expire if not successfully delivered to a recipient. 
14. The system shall have the ability to schedule alerts/notifications and have daily, weekly, or monthly reoccurring alerts/notifications.
15. When used to notify rosters, the proposed system should:

1. Have the ability to query recipients regarding their availability and ETA using automated prompts.
2. Include the capability to create and customize queries.
3. Have the ability to view message responses in real time.
4. Be capable of capturing feedback from automatic prompts in comprehensive reports.

1. 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.
2. Explain any client priorities your system may have, for example, during a large scale event affecting a region or multi-state area.
3. Proposed system should include an Application Programming Interface (API) for integration with Facebook and Twitter to post notifications sent through the system.
4. Proposed system should include the ability to update multiple Facebook/Twitter pages by user designation.
5. 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:

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

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

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

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

1. 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.
2. Proposer should specifically detail if IPAWS is integrated into the application core or offered as a stand-alone application.

6.           Mapping and Geographic Data Selection

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:

•   Circle with a given radius
•   Predetermined geographic areas (zip code, evacuation zone, imported layer, etc.)
•   User-defined polygon
•   Buffer from selected feature
•   Multi-ringed buffer from site (1, 2, 3-mile radius, etc.)
•   Imported Images (i.e. plume model)

1. The proposal shall fully describe the mapping utilized and the geographic selection features which will be part of their solution.
2. The system must allow the user to select multiple contiguous or non-contiguous areas for notification.
3. 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.
4. The system must be able to add custom mapping layers.
5. The system must have the ability to designate specific addresses while determining a radius around these target areas.
6. 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.
7. The system must have the ability to prioritize notifications closest to the event location and systematically expand outward.
8. 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.

7.           Monitoring and Reporting

1. The system shall provide real time monitoring of delivery results for all modes of transmission.
2. The system shall provide system reporting capabilities including:

• Notification content
• Recipient/Group list
• Time of transmit by each device by each recipient
• All attempts with specific results
• Recipient responses
• Summary of responses and time notification was closed.

1. The proposer must provide samples of their standard reports.
2. 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.
3. 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.
4. 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.

8.           Cost, Maintenance, Training and Support

1. The government seeks solicit for a base year contract with four additional option years for a total of five years. 
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. 
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.
4. Proposers must supply examples of training materials and descriptions of the training sessions as part of their proposal response.
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.
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.
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.
8. Explain how you’re pricing is determined (population, registrations, contacts) and what is included in the proposed price. 
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.
10. Outline and explain any possible additional fees or provide a clear statement that there will be no additional fees.