Att K - AFIS Statement of Work.docx

Attachment K - AFIS Statement of Work Contents

I. EXECUTIVE SUMMARY

a. OVERVIEW Indiana’s Automated Fingerprint Identification System (AFIS) is the State’s critical platform for processing all criminal and applicant fingerprint submissions from 92 county jails, public livescan sites, and courts, while supporting latent print examination and exchanges with the Federal Bureau of Investigation’s (FBI) Next Generation Identification (NGI) system. The State is undertaking a modernization initiative to transition AFIS from aging, on‑premises infrastructure to a secure, scalable solution that maintains all existing workflows and integrations, including the Computerized Criminal History (CCH) system, Multi-Biometric Identification System (MBIS), NGI system, and Indiana State Police (ISP) systems, without disrupting statewide operations.

b. PURPOSE AND BENEFITS The purpose of this engagement is to implement a modern AFIS platform that improves performance, reliability, interoperability, and security while supporting growing biometric data volumes and increasing operational demands. The modernized solution will reduce manual processing, strengthen lights‑out capabilities, enhance exception handling and monitoring, improve data integrity and reporting, and ensure continued compliance with State and Federal security requirements. This initiative is expected to be completed within 18 months, following a structured Hybrid Agile approach with defined deliverables, acceptance criteria, and governance controls to ensure transparency and successful statewide adoption.

II. BACKGROUND AND CURRENT STATE

a. CURRENT DESCRIPTION OVERVIEW The current AFIS environment processes fingerprint-based submissions originating from electronic fingerprint capture sites throughout the State of Indiana and all 92 county jails. AFIS functions as the front door to Indiana’s criminal history process and remains one of the most critical systems within ISP operations. Submissions initiate an automated workflow that culminates in review and processing by fingerprint analysis personnel.

AFIS serves as a central point of integration for multiple criminal justice systems. It receives, validates, and routes National Institute of Standards and Technology (NIST)-formatted transactions; interacts with the State’s CCH system; supports latent print examination and comparison; and exchanges biometric and related data with the FBI’s NGI system. If a latent print does not result in an identification it is registered within AFIS and is automatically searched against all new criminal fingerprint submissions received by AFIS. AFIS also supports interfaces with local MBIS installations and various law enforcement, judicial, and applicant processing entities statewide.

AFIS data includes Criminal Justice Information (CJI) containing Personally Identifiable Information (PII). The current repository contains over 15 million biometric items (fingerprints, palm prints, mugshots, and photographs) and occupies approximately 27 TB of storage, with planned growth to 35 TB over the next five (5) years. In the 2025 reporting year AFIS processed 381,163 total fingerprint submissions across criminal and applicant workflows (Criminal Fingerprints: 185,345 / Applicant Fingerprints: 195,818).

Current AFIS Components and Interfaces The current AFIS environment includes the following primary capabilities, components, and system interfaces required to support statewide biometric processing operations:

· Fingerprinting

· Reporting and Analytics

· User Access / User Interfaces

· Existing interfaces

· CCH

· Card Scanner

· Universal Latent Workstation (ULW) to FBI

· NEC MBIS:

· Indianapolis Metro Police Department (PD)

· South Bend PD

· Fort Wayne PD

· FBI NGI system

· Livescans

· County Jails

· Department of Corrections

· Police Departments

· Courts

· Applicant Livescans

· Gaming Riverboats

· ISP Records Management System (RMS)

These capabilities support AFIS's ongoing role as a statewide biometric processing hub, maintaining essential connections between State, local, and Federal criminal justice partners. The current AFIS environment operates on 26 physical servers that support the full set of statewide processing activities. Additional detail is provided in Attachment N – AFIS Equipment Listing.

b. CURRENT BUSINESS PROCESS FLOWS The existing business process flows for AFIS are documented as follows:

· Workflow Narrative

· Criminal NIST created and sent from livescan to:

· Local AFIS (3 counties)-prints are completed at the local AFIS and then sent to the State AFIS. The processes are completed at the state level as if it came directly from a livescan State AFIS system.

· Data in NIST validated by CCH system:

· Rejected - Response sent back to livescan & CCH system, transaction complete (no further processing is done)

· Accepted - Fingerprints are then processed either through lights out or human intervention through AFIS

· Prints of sufficient quality completed in Ten print process and a search of the latent data base is executed.

· If prior criminal history, arrest information is added to State number in both AFIS archive (data, mugshots & prints) and CCH system (data only), prints sent to NGI system for processing

· If there is no prior history, a State number is created by AFIS with arrest data being added in both AFIS archive (data, mugshots & prints) and CCH system (data only), prints sent to NGI system

· Prints of insufficient quality-Rejected & response sent back to livescan & CCH system, transaction complete (no further processing is done)

AFIS also supports the following additional workflow categories:

· NIST Tenprint Inquiry (TI) Workflow

· Criminal arrest event workflow:

· CAR: Search local, search FBI, retain both local & FBI

· Applicant background check workflows:

· Non-Federal Applicant User Fee (NFUF): Search local, Search FBI, retain local only

· Miscellaneous Applicant Civil (MAP): Search local, Search FBI, retain local only

· State Miscellaneous Applicant Civil (SMAP): Search local and retain local

· Non-NIST TI Workflow

· AFIS Submissions- manual AFIS only identification and registry

· TI Submissions-manual

· Latent Workflows

· Latent Combo

· Latent Palm Combo

· ULW Inbound

· ULW Outbound

· LI-latent manual inquiry

· Mobile 2-Finger Search Workflow (also known as Fast ID)

Review Attachment O - AFIS Workflow to view the current workflow diagram. Within the workflow diagram, please note the following when reviewing:

· Criminal History Record Information System (CHRIS)

· Next Generation Identification (NGI)

· Transaction Control Number (TCN) / Type of Transaction (TOT):

III. SCOPE OF WORK

a. OBJECTIVES OF THE ENGAGEMENT The State will modernize AFIS to ensure reliable statewide operations and long-term sustainability. The objectives are listed below. See Attachment P –Requirements Matrix for additional general and functional requirements.

· Migrate AFIS from aging on premises components to a secure and scalable cloud environment.

· Maintain all existing AFIS workflows during migration. This includes criminal processing, applicant processing, TI processing, latent examination, and ULW exchanges. No interruption to statewide operations will be permitted.

· Improve system performance and reliability. Provide strong monitoring. Provide timely identification of exceptions. Provide consistent resolution of issues.

· Strengthen interoperability with State and Federal criminal justice systems. Interfaces must remain fully supported. This includes CCH system, local MBISs, NGI system, RMS, and other agency systems connected to AFIS.

· Enhance security. Protect biometric and personal information.

· Meet Criminal Justice Information Services (CJIS) and CJI requirements.

· Meet the Indiana Office of Technology (IOT) requirements and supports the Risk and Authorization Management Program (RAMP) policy.

· Reduce manual processing. Enable lights out processing where appropriate. Minimize rejections through improved quality and validation.

· Provide a maintainable and Vendor supported solution. Favor configuration over custom code. Support future enhancements through configuration when possible.

· Define clear governance. Set deliverables. Set acceptance criteria. Set schedule expectations. Set reporting requirements. Enable transparent management of scope and lifecycle activities.

· Support scalability for data growth from the current size to the projected size within five (5) years.

· Enable a smooth transition of operations. Provide training and documentation. Ensure operational readiness. Support handoff to State personnel and future Vendors.

Administrative Module The State’s preference is that the proposed system includes a comprehensive administrative module that allows authorized personnel to manage, monitor, and configure system functionality. The administrative module should be accessible through a secure, role‑based interface. It should support both centralized and distributed administration to align with the State’s operational and governance structure.

b. TECHNICAL REQUIREMENTS The State strongly prefers a cloud-based service offering. Cloud-based service offerings are required to be within a state-owned cloud tenant. However alternative solutions may be considered if they demonstrate significant value. This section provides details on infrastructure and support requirements, outlining the State’s minimum requirements. Review and completed Attachment M – Infrastructure Overview for more detailed information.

The State prefers a solution that meets requirements in the following priority order: out of the box functionality; configuration; or customization only as a last resort. Respondents shall complete Attachment P –Requirements Matrix to indicate whether each requested function is available Out‑of‑the‑Box, can be met through Configuration, requires Customization, is Planned for future release, or is Not Addressed. For all customizations, Respondents must identify whether the enhancement will be incorporated into the core product going forward. For items marked “Not Possible,” Respondents must specify whether future roadmap support is planned.

The State expects the selected vendor to act as a partner to help identify potential business process changes that leverage out of the box or configuration options and reduce or eliminate the need for custom code. To help facilitate this, the selected vendor must document the out of the box and configuration options evaluated before proposing any customization and must demonstrate why configuration cannot satisfy the requirement.

Customizations should be considered only when one or more of these criteria apply: the requirement is necessary to meet a federal reporting requirement or regulation; the requirement is necessary to meet a state law, regulation, or rule; the requirement is necessary to satisfy state security requirements; the requirement is necessary to interface or integrate with state systems; or the requirement will produce a material improvement in service delivery, partner interactions, or utilization of state resources. Material improvements must be documented, justified, and presented to the Project Steering Committee for review.

All customizations require written approval from the Project Steering Committee before work begins. Each customization proposal must include a configuration first analysis, a functional specification, a technical design, an impact analysis addressing maintenance, upgrade compatibility, security, performance, accessibility, total cost of ownership, a test plan, a rollback plan, schedule impact, overall risk analysis, decision regarding adding to the core product functionality and why, and itemized pricing if applicable. Approved customizations must pass the same acceptance tests as core functionality, be upgrade compatible or provide a documented migration path, and meet State security standards. The vendor will deliver source code, developer and user documentation, and a perpetual royalty free license for any custom code. Additionally, the State expects the vendor to consider approved and implemented customizations for incorporation into the selected vendor core solution going forward so that they become out of the box functionality.

High Level Functional Requirements

· Provide native data migration, conversion and optimization to new algorithms, ensuring data integrity.

· Provide seamless communication with local agency MBISs in Indiana, including but limited to: Marion County SO/IMPD, Fort Wayne PD/Allen County and South Bend/St. Joseph County.

· Ability to migrate existing workflows to Cloud hosted system.

· Maintain in-state technicians capable of providing on-site service within SLA determined timeframes.

· FastID, fixed and mobile rapid identification for Public Safety agencies, compatible with existing systems workflows regional agencies in Indianapolis/Marion County, Fort Wayne/Allen County and South Bend/St. Joseph County.

· Support FastID capability for both fixed and mobile rapid identification use cases for public safety agencies across Indiana.

· Maintain all existing AFIS interfaces listed in the Current State section.

· Maintain all legacy interface and data sharing mechanisms for the duration of the contract.

· Maintain any new interfaces or data sharing mechanisms created during the engagement.

· Support all AFIS workflow types beyond NIST, including Non‑NIST, AFIS submissions, TI submissions, latent workflows, and ULW in/out.

· Support all State and Federal reporting requirements, including legacy reports.

· Support the continuation and maintenance of legacy reporting requirements for State and Federal partners.

· Support the creation and maintenance of new reporting requirements throughout the contract term.

· Support the continuation and maintenance of new interface and data sharing requirements.

· Support new and updated interface and data‑sharing requirements over time.

· Support Hybrid Agile SDLC delivery, including required artifacts and proven functionality delivered after each sprint for testing purposes.

· Provide Incident and Problem Management operations aligned to the State’s governance.

· Support statewide Data Warehouse / ODS / Data Mart management for reporting use cases.

· Support the State’s operational data store and data mart needs used for analytical reporting and summary level data access.

High Level Technical Requirements

· The initial database size is estimated to be around 27 TB. The scope is to allow for expandability to approximately 35 TB within five (5) years.

· Support standardized data migration.

· Expectation to integrate with Access Indiana single sign‑on.

· Comply with State Information Security Framework (ISF) beyond RAMP requirements.

· Comply with Assistive Technology accessibility standards in the ISF, as required.

· Comply with State AI Policy and complete required AI Readiness Assessment.

· Require CJIS Security Addendum and annual CJIS awareness training for all personnel.

SDLC and Testing Requirements

· Use a hybrid Agile approach that includes regular and reoccurring demos of the solution delivered to team members that represent the various stakeholders that will be using the solution in some capacity.

· Provide a Master Test Plan.

· Define entry and exit criteria.

· Own unit testing, system testing, performance testing, security testing, integration testing, and support User Acceptance Testing (UAT).

· The State will work with the vendor in supporting the testing of data as part of the conversion and migration to confirm all in-scope data is converted/migrated and with highest quality to meet State expectations.

· Own defect management while producing defect logs and resolution tracking reports and dashboards.

· Provide post migration and post implementation validation.

· If the State decides to add external Testing Services Partner as part of this engagement, the Vendor will copy the Testing Services Partner team member(s) on all appropriate project related communications (emails, meeting invites, collaboration tools, etc.) and will grant access to all documents and deliverables throughout the term of the contract. Vendor will partner with the Testing Services Partner to ensure the solution is delivered to the Agency with the highest quality.

c. DESIRED FUTURE STATE The modernized AFIS will operate in a secure and scalable cloud environment. It will support the full scope of Indiana biometric processing needs. The platform will migrate all existing workflows without disruption. The modernized AFIS will maintain and strengthen interoperability with CCH system, local MBISs, NGI system, and other ISP systems connected to AFIS. The modernization will refine processes, enhance security, improve workflow efficiency, and strengthen interfaces with internal and external systems.

The State expects implementation to be completed within eighteen months. The Vendor will use a hybrid Agile approach with regular demonstrations and defined governance. The project team will include training and knowledge transfer to ensure readiness for operations.

AFIS future workflows that must be supported include criminal arrest events, TI processing, applicant background checks, non NIST TI processing, latent processing, ULW inbound and outbound, and manual inquiries. Mobile 2-finger search may be considered an optional workflow.

Future-State AFIS Workflows The modernized AFIS must support the full set of workflows currently in use across Indiana criminal justice operations. These workflows form the basis for functional and technical requirements and will guide the Vendor’s design and implementation activities. Workflows to be supported include the items listed below.

Criminal and TI Workflows

· NIST TI Workflow

· Criminal Arrest Event Workflow that searches local and Federal repositories and retains both local and FBI records when required Applicant Background Check Workflows

· Non-Federal Applicant User Fee processing

· Miscellaneous Applicant Civil processing

· State Miscellaneous Applicant Civil processing Non NIST and Manual Print Processing

· Non-NIST TI Workflow

· AFIS manual identification submissions

· TI inquiry submissions Latent Workflows

· Latent Combo processing

· Latent Palm Combo processing

· ULW inbound transactions

· ULW outbound transactions

· Latent manual inquiry processing Workflow

· Mobile 2-finger rapid search workflow when requested by the State.

These workflow requirements form the basis for the functional and technical requirements used by the ISP CJIS/AFIS unit and the Vendor’s project team during design and implementation.

d. PROJECT EXCLUSIONS The following items are excluded from this engagement: Services outlined in Quantity Purchase Agreement (QPA) 71766 with IDEMIA (https://www.in.gov/idoa/proc/QPA/71766.pdf.

e. DELIVERABLES AND DEADLINES The Vendor shall provide, at a minimum, the following deliverables according a mutually agreed upon schedule. Each deliverable must include the required compliance evidence and will be subject to formal review and approval by the State. Deliverables should be submitted in both editable and PDF formats and stored in a state-owned repository.

Deliverables with Acceptance Criteria include, but are not limited to:

· Project Kickoff Package Includes kickoff agenda, team organization chart, and communication plan.

Acceptance Criteria: Signed kickoff meeting minutes and list of State participants, and approved organization chart and communication plan.

· Requirements and Needs Assessment Includes a detailed requirements document.

Acceptance Criteria: Formal sign-off of detailed requirements document by the State.

· Requirements Traceability Matrix (RTM) Includes a comprehensive mapping of all functional, technical, and security requirements to design elements, test cases, and deployment activities.

Acceptance Criteria: RTM shows full coverage and traceability and is approved by the State.

· Project Plan and Schedule Includes detailed and integrated tasks owned by the Vendor, the State, and any other vendor that is participating on the project, milestones, resource allocation, and critical path analysis.

Acceptance Criteria: Approved baseline schedule and resource plan.

· Updated Project Schedule (Major Phases) Includes updated schedules at each major phase reflecting approved changes, dependencies, and critical path revisions.

Acceptance Criteria: Updated schedule submitted in approved format and accepted by the State.

· Architecture & Design Package Includes system architecture diagrams, interface specifications, data flow models, and detailed design documentation.

Acceptance Criteria: Design documents are internally consistent, traceable to requirements, peer‑reviewed, and approved by the State.

· Design or Prototype Documentation Includes conceptual models, wireframes, or engineering drawings.

Acceptance Criteria: Demonstration of prototype and documented feedback log.

· Technical or Implementation Specifications Includes configuration details, integration points, and data flows.

Acceptance Criteria: Peer review completed and State approval received.

· Data Conversion & Migration Package Includes an overarching data migration plan, data mapping documents, conversion scripts, transformation rules, audit logs, RACI, and pre‑/post‑migration reconciliation reports.

Acceptance Criteria: Data migration plan approved by the State before any data conversion/migration begins. Reconciliation confirms completeness and accuracy of migrated data and associated documents; approved by the State prior to go‑live.

· Master Test Plan Includes testing strategy, RACI, defect management, environments, entry/exit criteria, reference to test data availability and usage, and coverage of all test cycles including unit, system, performance, security, integration, and UAT.

Acceptance Criteria: Approved by the State before any testing activities begin

· Test Plan and Quality Assurance Results Includes comprehensive test cases using the RTM, pass/fail results, and defect logs.

Acceptance Criteria: All critical, high, and medium defects resolved or approved waiver documented.

· Training and Knowledge Transfer Materials Includes training plan, training guides, training delivery, recorded sessions, and competency sign-off forms.

Acceptance Criteria: Designated users confirm competency.

· Implementation & Deployment Plan Includes go‑live sequence, detailed cutover steps, rollback plan, go/no‑go criteria, and deployment resourcing.

Acceptance Criteria: State approval received prior to implementation

· Deployment / Handover Package Includes operational procedures, deployment checklist, and rollback plan.

Acceptance Criteria: Successful production cutover and verification completed.

· Hypercare Includes heightened support to stabilize the solution post go-live for the period defined in the maintenance and operations section.

Acceptance Criteria: A stable solution in production with all critical and high defects corrected and approved in production.

· Final Report and Closeout Documentation Includes as-built documentation and lessons learned.

Acceptance Criteria: Formal closeout sign-off by the State.

· Warranty and Maintenance Transition Documentation Includes service level agreements, support contacts, and escalation procedures.

Acceptance Criteria: SLA executed and support process tested.

f. PAYMENT MILESTONES Payments under this engagement will be tied to milestone completion and formal acceptance of deliverables by the State. No payments will be issued for initial activities such as project kickoff. Instead, payment will occur after milestone three, covering all work completed up to that point. Subsequent payments will be made upon acceptance of each major deliverable as outlined in the Deliverables and Deadlines Section. Invoices must reference the accepted Milestone number and Deliverable Covered, the date of acceptance, and include the acceptance record and any required compliance evidence.

The State is prohibited from issuing advance payments for services, supplies, materials, or equipment unless expressly authorized under Indiana Code 4-13-2-20. Exceptions may apply for specific categories such as subscriptions, license fees, or insurance premiums, subject to prior approval by the State Budget Agency. For full details, refer to Indiana Code 4-13-2-20.

IV. PROJECT MANAGEMENT

a. PROJECT MANAGEMENT PLAN The Vendor will deliver a Project Management Plan within 4 weeks of the contract start. The Project Management Plan will guide the planning and execution of all activities under this engagement and will be reviewed and approved by the State. The Vendor will maintain the Project Management Plan as a living document and update it when required. The State anticipates assigning an internal Project Manager with whom the Vendor will coordinate all project-related activities.

The Project Management Plan will include, at a minimum, the items listed below.

Project Schedule

· The Vendor will develop a schedule that identifies milestones, tasks, dependencies, and resource assignments. The schedule will include both Vendor activities and any State activities that are required for completion. The Vendor will update the schedule at least weekly and provide visibility into critical path items.

Project Organization and Staffing

· The Vendor will describe the project team structure and roles. This includes key personnel, supporting personnel, reporting relationships, and communication expectations. The plan will describe the Vendor’s staffing approach and the process for replacing team members when necessary.

Requirements and Traceability Approach

· The Vendor will describe the approach for documenting requirements and maintaining traceability through the Requirements Traceability Matrix. The Matrix will track requirements through design, testing, and implementation. The Vendor will maintain the Matrix in the State’s Application Lifecycle Management tools.

Risk and Issue Management

· The Project Management Plan will describe how risks and issues are identified, documented, tracked, and escalated. A risk log and an issue log will be maintained throughout the engagement and updated as part of weekly status reporting.

Communication Plan

· The Vendor will describe how project information will be communicated. The plan will identify communication methods, meeting structure, reporting frequency, and stakeholder communication expectations. This includes weekly status meetings, monthly reviews, and quarterly business reviews.

Quality Management

· The Vendor will describe the quality standards and review processes used to ensure that project deliverables meet State expectations. The plan will describe how deliverables will be reviewed, approved, and updated when required.

Change Control Process

· The Vendor will describe the process for evaluating and approving changes. The process will follow State standards and will require a Change Impact Analysis before changes are approved. Work may not begin until the State provides written approval.

SDLC Overview

· The Vendor will briefly describe how hybrid Agile methods will be applied to design, development, testing, and deployment. More detailed expectations for SDLC and testing appear in project management and testing sections that follow.

Use of State Tools and Repositories

· The Vendor will use State approved tools for documentation, file storage, and artifact management. The State will provide repositories such as Teams, SharePoint, and Application Lifecycle Management tools. The Vendor will follow State naming and version standards.

b. KEY PERSONS The individuals listed in this section are designated as Key Persons for this engagement. These personnel are essential to the success of the project due to their responsibilities, specialized skills, and expected availability. Any substitution of a Key Person must be approved in writing by the State. The State may require a replacement if performance does not meet expectations. Any proposed replacement must meet or exceed the qualifications of the original individual. The State may interview proposed replacements before approval.

Executive Lead The Executive Lead directs overall project oversight and serves as a senior liaison with ISP and other State stakeholders. This individual ensures that the Vendor assigns adequate and qualified staffing to support delivery and addresses issues that require executive attention. The person filling this role will have at least seven (7) years of experience managing or leading projects of similar size and scope. The individual will also have at least three (3) years of experience with the proposed solution or with a system of similar capabilities. Experience implementing the proposed AFIS for at least one client is preferred.

Project Manager The Project Manager coordinates all design, development, and implementation activities. This person serves as the single point of contact for all system related communications between the Vendor and the State. The Project Manager ensures performance standards are met and that deliverables are completed on schedule. This role is full time during design, development, implementation, and stabilization. On-site presence will be provided as required by ISP. The individual who fills this position will have at least seven (7) years of experience managing large-scale information technology projects and at least three (3) years of experience with the proposed solution or a system of similar size. A minimum of five (5) years of experience with system design, development, implementation, maintenance, and operations is expected. Project management certification is preferred. Strong written and verbal communication skills are required.

Lead Solution Architect The Lead Solution Architect guides architectural design activities and ensures alignment of the solution with required technical standards. Responsibilities include leading system and subsystem design, application and data modeling, systems integration activities, and the review of technical documentation. This individual must have at least three (3) years of experience developing web applications and at least three (3) years of experience managing system architecture or system development projects. Experience with the proposed solution or with a system of similar capabilities is preferred. Availability from project start through system go live is required.

Lead Business Architect The Lead Business Architect guides process design and ensures that system capabilities align with business requirements. Responsibilities include documenting business processes, identifying opportunities to reduce customization through configuration, and overseeing development of operational procedures. This individual must have at least three (3) years of experience leading business process design and at least three (3) years of experience managing business system development efforts. Experience with the proposed solution or a system of similar capabilities is preferred. Availability from project start through system go live is required.

Implementation Lead The Implementation Lead is responsible for overseeing implementation activities, tracking performance standards, and addressing escalated issues during deployment. The position is full time through implementation planning and execution. This individual must have at least three (3) years of experience with the proposed solution or a system of similar size and at least two (2) years of experience managing implementation activities for web-based applications. Prior experience implementing the proposed solution for another client is preferred.

Testing Lead The Testing Lead directs all testing activities including planning, documentation, scheduling, and execution. Responsibilities include coordination with all testing participants, oversight of defect tracking, and support for user acceptance testing. This individual ensures compliance with State and Federal testing requirements. Full-time support is required during system testing. The Testing Lead must have at least five (5) years of experience leading testing efforts for complex projects and at least three (3) years of experience performing various testing cycles.

Data Migration Lead The Data Migration Lead oversees data extraction, profiling, mapping, transformation, migration, and validation. This individual ensures migrated data is accurate, complete, and compliant with State requirements. Responsibilities include developing the data migration strategy, ensuring the data migration plan is complete and accurate initially and throughout the project, coordinating data profiling and cleansing, overseeing data mapping and conversion design, directing migration tool and script development, and ensuring overall data quality. The role requires close coordination with State data owners, technical teams, and business stakeholders to resolve data issues and ensure migration deliverables meet standards. This position requires full‑time engagement during data design, migration development, mock conversions, testing, cutover, and Hypercare. The individual will have at least five (5) years of experience leading data migration efforts for large‑scale IT projects and at least three (3) years of experience with data migration for the proposed solution or a similar system. Experience with data profiling, data quality management, and migration automation tools is required. Prior experience completing a full data conversion for the proposed solution for another client is preferred.

Release Manager The Release Manager works with the State to develop the release strategy and manages all planned post implementation releases. Responsibilities include maintaining the release plan and supporting release activities for statewide rollout. This individual will have at least three (3) years of experience with the proposed solution or with a system of similar capabilities and at least two (2) years of release management experience. Experience supporting releases for the proposed solution for other clients is preferred.

c. OTHER PROJECT STAFF The Vendor will assign sufficient staff with the skills and experience required to support successful delivery of the project. These personnel will work under the direction of the Key Persons and will perform activities needed to complete design, development, testing, deployment, and operations support. The Vendor will prepare a Project Resource Staffing Plan that identifies all project staff, their roles and responsibilities, and the qualifications required for each position. The Staffing Plan will also describe the work locations of project personnel and any arrangements that include remote work when approved by the State.

The Vendor will ensure that all project staff meet the minimum qualifications defined by the Vendor’s proposed solution and by the expectations of the State. The Vendor will also ensure that staff receive any required training to perform their duties and maintain compliance with State policies. This includes training needed for quality standards, security requirements, and operational processes.

The State reserves the right to review proposed staff and to request a change if performance does not meet expectations or if the individual’s skills are not aligned with the work required. The State may interview proposed replacements before approval. Any replacement staff must meet or exceed the qualifications of the original assigned individual.

The Vendor will maintain appropriate staffing levels throughout the engagement and will provide timely replacements for staff who depart or are reassigned. The Vendor will follow the timelines established for staff replacement and will ensure that any transition of duties is completed without disruption to ongoing work. Staff providing services under this engagement must be located within the United States unless the State grants written approval for an exception.

The Vendor will ensure that all personnel who require access to Criminal Justice Information meet all State and Federal security requirements. The Vendor will sign the CJIS Security Addendum at the corporate level and each employee who requires unescorted access to Criminal Justice Information will sign the CJIS Security Addendum Certificate. Each employee with access to Criminal Justice Information will also complete annual CJIS Awareness Training through the CJISONLINE portal. Individuals who do not meet these requirements will not be permitted to work on the project.

The Vendor will maintain low turnover among project staff and will describe in the Staffing Plan how workforce stability will be supported. This includes strategies to retain high performing staff and to ensure continuity of knowledge throughout the contract term.

Complete Attachment Q - Resource Usage Matrix to provide the roles and associated number of hours the Respondent expects to commit to the project, which should include both Key Persons and Other Project Staff sections, and the roles and associated number of hours estimated for the State resources. These amounts should be based on the functionality the State desires, included in this RFP.

d. DOCUMENT MANAGEMENT The State will establish a project repository using Microsoft Teams that will serve as the primary location for all documents created or exchanged during the engagement. The Vendor will use the State provided repository for all deliverables, project artifacts, administrative documents, and supporting materials. The Vendor will submit all documents in both editable and PDF formats. Documents will follow the naming conventions and version control standards established by the State.

The Vendor will maintain version history for all project documents. This includes tracking updates, revisions, approvals, and the status of each document. The Vendor will ensure that documents remain organized, current, and easily accessible to State staff at all times. The Vendor will not use external or unapproved repositories for project work. All documentation must reside in the State approved environment.

The preference is for the Vendor to use the State’s Application Lifecycle Management tools such as Azure Dev Ops (ADO) for managing requirements, design artifacts, testing artifacts, and release information. These tools will also be used to track versioning, traceability, approvals, and the lifecycle of design and development tasks. The Vendor will follow all State standards for documentation quality and will ensure that each artifact is complete and consistent with earlier and later project phases.

The Vendor will ensure that all documentation remains accurate throughout the life of the project. When changes to requirements, design, testing, or implementation occur, the Vendor will update the associated documentation in a timely manner. As part of deliverable acceptance, the Vendor will ensure that all documentation associated with that deliverable is complete and stored in the project repository.

e. STATUS UPDATES AND REPORTING The Vendor will provide regular and timely reporting to support transparency, oversight, and decision making throughout the project. Reporting will follow the structure described in this section and will use formats approved by the State. The Vendor will revise reporting templates at the request of the State.

Weekly Status Reports The Vendor will submit a weekly status report that provides a clear view of project progress and any conditions that require State attention. Each weekly status report will include the items listed below.

· A summary of work completed

· A summary of work planned for the next reporting period

· Schedule compliance, including any changes to the critical path

· Status of open incidents, including priority levels and the length of time each incident has remained open

· Status of open defects, including severity levels and the length of time each defect has remained open

· Current risks with mitigation actions

· Current issues and required decisions

· Updates to the project schedule when required

· Open action items

Every-Other-Week Review Meetings The Vendor will schedule and own review meetings with the State every other week. These meetings will provide a consolidated view of project performance, staffing levels, progress against deliverables, and any emerging risks or issues. The Vendor will prepare all necessary materials for these meetings, including sending out an agenda no less than 24 hours prior to the start of the meeting and will update documentation as requested by the State. The Vendor will capture and disseminate meeting minutes no later than 24 hours after the conclusion of the meeting. Meeting frequency may increase as the project approaches implementation.

Quarterly Business Reviews The Vendor will schedule and own quarterly business reviews that summarize work completed during the period, planned work for the upcoming quarter, and performance across key indicators. The Vendor will prepare all necessary materials for these meetings, including sending out an agenda no less than 24 hours prior to the start of the meeting. The review will include analysis of trends in incidents, defects, risks, schedule adherence, and deliverable acceptance. The Vendor will provide updated dashboards or summary materials for these sessions. The Vendor will capture and disseminate meeting minutes no later than 24 hours after the conclusion of the meeting. These meetings may become more frequent as the project approach implementation.

Ad Hoc Meetings The Vendor will attend ad hoc meetings when requested by the State. When on site attendance is required, the State will provide three business days’ notice. When presentation materials are needed, the Vendor will prepare the materials and provide them to the State in advance of the meeting.

Documentation of Reporting and Records All reports, meeting materials, decision logs, dashboards, and supporting documents will be stored in the State designated project repository. The Vendor will maintain version control, ensure information is accurate, and update records in a timely manner.

f. ORGANIZATIONAL CHANGE MANAGEMENT (OCM) The objective of the Organizational Change Management (OCM) activities is to plan, develop, and execute a comprehensive OCM Plan that supports successful implementation and user adoption of the AFIS solution. OCM activities shall include, but are not limited to, conducting an Organizational Change Readiness Assessment, developing and maintaining a Stakeholder Communication Plan, creating Organizational Transition Plans, and facilitating overall stakeholder engagement and “buy‑in.”

OCM efforts will occur within the ISP as well as with external entities whose use of the AFIS solution as mandated by statute. These activities require disciplined planning, coordination, and communication to ensure efficient implementation, operational readiness, and broad user acceptance. OCM tasks are typically integrated into, or aligned with, the overall implementation and must be coordinated with project management, system integration, training, and deployment activities to ensure a seamless transition to the future‑state environment.

V. INDEPENDENT VERIFICATION AND VALIDATION

If the State decides to add Independent Verification & Validation (IV&V) services as part of this Contract, the Vendor will copy the Indiana Department of Administration (IDOA) – IV&V Team member(s) on all project related communications (emails, meeting invites, collaboration tools, etc.) and will grant access to all documents and deliverables throughout the term of the Contract. If IDOA elects to deploy IV&V services in connection with this engagement, the IV&V Team will review and assess all deliverables to determine compliance with the State’s requirements set forth in the Contract including the Statement of Work. For contracts entered into, renewed, or amended after June 30, 2026, the IV&V Team may serve as an approving authority, and if the IV&V Team is the approving authority, no payment shall be issued to the Vendor unless and until IV&V has provided such approval.

VI. COMPLIANCE REQUIREMENTS

a. SECURITY POLICIES AND STANDARDS The State has robust and comprehensive security standards that permeate all levels of the organization. The Indiana Office of Technology (IOT) has been tasked with establishing and maintaining these security standards. The security standards include assessing security risks, developing, and implementing effective security procedures, and monitoring the effectiveness of those procedures. If the proposed solution involves information technology-related products or services, all such products or services are to be compatible with any of the technology standards found in the Statewide IT Policies, Procedures, & Standards (https://www.in.gov/iot/policies-procedures-and-standards/) that are applicable, including the assistive technology standard. The Contractor will be required to sign a Non-Disclosure Agreement (NDA) to access the more sensitive standards and policies. The Contractor should review the Statewide IT Policies, Procedures, & Standards and ensure their proposed solution meets all standards therein.

Any proposed cloud-based service offerings submitted in response to this RFP will need to comply at the time of solution implementation with the IOT RAMP Policy for Cloud Offerings (Policy P.05), which can be found at https://www.in.gov/iot/iot-vendor-engagement/. Prospective vendors should keep all the foregoing in mind as they prepare their proposals and be confident that any proposal they ultimately choose to submit are flexible enough to accommodate commonly accepted industry practices and standards in the typical state government-required RAMP. Please visit the RAMP Cybersecurity Frequently Asked Questions page for additional information.

b. ARTIFICIAL INTELLIGENCE STANDARDS The State has adopted an enterprise-level policy governing the use of Artificial Intelligence (AI) within state government. The State’s AI Policy is issued and monitored by the Office of the Chief Data Officer (OCDO), in cooperation with the Chief Privacy Officer (CPO) and the Management Performance Hub (MPH). As a complement to the AI Policy, the State Agency Artificial Intelligence Systems Standard outlines the rationale behind the AI Readiness Assessment Process required for the implementation or any use of AI by a state agency. That Standard outlines the requirement for the submission of a Readiness Assessment Questionnaire prior to implementation or use of an AI tool or system. Any proposed solution meeting these requirements must support the State’s AI Policy and follow the AI Readiness Assessment Process. See https://www.in.gov/mph/AI/ for more detailed information.

c. ACCESSIBILITY In accordance with Indiana Code § 4-13.1-3 and the IN.gov Accessibility Policy, all systems must comply with the Web Content Accessibility Guidelines (WCAG) 2.1, ensuring that digital services are usable by individuals with disabilities, including those using assistive technologies. Any deviation from these requirements must be approved in writing by IOT in advance.

d. DATA EXCHANGE The State has robust and comprehensive data transmission standards that operate enterprise wide. The IOT established and maintains these standards, which support IOT’s data exchange and API-led strategies for the State. The Vendor’s solution must support the State’s standard API and file transfer methods to facilitate secure data transmission. The State’s standardized data transmission technologies are the MuleSoft API Management and GoAnywhere Managed File Transfer (MFT) services. See https://www.in.gov/iot/policies-procedures-and-standards/applications-standards/.

e. AUTHENTICATION The proposed solution is expected to integrate with Access Indiana.