RFP27007119 Scope of Work.pdf

2023-1.v3.04082026 RFP – Agency Solicitation Specifications Page 1 of 19 Revised 4/8/2026

RFP27007119 - AGENCY SOLICITATION SPECIFICATIONS

TITLE: RHODE ISLAND STATE ALERT WARNING AND NOTIFICATION SYSTEM

DESCRIPTION: EMERGENCY ALERT AND WARNING TO THE PUBLIC

PRE-BID/ PROPOSAL CONFERENCE: NO

MANDATORY: NO

BONDING REQUIREMENTS:

BID SURETY BOND REQUIRED: NO

PAYMENT AND PERFORMANCE BOND REQUIRED: NO

CONTRACT TERMS:

The initial contract period will begin approximately April 1st, 2027 for a 3-year period, which includes the Implementation period. Contracts may be renewed for up to 3 additional 24-month periods at the sole discretion of the State based on vendor performance and the availability of funds.

INSURANCE REQUIREMENTS: See OSP solicitation information.

SECTION A: BACKGROUND

The State of Rhode Island, through the Rhode Island Emergency Management Agency

(RIEMA), is seeking proposals for a comprehensive, cloud-based, statewide Alert, Warning, and

Notification (AWN) system. The goal is to establish a unified, multi-tenant platform that grants access to a statewide tenant, all thirty-nine (39) municipalities, recognized tribal nations, and seven (7) core state agencies, with expected user count between 50-700 users.

This system must balance localized, municipal-level control for targeted community notifications with centralized state-level oversight for high-level, mass-dissemination authorities.

Currently, Rhode Island relies on a disparate patchwork of AWN protocols, methods, and software platforms across various state, local, and tribal jurisdictions. While some municipalities and state agencies have independently invested in localized software solutions, many areas remain unserved or underserved.

This fragmented implementation presents significant operational challenges:

2023-1.v3.04082026 RFP – Agency Solicitation Specifications Page 2 of 19 Revised 4/8/2026

• Lack of Interoperability: Existing systems operate in silos, preventing real-time data sharing and cross-jurisdictional visibility between municipal emergency managers, state agencies, and federal partners.

• Geographic Gaps for Transient Populations: Because current local systems are primarily "opt-in," residents traveling outside their home municipalities, as well as out-of-state tourists, fail to receive critical alerts even if they have opted into their home jurisdiction's system.

• Administrative Complexity: Managing competing vendor contracts, inconsistent hardware/software requirements, and separate system maintenance strains local resources and limits cohesive statewide coordination.

Desired Future State and Core System Requirements

The State requires a holistic, interoperable platform that streamlines communication across all levels of government while preserving distinct operational capabilities:

• Centralized IPAWS Authority: The system must support the Integrated Public Alert &

Warning System (IPAWS) capability, including the Wireless Emergency Alerts (WEA) and the Emergency Alert System (EAS). To ensure strict regulatory compliance and message integrity, IPAWS launch capability must be restricted to the State level

(RIEMA), while allowing local tenants to request or draft alerts for state approval and dissemination.

• Localized Core Capabilities: All 39 cities and towns, alongside tribal and state agency tenants, must retain the ability to launch localized notifications. The platform must fully support and maintain:

o Reverse 911 Capability: The ability to upload, maintain, and target landline/Geographic Information System (GIS) based location data for emergency call-outs.

o Public Opt-In Portals: Robust, user-friendly mechanisms for residents and visitors to opt into specific local keyword alerts, weather warnings, and non-emergency community notifications.

• Operational Redundancy: RIEMA, in coordination with the selected vendor, will act as the system "Power User." RIEMA will maintain full visibility across all sub-tenants and serve as the operational backup to originate local AWNs if a municipal or tribal alert originator is compromised or unable to broadcast.

Governance and Vendor Management: The selected vendor will manage the end-to-end implementation, ongoing maintenance, change management, and technical support for all participating tenants. System access, protocols, and standard operating procedures will be overseen by a newly established statewide Governance Council.

2023-1.v3.04082026 RFP – Agency Solicitation Specifications Page 3 of 19 Revised 4/8/2026

SECTION B: SCOPE OF WORK AND REQUIREMENTS

SYSTEM REQUIREMENTS

Offeror shall provide a commercial-off-the-shelf (COTS) or a Software as a Service (SAAS) product mass notification and communication system that leverages secure and modern communication method to issue AWNs. Offeror must respond to each of the items below and indicate whether and describe how Offeror’s system complies with, meets or exceeds the General

System Requirements and the Specific System Requirements, as follows:

General System Requirements:

1) User Functionality

1. Identify whether the system offers the following functionality and if so, describe:

a. Client branding to websites, internal portals, etc.

b. Non-secure landing page (prior to login credentials being entered).

c. System wide user directory.

2. Please describe how staff will be trained

a. Optional – Please describe any on-site supplemental/custom training offered

2) Administrator View

1. Describe how new administrators are added/vetted to the secure system.

2. Describe the types of reports that are available to system level administrators.

Include information on what detailed information is reported by group (end user, role, attribute, alert statistics and success/failure, etc.)

3. Identify whether the system offers the following view features, and if so, describe:

a. Hierarchy of system administration rights and privileges.

b. Customized attribute creation based on a user’s specific job or function.

c. Role/group selection.

3) Secure Notifications and Alerts

1. Please identify and describe in detail each method of message delivery available to the system.

2. How does an administrator select how a message will be disseminated?

3. Describe the location targeting capabilities of the system. Include the following: Where are mapping layers drawn from? How often are they updated? What layers and data sets can be seen within the system?

4. When sending a message to a specific set of users within a defined location, how accurate is the message delivery within the defined area? In other words, if there is “bleed over,” how much?

5. Is there a per notification charge for email, text, fax, and/or phone notifications? If yes, please describe. Include the specific amounts for each type of notification.

6. Identify whether your system offers the following notification features, and if so, describe:

a. Pre-scripted (template) notifications. Can the requirement for notification confirmation or receipt be disabled?

b. Polling questions that can be conveyed back to the notification originator.

2023-1.v3.04082026 RFP – Agency Solicitation Specifications Page 4 of 19 Revised 4/8/2026

7. Is Offeror’s system capable of initiating an IPAWS Message? Is Offeror an approved Alert Origination Software Provider with a current Memorandum of

Agreement on file with the FEMA IPAWS Office?

8. Does Offeror’s system support different languages? If so, how many and what are they? Please describe how multi-language support is offered.

4) System Security

1. Describe the infrastructure supporting Offeror’s company’s system, such as data centers and telecommunications circuits. Is it all domestically based?

(Domestic implies continental US based and is required)

2. Describe Offeror’s system security. If Offeror’s systems SSL encrypted? If yes, with what vendor?

3. Does the system utilize MFA or SSO?

5) System Resiliency

1. Describe any uptime certifications Offeror or Offeror’s affiliated hosting centers have (eg: Uptime Institute Level certification, etc.).

2. Describe how Offeror’s telecommunications are patched to the software and whether there are redundancies

3. Describe Offeror’s systems resiliency and backup system. Including, if the critical event management platform is hardened to provide First Responder

Grade availability, scalability and redundancy to lower the risk of service degradation during a critical event response. Also include the systems are located.

4. If the system’s back up system is independent, describe the process for replication between environments, and whether the backup environments have the same capacity (telecommunications, concurrent logins) as the primary site.

5. What is the process for system backup and restoration in the event of an outage?

6. What are the SLAs for help desk ticket? Are SLAs handled different during an ongoing emergency?

7. Identify whether any component of the system is cloud based and describe.

6) Product Updates

1. Describe the frequency with which major and minor versions are released?

2. Describe Offeror’s quality assurance policies and processes pre- and post-release.

3. Describe Offeror’s commitment to the system. Include defect system, patches, and non-required feature implementation.

7) System Compatibility (Added Value)

1. Explain whether any browsers or Operating Systems are not supported and why.

2. Are there any mobile devices that are not supported for either users (message receivers) or administrators (message originators)?

3. Explain what current systems/compatible systems are deployed throughout the

State of Rhode Island.

2023-1.v3.04082026 RFP – Agency Solicitation Specifications Page 5 of 19 Revised 4/8/2026

8) Optional Features

1. Describe any off-network tools or views Offeror’s system offers. Identify if the system is 100% web based.

2. Describe if caller ID can be set to a customized number. Describe whether

Offeror’s system is federated with other secure systems.

3. Describe any included additional features.

4. Does Offeror have the ability to pre-load business, residential, VoIP, E-911, and/or wireless subscribers contact information into the system?

5. Describe how the system identifies duplicate users, email addresses, phone numbers, etc. with focus on initial implementation

9) Ingestion of Current Data

If selected, does Offeror’s system have the ability to ingest current Opt-In user data, established group lists, templates, etc.? Is there an additional cost for this?

10) Multimodal Communication: Integration with 3rd Party Partners

1. Please describe the ability and extent of Offeror’s system’s ability to integrate with any 3rd party partners. Examples include but are not limited to: Google, Facebook, X

(Formerly Twitter), Instagram, the National Weather Service, U.S.G.S.

2. Please describe the various methods of communication your system utilizes (e.g.

SMS, Email, Voice Call, etc.).

Specific System Requirements:

1) System availability and stability: 99.99% system availability and “up” time with demonstrated geographically diverse redundancy (based upon previous annual trends over a

3-year period).

2) System security: to meet and or exceed industry standard thresholds to include FedRAMP and SOC 3 certifications for health and emergency alerting.

3) Secure access: Access to the notification/communication system must require secure authentication username and password, including password forgiveness and multifactor authentication, not limited to text or authentication app.

4) System Compatibility: System must interface with multi-modal communication systems and devices. Compatibility with multiple browsers and operating systems is required, including android, apple, and windows devices. Must support the convergency of existing state agency subscribed mass notifications systems to be centrally managed.

5) Communications Capabilities: The system must support SMS, RCS, and MMS messaging, e-mail, voice calls, TDD/TTY messaging; really simple syndication (RSS), mobile device apps for android, apple, and windows devices; and integration with various social media platforms

(including but not limited to Facebook, X, and Instagram) and other internet-based services.

For notification methods where the sent message exceeds the allowed number of characters

(i.e. a Tweet) the system must intelligently detect and provide an alternate mechanism for the recipient to view the complete message, such as a short-code link.

2023-1.v3.04082026 RFP – Agency Solicitation Specifications Page 6 of 19 Revised 4/8/2026

6) All text/SMS messaging must be the latest standard in messaging (IE: SMS, MMS, RCS) via cellular network gateway providers. To reduce the possibility of notification messages being handled as spam, the vendor must have an established SMPP short code that it whitelisted with the major US commercial cellular carriers (at minimum Verizon, T-Mobile, and

AT&T). SMTP text messaging, or any portion of the user profile that requires a user to specify their mobile carrier, does not meet this requirement. Must have pre-vetted partners to support the resiliency requirement.

7) Defects: System must be free of any product, design, or programmatic defects that cause impede use or generate multiple system requests.

8) Recipient Alert Confirmation: System must allow notification recipient to confirm receipt of the received alert or communication for certain message types. Confirmation can be via email or text reply, web portal interface, or phone prompt.

9) Administrator view/reports: System and alert success reports must be available to track and monitor individuals' participation with the system. Extract reports on user contact and organization information should also be available.

10) CAP Format: System must be capable of initiating messages in Common Alerting Protocol

(CAP) Version 1.2. and/or most recent approved version. The system must adhere to the

“Common Alerting Protocol” standard specified by FEMA via the Organization for the

Advancement of Structured Information Standards (OASIS). As new CAP versions and sources are implemented, the system must be updated to include CAP format changes as part of ongoing system updates.

11) ‘Opt In” Capability: System must allow recipients to access a web portal to provide contact information and communication method preferences for “opt in” messaging.

12) Location based alerting: System must allow targeting of some types of messaging based upon location. This should be accomplished utilizing a graphical user interface with click and drag polygons, or pre-loaded shape files and a map. It is preferred that the system displays how many users will likely be notified within the given area. The system should be accurate to within 100 meters.

13) Suite of Services: The system should provide a comprehensive suite of services that can be used depending on the specific needs of the situation alerting community members and first responders.

14) NWS Integration: The system must provide automated notifications to users of flash floods, tornados, tsunamis, and other watches and warnings issued by the National Weather Service

(NWS) based on the user’s location.

15) Multi-language Support: The system must support multiple languages and be defined by the recipient of the message.

16) Individualized Messaging based on method: The System must be capable of delivering customized messages, both in the content and the delivery mechanism, to each individual, and in the case of voice messages, using a text-to-speech engine to dynamically create the messages.

2023-1.v3.04082026 RFP – Agency Solicitation Specifications Page 7 of 19 Revised 4/8/2026

17) Multiple Automatic Message Delivery Attempts: Must have the ability to send the notification to one device and, if there is no answer within a specified timeframe, as determined by the type of incident, send the notification to the next device listed in the user’s profile. This includes being able to select which phone device the message is being sent to

(i.e. cell phone vs. work phone vs. home phone). This process must continue until contact attempts for all listed devices defined in the user’s profile are exhausted. The message initiator must have the ability to require the system to continue contact attempts until contact is successful.

18) Notification of Groups and Individuals: Must have the capacity to notify predefined groups and “on-the- fly” ad-hoc groups, not only by name, but by all fields (i.e. roles, agency worked for, geographic location, and political jurisdiction).Must have the capacity to notify

‘subgroups’ (i.e. group(s) within a group), as applicable. Must have the capacity to select individuals even if they are not in a group or subgroup, as applicable.

19) Must allow for the activation of alerts via the Internet or telephone; security must be in place to only permit a notification request from specific, predefined phone numbers and systems user identification accounts. Additionally, a log of notification requests from any source, successful or not, must be maintained in the system (not through manual logging) and made available as an automated report.

20) Must allow for multiple layers of authorization/authority. Multiple authorized users must be able to send a non-emergency notification via email or fax, but only those with approved authority can send emergency notifications.

21) Must be able to have multiple layers of administrator rights as to what access is given (i.e.

view, change, add, and notify rights determined by the State office).

22) Must have the ability to provide login audit tracking.

23) Must have the ability to maintain privacy of all contact information through access control where only administrators with appropriate rights can view or update recipient and contact information.

24) Must have the ability to customize the telephone number display (caller identification (ID) for voice messages and the email addresses for text messages.

25) Must have the ability to leave a message when a voice-delivered message reaches an answering machine or voicemail.

26) Support for system must be available and provided (as needed) 24 hours-a-day, 7 days-a-week, 365 days-a-year, including holidays, (24/7/365) via telephone and the Internet.

27) Must be capable of providing Keyword/zip code opt-in via text message.

28) Situational Awareness/Deconfliction: Must have the ability to display information about messages being issued around the state in a dashboard like format.

29) Data Interoperability: When data is collected for opt in notifications, it must be available to all administrators within the state. (Subject to administrative view/access restrictions).

2023-1.v3.04082026 RFP – Agency Solicitation Specifications Page 8 of 19 Revised 4/8/2026

30) Data Incorporation: If the selected Offeror currently serves other clients within the state who will be migrated to this system, all system branding, opt in data, and user accounts/groups must be transferrable to the new system by the offeror.

31) It is required that the system to be implemented have the ability to ingest previously collected opt-in data regardless of other system.

32) System must have tiered administration to include state, county, and city levels.

Administrators shall be able to view system activity of all administrators below their level.

The highest level of administration must be the state level administrators, followed by local level administrators. There must be no limit on the number of administrators.

33) The system must allow for the option to input “special needs” and “vulnerable population” information by subscribers. This should include, but is not limited to, allowing the citizen to identify their need (i.e. mobility impaired, blind, oxygen dependent, etc.), provide guardian contact information, and contact information for any servicing agencies. The system must automatically request, on an annual basis, that the registered citizen verify and update the provided information. The system should be automatically searchable for those who have provided such information within a specific information.

34) System must support the ability to search for a geographic location using a contact name, address, street segments, zip code, and latitude/longitude. System must allow for a search of the database using any of the fields contained in the database.

35) Use of the system must not be governed by number of minutes, messages, increments, or credits.

36) The system must allow message originators to enable a timeout option for notifications, at which time notification attempts will cease, even if a user has not been successfully contacted. For weather notifications, this timeout window should default to the expiration of the product issued by the National Weather Service.

37) System must be Americans with Disabilities Act (ADA) compliant to include TDD/TTY capability.

38) The data must be exportable from the system at any time and provided to the State of Rhode

Island for distribution to jurisdictions upon termination of the Contract. The system’s recipient data, including opt-in or jurisdiction supplied, remains the property of the jurisdiction and/or State of Rhode Island. Data must only be used by the offeror for the sole purpose of initiating notifications through the system and may not be used for marketing purposes. The data may not be sold or rented to any third party.

Special Enhancement Activities as Needed

In addition to Tasks listed above in Section B: Scope of Work and Requirements, should additional funding become available, the State reserves the option to conduct additional tasks to support the overall scope of this project. It is critical that the state have the flexibility to bring on additional technical assistance and expertise in a timely manner in order to perform activities which require similar expertise and work functions as those in Section B: Scope of

Work and Requirements, above. The decision to utilize services under an additional Task

2023-1.v3.04082026 RFP – Agency Solicitation Specifications Page 9 of 19 Revised 4/8/2026 will be solely at the State’s request and will be for specific enhancement activities not already included above. These optional activities will be defined and agreed to in writing, by both the State and the vendor, before any enhancement work begins. There is no commitment on the part of the State to utilize any or all special projects/enhancement activities. All bidders must bid on this Task using the hourly rates established in Appendix C- Cost

Proposal Template, and eventual award. The Task should be bid on a fully loaded Time and

Materials or Firm Fixed Price basis, in accordance with the specifics of the contract year in which the services are provided, for all personnel and subcontractors to be utilized in completing the optional task(s). This work must support but not duplicate the work described in the technical proposal’s scope of work. This work cannot exceed 20% of the initial award’s Total Contract Value. Should new funding become available the Purchasing Agent would need to authorize payments in excess of 20% of the contract for special enhancements. The awarded vendor shall not perform any special enhancement activities without receipt of a formal change order issued by the Division of Purchases.

SECTION C: PROPOSAL MATERIALS

1. Technical Proposal

Narrative and format: Bidders must submit a technical proposal which addresses each of the following elements and is limited to 20 (twenty) pages (this excludes any appendices and as appropriate, resumes of key staff that will provide services covered by this request):

A. Staff Qualifications – Provide staff resumes/CV and describe qualifications and experience of key staff who will be involved in this project, including their experience in Alert & Warning Systems or Emergency Notifications. Please note:

All staff should be based domestically (US).

B. Capability, Capacity, and Qualifications of the Vendor - Please provide a detailed description of the Vendor’s experience implementing, deploying, and support Alert & Warning Systems or Emergency Notifications. List a minimum of three (3) relevant client references, to include client names, addresses, contact names with emails and phone numbers, dates of service and type(s) of service(s) provided.

For references of the Vendor, Subcontractor(s), and/or its Resources, The

Department reserves the right to contact none, any, or all of the specified references. The Department also reserves the right to include or not include reference information obtained from those references, in the evaluation criteria of this RFP.

The State requests that any vendor who intends to list a current Rhode Island State employee as a reference on a bid proposal, contact that State person to receive written permission, prior to listing that person on any bid proposal. If this pre-approval is not obtained and provided within the submittal of a vendor’s technical proposal, the State reserves the right to eliminate information received from that employee, as it pertains only to a Vendor reference

2023-1.v3.04082026 RFP – Agency Solicitation Specifications Page 10 of 19 Revised 4/8/2026

C. Work Plan - Please describe in detail the framework within which requested

Implementation & Support services will be performed. The following elements should be included:

Provide o Implementation Services Staffing o Effort hours assumed o Data Migration o IPAWS Integration level of effort o Governance and Reporting o Licensing Requirements

- State Side resource needs to meet deliverables listed in the Scope of Work M&O

Services o Post Go Live staffing plan o Monthly Services and Deliverables o Ongoing Licensing needs

IMPORTANT: Whether the vendor and any subcontractors are handling PII or PHI, all responding vendors must detail that it has robust database security by adhering to steps below:

1. The State requests your firm provide insights and information into all Artificial Intelligence (AI) in your proposed solution. If the functionality your firm is proposing contains any use of AI

(Generative, etc.), the State requests:

1. It be identified, and

2. It be optional during the initial implementation of your solution, including if it is Hosted or not Hosted on State Infrastructure, and

3. You identify current usage or plan to use, AI Agents, in development or otherwise.

2. Please describe in detail the cybersecurity risk mitigation controls that are implemented within scope of the proposed solution and applicable cybersecurity framework used: NIST CSF 2.0, NIST

800-53 low, moderate, or high control families, CIS Benchmarks, ISO 27001, PCI DSS, CSA, or

SCF.

3. Please complete the full Appendix F – ETSS Cybersecurity Questionnaire attached and include it with your submission, and additional applicable information per the above.

a. If you already have a current SOC 2 Type 2 report, current ISO 27001 certificate, or current FedRamp or GovRamp authorization:

i. You may complete the Questionnaire at a minimum to question 5 finishing the firm’s general information section, select ‘yes’ for having a third-party attestation. This will satisfy the Questionnaire requirement when accompanied by documented report artifact (e.g. SOC2 Type 2 report or ISO 27001 certification) to validate your selected response. The Questionnaire must always be submitted, regardless of the number of questions and replies within it.

b. Additional security documentation may be requested to validate questionnaire responses if attestation artifacts are not provided. Prior to contract award, the State may in its discretion require the Vendor to provide additional security documentation, including but

2023-1.v3.04082026 RFP – Agency Solicitation Specifications Page 11 of 19 Revised 4/8/2026 not limited to, vulnerability assessment reports and penetration test reports. The awarded

Vendor shall provide such additional security documentation upon request by the State during the term of the contract.

4. The above-referenced Appendix F – ETSS Cybersecurity Questionnaire will be evaluated as part of the Technical Proposal. During the RFP evaluation process, or anytime thereafter, the State reserves the right to request additional Artificial Intelligence (AI) and/or IT Security information be provided and approved, based on any subsequent request and eventual award for services.

Return your responses to Appendix F – ETSS Cybersecurity Questionnaire as an excel spreadsheet, as a separate document in your technical proposal. Additionally, if a vendor does not adhere to the above and/or alters the layout of the Appendix F - ETSS Cybersecurity

Questionnaire, the State reserves the right to reject their proposal.

5. Please see and review the attached Appendix D - Addendum B – IT Policies, and the attached

Appendix E – Vendor Checklist to RI GCOP IT Policies.

a. For all applicable items, vendors are to respond to the categories in the Appendix E –

Vendor Checklist to RI GCOP IT Policies.

b. For each row, indicate if your firm Agrees (A) or is Rejecting (R), by entering the value of 'A', or 'R' in column 'E' of that item’s row. If your firm enters an 'R' in any row, please use column ‘F’ to comment on the rejection.

c. If your firm enters an ‘A’ in any row, and that item is covered in an agreement that already exists with the State and/or is part of your terms and conditions, please use column ‘F’ to explain.

d. Return this Checklist as an excel spreadsheet, and if applicable, redlines to Appendix D -

Addendum B – IT Policies, in your reply, as separate documents in your technical proposal.

D. Approach/Methodology/Functionality – Define the methodology to be used for the Alert & Warning System implementation, please include implementation type

(Agile, waterfall, hybrid, etc.), implementation phases/schedule, plan for go live and training. Include how the system meets all General System and Specific System requirements.

E. Video Presentation - (required as part of each Technical Proposal submitted)

- All vendors must include a video presentation of the proposal with a current version of their solution that is being utilized by other clients, indicating version number, to allow you to verbally describe your plan. Please also note that vendors may not include or refer to any cost proposals in the video. Any reference to the cost proposal (i.e. the budget for the project) in the video will result in that organization’s immediate disqualification from consideration. The identified lead staff member in the Staffing Plan should present the technical proposal in the video. The vendor should present each component of the technical proposal. Any information the vendor would like to present during the Presentation must be included within the written technical proposal. The video should be no more than

15 minutes. The following listing of file extensions are supported in the software for uploading CSV, DOC, DOCX, DOT, DOTX, GIF, JFIF, JPEG, JPG, ODS, PAGES, PDF, PNG, PPS, PPT, PPTX, TXT, XLS, XLSX, and/or ZIP.

2023-1.v3.04082026 RFP – Agency Solicitation Specifications Page 12 of 19 Revised 4/8/2026

Video Presentation will have 5 Categories:

Category 1: UI & Crisis Workflow Efficiency (0–3 Points)

• Operational Focus: Speed, clarity, and ergonomics under extreme stress.

• Demonstration Task: Vendor must demonstrate launching an emergency alert from a cold start on both desktop and mobile web interfaces.

• Evaluator Scoring Criteria:

o 3 Pts: Emergency dashboard uses clear visual hierarchy (high-contrast/dark-mode compatible), requiring ≤ 3 clicks from login to final confirmation.

o 2 Pts: Functional dashboard, but navigation requires searching through sub-menus or navigating multi-tab interfaces under time pressure.

o 1 Pt: Cluttered interface, small touch targets, high risk of operator confusion or slow execution.

Category 2: Geo-Targeting & GIS Polygon Precision (0–3 Points)

• Operational Focus: Targeting accuracy, spatial boundary filtering, and minimal alert overshoot.

Demonstration Task: Live import of a custom Shapefile / ESRI GIS layer, drawing a complex polygon around a hazard zone, and demonstrating real-time population estimation within the zone.

o 3 Pts: Flawless GIS layer import, instant polygon drawing/editing with buffer tools, real-time device population calculation, and auto-filtering of out-of-boundary recipients.

o 2 Pts: Basic radius or bounding box options available; GIS import functions but requires manual coordinate cleaning or experiences rendering delay.

o 1 Pt: Map controls lag, polygon boundaries distort, or targeting relies strictly on rigid ZIP codes/jurisdictional lines rather than custom shapes.

Category 3: IPAWS, WEA 3.0 & EAS Dual-Launch Capability (0–3 Points)

• Operational Focus: Simultaneous public warning broadcast compliance (FEMA CAP protocol).

• Demonstration Task: Demonstrating a simultaneous message broadcast across WEA

(90 & 360 characters), EAS broadcast override, and local opt-in channels (SMS, voice, email, social media).

o 3 Pts: Seamless dual-launch execution. Clear character counter compliance for

WEA 90/360, built-in text-to-speech audio preview for EAS, and auto-routing to local opt-in lists without duplicate entries.

2023-1.v3.04082026 RFP – Agency Solicitation Specifications Page 13 of 19 Revised 4/8/2026 o 2 Pts: Channels must be configured and sent individually, or WEA character limit alerts do not auto-adjust.

o 1 Pt: System fails to integrate WEA/EAS into a unified pathway or lacks real-time validation against FEMA CAP standards.

Category 4: Administrative Safeguards & Approval Workflows (0–3 Points)

• Operational Focus: Preventing accidental live broadcasts while maintaining speed for authorized personnel.

• Demonstration Task: Demonstrating user permissions, multi-factor authorization, peer-approval queues for high-level alerts, and quick cancellation/update steps.

o 3 Pts: Unmistakable visual separation between "IPAWS Lab/Demo COG" and

"LIVE Production". Two-step confirmation (e.g., dual-authorization or biometric push) with full immutable audit logging.

o 2 Pts: Basic pop-up prompt ("Are you sure?"); administrative roles exist but approval workflows lack customizable escalation paths.

o 1 Pt: Weak visual distinction between test and live environments (high risk of accidental broadcast) or missing message update/cancellation workflows.

Category 5: Scenario Templates & Multilingual Capabilities (0–3 Points)

• Operational Focus: Rapid deployment during recurring threats and reaching non-

English speaking populations.

• Demonstration Task: Selecting a pre-scripted hazard template (e.g., Flash Flood, Evacuation, Active Threat) and demonstrating automated Spanish translation with side-by-side editing.

o 3 Pts: Robust library of pre-scripted, FEMA-compliant templates. Real-time automated dual-language translation (English/Spanish side-by-side) with manual override capabilities.

o 2 Pts: Templates exist but must be populated manually; translation requires copy-pasting from an external tool or lacks side-by-side preview.

o 1 Pt: No pre-built hazard templates or missing multi-language CAP character encoding.

2023-1.v3.04082026 RFP – Agency Solicitation Specifications Page 14 of 19 Revised 4/8/2026

3. Video Presentation Scoring Sheet

Vendor Name: Evaluator Name:

RFP Title: Statewide Alert & Warning Platform Date:

Evaluation Criteria Max

Score

Vendor

Score (0–3)

Evaluator Justification & Specific

Notes

1. UI & Crisis

Workflow Efficiency 3 Evaluate click-depth, visual clarity, and responsiveness under stress.

2. Geo-Targeting &

GIS Mapping

Evaluate ESRI shapefile import, polygon drawing, and population estimation.

3. IPAWS / WEA /

EAS Dual Launch

Evaluate unified CAP dissemination across WEA, EAS, and local channels.

4. Safeguards &

Approval Controls

Evaluate test/live separation, permission locks, and update/cancel speed.

5. Templates &

Multilingual

Handling

Evaluate pre-scripted hazard templates and multi-language support.

TOTAL DEMO

SCORE

15 ____ / 15 Summary Evaluation:

2023-1.v3.04082026 RFP – Agency Solicitation Specifications Page 15 of 19 Revised 4/8/2026

2. Vendor Presentation/Demonstration

**This is a separate item from the video presentation that is asked for in the technical proposal.

Category Definitions & Point Allocations (15 Points Total)

Category A: System Demonstration & Core Capabilities – 5 Points

• Maximum Score: 5.0 Points

• Definition: Evaluates the vendor’s live demonstration of system functionality, interface intuitive design, platform reliability, speed, and real-time operational workflow.

Evaluators assess the live execution of scenario-based walkthroughs (e.g., sending high-priority IPAWS/WEA alerts, geographic targeting/polygons, multi-language translation, and system redundancy).

• Key Focus Areas:

o System speed, interface ease-of-use, and administrative dashboard navigation.

o Live demonstration of geo-targeting accuracy, IPAWS/EAS integration, and mass communication channels (SMS, voice, email, social, municipal opt-in).

o System fault tolerance, security protocols, and operational resiliency during crisis scenarios.

Category B: Implementation Strategy, Technical Support & Transition – 5 Points

• Maximum Score: 5.0 Points

• Definition: Assesses the clarity, feasibility, and technical depth of the vendor’s execution plan for system deployment, migration, and long-term operational support. Evaluators review the vendor's roadmap for system integration, municipal opt-in onboarding, administrative user role configuration, and continuous training.

• Key Focus Areas:

o Realistic timelines for system setup, database migration, and testing phases.

o Comprehensive initial training and ongoing 24/7 technical/emergency support structure.

o Operational readiness for emergency management operations and public safety interagency coordination.

Category C: Presentation Delivery & Q&A Responsiveness – 5 Points

• Maximum Score: 5.0 Points

• Definition: Measures the overall quality, professionalism, and clarity of the oral presentation, as well as the vendor team's subject matter expertise during the direct

Question & Answer (Q&A) period.

• Key Focus Areas:

o Direct engagement by key personnel (e.g., project managers, lead technical engineers) rather than solely sales representatives.

o Direct, complete, and articulate answers to the Evaluation Committee's operational, technical, and compliance questions.

2023-1.v3.04082026 RFP – Agency Solicitation Specifications Page 16 of 19 Revised 4/8/2026 o Alignment with state requirements and overall professionalism.

3. Cost Proposal

Detailed Budget and Budget Narrative:

1. Selected Cost Proposal Structure

To align with the deployment of a modern Software as a Service (SaaS) or Commercial-Off-The-

Shelf (COTS) platform, the recommended structure for this cost proposal is a Hybrid Fixed-

Subscription and Deliverable-Based Fee Structure.

This structure ensures budget predictability for the State while holding the Offeror accountable for initial deployment milestones. It is broken down as follows:

• Fixed-Fee Implementation & Data Ingestion (Deliverable-Based): One-time costs mapped directly to specific setup milestones (e.g., data ingestion of legacy data, configuration of Rhode Island branding, portal development, and multi-tiered administrator setup).

• Annual SaaS Subscription (Fixed Fee / Enterprise Flat Rate): An all-inclusive annual recurring fee. Per Specific System Requirement #35, usage must not be governed by minutes, messages, increments, or credits. Therefore, a flat enterprise subscription tier based on the state’s total population or unlimited usage is required to eliminate unpredictable overage costs.

• Optional Features Pricing (Fixed Unit Pricing): Separate, non-bundled pricing for ancillary services or future expansions so they do not impact the core baseline evaluation.

2. Cost Proposal Narrative & SOW Compliance Mapping

Offerors must complete the attached Cost Proposal Template in strict accordance with the pricing boundaries established by the General and Specific System Requirements:

General System Requirements Pricing Impact

• User Functionality & Admin Views (Gen Req 1 & 2): Core platform configurations, including custom branding ($$ cost), non-secure landing pages ($$ cost), system-wide directories ($$cost), and multi-level administrative reporting hierarchies, must be fully absorbed into the baseline Annual SaaS Subscription Fee.

• Secure Notifications & Message Delivery (Gen Req 3): Per Gen Req 3.5, vendors must explicitly disclose if any delivery channels incur transactional costs. However, to maintain alignment with Specific Req #33 (No Minute/Credit limits), any per-notification costs must be built into an unlimited cap within the baseline enterprise rate.

2023-1.v3.04082026 RFP – Agency Solicitation Specifications Page 17 of 19 Revised 4/8/2026

IPAWS capabilities ($$) and multi-language engines ($$) must be native to the platform at no additional cost.

• Security, Resiliency, & Updates (Gen Req 4, 5, & 6): Costs associated with

FedRAMP/SOC 3 hosting, 99.99% uptime compliance, First Responder Grade hardening, automated failovers, and routine major/minor software patches must be bundled into the subscription. No separate maintenance or maintenance-release fees are permitted.

• Ingestion of Current Data (Gen Req 9): Any costs related to mapping, scrubbing, and importing legacy State of Rhode Island opt-in data, established group lists, or pre-existing templates must be listed as a one-time deliverable-based fee.

Specific System Requirements Pricing Impact

• Unlimited Usage (Spec Req #35): The financial model cannot utilize metered billing

(per-message, per-minute, or per-SMS segment fees).

• Short Code Whitelisting (Spec Req #6): Costs for maintaining established, carrier-white listed SMPP short codes (Verizon, T-Mobile, AT&T) must be covered entirely within the annual subscription.

• Data Ownership & Off boarding (Spec Req #38): All recipient and opt-in data remains the property of the State. Offerors must confirm that data extraction and hand-off to the

State upon contract termination will be executed at zero additional cost.

• Support (Spec Req #24): 24/7/365 internet and telephone technical support must be inclusive; no tiered support or premium helpdesk upcharges are allowed.

3. Cost Proposal Template

Vendors must populate cells in the Appendix C – Cost Proposal Template below. Vendors are to submit their cost proposals in excel format. Do not alter the structure of these tables to ensure a seamless evaluation process.

Only the total value of the 3 base contract years (Cost proposal template tab ‘3-year base’ cell

E7) will be used in the factoring of cost points.

Table A: One-Time Implementation & Deployment Costs (Deliverable-Based & Fixed Fee)

Table B: Recurring Annual SaaS Subscription Fees (Fixed Fee)

Table C: Optional Features & Future Value-Add Capabilities

Table D: Cost Proposal Summary

Offer or Affirmation Statement: > By submitting this cost proposal, the Offeror affirms that the pricing provided is comprehensive and compliant with all SOW terms, including the mandate for unlimited usage (no minute/credit constraints) and free data extraction upon contract termination.

2023-1.v3.04082026 RFP – Agency Solicitation Specifications Page 18 of 19 Revised 4/8/2026

4. Supplemental Bidder Attestation Form

See Appendix A on the “Overview” tab in Ocean State Procures™ for information. Vendors are required to complete, sign and submit this form with their overall proposal.

5. ISBE Proposal

See Appendix B on the “Overview” tab in Ocean State Procures™ for information and the MBE, WBE and/or Disability Business Enterprise Participation Plan form(s). Vendors are required to complete, sign and submit these forms with their overall proposal. Please complete separate forms for each MBE, WBE, and/or Disability Business Enterprise subcontractor to be utilized on the solicitation.

SECTION D: EVALUATION AND SELECTION - SOLICITATION SPECIFIC

1) Technical proposals must receive a minimum of 44 (80%) out of a maximum of 55 points to advance to the Vendor Presentation phase. Technical proposals scoring less than 44 points shall not advance to the Vendor Presentation phase or have the accompanying cost or ISBE participation proposals opened or evaluated; such proposals shall not receive further consideration.

2) Vendor Presentations must receive a minimum of 12 (80%) out of a maximum of

15 points to advance to the cost evaluation phase. Vendor Presentations scoring less than 12 points shall not have the accompanying cost or ISBE participation proposals opened or evaluated; such proposals shall not receive further consideration.

3) Cost Evaluation Phase – vendors moving to the Cost Evaluation Phase will be evaluated and assigned up to a maximum of 30 points bringing the total potential evaluation score to 100 points. As total possible evaluation points are determined, vendor ISBE proposals shall be evaluated and assigned up to 6 bonus points for

ISBE participation.

2023-1.v3.04082026 RFP – Agency Solicitation Specifications Page 19 of 19 Revised 4/8/2026

Proposals shall be reviewed and scored based upon the following criteria:

Criteria Possible Points

Staff Qualifications 5 Points

Capability, Capacity, and Qualifications of the Vendor 10 Points

Work Plan – Implementation & M&O Support Services

Delivery

15 Points

Approach/Methodology/Functionality 10 Points

Video Presentation 15 Points

Total Possible Technical Points 55 Points

Vendor Presentation 15 Points

Total Possible Vendor Presentation Points 15 Points

Cost Proposal 30 Points

Total Possible Evaluation Points 100 Points

ISBE Participation 6 Bonus Points

Total Possible Points 106 Points

Additional evaluation criteria can be found at:

• For those with an OSP account, see the “Requirements” tab of this solicitation in OSP for additional information on the evaluation and selection process in the “RFP Standard

Specification” section.

• For those without an OSP account, public access to the full bid can be found at https://ridop.ri.gov/vendors/bidding-opportunities. Search for this solicitation, open the record, click on the “Print/Download Solicitation Summary” button in the upper right corner for all the solicitation requirements and supporting documents are found at the bottom of the page in the “Solicitation Attachments” section.

https://ridop.ri.gov/vendors/bidding-opportunities

3. Cost Proposal

SECTION D: EVALUATION AND SELECTION - SOLICITATION SPECIFIC

≤ 3