90DETR-S3968 Requirements Matrix CPC 2026.xlsx
XLSX spreadsheet 39 KB Posted
- Attached to
- Client Payment Card Program
- Solicitation number
- 90DETR-S3968
- Issued by
- Nevada
About this file
This is a Requirements Matrix document for the Client Payment Card Program, a state and local contract opportunity in Nevada. The document outlines the system configuration requirements and implementation approach for the proposed solution. The matrix details specific functional and nonfunctional requirements and indicates whether each requirement can be met through the proposed base system without modifications or requires configuration work. The Q&A period for vendor questions closes on August 25, 2026, at 5:00 PM (PST), with answers to be posted by September 1, 2026, at 5:00 PM (PST). The document serves as a technical evaluation tool to assess vendor proposals against the stated requirements for the payment card program implementation.
The Requirements Matrix includes estimated hours needed to configure the proposed system to meet each requirement, providing a baseline for evaluating implementation costs and timelines. The matrix distinguishes between requirements met out-of-the-box through the vendor's standard offering and those requiring custom configuration, enabling the evaluating agency to understand the scope of customization work necessary. This document functions as a key component in the vendor selection process, allowing the Nevada jurisdiction to assess technical feasibility and relative implementation complexity across competing proposals for the Client Payment Card Program.
View the file
Other files
| File | Type | Posted |
|---|---|---|
| 90DETR-S3968 Standard-form-contract.docx | DOCX document | |
| 90DETR-S3968 Terms-and-conditions-for-services.pdf | ||
| 90DETR-S3968 Insurance Requirements.docx | DOCX document | |
| 90DETR-S3968 RFP.docx | DOCX document | |
| Quote Instructions.pdf | ||
| 90DETR-S3968-reference-questionnaire.docx | DOCX document | |
| 90DETR-S3968-Vendor-Information-Response.pdf | ||
| 90DETR-S3968 Certification-regarding-lobbying.pdf | ||
| 90DETR-S3968 Cost Schedule.xlsx | XLSX spreadsheet |
On GovTribe
Work with this file
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
Requirements
| Met through Configuration | |||
| Requirement Number | General/Functional/Nonfunctional Requirement(s) | Requirement Met |
w/o Change to Proposed Base
| (100% Out of the Box) | Configuration |
| Mechanism | Estimated |
Hours to Configure
| (<5, <20, >20) | Who Makes the Change | |
| (Business, IT or Vendor) | Custom Extension | Client(s) |
Where Req.
| is Operating | Can other Customers Benefit | ||
| Requirement Description | 0% | ||
| 1 | General Functional Requirements | ||
| 1.1 | The vendor shall establish a secure, web‑based portal that provides: | ||
| 1.1.1 | A user interface for authorized DETR staff. | ||
| 1.1.2 | A user interface for the cardholders. | ||
| 1.2 | The system shall provide DETR‑assigned staff and management with access to a web‑based payment card portal that allows them to perform, including but not limited to, the following functions: | ||
| 1.2.1 | Creating an account for the cardholder. | ||
| 1.2.2 | Issuing personalized payment cards to the cardholder. | ||
| 1.2.3 | Loading authorized estimated amounts, specific vendor(s) and item(s) onto the payment card. | ||
| 1.2.4 | Activate cards | ||
| 1.2.5 | Deactivate cards | ||
| 1.2.6 | Place holds | ||
| 1.2.7 | Stop payment | ||
| 1.2.8 | Remove or add funds | ||
| 1.2.9 | Determine the status of the card | ||
| 1.2.10 | Review undeliverable card status | ||
| 1.2.11 | Review card use and transaction history | ||
| 1.2.12 | Review purchases using available item or transaction-level details (such as commodity codes, MIDs, UPCs, or other relevant identifiers) | ||
| 1.2.13 | View vendor and date transaction details | ||
| 1.2.14 | View cardholder account status | ||
| 1.2.15 | View remaining balances | ||
| 1.2.16 | Access other applicable information necessary for program operations as agreed upon between the vendor and DETR. | ||
| 1.3 | The vendor shall authorize funds to the cardholder’s account within the shortest time frame operationally possible. The State requires that funds be made available to clients in the most expeditious manner to ensure timely access to benefits and services. | ||
| 1.4 | The system must prevent transactions for goods or services that are not pre-authorized by DETR. | ||
| 1.5 | The system must include mechanisms to detect, prevent, or flag potentially fraudulent usage. | ||
| 1.6 | The system must include controls to identify and prevent submission of falsified documentation such as invoices, receipts, or provider credentials. | ||
| 1.7 | The system must prohibit cash advances or any method of transferring funds from the card to another account or individual. | ||
| 1.8 | The system must prohibit the cardholder from adding value, depositing funds, or otherwise increasing the balance on the card. | ||
| 1.9 | The system must prohibit the cardholder from obtaining checks or negotiating checks against the card or the underlying account. | ||
| 1.10 | The system must include controls to detect and prevent identity theft, including attempts to use another client's personal information to access benefits. | ||
| 1.11 | The system shall provide configurable controls that allow designated product or merchant attributes to be used to enable or restrict transactions for each issued card. These attributes may include, but are not limited to, merchant category classifications (such as MCCs), merchant identifiers (such as MIDs), and item-level data (such as UPCs or SKUs). The system shall support mapping or associating these attributes as needed to apply filtering rules at the merchant or item level. | ||
| 1.12 | The system must provide notifications within the web‑based portal when replacement cards are returned or determined to be undeliverable. | ||
| 1.13 | The system shall provide the ability to identify, allow, add, modify, restrict, and/or block transaction‑related controls, including but not limited to: | ||
| 1.13.1 | Card transaction limits | ||
| 1.13.2 | Access to financial institutions and points of sale based on defined authorizations | ||
| 1.13.3 | Transactions at specific vendor websites | ||
| 1.13.4 | Blocking the use of funds internationally | ||
| 1.13.5 | Stopping or cancelling pending authorizations, payment cards, and cardholder accounts, and deallocating program funds as needed | ||
| 1.13.6 | The system shall provide the ability to configure and enforce business rules and monitoring tools on payment cards to meet program needs identified by DETR, including but not limited to: | ||
| 1.13.7 | Establishing controls at both the program level and individual card level, not to exceed authorized amounts | ||
| 1.13.8 | Setting the number of card authorizations permitted per designated period (e.g., per day or per twenty‑four (24) hour period) | ||
| 1.13.9 | Implementing program edit checks and controls to mitigate data access and data entry errors related to cardholders and authorized amounts or items | ||
| 1.13.10 | Supporting additional controls as defined and agreed upon between DETR and the vendor | ||
| 1.13.11 | Providing transaction monitoring and audit trail capabilities, including the ability to flag certain purchases and usage patterns | ||
| 1.13.12 | Providing security controls to minimize the risk of unauthorized transactions | ||
| 1.14 | The system shall provide DETR staff with the ability to authorize and allocate funds to payment cards and to initiate card issuance on site. | ||
| 1.14.1 | The vendor shall describe in their proposal how DETR staff will be able to issue payment cards on site, including but not limited to the solution, process, system capabilities, and any equipment required to support on‑site card issuance. | ||
| 1.15 | The system shall support both automatic and manual removal of unused funds from a payment card to the program budget. Automatic removal shall occur if the funds remain unutilized beyond a specified expiration date. | ||
| 1.16 | The system shall provide DETR staff with the ability to access program specific information. This includes program specific funding separation for Workforce and VR. | ||
| 1.17 | The vendor shall provide a secure and reliable method to exchange data with DETR’s case management systems, supporting the transfer of cardholder information, contact information (phone, email, mailing address), authorization, usage, and reconciliation data in formats compatible with DETR systems. The State requires that the vendor’s interfacing solution make funds available to the cardholder in the most expeditious manner and operationally possible, regardless of the integration method used. | ||
| 1.18 | The vendor shall support data exchange with multiple DETR case management systems and ensure that the solution accommodates differing data formats, field requirements, and transmission schedules for each system. | ||
| 1.19 | The vendor shall provide the necessary data mapping, formatting, and transformation capabilities to ensure transmitted data aligns with each DETR case management system’s structure and requirements. | ||
| 1.20 | The vendor shall provide test environments, documentation, and support needed to validate successful data exchange with each case management system throughout implementation and UAT. | ||
| 1.21 | The vendor shall provide a secure, web‑based and/or mobile application portal that allows cardholders to access their account information, including but not limited to: | ||
| 1.21.1 | Review account balances | ||
| 1.21.2 | Review card status: active, inactive or on hold | ||
| 1.21.3 | Review undeliverable card status | ||
| 1.21.4 | Update their address | ||
| 1.21.5 | Update their contact information | ||
| 1.21.6 | Report lost or stolen cards with appropriate security checks. | ||
| 1.21.7 | Request replacement cards | ||
| 2 | Project Management | ||
| 2.1 | The vendor shall provide the Project plan. | ||
| 2.2 | The vendor shall provide the Project timeline. | ||
| 2.3 | The vendor shall provide the Testing plan. | ||
| 2.4 | The vendor shall provide the Training plan. | ||
| 2.5 | The vendor shall provide the Knowledge Transfer plan. | ||
| 2.6 | The vendor shall provide the Business Continuity plan | ||
| 2.7 | The vendor shall provide the Disaster recovery plan. | ||
| 2.8 | The vendor shall provide the Implementation Support plan. | ||
| 2.9 | The vendor shall provide the ongoing Support plan. | ||
| 2.10 | The vendor shall conduct a requirement discovery and documentation. | ||
| 2.11 | The vendor shall facilitate and provide materials for the project kick off meeting. | ||
| 2.12 | The vendor shall provide workflow diagrams/processes, wireframes, mockups and prototypes in close collaboration with PM and SMEs to ensure alignment with project objectives. | ||
| 2.13 | The vendor shall provide wireframes and/or mockups of the web-based portal showing DETR and cardholder user interfaces, to demonstrate understanding of project requirements provided during discovery and to ensure alignment with stakeholder expectations. Wireframes and mockups should include the mobile app to be used by cardholders. | ||
| 2.14 | For UAT, vendor must provide prototype with functionality of the web-based portal, with DETR and cardholder user interfaces, and the mobile app, that meet stakeholder expectations, including testing transaction restrictions for cardholders. Vendor must coordinate UAT of prototype with the PM and provide sufficient notice to representatives of functional departments involved in the project. | ||
| 3 | Payment Card Features and Security | ||
| 3.1 | The vendor shall provide payment cards which prominently displays the DETR logo to DETR clients which are widely accepted by a variety of vendors nationally either in person, online to reimburse clients for personal funds paid for approved goods or services. | ||
| 3.2 | The vendor shall provide a branded VISA or Mastercard, operate via the VISA or Mastercard network, be accepted by any participating merchant, and will allow for PIN-based and signature-based purchases. | ||
| 3.3 | The vendor shall provide a "Regulation E" compliant card. The thickness of the card should be comparable to industry standard for commercial credit cards. The Vendor will provide a sample of the proposed card stock with the response to this proposal. | ||
| 3.4 | The vendor shall ensure the card will operate as a debit card, a stored value card, or another electronic access-type card and must have no line of credit. | ||
| 3.5 | The vendor must not charge cardholders fees or interest in providing this pre-funding service. If there are fees, they will be charged to DETR. | ||
| 3.6 | The vendor shall invoice DETR at the specified time and format as agreed upon for regularly scheduled replenishment of the Program specific funding. | ||
| 3.7 | The vendor shall provide the ability to waive Program monthly fees for payment cards issued to cardholders, at a minimum when no authorized purchases are loaded and/or alternative options to mitigate unnecessary or excessive program costs, as agreed upon by DETR and vendor. | ||
| 3.8 | The vendor shall provide a toll-free method for handling questions concerning charges or returns to include provisions for handling how and when to: | ||
| 3.8.1 | Contact the vendor or DETR to discuss questioned or disputed items. | ||
| 3.8.2 | Credit DETR’s cardholder account, pending resolution of the disputed item. | ||
| 3.8.3 | Process charge-backs or returns for items, resolved in the cardholder and DETR’s favor. | ||
| 3.8.4 | The system shall provide the ability for DETR, or cardholder where defined, to take appropriate actions on cardholder accounts, including: | ||
| 3.8.5 | Making changes in cardholder accounts, including number of transaction limits, purchase restrictions, cardholder name, cardholder address or telephone number and card unique identifier number (PIN). These changes may be made in the Program web-based portal, email, or phone/video with appropriate security checks. | ||
| 3.8.6 | Reporting lost or stolen cards to the vendor through a web-based portal or phone system with appropriate security checks. The vendor must provide for immediate cancellation and emergency issuance of a replacement card. | ||
| 3.8.7 | Established for Program and at individual card levels, not to exceed the authorized amounts. | ||
| 3.8.8 | Program edit checks and controls that help to mitigate data access and data entry errors of cardholders and related authorized amounts and items. | ||
| 3.8.9 | Additional controls as defined and agreed upon between DETR and vendor. | ||
| 3.8.10 | Establish transaction monitoring and audit trail which includes flagging of certain purchases and/or usage. | ||
| 3.8.11 | Security controls which minimize the risk of unauthorized transactions. | ||
| 3.9 | The vendor shall provide the ability to offer virtual payment capability via mobile app. | ||
| 3.10 | The vendor shall not solicit any products or services that will be made available to DETR staff or cardholders. | ||
| 3.11 | The vendor shall ensure DETR, and the cardholders are protected by Europay, Mastercard, and Visa (EMV)cardholder regulations regarding fraud after the vendor is notified of a lost or stolen payment card. | ||
| 3.12 | The vendor shall provide branded payment cards including industry standard EMV enabled security features to reduce potential for fraud (e.g., magnetic strip, chip, secure activation, PIN). | ||
| 3.13 | The vendor shall provide the vendor’s toll-free customer service number printed on the payment card. | ||
| 3.14 | The vendor shall issue the personalized payment card within seven (7) days to clients through U.S. Mail after DETR cardholder account creation in vendor’s web-based portal. | ||
| 3.15 | The vendor shall implement proven procedures to ensure the security and accountability of payment cards delivered through the mail. | ||
| 3.16 | The vendor shall provide the option to issue an anonymous payment card and/or a “virtual payment card” for urgent use to meet client’s needs. | ||
| 3.17 | The vendor shall ensure that each payment card issued has unique card numbers and assigned Personal Identification Number (PIN). | ||
| 3.18 | The vendor shall ensure PIN numbers can only be changed by the cardholder and identified guardians or conservators, if needed. | ||
| 3.19 | The vendor shall provide the ability for the payment card transaction record/receipt to segregate any service fees added to the cost of the goods and/or services authorized for purchase. | ||
| 3.20 | The vendor shall ensure lost, stolen, or demagnetized cards will be replaced by vendor by mail to the cardholder’s address on file within five (5) days. | ||
| 3.21 | The vendor shall provide an accurate and itemized receipt at the time of purchase via print or electronically at the cardholder’s choosing; and, made available electronically for DETR to access for verification of the receipt of goods or services as needed for proof of payment. | ||
| 3.22 | The vendor shall ensure the payment card is packaged with easy-to-follow instructions which include customized information specifically for DETR clients on proper use of services. | ||
| 3.23 | The vendor must describe what security measures will be taken to ensure confidentiality of the Cardholder’s information in their response. | ||
| 4 | Reporting | ||
| 4.1 | The system shall provide access and ability to generate real-time electronic downloadable reports in commonly used file formats through the vendor’s secure web-based portal. Data elements of reports should include but are not limited to all payment cards loaded with date, client name, client participant identification number (PID), funds loaded to the card, and related data fields for tracking and monitoring purposes, as identified and agreed upon by DETR and vendor. | ||
| 4.2 | The system shall maintain the database of cardholder accounts including client, PID number, authorization number, authorized amounts, authorized items, date loaded, purchase amount, retail location, and other related data fields needed for Program services tracking, usage, reconciliation, and reporting. | ||
| 4.3 | The system shall provide reporting matrix to include, but not limited to: | ||
| 4.3.1 | Report timing to be at designated intervals as needed and defined (daily, monthly, quarterly, annual, on demand) for payment cards issued, as agreed upon by DETR and vendor. | ||
| 4.3.2 | Ability to provide detailed, on-demand reporting of card order, activation and funding activity by division, office location, cardholder address update, telephone number update and accessed by the DETR staff member. | ||
| 4.3.3 | The ability for DETR Managers to audit all changes to the cardholder's account. | ||
| 4.4 | The vendor shall provide defined transaction reports to DETR which provide: | ||
| 4.4.1 | Reconciliation and close out authorization | ||
| 4.4.2 | Office location | ||
| 4.4.3 | Purchase using UPC's, SKU's,MCC's or other applicable filters | ||
| 4.4.4 | Authorized DETR staff | ||
| 4.4.5 | Reference number | ||
| 4.4.6 | Card returns due to bad address | ||
| 4.4.7 | Transactions which do not exhaust available funds. | ||
| 4.4.8 | The ability to capture validation information (such as PID number, recipient name) for card activation and related service needs, as applicable. | ||
| 4.4.9 | Develop and provide various reports to accommodate the informational and security needs between DETR and vendor, exportable to commonly used file formats that can facilitate time-defined data exchange. Including, but not limited to: | ||
| 4.4.10 | Electronic reports in specified configuration to include fields suitable for uploading into DETR’s case management system(s). | ||
| 4.4.11 | Cards that are issued to clients statewide, with the listing of newly established DETR cardholder accounts and status, including active, inactive, and closed. | ||
| 4.4.12 | Authorization and usage reports include, but not limited to, cardholder name, PID number, authorization number, authorization codes and amounts, and relevant purchase transaction information, including vendors name, transaction date and time, and other fields as needed for DETR to post expenditures in DETR’s case management system(s). | ||
| 4.4.13 | Cardholder purchase transactions report including but not limited to, DETR cardholder name and account number, charge amounts, purchase amount, vendors name and address, ship-to information, date of purchase, POS, online, and transaction rejections. | ||
| 4.4.14 | Electronic receipt data for merchants who do not have the ability to upload purchases (i.e., handheld POS devices). | ||
| 4.4.15 | Void/Damaged, Lost/Replacement, Undeliverable/Returned card report(s). | ||
| 4.4.16 | Purchase returns, exchanges, credits, disputes, adjustments, duplicates, and other reconciliation transactions. | ||
| 4.4.17 | The vendor shall prepare program services invoices and submit them to DETR at intervals as agreed upon between DETR and vendor. | ||
| 4.4.18 | The vendor shall establish and provide payment card audit trail accountability and reporting tools. | ||
| 4.4.19 | The vendor shall provide real-time, on-demand dashboard reporting with up-to-the-moment data. | ||
| 4.4.20 | The vendor shall provide the ability to create a Program Portal Dashboard and Notification System, with data search capabilities to meet program reporting and monitoring needs. | ||
| 4.4.21 | The vendor shall retain data and reports in compliance with federal and state program reporting requirements. The vendor shall destroy data in compliance with the State of Nevada Data Retention Policy. | ||
| 4.4.22 | At designated timeframes (e.g., daily, weekly, biweekly, or monthly), the vendor will provide a statement or report of card usage/payments with information needed for posting the amounts paid for the goods or services to the DETR's cardholder's record. | ||
| 4.4.23 | The vendor shall provide the ability to generate on-demand and scheduled cardholder account reports with designated information in commonly used file formats for procurement processing, state and federal reporting, and compliance requirements. | ||
| 5 | Training and Implementation | ||
| 5.1 | The Vendor shall provide comprehensive training to Agency staff. Training shall include, but is not limited to, instruction on program features and card benefits; card issuance and loading procedures; cardholder account management processes; and the use of available reports. | ||
| 5.2 | The vendor shall provide appropriate web-based card training and resources to inform cardholders on the proper use of the payment card and available customer service at no cost to the cardholder. | ||
| 5.3 | The vendor shall provide a point-of-contact person who will be available by telephone to answer questions that arise during DETR’s training activities and related implementation. | ||
| 5.4 | The vendor shall provide vendor developed training programs, aids, and user management tools such as videos and online support as available. | ||
| 5.5 | The vendor shall provide account profiles to appropriate DETR staff as authorized by the Program Services Manager to enter information into the vendor Program web-based portal. | ||
| 5.6 | The vendor shall track and monitor training completion by DETR staff. | ||
| 5.7 | The vendor shall provide toll-free phone and web-based Program support to all authorized users. | ||
| 5.8 | The vendor shall ensure the training materials comply with the Americans with Disabilities Act (ADA) and adhere to Web Content Accessibility Guidelines (WCAG) 2.1 at a minimum Level AA. | ||
| 5.9 | The vendor shall provide written training materials for cardholders in English and Spanish to be issued with each card, including how to use the card, process for reporting/replacing lost, stolen, or damaged cards, and a toll-free customer service number. | ||
| 6 | Customer Service and Communications Support | ||
| 6.1 | The vendor shall provide DETR personnel and cardholders with secure web-based portal access and support 24 hours/7 days a week. | ||
| 6.2 | The vendor shall provide technical customer service support via a toll-free telephone number at no charge during normal business hours (e.g., Monday – Friday 7am-6pm PST) to include assistance with DETR services questions and issues, card issues during purchases, reporting of lost, stolen, or inoperative cards, and related needs. | ||
| 6.3 | The vendor shall provide customer service for cardholders phone support 24 hours/7 days a week. | ||
| 6.4 | The Vendor shall provide multilingual customer service support, at a minimum in English and Spanish, across all customer service channels. | ||
| 6.5 | The vendor shall provide TTY capability support or alternative communication services for clients with hearing impairments, including but not limited to Real-Time Text (RTT), Video Relay Services (VRS), text-based messaging, and/or other accessible digital communication methods. The vendor shall respond timely to and resolve all claims, inquiries, and complaints arising from DETR payment card service entries, Program services, and/or cardholder use. | ||
| 6.6 | The vendor shall respond/resolve reported issues as follows: |
•High (loss of system functionality which prevents business operations) - Within 1 hour from report •Medium (loss of system functionality which impedes or limits business operations) - Within 8 hours from report •Low (questions on system functionality and/or corrections to system functionality which do not impede business operations) - Within 24 hours from report.
| 7 | Information Technology and Security |
| 7.1 | The vendor shall comply with and support the Payment Card Industry Data Security Standard (PCI DSS) for the secure storage, transmission, and processing of cardholder data. |
| 7.1.1 | The vendor shall provide either a shared responsibility matrix or assist DETR with building a requirements model to meet and maintain PCI-DSS control compliance as required. |
| 7.2 | The vendor shall provide the ability to enable web-based user controls and provide security access ability to limit access to authorized users requiring individual authentication credentials (username, password) as well as user level permissions to promote and maintain separation of duties including, but not limited to: |
| 7.2.1 | Super-user: Full entry, view, and report capabilities; access and ability to troubleshoot user issue. |
| 7.2.2 | User: Enter data necessary to complete transaction to activate Client accounts, load funds onto the card, execute searches and perform essential related tasks. |
| 7.2.3 | Approver: Approve large dollar or high-risk transactions which exceed the limit established by DETR Manager prior to posting to card. |
| 7.2.4 | Read Only: Review data necessary to validate information for audit purposes. |
| 7.3 | The vendor shall provide support for Multifactor Authentication as allowed by NIST SP 800-63 (specifics to be discussed with vendor during contract negotations) |
| 7.4 | The vendor shall provide support for Single Sign On access for DETR staff. In addition, the vendor should support Federated Identity Management capabilities, both for internal and external users. |
| 7.5 | The vendor shall provide functionality to restrict access for Workforce and VR users and ensure that transactions draw only from their designated program‑specific funds. |
| 7.6 | Cardholder information must be protected and maintained as confidential in full compliance with NRS 603A . The vendor shall not use cardholder information for advertising, marketing, mass mailing, or any other non‑program‑related purposes. |
| 7.7 | The vendor shall comply with NRS 603A by promptly notifying DETR of any affected Nevada resident in the event that unencrypted personal information is, or is reasonably suspected to have been, acquired by an unauthorized party. Such notification must be provided as soon as practicable, consistent with law enforcement requirements and efforts to assess the scope of the breach and restore the integrity of the system. |
| 7.8 | The vendor shall work with DETR's Information Security team to conduct controls and risk assessments. Assessments will be conducted annually. Alternatively, third party risk and/or controls assessments already performed on the vendor's platform can be submitted for this requirement. |
| 7.9 | The vendor shall establish a communication path for DETR's Information Security team to collaborate for risk and controls assessments, and to ensure control compliance with NRS 603A is achieved. |
| 7.10 | The vendor shall provide the ability to provide a Secured File Transfer Protocol (SFTP) site (or alternative secure method) for DETR and the vendor to transfer payment card electronic data files for cardholder account and loading of authorization transactions, as defined and agreed-upon by DETR and vendor. |
| 7.11 | The vendor shall encrypt all data in transit and at rest. |
| 7.12 | The vendor shall develop, implement, and maintain a Business Continuity Plan (BCP) to ensure the continued operation of critical services during emergencies, disruptions, or disasters. |
| 7.13 | The vendor shall develop, implement, and maintain a Disaster Recovery Plan (DRP) to ensure the rapid restoration of critical systems, data, and services in the event of a disaster or major disruption. |
| 7.14 | The vendor shall regularly test, update, and maintain the Business Continuity Plan (BCP) and Disaster Recovery Plan (DRP) throughout the duration of the contract. Testing shall be conducted at least annually. |
| 7.15 | The vendor shall meet National Institute of Standards Technology (NIST) SP800-53 Moderate and applicable state standards. |
| 7.16 | The vendor shall ensure vendor’s web-based portal and mobile app comply with the Americans with Disabilities Act (ADA) and adhere to Web Content Accessibility Guidelines (WCAG) 2.1 at a minimum Level AA. |
| 7.17 | The vendor must support source IP filtering to ensure only connections from the State network are allowed. |
| 7.18 | Please confirm whether your solution supports Mutual TLS (mTLS) for administrative access, including certificate-based client authentication |
| 7.19 | The vendor shall identify and document any additional requirements discovered during the project discovery phase. These requirements shall be communicated to DETR and incorporated into the project scope, as agreed upon by DETR and vendor. |
| 8 | Post Implementation Support |
| 8.1 | The Vendor shall provide comprehensive Post‑Implementation Support for a defined stabilization period following go‑live. At minimum, the Vendor must: |
| 8.1.1 | Provide a dedicated support team with clearly defined roles, responsibilities, and escalation paths. |
| 8.1.2 | Maintain an issue‑tracking process with documented SLAs for triage, response, and resolution. |
| 8.1.3 | Deliver break/fix support, including deployment of hotfixes, patches, and configuration corrections. |
| 8.1.4 | Monitor system performance, integrations, and data quality and promptly resolve identified issues. |
| 8.1.5 | Provide updated documentation, knowledge transfer, and training materials to the Agency’s support staff. |
| 8.1.6 | Support end users through agreed communication channels and provide timely status updates. |
| 8.1.7 | Manage post‑go‑live changes using controlled change‑management procedures. |
| 8.1.8 | Conduct a formal transition to steady‑state operations once stabilization criteria are met. |
File details come from the government source that posted it. Updated .