ATTACHMENT A - Terms and Conditions - RFP 758 2400000459 KY Drivers License Information System Modernization.pdf

ATTACHMENT A

Commonwealth of Kentucky Request for Proposal (RFP)

For

KY DRIVERS LICENSE INFORMATION SYSTEM MODERNIZATION

RFP 758 2400000459

Release Date: May 10, 2024 CLOSING DATE AND TIME: June 21, 2024 at 3:30pm ET

Issued by

The Finance and Administration Cabinet

Commonwealth Buyer:

Jenifer Taylor, KCPM

Assistant Director

COMMONWEALTH OF KENTUCKY

FINANCE AND ADMINISTRATION CABINET

Office of Procurement Services 200 Mero Street, 5th Floor

Frankfort, KY 40622

(502) 564-6522

Jenifer.Taylor@ky.gov

TABLE OF CONTENTS

Proposal Submission Checklist Section 1 – Summary Section 2 – Introduction Section 3 – Scope of Work Section 4 – Commonwealth Office of Technology Requirements Section 5 – Procurement Requirements and Instructions Section 6 – Proposal Submission Section 7 – Proposal Evaluation Section 8 – Negotiations Section 9 – Contract Requirements Section 10 – Standard Terms and Conditions Section 11 – Attachments mailto:Jenifer.Taylor@ky.gov

PROPOSAL SUBMISSION CHECKLIST

The vendor MUST include the following with the proposal submission.

If the items highlighted below are not submitted with the proposal submission, the Commonwealth MUST deem the proposal non-responsive and SHALL NOT consider for award.

All other items MUST be submitted prior to award.

*PROPOSED TECHNICAL SOLUTION

*PROPOSED COST SOLUTION

TRANSMITTAL LETTER [see Section 6.7(A)]

REVENUE FORM 10A100 KENTUCKY TAX REGISTRATION APPLICATION IF APPLICABLE

(see Section 6.7 (C)], CERTIFICATE OF AUTHORITY- REGISTRATION WITH SECRETARY OF STATE BY A FOREIGN

ENTITY IF APPLICABLE [see Section 6.7 (D)]

REQUIRED ANNUAL AFFIDAVIT AND OTHER AFFIDAVIT(S)

https://finance.ky.gov/office-of-the-secretary/FinanceForms/Annual%20Required%20Affidavit%20for%20Bidders%20Offerors%20and% 20Contractors.pdf

EEO FORMS IF APPLICABLE [see Section 10.19]

*Please see Attachment E - The Protection of Personal Information Security and Breach Investigation Procedures and Practice Act (KRS 61.931), et seq. effective January 1, 2015.

https://finance.ky.gov/office-of-the-secretary/FinanceForms/Annual%20Required%20Affidavit%20for%20Bidders%20Offerors%20and%20Contractors.pdf https://finance.ky.gov/office-of-the-secretary/FinanceForms/Annual%20Required%20Affidavit%20for%20Bidders%20Offerors%20and%20Contractors.pdf https://finance.ky.gov/office-of-the-secretary/FinanceForms/Annual%20Required%20Affidavit%20for%20Bidders%20Offerors%20and%20Contractors.pdf

SECTION 1 - RFP SUMMARY

1.1 Estimated Schedule of RFP Activities

The following table presents the anticipated schedule for major activities associated with the RFP distribution, proposal submission, proposal evaluation process, and contract award. The Commonwealth reserves the right at its sole discretion to change the Schedule of Activities, including the associated dates and times.

Anticipated Schedule of Activities

Release of RFP

May 10, 2024

Vendors’ Written Questions due by 12:00 PM ET

(SUBMIT QUESTIONS ON ATTACHMENT D-VENDORS’ QUESTION FORM)

May 22, 2024

Commonwealth’s Response to Vendors’ Written Questions

May 31, 2024

Proposals due by 3:30 PM ET

June 21, 2024

1.2 Issuing Office

The Commonwealth of Kentucky, Finance and Administration Cabinet, Office of Procurement Services issues this RFP on behalf of the Kentucky Transportation Cabinet (KYTC). The Finance and Administration Cabinet is the only office authorized to change, modify, amend, alter, or clarify the specifications, terms and conditions of this RFP.

A contract, based on this RFP, may or may not be awarded. Any contract award from this RFP is invalid until properly approved and executed by the Finance and Administration Cabinet.

1.3 Agencies to Be Served

This contract shall be for use by the Kentucky Transportation Cabinet (KYTC). No shipments shall be made except upon receipt by vendor of an official delivery order from the using agency.

Extending the Contract Use to Other Agencies The Office of Procurement Services reserves the right, with the consent of the vendor, to offer the Master Agreement resulting from this solicitation to other state agencies requiring the product(s) or service(s).

SECTION 2 - INTRODUCTION

2.1 Purpose

The purpose of this Request for Proposal (RFP) is to solicit proposals for competitive negotiations pursuant to 200 KAR 5:307.

The Kentucky Drivers License Information System (KDLIS) was developed in 1989-90 to address on-line issuance and record keeping for all driver licensing including the addition of

Commercial Motor Vehicle Safety Act of 1986 (CDL federal mandate). The current legacy mainframe driver license system issues all forms of driver license in the Commonwealth. The current mainframe is table driven and has many interfaces and FTP files exchanging information.

There are many challenges supporting the mainframe system including finding architects, programmers, and the lack of user-friendliness. KYTC often finds delivering modern customer services through the mainframe difficult and time-consuming.

KYTC wants to move to a new modernized driver licensing system called Kentucky’s

Information Network for Driver Licensing (KINDL) to replace the existing mainframe application. This system can offer state of the art customer services, user-friendly interactions, flexibility, and can utilize our core .NET application development team for part of the long-term support. KYTC is looking for a vendor with a proven track record of delivering fully compliant systems on time and on budget.

Any modernized system must keep the state in compliance with all federal mandates affecting driver license issuance, identity management, and control. A key component of the new driver licensing system is timing from start to completion. Due to several factors including resource availability, meeting federal compliance and minimizing the risk of AAMVA’s mainframe support being unavailable in 2025, this moderation effort must be completed within 18 months of contract award.

Any software application on the Commonwealth’s network must comply with Commonwealth of

Technology guidelines. KYTC is a consolidated agency under the Commonwealth Office of

Technology (COT). COT is responsible for infrastructure, network, security, IT policies, and IT procurement for all Executive branch agencies.

2.2 Background

Current Kentucky Driver Licensing System

Issuance of Driver Licenses

The Commonwealth of Kentucky recently transformed its driver licensing organizational structure to regional offices operated by KYTC’s, Department of Vehicle Regulation, Division of

Driver Licensing (DDL). Before this restructuring, driver licenses were issued by locally elected

Circuit Court Clerks in all 120 counties under the Administrative Office of Courts in the Judicial

Branch of government. Driver testing is conducted by Kentucky State Police (KSP) at DDL regional offices.

Currently there are 32 regional offices that issue licenses statewide. See DRIVE.KY.GOV for additional information. See Attachment G for list of issuance sites and volume of issuances.

DDL also offers a “pop-up” service with mobile issuance units in counties without a regional office. The pop-up service allows DDL employees to issue licenses by appointment according to schedule, ex. one day per quarter. These mobile units are also used for disaster relief, conferences, and community events. Idemia provides peripheral equipment (camera, scanner, memo pad, back drop) for issuance and back-office gates to review specific type of issuance before a license is manufactured at a central site and mailed to the driver. There are approximately 240 workstations and 30 mobile units supporting issuance. KY issues approximately 1.4 million licenses annually. There are approximately 245 licenses issued in

KDLIS that have various combinations of endorsements and restrictions.

KY worked with Idemia to develop an intuitive driver license application process integrated with a legacy mainframe application that only asks questions relevant to the data for the individual person, for example ID card applicants are not asked driver licensing questions. Non-US

Citizens and Permanent Residents are not asked if they want to register to vote. Applicants already registered to vote are not asked again. Applicants are asked to validate contact information (email address, phone, etc.). Applicants are asked organ donor questions.

The applicant answers questions and signs the application on a MEMO pad and the application is stored in Idemia back-office. Idemia sends new voter registrations, name changes, new addresses, and new county information to the State Board of Elections. One of the improvements needed is a modernized address verification system that can identify the correct county when sending applications to the State Board of Elections.

Idemia also provides back office and gated processes to review driver applications and documentation before being sent to the factory to be printed and mailed to the driver.

The Kentucky Driver Licensing Information System (KDLIS) is a legacy system with a COBOL, IMS database (nonrelational) running on an IBM mainframe with nightly batch processes for driver record updating (convictions, withdrawals, suspensions, out-of- state violations, AAMVA communication via UNI, etc.) KDLIS uses AAMVA interfaces to ensure driver eligibility. They include Social Security online verification, Commercial Driver License Information System, National Driver Register, and Problem Driver Pointer System. KY currently checks Systematic

Alien Verification for entitlements, passports, and other related Territorial and US identify documents with AAMVA in a gated process through AAMVA. The mainframe prevents some of these interfaces from being integrated into KDLIS due to the antiquated version of the system.

This RFP will require the vendor to develop and implement Real ID requirements – State 2

State Driving History Record, as well as Federal Motor Carrier Safety Administration mandates, Exclusive Electric Exchange, Drug and Alcohol Clearinghouse, and National

Registry of Certified Medical Examiners.

KYTC DDL uses Tyler Technology (Tyler) for a Point of Sale (POS) system for cash, check, and credit card payments for all issuance and non-issuance fees collected. Tyler uses smart codes to deposit fees into the correct state accounts per statute. Tyler supplies card swipes for the regional office and mobile units. There is an interface between Idemia, Tyler, and KDLIS to ensure the correct amount is collected.

Non-issuance or Central Office functions

The Commercial Driver Licensing (CDL) section handles reporting through AAMVA and the interface with other states regarding citations and convictions. They also assist KY regional offices with issuance questions. This section works closely with a KYTC CDL portal where

CDL drivers can submit their applications and other required documents prior to visiting an office. This portal saves both driver and regional office staff time and ensures the visit is successful. It is envisioned that the CDL section will handle State to State (S2S) Driving

History Record (DHR) inquiries because they are familiar with CDLIS procedures.

The Court Records Section handles in-state and out-of-state convictions in the DDL central office. KY receives convictions and failures to appear electronically from the Administrative

Office of Courts (AOC) nightly via a batch process. The Commonwealth’s Courts send convictions to AOC daily. Convictions load to the driver history record and convictions on out-of-state drivers are sent to the driver’s home state. Currently, records are set up for convictions on mandatory violations on out-of-state drivers. Before a withdrawal letter is sent to the driver, it is reviewed for accuracy against the driver history record.

Drivers convicted of DUI may be eligible for an Ignition Interlock. Currently due to mainframe programming restrictions each of these cases are reviewed and applied manually to a driving record by the Court Records and Ignition Interlock sections. This creates the potential for human error or inaccuracy of a KY driving record.

If a KY driver receives a minor traffic conviction, the court could refer the driver to State Traffic

School (STS). They complete the class on-line, and a completion is sent nightly to DDL by the

STS vendor, “Right Lane”. Currently, there are a few classroom-type classes still being conducted. Completions are transferred via ftp to DDL and placed on the driver’s record. The classroom completions are entered manually.

New drivers (under age 18) must attend a four-hour traffic safety class.

The driver must complete an approved Graduated Driver Licensing Class before being issued a full, unrestricted license. New drivers complete the class on-line, and a completion is sent nightly to DDL by GDL vendor “Right-Lane”. There are still some classroom classes, titled “25

Alive” being held. Completions are transferred to DDL and placed on the driver’s record manually Alcohol Treatment Course before reinstatement after a Driving Under the Influence

(DUI) conviction. Currently, completions are entered manually by DDL.

Motorcycle drivers may complete a safety class that will waive the skills test. These completions are reported manually.

DDL provides “jury lists” to AOC via ftp annually or upon request.

KY DDL central site also manages a Medical Review Board to monitor and test at risk drivers.

Drivers recommended to the Medical Review Board may need to have medical exams, take a driving test, have restrictions placed on their license, or their license could be canceled. Most of these functions are a manual process applied to a KY driving record because of mainframe programming restraints.

KY points system monitors drivers accumulating excessive violations in a two-year period.

Drivers having excessive “points” may be placed on probation or suspended subject to an administrative hearing.

KY DDL has a fraud section that reviews facial recognition matches before issuance. If needed, this section would set up a hearing to review possible fraud cases from facial recognition or tips from law enforcement.

A customer call center handles customer questions pertaining to their driving record or other inquiries regarding driver licenses. This section works closely with KYTC Public Affairs and

Tyler Technology on drive.ky.gov to assist customers.

Regional offices balance fees daily. The central office reports fees collected to KYTC

Accounts.

KDLIS - DDL also has an administrative office that on-boards and deactivates accounts, creates reports, and works with programming staff on new laws and requests.

Driver testing is performed by Kentucky State Police, Driver Testing Branch. Recently, the

Driver Testing Branch implemented Idemia’ s auto-test software. This software sends scores electronically to the KDLIS system. This process reduced the paper test history cards and helped the transition from county to regional offices.

Kentucky State Police sends “accident reports” to KDLIS to be placed on driver’s records.

KDLIS receives a file from Vital Statistics to report deceased drivers.

KSP conducts vision screening on new drivers and drivers needing vision tests to be reinstated. Additionally, a new law requires DDL to start voluntary vision screening of drivers renewing their license in July 2024.

KDLIS does share read-only data with several other state agencies and federal agencies on a need-to-know basis.

KDLIS is also used as a source to enable other applications and agencies to verify identity and

SSN information.

KDLIS does flag drivers for various reasons such as school bus drivers, KYTC employees, fraud, etc. If the record is flagged, traffic convictions are reported to the agency sponsoring the flag.

DDL offers a driver monitoring service through Tyler Technologies for businesses.

Tyler Technologies sells Driving History Records online to insurance companies, businesses, and individuals. These records are 3-year public records, or full records (5 years for non CDL).

Tyler Technologies works with DDL and Idemia to allow on-line renewals of driver licenses and

Identification Cards via interfaces to the mainframe system of record.

Tyler Technologies also provides DDL with a website to pay a reinstatement fee online. This updates the mainframe system driver’s record in real time.

Tyler Technologies provides an eligibility letter to young drivers to show they have successfully completed KY’s Graduated Driver Licensing program and are ready for skills testing.

KY schools use an application with Tyler Technology to cancel student license under KY’s “No

Pass No Drive law” via an interface to the mainframe system.

KDLIS receives files from the KY Department of Revenue on delinquent taxpayers and from the KY Division of Child Support for delinquent child support. Upon receipt, KDLIS places a suspension on the driver record.

Kentucky will implement mDL/mID (mobile Driver License/ mobile Identification) in 2024 with

Idemia and TSA using ID fabric. Wallets services will follow.

KDLIS provides daily updates to law enforcement on driver records via real time interface to the mainframe system.

KYTC’s vehicle titling and registration system (KAVIS) uses driver licensing files to identify customers as KAVIS moves to a customer centric date base.

KDLIS stores emergency contact information and mobile phone numbers on a driver’s records.

This information can be entered directly into KDLIS or passed to KDLIS via the Idemia memo pad during application time.

KDLIS captures emails of drivers that allows drivers to receive renewal reminders and other notices through Gov Delivery. It is envisioned this service could notify drivers of other actions like suspensions, failure to pay, and reinstatements.

KDLIS provides a monthly file of new organ donors to KY Organ Donor Affiliates.

KDLIS provides verification services for KY hunting and fishing licenses.

KDLIS produces over 100 different letters and correspondence to drivers.

KDLIS produces a nightly file for back up servers.

Mainframe KYTC Division of Driver License utilizes Commonwealth of Technology mainframe hosted by Kyndryl for mainframe computer data and applications. This application has been frequently modified over decades to meet changing legislative mandates and increasing operational demands. These systems retain much of their original design and technical architecture from 1989. Changes to these legacy systems over many years have resulted in a patchwork of code modules and segregated systems that are increasingly difficult and costly to maintain and update. Even relatively minor system upgrades, whether mandated by law or desirable for better service, are expensive and time-consuming due to the complex reprogramming work that is needed.

Many Driver License computer applications and systems have been extended beyond their expected life. As a result, KYTC DL systems face an ever-increasing risk of failure. KYTC Division of Driver License cannot serve customers well because of the inefficient and time-consuming business processes that are driven by inflexible and obsolete technology.

There are manual paper driven processes in place, which require automation. The overall condition of the current KYTC driver license systems, processes, and procedures necessitate a full modernization, that will automate and simplify current systems and legacy processes and procedures.

SECTION 3 – SCOPE OF WORK

PROPOSALS THAT DO NOT MEET MANDATORY REQUIREMENTS WILL BE DEEMED NON-

RESPONSIVE AND WILL NOT BE CONSIDERED. REFER TO ATTACHMENT F – MANDATORY

REQUIREMENTS CHECKLIST.

Mandatory Requirement means a condition set out in the specifications or statement of work that must be met without exception.”

3.1 Scope of Work/Technical Requirements

Vendor must have experience as the prime vendor and have at least five modernized integrated driver licensing systems in production in AAMVA jurisdictions that took less than 20 months to complete and have been implemented within the past 10 years. These five projects must be a modernization from a mainframe legacy system to a modernized solution. At least three of the five projects must include integrations with Idemia for image capture, back-office, facial recognition, and credential printing. The modernization solution must be successfully deployed, fully functional, within budget and currently in operation.

The Driver Licensing modernization effort must replace KDLIS mainframe functionality, all interfaces mentioned in 2.2 background, all FTP data transfers for system updates, all AAMVA interfaces, idFabric for mID functionality with Idemia, and State 2 State Driving History Record and other FMSCA mandates such as well as Exclusive Electric Exchange, Drug and Alcohol

Clearinghouse, and National Registry of Certified Medical Examiners within 18 months of contract award.

The modernized solution must include all existing federally mandated functionality and any new functionality for the life of the contract. The modernization solution must keep the state in continuous compliance with federal mandates enforced by AAMVA throughout the contract.

The modernized solution must also be updated to comply with state legislative law changes.

KYTC should continue to utilize Idemia for photo capture, document scanning, printing of temporary license document, card printing and mailing, memo pad applications, web service with State Board of Elections for motor voter, back-office functionality including facial recognition, Digital Image Exchange, and mDL/mID.

KYTC should continue to use Tyler Technology for DHR sells, POS at field offices, web services that will interact with a modernized DL system such as DL online renewals, pay a reinstatement fee, graduate driver licensing eligibility letters, emergency contact information, sign-ups for renewal reminders, and appointment scheduling. KYTC should still use Idemia auto test to pass testing information to a modernized system.

The modernized solution should make the issuance workflow efficient. For example, the current issuance process has two web services with Idemia. The modernized version should have one web service. Example of new license process could be as follows 1) process looks to see if record exists (no duplicate records), 2) checks state system (KINDL) and AAMVA for eligibility 3) issuer populates answers to questions until a specific license is identified for issuance, 4) the system should show cost of license prior to issuance, 5) allows for license payment and Trust for Life donations, then 6) commits to driver’s record and reporting, 7) issues temporary license.

The modernized solution and services provided by the vendor should include the following, at minimum:

1. Show driver image and image history on driver file.

2. Integrate digital image exchange and mDL/mID into the workflow.

3. Be flexible allowing additional or new on-line/digital customer services.

4. Be flexible adding new state required functionality, such as a new law or new electronic exchange of information. An example is the manual completion entries described in “Current

KY Driver Licensing” section in 2.2 Background.

5. Capture and report, at a minimum, on each credential issued by office and user.

6. Capture and report on all convictions, withdrawals and administrative entries used in KDLIS.

7. The ability to convert native(state) conviction codes to ACD codes when other states are involved.

8. Integrate with Idemia, Tyler KY, Trust for Life (T4L) on issuance process both in person and online for efficient customer experience.

9. Produce driving history 3 year and full records that can mask certain personal and data entry information. The DHR is distributed by Tyler Technologies (Tyler KY/TKY)

10. Establish a mechanism to provide data in real-time to Tyler KY for Driver Monitoring program.

11. Establish a highly configurable system to minimize support needs, examples are new convictions, suspension times, compliance periods, new fees, etc.

12. Provide a consolidated view of customer’s driving history information, image, and correspondence and provide a clearly defined process for completing customer transactions for the customer’s individual scenario. The consolidated view should integrate all the customer’s interactions with the KYTC Division of Driver License and provide relevant account information to KYTC DDL employees handling a walk-in contact, a telephone call, an e-mail query, or paper-based correspondence or on-line portals.

13. Customer’s credential or driving privileges should be updated automatically depending on information received from the courts, from DMV of one or more other states, from law enforcement, or from other agencies. System should allow both automated and manual capabilities to:

a. Add action to driver record.

b. Suspend credentials.

c. Cancel credential.

d. Transfer entries

e. Deceased

f. Test authorized.

g. Others

14. Provide ability to reinstate credential/driving privileges only after ensuring all sanctions are served and reinstatement fees are paid. The proposed system should correctly calculate the sanctions and fees and adapt to the changes implemented.

15. Provide ability to document and track specific medical conditions related to driver safety in a secure manner for approved roles.

16. Provide capability to generate data and data reports to individuals and organizations as allowed by state and federal law.

17. Provide a correspondence engine to generate a multitude of different correspondence types/styles for various purposes.

18. Provide pre-designed and ad-hoc robust capabilities to provide statistical reports, financial reports, fraud detection reports, auditing reports, logging reports, and other reports as deemed necessary.

19. Provide capability to verify address and county of residence accuracy during transactions.

Address verification should be integrated with internal and external interfaces with web services and data exchanges.

20. Provide data extracts and other custom formatted data to external entities as approved by

KYTC.

21. Driver License Hearings/ Driver License Fraud: Provide capability for the public to request hearings and KYTC DDL the ability to enter hearings and to track hearing requests to include assignment of case to KYTC DDL hearing officer, scheduling of hearing, hearing disposition, and required correspondence to hearing requestor.

22. The modernized solution should replace KYTC CDL portal where CDL drivers submit applications and DOT physical forms prior to arriving at a regional office to get their CDL.

23. Solution should be scalable and have user interface with a common look and feel across the entire solution where possible.

24. Solution should provide updates to the system in real-time as technology and business processes allow.

25. Solution should be browser agnostic, platform, and device independent, where possible.

26. The system should provide robust capabilities to provide auditing and logging of all activities.

27. The solution should include migrating all data and applications off the state’s mainframe.

Solution should also include migration activities (discovery, clean-up, and migration) from legacy data sources.

28. The solution should be available 24 hours per day, 7 days per week, with scheduled time for appropriate maintenance.

29. The solution should ensure all systems and data are backed up and properly protected via physical security and encryption when stored as well as when moved across the network.

30. The solution should provide disaster recovery and business continuity solutions.

31. The solution should provide multiple secure options for exchanging data with internal and external customers.

32. The solution should provide the capability for concurrent and multiple environments, development, test and production which can be configured and loaded to mimic a current production environment.

33. The proposed solution should provide security that complies with all required state and federal security requirements. SOC2 reports are required annually.

34. The solution should have mechanisms in place to prevent the inadvertent disclosure of the individual’s social security number and other personally identifying information to members of the public or to persons other than those persons who, in the performance of their duties and responsibilities, have a lawful and legitimate need to view the individual’s social security number and other personally identifying information.

35. The solution should have a mechanism to mask any data element based on configurable rules and elements.

36. The solution should implement automated software update tools to the most current security updates provided by the software vendor.

37. The solution should provide at minimum 2-factor authentication.

38. The solution should ensure all data is encrypted at rest and in transit.

39. Security testing should be allowed against proposed solution before moving to production and at routine intervals with vendor agreeing to mitigate and resolve identified and reported vulnerabilities.

40. The solution should be hosted in a FedRamp compliant cloud environment.

41. The hosted solution should be scalable, reliable, and secure.

42. The hosted solution should guarantee a minimum uptime of 99.9%.

43. The hosted solution should be capable of scaling seamlessly to accommodate increased user traffic or data volume.

44. The hosted solution should include backup and disaster recovery measures to mitigate the risk of data loss and ensure business continuity.

45. The hosted solution should provide fast and responsive performance to meet the needs of users and applications.

46. The hosted solution should comply with agency data retention requirements.

47. Vendor should provide annual maintenance services necessary to support the KINDL system and hosted environment in conjunction with two KYTC development resources and one KYTC business analyst.

48. The solution may need to supply data to the Transportation Data Warehouse if the need is identified.

49. The solution should allow Driver History Record access to specified agencies to be identified by Dept of Vehicle Regulation. Ex. Administrative office of Courts.

50. The vendor should be responsible for ensuring all DDL staff and regional office staff are trained on the new KINDL system.

51. During the modernization effort, it is expected the vendor determines other needs not documented herein that are required and necessary to provide a fully functioning automated and modernized system. It is expected the vendor performs implementation of other agreed upon needs as necessary to complete the modernization effort.

3.2 Value Added Services

Value-added services, within scope of this RFP, may be added to the contract with the prior approval of the Commonwealth Office of Technology (COT) and the Office of Procurement Services (OPS) Buyer of Record. Upon approval, a formal modification will be made to add the service(s). No work shall begin until a contract modification is completed and notice provided by the OPS Buyer that work may begin.

Vendor may list and describe other solutions for this modernization effort. These will not be scored but could be added later. Examples, could include:

1. Use of kiosks

2. Pre-application submission of identity documents

3. Establishing a driver record for testing

4. Proxy testing of new drivers – written and vision

5. Vision screening at renewal

6. Expanded use of mDLs

7. Other efficiencies or customer services

SECTION 4 – COMMONWEALTH OFFICE OF TECHNOLOGY (COT)

REQUIREMENTS

4.1 Hosting

The Commonwealth is seeking a vendor who can provide a solution per the RFP requirements. If the vendor is proposing a cloud solution, the Commonwealth prefers the proposed cloud solution to be hosted on either AWS or Azure government cloud platforms. If AWS or Azure government cloud is not proposed, the vendor shall propose a commercial Federal Risk and Authorization Management Program (FedRAMP) - certified or. The proposed solution must accommodate the Commonwealth Office of Technology (COT) oversight that includes an isolated tenant, cloud network access (peering connection) and monitoring solutions.

4.2 Commonwealth Information Technology Policies and Standards

A. The vendor and any subcontractors shall be required to adhere to applicable Commonwealth policies and standards.

B. The Commonwealth posts changes to COT Standards and Policies on its Commonwealth Office of Technology - Home - Commonwealth Office of Technology (Kentucky) website.

Vendors and subcontractors shall ensure their solution(s) shall work in concert with all posted changes. Vendors or subcontractors that cannot comply with changes must, within thirty (30) days of the posted change, request written relief with the justification for such relief. The Commonwealth may: 1) deny the request, 2) approve an exception to the policy/standard, or 3) consider scope changes to the contract to accommodate required changes. Vendors or subcontractors that do not provide the response within the thirty (30) day period shall be required to comply within ninety (90) days of the change.

4.3 Compliance with Kentucky Information Technology Standards (KITS)

A. The Kentucky Information Technology Standards (KITS) reflect a set of principles for information, technology, applications, and organization. These standards provide guidelines, policies, directional statements and sets of standards for information technology.

It defines, for the Commonwealth, functional and information needs so that technology choices can be made based on business objectives and service delivery. The vendor shall stay knowledgeable and shall provide a solution that works in concert with these standards for all related work resulting from this RFP.

https://technology.ky.gov/about-the-agency/Pages/kits.aspx

B. The vendor and any subcontractors may be required to submit a technology roadmap for any offered solution. Additional roadmaps will be submitted upon request of the Commonwealth. If required, the roadmap shall include, but is not limited to, planned, scheduled and projected product lifecycle dates and historical release/patch or maintenance dates for the technology. In addition, any guidance on projected release/revision/patch/maintenance schedules would be preferred.

4.4 Compliance with Industry Accepted Reporting Standards Based on Trust Service Principles and Criteria The vendor must employ comprehensive risk and threat management controls based on defined industry standards for service organizations such as ISO AICPA TSP section 100, Trust Services Principles and Criteria. The vendor must annually assert compliance and engage a third-party certification registrar to examine such assertions and controls to provide a Report, such as ISO 9000, ISO 14001, AT101 SOC 2 type 2, on Controls at a Service Organization Relevant to Security, Availability, Processing Integrity, Confidentiality, and Privacy, which contains an opinion on whether the operating controls effectively support the assertions. All such reports, including publicly available reports (i.e. AT 101 SOC 3) shall be made available to the Commonwealth for review.

4.5 System Vulnerability and Security Assessments

The Commonwealth reserves the right to conduct, in collaboration with the vendor, non-invasive vulnerability and security assessments of the software and infrastructure used to provide services prior to implementation and periodically thereafter. Upon completion of these assessments, the Commonwealth will communicate any findings to the vendor for action. Any cost relating to the alleviation of the findings will be the responsibility of the vendor. Mitigations will be subject to re-evaluation after completion. In cases where direct mitigation cannot be achieved, the vendor shall communicate this and work closely with the Commonwealth to https://technology.ky.gov/Pages/index.aspx https://technology.ky.gov/Pages/index.aspx https://technology.ky.gov/about-the-agency/Pages/kits.aspx identify acceptable compensating controls that will reduce risk to an acceptable and agreed upon level. An accredited third-party source may be selected by the vendor to address findings, provided they will acknowledge all cost and provide valid documentation of mitigation strategies in an agreed upon timeframe.

4.6 Privacy Assessments

The Commonwealth reserves the right to conduct privacy assessments of the collection, use, maintenance and sharing of Commonwealth data by any vendor services, software, and infrastructure used to provide services prior to implementation and periodically thereafter.

Upon completion of this assessment, the Commonwealth will communicate any findings to the vendor for action. Any cost relating to the alleviation of the findings will be the responsibility of the vendor. Mitigations will be subject to re-evaluation after completion. In cases where direct mitigation cannot be achieved, the vendor shall communicate this and work closely with the Commonwealth to identify acceptable compensating controls or privacy practices that will reduce risk to an acceptable and agreed upon level. An accredited third-party source may be selected by the vendor to address findings, provided they will acknowledge all cost and provide valid documentation of mitigation strategies in an agreed upon timeframe.

4.7 Privacy, Confidentiality and Ownership of Information

The Commonwealth is the designated owner of all Commonwealth data and shall approve all access to that data. The vendor shall not have ownership of Commonwealth data at any time.

The vendor shall not profit from or share Commonwealth data. The vendor shall be in compliance with privacy policies established by governmental agencies or by state or federal law. Privacy notice statements may be developed and amended from time to time by the Commonwealth and will be appropriately displayed on the Commonwealth portal (Ky.gov).

The vendor should provide sufficient security to protect the Commonwealth and COT data in network transit, storage, and cache. All Commonwealth data, including backups and archives, must be maintained at all times within the contiguous United States. All Commonwealth data, classified as sensitive or higher, as defined in Enterprise Standards, must be encrypted in-transit from vendor’s network and at rest while stored on vendor’s laptops or other portable media devices.

4.8 EU GDPR Compliance

The Commonwealth of Kentucky requires all vendor contracts to comply to the extent applicable with the European Union’s General Data Privacy Regulation [Regulation (EU) 2016/679] (the “GDPR”) when the Commonwealth is a “controller” or “processor” of “personal data” from an individual “data subject” located in the European Union, as those terms are defined in the GDPR. The vendor acknowledges and agrees that it is acting as a “processor” of “personal data” for the Commonwealth under this Agreement and that all applicable requirements of the GDPR are incorporated by reference as material terms of this Agreement.

The vendor represents and warrants that (1) it is aware of and understands its compliance obligations as a “processor” under GDPR; (2) it has adopted a GDPR compliant data privacy compliance policy/program, a summary of which has been provided to the Commonwealth; (3) it will process “personal data” only in accordance with the Commonwealth’s instructions; and

(4) with regard to its obligations under this Agreement, it shall comply with all applicable requirements of the GDPR. Additionally, the vendor may be found liable to the Commonwealth for damages arising from any violation of applicable requirements of GDPR by the vendor in its performance of the services hereunder.

4.9 Data Quality

The vendor shall provide proposed levels of data quality per the following dimensions.

Data Quality is the degree to which data is valid, accurate, complete, unique, timely, consistent with all requirements and business rules, and relevant for a given use. The vendor shall provide data quality definitions and metrics for any data elements. Data has to be of the appropriate quality to address the needs of the Commonwealth of Kentucky. The following dimensions can be used to assess data quality:

• Validity – The data values are in an acceptable format.

• Accuracy – The data attribute is accurate.

• Completeness – There are no null values in a data field.

• Uniqueness – There are no duplicate values in a data field.

• Timeliness – The data attribute represents information that is not out-of-date.

• Consistency – The data attribute is consistent with a business rule that may be based on that attribute itself, or on multiple attributes.

• Adherence to business rules – The data attribute or a combination of data attributes adheres to specified business rules.

4.10 License Agreements

Any proposed software agreements, i.e. license agreement, subscription agreement, end-user license agreement, etc. shall include the following, or similar, language:

“All terms in this agreement/EULA shall be read as applicable only to the extent permitted by Kentucky law and no term in violation of the Kentucky law, inclusive of Kentucky Procurement Law, shall be given effect.”

Any third-party software licenses and cloud resources necessary for the proposed solution may be procured via the Commonwealth’s existing contracts.

4.11 Software Version Requirements

All commercially supported and Commonwealth approved software components such as Operating system (OS), Database software, Application software, Web Server software, Middle Tier software, and other ancillary software must be kept current. In the event that a patch interferes with the solution, the vendor must present a plan for compliance to the Commonwealth outlining the constraints and an appropriate plan of action to bring the solution in to compliance to allow this patch to be applied in the shortest timeframe possible, not to exceed three (3) months, unless otherwise negotiated with the Commonwealth.

4.12 No Surreptitious Code Warranty

The vendor represents and warrants that no copy of licensed software provided to the Commonwealth contains or will contain any Self-Help Code or any Unauthorized Code as defined below. This warranty is referred to in this contract as the "No Surreptitious Code Warranty”.

As used in this contract, "Self-Help Code" means any back door, time bomb, drop-dead device, or other software routine designed to disable a computer program automatically with the passage of time or under the positive control of a person other than the licensee of the software. Self-Help Code does not include Software routines in a computer program, if any, designed to permit an owner of the computer program (or other person acting by authority of the owner) to obtain access to a licensee's computer system(s) (e.g. remote access) for purposes of maintenance or technical support.

As used in this contract, "Unauthorized Code" means any malware designed to permit unauthorized access to disable, erase, or otherwise harm software, equipment, or data; or to perform any other such actions. The term Unauthorized Code does not include Self-Help Code.

In addition, vendor will use up-to-date commercial virus detection software to detect and remove any viruses from any software prior to delivering it to the Commonwealth.

The vendor shall defend the Commonwealth against any claim and indemnify the Commonwealth against any loss or expense arising out of any breach of the No Surreptitious Code Warranty.

4.13 Network Connection Requirements

A. Vendor shall work with COT to establish any network connections. If a secure site-to-site connection is required, the vendor shall employ a secure site-to-site connection procured by the Agency from COT.

B. Vendor shall, at COT’s discretion, provide appropriate access to enable the Commonwealth to perform additional security measures, such as decryption of the network traffic if required for inspection. If the proposed solution does not have the ability to meet this requirement, the vendor must provide an alternative such as audit reporting of this function.

C. Vendor should provide notifications to the Commonwealth Service Desk for unplanned outages within fifteen (15) minutes.

D. Vendor shall notify COT Change Management, through the Commonwealth Services Desk, a minimum of two (2) business days prior to any planned outage.

E. Vendor, in conjunction with the agency, shall provide a Business Impact Assessment (BIA) to appropriately classify all data before production/go-live.

F. Vendor shall include a Web Application Firewall when application houses any data classified as sensitive or higher as defined in KITS standards.

G. Vendor shall provide Recovery Time Objective (RTO) and Recovery Point Objective (RPO) services. Vendor shall provide those services to achieve those SLAs.

4.14 OS Requirements

A. Non-On Prem Solutions

1. No Commonwealth data shall be co-mingled with another entity, without the prior approval of the Commonwealth.

2. Vendor shall provide a solution to move data to the Commonwealth, if required by the Commonwealth.

a. At the end of the contract, the vendor shall provide all agency data in a useable standard data format (such as asci, csv, etc.) that can be converted to a subsequent system. The vendor shall cooperate to this end with the agency and/or a vendor of the agency’s choice, in a timely and efficient manner.

b. Vendor shall address the destruction of Commonwealth data as defined in CIO-092 and provide a certification of the complete and permanent deletion the Commonwealth data.

B. Infrastructure as a Service

1. Vendor shall work with the agency and COT to establish all administrative personnel engagements.

2. Vendor shall meet certification requirements for classification of data being stored.

3. Vendor shall, at COT’s request, provide appropriate access to enable the

Commonwealth to perform additional security measures in compliance with Commonwealth Enterprise Policies, Standards, and/or any Federal or State requirements.

4. Vendor shall provide an Exit Strategy, to move all data to the Commonwealth Data Center, if required by the Commonwealth.

a. At the end of the contract, the vendor shall provide all agency data in a form that can be converted to any subsequent system of the agency’s choice. The vendor shall cooperate to this end with the vendor of the agency’s choice, in a timely and efficient manner.

4.15 Project Governance

Vendor shall work with the agency and appropriate COT offices, when needed, in the cases of data governance, security aspects, hosting, integration, etc., provided that such work does not expand the scope of the services as described in Section 50 of this RFP absent a corresponding change order agreed to by the parties reflecting such expansion.

4.16 Monitoring Requirements for On Premise and Cloud (SaaS)

Vendor shall work with the agency and COT to establish a monitoring solution. Vendors shall provide a view into their environment either by providing a COT and agency approved comprehensive dashboard or allow COT to install their KITS compliant infrastructure and application monitoring solution; to include but not limited to performance and availability. For a Cloud solution, Vendor is expected to provide a monitoring solution.

4.17 Application and Service Requirements

Current Enterprise Applications and Services

1. COT provides a number of Enterprise Shared Services to State agencies. Vendor shall use published IT Applications and Services provided on KITS for: Enterprise Service Bus, Enterprise Content Management, Data Warehousing, Data Analytics and Reporting, Business Intelligence, Web Services, GIS, unless explicitly approved by

COT.

2. Vendor provided dedicated application components (i.e., Application Servers, Databases, etc.) shall comply with KITS or if the technology is not included in KITS, the technology must be accepted by the Commonwealth for inclusion in KITS or granted a written exception to KITS according to COT Information Technology Standards Policy currently CIO-051.

3. Vendor applications must describe in detail all available features and functionality accessible via APIs.

4. All business applications must support the ability to use modern authentication for authentication and authorization. Modern authentication technologies would include SAML 2.0, WSFED, OAuth, or OpenID Connect.

4.18 Project Management Requirements

The COT Division of Governance and Strategy (COT-DGS) is responsible for overseeing large and complex technology projects throughout the Commonwealth. The vendor shall adhere to Project Management standards and reporting requirements established by COT-DGS, which are posted at https://technology.ky.gov/services-and-support/Pages/About-the-Project- Management-Branch.aspx. These include, but are not limited to, having a documented project https://technology.ky.gov/services-and-support/Pages/About-the-Project-Management-Branch.aspx https://technology.ky.gov/services-and-support/Pages/About-the-Project-Management-Branch.aspx schedule, risk management, issue management and reporting project status to the CIO monthly in the format defined by COT-DGS. In addition to the project management standards required by COT-DGS, agency specific requirements may be defined in Section 50 of this

RFP.

4.19 Applicable Security Control Framework Compliance

The vendor must have an awareness and understanding of the NIST Special Publication 800- 53 Security Control Framework and employ safeguards that meet or exceed the moderate level controls as defined within the standard. The vendor must provide sufficient safeguards to provide reasonable protections around the Commonwealth’s data to ensure that the confidentiality, integrity, and availability is maintained at an appropriate level. These include but are not limited to:

• Access Control The vendor must employ policy and process that provide for stringent control to limit physical and logical access to systems that house Commonwealth data, on a need to know basis, provide clear separation of duties, and adheres to least privilege principles.

• Awareness and Training The vendor must provide the appropriate role specific training for staff to…