Attachment L: Testing, Training, & Support Attachment L: Testing, Training, & Support is organized into four sections:

· Section 1: Testing defines Minnesota’s testing framework and required activities across all Comprehensive Child Welfare Information System (CCWIS) design, development, and implementation (DDI) phases, including functional, technical, performance, security, accessibility, data, and User Acceptance Testing (UAT), along with governance, traceability, and defect management expectations. The Responder should submit a proposal that clearly describes a collaborative testing strategy, detailing how the Responder and the State will jointly plan, execute, manage, and validate all testing activities to ensure the CCWIS solution fully meets requirements within a structured, transparent, and large‑scale project environment.

· Section 2: Training describes the training framework and required deliverables for preparing all user groups for the new solution. Responders should outline a scalable, role-based program aligned with the hybrid-agile delivery model, covering training methods, environments, regional delivery, accessibility, and ongoing updates.

· Section 3: Sustainability Support and Warranty outlines expectations for Hypercare (Sustainability Support), Warranty, and Knowledge Transfer. Responders should present an Information Technology Infrastructure Library (ITIL) aligned model covering incident response, change and release processes, monitoring, security, continuity, documentation, knowledge transfer, and multi-agency coordination.

· Section 4: Service Level Agreements (SLAs) provides example SLAs illustrating expectations for availability, severity levels, response and resolution times, monitoring thresholds, maintenance windows, security and disaster recovery requirements, and corrective action procedures. Responders are asked to describe their overall service level approach for CCWIS operations and support, using the illustrative SLAs provided as context, to inform negotiation of final SLAs to be incorporated into the contract.

Section 1: Testing Minnesota’s CCWIS project will follow a comprehensive testing strategy designed to validate both functional and nonfunctional requirements across all delivered capabilities, support federal compliance, and enable a controlled and auditable transition to go-live. Testing activities are integrated with the State’s hybrid-agile delivery approach described in Attachment K: Project Management and Implementation Methodology, ensuring that testing is iterative throughout the Software Development Life Cycle (SDLC) rather than deferred to the end. Attachment J: Testing, Training, and Maintenance and Operations Requirements Traceability Matrix (RTM) includes the testing requirements, which provide end-to-end traceability supporting governance and oversight.

Scope and Governance Scope To support the complexity of Minnesota’s CCWIS solution, testing should span the full development lifecycle and technology stack. Testing should include multiple levels and types, such as unit and component testing; system and system integration testing; interface and data exchange validation; data conversion and reconciliation testing; reporting and federal compliance testing; accessibility conformance to WCAG 2.1 AA; security and privacy validation; performance and scalability testing; mobile and offline capability testing; user acceptance testing; business continuity and disaster recovery testing; and operational readiness and cutover rehearsals.

Each testing level will be governed by defined entry and exit criteria, pass thresholds, and formal approval gates. These controls will be managed through project governance processes and aligned with stage gate expectations to ensure quality, traceability, and readiness for statewide deployment.

Governance Approach Testing activities operate within State project governance and should incorporate Project Management Institute (PMI) aligned processes referenced in Attachment K: Project Management and Implementation Methodology. To maintain traceability and audit readiness, each requirement (nonfunctional and functional) will be linked to corresponding test case(s) and should be readily available for review throughout the development lifecycle. In addition, each test level should include defined entry criteria, exit criteria, pass thresholds, and approval gates. These controls are reviewed through project governance and align with stage gate expectations.

Roles and Responsibilities Upon review and approval of the successful Responders software development life cycle testing activities, the State will participate in readiness reviews and is responsible for conducting UAT. Leading up to UAT, the State will engage in testing activities at the end of each sprint, testing the functional components of the CCWIS solution, as well as testing functionality at the end of the development of a single module.

In addition, the State will align with the selected Independent Validation and Verification (IV&V) vendor to perform formal reviews of testing processes, artifacts, and functionality in increments.

Testing Deliverables Required deliverables include a Master Test Plan, test strategy, test schedule, RTM with test coverage, test cases and data, automated test suites, status reports, defect logs, phase exit reports, and UAT execution records and sign off documentation.

Test Environments, Data, and Tools To support the testing of functionality, while development of other functionality is taking place, a separate environment is needed to support testing activities. At a minimum, a UAT environment is needed to support testing efforts, up to and including full end-to-end UAT. Within the testing environment(s) of the solution, test data should be made available, including synthetic and deidentified datasets. No Personally Identifiable Information (PII) or Protected Health Information (PHI) will be used in any environment other than production. All testing artifacts are stored in the State Project Library, to be established at project inception.

Defect Management, Metrics, and Reporting Defect management includes severity and priority definitions, response and resolution expectations, root cause analysis for critical issues, and reporting aligned with Attachment K: Project Management and Implementation Methodology biweekly and monthly cadences. Metrics include test coverage, pass rates, escaped defects, Mean Time to Detect, Mean Time to Resolve, and automation stability.

Federal and Program Compliance Alignment Testing produces evidence suitable for CCWIS self-assessment and federal review. Reporting validation includes mapping verification, reconciliation reporting, and data lineage documentation for federal reporting.

Section 1 Response Instructions Describe a clear and collaborative approach to testing that outlines how the Responder would work with the State to ensure the CCWIS solution meets all functional, technical, performance, and security requirements. The Testing Approach should demonstrate the Responder’s ability to deliver a structured, transparent, and high-quality testing program within a large and diverse project environment. The CCWIS Testing Approach proposal has a recommended limit of eight (8) pages and should include the following components:

· An overview of the testing methodology and how it aligns with State standards, federal requirements, and best practices.

· A description of the shared testing partnership, including roles, responsibilities, communication protocols, and joint decision making.

· A summary of all testing phases, such as unit, system, integration, accessibility, performance, security, regression, and UAT.

· A plan for managing testing environments and test data, including environment readiness and coordination with State teams.

· A description of tools and automation strategies that support efficient and repeatable testing.

· A streamlined defect management process, including logging, triage, prioritization, resolution, and reporting.

· A method for maintaining traceability between requirements, test cases, and test results.

· A structured approach to support the State in the execution of UAT, including how testers will be trained, enabling effective participation in UAT.

· Criteria for test completion and readiness for deployment, including exit criteria and quality thresholds.

Section 2: Training Minnesota will build on DCYF’s established Social Services Information System (SSIS) training and mentoring foundation to deliver a scalable, role-based training program for the modernized CCWIS solution. The approach aligns with governance and deliverable expectations in Attachment K: Project Management and Implementation Methodology and uses the hybrid-agile delivery model so training content stays synchronized with approved WBS elements. This preserves traceability from requirement to training artifacts and ensures evidence of readiness.

By leveraging DCYF’s SSIS support unit, the statewide Mentor Program, and the Training Academy partnership, the State gains a cohesive CCWIS training program that is regional, accessible, and sustainable. This approach supports consistent adoption at go-live, accelerates new hire onboarding, and strengthens long term proficiency across State and county agencies while meeting governance and audit expectations.

Current Foundation DCYF operates a dedicated SSIS Training and Support unit within the SSIS Business Operations team and partners with the Minnesota Child Welfare Training Academy (CWTA) to deliver SSIS Essentials eLearning and SSIS Child Protection Basics, which cover navigation, core functions, and “life of a case” data entry. SSIS content is also embedded in the CWTA’s New Worker Foundations Training through video modules and on demand vignettes for Intake, Investigation/Assessment, and Case Management, including ICWA data entry topics. DCYF continues to innovate with new mentor orientations, asynchronous modules on SSIS Administration and Data Integrity, a mentor training sandbox, monthly online mentor meetings, and redesigned public SSIS guidance. The longstanding SSIS Mentor Program provides local, frontline support in every county and AICWIT agency, coordinated by a state Mentor Coordinator who maintains curricula, training events, and the statewide mentor roster.

How this Foundation Transitions to CCWIS The State will extend the proven SSIS model to CCWIS by (1) retaining the statewide mentor network as the core “train-the-trainer” and change champion layer, (2) migrate existing SSIS training patterns into CCWIS role-based curricula, and (3) expand embedded eLearning so “just-in-time” guidance is available inside CCWIS. Training artifacts might include instructor guides, learner guides, micro-learnings, FAQs, one-pagers, videos, and in-product help, produced in editable Word and PDF formats. All materials need to meet state and federal accessibility standards.

Delivery Model Consistent with Minnesota’s preference for region-based training and implementation, CCWIS training will follow a train-the-trainer delivery model led by the DDI Vendor. The DDI Vendor will be responsible for developing and delivering comprehensive training to designated trainers to ensure they are fully prepared to support statewide rollout and ongoing workforce enablement across the entire CCWIS solution.

The training approach will use a blended delivery model that includes regional, instructor led sessions to support go-live and initial new hire cohorts; virtual, self-paced learning for reinforcement and refresher training; regional lab environments supported by county mentors; and embedded learning within CCWIS to promote just-in-time learning and sustained proficiency.

CCWIS will be implemented through a phased rollout across five regions over a five‑month period. Training should be delivered in alignment with each regional rollout and will include onsite sessions held at least twice in each of the five State‑identified regional locations, as well as at a central St. Paul location.

Technology and Operations Training In parallel with train-the-trainer training, MNIT and CCWIS operations staff will receive targeted technical curricula on security and access administration, configuration promotion, environment and monitoring practices, data exchanges, and federal reporting, reflecting integration, data quality, and reporting expectations seen in the State’s readiness and operations deliverables.

Governance, Metrics, and Sustainability The Training Plan, schedule, curricula, and completion reporting should follow the State’s project governance and storage requirements. An LMS strategy will track enrollments, completions, assessments, and acknowledgments; if the State adopts an embedded or vendor supported LMS, it will integrate with role assignments and provide region and role reporting. Training content should be updated at the end of each increment, using release notes and demos, so training always reflects the production ready components of the CCWIS solution.

Artificial Intelligence (AI) As Minnesota modernizes training delivery, AI can augment both end-user learning and long-term support. AI enabled help tools can provide contextual, in system guidance that answers user questions, recommends next steps, or links directly to training resources based on the user’s workflow. AI may also assist in generating draft training materials, knowledge base articles, or personalized learning recommendations, provided all outputs are reviewed through human-in-the-loop processes as required by the State’s responsible use guardrails.

Additionally, AI driven analytics can identify common user errors, training gaps, and high volume support themes that inform updates to training content, mentor coaching topics, and change management messaging. This supports continuous improvement and aligns with the CCWIS project’s emphasis on quality, accessibility, and operational readiness.

Section 2 Response Instructions Describe a comprehensive and collaborative approach to training that clearly outlines how the Responder would partner with the State to ensure end users become fully proficient in the new CCWIS system. The training program should utilize a train-the-trainer approach that supports end user training of approximately 6,500 end users. The response should demonstrate high quality, accessible, and role appropriate instruction. The CCWIS Training Approach proposal has a recommended limit of ten (10) pages and should include the following components:

· A detailed description of curricula development that aligns to the State’s defined hybrid-agile methodology, with particular attention placed on the local jurisdiction variability.

· A detailed Train the Trainer program supported by training materials that use a variety of media formats to reach diverse learners.

· A description of how the proposed training approach and CCWIS solution would integrate AI responsibly to support end-user training, embedded learning, and ongoing assistance. The response should explain how AI features will comply with State governance requirements, maintain appropriate human review, protect data security, and improve the efficiency and accuracy of training materials, knowledgebase updates, and in system guidance.

Section 3: Support, Warranty, and Knowledge Transfer The Responder should support a structured transition from implementation to steady state operations through Sustainability Support, Warranty services, and planned Knowledge Transfer activities that equip the State to operate, sustain, and enhance the CCWIS solution. This approach is designed to ensure operational stability following Go Live, supports the State’s phased regional rollout and prepares State staff support teams to assume primary responsibility over time. The approach aligns with State governance and PMO practices, ACF guidance, and public sector delivery best practices, and supports a configurable CCWIS solution with coordinated operations across State, county, Tribal, and partner systems.

Sustainability Support Duration and Objectives The Responder should provide Sustainability Support beginning at initial Go Live and continuing through phased regional implementation and statewide stabilization. The objectives of Sustainability Support are to stabilize each region following Go Live, resolve early defects and configuration issues, support end users during initial adoption, monitor data quality and system performance, and progressively transition operational responsibility to the State.

Phased Post Go Live Support The DDI Vendor should establish and operate a Post Go-Live (PGLS) team for each region as it goes live. For each of the five regions, the PGLS should operate for no less than thirty (30) calendar days following the region’s Go Live. During this time, the Responder should provide elevated functional and technical support focused on issue triage, resolution, user assistance, and operational stabilization for that region.

At the conclusion of each regional PGLS period, operational support for that region should transition to the State support team. The Responder should then shift PGLS operations to the next region entering Go Live. This phased approach should continue until all five regions have completed their regional PGLS period.

Upon completion of the five defined regional rollouts, the Responder should operate a thirty (30) calendar day Post Go Live Support team that supports the full CCWIS user base and validates statewide readiness.

Scope PGLS includes focused monitoring of application performance, interfaces, and data integrity, along with prioritized triage and resolution of issues encountered during early adoption. The Responder should provide dedicated technical and functional resources to remediate defects, address configuration related issues, and support elevated service desk coverage. Critical issues should receive enhanced response coverage to ensure continuity of child welfare operations.

Operational Readiness Validation Throughout PGLS, the State and the Responder should conduct controlled releases and updates as needed to validate deployment procedures, configuration practices, support workflows, with State participation to support ongoing operational activities. These activities confirm readiness to exit elevated support and transition to State administered sustainment.

Reporting and Reviews The Responder should provide regular PGLS reports and facilitate routine review meetings with State leadership. These reviews should focus on regional stabilization progress, issue trends, resolution effectiveness, user impacts, and readiness for transition between regions and into statewide stabilization.

Ongoing Maintenance and Operations (M&O) Following completion of the initial six-month PGLS period, the Responder will continue to provide Ongoing M&O for a period of no less than twelve (12) months. This phase is intended to reinforce system stability, support the State’s transition to primary support responsibility, and maintain continuity of critical CCWIS services as the solution enters steady state. At the conclusion of this period, the State may elect to extend M&O to address evolving operational needs, significant changes, or major updates.

Ongoing Support Focus on continued incident response and issue resolution aligned with agreed severity levels, with heightened attention to critical issues that impact statewide child welfare operations. The Responder should work closely with State support teams to coordinate resolution activities, ensure clear communication, and support consistent service delivery.

Coverage and responsiveness. Severity 1 incidents receive 24x7 coverage. Lower severity events receive business hour support with on call escalation. The Responder should maintain monthly availability of at least 99.9 percent excluding approved maintenance windows.

Reporting Cadence The Responder should deliver monthly SLA and operations reports and conduct monthly reviews.

Patching and upgrades. The Responder should manage patches for all components it delivers. Remediation timelines should meet the following standards: seven calendar days for critical, fourteen for high, and thirty for medium. All changes follow ITIL change controls, pre-deployment testing, rollback plans, and advance notifications. The Responder should coordinate upgrades with the State to prevent service disruption.

Performance Monitoring The Responder should provide application and infrastructure monitoring with dashboards that show response times, transaction latency, API performance, batch durations, availability, utilization, and error rates. Thresholds will align to SLA targets and generate alerts on degradation. Results appear in monthly and quarterly reports.

Security and Compliance The Responder should provide continuous security monitoring that includes intrusion and anomaly detection, log correlation, and vulnerability scanning at least monthly and after major releases. Confirmed security incidents will be reported to the State within required timelines. The Responder should maintain encrypted backups and validate restoration through testing.

Warranty Start and Duration The Warranty period begins after successful statewide deployment and acceptance of contracted scope. The Warranty will extend for eighteen (18) months.

Coverage The Responder should correct defects attributable to delivered configuration, code, or any failure to meet documented requirements at no cost to the State. Fixes will meet SLA timelines by severity. A formal root cause analysis should be delivered for Severity 1 and 2 incidents within five business days.

Quality Controls All remediations should undergo nonproduction validation and regression testing prior to release, with documentation and configuration records updated within ten business days after deployment. Monthly reports should summarize incident trends, availability, performance, patch status, and capacity.

Knowledge Transfer Objectives and Plan Knowledge Transfer is continuous throughout implementation, PGLS, M&O, and the Warranty period to ensure the State is prepared to assume long-term ownership of CCWIS operations. The Responder should deliver a Knowledge Transfer Plan that defines roles, learning objectives, delivery methods, schedules, and success criteria. The plan includes how effectiveness should be measured and how State staff should demonstrate proficiency in operating and enhancing the system.

Methods The Responder should provide role-based training, provide operational walkthroughs for change and release processes, and allow for shadowing by State staff beginning with the initial PGLS period to provide hands on practice of configuration, data exchange management, and reporting. Joint exercises should confirm readiness to manage the backlog, plan releases, and operate the service desk.

Documentation The Responder should maintain an up-to-date repository that includes architecture diagrams, interface specifications, operational runbooks, batch schedules, deployment procedures, and user and system documentation. Documentation should be updated within ten business days of approved changes and will be available to the State at all times.

Exit Transition The Responder should produce an Exit Transition Plan that details activities, roles, milestones, asset inventories, data and tool transfers, contract and third-party considerations, and the criteria for successful transition. The Responder should support the State for a minimum of 180 days or as otherwise defined to complete the transition. The Responder should provide a Final Acceptance document certifying successful Knowledge Transfer and completion of closeout activities.

Configuration First, Minimal Customization To strengthen sustainability and reduce total cost of ownership, the Responder should prioritize configuration over customization. This reduces technical debt, shortens patch and upgrade cycles, and supports faster adoption of federal rule updates. This approach aligns with CCWIS guidance and with the direction that favors modern configurable solutions and cloud operations.

Multi-Agency Coordination The operating model supports collaboration across health and human services partners and other state systems. The Responder should maintain an interface catalog, data exchange runbooks, and a testing cadence that covers both agency-owned and third-party systems. The approach incorporates the bi- directional exchange and interoperability emphasis reflected in ACF CCWIS regulations and guidance, and supports process redesign and interested party validation.

Federal Alignment and Oversight The approach conforms to Children’s Bureau regulations and guidance for CCWIS, including traceability, data quality, exchange standards, and oversight mechanisms. The Responder should support federal reviews, pilots when appropriate, and IV&V activities required by cognizant agencies. The Responder should coordinate with the State to prepare for Children’s Bureau reviews and ensure that documentation and operational evidence meet federal expectations.

Roles and Responsibilities Responder Operates PGLS, M&O, and Warranty, services. Provides 24x7 Severity 1 support, ITIL aligned processes, monitoring, patching, security control operations, reporting, and continuous improvement. Maintains documentation and delivers Knowledge Transfer and Exit Transition.

State Provides governance and decision making, participates in CAB, validates SLAs, approves releases and changes, and co leads production readiness and controlled releases. The State participates directly in operational work so that sustainment responsibilities can be assumed with confidence.

Section 3 Response Instructions Responders should provide a comprehensive Support, Warranty, and Knowledge Transfer Approach that describes how the Responder will partner with the State to support a successful transition from Go Live through phased statewide implementation and into steady state operations. The response should clearly explain how the Responder will stabilize the solution during early adoption, support regional and statewide rollout, and progressively prepare the State to assume primary support responsibility.

The approach has a recommended limit of ten (10) pages and should address the following areas:

· The overall Sustainability Support approach, including how post Go-Live support would be structured to stabilize each region, support users during early adoption, and maintain system reliability during phased implementation.

· The overall approach taken by the Responder related to defects and/or enhancements requests received during train-the-trainer sessions and regional roll-outs.

· The proposed Post Go Live Support (PGLS) model, including how regional PGLS teams would be established, operated, and transitioned to the State across the five regions, as well as how statewide PGLS support would be provided once all regions are live.

· The approach to ongoing M&O following initial statewide stabilization, including how the Responder would continue to support system stability, incident resolution, releases, and State readiness during the transition to steady state.

· The Warranty strategy, including duration, coverage, defect correction approach, and how quality controls and validation would be applied during the Warranty period.

· The approach to monitoring, performance visibility, and reporting used to support system health, issue management, and risk identification throughout M&O and Warranty.

· The approach to patching, configuration updates, and approved system changes, including coordination with the State to ensure controlled deployment and minimal disruption.

· Security, compliance, and data protection practices that support ongoing regulatory alignment, incident response, and system resiliency during support and Warranty periods.

· The Knowledge Transfer approach, including how the Responder would prepare State staff to assume long term ownership through documentation, training, shadowing, and structured transition activities.

Responders should focus on describing how these activities should be delivered and governed rather than providing detailed service level agreements or long-term operational contracts. Materials related to ongoing operations beyond M&O and Warranty are not required in this section.

Section 4: Service Level Agreements for CCWIS Operations and Support These are illustrative examples intended for negotiation and finalization in the resulting CCWIS contract. The SLAs in this section are not prescriptive. Final SLAs are intended to be refined during contract negotiations and incorporated into the Service Catalog and Operations Manual.

Scope and guiding principles The Responder provides ITIL aligned Incident, Problem, Change, Release, and Configuration Management with a customer portal for real time visibility and reporting.

· Operations emphasize configuration first and minimal customization, support cloud deployment, and maintain bi-directional data exchanges across health and human services partners.

· The approach aligns with Minnesota’s CCWIS procurement direction to purchase a cloud-based solution and to integrate business processes for steady state operations.

· Federal alignment is maintained with Children’s Bureau CCWIS regulations and guidance.

Service hours and contacts

· Severity 1 incidents receive 24x7x365 coverage with executive notification during major incidents. Lower severities receive business hour coverage with on call escalation.

· The customer portal displays tickets, outages, SLA metrics, maintenance windows, and exportable reports.

Change and Release Management

· Provider must notify customer of major platform releases, feature deprecations, or behavior changes at least 60 days prior to production rollout.

· Deprecated features must remain operational for a minimum of 12 months after announcement unless a critical security issue necessitates earlier removal. Customer must be provided sandbox or non-production access to preview releases at least 30 days prior to production rollout.

Severity classes and examples The following defines impact and typical examples. Exact wording to be finalized in the SLA catalog.

· Severity 1, Critical: Complete production outage, data corruption risk, or security event with active exploitation, no viable workaround. Example: CCWIS unavailable statewide or core intake functionality down. Targeted for 24x7 response.

· Severity 2, High: Significant degradation or loss of a critical function with a temporary workaround, multiple agencies or regions affected.

· Severity 3, Medium: Function impaired for a subset of users, workaround available, limited scope.

· Severity 4, Low: Cosmetic issues or requests that do not affect service delivery.

Response and resolution targets (illustrative) Targets are examples consistent with the MN matrix requirement for severity‑based timelines. The parties will finalize values during contract negotiations.

Major Incident Management includes executive notification within one hour and a written root cause analysis for Sev 1 and Sev 2 incidents within five business days.

Availability and maintenance windows

· Monthly availability: 99.9 percent minimum for production, excluding approved maintenance windows, measured at the application service level.

· Planned maintenance: Published in advance with agreed windows and rollback plans.

Performance and capacity (illustrative thresholds)

· Page response times for core casework functions within target thresholds under normal load, and transaction latency for APIs within agreed limits. Monitoring includes response time, batch duration, infrastructure utilization, and error rates, with automated alerts on threshold breaches.

· Quarterly reviews include trend analysis and capacity forecasts that inform scaling actions.

Patch and vulnerability management

· Remediate critical vulnerabilities within 7 calendar days, high within 14 days, and medium within 30 days, with emergency protocols and State notifications.

· All patches follow ITIL Change and Release processes with pre deployment testing, maintenance windows, and rollback procedures.

Security operations

· Continuous security monitoring which includes intrusion detection, anomaly detection, log correlation, and event escalation. Confirmed security incidents are reported to the State within required timelines.

· Monthly automated vulnerability scans for application and infrastructure, and after major releases, with results available to the State.

Business continuity and disaster recovery

· RTO not to exceed 8 hours and RPO not to exceed 1 hour for the CCWIS environment. Annual failover and restoration tests are required with documented results.

· Encrypted backups for all data types with annual restoration validation.

Interoperability and data exchanges

· The Responder maintains compatibility for contractor‑provided interfaces and remediates interface defects within SLA timelines.

· SLAs include exchange availability and timeliness targets consistent with Minnesota’s emphasis on bi-directional integration across partner systems.

Service Desk Operations

· Provide ITIL aligned Level 2 and Level 3 support. 24x7x365 on‑call for Severity 1. Always‑available web submission for incidents. Support is provided from within the continental United States.

Documentation and knowledge transfer

· Update operational runbooks, configuration records, and user or system documentation within 10 business days of approved changes.

· Provide ongoing knowledge transfer and shadowing opportunities during major operational events and releases.

Warranty alignment

· During the 18-month Warranty, defects attributable to configuration or code are corrected at no cost and within SLA timelines, with regression testing prior to deployment and documentation updates within ten business days.

· Warranty begins after statewide deployment and successful controlled releases that validate operations and State participation in run activities.

Service credits and corrective actions (illustrative) Service credits are examples, subject to negotiation.

· Availability: If monthly availability falls below 99.9 percent, a 5 percent service credit of the monthly Service fee per 0.1 percentage point below target, capped at 20 percent.

· Severity 1 response breach: More than two Sev 1 breaches in a month triggers an executive review and a corrective action plan within five business days. A 5 percent service credit applies if the plan is not delivered or if repeated non‑compliance occurs in the next month.

· Reporting breach: Failure to deliver required monthly reports within five business days of month end results in a 2 percent service credit and a remediation plan.

Section 4: Response Instructions The Service Level Agreements (SLAs) included in this section are illustrative examples intended to convey the State’s general expectations for operational performance, responsiveness, reliability, and accountability for CCWIS operations and support.

Responders should provide a high‑level description of their proposed service level approach, including how service levels are defined, governed, monitored, and enforced within their operating model. The response should reflect how the Responder typically structures SLAs for large, statewide, mission‑critical systems and any key assumptions or considerations relevant to establishing SLAs for CCWIS. These examples are for contextual purposes only and will not be evaluated as binding commitments.

Policy Template 1

CCWIS RFP: Attachment L 1 image3.png image4.svg image1.png image2.svg