Addendum 1-24RFP11465.pdf

Addendum #1: Please refer to Sections 1.6.2; 3.3 and 3.9.3 for updated information.

STATE OF SOUTH DAKOTA

OFFICE OF PROCUREMENT MANAGEMENT

523 EAST CAPITOL AVENUE

PIERRE, SOUTH DAKOTA 57501-3182

Digital Evidence Management System

PROPOSALS ARE DUE NO LATER THAN NOVEMBER 1, 2024

RFP #: 24RFP11465

EMAIL: jamie.reed@state.sd.us

BUYER: South Dakota Office of the Attorney General (SD ATG), Division of Criminal Investigation (SD DCI)

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:

mailto:24RFP10154@state.sd.us

10/31/2017 2

1.0 GENERAL INFORMATION

1.1 PURPOSE OF REQUEST FOR PROPOSAL (RFP)

Background: The South Dakota Division of Criminal Investigation (DCI) is a statewide law enforcement agency that operates under the South Dakota Attorney General’s Office. The South Dakota DCI employs 130 personnel in a variety of areas, including Special Agents, Special Investigators, Analysts, Forensic Scientists, Law Enforcement Trainers, Identification Specialists, Sex Offender Registration, Victim Advocates, Information Technology Specialists and Administrative Support Staff. The primary mission of the South Dakota DCI is to provide high level criminal investigation services to state and local law enforcement partners as well as conducting proactive criminal investigative efforts. The South Dakota DCI also offers many different law enforcement services and run many statewide programs such as the State Forensic Laboratory, Law Enforcement Training Academy, Missing Persons Clearinghouse, Sex Offender Registration, 24/7 program, SAVIN, NIBRs and Statistical Analysis Center, the South Dakota Internet Crimes Against Children (ICAC) Task Force, Electronic Crimes, Technical Services Unit, Elder Abuse, Polygraphs and process criminal and civilian background checks. In addition, the South Dakota DCI partners with other agencies across the state in drug task forces, drug asset forfeiture program, the FUSION Center, Amber Alert and Endangered Missing Advisory and Special Victims Unit Multi-disciplinary Team.

The DCI Field Operations consists of approximately 60 Special Agents and Special Investigators who focus on major criminal investigations, narcotics investigations, ICAC investigations, electronic crime investigations; many of these operations utilize our technical services unit for electronic surveillance. These Special Agents and Special Investigators encounter various forms of digital evidence and digital data that must be stored and maintained as evidence or for investigative documentation purposes.

1.2 ISSUING OFFICE AND RFP REFERENCE NUMBER

The SD DCI is the issuing office for this document and all subsequent addenda relating to it, on behalf of the State of South Dakota, SD DCI. The reference number for the transaction is 24RFP11465. This number must be referred to on all proposals, correspondence, and documentation relating to the RFP.

1.3 DEFINITIONS USED IN THIS RFP

The following definitions are used in this RFP:

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

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

State - South Dakota Office of the Attorney General (SD ATG), Division of Criminal Investigation (SD DCI).

10/31/2017

1.4 OFFEROR INQUIRIES

Offerors may email inquiries concerning this RFP to obtain clarification of requirements.

No inquiries will be accepted after the date and time indicated in the Schedule of Activities. Inquiries must be emailed to Jamie Reed at Jamie.reed@state.sd.us with the subject Line “RFP #24RFP11465”.

The State will respond to offeror’s inquiries (if required) via e-mail. All Offerors will be informed of any inquiries and the State’s response. Offerors 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. Offerors will be notified in the same manner as indicated above regarding any modifications to this RFP. Offerors 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. Offerors will be notified in the same manner as indicated above regarding any modifications to this RFP.

Offerors are expected to raise any questions, exceptions, or additions they have concerning the RFP document by the deadline for submission for written inquiries as indicated in the Schedule of Activities. If an Offeror discovers any significant ambiguity, error, conflict, discrepancy, omission or other deficiency in this RFP, the Offeror should immediately notify Jamie Reed, of such error and request modification or clarification of the RFP.

Offeror's Contacts: Offerors and their agents (including subcontractors, employees, consultants, or anyone else acting on their behalf) must direct all of their questions or comments regarding the RFP, the evaluation, etc. to Jamie Reed as indicated above.

Offerors and their agents may not contact any other state employee regarding any of these matters during the solicitation and evaluation process. Inappropriate contacts are grounds for suspension and/or exclusion from specific procurements. Offerors and their agents who have questions regarding this matter should contact Jamie Reed as indicated above.

1.5 SCHEDULE OF ACTIVITIES (SUBJECT TO CHANGE)

RFP Publication September 18, 2024 Deadline for Submission of Written Inquiries October 4, 2024 Responses to offeror Questions October 18, 2024 Proposal Submission Deadline November 1, 2024 Evaluation of Proposals November 4-15, 2024 Demonstrations and presentations (as determined by State) December 2-13, 2024 Proposal Revisions (if required) January 3, 2025 Anticipated Award Date January 17, 2025 Contract Negotiation January 20-March 14, 2025 Anticipated Go-Live June 13, 2025 mailto:Jamie.reed@state.sd.us

1.6 PREPARING AND SUBMITTING YOUR PROPOSAL

Elaborate proposals (e.g., expensive artwork) beyond that sufficient to present a complete and effective presentation are not necessary or desired.

1.6.1 Incurring costs

The State is not liable for any cost incurred by Offerors in replying to this RFP.

1.6.2 Submitting the proposal

All proposals must be completed and received in the SD DCI by the date and time indicated in the Schedule of Activities.

Proposals received after the deadline will be late and ineligible for consideration.

Offerors may send their proposals in hard copy or electronically via email.

If sending electronically, The electronic version should be provided in MS WORD or in PDF format to jamie.reed@state.sd.us. The email, including attachments, must be limited to 10MB in size. Multiple emails can be sent.

All proposals must be signed by an officer of the Offeror, legally authorized to bind the Offeror to the proposal. Proposals that are not properly signed may be rejected. To facilitate the electronic signature of proposals, Offerors shall provide the email address of the officer legally authorized to bind the Offeror to the proposal by 11:59PM CST, November 1, 2024. If Offerors do not wish to sign electronically, the first page of the RFP must accompany the proposal submission, completed, and signed.

Electronic proposals received after the deadline will be late and ineligible for consideration.

Offerors may not send the electronically formatted copy of their proposal via email.

If sending hard copy, offerors will mail 5 printed copies of their proposal, along with one electronic copy on a thumb drive, including all attachments, in both Microsoft Word and PDF electronic formats.

The cover sheet of the proposal must be signed, in ink, by an officer of the Offeror, legally authorized to bind the Offeror to the proposal, and sealed in the form intended by the Offeror. Proposals that are not properly signed may be rejected. The cover sheet must be printed and submitted with the proposal. The sealed envelope must be marked with the appropriate RFP Number and title. The words “Sealed Proposal Enclosed” must be prominently denoted on the outside of the shipping container.

All proposals must be signed, in ink, by an officer of the offeror, legally authorized to bind the offeror to the proposal and sealed in the form. Proposals that are not properly signed may be rejected. The sealed envelope must be marked with the appropriate RFP Number and Title. The words “Sealed Proposal Enclosed” must be prominently denoted on the outside of the shipping container.

Proposals must be addressed and labeled as follows:

REQUEST FOR PROPOSAL # 24RFP11465

DUE DATE: NOVEMBER 1, 2024

SOUTH DAKOTA DIVISION OF CRIMINAL INVESTIGATION

JAMIE REED

1302 E. HIGHWAY 14, SUITE 5

PIERRE, SD 57501

All capital letters and no punctuation are used in the address. The South Dakota Division Of Criminal Investigation address as displayed should be the only information in the address field.

Hard copy proposals postmarked after the deadline will be late and ineligible for consideration.

No proposal shall be accepted from, or no contract or purchase order shall 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.7 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.8 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.9 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 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.10 RESTRICTION OF PROHIBITED ENTITY

In accordance with the South Dakota Codified Law 5-18A, any bidder or offeror submitting a bid or offer in response to this document certifies and agrees that the following information is correct:

The bidder or offeror is not an organization, association, corporation, partnership, joint venture, limited partnership, limited liability partnership, limited liability company, or other entity or business association, including all wholly-owned subsidiaries, majority-owned subsidiaries, parent companies, or affiliates, of those entities or business associations, regardless of their principal place of business, which is ultimately owned or controlled, directly or indirectly, by a foreign parent entity from, or the government of, the People’s Republic of China, the Republic of Cuba, the Islamic Republic of Iran, the Democratic People’s Republic of Korea, the Russian Federation, or the Bolivarian Republic of Venezuela.

It is understood and agreed that, if this certification is false, such false certification will constitute grounds for the purchasing agency 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, and further would be cause to suspend and debar a business under SDCL § 5-18D-12.

The successful bidder or offeror further agrees to provide immediate written notice to the purchasing 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.11 CERTIFICATION OF NO STATE LEGISLATOR INTEREST

Offeror (i) understands neither a state legislator nor a business in which a state legislator has an ownership interest may be directly or indirectly interested in any contract with the State that was authorized by any law passed during the term for which that legislator was elected, or within one year thereafter, and (ii) has read South Dakota Constitution Article 3, Section 12 and has had the opportunity to seek independent legal advice on the applicability of that provision to any Agreement entered into as a result of this RFP. By signing an Agreement pursuant to this RFP, Offeror hereby certifies that the Agreement is not made in violation of the South Dakota Constitution Article 3, Section 12.

1.12 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.13 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.14 LENGTH OF CONTRACT

The contract will be for a five (5) year term and the State, in its sole discretion, may renew the Agreement under the same terms and conditions for up to one additional five-year period.

1.15 GOVERNING LAW AND VENUE

This RFP shall be governed by and construed in accordance with the laws of the State of South Dakota, without regard to any conflicts of law principles, decisional law, or statutory provision which would require or permit the application of another jurisdiction’s substantive law. Venue for any lawsuit pertaining to or affecting this RFP shall be in the Circuit Court, Sixth Judicial Circuit, Hughes County, South Dakota.

1.16 PRESENTATIONS/DEMONSTRATIONS

An oral presentation by an offeror to clarify a proposal may be required at the sole discretion of the State. However, the State may award a contract based on the initial proposals received without discussion with the Offeror. If oral presentations are required, they will be scheduled after the submission of proposals. Oral presentations will be made at the offeror’s expense.

This process is a Request for Proposal/Competitive Negotiation process. Each Proposal shall be evaluated, and each respondent shall be available for negotiation meetings at the State’s request. The State reserves the right to negotiate on any and/or all components 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.17 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. There will be a Technical Review involving the South Dakota Bureau of Information and Communications (“BIT” hereinafter) relating to the Offeror’s responses to the Security and Vendor Questions at the discretion of the State.

1.18 NEGOTIATIONS

This process is a Request for Proposal/Competitive Negotiation process. Each proposal shall be evaluated, and each respondent shall 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.

2.0 STANDARD CONTRACT TERMS AND CONDITIONS

Any contract or agreement resulting from this RFP will include, at a minimum, the substance of the contract terms and conditions as set forth in Appendix A. However, as part of the negotiation process, the language of a specific term or condition listed in Appendix A could be modified upon agreement between the State and the vendor. Additional terms and conditions may be required. The Offeror should indicate in their response any issues they have with specific contract terms. If the Offeror does not indicate that there are any issues with any contract terms, the State will assume those terms are acceptable to the Offeror.

3.0 SCOPE OF WORK

The successful Vendor shall provide qualified staff and support for successful completion of the project. The Owner reserves the right to add or delete related project requirements during the term of the contract as needed. Prices for these changes will be negotiated and finalized as the work requires and as available funding allows. Owner is not responsible for Vendor costs that exceed approved project cost or for any costs resulting from Vendor work undertaken before Owner representative’s acceptance and written approval.

3.1 Vendor Hosted Cloud Solution: The Vendor will provide projected cost for, and assist in, hosting a solution in a cloud environment. Microsoft Azure Government or AWS GovCloud environments are currently the state standard. If the Vendor is going to propose a cloud solution that is not Microsoft Azure Government or AWS GovCloud environments, the Vendor must provide their FedRAMP certification and proof that you meet the CJIS Security Policy Requirements.

3.2 Storage: The Vendor will provide a plan for and cost estimates of storage.

Current storage needs are estimated at the current size of approximately one (1) Petabyte, with needs for future infinite growth. Data will be automatically tiered into storage pools based off user demand and performance needs.

3.3 Management Services: Provide initial onboarding and ongoing services related to:

3.3.1 Management of Azure Enrollment or AWS GovCloud Enrollment

3.3.1 Management of Cloud Enrollment

3.3.2 Monitoring and audit

3.3.3 Transfer/Upload of sensitive data/content from current servers to secure cloud environment

3.3.4 Transfer/Upload of video evidence from current servers to secure cloud environment

3.3.5 Video evidence archiving

3.3.6 24/7 support and management for:

3.3.7 Data Archiving

3.3.8 Data Management

3.3.9 Incident Recovery

3.3.10 Backups

3.3.11 Restoration

3.3.12 Community Upload Link feature and capabilities

(this item is optional, but not a requirement)

3.3.13 Milestone, Video Management Software, integration

(this item is optional, but not a requirement)

3.4 Hosting and Data Access Requirements

The state is looking for a Vendor Hosted Cloud Solution. The contract doubles as an agreement for the State to own the data tables and can 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 shall describe the process by which the State can access data housed within the proposed solution for ingestion into a state data repository, encompassing available methodologies (e.g., flat file, API), data formatting, frequency of updates, and any inherent constraints. Additionally, provide a high-level architecture diagram, as part of the Solution Diagram, elucidating the proposed solution's data provision mechanism.

3.5 Single Sign-On Requirements

As part of the State’s Identity and Access Management (IAM) strategy, the proposed solution will need to integrate with the State of South Dakota’s standard identity management service single sign-on (SSO) which enables custom control of how citizens and state employees sign up, sign in, and manage their profiles.

The 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. Microsoft’s official documentation on the identity provider the State has implemented can be found at: 1) https://docs.microsoft.com/en-us/azure/active-directory-b2c/ and https://docs.microsoft.com/en-us/azure/active-directory-b2c/integrate-with-app-code-samples for public/citizens (Azure B2C), 2) https://learn.microsoft.com/en-us/azure/active-directory/architecture/auth-oauth2 and https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-protocols-oidc for state employees, businesses, partners, providers, etc. (Azure Active Directory).

If the offeror is not able to fulfill this identity management standard, they will be excluded from the list.

3.6 Onboarding/Provisioning Users

The offeror must describe how new users are onboarded/provisioned in the system using an external identity provider an Identity/SSO/Login Design Document.

3.7 Interfaces and Integration

The offeror must describe how the system can adapt to business necessary interfaces using widely adopted open APIs and standards. Additionally, SD DCI expects that the offeror will make available/expose software services and publish documentation for those software services that would enable third party developers to interface other business applications. A detailed description of system capability shall be included in the proposal.

The state currently utilizing On-Prem Milestone. Future program expansions would provide the ability to offer direct edge to cloud streaming of video surveillance footage from within the Milestone system to the cloud storage solution with the ability to automatically convert the proprietary video format into a standard .mp4 video file while maintaining the original “first instance” file.

3.8 Solution Diagram

The offeror must provide a solution diagram providing specific details of how the entire https://docs.microsoft.com/en-us/azure/active-directory-b2c/ https://docs.microsoft.com/en-us/azure/active-directory-b2c/integrate-with-app-code-samples https://docs.microsoft.com/en-us/azure/active-directory-b2c/integrate-with-app-code-samples https://learn.microsoft.com/en-us/azure/active-directory/architecture/auth-oauth2 https://learn.microsoft.com/en-us/azure/active-directory/architecture/auth-oauth2 https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-protocols-oidc https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-protocols-oidc solution will meet the requirements of the RFP. This will include integration with the State’s infrastructure, existing systems that will integrate with the proposed solution, how data would flow between systems, the technology stack of the solution including any dependencies, and include user onboarding/provision and SSO.

3.9 Scope of Components or Phases

Currently the SD DCI and the SD Attorney General’s Office are using external hard drives, thumb drives, CDs/DVDs, and other removeable storage media to collect or share discovery with LE partners. Depending on the type of digital evidence, it is then stored within the agency Central Square Pro-Suite RMS system, the agency shared network drive, individual NAS storage servers or removable media. For all files except video and extremely large files, they are shared through the DCI RMS web client. For video and extremely large files, they are burned to a CD.

Approximately 130 agency users:

• Approximately 10 users with full admin access and permissions

• Approximately 90 users with read/write access and permissions

• Approximately 30 users with read only access and permissions ***ICAC investigations/data involving child sexual abuse material (CSAM) or other sensitive material or data will require the ability to limit access to specific users.*** Approximately 1,500 investigations a year.

Current digital forensics programs being used in our agency include the following:

Cellebrite UFED 4PC, Cellebrite Physical Analyzer, Cellebrite Digital Collector, Magnet AXIOM, Magnet OUTRIDER, X-Ways Forensics

3.9.1 This proposed project is to provide hosted and managed services for securely uploading the storage of all digital evidence and digital data associated with the DCI Field Operations to the cloud environment. The end goal is to reduce and eliminate as much as possible the physical footprint of storage and server hardware, currently in many different physical locations throughout the state.

Due to the sensitive nature of some of the data involved with ICAC investigations and major crimes, the storage of this data must be secured via encryption and/or with restricted access to the point where even the vendor cannot see the actual data contents. Other types of digital evidence and digital data may not require the same level of encryption or restricted access. Regardless of encryption or restricted access requirements, all new and existing data must be automatically backed up with full audit capabilities to document who accessed or touched secured data. Also, this data will need to be stored and maintained pursuant to state laws and agency policy, which in some cases may be indefinite storage. This will include evidence/data retention categories and automated alerts. In addition, this cloud storage solution must have the capability for infinite growth.

3.9.2 The proposed cloud storage solution must provide a digital evidence management system (DEMS) that includes the following features:

• The ability to create a case within the DEMS based upon an agency case number or other unique identifier and upload various types of digital evidence to each case.

• The ability to categorize, store and search for digital evidence based upon a specific case number or other unique identifier.

• The ability to apply a specific retention tag or designation to individual items of digital evidence with automatic notifications regarding specific retention periods that have been reached.

3.9.3 The proposed cloud storage solution must also provide the capability to electronically transfer digital evidence and digital data between agency users, law enforcement partners, prosecutors, and other stakeholders. This will include the capability to provide digital evidence discovery to prosecutors outside of the state network infrastructure as well as the ability to transfer or share digital data with law enforcement partners outside of the state network infrastructure. This feature should include the ability to share a secure data upload and/or data download link as well as being able to assign controlled or limited access to a specific file/folder within the cloud storage solution. In addition, this will include a Community Upload Link feature and capability that will allow DCI Field Operations to create an upload link within the cloud storage solution that can be provided to members of the public for the purpose of uploading digital images and video footage regarding critical incidents and other incidents that are being investigated by the DCI. Lastly, this will include full audit capabilities to document the transfer of digital evidence and digital data between all users.

3.9.4 The following file types/extensions are currently used/received in our agency. The proposed cloud solution will need to be able to upload and store these file types/extensions into the new system; .jpg, .png, .bmp, .giff, .mov, .mpeg, .avi, .wma, .wav, .mp3, .m1a, .mid, ,mdi, .chm, .pdf, .doc, .docx, .xls, and Milestone video format.

3.9.5 The current annual budget for this project is $100,000.00. This includes implementation, go live, and reoccurring annual costs.

3.9.6 Target go-live date is June 13, 2025.

3.10 PROJECT DELIVERABLES/APPROACH/METHODOLOGY

This section identifies tasks and deliverables of the project as described in Section 3.0.

The selected offeror is responsible for providing the required deliverables. These deliverables will be the basis against which the offeror’s performance will be evaluated.

3.10.1 Since the offeror is hosting the solution, provide a diagram giving an overview of the proposed system. It is preferred that this diagram be provided as a separate document or attachment. The file must be named “(Your Name) Hosted System Diagram”. If the offeror elects to make the diagram part of the proposal, then the location of the diagram must be clearly indicated in the Table of Contents.

3.10.2 The offeror should state whether its proposed solution will operate in a virtualized environment. Offeror also should 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 solution diagram for the offeror hosted solution.

3.10.3 The offeror is required to include a test system for its application. This test system will be used at the discretion of BIT. All resource costs associated with keeping the test system available must be borne by the project owner or the offeror. Any licensing costs for the test system must be included with the costs.

3.10.3.1 At BIT’s discretion, any code changes made by the offeror, either during this project or thereafter, will be placed in the above test system first. It is at BIT’s discretion if the code changes are applied by BIT or the offeror. If the code testing delays a project’s timeline, a change management process should be followed, and the State will not be charged for this project change.

If the test and production systems are to be hosted by the State, the schedule for the testing of the code changes is to be decided by BIT. Testing of emergency code changes will be scheduled by BIT based on the severity and resource availability.

3.10.3.2 The test system will be maintained by the offeror as a mirror image of the production system code base. At BIT’s discretion, updates to the production system will be made by copying code from the test system after the test system passes BIT certification requirements.

3.10.3.3 If BIT determines that the application must be shut down on the production system, for any reason, the offeror will, unless approved otherwise by BIT, diagnosis the problem on and make all fixes on the test system. The offeror is expected to provide proof, to BIT, of the actions taken to remediate the problem that led to the application being denied access to the production system before the application can go back into production. This proof can be required by BIT even if the fix passes all BIT certification criteria. BIT is willing to sign a non-disclosure agreement with the offeror if the offeror feels that revealing the fix will put the offeror’s intellectual property at risk.

3.10.4 All solutions acquired by the State that are hosted by the offeror, including

Software as a Service, or hosted by a third-party for the offeror will be subjected to security scans by BIT or preapproved detailed security scan report provided by the offeror. The scan report sent in with the proposal can be redacted by the offeror. The State’s goal at this point is to see if the contents of the report will be acceptable, not to review the contents themselves. If the offeror will be providing a security scan report, one must be sent with the proposal for approval. Approval is not guaranteed. If the scan report is not acceptable, the State must scan the offeror’s solution. The actual scanning by the State or the submission of a security scan report will be done if the proposal is considered for further review.

A detailed security report must consist of at least:

3.10.4.1 The system that was evaluated (URL if possible, but mask it if needed).

3.10.4.2 The categories that were evaluated (example: SQL injection, cross site scripting, etc.)

3.10.4.3 What were the general findings, (meaning how many SQL injection issues were found, what was the count per category)

3.10.4.4 Technical detail of each issue found. (where was it found – web address, what was found, the http response if possible)

The cost of any scans done by the offeror or the offeror’s costs associated with the State’s scans must be part of the offeror’s bid. If the offeror is sending a security scan report, it should price the product both as if the State was to do the security scan or if the offeror was to do the security scan.

3.10.5 Security scanning will be performed during the software development phase and during pre-production review. These scans and tests can be time consuming and should be allowed for in project planning documents and schedules. Products that do not meet BIT’s security and performance requirements will not be allowed to go into production and may be barred from UAT until all issues are addressed to the State’s satisfaction. The State urges the use of industry scanning/testing tools and secure development methods be employed to avoid unexpected costs and project delays. Costs to produce and deliver secure and reliable applications are the responsibility of the software entity producing or delivering an application to the State. Unless expressly indicated in writing, the State assumes all price estimates and bids are for the delivery and support of applications and systems that will pass security and performance testing. If the State determines the hardware, website(s), software, and or cloud services have 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 product(s) does not pass the initial security scan, additional security scans may be required to reach an acceptable level of security. The offeror must pass a final follow-up security scan for the website(s), software or cloud services for the product(s) to be acceptable products to the State. The State may suspend or cancel payments for hardware, website(s), software, or cloud services that do not pass a final security scan.

Any website or web application hosted by the offeror that generates email cannot use “@state.sd.us” as the originating domain name per state security policy.

3.10.6 As part of this project, the offeror will provide a monitoring tool the State can utilize to monitor the operation of the proposed solution as well as all systems and all subcomponents and connections. It is required that this tool be easy to use and provide a dashboard of the health of the proposed solution. The effectiveness of this monitoring tool will be a component of the acceptance testing for this project.

3.10.7 As part of the project plan, the offeror will include development of an implementation plan that includes a back out component. Approval of the implementation plan by BIT should be a project milestone. Should the implementation encounter problems that cannot be resolved and the implementation cannot proceed to a successful conclusion, the back out plan will be implemented. The Implementation and back out documentation will be included in the project documentation.

3.10.8 The successful offeror will use the approved BIT processes and procedures when planning its project, including BIT’s change management process. Work with the respective agency’s BIT Point of Contact on this form. The Change Management form is viewable only to BIT employees. The purpose of this form is to alert 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 resources and systems to schedule the:

3.10.8.1 Movement of individual source code from test to production for production systems

3.10.8.2 Implementation of a new system

3.10.8.3 A major enhancement to a current system or infrastructure changes that impact clients

3.11.8.4 Upgrades to existing development platforms

3.10.9 If as part of the project the state will be acquiring software the proposal should clearly state if the software license is perpetual or a lease. If both are options, the proposal should clearly say so and state the costs of both items separately.

3.10.10 Include in your submission details on your:

• Data loss prevention methodology;

• Identity and access management;

• Security intelligence;

• Annual security training and awareness;

• Manual procedures and controls for security;

• Perimeter controls;

• Security certifications and audits.

3.10.11 Since the offeror will have State data on its system(s) or on a third-party’s system and the data cannot be sanitized at the end of the project, the offeror’s proposal must indicate this and give the reason why the data cannot be sanitized as per the methods in NIST 800-88.

3.10.12 The offeror’s solution cannot include any hardware or hardware components manufactured by Huawei Technologies Company 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 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.

3.10.13 If the offeror’s solution requires 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 solution. If the offeror later requires accounts that exceed the number of accounts that was originally indicated, the costs of those accounts will be borne by the offeror and not passed onto the State. The offeror should review the State’s security policies regarding authorization, authentication, and, if relevant, remote access (See ITSP 230.67, 230.76, and 610.1). Use of Remote Access Devices (RAD) by vendor or any subcontractors to access the State’s system must be requested when an account is requested. The offeror should be aware that access accounts given to non-state employees, Non-State (NS) accounts, will be disabled if not used within 90 days.

A NS account may be deleted after 30 days if it is not used.

3.10.14 Testing: The following testing may be required:

3.10.14.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.

3.10.14.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).

3.10.14.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.

3.10.14.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.

3.10.14.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 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.

3.10.14.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.

3.10.15 The State, at its sole discretion, may consider a solution that does include all or any of these deliverables or consider deliverables not originally listed. An offeror must highlight any deliverable it does not meet and give any suggested “work-around” or future date that it will be able to provide the deliverable.

4.0 PROPOSAL REQUIREMENTS AND COMPANY QUALIFICATIONS

4.1 TEAM ORGANIZATION: Provide the following information.

4.1.1 PROJECT ORGANIZATION CHART

List names, job titles (designate vacancies), and the city and state in which individual will work on this project.

4.1.2 LIST OF ALL CONSULTANTS AND SUBCONTRACTORS

List all entities to be used for performance of the services described in this RFP. In the work plan, describe which responsibilities will be assigned to consultants or subcontractors and the city and state in which the consultants or subcontractors are located.

4.2 PROJECT STAFFING ROLES

4.2.1 Agency Project Sponsor

Who: This is an Agency Manager for whom the project is undertaken and who are the primary stake holder and the primary risk taker.

Role: Some of the duties performed by the Agency Project Sponsor are:

• Resolves resource and priority conflicts

• Approves the Project Charter and/or Plan

• Holds subordinate managers accountable for their performance

• Direct communication and reporting relationship with the Agency Project

Manager.

• Chief advocate for the project.

• Keeps the team focused on appropriate goals

• Keeps the team updated with new information

• Holds the project team accountable planning and executing the project

• Holds the team accountable for delivering agreed-upon results

4.2.2 Development Team Project Manager

Who: This person would be a consultant employee.

Role: Some of the duties performed by the Development Team Project Manager are:

• Provides day to day supervision of the employees of the development team

• In close daily contact with the Agency Project Manager to ensure that all requirements are fulfilled

• Able to advise the Agency Project Manager of cost/benefit as well as consequences of any changes in work direction

Reports to: Agency Project Manager. Also reports to the Project Steering Team if one exists.

4.2.3 Agency Project Manager

Who: This person would be an Agency employee, appointed by the Project Sponsor.

Role: Some of the duties performed by the Agency Project Manager are:

• Day to day oversight of the project

• Approves consultant payments based on contract/work order language

• Provides direction to Agency employees as well as the team

Reports to: The Agency Project Sponsor. This person must keep the Project Sponsor informed on a weekly basis regarding progress and status of the project. When issues arise, this person must be able to make recommendations to the team regarding amendments and changes to the deliverables, schedule or budget.

4.2.4 Agency Technical Lead

Who: This person would be an Agency employee, appointed by the Agency Project manager.

Role: Some of the duties performed by the Agency Technical Lead are:

• Liaison between agency, consultant, and BIT for project technical needs.

• In close daily contact with the Agency Project Manager to ensure that all requirements are fulfilled

• Able to advise the Agency Project Manager of benefits/consequences of any changes in work direction

4.2.5 Project Security Lead

Who: This person would be a consultant employee and must be identified by the consultant.

Role: The security lead shall certify in writing the security of each deliverable. The security lead will have overall responsibility for the security of the application development, management, and update process throughout the contract period.

Reports to: The Agency Project Sponsor as part of the project status meetings. When issues arise, this person must be able to make recommendations to the team regarding amendments and changes to the deliverables, schedule or budget.

4.2.6 Project Steering Team

Who: This team consists of at least one member from each affected departmental area and may include an offeror representative.

Role: Some of the duties performed by the Project Steering Team:

• Oversee the project in terms of the contract and work order agreements. Specific items of oversight include:

o What are the deliverables for his or her agency, and are they being met?

o Is the project on schedule? If not, what are the consequences? Should the project be put back on schedule and how will that be done?

o What expenditures have been made? Is the project on budget? If not, what are the circumstances surrounding it?

• Recommendation of approval of any scope changes, or any changes that affect cost and schedule based on cost benefit to the Project Owner

Reports to: Their Agency Manager.

Authority: Each Steering Team member should have authority to make decisions for their own departmental area.

4.3 STAFF RESUMES AND REFERENCES

Resumes and references of key personnel, 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 from present to 2018

(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 they played in the projects similar to this project

• Project Management Experience

• Technical Knowledge

• Education

• Relevant Certifications

• Three Professional References (name, telephone number,…