7-Attachment F Requirements Matrix.xlsx
XLSX spreadsheet 29 KB Posted
- Attached to
- Mass Communication Solution State and local contract opportunity
- Solicitation number
- 542995
- Issued by
- Wayne County, Detroit City, Michigan
About this file
This is an Attachment F Requirements Matrix for a Mass Notification and Emergency Communications Solution Request for Proposal (RFP #542995) issued by the City of Detroit Office of Contracting and Procurement on behalf of the Department of Innovation and Technology in Michigan. The RFP seeks a comprehensive mass notification and emergency communications solution capable of supporting reliable, scalable, and secure communications for both public safety and internal operational use. The requirements matrix organizes 122 total functional requirements and questions across five functional areas: General Technical (37 requirements), Reporting (12 requirements), Security (40 requirements), Cloud Checklist Questionnaire (26 requirements), and Backups/Business Continuity and Recovery Questionnaire (7 requirements). The matrix provides a standardized evaluation tool where vendors respond with "C" (Requirement Met and Proposed), "A" (Intent of Requirement Met with Alternative), or "N" (Requirement Not Met) for each specification.
The General Technical requirements encompass system capabilities including secure internet-based access across multiple devices, multi-channel notification distribution (email, SMS, social media, web portals), geo-fencing and GIS mapping functionality, multilingual support (English, Spanish, Arabic), contact database management with import/export capabilities, and message delivery tracking. Security requirements address data protection, encryption (in transit and at rest), role-based access controls at multiple levels, Active Directory and SAML authentication integration, multi-factor authentication, audit trail capabilities, and compliance certifications including SOC 2 Type 2 reports. Business continuity requirements mandate geographically diverse data centers meeting Tier III standards, backup capabilities without service disruption, defined Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO), and crisis management plans subject to City approval. All non-public City of Detroit data, including backups and disaster recovery materials, must remain stored within the United States.
View the file
Other files for this state and local contract opportunity
| File | Type | Posted |
|---|---|---|
| 1-Equalization Credit Statement.pdf | ||
| 5-Attachment E- City of Detroit Technology Contract.docx | DOCX document | |
| 2-Attachment A - Respondent Questionnaire.docx | DOCX document | |
| 8-EUNA RFP 542995.docx | DOCX document | |
| 6-Attachment C Pricing.xlsx | XLSX spreadsheet | |
| 3-Attachment B - Respondent Introduction and Overview.docx | DOCX document | |
| 4-Attachment D -Required Documents Packet.pdf |
On GovTribe
Work with this file on GovTribe
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
Table of Contents
| Mass Notification and Emergency Communications Solution RFP Table of Contents | ||
| Tab No. | Functional Area | Number of Requirements / Questions |
| 1 | General Technical | 37 |
| 2 | Reporting | 12 |
| 3 | Security | 40 |
| 4 | Cloud Checklist Questionnaire | 26 |
| 5 | Backups / Business Continuity and Recovery Questionnaire | 7 |
| Total Requirements + Questions: | 122 |
General Technical
| ATTACHMENT F - REQUIREMENTS MATRIX | ||||
| Mass Notification and Emergency Communications Solution RFP #542995 | Enter vendor name here | |||
| Available Responses | ||||
| C | Requirement Met and Proposed (Standard features available in the product) | 0 | ||
| A | Intent of Requirement Met and Proposed with Alternative | 0 | ||
| N | Requirement Not Met with Proposal | 0 |
. TOTAL 0
| Req # | Function | General Technical Requirement | Vendor Response | |
| (C, A, N) | Modules Required to Fulfill Requirements | Comments | ||
| GT1 | General/Technical | The system has the ability to allow City users access via a secure internet connection from any computer, tablet, or smart phone in order to send out alerts and notifications. | ||
| GT2 | General/Technical | The system has the ability to publish event-based notifications via email and SMS | ||
| GT3 | General/Technical | The system has the ability to publish event-based notifications directly to Facebook and Twitter | ||
| GT4 | General/Technical | The system has the ability to publish event-based notifications directly to event web pages | ||
| GT5 | General/Technical | The system has the ability to publish event-based notifications directly to public/member portal | ||
| GT6 | General/Technical | The system supports automatic opt-in expirations | ||
| GT7 | General/Technical | The system supports zip code opt-in functionality for members of the public | ||
| GT8 | General/Technical | The system supports Google Public Alerts integration | ||
| GT9 | General/Technical | The system supports voice, SMS and email messaging | ||
| GT10 | General/Technical | The system supports messaging templates | ||
| GT11 | General/Technical | The system has the ability to allow 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. | ||
| GT12 | General/Technical | The system has the ability to manage data from all sources to prevent duplication. | ||
| GT13 | General/Technical | If there is a process for periodically removing inactive phone numbers from the database, please indicate so and describe the process in the Comments field. | ||
| GT14 | General/Technical | The system has the ability to create scenarios and store prepared messages to be initiated in the future. | ||
| GT15 | General/Technical | The system has the ability to recognize human voice vs. a voicemail or answering machine and wait until the outgoing message from an answering machine or voicemail has ended prior to leaving the emergency notification message. | ||
| GT16 | General/Technical | The system has the ability to track, and search, message status (i.e. message successfully delivered, viewed). | ||
| GT17 | General/Technical | The system has the ability to spell check on any field with the ability for a user to accept or ignore suggestion. | ||
| GT18 | General/Technical | The system supports the ability to terminate any message notification in progress. Please use the Comments field to describe the ability to cancel or terminate the process in the middle of sending out an alert or mass notification message. | ||
| GT19 | General/Technical | The system has the ability to support message expiration. | ||
| GT20 | General/Technical | The system has the ability to allow the City to create response-needed messages that include questions and prompts for the recipient to answer. | ||
| GT21 | General/Technical | Proposal 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. | ||
| GT22 | General/Technical | The system supports voice, text and email capability with geo-fencing. | ||
| GT23 | General/Technical | The system supports the use of a GIS mapping interface that allows the user to designate an area to be notified with the following functions at minimum: | ||
| GT23 a | General/Technical | Circle with a given radius | ||
| GT23 b | General/Technical | Predetermined geographic areas (zip code, evacuation zone, imported layer, etc.) | ||
| GT23 c | General/Technical | User-defined polygon | ||
| GT23 d | General/Technical | Buffer from selected feature | ||
| GT23 e | General/Technical | Multi‐ringed buffer from site (1, 2, 3 mile radius, etc.) | ||
| GT24 | General/Technical | Multilingual capability (minimum: English, Spanish, Arabic) | ||
| GT25 | General/Technical | Opt-in / Opt-out feature (after residents enter an address, a choice of alerts will appear for them to select) | ||
| GT26 | General/Technical | The system has the ability to provide a custom registration widget | ||
| GT27 | General/Technical | The system has the ability to support Google public alerts | ||
| GT28 | General/Technical | The system has the ability to support zip code and keyword opt-in | ||
| GT29 | General/Technical | The system has the ability to support public and private group messages | ||
| GT30 | General/Technical | The system has an import tool for contacts & databases | ||
| GT31 | General/Technical | The system has the ability to support National Weather Service re-broadcast | ||
| GT32 | General/Technical | The system has the ability to support image, document, & PDF attachments | ||
| GT33 | General/Technical | The system has the ability to support IPAWS publications | ||
| GT34 | General/Technical | The contact information database has data import and export capabilities using industry standard formats and API’s (e.g. Excel, comma delimited, MS SQL, Active Directory, etc.) and the ability to schedule these tasks. | ||
| GT35 | General/Technical | The system has the ability to support modern web browsers. Please use the Comments field to indicate which browsers are supported. | ||
| GT36 | General/Technical | The system has the ability to recognize the device that is being used to view the software to make the necessary window adjustments (screen optimization). | ||
| GT37 | General/Technical | The vendor must proactively notify the System Administrator regarding which releases of third-party software (JAVA virtual machine, Internet Explorer, Mozilla, Safari, etc.) are known to create problems with the current version of the vendor software. |
Reporting
| ATTACHMENT F - REQUIREMENTS MATRIX | ||||
| Mass Notification and Emergency Communications Solution RFP #542995 | Enter vendor name here | |||
| Available Responses | ||||
| C | Requirement Met and Proposed (Standard features available in the product) | 0 | ||
| A | Intent of Requirement Met and Proposed with Alternative | 0 | ||
| N | Requirement Not Met with Proposal | 0 |
TOTAL 0
| Req # | Function | Reporting Requirements | Vendor Response | |
| (C, A, N) | Modules Required to Fulfill Requirements | Comments | ||
| R1 | Reporting | The system has the ability to support notification delivery statistics and analytics | ||
| R2 | Reporting | The system has the ability to provide an integrated report writer. | ||
| R3 | Reporting | The system has the ability to allow a user to easily determine the number of active recipients who have signed up to receive public notifications. | ||
| R4 | Reporting | The system has the ability to provide a library of standard reports (i.e. "canned" reports). | ||
| R5 | Reporting | The system has the ability to save a report as a new template after a user copies and modifies an existing report | ||
| R6 | Reporting | The system has the ability to allow a user to modify existing reports, with appropriate security permissions. | ||
| R7 | Reporting | The system has the ability to allow one or more users to query information and run reports at the same time. | ||
| R8 | Reporting | The system has the ability to allow reports to be generated that are searchable. | ||
| R9 | Reporting | The system supports real-time tracking and reporting. | ||
| R10 | Reporting | Please use the Comments field to describe how the solution defines a successfully delivered message for each notification method available. | ||
| R11 | Reporting | Proposer should define “unsuccessful delivery” and the circumstances or causes for a message delivery to be unsuccessful whether it is text, voice, and/or email. | ||
| R12 | Reporting | The system has the ability to identify contacts and contact phone numbers and email addresses that fail to receive text, voice, or email messages when a notification is sent. |
Security
| ATTACHMENT F - REQUIREMENTS MATRIX | ||||
| Mass Notification and Emergency Communications Solution RFP # 542995 | Enter vendor name here | |||
| Available Responses | ||||
| C | Requirement Met and Proposed (Standard features available in the product) | 0 | ||
| A | Intent of Requirement Met and Proposed with Alternative | 0 | ||
| N | Requirement Not Met with Proposal | 0 |
TOTAL 0
| Req # | Function | Security Requirement | Vendor Response | |
| (C, A, N) | Modules Required to Fulfill Requirements | Comments | ||
| S1 | Data Security | Proposal must include detailed information related to the data security features of the proposed system. | ||
| S2 | Data Breach Protocols | Proposal must include detailed information about the vendor's response procedures in the event of a data breach. | ||
| S3 | Data backup | Proposal must include detailed information about the vendor's data backup procedures, including confirmation that backup data can be provided to the City on a monthly basis. | ||
| S4 | Security | Proposal must describe how the system will prevent access by a “bot” or other inappropriate access. | ||
| S5 | Data Privacy | Proposal must describe how the vendor ensures that contact data is protected from reselling and other exploitations. | ||
| S6 | SSO | The system has the ability to utilize the City's Active Directory user validation to achieve single-sign-on, regardless of deployment method. | ||
| S7 | AD integration | The system has the ability to inherit groups from Active Directory for application authentication. | ||
| S8 | Multi Factor Authentication | The system has the ability to support Multi Factor Authentication (MFA) | ||
| S9 | SAML | The system has the ability to utilize the City's SAML Authentication (Azure Active Directory) for user validation to achieve single-sign-on, regardless of deployment method. | ||
| S10 | SAML | The system has the ability to map SAML groups or App roles from Azure Active Directory for application permissions . | ||
| S11 | Encryption | The system has the ability to encrypt data stored in the database. | ||
| S12 | Encryption | The system has the ability to encrypt data stored in the application. | ||
| S13 | Encryption | The system has the ability to encrypt data in transit. | ||
| S14 | Encryption | Please provide information as to what level of encryption/encryption methods are used in transit and at rest. | ||
| S15 | Role based security | The system has the ability to provide read, write, update, and delete access using role based security. | ||
| S16 | Role based security | The system has the ability to provide security at the following levels: | ||
| S17 | Role based security | Department or Agency; | ||
| S18 | Role based security | Division; | ||
| S19 | Role based security | Role or group; | ||
| S20 | Role based security | User ID; | ||
| S21 | Role based security | Screen; | ||
| S22 | Role based security | Menu; | ||
| S23 | Role based security | Report; | ||
| S24 | Role based security | Field; | ||
| S25 | Role based security | The system allows for departmental administrative self-service (e.g. ability to make changes to roles and workflows) with audit trail capability. | ||
| S26 | Role based security | The system has the ability to update all user profiles automatically (user discretion) when a change in their role (s) is/are made. | ||
| S27 | Role based security | The system has the ability to allow a City system administrator to add and change permissions for system access. | ||
| S28 | User Groups | The system has the ability to establish, deactivate, and archive user groups. | ||
| S29 | User Groups | The system has the ability to delete user groups that do not have historical data, with an audit trail. | ||
| S30 | User Groups | The system allows for departmental administrative self-service (e.g. ability to make changes to roles and workflows) with audit trail capability. | ||
| S31 | Compliance | The system meets compliance rules / regulations in order to ensure the sensitive digital assets are guarded against loss, theft and misuse | ||
| S32 | Compliance | The system is compliant with applicable compliance regulations. | ||
| S33 | Security Certifications | Please list any industry standard security certifications the solution / vendor has. (Ex: ISO 27001). |
Please note annual SOC 2 type reports will be required via the City’s contract.
| S34 | Audit Capabilities | The system has the ability to track and audit changes throughout the system that creates a log of all records maintained and includes: |
| S34 a | Audit Capabilities | Date; |
| S34 b | Audit Capabilities | Time; |
| S34 c | Audit Capabilities | User; |
| S34 d | Audit Capabilities | Information prior to change; |
| S34 e | Audit Capabilities | Changed information |
| S35 | Audit Capabilities | The system has the ability to allow the audit trail to have a date/time stamp to the nearest second. |
| S36 | Audit Capabilities | The system has the ability to allow a City system administrator to configure the duration that time audit logs are retained (e.g. 90 days). Proposer to describe how this feature works. |
| S37 | Audit Capabilities | The system has the ability to provide customizable audit reports. |
| S38 | Access Time Out | The system has the ability to log users off the system after an administrator-defined period of inactivity, based on user-defined roles. |
| S39 | Access Time Out | The system has the ability to allow a system administrator to log out users. |
| S40 | Security | The system has the ability to allow authorized users to have access to a log of security activity to determine users that have signed on and off the system, as well as unsuccessful attempts to sign on to the system. |
Cloud Checklist
ATTACHMENT F - REQUIREMENTS MATRIX
Mass Notification and Emergency Communications Solution RFP # 542995
| Cloud Service Provider Security Checklist | ||
| Please provide an answer or statement to all issues listed | ||
| Enter vendor name here | ||
| Prompt # | Topic | Vendor Response |
| 1 | Describe who is responsible uptime, maintenance, patching and administration of the server. | |
| 2 | The provider must show diagram (and possible past examples) of their governance and notification processes for their services. | |
| 3 | Describe how the provider will guarantee legal and regulatory compliance with government and sectorial (industry specific) laws and regulations. | |
| 4 | Does the solution follow one of the following sets of security and privacy control best practices? Indicate which. | |
| 4a | NIST Series | |
| 4b | ISO/IEC Series | |
| 4c | COBIT | |
| 4d | ITIL | |
| 5 | The vendor will provide to the City, at no additional cost, the most recent SOC 2 Type 2 report from its cloud hosting provider covering the environments used by the City. | |
| 6 | Describe process for Account Management | |
| 7 | Define who is responsible for security monitoring. If the City will be responsible for securing the environment, describe how the City will obtain logs to ingest into its SIEM. | |
| 8 | Describe how a data inventory of City of Detroit Data Assets will be kept. | |
| 9 | Will subcontractors be used? If yes, will all security controls be inherited by subcontractors? | |
| 10 | Describe Public Key Infrastructure | |
| 11 | Process for separation of data belonging to different consumers in a multi‐tenant environment. | |
| 12 | Does the solution use a private, shared or hybrid cloud? | |
| 13 | Process used to separation of network traffic in a shared multi‐tenant provider environment | |
| 14 | Statement guaranteeing adherence to all privacy laws governing the physical areas of data storage. | |
| 15 | Willing to participate in a Risk Assessment and Privacy Impact Assessment covering the storage of PII. | |
| 16 | Network traffic must be screened and firewall protected network must have intrusion detection & prevention in place. | |
| 17 | Network must have detailed logging and documented alerting capabilities. | |
| 18 | Dedicate VLANs with dedicated virtual firewall. | |
| 19 | Describe how the City of Detroit network access separated from provider network access. | |
| 20 | Are the City of Detroit VMs are on a dedicated hypervisor? | |
| 21 | Will provider's servers only communicate with the City of Detroit logical disk units? | |
| 22 | Will online storage and backup media be scrubbed when retired or replaced? | |
| 23 | Identify system environments that will be available to the City (e.g. production, development, test) | |
| 24 | Identify shared components of the system (e.g., network segments, backup tapes, etc.) | |
| 25 | Identify Data storage and transfer limits | |
| 26 | Identify normal and peak bandwidth requirements |
Backup-Recovery
ATTACHMENT F - REQUIREMENTS MATRIX
Mass Notification and Emergency Communications Solution RFP # 542995
| Backups / Business Continuity and Recovery RFP Questions | ||
| Please provide an answer or statement to all issues listed | ||
| Enter vendor name here | ||
| Prompt # | Topic | Vendor Response |
| 1 | Proposers shall have a backup and recovery capability for the system and application, including incremental and full backup capabilities. Additionally, system backups shall be accomplished without taking the application out of service and without degradation of performance or disruption to City operations. | |
| 2 | Proposers shall be able to provide the service from at least two geographically diverse data centers that do not share common threats (e.g., the data centers cannot be in the same earthquake zone, likely hurricane path, same flood zone, etc.). The data centers shall at a minimum meet Tier III standards for redundancy of power, telecommunications, HVAC, security, fire suppression and building integrity. |
• Where are the data center and storage facilities?
• The Proposer shall not store or transfer non-public City of Detroit data outside of the United States without the written consent of the City. This includes backup data and Disaster Recovery locations.
| 3 | Proposers shall specify whether, in the event of a technology or other failure at the primary processing center, the alternate system will meet the following tiers, for which the City’s use should be identical regardless of which location is processing the City’s work: |
| 3a | • High Availability – Continuous operation without interruption or degradation in service |
| 3b | • Standard availability – Available for City use within 48 hours with no degradation in service |
| 3c | • Non-Critical Availability – Available for City use within 96 hours with no degradation in service |
| 4 | Proposers shall implement crisis management, business continuity and disaster recovery plans, subject to City approval, which the City will not reasonably withhold. These plans shall outline how the Proposer will support the City’s recovery at the alternate site, including backup staff required to implement the plan in an emergency if the Proposer’s primary staff is unavailable. Such plans may also include annual testing in coordination with the City. |
| 5 | Proposers shall specify the System’s proven, maximum tolerable length of time that a computer, system, network, or application can be down after a failure or disaster occurs or its recovery time objective (“RTO”) and the amount of data at risk, as determined by the amount of time between data protection events, and as it reflects the amount of data that potentially could be lost during a disaster recovery point objective, (“RPO”) in case the primary site becomes unavailable. The selection of the RTO and RPO will be agreed upon objectives between the Proposer and the City. |
| 6 | Proposers shall specify whether the System will meet the following availability tiers, which tier, and shall specifically describe how the System meets such tier: |
| 6a | • High Availability, 99.982% |
RTO Characteristics and RPO: Intra-day, Typically involves data replication, to a hot-site for each transaction, or at short intervals, like 15 minutes.
6b • Standard Availability, 99.741% RTO Characteristics and RPO: 24 to 48 hours Nightly imaging to cloud / data center. System reestablished at time of disaster from cloud / data center. May lose up to one day of data.
6c • Non-Critical Availability, 99.671% RTO Characteristics and RPO: 48 to 56 hours, Nightly imaging to cloud / data center. System reestablished at time of disaster from cloud / data center. May lose up to one day of data.
7 Identify shared components of the system (e.g., network segments, backup tapes, etc.)
File details come from the government source that posted it. Updated .