The file's text, extracted by GovTribe without its formatting.
ATTACHMENT C
FUNCTIONAL REQUIREMENTS
The terms “System”, “Software”, and “Application” is used throughout this exhibit. These terms are meant to represent the Consultant’s proposed software and infrastructure, as applicable.
1. Consultant must respond to each individual requirement by entering an ‘X’ in one of the columns provided. Select the appropriate response using the following guidelines below.
| Standard |
| The requirement is satisfied by the System proposed. |
· If the System requires specialized configuration, Consultant must enter required configuration in the “Describe” section provided.
· If the requirement is satisfied by third-party software, please indicate the third-party product proposed.
| Customization |
| A modification to the System is required to satisfy the requirement. |
· Consultant must provide an explanation of the work required to perform the modification in the “Describe” section provided.
| Not Available |
| The System will not satisfy the requirement. |
2. Consultant is strongly encouraged to provide a brief explanation of how the requirement will be satisfied.
| Describe |
| · If requirement is met by more than one module, Consultant must list which module or modules are required to satisfy the requirement. |
· Consultant may also include screen shots, diagrams, samples, and inventories for any requirement listed.
· If unable to meet the requirement, Consultant must offer a brief explanation or propose an alternative way to meet the requirement.
Table of Contents
| C. |
| Polling Place Management |
| Ref. No |
| Category |
| Requirement |
| Standard |
| Customization |
| Not Available |
| Describe |
A.
Admin & Operations
The System must provide an email template builder supporting subject and body creation, including rich‑text formatting capabilities and reusable templates to standardize communications.
| 2. |
| Admin & Operations |
| The System must allow authorized staff to create or save new communications templates without vendor assistance. |
| 3. |
| Admin & Operations |
| The System must support dynamic placeholders (e.g., {FirstName}, {PollingPlace}) in communications templates including emails. |
| 4. |
| Admin & Operations |
| The System should allow authorized staff to edit existing communications templates with version tracking. |
| 5. |
| Admin & Operations |
| The System should support communications template lifecycle controls, including archive, hide, and delete. |
| 6. |
| Admin & Operations |
| The System must provide an audience builder allowing staff to select recipients by stored attributes such as role, precinct, assignment status, training status, and text‑based filters. |
| 7. |
| Admin & Operations |
| The System could allow staff to generate recipient lists from System‑produced reports or uploaded files, including lists containing dynamic fields such as employee IDs. |
| 8. |
| Admin & Operations |
| The System should allow staff to send messages to a pasted or uploaded list of email addresses for one‑off communications. |
| 9. |
| Admin & Operations |
| The System must allow staff to schedule messages by date and time. |
The System must allow authorized staff to configure automated communications for election workers based on time‑ or status‑based triggers (e.g., missed training).
| 11. |
| Admin & Operations |
| The System must support sending SMS messages to designated recipients. |
| 12. |
| Admin & Operations |
| The System could support receiving SMS messages or responses and capturing them within the System. |
| 13. |
| Admin & Operations |
| The System must allow staff to create and track service tickets for real‑time issue or emergency resolution. |
| 14. |
| Admin & Operations |
| The System should allow workers to submit low‑severity service or supply requests through a self‑service interface. |
| 15. |
| Admin & Operations |
| The System must allow staff to categorize tickets by issue type and tag them by precinct or site. |
| 16. |
| Admin & Operations |
| The System must allow staff to assign or reassign tickets, capture resolution notes, and update ticket status. |
| 17. |
| Admin & Operations |
| The System must provide a dashboard of open tickets with filters such as category, precinct, and assignee. |
| 18. |
| Admin & Operations |
| The System must allow exporting complete ticket histories in CSV or XLS format. |
| 19. |
| Admin & Operations |
| The System must provide a report builder that can analyze data across entities such as workers, assignments, sites, inventory, and tickets. |
| 20. |
| Admin & Operations |
| The System must treat saved reports or queries as dynamic views that refresh with current data, while allowing users to export static report snapshots when needed. |
| 21. |
| Admin & Operations |
| The System must allow users to add or remove fields from reports without vendor assistance. |
| 22. |
| Admin & Operations |
| The System must support basic aggregate functions (e.g., count, sum, average) within analytical reports. |
| 23. |
| Admin & Operations |
| The System must support multi‑criteria filtering, including AND/OR operators and basic text and numeric matching. |
| 24. |
| Admin & Operations |
| The System must allow users to save named queries or views for reuse across multiple sites and election cycles. |
| 25. |
| Admin & Operations |
| The System must allow authorized users to export reports in standard formats, including CSV, XLS/XLSX, and PDF. |
| 26. |
| Admin & Operations |
| The System must support reporting on current and past elections with election‑specific filtering. |
| 27. |
| Admin & Operations |
| The System must allow authorized staff to create, configure, and manage structured report templates (e.g., certificates, rosters, letters) with predefined layouts, data fields, and formatting. |
| 28. |
| Admin & Operations |
| The System must generate template‑based reports by automatically populating predefined fields with System data associated with workers, sites, elections, roles, equipment, or assignments. |
| 29. |
| Admin & Operations |
| The System must support batch generation of template‑based reports for selected groups of workers, sites, precincts, or assignments to support operational workflows (e.g., training certificates, precinct rosters, delivery cards). |
| 30. |
| Admin & Operations |
| The System must allow authorized staff to generate, print, and export template-based reports in standard formats (PDF, CSV, XLS/XLSX). |
| 31. |
| Admin & Operations |
| The System could support configurable conditional fields or sections within template‑based reports that display dynamically based on worker, site, or assignment attributes. |
B.
Inventory
| 32. |
| Inventory |
| The System must allow authorized users to create, edit, and deactivate inventory item types or categories (e.g., Pollbook, Ballot Box, ADA Kit, Signage, Furniture), including defining standard fields and attributes for each item type. |
| 33. |
| Inventory |
| The System must allow authorized staff to create, edit, and deactivate individual inventory item records. |
| 34. |
| Inventory |
| The System must provide an overall inventory structure that allows staff to view, search, and manage all inventory item types and item records across the organization. |
| 35. |
| Inventory |
| The System must allow staff to associate inventory items and quantities with polling places, including sites, and rooms. |
| 36. |
| Inventory |
| The System should support assigning equipment/supplies to specific sites for a given election, without overwriting historical assignments. |
| 37. |
| Inventory |
| The System should support grouping inventory items into template kits (e.g., “Judge Supply Kit,” “Check‑in Station Kit”) to be populated for site assignments and reflected within delivery packages. |
| 38. |
| Inventory |
| The System could support hierarchical grouping or kit structures (e.g., kits containing sub‑kits). |
| 39. |
| Inventory |
| The System must support creating and managing distinct delivery packages for each site, allowing multiple deliveries (e.g., Early Voting setup, Election Day setup, supplemental deliveries) to be planned, tracked, and confirmed separately. |
| 40. |
| Inventory |
| The System must allow authorized site staff to confirm and view inventory allocation by site, including expected quantities, delivered quantities, and any outstanding items. |
| 41. |
| Inventory |
| The System must support tracking the return of equipment and supplies from each site, including date/time and staff completing the check‑in. |
| 42. |
| Inventory |
| The System could support electronic tracking methods, such as barcoding or RFID, for equipment delivery, return, and inventory management. |
| 43. |
| Inventory |
| The System must allow staff to mark delivery/return exceptions (e.g., missing items, damaged items, partial return). |
| 44. |
| Inventory |
| The System must support attaching photos and documents to inventory items or delivery package (e.g., damaged item images, configuration sheets). |
| 45. |
| Inventory |
| The System must allow staff to enter inventory‑level or delivery package notes documenting item condition or issues (e.g., “power cord missing,” “battery replaced,” “case cracked”). |
| 46. |
| Inventory |
| The System should assist in generating efficient truck routes based on delivery package schedules. |
| 47. |
| Inventory |
| The System should allow users to manually edit any generated truck routes. |
| 48. |
| Inventory |
| The System should allow truck routes to be exported and printed. |
| 49. |
| Inventory |
| The System should support ability to create, modify, export, print delivery and redelivery schedules per day, truck, precinct, or site. |
| 50. |
| Inventory |
| The System must support recording the chain of custody for election materials, including assignment, transfer, and return events. |
| 51. |
| Inventory |
| The System could allow third‑party vendors or delivery personnel to record chain‑of‑custody events, such as material delivery or return, using limited, role‑based access. |
| 52. |
| Inventory |
| The System must support tracking the delivery and redelivery of individual items and packages by truck, precinct, or site in real-time. |
C.
Polling Place Management
| 53. |
| Polling Place Management |
| The System could enable the direct upload of standard geospatial file types, including Esri Shapefiles (.shp ) without requiring third-party data conversion. |
| 54. |
| Polling Place Management |
| The System could support the direct consumption of standard geospatial web service endpoints without requiring third‑party data conversion. |
| 55. |
| Polling Place Management |
| The System could generate print‑ready 100‑foot electioneering buffer maps for each polling place. |
| 56. |
| Polling Place Management |
| The System must allow authorized staff to create, edit, and deactivate polling site records. |
| 57. |
| Polling Place Management |
| The System should allow third‑party vendors or facility contacts to update polling place information, such as building details or contact information, using limited, role‑based access. |
| 58. |
| Polling Place Management |
| The System must allow staff to associate one or more precincts with a polling site. |
| 59. |
| Polling Place Management |
| The System should allow staff to create, edit, and deactivate rooms or areas within a site/building that may be used for Election Day, Early Voting, training, dropoff, or other site functions. |
| 60. |
| Polling Place Management |
| The System must prevent accidental creation of duplicate site records based on name/address matching and must allow authorized staff to merge duplicates when needed. |
| 61. |
| Polling Place Management |
| The System must support Active, Potential, and Inactive statuses for sites. |
| 62. |
| Polling Place Management |
| The System must support assigning sites to specific elections without affecting historical election data. |
| 63. |
| Polling Place Management |
| The System must allow maintaining or copying site, room configurations and precinct association from a previous election into a new election cycle. |
| 64. |
| Polling Place Management |
| The System must allow staff to associate precinct → site/building → room so worker assignments reflect correct physical locations. |
| 65. |
| Polling Place Management |
| The System must allow authorized administrators to create, edit, and deactivate System‑wide custom fields for polling‑site records. |
| 66. |
| Polling Place Management |
| The System should support attaching documents, photos, diagrams, floorplans, agreements, and checklists to site records. |
| 67. |
| Polling Place Management |
| The System must allow staff to store site‑specific notes visible to Election Day support teams (e.g., access restrictions, room setup constraints). |
| 68. |
| Polling Place Management |
| The System should expose polling place details (address, contacts, notes, ADA information, and room details) to assignment workflows, logistics workflows, ticketing workflows, and reporting, without siloing. |
| 69. |
| Polling Place Management |
| The System must allow sites/buildings to serve multiple roles (Election Day site, Early Voting site, training site, drop‑off site) within the same election if applicable. |
| 70. |
| Polling Place Management |
| The System must allow staff to view precinct boundary maps for buildings/sites. |
| 71. |
| Polling Place Management |
| The System must allow authorized staff to create, edit, and deactivate site‑level contact records (e.g., head custodian, assistant manager, facility coordinator). |
| 72. |
| Polling Place Management |
| The System must allow staff to store multiple contacts for each site/building, each with name, role, phone number(s), email address, and optional notes. |
| 73. |
| Polling Place Management |
| The System should allow creation and maintenance of organization-level contacts (e.g., Minneapolis Public Schools, Park Board) separate from site contacts. |
| 74. |
| Polling Place Management |
| The System should allow linking site contacts to organization records (e.g., a school’s principal is an org‑level contact). |
| 75. |
| Polling Place Management |
| The System could allow staff to associate documents to organizations or contact records (e.g., agreements, security instructions, parking maps). |
| 76. |
| Polling Place Management |
| The System must allow staff to designate a “primary contact” for each polling place and organization. |
| 77. |
| Polling Place Management |
| The System could support the creation of follow‑up tasks linked to specific sites. |
| 78. |
| Polling Place Management |
| The System could track site usage history (which elections used it and any issues reported). |
| 79. |
| Polling Place Management |
| The System could generate print‑ready site setup checklists based on site configuration. |
D.
Workers & Training
| 80. |
| Workers & Training |
| The System must provide a mobile‑friendly public‑facing portal that supports all worker interactions, including submitting applications, managing profiles, viewing application status, confirming assignments, and managing training signup. |
| 81. |
| Workers & Training |
| The System must allow worker records to be generated automatically from public‑facing online applications. |
| 82. |
| Workers & Training |
| The System should allow staff to review and modify worker records created from public‑facing applications before activation. |
| 83. |
| Workers & Training |
| The System must allow authorized staff to create and edit worker records without requiring a public‑facing application. |
| 84. |
| Workers & Training |
| The System must allow authorized administrators to define and maintain standardized worker fields, including both System‑provided fields (e.g., contact information, language skills) and administrator‑created custom fields that appear on all worker records. |
| 85. |
| Workers & Training |
| The System must support tracking worker status (e.g., Active, Inactive, Terminated) and allow bulk status updates. |
| 86. |
| Workers & Training |
| The System must support detecting and merging duplicate worker records. |
| 87. |
| Workers & Training |
| The System must support attaching documents to worker records (e.g., waivers, notes, payroll forms, parent permission). |
| 88. |
| Workers & Training |
| The System should allow staff to send forms to external contacts and collect completed submissions—either as returned documents (e.g., PDFs) or through digital completion—while tracking their completion status. |
| 89. |
| Workers & Training |
| The System must support field validation on public‑facing online worker applications, ensuring required fields are completed and entries follow defined formats (e.g., phone number, email, address). |
| 90. |
| Workers & Training |
| The System must provide an application queue with filtering options such as date submitted, application status, and desired work role type. |
| 91. |
| Workers & Training |
| The System must allow staff to review, accept, or deny applications individually or in batch. |
| 92. |
| Workers & Training |
| The System must allow authorized staff to create, edit, and deactivate or archive election worker job roles/titles (e.g., Head Election Judge, Poll Book and Registration Specialist, Early Vote Center team member), including configuring default pay rates, default hours for each role/title. |
| 93. |
| Workers & Training |
| The System must allow authorized staff to create, configure, and manage available worker shifts by site and role. |
| 94. |
| Workers & Training |
| The System must allow authorized staff to assign and update worker placements for sites and shifts. |
| 95. |
| Workers & Training |
| The System must support multi‑day and multi‑week scheduling worker shifts for voting operations before Election Day (e.g. Early Voting sites). |
| 96. |
| Workers & Training |
| The System must surface worker attributes relevant to assignment decisions during assignment workflows, including language skills, party affiliation, home precinct, student status, and any site or shift preferences. |
| 97. |
| Workers & Training |
| The System should allow staff to make or edit assignments directly from a worker’s profile in addition to other assignment workflow screens. |
| 98. |
| Workers & Training |
| The System must surface polling place requirements during assignment workflows, including language needs, balance of political party representation, student worker requirements, and required role types. |
| 99. |
| Workers & Training |
| The System must track student worker information, including student status, school name, graduation year, and any per‑election requirements such as parent authorization |
| 100. |
| Workers & Training |
| The System must support batch operations to update student worker records, including removing parent authorization when no longer required and advancing student workers to non‑student status upon graduation. |
| 101. |
| Workers & Training |
| The System must allow workers to confirm or decline assigned shifts through the worker portal. |
| 102. |
| Workers & Training |
| The System must support viewing and filtering assignments by worker and by assignment attributes including site, precinct, role, and shift. |
| 103. |
| Workers & Training |
| The System should provide advisory warnings (not hard stops) when precinct or site staffing targets are unmet, including party balance, language needs, and role/ mix. |
| 104. |
| Workers & Training |
| The System must allow authorized staff to create and maintain training class types (e.g., certification, recertification, specialist). |
| 105. |
| Workers & Training |
| The System must allow authorized staff to create training class sessions with date/time, location, capacity, and registration details. |
| 106. |
| Workers & Training |
| The System must support bulk creation of training class sessions, enabling staff to generate multiple sessions at once based on shared parameters such as date/time, location, capacity, or templates. |
| 107. |
| Workers & Training |
| The System must allow authorized staff to define required and optional training requirements for each worker role and specify which training class types and sessions fulfill those requirements. |
| 108. |
| Workers & Training |
| The System should allow staff to define required and optional training requirements based on worker criteria such as experience, past training, number of elections worked, or whether the worker is new to a job title. |
| 109. |
| Workers & Training |
| The System should allow staff to define prerequisite ordering for training courses. |
| 110. |
| Workers & Training |
| The System must allow workers to self‑select training class sessions available to them based on defined role‑based training requirements through a worker portal. |
| 111. |
| Workers & Training |
| The System must allow authorized staff to assign workers directly to training class sessions through an admin interface. |
| 112. |
| Workers & Training |
| The System could allow workers to export assigned shifts and scheduled training sessions to a personal calendar (e.g., ICS). |
| 113. |
| Workers & Training |
| The System must support tracking training status (assigned, completed, missed) per election. |
| 114. |
| Workers & Training |
| The System must support generating, exporting and printing class rosters, sign‑in sheets, and name tags. |
| 115. |
| Workers & Training |
| The System must support efficient digital attendance tracking, including fast/bulk attendance entry for training sessions. |
| 116. |
| Workers & Training |
| The System must provide visibility into missed‑training status so authorized staff can incorporate this information into assignment decisions. |
| 117. |
| Workers & Training |
| The System could support online or virtual training options for defined worker groups. |
| 118. |
| Workers & Training |
| The System could facilitate options for online training modules or integrations. |
| 119. |
| Workers & Training |
| The System should determine and record a worker’s home precinct based on their Minneapolis address (and corresponding precinct location dataset) and surface it to staff to support assignment decisions. |
| 120. |
| Workers & Training |
| The System must allow authorized staff to create and manage digital worker surveys and peer assessments and associate them with specific roles, elections, or assignments. |
| 121. |
| Workers & Training |
| The System must allow authorized staff to review and manage submitted worker surveys and feedback, including assigning an overall review score per worker per election. |
| 122. |
| Workers & Training |
| The System must display evaluation scores and related evaluation history on worker records for authorized staff. |
| 123. |
| Workers & Training |
| The System must retain and display historical assignment records as part of the worker record. |
| 124. |
| Workers & Training |
| The System must allow workers to record their own time entries using a self‑reporting interface. |
| 125. |
| Workers & Training |
| The System must enable authorized users to review, validate, and edit worker‑reported time. |
| 126. |
| Workers & Training |
| The System must support exporting reported hours and pay rate per election worker. |
| 127. |
| Workers & Training |
| The System should allow election workers to be designated as volunteers, with their compensation automatically set to zero. |
E.
Campaign Finance
The System could support the following Campaign Finance functionality. Systems without Campaign Finance capabilities will still be considered.
| 128. |
| Campaign Finance |
| The System should allow candidates to create and manage distinct campaign‑finance user accounts, separate from worker or vendor accounts, and must support a single individual holding multiple account types without exposing information across them. |
| 129. |
| Campaign Finance |
| The System should allow candidates to create and maintain campaign profiles associated with specific election cycles. |
| 130. |
| Campaign Finance |
| The System should allow campaign profiles to be accessed and managed by multiple authorized user accounts (e.g., candidates, treasurers, officers). |
| 131. |
| Campaign Finance |
| The System could support onboarding workflows that guide candidates through required initial filings based on election rules (e.g., initial ethics disclosures). |
| 132. |
| Campaign Finance |
| The System should allow authorized staff to define and manage filing requirements for candidates based on election‑specific rules (e.g., spending thresholds, ballot status, and campaign closure). |
| 133. |
| Campaign Finance |
| The System should allow authorized staff to create and manage structured digital filing forms, including required candidate ethics or disclosure forms, and allow candidates to complete and submit them online. |
| 134. |
| Campaign Finance |
| The System should allow candidates to complete and submit required filing forms digitally, with the option to generate a copy of the submitted data. |
| 135. |
| Campaign Finance |
| The System should allow authorized staff to create, configure, and manage campaign finance report types, including defining filing deadlines and reporting periods. |
| 136. |
| Campaign Finance |
| The System should allow candidates to generate campaign finance reports by selecting the appropriate report type based on required filing deadlines. |
| 137. |
| Campaign Finance |
| The System should provide staff with tools to monitor candidate filing requirements, track submitted reports and automatically identify reports that are overdue or missing. |
| 138. |
| Campaign Finance |
| The System should allow authorized elections staff to view draft versions of candidate-submitted campaign finance reports. |
| 139. |
| Campaign Finance |
| The System should allow campaign staff to directly submit and publish campaign finance reports into the System without needing approval by Elections staff. |
| 140. |
| Campaign Finance |
| The System should allow candidates to enter and edit individual contribution and expenditure transactions manually. |
| 141. |
| Campaign Finance |
| The System should allow candidates to import contribution and expenditure transactions via CSV and review or edit the imported transaction details. |
| 142. |
| Campaign Finance |
| The System should display a complete report summary (totals, itemized transactions, contributions, expenditures) for candidates to review before submission. |
| 143. |
| Campaign Finance |
| The System should allow candidates to file amended versions of previously submitted reports. |
| 144. |
| Campaign Finance |
| The System should facilitate an option for staff, candidates, and the public to download submitted campaign finance reports in standard export formats (e.g., PDF, CSV).” |
| 145. |
| Campaign Finance |
| The System should provide a public-facing portal where campaign finance reports, transactions, and candidate summaries are viewable. |
| 146. |
| Campaign Finance |
| The System should present clear and consistent totals and indicators in public search results to prevent misinterpretation caused by filtered data views |
| 147. |
| Campaign Finance |
| The System should store transactions as discrete, itemized records to support public search and reporting. |
| 148. |
| Campaign Finance |
| The System should allow the public to search campaign finance data by election cycle, candidate, contributor, and other filters. |
| 149. |
| Campaign Finance |
| The System should allow authorized staff to export data for use in legal compliance review and referral. |
| 150. |
| Campaign Finance |
| The System should allow authorized staff to send communications to candidate groups based on filing obligations, campaign status, and election-specific criteria. |
ATTACHMENT D
CLOUD TECHNICAL CAPABILITIES
The terms “System”, “Software”, and “Application” is used throughout this attachment. These terms are meant to represent the Consultant’s proposed software and infrastructure, as applicable.
1. Consultant must respond to each individual capability by entering an ‘X’ in one of the non-grey columns provided. Select the appropriate response using the following guidelines below. If the columns are grey, provide a description in the “Describe” column. It is highly recommended that a technical resource completes this attachment.
| Standard |
| The capability is satisfied by the System proposed. |
· If the System requires specialized configuration, Consultant must enter required configuration in the “Describe” section provided.
· If the capability is satisfied by third-party software, please indicate the third-party product proposed.
| Customization |
| A modification to the System is required to satisfy the capability. |
· Consultant must provide an explanation of the work required to perform the modification in the “Describe” section provided.
| Not Available |
| The System will not satisfy the capability. |
2. Consultant is strongly encouraged to provide a brief explanation of how the capability will be satisfied for each capability.
| Describe |
| · If the capability is met by more than one module, Consultant must list which module or modules are required to satisfy the capability. |
· Consultant may also include screen shots, diagrams, samples, and inventories for any capability listed.
· If unable to meet the capability, Consultant must offer a brief explanation or propose an alternative way to meet the capability.
| Ref. No. |
| Capability |
| Standard |
| Customization |
| Not Available |
| Describe |
The System will not be allowed to use the City’s email system. Describe how the System will send emails.
The proposed System must be hosted under a valid and registered domain name (e.g., https://yourcompany.vendor.com) and not solely accessible via an IP address. The System must:
· Provide a fully qualified domain name (FQDN) for the hosted service.
· Not make use of raw IP addresses for production access, user login, or application endpoints.
The System must run over a web browser.
The System must not require a thick or thin client for both administrative- and end-users.
All functionality is supported over a web browser.
System supports current browser versions, including but not limited to Firefox, Chrome, Edge and implements modern web standards.
If the System doesn’t run over a web browser, describe how the software runs (for example, via a thick client).
If via a thick or thin client, software must support remote, unattended/silent installation and configuration.
If the System provides a native mobile application, describe how the application renders on smart phones and/or tablets, including any hardware or operating system limitations.
If a mobile application is available, it continues to be functional during loss of network connectivity, e.g. store locally and automatic sync when network connectivity is available. Describe how this can be achieved.
Software is designed to run on a wide variety of form factors using a responsive or native design.
Application Security
System does not require users to have local administrator rights to access or use the solution.
System design adheres to the principle of least privilege (see, for reference, NIST’s definition: https://csrc.nist.gov/glossary/term/least_privilege).
Consultant shall provide a comprehensive, third-party penetration testing report annually, detailing the testing scope, methodology, and a prioritized list of findings.
Application must comply with OWASP top 10 risks for web applications.
System operates with controls applied by mobile device and mobile application management technology services (MDM, MAM).
Application must support SAML for modern authentication protocols for single sign-on for City users and provide a mechanism for additional identity provider for constituents.
Data Security
System has the ability to classify data elements and unstructured data that are regulated as private or otherwise not public under local, state or federal law.
System has the ability to mask and/or redact regulated non-public data from system views, query results, and outputs.
System has the ability to classify and prevent changes to structured or unstructured data elements that are considered official (immutable) government records within the System.
System has the ability to support input validation to maintain data quality and integrity.
System has the ability to prevent unauthorized users from changing or deleting data.
System has the ability to secure data transferred between the client (i.e. on City devices, client devices, or a web browser) and the application.
System has the ability to encrypt data, including backups, at rest and in transmission.
System must ensure confidentiality, integrity and availability of the data.
Secure Maintenance
Describe how Consultant maintains an active vulnerability and threat-monitoring program that conforms to the following standards:
· Zero-day vulnerabilities are remediated within two business days
· Critical and high vulnerabilities are remediated within 30 business days
At minimum, System supports versions of software with a standard of Current Minus Two (two versions behind most recent release).
Cybersecurity
System must protect City data and services with a firewall or other City-approved solution that excludes all network traffic to environments hosting City data and services, except that which is explicitly allowed. Examples of untrusted networks include:
· Internet
· Other customer networks
· Consultant management network
· Consultant corporate network
System employs and monitors network and host-based intrusion detection and prevention solutions to protect City data and services. This includes anti-malware capabilities.
System employs a continuous security monitoring solution including the ability to manage and protect log files from tampering and retain logs for up to 12 months.
The System must ensure full separation of the City’s data from that of other customers, tenants, or clients on the same platform, and guarantee that no other customer can access the City’s data.
System must restrict access to City data and services by Consultant’s personnel to only those who have an approved business need.
System has the ability to log and report on physical access to infrastructure hosting City data and services.
System must ensure all City data, including backups, resides within the continental United States.
Describe how the System uses artificial intelligence to fulfill any of the functionality provided by the System.
System will not transmit City data to general purpose AI models such as ChatGPT.
| D. |
| Auditability/Security Monitoring |
System must include documented procedures to audit at least annually all user access accounts to City data.
System preserves and protects logs against tampering or deletion by privileged users.
System must have the capability to enforce auditing and log basic information about user access activity, administration activities, system events and errors, and access violation reports. Activity logs must capture at least the following:
· User authentication
· Type of event
· Date and time
· Success or failure indication
· Origination of event
· Identity or name of affected data, system component or resource
System logs and reports on security events including, but not exclusive to:
· Log on
· Log off
· Failed Log on
· Account Locked
· Account Unlocked
· Password Reset
System logs and reports on access/authentication changes including, but not exclusive to:
· New account created
· Accounts disabled / enabled
· Account deleted
· Authorization changes such as adding user (or removing from) a new role or other evidence of an authorization change.
· Privilege escalation (i.e. escalation from any user role to system administrator role)
System has the ability to implement ‘separation of duties’ (fraud prevention) controls around critical workflow and transaction changes and approvals.
System logs and reports on changes to configuration settings.
System logs and reports on application and data management events such as:
· Data Element Changes
· System Error messages
· Files opened and closed
· Files modified
System provides mechanism to consume secure SOAP-based and/or REST-based web services from external and internal systems.
| 1. |
| Describe how the System provides existing web service API(s) that can be exposed for internal and external consumption. |
System provides mechanism that can be automated to export data via batch process(es).
| 1. |
| Describe the mechanisms that the System can provide to import data via batch process(es). |
System provides capability for automated near real-time export of data out of the system.
System integration layer is kept on same upgrade schedule as the core system.
System provides a repeatable and automated mechanism to access data required by the City to perform all reporting and ETL functions necessary to support business processes.
| F. |
| Storage, Reporting, and Retrieval |
System allows for the configuration of data retention rules within the System.
The System must include robust reporting functionality that meets both operational and strategic business needs. Specifically, the System must:
· Provide a comprehensive set of standard out-of-the-box reports relevant to the solution’s core functions.
· Support the ability to generate custom reports based on business-specific criteria, including filtering, grouping, date ranges, and user-defined fields.
All data collected within the System (whether it be out-of-the-box or customized) must be accessible via the System’s robust reporting functionality.
System has the ability to back-up and restore data to support the following:
· Recovery Point Objective: 24-hours – no more than 24-hours data loss.
· Recovery Time Objective (Incidental Restore Requests): 4 hours
System supports 99.99% uptime.
System supports testing or other verification of the disaster recovery process on an annual basis.
ATTACHMENT E
SOLUTION CATEGORY IDENTIFICATION
1. The Definitions Table below provides information on how the City defines on-premise, cloud, and SaaS solutions. Consultant must respond by entering an ‘X’ in the column that best matches its proposed solution in the Consultant’s Response Table.
2. Consultant must provide a brief explanation of how its solution deviates from the definition, if at all.
Definitions Table:
| On-Premise |
| The City provides support for the following, if applicable: |
· Network services, such as connectivity
· Infrastructure services, such as virtual servers (web servers, database servers)
· Desktop services, such as computers and client installs The Consultant provides the following, if applicable:
· Software solution, including support
· Hardware device, such as an appliance or a hand-held device
| IaaS |
| Consultant provides and manages the infrastructure, such as servers, virtual machines, storage, networks, operating systems, from a cloud provider on a pay-as-you-go basis. |
| PaaS |
| Consultant provides an on-demand environment for developing, testing, delivering, and managing software applications. PaaS is designed to make it easier for developers to quickly create web or mobile apps, without worrying about setting up or managing the underlying infrastructure of servers, storage, network and databases needed for development on a pay-as-you-go basis. |
| SaaS |
| Consultant hosts and manages the software application and underlying infrastructure, and handles any maintenance, like software upgrades and security patching. Users connect to the application over the internet, usually with a web browser on their phone, tablet, or PC. All services are included as part of the SaaS subscription fee. |
Consultant’s Response Table
| On-Premise |
| IaaS |
| PaaS |
| SaaS |
| Description of Deviation(s) |
Solution Dependencies
· Consultant must specify, in the Solution Dependency Table below, if the proposed solution has any dependencies on City network or infrastructure, such as:
1. Network connectivity or communication that requires a site-to-site VPN tunnel
2. Data transfer to or from the Consultant doesn’t go over the public internet
3. Connects to local Active Directory for authentication
Solution Dependency Table The proposed solution has the following dependencies on City network or infrastructure:
ATTACHMENT F
COST/FEE TEMPLATE
(include in RFP release as an Excel spreadsheet)
Attachment Cost_Fee Template.xlsx
ATTACHMENT G
DATA PRIVACY
Consultant must answer the following questions relating to data privacy.
| 1 |
| What data will be created or collected by the System? |
| 2 |
| Describe all uses of the data that is created or collected by the System beyond the City’s use of the System. |
| 3 |
| Will third parties have access to this data for purposes other than those related to the project? Please provide details. |
| 4 |
| Have any third-party security or data protection assessments been performed against the System? If yes, please provide the assessments. |
| 5 |
| How will Consultant obtain written approval from the City prior to sharing any City data with a third party? |
| 6 |
| How will the Consultant ensure the City's data is returned and/or destroyed within 90 days of the end of services? |
ATTACHMENT H
REFERENCES
Consultant is requested to provide three references of current customers, and three references of former customers. For each numbered row, Consultant should provide the requested reference information in writing, using the soft copy of this template. All customer references provided should be in regard to customer accounts where Consultant’s services are/were similar to the City’s project in terms of size, scope and geographic footprint.
| Consultant’s Customer |
| Contact Name and Title |
| Contact’s Email and Phone Number |
| Brief Description of Consultant’s Service |
Relationship with Customer
CURRENT CUSTOMERS
1.
2.
3.
FORMER CUSTOMERS
4.
5.
6.
ATTACHMENT I
Q&A SUBMITTAL FORM