RFP Document.pdf

UPDATED APRIL 13, 2026 V5.4 1

STATE OF SOUTH DAKOTA

INFORMATION TECHNOLOGY (IT) RFP

Department of Agriculture and Natural Resources Office of Water, Water Quality Program

523 E Capitol Ave, Pierre SD 57501

Develop a Wetland Screening Tool and Associated Products

PROPOSALS ARE DUE NO LATER THAN 11:59 PM CDT July 8, 2026

RFP #: 26RFP19836 STATE POC: Aaron Ward EMAIL: Aaron.Ward@state.sd.us

READ CAREFULLY

FIRM NAME: AUTHORIZED SIGNATURE:

ADDRESS: TYPE OR PRINT NAME:

CITY/STATE: TELEPHONE NO:

ZIP (9 DIGITS): FAX NO:

E-MAIL:

PRIMARY CONTACT INFORMATION

CONTACT NAME:

TELEPHONE NO:

FAX NO: E-MAIL:

UPDATED APRIL 13, 2026 V5.4 2

1 General Information

1.1 Purpose of Request for Proposal (RFP)

The Department of Agriculture and Natural Resources (DANR) is the state agency responsible for the protection of surface water resources including wetlands. DANR collaborates with a number of local and federal partners to accomplish the goal of protecting the surface water resource including the Environmental Protection Agency, United States Army Corps of Engineers, and cities, towns, and counties throughout the state among others. Recent federal level events including the Sackett decision of 2023 and other actions have refocused federal protection of surface waters to only those waters that should truly meet the definition of WOTUS and thus, placed greater responsibility on states to protect their surface water resource. Through robust stakeholder engagement activities conducted in 2025 DANR found the regulated public and other interested parties agreed that an accurate, state-specific web-accessible map detailing the location of wetlands would be useful for numerous industries, local and federal government partners as well as DANR.

1.2 Issuing Office and RFP Reference Number

The Department of Agriculture and Natural Resources, Office of Water, Water Quality Program (“Agency” or “DANR”) is the issuing office for this document and all subsequent addenda relating to it, on behalf of the State of South Dakota (“State”). The reference number for this transaction is RFP#26RFP19836. This reference number must be referred to on all proposals, correspondence, and documentation relating to this RFP. For purposes of this RFP, the State’s centralized IT agency, the Bureau of Information and Technology (“BIT”), must approve all IT related purchases.

1.3 Schedule of Activities (Subject to Change)

All deadlines in the Schedule of Activities are due by 11:59 p.m. CST. The Schedule of Activities for this RFP is as follows:

RFP Publication June 3, 2026 Deadline for Submission of Written Inquiries June 10, 2026 Deadline for Responses to offeror Questions June 17, 2026 Deadline for Proposal Submission July 8, 2026 Evaluation of Proposals to Determine Short List July 10, 2026 Discussions / Technical Review (w/ SDBIT) July 15-22, 2026 Demonstrations and presentations July 23-29, 2026 Anticipated Award Decision/Contract Negotiation July 31, 2026

1.4 Submitting a Proposal

All proposals must be completed and received by the Agency by the date and time indicated in Section 1.3 Schedule of Activities.

Proposals received after the Deadline for Proposal Submission will be late and ineligible for consideration.

All proposals must be signed, in ink or electronically, by a representative of the offeror

UPDATED APRIL 13, 2026 V5.4 3

who is legally authorized to bind the offeror to the proposal. Proposals that are not properly signed may be rejected. The offeror’s proposal must be prepared pursuant to the requirements of Section 6 Proposal Submission Requirements of this RFP.

The State will only accept electronic proposals via email.

Each offeror must provide an electronic version of the proposal. The electronic version should be provided in MS Word or in PDF format to Aaron Ward at aaron.ward@state.sd.us. The email, including attachments, must be limited to 20MB in size.

No proposal will be accepted from, or no contract or purchase order will be awarded to, any person, firm, or corporation that is in arrears upon any obligations to the State of South Dakota, or that otherwise may be deemed irresponsible or unreliable by the State of South Dakota.

1.5 Certification Regarding Debarment, Suspension, Ineligibility, and Voluntary

Exclusion – Lower Tier Covered Transactions

By signing and submitting this proposal, the offeror certifies that neither it nor its principals is presently debarred, suspended, proposed for debarment, declared ineligible, or voluntarily excluded from participation, by any Federal department or agency, from transactions involving the use of Federal funds. Where the offeror is unable to certify to any of the statements in this certification, the offeror shall attach an explanation to its offer.

1.6 Non-Discrimination Statement

The State of South Dakota requires that all contractors, vendors, and suppliers doing business with any State agency, department, or institution, provide a statement of non-discrimination. By signing and submitting their proposal, the offeror certifies they do not discriminate in their employment practices with regard to race, color, creed, religion, age, sex, ancestry, national origin, or disability.

1.7 Restriction of Boycott of Israel

For contractors, vendors, suppliers, or subcontractors with five (5) or more employees who enter into a contract with the State of South Dakota that involves the expenditure of one hundred thousand dollars ($100,000) or more, by submitting a response to this solicitation or agreeing to contract with the State, the bidder or offeror certifies and agrees that the following information is correct:

The bidder or offeror, in preparing its response or offer or in considering proposals submitted from qualified, potential vendors, suppliers, and subcontractors, or in the solicitation, selection, or commercial treatment of any vendor, supplier, or subcontractor, has not refused to transact business activities, has not terminated business activities, and has not taken other similar actions intended to limit its commercial relations, related to the subject matter of the bid or offer, with a person or entity on the basis of Israeli national origin, or residence or incorporation in Israel or its territories, with the specific intent to accomplish a boycott or divestment of Israel in a discriminatory manner. It is understood and agreed that, if this certification is false, such false certification will constitute grounds

UPDATED APRIL 13, 2026 V5.4 4

for the State to reject the bid or response submitted by the bidder or offeror on this project and terminate any contract awarded based on the bid or response. The successful bidder or offeror further agrees to provide immediate written notice to the contracting executive branch agency if during the term of the contract it no longer complies with this certification and agrees such noncompliance may be grounds for contract termination.

1.8 Certification Relating to Prohibited Entity

For contractors, vendors, suppliers, or subcontractors who enter into a contract with the State of South Dakota by submitting a response to this solicitation or agreeing to contract with the State, the bidder or offeror certifies and agrees that the following information is correct:

The bidder or offeror, in preparing its response or offer or in considering proposals submitted from qualified, potential vendors, suppliers, and subcontractors, or in the solicitation, selection, or commercial treatment of any vendor, supplier, or subcontractor, is not a prohibited entity, regardless of its principal place of business, that is ultimately owned or controlled, directly or indirectly, by a foreign national, a foreign parent entity, or foreign government from China, Iran, North Korea, Russia, Cuba, or Venezuela, as defined by South Dakota Codified Law § 5-18A. It is understood and agreed that, if this certification is false, such false certification will constitute grounds for the State to reject the bid or response submitted by the bidder or offeror on this project and terminate any contract awarded based on the bid or response. The successful bidder or offeror further agrees to provide immediate written notice to the contracting executive branch agency if during the term of the contract it no longer complies with this certification and agrees such noncompliance may be grounds for contract termination and would be cause to suspend and debar a business under SDCL § 5-18D-12.

1.9 Modification or Withdrawal of Proposals

Proposals may be modified or withdrawn by the offeror prior to the established due date and time.

No oral, telephonic, telegraphic or facsimile responses or modifications to informal, formal bids, or Request for Proposals will be considered.

1.10 Questions Regarding RFP

All written questions should be sent to: aaron.ward@state.sd.us, only emailed questions will be accepted.

Each offeror may submit questions via email concerning this RFP to obtain clarification of requirements. No questions will be accepted after the date and time indicated in the above schedule of activities. Email questions to the email address listed above with the subject line “RFP#26RFP19836”. The questions and their answers will be sent to all offerors that submitted Letters of Intent, submitted questions, or requested the questions and answers via email before the proposal submittal date and will be sent by the date and time indicated in the above calendar of events. Offeror may not rely on any other statements, either of a written or oral nature, that alter any specification or other term or condition of this RFP that have not originated from the SD RFP Project Contact. Offerors will be notified in the same manner as indicated above regarding any modifications to this

UPDATED APRIL 13, 2026 V5.4 5

RFP. Offerors and their agents may not contact any state employee other than the buyer of record regarding any of these matters during the solicitation and evaluation process.

Inappropriate contacts are grounds for suspension and exclusion from specific procurements.

1.11 Proprietary Information

The proposal of the successful offeror(s) becomes public information. Proprietary information can be protected under limited circumstances such as client lists and non-public financial statements. An entire proposal may not be marked as proprietary.

Offerors must clearly identify in the Executive Summary and mark in the body of the proposal any specific proprietary information they are requesting to be protected. The Executive Summary must contain specific justification explaining why the information is to be protected. Proposals may be reviewed and evaluated by any person at the discretion of the State. All materials submitted become the property of the State of South Dakota and may be returned only at the State's option.

1.12 Length of Contract

The length of the contract will be for a term of two year(s). The State will have the opportunity to renew the contract annually for up to 1 one-year time extension. The extension will not be automatic.

1.13 Governing Law

This RFP will be governed by and construed in accordance with the laws of the State of South Dakota. Any lawsuit pertaining to or affecting this RFP will be venued in Circuit Court, Sixth Judicial Circuit, Hughes County, South Dakota.

1.14 Presentations/Demonstrations

At the State’s discretion, the State may require a presentation or demonstration by an offeror to clarify a proposal. However, the State may award a contract based on the initial proposals received without a presentation or demonstration by the offeror. If presentations or demonstrations are required, they will be scheduled after the submission of proposals. Presentations and demonstrations will be made at the offeror’s expense.

1.15 Discussions

At the State’s discretion, the offeror may or may not be invited to have discussions with the State. The discussions can be before or after the RFP has been submitted.

Discussions will be made at the offeror’s expense.

UPDATED APRIL 13, 2026 V5.4 6

1.16 Technical Review

At the State’s discretion, the State may require a technical review of the offeror based on the offeror’s proposal and response to the Security and Vendor Questionnaire.

1.17 Negotiations

This process is a Request for Proposal/Competitive Negotiation process. Each proposal will be evaluated, and each respondent will be available for negotiation meetings at the State’s request. The State reserves the right to negotiate on any component of every proposal submitted. From the time the proposals are submitted until the formal award of a contract, each proposal is considered a working document and as such, will be kept confidential. The negotiation discussions will also be held as confidential until such time as the award is completed.

1.18 Definitions

Offeror – A company who has submitted a proposal in response to this RFP.

Contractor – An Offeror that has been awarded a contract as a result of this RFP.

State – South Dakota Department of Agriculture and Natural Resources, Office of Water, Water Quality Program (DANR).

2 Standard Contract Terms and Conditions

Any contract or agreement resulting from this RFP will include the State’s standard terms and conditions as shown in Appendix A, the State’s standard Information Technology (“IT”) contract terms listed in Appendix B, and any additional terms and conditions as negotiated by the parties. The offeror must indicate in its response any issues it has with specific contract terms.

If the offeror does not indicate that there is an issue with a specific contract term, then the offeror will be deemed to have accepted the contract terms as written.

3 Scope of Work

3.1 Overview of Wetland Screening Tool Project/Project Goals

Gathering data that is likely to be predictive of wetland location and extent. Gathering examples of wetlands that have been delineated and are likely representative of wetlands in the state of South Dakota. Development of tool(s) to predict the location and extent of wetlands in South Dakota. Utilization of predictive tool(s) to generate a map layer predicting the extent and location of wetlands within the boundaries of the state of South Dakota. Training of DANR employees on the map, including any limitations and assumptions. Collaborating with DANR on any necessary revisions or improvements to the model/mapping product. Development of a website that displays the map layer developed as well as other useful layers and user interface. Development of products to assist the public in use of the website. Provision of training to program partners, remotely or in person, on the use of the website. Improvement of the website/map/model based on user feedback.

UPDATED APRIL 13, 2026 V5.4 7

GOAL 1: DANR would like to have a web-accessible map on a publicly facing website showing the location and extent of all wetlands throughout the entire state of South Dakota. DANR would like to provide training to program partners on the use of this map once it is developed. The selected vendor will be available, in person or virtually, to present at partner meetings when this training is provided. This map should clearly show areas that are likely wetlands as that term is defined in ARSD 74:51:01:01(47). This map will include additional layers that may enhance usability for industry and other program partners. Those additional layers are discussed further in the RFP. This map is not expected to be a definitive wetland “jurisdictional determination” and should clearly state it is not a final regulatory decision.

GOAL 2: This map should inform industry, local government and other entities involved in land use or the protection of the surface water resource. This map should assist those entities in the avoidance and minimization of impacts to wetlands by displaying likely location and extent of wetlands based on predictive or other forms of modeling as well as other techniques (aerial photo interpretation etc). This map should also provide the public with information as to where wetlands likely were or could be constructed (restoration potential) to better inform construction of wetland mitigation sites.

GOAL 3: The accomplishment of this goal will produce a high-resolution geospatial layer depicting the locations and extent of wetlands to quantify wetlands within the state and better understand their connectivity to other surface water features (streams, lakes, ponds, etc) both perennial and intermittent. The creation of this map should produce data that is available to DANR staff for future projects such as flood and water quality modeling.

GOAL 4: The accomplishment of this goal will result in the development of predictive models to better identify locations and extent of wetlands in each of the Level III ecoregions throughout all of South Dakota. Alternative approaches are allowable based on demonstrated ability to achieve the goal of this RFP.

GOAL 5: The accomplishment of this goal will likely use machine learning and provide for on-going “training” of the model to ensure continued, enhanced accuracy. It is further anticipated that the creation of this map and website will use high-resolution LiDAR data, satellite imagery, and other remotely sensed data. Discuss data sources to be gathered or used and verify Offeror currently has access to this data. Discuss shareability/accessibility of this data to DANR for future uses.

3.2 High-level Requirements and Business Process

GOAL 1: Wetland map on publicly accessible website. The end product will be a web-accessible map; providing numerous user selectable base maps, depicting location and extent of wetlands derived from predictive modeling, aerial photo interpretation, and include an NWI wetland layer. Important layers that should be included in the finished product include: county, HUC-8 watershed, EPA Level III ecoregions, streams/rivers layer, topography, federal lands, Indian reservations. Important base maps: aerial imagery, USGS 7.5min quad or other topo layer, terrain map, road map. Other layers that may inform decision making and research are also welcome.

The user interface should have search feature to allow searching by latitude/longitude in decimal degrees, town name, place name, street address, and township/section/range.

UPDATED APRIL 13, 2026 V5.4 8

The user interface should include other useful features such as report generation or map printing capability.

Resident privacy is of some concern as is compatibility with the Federal Geographic Data Committee Wetland Mapping Standard (FGDC-STD-015-2009). The Offeror should discuss the selected resolution chosen for basemaps and wetland layer and how that resolution meets the objective of displaying wetland location and extent while also providing reasonable privacy to residents.

GOAL 2: Restoration potential. The products developed during this project should be useful to wetland mitigation bankers and others involved in the work of wetland protection and restoration for identifying sites suitable for wetland creation.

GOAL 3: High-resolution geospatial layer of wetlands, streams and lakes/ponds useful for future projects (flood or water quality modeling). Data used in any modeling should be accessible to DANR for future work (water quality and flood modeling).

GOAL 4: Development of predictive model taking into consideration Level III ecoregions.

Discuss what model or process will be used. Proposal should include costs for validation, training, maintenance including updates based off additional site specific in the field wetland delineations.

GOAL 5: Use of machine learning to enhance accuracy and provide for on-going improved accuracy. Use of varied data sources to enhance accuracy and usability.

3.3 Detailed requirements

3.3.1 Goal 1

Full Satisfaction of Goal 1 will include at least, all of the following:

• Website domain for web accessible map.

• Website hosting.

• Web accessible map including the following layers and functions:

o Location and extent of all wetlands throughout all of South Dakota.

o Locations of other surface water features (streams, rivers, lakes, ponds, other impoundments).

o Topography or a topographic base map.

o County boundaries.

o Disclaimer statement indicating this is not a formal or final jurisdictional determination. Specific wording to be determined later.

o Disclaimer statement indicating any boundary shown is not a formal/official survey.

o Search bar allowing user to search by place name, address, latitude/longitude in decimal degrees and township/section/range.

o Legend clarifying any unique symbology.

o User selectable basemaps including: topo, aerial photo, road map.

o Website should be useable on multiple common browsers (Chrome, Firefox, Edge, etc) and optimized for at least one of those browsers.

o Report, export, or Print to PDF function.

UPDATED APRIL 13, 2026 V5.4 9

3.3.2 Goal 2

Full Satisfaction of Goal 2 will include at least, all of the following:

• Development of a predictive model (alternate approaches are allowable pending discussion), additional model(s) may be needed for specific ecoregions or areas lacking adequate information.

• Report on methods used to produce wetland layer.

• Feature on webmap for restoration potential, identifying areas based on geomorphic position, soils, land use history or other factors that are likely best suitable for wetland creation.

3.3.3 Goal 3

Full Satisfaction of Goal 3 will include at least, all of the following:

• Creation of a high-resolution geospatial layer of wetlands throughout all of

South Dakota that is sharable to other programs within DANR and their contractors for future projects (flood modeling, water quality modeling, etc).

• Discussion of how the resolution chosen will enable DANR and program partners to fully use the map for its intended purposes of: informed land buyer and land owner decision making, wetland mitigation, wetland protection while protecting the privacy of private property owners.

3.3.4 Goal 4

Full Satisfaction of Goal 4 will include at least, all of the following:

• Creation of predictive model(s) to identify the location and extent of wetlands throughout all of South Dakota taking into consideration each of the unique Level III ecoregions.

• Alternate methods not including predictive modeling may be approved based on demonstrated merit.

3.3.5 Goal 5

Full Satisfaction of Goal 5 will include at least, all of the following:

• Development of process to “train” the model on a routine basis.

• Development of process to share training information bilaterally between

DANR and the Offeror.

• Acquisition of LiDAR data, satellite imagery and other remotely sensed data.

A process to share or provide DANR with access to this raw data should be developed.

3.3.6 Office Automation Integration

DANR has standardized on Microsoft Office suite products (Word, Excel, PowerPoint, etc.) and Adobe. The Solution must be compatible with these products to support, at a minimum, documents as attachments, automated generation of documents (e.g., PDF reports, XLSX spreadsheet, MS Word documents), and cut/paste of text into the Solution’s text fields. Numerous contemporary web browsers are used (Firefox, Chrome, Edge) the final products should be optimized for at least one of these browsers.

UPDATED APRIL 13, 2026 V5.4 10

3.3.7 Disaster Recovery Plan

The Contractor will have a disaster recovery plan for the Solution. This plan will document the sequence of events to follow in the circumstance that an internal or external interruption impacts services provided to the solution user community that may arise because of failure of one or more components that comprise the Solution’s infrastructure, hardware, software, interfaces, networks, Contractor’s data center facility, or power. This plan will be developed in consultation with DANR and in adherence with the State of South Dakota Information Technology Security policies, which include Disaster Recovery standards for the State. The Contractor will provide validation reports of disaster recovery tests successes or failures on an annual basis.

The activities of the disaster recovery plan are intended to reduce or minimize downtime of critical equipment, interruption of employee work schedules, and financial exposures for DANR and the Contractor. This plan will also document a sequence of communication events to follow during an internal or external infrastructure failure or natural disaster (act of nature).

3.4 Solution Implementation Requirements

3.4.1 Implementation Approach

Offerors must provide details of their implementation approach in their project implementation plan. This plan should describe how the Offeror will meet the June 2027 completion deadline. All proposal responses should be based on this implementation approach, including the project implementation plan. The project implementation plan will require DANR approval before beginning.

3.4.2 State Project Support

DANR and SDBIT (SDBIT level of support dependent on whether the Solution is hosted locally or by the Contractor) are committed to the success of this project and will provide staffing resources as appropriate. To help DANR and SDBIT better plan to have the right resources available in the right quantities at the right time, the Offeror must provide a state project support plan in their response.

DANR and SDBIT understand that its participation is critical to ensure the goals of the project are accomplished; therefore, advanced notice of the expected DANR and SDBIT resource support required is beneficial. This should include the roles (Project Manager, architect, DBA, etc.) and amount of recommended effort during specific timeframes.

3.4.3 Training

The Contractor will be responsible for providing adequate training to ensure DANR’s staff are properly trained to utilize the implemented Solution and access GIS-related features directly from within ArcGIS Pro. It is expected that the Contractor will develop and conduct training of Water Quality Program staff, BIT staff, and other program partners at an appropriate time during implementation:

UPDATED APRIL 13, 2026 V5.4 11

• DANR End Users: The Contractor must at a minimum provide onsite, instructor-led, computer-based, hands-on solution functionality training to key users who will be trained in a train-the-trainer approach, being thorough enough to enable those who are trained to then train and support other staff as needed.

• Key Technical Resources: The Contractor will provide a technical diagram/schematic of the Solution documenting the content of and relationships between data and location of data. It is also expected that the Contractor will provide DANR with documentation/help menu of the Solution sufficient for DANR staff to implement the Solution and refer to for training purposes.

The Offeror must provide a training plan in their response that at minimum identifies the approach and method of training recommended for the various users of the Solution.

3.4.4 Post-Implementation & Ongoing Support

Offerors must provide details for any on-going maintenance services provided following implementation of the Solution. Offerors should provide details of the following:

• Post-implementation support to ensure the Solution is implemented and running in a stable manner without major flaws following implementation.

• On-going maintenance/service agreement terms and costs, including costs associated with Offeror hosting the Solution.

Regarding Solution upgrade/update support. DANR is interested in learning Offeror’s approach for incorporating agency feedback on proposed updates, enhancements, etc. to the Offeror’s Solution and associated costs.

4 Project Deliverables/Approach/Methodology

The offeror must describe in detail how its proposed deliverables will meet the needs of the State as described in Section 3. At its sole discretion, the State may consider a solution that includes any of these deliverables or consider deliverables not originally listed.

An offeror must highlight any requirement in Section 3 or Section 4 that the offeror’s proposed deliverables cannot comply with, and the offeror must provide any suggested “work-around” to the requirement in question or a future date that the offeror will be able to comply with the requirement.

4.1 The offeror’s proposal must include a:

• Project Management Plan

• Project Schedule

• Risk Management Plan

• Data Conversion Plan, if applicable

• Requirements Traceability Matrix

UPDATED APRIL 13, 2026 V5.4 12

• Communication Plan

• Testing Plan

• Training Plan

• Go-Live/Cutover Plan

• Post-Implementation Support (or Maintenance and Operations Plan)

In addition, the offeror’s proposal must include how its proposed deliverables will meet the following IT requirements (General, State Hosted, and Vendor Hosted). If the offeror’s proposed solution can be hosted by the offeror or in the State’s cloud environment, the offeror must provide a separate response for each proposed solution and how each solution will meet the requirements in Sections 3 and 4.

4.2 GENERAL IT REQUIREMENTS

4.2.1 Artificial Intelligence Use

The offeror must provide an explanation of its use of Artificial Intelligence, both in its proposed solution and the development lifecycle of the proposed solution. This requirement includes the offeror’s use of Generative AI (GenAI) tools/products.

For GenAI tools/products, the offeror must provide the following:

• GenAI model name,

• product owner,

• product description (including purpose, functionality, and key characteristics),

• use case (or goal e.g. image recognition, natural language processing, text summarization),

• the intended information use (context for how information is used in the model) for the GenAI included in the offeror’s proposal,

• the geographical location of the tool, and

• how the offeror monitors and audits the tool’s compliance on use restrictions, data restrictions, legal compliance (non-discriminatory outputs), and biases in the tool’s outputs.

4.2.2 Hosting and Data Access Requirements

The State will own all data tables created as a result of the Agreement. The State must have the ability to manipulate data, run reports as needed, pull code tables, access raw data, and develop dashboards as needed through Microsoft Power BI, ESRI, Tableau, and associated platforms.

The offeror’s proposal must describe how the State can access data housed within the proposed solution for ingestion into a state data repository, encompassing available methodologies (e.g., application programming interface (API), flat file), data formatting, frequency of updates, and any inherent constraints. Additionally, the offeror’s proposal must provide a high-level architecture diagram, as part of the solution diagram as required by Section 6.7, explaining the proposed solution's data provision mechanism.

If available, the offeror must provide separate, complete proposals for the offeror’s proposed solution to be hosted by the offeror, by the State on its

UPDATED APRIL 13, 2026 V5.4 13

internal infrastructure, and on the State’s Azure cloud hosted tenant as a PaaS solution. If any of the hosting options is not available, the offeror must clearly state that in the offeror’s proposal and provide an explanation as to why the hosting option is not available.

4.2.3 Single Sign-On Requirements

If the offeror’s proposal includes a deliverable with a login component, the proposal must describe how the deliverable will integrate with the State’s standard identity management service single sign-on (SSO).

The State’s SSO supports the industry standard OAuth 2.0 protocol. This identity management will handle password recovery and multi-factor authentication (MFA). MFA is required for all application Administrators and may be required for other users. The State’s SSO requirement and links to Microsoft’s official documentation can be found at:

https://www.sd.gov/bit?id=bit_standards_single_sign_on

If the offeror is not able to fulfill this identity management standard, the offeror’s proposal will be rejected from consideration.

4.2.4 SSO Logout Initiation Requirements

• The offeror’s deliverable must provide users with a clear and easily accessible logout mechanism (e.g., a “Logout” button/link).

• The logout functionality of the offeror’s deliverable must trigger a session-based logout process utilizing the sign-out endpoint found in the metadata document provided during implementation.

4.2.5 Session Timeout Requirements

• The offeror’s deliverables must allow for a customizable, State-defined inactive user session timeout period.

• The offeror’s deliverables must notify users of impending session expiration five minutes before the timeout occurs, providing users with the option to extend the session.

4.2.6 Session Termination on Browser Close Requirement

The offeror’s deliverables must clearly notify users that closing the browser window or tab is not a valid logout because the SSO session may remain active.

The notice must further notify users that they are responsible for explicitly logging out to ensure complete session termination.

4.2.7 Onboarding/Provisioning of Users Requirement

The offeror’s proposal must describe how new users are onboarded or provisioned into the deliverable. The offeror must provide an automated process for onboarding and offboarding users or must provide a process that requires minimal manual steps.

https://www.sd.gov/bit?id=bit_standards_single_sign_on

UPDATED APRIL 13, 2026 V5.4 14

4.2.8 Interfaces and Integration Requirements

The offeror’s proposal must describe how the deliverables can adapt to business necessary interfaces using widely adopted open APIs and standards.

Additionally, the offeror must make available or expose software services that would enable third-party developers to interface other business applications.

The offeror must publish documentation for the software services in question.

The offeror’s proposal must include a detailed description of system capability.

4.2.9 Web Application Vulnerability Scan Requirements

Any web-based deliverable must undergo a web application vulnerability scan (“Vulnerability Scan”). The Vulnerability Scan must identify misconfigurations or vulnerabilities such as those found in the OWASP Top Ten and must detail the certainty level of each finding.

Unless expressly indicated in writing, the State assumes all price estimates and bids are for the delivery and support of deliverables that will pass Vulnerability Scans. If the State determines that any aspect of the deliverable has security vulnerabilities that must be corrected, the State will inform the offeror of the nature of the issue and the offeror will be required to respond in writing regarding mitigation plans for the security vulnerabilities. If the deliverable does not pass the initial Vulnerability Scan or the offeror cannot provide a satisfactory Vulnerability Scan report, additional scans may be required to confirm the deliverable is secure.

State Hosted: For state hosted web-based deliverables, the Vulnerability Scan will be performed by the State and the offeror’s proposal should take that into consideration when responding to this RFP. As a condition of the resulting contract, the state hosted web-based deliverable will have to successfully pass the Vulnerability Scan prior to the deliverable being allowed to go in a production environment. Any offeror who responds to this RFP must accept such a contract term and must factor this security requirement into the offeror’s proposal.

Vendor Hosted: For vendor hosted web-based deliverables, any offeror who makes it to the “Tech Review” stage of the RFP process must provide the State a copy of the full report of the deliverable’s most recent Vulnerability Scan, a summary will not be accepted. The offeror should mark the vulnerability report as “Confidential” if it treats such a report as confidential information. If the offeror requires a Non-Disclosure Agreement (NDA) to be in place before the State may review the Vulnerability Scan report, the offeror must notify the State of such a requirement and resolve the signing of an NDA with enough time to respond to this RFP within the timeframe.

The offeror’s Vulnerability Scan report must consist of, at a minimum:

• The system that was evaluated,

• The categories that were evaluated (examples: SQLi, XSS, or RCE), UPDATED APRIL 13, 2026 V5.4 15

• What were the general findings,

• Technical detail of each issue found,

• Remediation status of enumerated issues (if any).

The cost of any Vulnerability Scans done by the offeror or the offeror’s costs associated with the State performing Vulnerability Scans must be part of the offeror’s cost proposal. Failure of a deliverable to satisfactorily pass a Vulnerability Scan may result in the offeror’s proposal being rejected.

4.2.10 Test System Requirement

The offeror must include a test system for its application deliverables to be used at the discretion of the State. All resource costs, including licensing costs, associated with keeping the test system available must be detailed in the offeror’s cost proposal. If the offeror does not include the test system costs in the offeror’s proposal, then the offeror will bear the costs. The offeror will maintain the test system as a mirror image of the production system code base.

4.2.11 Internal Processes and Procedures Requirement

The offeror must use industry standard processes and procedures, such as a software development lifecycle, when planning the development, configuration, implementation, and support of a proposed deliverable. The offeror must outline their internal processes and procedures in their proposal, including, but not limited to, alerting key stake holders (such as: Operations, Systems Support staff, Desktop Support staff, Administrators, Help Desk personnel, Client Representatives, and others) of changes that will be occurring within State or offeror resources or systems.

4.2.12 Email Domain Name Requirement

If the offeror’s proposal includes a website or a web application that generates email and is hosted by the offeror or in the State’s cloud, the proposed website or web application cannot use state email domains as the originating domain name.

4.2.13 Banned Entity Requirement

The offeror’s proposed deliverables cannot include any hardware or hardware components manufactured by Huawei Technologies Company, Nuctech, or ZTE Corporation or any subsidiary or affiliate of such entities. This includes hardware going on the State’s network as well as the offeror’s network if the offeror’s network is accessing the State’s network or accessing State data. This includes Infrastructure as a Service, Platform as a Service, or Software as a Service situations. Any company that is considered to be a security risk by the government of the United States of America under the International Emergency Economic Powers Act, in a United States appropriation bill, an Executive Order, or listed on the US Department of Commerce’s Entity List will be included in this ban.

UPDATED APRIL 13, 2026 V5.4 16

4.2.14 Access Management Requirement

If the offeror’s proposed deliverables require accounts allowing access to State systems, then the offeror must indicate the number of the offeror’s staff or subcontractors that will require access, the level of access needed, and if these accounts will be used for remote access. These individuals will be required to use Multi-Factor Authentication (MFA). The State’s costs in providing these accounts will be a consideration when assessing the cost of the offeror’s proposal. All costs associated with providing an account to the offeror will be borne by the agency.

4.2.15 Testing Requirements

The following testing may be required:

4.2.15.1 Regression Testing – Regression testing is the process of testing changes to computer programs to make sure that the older programming still works with the new changes.

4.2.15.2 Integration Testing – Integration testing is a software development process which program units are combined and tested as groups in multiple ways. In this context, a unit is defined as the smallest testable part of an application. Integration testing can expose problems with the interfaces among program components before trouble occurs in real-world program execution. Integration testing is also known as integration and testing (I&T).

4.2.15.3 Functional Testing – Functional testing is primarily used to verify that a piece of software is meeting the output requirements of the end-user or business. Typically, functional testing involves evaluating and comparing each software function with the business requirements.

Software is tested by providing it with some related input so that the output can be evaluated to see how it conforms, relates or varies compared to its base requirements. Moreover, functional testing also checks the software for usability, such as ensuring that the navigational functions are working as required. Some functional testing techniques include smoke testing, white box testing, black box testing, and unit testing.

4.2.15.4 Performance Testing – Performance testing is the process of determining the speed or throughput of an application. This process can involve quantitative tests such as measuring the response time or the number of MIPS (millions of instructions per second) at which a system functions. Qualitative attributes such as reliability, scalability and interoperability may also be evaluated. Performance testing is often done in conjunction with load testing.

4.2.15.5 Load Testing – Load testing is the process of determining the ability of an application to maintain a certain level of effectiveness under unfavorable conditions. The process can involve tests such as ramping up the number of users and transactions until the breaking point is http://searchnetworking.techtarget.com/definition/response-time http://searchdatacenter.techtarget.com/definition/MIPS http://whatis.techtarget.com/definition/reliability http://searchdatacenter.techtarget.com/definition/scalability http://searchsoa.techtarget.com/definition/interoperability http://searchsoftwarequality.techtarget.com/definition/stress-testing

UPDATED APRIL 13, 2026 V5.4 17

reached or measuring the frequency of errors at your required load.

The term also refers to qualitative evaluation of factors such as availability or resistance to denial-of-service (DoS) attacks. Load testing is often done in conjunction with the more general process of performance testing. Load testing is also known as stress testing.

4.2.15.6 User Acceptance Testing – User acceptance testing (UAT) is the last phase of the software testing process. During UAT, actual software users test the software to make sure it can handle required tasks in real-world scenarios, according to specifications. UAT is one of the final and critical software project procedures that must occur before newly developed or customized software is rolled out. UAT is also known as beta testing, application testing or end user testing. In some cases, UAT may include piloting of the software.

4.2.16 Website Requirements

Any website must meet the Web Standards listed in this RFP and as found in the following:

https://www.sd.gov/bit?id=bit_standards_web https://www.sd.gov/bit?id=bit_standards_vendor_client_sec_req

4.2.17 Web Content Accessibility Guidelines Requirement

The offeror’s proposed deliverables must conform to the Web Content Accessibility Guidelines 2.1 Level AA.

4.2.18 Browser Compatibility

The offeror’s proposed deliverables must be compatible with supported versions of Edge, Chrome, Safari, and Firefox browsers.

4.3 STATE HOSTED SOLUTIONS (ON-PREM OR STATE CLOUD) REQUIREMENTS

4.3.1 Virtualized Environment Requirement

The offeror should state whether its proposed solution will operate in a virtualized environment. The offeror must identify and describe all differences, restrictions, or limitations of its proposed solution with respect to operation, licensing, support, certification, warranties, and any other details that may impact its proposed solution when hosted in a virtualized environment. This information must be included with the system diagram.

4.3.2 Network Vulnerability Scan Requirement

All deliverables hosted by the State will be subject to a network vulnerability scan by the State.

4.3.3 Load Balancing Requirement

The offeror must state if its proposed deliverables can be load balanced across multiple servers, which is a requirement for an application to operate within the State’s computing environment.

http://searchnetworking.techtarget.com/definition/availability http://searchsoftwarequality.techtarget.com/definition/performance-testing https://www.sd.gov/bit?id=bit_standards_web https://www.sd.gov/bit?id=bit_standards_vendor_client_sec_req

UPDATED APRIL 13, 2026 V5.4 18

4.3.4 Use of Abstraction Technologies Requirement

The offeror must describe how its proposed deliverables use abstraction technologies, which is defined as the removal of the network control and forwarding functions that allows the network control to become directly programmable and the underlying infrastructure to be separated for applications and network services.

In addition, the offeror must affirmatively state that its proposed deliverables do not use hard-coded references.

4.3.5 Non-Standard Hardware and Software Requirement

State standard hardware and software should be utilized unless there is a reason not to. If the offeror’s proposal recommends using non-standard hardware or software, the proposal must very clearly indicate what non-standard hardware or software is being proposed and why it is necessary to use non-standard hardware or software to complete the project requirements. The costs of such non-standard hardware or software should be reflected in the offeror’s cost proposal. See https://bit.sd.gov/bit?id=bit_standards_overview, for lists of the State’s standard hardware and software. The offeror’s proposal must include a link to the offeror’s hardware and software specifications if one is available or explain why a link is not available. BIT must approve the use of any non-standard hardware or software before a contract can be awarded.

4.3.6 Vendor to State Hosted Transition

If, as part of the proposed project plan, the offeror intends to set up or configure a deliverable outside of State’s IT infrastructure, even in part, and then move said deliverable to the State’s infrastructure, then the offeror must provide a complete and detailed project plan on how that transition will occur. The offeror’s proposal should include any additional time and money considerations for the transition.

4.4 VENDOR HOSTED SOLUTION REQUIREMENTS

4.4.1 General Vendor Hosted Requirements

In the offeror’s proposal, the offeror must describe its:

• Data loss prevention methodology;

• Data sanitization methodology and procedures;

• Identity and access management;

• Security intelligence;

• Annual security training and awareness;

• Manual procedures and controls for security;

• Perimeter controls;

• Security certifications and audits.

4.4.2 Import and Export of Data Requirement

The offeror’s proposed deliverables must allow the State the ability to import or https://bit.sd.gov/bit?id=bit_standards_overview

UPDATED APRIL 13, 2026 V5.4 19

export the State’s data piecemeal or in its entirety at the State’s discretion without interference from the offeror. The data must be able to be exported in a non-proprietary format and must include information such as metadata (data structure descriptions, data dictionary, and data). The offeror’s proposal must describe how this functionality works within its deliverables.

5 Resources

5.1 Staff Resumes and References

Resumes and references of key personnel are required as part of the offeror’s proposal.

Key personnel are considered to be those who are accountable for the completion of one or more major deliverables, has the responsibility of any or all of the total project management, or is responsible for the completion of the project. Provide resume details for all key personnel, including any subcontractors’ project leads, by listing the following in the order in which it appears.

• Name

• Title

• Contact Information (telephone number(s), e-mail address)

• Work Address

• Project Responsibilities (as they pertain to this project)

• Percentage of time designated to this project

• Brief listing of work experience in reverse chronological order over the last five years

(only provide company name, job title(s)/position(s) held, date started, and date left each position, brief description of job duties, responsibilities, and significant accomplishments)

• RFP Project Experience

• Technical Background relative to this project

• Experience in Similar Projects

• Names of the Similar Projects they were involved in

• Role the person played in the projects similar to this project

• Project Management Experience

• Technical Knowledge

• Education

• Relevant Certifications

• Three Professional References (name, telephone number, company name, relationship to employee)

6 Proposal Submission Requirements

The offeror’s proposal should be prepared simply and economically and provide a direct, concise explanation of the offeror’s proposal and qualifications. Elaborate brochures, sales literature, and other presentations unnecessary to a complete an effective proposal should not be submitted.

The offeror is cautioned that it is the offeror's sole responsibility to submit information related to the evaluation categories. The State of South Dakota is under no obligation to solicit any information that is not included with the proposal. The offeror's failure to submit all requested information in this RFP may cause an adverse impact on the evaluation of the offeror’s

UPDATED APRIL 13, 2026 V5.4 20

proposal. The offeror should respond to each point in Sections 3 and 4 in the order they were presented.

6.1 Use of State Seal Restriction

The offeror’s proposal should refrain from using the State of South Dakota State Seal in its proposal. Offerors are cautioned that use of the State Seal in any of its documents is illegal as per South Dakota Codified Law § 1-6-3.1.