Emergency Notification System

The Vendor is required to provide emergency notification system would have the following capabilities:
•    Reliable – near 100% uptime, redundancy
•    Scalable – robust configurability
•    Usability – easy to configure, easy to administer
•    Security – user contact information is highly secure
•    Multi-channel communication – send notifications in different ways simultaneously
•    Integration – user contact information kept up to date via regular data feed or direct connectivity to database
•    Reporting and analytics – robust reporting to include user audit data, easy to configure metrics reports
•    Two-way communication – notification acknowledgement
- Emergency notification system (ENS) features needed:
1. Reliability
•    Uptime must be near 100%. 
•    Downtime for maintenance should be no more than 1 hour per week.
•    Notifications, even if multi-channel, should reach intended audience in no more than 60 seconds.
•    Department would like to be able to execute a small pilot of the system prior to committing to purchase for the entire agency.
•    Must have redundant system so we still have availability during maintenance windows or other downtime.
•    Department would prefer to host in our own environment.
2. Scalability
•    System should allow us to build our own templates as we identify more scenarios that require notification.
•    System should allow us to add new zones as our sites change.
•    System should allow recorded "hotline" messages.
•    If available, system should allow us to add and change the hotline messages
•    If available, system should allow multiple different hotline messages that user can call in and select from
3. Usability
•    System offers minimum 3 user types: admins (to manage and configure system), operators (to send notifications), and subscribers (to receive notifications).
•    System offers ability to group subscribers by customizable characteristics: office/building, city, zone and region, job title or other security level.
•    System should be so intuitive that only minimal training is required for operators, and no training is required for subscribers.
•    System should allow authorized admins and operators to configure and send pre-scripted messages or compose custom messages.
•    System should allow users to select subscribers by individual or characteristic group for each message.
•    System should allow operators to select channels for each message.
•    Subscribers can enroll personal cell phones and email addresses.
•    Messages can be scheduled.
•    System should allow subscribers to receive notifications on desktops and mobile devices (phones, tablets) without requiring an app installation
•    Mobile app is available for operators to send messages "on the go".
•    Ability to configure required notifications vs optional notifications.
•    Subscribers should be able to opt-in to receive optional notifications (ex: weather).
•    Recipients get messages in their preferred language.
•    Ability to recover from admin lockout.  
•    Will have multiple admins.
•    Subscribers should include local LEO and emergency response.
•    Automated bi-annual and annual confirmation of contact information
•    Subscribers should be able to set their primary work location, so they receive appropriate notifications. 
•    Select additional and different zones and set their primary work location.
•    Subscribers should be able to select additional and different zones to receive notifications.
•    System should handle at least 4000 subscribers cleanly.
•    System should allow texts to be scheduled on a recurring frequency.
4. Security
•    System should protect subscriber contact information.
•    System should have strong access controls and use for anyone who logs in to update their profile.
•    System should prevent unauthorized users from accessing system.
•    System should track every notification and provide audit logs of sender, recipients, message, priority, zones, etc.
•    Vendor must provide documentation (upon request) for internal agency NIST audit compliance artifacts and reporting cycle.
•    System should expire default passwords at first login.
•    System must include encryption of user data in transit during enrollment and profile maintenance on any open networks.
•    System should be fed ramp (preferred), but state ramp is acceptable.
•    System should integrate with authentication (single-sign-on for admins and operators).
•    Right to be forgotten: erasure of agency data upon user disenrollment or contract termination will be permanent and binding.
•    Data portability: agency has the right to retrieve all collected data upon notification of termination of contract and use this data for other applications.
•    Further processing: agency will be notified of any existing or future 'further data processing' of proprietary agency data.
•    Further processing: notification of 'further processing' will include location, service, and third-party vendor as applicable to both data controller and data processor.
•    Vendor required to collect net flow, event, and application logs from servers, server less applications, and firewalls x 30 days encrypted in transit rest.
•    Vendor to prevent agency data from offshore transit beyond continental us.
•    Vendor is prohibited from utilizing any agency data, including messaging content, for training or enhancing any ml (machine learning), AI (artificial intelligence), LLM (large language model) or similar application.
5. Multi-channel communication
•    System should be capable of sending to multiple channels simultaneously.
•    System offers pre-recorded "hotline" messages that users can call in and listen to.
•    System must be able to push email, SMS and text, voice calls.
•    System should be able to send notifications via instant messaging, desktop push.
6. Zone-based alerts
•    System must allow notifications based on customizable zones like region, city, facility, office, etc.
•    System should allow configuration of at least 500 zones, regions, cities, facilities, offices, etc. (prefer unlimited).
•    System should allow a single district to be part of multiple zones.  Ex: each office needs to be part of a city as well as a region as well as a district.
•    System should be able to send notifications based on real-time location.  
•    We might want to require for state phones but it would be optional for personal phones.
7. Integration
•    System has API capable of importing contact information from an external system via flat file.
•    System should allow notifications to be triggered based on flat file data.  (Ex: we want to trigger a notification based on data that comes out of our proprietary ETS system.)
•    System must allow manual data imports. (Ex: we may need to run an off-cycle data import.)
•    System should allow scheduled data imports. 
•    At least once per day with more frequent manual imports.
•    System should be capable of segregating opt-in contact information from imported contact information, so that imported data does not overwrite opt-in data.
•    SNS and email message configuration must include certificates to pass email spoof filtering.
•    System should be able to integrate with active directory.
8. Reporting and analytics
•    System must have a user activity audit report to include, at a minimum, login and logout, locked account, privilege changes, activation and deactivation, and profile changes.
•    System should have a report of subscriber notification acknowledgements - who, when, by what means (text, email, voice).
•    System should have a metrics report that includes messages by type, zone, and other characteristics.
•    System should allow view of historical messages and recordings.
9. Vendor (product) quality, longevity, support
•    Product should be 800-53 compliant.
•    Vendor must provide a copy of their most current soc3 report.
10. Maintenance and support
•    Customer must have full control of user account access and privileges.
11. Two-way communication
•    System should allow each message to be configured for no-reply or acknowledgement.
•    System should allow configuration of acknowledgements. Ex: 1- ACK, 2-ok, 3-travel restricted, 4-iced in, 5- sick, etc.