COOK COUNTY GOVERNMENT

Office of the Chief Procurement Officer

Request for Proposal

RFP No. 2550-09162 for

Case Management System

Non-Mandatory Pre-Proposal Meeting:

Date: February 5, 2026 Time: 11:00 AM Local Time – Chicago Web Link: Microsoft Teams Join the meeting now Meeting ID: 254 688 387 413 05 Passcode: bu3Rv3xf Dial in by phone +1 872-215-6022,,538087704# United States, Chicago Find a local number Phone conference ID: 538 087 704#

Questions:

Questions must be submitted in Bonfire no later than: February 11, 2026 at 10:00 a.m. Local Time

– Chicago

Proposal Due Date:

Proposals are due in Bonfire no later than: 10:00 a.m. Local Time – Chicago on Tuesday, March 31, 2026

Proposal and Questions Must be Uploaded on the Contract Opportunity in Bonfire via:

https://cookcountyil.bonfirehub.com/portal/?tab=openOpportunities

LATE PROPOSALS WILL NOT BE CONSIDERED

Buyer Contact Information:

Buyer: Halyna Shuruk E-Mail: halyna.shuruk@cookcountyil.gov

Toni Preckwinkle Raffi Sarrafian Cook County Board President Chief Procurement Officer https://teams.microsoft.com/l/meetup-join/19%3ameeting_N2ViN2FhYTgtYTdkMi00ZTVhLTkwNGQtOTdkNTgyY2U3MDMz%40thread.v2/0?context=%7b%22Tid%22%3a%228b4d55ae-6db4-4e05-a85c-59d6a256cd6e%22%2c%22Oid%22%3a%2290d19237-cf04-44da-a423-41fca147eb65%22%7d tel:+18722156022,,538087704 https://dialin.teams.microsoft.com/eb9b93da-8c7c-4393-8724-4a248832530e?id=538087704 https://cookcountyil.bonfirehub.com/portal/?tab=openOpportunities mailto:halyna.shuruk@cookcountyil.gov

RFP N0. 2550-09162

1 INTRODUCTION

1.1 Overview

1.2 Purpose

1.3 Business Goals and Objectives

1.4 Cook County Background

2 SCOPE

2.1 Proposed Project Approach

2.1.1 Project Management & Methodology

2.1.2 Discovery and Scoping Process

2.1.3 Development, Implementation, & Configuration Process

2.1.4 User Acceptance Testing (UAT)

2.1.5 Project Plan and Timeline

2.1.6 Project On-Site Requirements

2.2 Support and Training

2.2.1 Knowledge Transfer and Training

2.2.2 Go-Live Support

2.2.3 Ongoing Support & Service Level Agreements (SLAs)

2.2.4 Administrator Features & Enablement

2.2.5 Maintenance & Updates

2.2.6 Enhancement Requests

2.3 System Solution

2.3.1 System Solution Overview

2.3.2 Software & Technical Specifications

2.3.3 Application Functionality Overview

2.3.4 Hosting Environment

2.3.5 User Experience (UX) & User Interface (UI)

2.4 Data Implementation, Security, and Compliance

2.4.1 Data Conversion/Migration

2.4.2 Data Integrations

2.4.3 Data Ownership, Access, and Retention

2.4.4 System/Data Security

2.4.5 Security Compliance and Auditing

2.4.6 Incident Response Plan

2.4.7 Business Continuity and Disaster Recovery

2.5 Agreement Terms

2.5.1 Contract Performance Review and Acceptance

2.5.2 Invoicing and Payments

2.5.3 Licensing, Warranties and other terms and conditions

2.5.4 Intellectual Property

2.5.5 Transition Out and Exit Requirements

2.5.6 Vendor Capacity

3 SCHEDULE

4 INSTRUCTIONS TO PROPOSERS

4.1 Instructions

4.2 Availability of Documents

4.3 Non-Mandatory Pre-Proposal Conference

4.4 Special Access to the Pre-Proposal Conference

4.5 Clarifications

4.6 Submitting the Proposal Package

4.7 Uniformity

4.8 Proposal Material

4.9 Addenda

4.10 Proposer’s Responsibility for Services Proposed

4.11 Errors and Omissions in the RFP

4.12 RFP Interpretation

4.13 Confidentiality and Response Cost and Ownership

4.14 Use of Subcontractors

4.15 MBE/WBE Participation Goals

4.16 Proposer’s Disclosure and Conflict of Interest

4.17 Cook County RFP Format

4.18 Pricing

4.19 Period of Firm Proposal

4.20 Awards

4.21 Cook County Rights

4.22 Alteration/Modification of RFP Content

4.23 Recycling

5 EVALUATION AND SELECTION PROCESS

5.1 Responsiveness Review

5.2 Acceptance of Proposals

5.3 Evaluation Process

5.3.1 Proposer Presentations

5.3.2 Right to Inspect

5.3.3 Best and Final Offer

5.4 Selection Process

6 EVALUATION CRITERIA

6.1 Responsiveness of Proposal

6.2 Technical Proposal

6.3 Oral Presentations

6.4 Price Proposal

6.5 Best and Final Offer

7 SUBMISSION OF PROPOSAL

7.1 Instructions for Submissions

7.1.1 Electronic Submission

7.1.2 Time for Submission

7.1.3 Format

7.1.4 Complete Proposals

7.1.5 Packaging and Labeling

7.1.6 Timely Delivery if Proposals

7.1.7 Late Proposals

7.1.8 Schedule of Revisions to RFP Schedule

7.2 Submission Requirements

7.2.1 Cover Letter

7.2.2 Executive Summary

7.2.3 Qualifications of the Proposer

7.2.4 Proposed Plan of Action, Implementation, and Solution

7.2.5 Key Personnel

7.2.6 Subcontracting or Teaming

7.2.7 MBE/WBE Participation

7.2.8 Financial Status

7.2.9 Legal Actions

7.2.10 Conflict of Interest

7.2.11 Economic Disclosure Statement

7.2.12 Cook County Professional Services Agreement (PSA)

7.2.13 Identification of Subcontractor/Supplier/Subconsultant Form

7.2.14 Addendum Acknowledgement Form

7.2.15 Pricing Proposal

7.2.16 System Requirements Matrix

7.2.17 Insurance Requirements Statement

7.2.18 Other

EXHIBIT I

EXHIBIT II

EXHIBIT III

EXHIBIT IV

EXHIBIT V

EXHIBIT VI

EXHIBIT VII

EXHIBIT VIII

EXHIBIT IX

EXHIBIT X

EXHIBIT XI

System Requirements Matrix

Pricing Proposal Form

Instructions for Submitting electronic Bid/Proposal/Qualification

Cook County IT Special Conditions, ADA ITDSCs EXHIBIT X

Criminal Justice Information Services (CJIS) Security Policy Appendix H

Economic Disclosure Forms

Cook County Professional Services Agreement

Addendum Acknowledgement Form

MBE/WBE Utilization Plan Forms

Identification of Subcontractor/Supplier/Subconsultant Form

Certification for Consulting or Auditing Services

EXHIBIT XII Electronic Payables Form

EXHIBIT XIII Cook County Travel Policy

1 INTRODUCTION

1.1 Overview

The Cook County Law Office of the Public Defender (“OPD”) is seeking proposals from qualified firms for a Case Management System (CMS) tailored to the operational demands of one of the largest public defense offices in the country, serving tens of thousands of clients annually with a staff of over 490 attorneys, 130 support staff, and 80 administrators.

The mission of OPD is to safeguard the fundamental rights, liberties, and dignity of each person whose case is entrusted to the Public Defender, through exceptional legal representation. OPD operates the following divisions and units: Homicide Task Force, Felony Trial Division, Municipal Divisions 1 to 6, Juvenile Justice Division, Family Defense Division, Arrest Response Division, Investigations Division, Forensic Science Division, Multiple Defendant Division, Trial Technology Division, Mitigation Division, Legal Resources Division, Professional Development, Domestic Advocacy Unit, Immigration Division, Mental Health Resource Unit, and Pretrial Division.

OPD provides legal services to indigent clients as mandated by the United States Constitution and the Illinois Public Defender Act. The OPD is directed by the court to act as attorney, without fee, for all persons who are held in custody or charged with any criminal offense, and who the court finds are unable to employ counsel. The Public Defender is also statutorily directed to represent individuals subject to the Juvenile Court Act. Public Defenders are appointed by the judge when an individual is unable to afford an attorney (55 ILCS 5/3-4006).

1.2 Purpose

The purpose of this solicitation is to identify qualified proposers of Case Management System (CMS) solutions and implementation services. The CMS is mission-critical and must function as the central hub for managing all case-related activities, accommodating the specialized requirements of public defense attorneys, investigators, specialists, and administrative support staff. The proposed solution should seamlessly integrate with upstream data sources, streamline complex workflows, enhance productivity and efficiency, improve data accuracy and accessibility, strengthen reporting capabilities for informed decision-making, and rigorously protect client confidentiality.

The OPD intends to enter into a 5-year agreement with one 3-year renewal plus one 2-year renewal option with the successful Proposer.

1.3 Business Goals and Objectives

The OPD, through the Office of the Chief Procurement Officer (“Procurement”), is issuing this Public Defender Case Management System Request for Proposals (RFP) to deliver robust case flow, case processing, document management, reporting and other capabilities such as case discovery and disposition management. It is the expectation of OPD that the commercial-off-the-shelf (COTS) solution will provide significant efficiency gains in the overall public defender case management processes. The system must allow for more than 750 concurrent sessions at any given time.

Upon successfully completing this initiative the OPD expects to meet the following goals and objectives:

A. Improve automation throughout the law office;

B. Increase operational visibility;

C. Improve fiscal efficiency;

D. Real-time case tracking;

E. Eliminate redundancies in data entry;

F. Manage and track the overall PD operations and activities;

G. Reduce manual steps;

H. Reduce paper processes;

I. Reduce processing time;

J. Track and manage workload distribution;

K. Retrieve information easily;

L. Enable robust statistical analysis and research;

M. Track and manage incidents; and, N. Improve reporting;

O. Improve with document management and discovery review;

P. Integrate with third-party applications and productivity tools;

Q. Integrate with internal and external data systems.

1.4 Cook County Background

Cook County Government is a home rule county pursuant to Article VII, Section 6 of the Illinois State Constitution and is governed by a 17-member Board of Commissioners that is elected from single-member districts. The Commissioners and County Board President are elected to four-year terms by the citizens of the County. Cook County represents one of the major metropolitan areas in the state and nation, and contains 134 municipalities, (including the City of Chicago), 29 townships, 221 special districts, and 164 school districts. Cook County is home to 5.28 million residents making it the second most populous County in the United States.

The County’s fiscal year begins on December 1st and ends on November 30th. As mandated by state law, the County has principal responsibility for the protection of persons and property, the operation of public health services, the administration of the property tax levy, assessment, collection, and distribution process, and the maintenance of County highways. The obligation to protect persons and property, commonly called public safety, is fulfilled by the provision of County judicial and law enforcement services. The Circuit Court of Cook County which is one of the largest unified court systems in the United States, and the County Jail which is one of the largest single site jail facilities on the country, are solely the responsibility of Cook County Government. Also, Cook County Government administers the second largest property taxation system in the United States, with 1.8 million parcels of real estate.

The obligation to provide public health services is fulfilled by the operation of a comprehensive network of medical facilities for the citizens of the County, and provision of services regardless of their ability to pay. Cook County Health (CCH) consists of the Bureau Health Services, John, H.

Stroger, Jr. Hospital of Cook County, Provident Hospital of Cook County, Department of Public Health, Correctional Health Services at Cermak, Correctional Health Services at the Juvenile Temporary Detention Center, Ruth Rothstein CORE Center and County Care Health Plan (a managed care program for county residents). The Cook County Board of Commissioners established the Cook County Health Board (CCH Board) in 2008 to provide independent oversight of health care operations. The CCH Board is accountable to the Cook County Board of Commissioners. CCH is included in the reporting entity of Cook County, Illinois as an enterprise fund. As an enterprise fund, CCH’s financial statements are prepared using proprietary fund accounting that focuses on the determination of changes in net assets. Financial position, and cash flows in a manner similar to private sector businesses. Financial statements are prepared on an accrual basis of accounting.

2 SCOPE

Proposers must demonstrate proven experience delivering CMS solutions, preferably within the public defense domain, and the capability to deploy these services in a cost effective and efficient manner. The scope of these services encompasses several components outlined in the following subsections, including: a well-defined project approach; support and training methodologies; a detailed description of the system solution; critical data implementation, security, and compliance measures; as well as essential agreement terms to ensure a successful partnership and solution delivery for OPD.

2.1 Proposed Project Approach

Proposers should present a best-practice methodology and innovative solutions for OPD.

Proposals must include a detailed project plan for process initiation, reengineering, and automation, along with a work breakdown structure for work and communication management.

Proposer must provide evidence of past implementations of similar systems where final costs aligned with the original budget.

2.1.1 Project Management & Methodology

Proposers must detail their project management methodology (e.g., Agile, Waterfall/Traditional, Hybrid) and collaboration approach with OPD staff. This section must include:

• Proposed team structure (roles, responsibilities, relevant experience).

• Description of suggested milestones and deliverables as part of the proposed solution.

• Project management tools for collaboration, communication, and task management.

• A comprehensive communication plan (specifying meeting frequency, status reporting formats, escalation pathways).

• A risk management plan to minimize the impact of unexpected events and ensure the project stays on track, within budget, and on schedule.

• Describe approach to integrating the proposed CMS with existing enterprise applications/interfaces and detail the methodology for organizational change management to ensure successful user adoption.

• A description of the application development methodology and its adherence to data security and privacy best practices.

• Please detail all past projects involving a public defense office and other applicable engagements.

2.1.2 Discovery and Scoping Process

Proposer must utilize a Discovery and Scoping Phase before full-scale implementation. This phase allows the Proposer to gain a thorough understanding of OPD’s detailed technical requirements, data to be migrated, current integrations, and existing environment to refine the project scope and timeline.

• Potential activities include deep dives into existing systems, data, terminology;

development of blueprints; and mockups of new interface layouts / functionality. Proposer should detail deliverables included in this phase of the process.

Upon completion of the initial Discovery and Scoping Phase, the Proposer may submit revised timelines based on the deeper understanding gained. OPD reserves the right to review the proposed implementation plan, the Proposer's demonstrated capabilities, and the revised timeline resulting from this discovery phase.

2.1.3 Development, Implementation, & Configuration Process

Recognizing that both custom software applications and Commercial Off-the-Shelf (COTS) solutions require substantial development and configuration, the Proposer must detail its collaborative process for tailoring the system to OPD's unique workflows, operations, terminology, data fields, user roles, and reporting needs. If appropriate, the proposal must clearly differentiate between standard configuration and potential customization requiring additional development, including associated costs and change management processes.

This section must detail the approach for tracing OPD's current state to the proposed system's functionality, including at minimum:

• Business and technology requirements validation approach and timeline.

• Analysis of current systems and data migration strategy (see Section 2.4.1). Total data in the CMS is 2.29 TB as of November 2025.

• Mapping of proposed system functionality to stated business needs.

• Key personnel assigned to tasks and deliverables.

• Key technical and business documentation to be provided.

• Application/system development and configuration approach, including version control, iterative testing, or check-in/check-out procedures.

2.1.4 User Acceptance Testing (UAT)

The Proposer must provide a detailed UAT plan, including:

• Quality Assurance (QA) control tasks and testing required for environment transitions (e.g., testing to staging, staging to production).

• Tools and methods for issue tracking, resolution, and re-testing. Proposal should detail types of testing, including system integration tests, load testing, usability testing, and security testing.

• Development of comprehensive test scripts covering key workflows (e.g., case creation, assignments, support requests, document management, scheduling, reporting) across all user roles.

• UAT sessions involving diverse OPD staff. Clear definition of acceptance criteria for final UAT sign-off by OPD leadership.

2.1.5 Project Plan and Timeline

Proposers must provide a concise project plan outlining phases, a clear timeline with milestones and deliverables, critical success factors, potential risks, and key assumptions. Proposers must demonstrate their understanding of the requirements and propose a specific solution aligned with the described processes.

2.1.6 Project On-Site Requirements

If proposing on-site work, the Proposer must detail staffing and facility requirements. OPD will provide credential access during normal business hours (8 a.m. to 5 p.m. Monday-Friday), with escorted access outside these hours granted as needed. If applicable, the Proposer must describe:

• Physical location requirements (e.g., secure space, cooling, network connectivity).

• Cable and wiring requirements (specifying responsibility for procurement/installation).

• Any additional power requirements imposed on OPD.

• Amount, duration, and staffing (number and roles) for on-site work.

If any requirement is inapplicable, state the basis for this determination.

2.2 Support and Training

Effective user adoption and long-term system usability depend on comprehensive support and training. Proposers must detail their approach to knowledge transfer, training, go-live support, ongoing support including Service Level Agreements (SLAs), administrator enablement, system maintenance, and handling development or enhancement requests.

2.2.1 Knowledge Transfer and Training

Proposers must describe their comprehensive training plan tailored to different user roles (attorneys, investigators, supervisors, support staff, administrators) designed for effective and rapid user adoption. The plan must detail:

• Training content and delivery methods (e.g., on-site, virtual, train-the-trainer).

• Duration and scheduling strategy (minimizing operational disruption).

• Provision of high-quality training materials (manuals, guides, videos).

• Options for ongoing/annual refresher training. Specialized training workshops for both users and administrators.

• Key documentation deliverables (communication plan, training plan, manuals) including total hours and user type categories.

• Deliverables, acceptance criteria, and responsibilities.

• Sample documentation and training materials. Indicate whether training content adheres to the Shareable Content Object Reference Model (SCORM) standard.

• Description of online help resources available post-training.

2.2.2 Go-Live Support

Proposers must detail their strategy and dedicated resources for intensive support during the go-live phase and the immediate post-launch period (e.g., first 30-60 days). This must include:

• Readily available on-site or remote expert support.

• Defined service availability for issue response and resolution.

• Backup and recovery plan specific to the go-live transition (if applicable).

• Clear procedures for escalating critical issues.

• Strategy for supporting multiple Go-Live support windows if the CMS is launched in phases.

2.2.3 Ongoing Support & Service Level Agreements (SLAs)

The Proposal must detail a multi-tiered support model and explicitly state whether OPD is expected to provide Tier 1 support. Support and maintenance response/resolution times must align with defined incident severity levels.

The Proposal must address the following SLAs, stating whether they are offered, any additional costs (to be detailed in the pricing proposal), and specifics for each:

• Help Desk SLA: Hours of operation, methods of contact (phone, email, portal).

• Response Time SLA: Time to connect with the help desk based on issue severity (e.g., critical, high, medium, low), including escalation procedures.

• Incident Resolution SLA: Time from initiation to service restoration based on severity level.

• End-User Account Administration SLA: Types of routine functions available to end-users

(user ID setup, authorization changes, etc.).

• Dedicated Support Engineer SLA (optional): Assigned, named engineer(s) whose time is contractually dedicated to providing advanced technical support that bypasses standard SLAs. The engineer(s) must have the requisite experience to handle the Tier 2 and Tier 3 support requests as this is reserved for more critical or non-trivial requests.

For each SLA, there must be reporting to demonstrate compliance, any tiering (by severity or other classification), and offered service level credits, fee reductions, or earn-backs.

2.2.4 Administrator Features & Enablement

If OPD is expected to provide Tier 1 support or higher, the Proposer must deliver comprehensive training and resources to OPD help desk staff. If applicable, this includes:

• Comprehensive, up-to-date system documentation, user manuals, and an online knowledge base/FAQ.

• Scripts and training for Tier 1 or 2 functions. Include hours dedicated to training administrators.

• Provide detailed list of types of responsibilities and requests Tier 1 support staff are expected to handle.

• Describe options for Tier 1 staff to potentially handle Tier 2 requests with appropriate training. Indicate availability of on call support for Tier 1 escalations or the ability to schedule regular meetings with higher-tier support teams regarding support tickets that may need escalation.

• Define database credentials available to OPD administrators.

• List tools enabling internal support, such as:

o Comprehensive logging and error reporting (detailed logs, real-time monitoring, alerts, debug info).

o Configuration management tools (settings editor, module management, cache/index control).

o User and session management (active session monitoring, audited impersonation).

o Reports that provide audit trail, case access history, and security logs.

o Data integrity tools (validation, basic repair).

o Environment diagnostics (system info, health checks).

o Data dictionaries and entity relationship diagrams for backend data review.

Additional administrator features are detailed in Exhibit I System Requirements Matrix.

2.2.5 Maintenance & Updates

The proposal must detail policies and procedures for applying system updates, patches, and new releases, including:

• Frequency of updates.

• Process for notifying OPD of scheduled maintenance (requiring advance notice, minimizing business hour disruption).

• How new features/enhancements are introduced.

• Confirmation that the system supports CI/CD pipelines for seamless updates and can run in a container to ensure consistent performance across development and production environments.

• Ability to utilize virtualized environments to enable identical data and system configurations between development, testing, and production environments.

See Exhibit I System Requirements Matrix for more details.

2.2.6 Enhancement Requests

Describe the process for OPD to submit requests for system enhancements or new functionality beyond standard updates. Include how requests are evaluated, prioritized, potentially implemented, and associated costs (if any). Indicate if parties other than the Proposer can implement enhancements.

2.3 System Solution

This section requires a comprehensive technical description of the proposed CMS. Proposers should provide comprehensive details regarding the system architecture, software specifications, application functionality, hosting environment, and user experience, ensuring alignment with OPD's needs for an efficient, reliable, and user-friendly CMS.

2.3.1 System Solution Overview

Provide a high-level overview describing the components of the proposed solution. Include diagrams depicting logical and physical models, interfaces, network infrastructure, and other key elements. The solution must interface with common Single Sign-On (SSO) protocols such as SAML, OpenID Connect, or WS-Federation. The County utilizes Oracle Enterprise Single Sign- On Suite Plus. Detail upcoming feature releases if a vendor product roadmap exists.

2.3.2 Software & Technical Specifications

Provide a detailed description of the product(s) and versions proposed. Detail system features and capabilities, indicating if they are native or require third-party integration. Review the following:

• Language of application source code (frontend/backend).

• Operating systems (frontend/backend).

• Client-side or endpoint hardware requirements (if applicable).

• Indicate if a container image is utilized.

• Supported web browsers (referenced in Section 2.3.5).

• Mobile device compatibility (responsive web design required; specify iOS/Android app availability if applicable (referenced in Section 2.3.5).

• Multi-Factor Authentication (MFA) login methods supported with integrations to IAM/SSO.

• New version release schedule.

• Security and audit capabilities (administration, network transmission).

• Application architecture (interfaces, third-party tools, transaction processing).

• Backup and recovery procedures (detailed in Section 2.4.7).

• Support for batch processing and real-time streaming data flows.

• A well-documented API (preferably REST-based).

• Query languages and languages supported by API available to users.

• Documentation provided (operations, technical, training manuals, online help).

Additional Software & Technical requirements are listed in Exhibit I System Requirements Matrix.

2.3.3 Application Functionality Overview

OPD seeks a customized software solution, SaaS product, or Commercial Off-the-Shelf (COTS) cloud-based CMS solution designed for the public defense context, prioritizing efficiency, reliability, and ease of use. Core functional areas are detailed in Exhibit I System Requirements Matrix.

2.3.4 Hosting Environment

Describe the proposed hosting environment, rationale for selection, and any alternatives (with pros/cons). Specify the following details:

• Indicate whether the CMS will be hosted on the vendor's servers, on the organization's own servers (on-premise), on a third-party cloud provider, or indicate if there is flexibility.

• If the platform follows a SaaS (Software as a Service) subscription-based model indicate details about the central hosting infrastructure and how that is maintained. Alternatively, indicate if the platform uses a perpetual licensing (a one-time purchase with ongoing maintenance fees), open-source solutions, or if the platform is considered “works made for hire” or otherwise assigned to/owned by the OPD.

• Proposers are encouraged to provide different hosting options which may confer a better solution or value. Indicate the extent to which the vendors hosting and/or licensing model can separate hosting costs, licensing fees, maintenance, support, and potential customization.

• Cloud provider(s), cloud services utilized (VMs, object storage, databases), data center locations, and commercial/government cloud availability. Indicate if the application layer is stateless, allowing for rapid horizontal scaling across multiple servers during peak loads or auto-recovery in the event of a virtual machine failure.

• Attainment of security certifications (e.g., FedRAMP, SOC 2 Type II, HIPAA). Proven ability to attain CJIS compliance is required.

• Describe system environments detailing any limitations. These should include a development environment (or "sandbox") for testing and debugging new features; a staging environment as a near-perfect replica of the production environment to assist with UAT, validation, load or integration testing; a production environment for Go Live user-facing deployment. A separate dedicated training environment is also desirable.

• Any shared system components (e.g., network segments, backup media, shared file systems). Assume components not identified as shared are dedicated to OPD. Explain how separation is achieved using devices like firewalls, routers, or VLANs, to create distinct subnetworks.

• Data storage and data transfer limits and associated costs for exceeding limits (detail costs in the pricing proposal).

• For on-premise or hybrid solutions: Detail all required server specifications, database compatibility, storage/network requirements, and the scope of OPD support needed for installation, configuration, and maintenance.

Refer to Exhibit I System Requirements Matrix for Hosting requirements.

2.3.5 User Experience (UX) & User Interface (UI)

The CMS must offer an intuitive, clean, and modern UI requiring minimal training. Proposals should describe the UI/UX and, if possible, provide links to interactive demos. Detail the following:

• Compatibility with current versions of major browsers (Chrome, Edge, Firefox, Safari).

• Responsive design for seamless use on desktops, laptops, tablets, mobile devices.

• Mobile access to key functionalities (via responsive web or dedicated app).

• Adherence to accessibility standards (WCAG 2.1 AA required).

• User-configurable dashboards and personalized views.

• Typical system performance metrics (e.g., page load times, search response times).

Detailed UX / UI requirements are listed in Exhibit I System Requirements Matrix.

2.4 Data Implementation, Security, and Compliance

This section details critical data management requirements, including migration, integration, ownership, security, compliance, incident response, and business continuity. Proposers must clearly articulate their strategies and capabilities in these areas to ensure the integrity, security, and availability of OPD's sensitive data within the proposed CMS.

2.4.1 Data Conversion/Migration

Data from OPD's current CMS is essential for conflict checking, managing active cases, fulfilling case retention obligations, and ensuring legal continuity. The Proposer must present a detailed migration strategy, including:

• Process for identifying, extracting, and transforming relevant data from the existing CMS to the new CMS schema.

• Approach for data mapping, format standardization, and resolving inconsistencies.

• Validation procedures, error-checking protocols, and migration testing in a non-production environment.

• A phased or singular cutover plan minimizing downtime and ensuring data integrity.

• Contingency and rollback plans in case of significant issues during cutover.

• Inclusion of data migration tasks in the project plan and timeline.

• Provide a detailed description of experience with data migration projects from legacy systems that may lack standardized data, comprehensive data dictionaries, or formal documentation, and outline the specific methodologies employed to overcome these challenges.

• Include a “mock data conversion” or “pilot migration” as a trial run prior to the full-scale data migration process as an early-stage deliverable.

2.4.2 Data Integrations

The CMS must integrate with critical data sources and systems. The CMS backend must allow establishing new connections to internal and external data sources. Proposer must detail their capability, approach, and potential costs for developing and maintaining integrations, and state if parties other than the Proposer can implement them.

Review of current and potential integrations, includes:

• The CMS must be capable of integrating with and consuming data from Cook County's Electronic Service Bus (ESB) managed by BOT based on Oracle Service Oriented Architecture (SAO) Suite. Data sources currently transferred via the ESB include case and court records from the Clerk of the Circuit Court, custody information from the Cook County Sheriff's Office, and First Appearance Court data. Electronic monitoring data from the Office of the Chief Judge may be transferred in the future. Currently OPD receives nightly data pushes from various justice system sources to its on premise database server.

• The bulk of CMS data is received from the Clerk of the Circuit Court’s Enterprise Justice data platform offered by Tyler Technologies. The CMS must have the capability to both receive data from this system via the ESB or directly interface with Enterprise Justice’s API to receive critical data, including case information, charges, court events, and case participant details (defendant, judges, witnesses, attorneys). While direct API access is not currently allowed, there may be a possibility to directly integrate in the future.

Proposers may offer ideas to securely connect to the Clerk’s data system in a way that respects access control policies and security guidelines -- this may include the creation of a separate staging area.

• Provide a reusable, well-documented code template or documentation—written in an industry-standard programming language such as Python—that demonstrates how to perform a common set of API operations against the proposed CMS. This template or document should be sufficiently generalized and modular to enable OPD’s internal development team to adapt and extend it for future integration efforts.

• Discuss feasibility to integrate with new systems such as eFile Illinois, Oracle E-Business Suite, Microsoft Outlook 365 (email/calendar), evidence management platforms (e.g., Axon Evidence.com), or run ad-hoc imports of CSV files from public sources (e.g., updating AOIC statute tables).

The CMS must support multiple methods for data transmission to ensure seamless integration with our existing systems. Please list all supported methods and resources, including but not limited to:

• Describe the system’s flexibility and ability to support current and future information sharing using standards like Global Justice XML (GJXML), National Information Exchange Model standards (NIEM), or other standard formats.

• Indicate supported methods for data transmission such as webhooks, APIs, ODBC, FTP/SFTP, message queues, object storage links and list preferred software and server components for transmitting data. Detail if such connections require a separate computational environment to enable transmission into the application.

• Identify the available developer resources and documentation, if available, that would enable OPD technical staff to build, manage, and maintain data integrations and other custom capabilities.

• OPD requires full access to the underlying CMS data and must be able to mirror or synchronize the CMS backend to an external OPD managed database for analytics and other related uses.

If the performance of integrations will cause OPD to incur additional cost, the proposer must itemize such costs in Exhibit II Pricing Proposal Form. Detailed data integration requirements are listed in Exhibit I System Requirements Matrix.

2.4.3 Data Ownership, Access, and Retention

All OPD Data submitted to or generated by the System must be and remain the sole and exclusive property of OPD. The selected Proposer will treat OPD Data as Confidential Information. The Proposer is granted a limited, non-exclusive, non-transferable license to use, transmit, process, and display County Data solely for performing its obligations under the Agreement. Proposer is prohibited from disclosing OPD Data to third parties without specific written OPD approval and may assert no lien or right to withhold OPD Data. Proposer must acknowledge and accept these terms or state specific objections. Proposer must provide a brief statement of its data protection practices and responsibilities regarding OPD data use/sale.

Furthermore, the response must state whether Proposer will meet the following data-related system requirements:

• The OPD must always be able to receive OPD data, metadata, subsets thereof, and associated files/attachments from the system in a usable, encrypted format.

• Upon contract termination and OPD request, Proposer shall destroy OPD Data (including backups) according to NIST standards or as directed by the OPD.

• The System must support data retention in a manner that is searchable and compliant with records retention laws and best practices.

• Proposer may not suspend or terminate OPD’s access to OPD Data or the system for breach of contract without providing reasonable notice and opportunity to cure per the OPD’s dispute resolution process.

2.4.4 System/Data Security

Protecting sensitive client data and ensuring compliance with legal/ethical obligations is paramount. The Proposer must describe the security architecture and processes adhering to information reliability and security standards, in particular CJIS requirements. The solution must incorporate comprehensive, multi-layered security features, including:

• Enforced zero trust or least access control privileges with granular, administrator customizable Role-Based Access Control (RBAC).

• Secure authentication with advanced password standards, mandatory Multi-Factor Authentication (MFA) supporting biometric, certificate-based, or out-of-band methods for all access (especially remote). Supports password-less authentication (e.g., FIDO2/WebAuthn) for users on mobile devices or tablets (if applicable).

• Support for SSO integration (as mentioned in 2.3.1). Support for SCIM (System for Cross-domain Identity Management) is desired to allow the County’s central IAM system to automatically create, update, or deactivate CMS accounts in real-time when an employee joins or leaves.

• Session management controls to allow timeouts, account lockouts, and system use notifications.

• Encryption of all data at rest (AES-256 or stronger) and in transit (TLS 1.2 or higher).

Ability for OPD to generate/manage cryptographic keys via a web interface is desired.

• Network security best practices such as Intrusion Detection Systems (IDS) / Intrusion Prevention Systems (IPS) and appropriate firewalls to block unsolicited requests and filter traffic.

• Comprehensive, immutable audit trails logging all data access, record creation/modification/deletion, and key user actions, with robust reporting capabilities.

• Regular vulnerability scanning, penetration testing (results available upon request), and timely patching processes.

• System adhere to CJIS recommendations.

Refer to Exhibit I System Requirements Matrix for system and data security requirements.

2.4.5 Security Compliance and Auditing

The Proposer must demonstrate how the system supports compliance with relevant standards (CJIS Security Policy, NIST SP 800-series, data privacy regulations, professional conduct rules) by providing the following:

• SOC 2 Type II (or SSAE-16) audit reports upon request and permit compliance/security audits by the designated Illinois CJIS Systems Agency (CSA) / FBI.

• Specific care must be taken to secure records related to juveniles, medical history, or mental health details per applicable laws.

• Proposers should indicate what Protected Health Information (PHI), if any and under what conditions, can be stored in a HIPAA-compliant manner in the solution.

Security compliance details are listed in Exhibit I System Requirements Matrix.

2.4.6 Incident Response Plan

Proposer must detail its data security Incident Response Plan (IRP) and processes according to the following conditions:

• IRP must conform to the Illinois Personal Information Protection Act and relevant breach notification laws.

• OPD reserves the right to review, approve, and reasonably modify the Proposer's IRP.

For events within Proposer's control, the Proposer must:

• Immediately notify the OPD of security incidents and data breaches.

• Provide detailed reports on the incident nature and data affected.

• Identify and implement immediate mitigation actions.

• Identify protection measures for affected individuals.

• Provide incident-related communications as directed by the OPD.

Exhibit I System Requirements Matrix reviews IRP requirements.

2.4.7 Business Continuity and Disaster Recovery

Proposers must detail their approach to ensuring system continuity and rapid recovery in the event of a disruption. This section requires on how the proposed solution meets the following requirements:

• Automated backup capabilities (incremental and full) performed without service disruption or performance degradation.

• Proposers of cloud-based solutions may describe how their architecture handles the failure of individual compute instances or virtual machines. Detail the automation used to detect failures and scale to new instances without user intervention or service degradation.

• Indicate ability to conduct an annual, full-scale Disaster Recovery (DR) test. This test must include a complete failover to the DR environment, validation of critical system functionality, and a successful failback to the production environment. Provide a detailed plan for how this will be accomplished.

• Geographically redundant infrastructure meeting Tier III data center standards and resilient to common threats.

• Specify Recovery Time Objectives (RTOs: e.g., intra-day to 48-96 hours) and Recovery Point Objectives (RPOs: e.g., frequency of data backup intervals) the system meets.

State the availability tier met and describe how (uptime percentage, RTO, RPO).

• Implement crisis management, Business Continuity and Disaster Recovery (BC/DR) plans, subject to OPD's reasonable approval. Plans must include support for OPD recovery at an alternate site, backup staff contingencies, and minimum annual testing coordinated with the OPD.

• Detail available performance credits for failure to meet uptime, RTO, and RPO requirements.

Exhibit I System Requirements Matrix lists BC/DR requirements.

2.5 Agreement Terms

This section outlines the contractual requirements, including performance review, payment terms, licensing, intellectual property, transition out processes, and vendor capacity. Proposers must clearly address each aspect to ensure a comprehensive understanding of the contractual obligations and the vendor's ability to deliver and support the proposed solution.

2.5.1 Contract Performance Review and Acceptance

Proposers shall provide a collaborative portal to securely store all documentation related to contract implementation and performance. Proposers should describe all expected contract performance metrics, an approach to collect and transfer all relevant assets to OPD, the required key staff to attend close out session(s) and expected close-out activities. The close-out plan should include at a minimum:

• List of all expected final documentation and respective acceptance criteria/process.

• Close-out dates, locations and required attendance -- including a review session six months after complete implementation.

• Vendor performance review expectations.

• Final project-lessons-learned review expectations.

• Sample documents such as Declaration of Satisfaction Form and project-performance-ranking forms.

• Sample Schedule of Performance Credits for failing to meet SLA and project milestones.

2.5.2 Invoicing and Payments

The OPD requires a fixed-fee. The Proposer must clearly address the following topics relating invoicing and payments (but all pricing itself shall be separately stated in the pricing proposal):

• Milestone-based or deliverable-based payments – the Proposer shall describe how it shall invoice OPD upon OPD’s acceptance of deliverables or project milestones, including:

o If the Proposal calls for completion of deliverables over an extended timeframe, the

Proposer shall clearly explain its corresponding payment expectations.

o If the Proposal calls for tendering deliverables of different types (e.g., hardware components vs. custom coding), the Proposer shall clearly explain its corresponding payment expectations.

• Travel and expenses – The Proposer shall state its willingness to obtain the OPD’s written approval prior to billing the OPD for travel and expenses, as well as its willingness to adhere to the Cook County Travel Policy, see Exhibit XIII.

2.5.3 Licensing, Warranties and other terms and conditions

The Proposer must provide sufficient detail on licensing agreements, warranties, and other terms and conditions associated with the proposal; if Proposer determines any of the following requirements to be inapplicable, Proposer shall state so and shall also state the basis for determining each such requirement to be inapplicable; Proposer must describe the following:

• Attach complete copies of software licensing agreements that the Proposal requires. The Proposer shall also succinctly state: duration of the software licenses (e.g., perpetual), County’s rights under the license (e.g., use, disclosure, sale, etc.), other license restrictions;

• State the length and scope of all warranties that accompany the Proposal’s software.

• Proposer shall agree that the County’s General Conditions Professional Service

Agreement (see Cook County Professional Services Agreement, Exhibit VII) as well as any special conditions to which the County and the Proposer agree, will supersede additional terms and conditions of the Proposer or third parties (see Cook County IT Special Conditions Exhibit IV). If the proposal would require OPD to agree to any of the following, the Proposer shall include complete copies.

2.5.4 Intellectual Property

Proposer deliverables may be considered “works made for hire” or otherwise assigned to/owned by the OPD. State agreement or specific objections regarding IP ownership for each of the following:

• Commercial-off-the-shelf software/components.

• Software/application customizations.

• Database schemas.

• Integrations.

• Workflows.

• Project plans.

• Documentation.

• Training materials.

• Other Deliverables.

2.5.5 Transition Out and Exit Requirements

The Proposal must individually address each the following requirements and provide sufficient detail on whether and how it meets the following requirements:

• The Proposal shall reasonably specify all foreseen exit and transition out requirements and associated costs, including those related to time, documentation, Proposer’s employees and OPD’s employees.

• Upon termination of the contract and OPD request, the Proposer shall destroy OPD Data, including backups and copies thereof, according to NIST standards or as otherwise directed by the OPD (as stated in Section 2.4.3).

2.5.6 Vendor Capacity

Provide information demonstrating the capacity to deliver and support the solution for an organization of OPD's size and complexity:

• Examples of previous CMS implementations with large organizations (preferably public defense agencies).

• Information demonstrating ability to support a long-term partnership, including successful implementation and maintenance.

• Number of current employees, specifically those dedicated to software development/engineering, implementation/training, and ongoing technical support.

3 SCHEDULE

The County anticipates the following Schedule:

RFP Posted to Bonfire Wednesday, January 28, 2026

Pre-Proposal Conference Thursday, February 5, 2026 11:00 a.m. Chicago Local Time

Proposer Inquiry Deadline Wednesday, February 11, 2026 10:00 a.m. Chicago Local Time

Response to Inquiries (tentative) Friday, February 27, 2026

Proposal Due Date Tuesday, March 31, 2026 10:00 a.m. Chicago Local Time

4 INSTRUCTIONS TO PROPOSERS

4.1 Instructions

This RFP provides potential proposers with sufficient information to enable them to prepare and submit proposals. This RFP also contains the instructions governing the submittal of a proposal and the materials to be included therein, including the County requirements, which must be met to be eligible for consideration. All proposals must be complete as to the information requested in this RFP in order to be considered responsive and eligible for award. Proposers providing insufficient details will be deemed non-responsive. The County is not obligated, either to purchase the full services or the products proposed by the proposer, nor to enter into an agreement with any one proposer.

4.2 Availability of Documents

The County will publish its competitive RFP, and other procurement notices, as well as award information at:

Current Contract Opportunities - Cook County (cookcountyil.gov)

Bonfire Vendor Portal - Open Opportunities https://www.cookcountyil.gov/service/current-contract-opportunities https://datacatalog.cookcountyil.gov/Finance-Administration/Procurement-Awarded-Contracts-Amendments/qh8j-6k63/data

Procurement - Awarded Contracts & Amendments | Cook County Open Data (cookcountyil.gov)

Interested proposers should note that, unless otherwise stated in the Bid or RFP documents, there is no charge to obtain a copy of the RFP documents and respond to documents posted for competitive solicitations. Proposers intending to respond to any posted solicitation are encouraged to visit the web site above to ensure that they have received a complete and current set of documents. Some procurement notices may provide a downloadable version of the pertinent documents and any amendments to them, that will be available to proposers after they have completed a simple registration process.

Any proposers receiving a copy of procurement documents from a bid referral service and/or other third party are solely responsible for ensuring that they have received all necessary procurement documentation, including amendments and schedules. The County is not responsible for ensuring that all or any procurement documentation is received by any proposer that is not appropriately registered with the County.

4.3 Non-Mandatory Pre-Proposal Conference

The county will hold a Non-Mandatory Pre-Proposal Conference on the date and…