Response to Offeror Questions document.docx

Q&A Document Date: August 14, 2026

Subject: Questions & Answers, 26RFP19882_CMS In accordance with the subject Request for Proposal (RFP), the following are answers to questions which have been submitted prior to 5PM, July 31, 2026. These questions are for informational purposes only; they do not alter the requirements specified within the RFP. Any changes to the RFP will be accomplished by the Office of Procurement Management through an addendum.

*The State's response will be in red font following the Vendor's question.

1. Is there an incumbent vendor currently supporting or maintaining the three DOE websites?

No

2. Will the incumbent vendor be eligible to submit a proposal for this RFP?

N/A

3. Is the use of offshore resources permitted for the performance of services under this contract?

See Exhibit D, Section XLIV.

4. If offshore resources are permitted, can a portion of the work be performed from outside the United States, such as from India?

See Exhibit D, Section XLIV.

5. Can the State share the anticipated budget range or ceiling for this CMS modernization project?

The budget will be determined after the proposals are received and reviewed.

6. Does the State accept Drupal as a CMS option for this project?

The State prefers non-PHP based CMS solutions. All solutions must be vetted by the State. It must have enterprise protections due to state data/information.

7. If Drupal is acceptable, are there any specific requirements or limitations we should be aware of?

The State will not host PHP-based solutions in our environments. PHP-based solutions must be hosted by the vendor.

8. Can all three websites be managed under a single Drupal multi‑site installation, or does the State expect separate CMS instances?

The State will not host PHP-based solutions in our environments. PHP-based solutions must be hosted by the vendor.

9. Does the State expect the vendor to host the CMS, or will BIT fully host the solution inside the State’s infrastructure?

The vendor should propose both options.

10. If the State is hosting, should the vendor set up and configure the development, UAT, and production environments within the State’s hosting platform?

The vendor should propose the minimum number of environments that need to be setup and configured regardless of what the solution is.

11. Can the State provide details on the hosting stack so we can confirm Drupal compatibility?

The State will not host PHP-based (Drupal) solutions in its environments.

12. If the State Cloud PaaS option is used, will BIT provide the infrastructure components, or must the vendor configure them?

The vendor should provide the PaaS components required for the solution.

13. Will the State consider Acquia as a hosting platform for the Drupal CMS?

The State will need to vet this as part of the Tech Review process.

14. If Acquia is considered, are there any restrictions on using Acquia’s cloud hosting within BIT’s security requirements?

The hosting solution must be in United States data center(s).

15. Will the State consider vendor‑hosted options if they meet all security and BIT requirements?

All options will be considered.

16. Does the State require SSO integration for public users, or only for administrators and editors?

All options will be considered.

17. Will the State provide OAuth 2.0 metadata, endpoints, and test credentials during implementation?

SSO information will be provided when appropriate. There are no test credentials, public or internally, so the vendor and the State will need to discuss and coordinate implementation and testing of SSO.

18. For State‑hosted solutions, will BIT perform all vulnerability scans, or must the vendor run scans before BIT’s review?

BIT will/can perform all web-application vulnerability scanning if state or vendor hosted.

19. If BIT’s vulnerability scan finds issues, will BIT provide remediation guidance, or is the vendor expected to diagnose and fix issues independently?

The vendor is responsible for research and remediation of any issues discovered as this is a vendor supplied and supported solution.

20. Can the State provide an approximate count of pages, documents, media assets, and content types across all three websites to help estimate migration effort?

The State will determine pages and document to retire prior to migration. As it currently exists:

DOE.sd.gov -- 451 pages, 13,300 documents History.sd.gov -- 416 pages, 1,776 documents Library.sd.gov -- 171 pages, 321 documents

21. Will the State identify which content should be migrated, archived, or removed, or should the vendor perform the content audit and recommendations?

The State will identify content.

22. Will the vendor receive access to existing CMS backends, databases, or repositories to plan and execute content migration?

The State can give backend access but there is no existing CMS.

23. Should the vendor migrate all content for all three websites, or will State staff assist with portions of the migration?

The vendor should migrate all three.

24. Should redirects from legacy URLs be included in the migration scope to preserve SEO and user navigation?

There will not be redirects. The same URLs should be maintained.

25. Can the State provide documentation on current integrations, APIs, or data sources used across the three websites?

No.

26. Should Power BI dashboards be embedded directly inside the CMS, or linked externally?

Documentation is limited for the current websites.

27. Will the State expose APIs or flat‑file feeds for data ingestion into Power BI, ESRI, Tableau, or other analytics tools?

This will be discussed and mutually agreed upon between the vendor and the State as to the industry best practices and architecture for integration, if needed.

28. Will the State provide brand guidelines, logos, color palettes, typography, and other design assets for the redesign?

The dashboard should be embedded directly.

29. Does the State require mockups for all three websites, or only for doe.sd.gov?

All three.

30. Does the State require WCAG 2.1 AA compliance, or a different accessibility level?

The State requires WCAG 2.1, Level AA compliance.

31. Should accessibility testing include both automated and manual testing?

Both should be included.

32. Does the State require a formal third‑party accessibility audit before launch?

No. The State will conduct its own, final, accessibility check. The Vendor is expected to do it’s own testing prior to launch.

33. How many State staff members will need CMS administrator and editor training?

Five.

34. Should training be delivered onsite, remote, or hybrid?

Remote training deliver is acceptable.

35. What response times does the State expect for critical and non‑critical support issues during the 90‑day post‑launch period?

Noncritical-72 hours. Critical-negotiable, no more than 6 hours.

36. Is 24×7 support required during the post‑launch period, or only business‑hours support?

Business hours support is acceptable.

37. What cyber liability insurance limit does the State require?

The State requires $3,000,000 limit.

38. Are fingerprint‑based background checks required for all vendor staff?

Fingerprint-based background checks are required for anyone who has access to state data and systems.

39. Can the State confirm that all data, metadata, and code tables must be exportable in non‑proprietary formats?

Yes.

40. Is experience with any credit‑card processor acceptable, or is specific experience with Converge/Elavon required for scoring under the familiarity‑with‑project‑locale criteria?

A specific experience with Converge/Elavon is not required for scoring under the familiarity-with-project-locale criteria.

41. Will experience integrating other payment gateways be considered equivalent to Converge/Elavon experience for evaluation purposes?

Please see scoring rubric in section 7.2.

42. Does the State prefer vendors with prior experience working with South Dakota agencies?

Please see scoring rubric in section 7.2.

43. If members of our team live in South Dakota or have worked on South Dakota projects, will that satisfy the evaluation criteria related to familiarity with the project locale?

The State will factor in all provided information in determining the scoring for each vendor.

44. Is there a mandatory cost proposal template that Offerors must use, or may Offerors submit their own detailed pricing workbook provided it includes all required cost elements?

No.

45. What is the expected duration of post-implementation support and maintenance that should be included in the proposed pricing?

The State has requested at least a 90 day post launch support. The State also anticipates a maintenance period of up to five years.

46. The RFP requests hourly development rates for potential future software development. Should these rates be provided by labor category, and are these rates intended solely for future optional work outside the initial project scope?

Rates should be provided by role and will be used for potential work outside the scope of the initial project.

47. Section 6.1 states that certain additional work must be included in the proposed price. Can the State clarify the expected scope or assumptions for pricing potential security remediation, functional corrections, third-party technology updates, and performance optimization?

The vendor is responsible for the cost of maintaining software updates, third-party component updates and security remediations. Functional correction should be included to meet the requirements/scope of the project and performance should match the agreed upon SLAs.

48. Does the State expect pricing to be organized by the project phases outlined in RFP document - Section 1.2.3 (Scope of Components or Phases), by deliverables (e.g., discovery, design, development, testing, deployment, training, and support), or by labor categories?

The State will accept pricing in the format of either sections or by deliverables.

49. For recurring services such as hosting, maintenance, and support, may Offerors include annual price escalations, or should pricing remain fixed throughout the contract term?

The State will evaluate the total cost proposal as submitted by each vendor.

50. If the proposed solution primarily utilizes open-source software or custom-developed components with no separate software licensing costs, should this be explicitly stated in the cost proposal?

Yes.

51. Is there a required service level (e.g., business hours, 24×7, response/resolution times, SLA requirements) that Offerors should assume when pricing on an ongoing service desk and support?

The State has requested at least a 90-day post launch support. The state also anticipates a maintenance period of up to five years. The state does not require 24x7 customer service support.

52. What Content Management System (CMS) is currently being used for each of the three websites, and are all three sites on the same platform?

The State does not currently have a CMS for the three websites.

53. Who is the current vendor supporting the existing websites, and will the incumbent be submitting a proposal?

The State does not currently have a vendor supporting the existing websites.

54. Can the State provide an estimated budget or anticipated funding range for this project?

The budget will be determined after the proposals are received and reviewed.

55. Is the State's preference for a fully State-hosted solution, or will vendor-hosted/SaaS solutions also be considered if they meet all security and technical requirements?

The State will evaluate all proposed solutions.

56. Does the State have a preferred CMS platform (e.g., Drupal, WordPress, Sitecore, CivicPlus), or is the State open to any solution that meets the requirements?

The State will evaluate all proposed solutions.

57. Approximately how many pages, documents, media files, and forms will need to be migrated across the three websites?

The state will determine pages and documents to retire prior to migration. As it currently exists:

DOE.sd.gov -- 451 pages, 13,300 documents History.sd.gov -- 416 pages, 1,776 documents Library.sd.gov -- 171 pages, 321 documents

58. Can the State provide a complete list of existing and planned third-party integrations (payment processing, newsletters, calendars, analytics, Power BI, GIS, social media, etc.)?

Power BI, Google Analytics, ServiceNow (calendar), and payment processing through Evalon

59. Is the State expecting a complete redesign of the websites, or should the existing branding and layouts be largely maintained?

Existing branding and layout will be largely retained.

60. Has the State recently completed an ADA/Section 508 accessibility audit that can be shared with prospective offerors?

Yes, and no the findings will not be made available.

61. Approximately how many content editors, administrators, and contributors will require CMS access after implementation?

There will be five administrators. The state does not have an estimate on the number of content editors or contributors at this point in time.

62. Is there a desired Go-Live date or any statutory deadlines that the selected vendor should plan around?

There are no statutory deadlines around which to work.

63. What analytics platforms are currently being used (Google Analytics, Adobe Analytics, Power BI, etc.), and are historical analytics expected to be preserved?

Google Analytics and Power BI. Historical analytics should be preserved for a period of time to be determined and on a case by case basis.

64. Will the State provide dedicated business users for User Acceptance Testing (UAT), and what level of participation is expected from agency stakeholders?

Yes, the State will provide dedicated business users for UAT. There will be limited participation from within the agency and other stakeholders for UAT.

65. Approximately how many State employees will require CMS training, and does the State prefer instructor-led, virtual, recorded, or train-the-trainer sessions?

Five employees will need to be trained; the state is open to the format. Recorded only trainings would not be considered favorably.

66. Following the initial 90-day support period, does the State anticipate negotiating a long-term maintenance and support agreement with the selected vendor?

The State reserves the right to negotiate a maintenance and support agreement with the selected vendor.

67. Can the State provide the estimated project budget, anticipated funding range, or not-to-exceed (NTE) amount for this engagement to help Offerors develop cost proposals that align with the State's budget expectations?

The budget will be determined after the proposals are received and reviewed.

68. Section 5.1.3 identifies "Audited Financial Statements" as part of the proposal submission requirements, while Section 5.14 indicates they may be requested by the State during the evaluation process. Could the State clarify whether audited financial statements must be included with the initial proposal or provided only upon request?

Upon State request.

69. Please clarify the State's expectations regarding the work arrangement for contractor personnel. Specifically, should project services be performed remotely, onsite, or under a hybrid model?

The State does not have a preference.

70. If onsite work or hybrid model are required, please identify the anticipated activities, work locations, and expected frequency or duration?

Neither onsite or hybrid is required.

71. Are there any incumbent vendor(s) currently providing services related to the existing websites, CMS platform, maintenance, hosting, or support?

If so, please identify the current vendor(s) and describe their scope of services if possible.

No.

72. Please provide additional information regarding the State's current hosting environment, infrastructure architecture, and any preferred technology standards or architectural requirements for the proposed State-hosted solution.

Please see Exhibit D.

73. Please provide information about the current technology environment, including the platform(s), Content Management System(s) (if applicable), custom applications, and associated version(s).

This information will help Offerors estimate the migration effort and develop an appropriate technical approach.

There is no CMS. Adobe Dreamweaver is used to create content.

74. Please clarify whether the State has identified any required key personnel roles (e.g., Project Manager, Solution Architect, Technical Lead, UI/UX Designer, QA Lead, Support Lead) or minimum staffing expectations that Offerors should include in their proposed project teams.

No, The State defers to the expertise of each vendor on how to propose fulfilling the requirements of the contact.

75. Translation: Are you looking for a multilingual site that supports manually-entered (human) translations or should we estimate for machine-based translation (Google)?

Google translate as a solution is satisfactory.

76. Hosting platform: Sections 1.1 and 3.1.8 describe the desired CMS as State hosted, while Sections 4.4 and 6 invite vendor-hosted and State cloud-hosted proposals. Is State-based hosting the preferred model, a mandatory requirement, or one of several hosting options that will receive equal consideration?

The State will evaluate all proposed solutions.

77. Hosting and deployments: If State hosting is preferred, can the State describe its hosting environment (operating systems, database platforms, container support, PHP support)? Does the State maintain its own Git repository?

The State’s preferred deployment model is a State‑managed Azure cloud environment, utilizing a standardized Azure Platform‑as‑a‑Service (PaaS) architecture to ensure consistency, scalability, security, and alignment with BIT’s enterprise cloud governance standards.

78. Credit card: What level of integration are you needing in regards to Converge/Elavon? How is this used today?

Full integration, Converge/Elavon is our credit card payment processor.

79. Budget: Could you share a budget or range of acceptable costs for the project? (e.g. $50k-100k, $100-250k, $250k+).

The budget will be determined after the proposals are received and reviewed.

80. Current Costs: What has been the total spend with the incumbent vendor over the course of the existing contract?

Not applicable, no existing contract.

81. Timeline: Do you have a set, or hoped-for, timeline for the project? Or are you open to discussing options with your chosen partner?

The State will evaluate all proposed timelines and is open to discussion with the selected vendor.

82. Data Integrations: Can you describe any external integrations more complex than an iFrame or embed code? (e.g. API integrations, data integrations, third-party services.)

The primary integrated embedded code is Power BI. There is also integrated content that comes from databases developed by the State.

83. Multiple websites: Do you have a preference for how the three different websites are managed? Should they be all within a single CMS install, or separate installations?

The State prefers separate installations.

84. Current CMS: What CMS (if any) are each of the three sites using today? What have been the biggest limitations to the current builds?

The State does not currently utilize CMS for these websites.

85. New CMS: Do you have a preference for any particular CMS? Would you consider open-source solutions such as Drupal or WordPress?

The State will evaluate all proposed solutions.

86. Remote work: Can we assume that most of the work may be conducted remotely, without a need for in-person meetings? We are open to travel as needed and/or required.

It is up to the contractor awarded the project to determine how best to meet the needs of the contract.

87. Existing content: Can you share some estimates of the number of pages, images, and files (PDFs and images) for the current 3 websites, to get a sense of the scope of the migration. Please include any additional data that will need to be migrated (e.g. directories, special databases)

The state will determine pages and documents to retire prior to migration. As it currently exists:

DOE.sd.gov -- 451 pages, 13,300 documents History.sd.gov -- 416 pages, 1,776 documents Library.sd.gov -- 171 pages, 321 documents

88. Databases and directories: Can you provide a list of any searchable database, directories or other web-based tools that go beyond basic pages and standard content?

The educational directory (https://doe.sd.gov/ofm/edudir.aspx)

89. Updating content: Do you wish to keep or migrate all existing content to the new site build “as is”, or do you plan to review, edit and/or cut any unused or outdated content beforehand?

The State reserves the right to cull some pages before migration.

90. Newsletter platform: What do you use today to manage and publish email newsletters? If it’s an internal tool, are you open to a third party solution?

The State will evaluate all proposed solutions, including third-party solutions. The current newsletter is embedded into an email.

91. Email blast: Does "newsletter creation and email blasts" require the CMS itself to send email, or is integration with an existing email/newsletter service acceptable?

Integration is acceptable.

92. Data Visualization: For data visualization and Power Bi, is the expectation to embed existing charts into the site or building/integrating new data visualizations from State data?

The State’s expectation is for the vendor to embed existing data and charts.

93. Data Ingestion: Section 4.2.2 requires State access to data for ingestion into a state repository via Power BI, ESRI, Tableau, etc. What data does the State expect to ingest — site analytics, form submissions, content data, or something else?

The State does not expect to require form submissions. We expect site analytics and contact data.

94. Microsites: The RFP calls for the ability to create microsites. Beyond the three main websites, how many additional microsites do you anticipate? What does a “microsite” mean in the context of your use case? (e.g. separate branding, different editors, different URLs?)

The State anticipates a maximum of five, temporary microsites at any one time. By microsite, the state means a small, 4-5 page website for short-term use. There would be no separate editors and branding would be consistent with the overall site branding.

95. Please confirm if this is a new initiative or a re-bid of an existing contract?

New initiative.

96. Please confirm the budget allocated for this project.

The budget will be determined after the proposals are received and reviewed.

97. If it is a re-bid, please share the names of the current service providers/incumbent vendors? Additionally, how many active resources are working under the previous contract?

Not applicable, not a rebid.

98. Please provide the historical spending associated with this contract.

Not available.

99. Are there any specific challenges, pain points or areas of concern that you are currently experiencing with the existing vendors?

There are no existing vendors. The sites are not on a CMS.

100. Please clarify the anticipated number of awards expected under this RFP.

The State expects to make one award.

101. Is there a local preference in connection with this RFP?

Please see scoring rubric in section 7.2.

102. Please confirm the evaluation criteria and weighting (e.g., technical vs. cost).

Please see scoring rubric in section 7.2.

103. Will there be an opportunity for a virtual/on-presentation or negotiation meeting during the evaluation process?

Yes.

104. What is the expected timeline for award notification and contract execution?

See section 1.3.

105. What is the anticipated volume of staffing requests (e.g., estimated number of requisitions per year)?

The State does not have an estimate at this time.

106. Could you please provide details on the job categories, labor classifications or skill sets most requested?

The State does not have this information.

107. Is there an employee conversion policy (i.e., can the department directly hire contractor staff after a defined period)?

The State does not anticipate hiring FTE out of this award.

108. Will timekeeping be handled through the department’s system or will vendors be required to provide a platform?

The vendor will be expected to bill the State and the State will pay from invoices. The State will not handle the vendor’s timekeeping for them.

109. In the event of a contract award, please clarify whether awarded vendors will be permitted to directly engage with individual departments/agencies for staffing requests or if all requirements will be routed through a centralized system?

The State’s communication team consists of a maximum of five individuals. The vendor will be expected to engage with that team. The vendor is expected to provide the support team necessary to complete requirements of the contract.

110. The RFP references vendor-hosted, State-hosted (on-premises), and State cloud-hosted PaaS deployment models. Will the State consider a fully managed vendor-hosted Platform-as-a-Service (PaaS) CMS solution, provided it meets all security, availability, data ownership, and contractual requirements?

Yes.

111. Given the "if available" / "if applicable" language in Section 6, please confirm whether offerors proposing only a vendor-hosted solution are expected to submit pricing for State-hosted deployment options, or whether a vendor-hosted pricing proposal alone satisfies the cost proposal requirements.

The vendor should submit a cost proposal for whatever solution they are proposing.

112. Please clarify what the State intends by a "State cloud-hosted PaaS solution":

the vendor's software deployed into the State's BIT-managed cloud tenancy; or a vendor-operated managed cloud platform consumed by the State as a service?

The State’s intent is that any solution deployed into the State’s BIT‑managed cloud tenancy must be architected as a Platform‑as‑a‑Service (PaaS) solution. This means the vendor’s software will run within the State‑managed Azure environment using PaaS‑based components and services that conform to BIT’s cloud, security, and operational standards.

113. For offerors proposing a vendor-hosted solution, how should the State-hosted requirements in Section 4.3 (e.g., Load Balancing, Abstraction Technologies, and State Standard Hardware/Software) be addressed in the proposal? Should these requirements be identified as not applicable, or should offerors describe equivalent capabilities provided by the vendor-hosted platform?

A vendor-hosted solution is not being hosted by the State, so state-hosted solutions requirements do not apply.

114. For a vendor-hosted solution, does the State recognize a FedRAMP Moderate Authorized environment as meeting or exceeding the State's security requirements for this procurement?

Yes.

115. Section 4.2.9 requires vendor-hosted offerors to provide their most recent full vulnerability scan report during the Technical Review. Please confirm whether an equivalent third-party assessment and continuous monitoring package (e.g., FedRAMP System Security Plan (SSP) and Continuous Monitoring (ConMon) artifacts) will be accepted in lieu of, or alongside, that report, and whether a non-disclosure agreement (NDA) may be executed to facilitate sharing. Additionally, please confirm that the State-performed vulnerability scan cost assumption described in Section 4.2.9 does not apply to vendor-hosted solutions.

While a FedRAMP SSP and continuous monitoring artifacts provide valuable insight into overall system security posture and control implementation, they generally do not offer the level of technical detail we require for validating the results of a web application–specific vulnerability scan or evidence of remediation of the findings. We would accept these alongside a detailed web-application vulnerability scan report. A NDA can be in place to facilitate the sharing.

116. Section 4.2.3 requires SSO integration via OAuth 2.0 and states that non-compliance may result in proposal rejection. Please confirm that OAuth 2.0/OpenID Connect (OIDC) integration with the State's identity provider satisfies this requirement, and identify the State's identity provider.

OAuth 2.0/OIDC integration with the State meets the SSO Requirements.

117. Section 5.13 requires a disaster recovery plan because "vendor-hosted solutions will not be covered by the State's disaster recovery plan." Please confirm whether a vendor's native platform disaster recovery capabilities—including backups, geographic redundancy, and documented recovery procedures—satisfy this requirement, or whether the State expects a separately documented and costed, State-specific disaster recovery plan.

The vendor should supply the native platform’s disaster recovery capabilities.

118. What CMS platforms currently power doe.sd.gov, history.sd.gov, and library.sd.gov, and are all three expected to migrate into a single CMS implementation?

There is not currently a CMS for any of the three. All three URLs must remain separate. The state anticipates the same CMS for all three sites.

119. Can the State provide current website traffic metrics (annual or monthly users, page views, and peak traffic events) for each of the three websites?

Doe.sd.gov (2025): 283,000 users Library.sd.gov (2025): 7,000 users.

120. Section 3.2 notes that each website is behind State-controlled DNS and Cloudflare. Please confirm the expected division of responsibility between the State's Cloudflare implementation and any vendor-provided CDN/edge services, and whether the State intends to retain Cloudflare in front of the vendor-hosted origin.

The State is responsible for Cloudflare’s administration and configuration. Yes, the state will retain Cloudflare in front of the vendor-hosted origin. Beyond the three websites identified.in the RFP, approximately how many additional websites or microsites does the State anticipate supporting over the life of the contract?

The State currently envisions the contract encompassing at a maximum the three named websites.

121. Our public-sector contracts are frequently transacted through an authorized distributor/reseller. Please confirm that awarding through, and invoicing via, an authorized third-party distributor is acceptable, and clarify how this affects submission of the W-9 (Exhibit B) and the Prohibited Entity Certification (Exhibit C).

This is not acceptable.

122. The contract term begins September 1, 2026. Please confirm the State's budget/fiscal-year cycle and preferred payment schedule (e.g., annual payment in advance), and whether option years should be presented as separate line items within the cost proposal.

The State operates on a fiscal year that runs from July 1 through June 30. The state will not pay invoices in advance of work completion. The state will evaluate all proposed budgets and terms.

123. What are the platforms the three sites are currently operating on? Do any of the 3 sites currently use a CMS? Is content for the 3 sites stored in a database?

The State does not utilize a CMS for any of the three sites.

124. Payment functionality. Do any of the 3 sites process credit card payments or offer similar credit card processing?

Only history.sd.gov processes credit card payments.

125. How many expected content manager users does the state expect for each site? I.E., the users who will be logging into the system to add and manage content of the site.

The State anticipates five administrators accessing the site.

126. Can more information on the state hosted infrastructure be provided? Is the current infrastructure AWS, Azure, or a similar cloud infrastructure solution? Or are these sites operating from state managed data centers?

The sites are currently utilizing state managed data centers

127. What web servers are the three sites currently utilizing?

IIS

128. Is the state maintaining the current UX design and site look-and-feel as part of the transition or is a state interested in UX redesign as part of the project?

No.

129. Are there any place of performance requirements associated with the statement of work?

No.

130. CMS Preference – Does the State have a preferred CMS platform (e.g., Drupal, WordPress, Sitecore), or should vendors propose the system they believe best meets accessibility and integration requirements?

No, the State will evaluate all proposed solutions.

131. Accessibility Standards – The RFP references ADA/Section 508 compliance. Can you confirm if full WCAG 2.1 AA compliance is mandatory at launch, or if phased remediation is acceptable?

It is mandatory at launch.

132. Content Migration – Should proposals include a detailed migration plan (volume of pages, legacy systems, file formats), or will the State provide this information after award?

The State defers to the vendors on how best to respond to the RFP. The state will not provide the information in advance of an award.

133. Security & Vulnerability Scans – For vendor hosted solutions, the RFP requires vulnerability scan reports. Can you confirm if scans must be performed annually, or only prior to launch?

Security and Vulnerability Scans must be performed both before launch and annually thereafter as well as prior to release of major version changes.

134. Training Deliverables – Beyond live training sessions, should vendors provide written documentation, user guides, or recorded webinars for staff?

Yes.

135. Evaluation Criteria – Will nonprofit/government sector experience be considered an additional evaluation factor, or is evaluation strictly limited to technical skills, cost, and creativity?

See Section 7.2.

136. Budget & Cost Proposal – Should proposals remain strictly within the anticipated budget range, or can vendors propose optional add on services outside the budget for consideration?

The State will evaluate all submitted responses.

137. Post Launch Support – The RFP specifies 90 days of support. Should vendors also propose extended maintenance agreements (e.g., annual renewals), or will this be negotiated later?

The State anticipates a support and maintenance contract upon the completion of the initial contract. The state will factor in any provided terms for such contracts when evaluating the overall proposal.

138. Artificial Intelligence Use – The RFP requires disclosure of AI/GenAI tools. Can you clarify if vendors must provide detailed model information even if AI is only used internally during development (not in the final product)?

The vendor must disclose how they are using AI/GenAI tools, whether it is just for internal development.

139. Timeline Flexibility – The RFP outlines phases (Discovery, CMS setup, migration, testing, training, go live). Is the State open to alternative sequencing if continuity of operations is maintained?

Yes. The State defers to the expertise of the vendor.

140. CMS standard and hosting baseline. The RFP describes a state-hosted CMS but also requests separate responses for vendor-hosted, State on-premises, and State cloud/PaaS options. Is Drupal a required or preferred CMS, and if so, is there an approved major version or distribution? Which hosting model should be treated as the baseline solution and cost, and will the alternative hosting models be evaluated equally?

The State will evaluate all proposed solutions.

141. BIT platform, approval, and scan gates. For a Drupal deployment hosted by the State, please provide the target BIT platform specifications and responsibility split for operating system, web/PHP and database versions, containers or PaaS, source control/CI-CD, secrets, storage, backups/DR, logging, monitoring, patching, and deployment access. What BIT approval artifacts, architecture reviews, and vulnerability-scan/retest windows must be included before UAT and production launch?

The State will not host PHP-based/Drupal deployments.

142. Migration inventory and accessibility treatment. Can the State provide an inventory by site of pages/content types, PDFs and Office files, media, forms, databases, taxonomies, redirects, and searchable archives, together with available export or database access? Does “migration of all content and artifacts” mean lift-and-shift of every item, or should the vendor audit, remediate to WCAG 2.1 AA/Section 508, consolidate, archive, or retire content? Please identify who approves disposition and redirect mapping.

The State will provide an exhaustive inventory to the selected vendor. The state will determine what content to consolidate, archive, and/or retire. The state will remediate all documents to ensure they meet accessibility standards. The vendor will work with the state’s communications team for any mapping and proposed disposition.

143. Administrative SSO and role model. Does the OAuth 2.0 State SSO requirement apply only to CMS administrators and editors, or will any public-facing functions require authentication? Please provide the expected number of users and roles by agency/site, whether users need cross-site access, and the approved claims or group-based method for automated provisioning and offboarding. Should the three sites share one administrative tenant/workspace or remain logically segregated?

If the solution requires logins for public users, then the State’s SSO (OIDC Only) must be used.

144. Cloudflare, DNS, and cutover ownership. Which State team controls the three Cloudflare zones, and what work is expected from the vendor for DNS, TLS certificates, CDN/cache rules, WAF and bot/rate-limit policies, origin protection, redirects, cutover, and rollback? Can the current Cloudflare/DNS configuration and origin architecture be shared? Does the requirement that URLs remain the same apply only to the three hostnames, or also to all existing page and document paths?

All Cloudflare administration/configuration will be handled by BIT. Yes, the URLs must remain the same. Configuration cannot be shared until contract is awarded.

145. Converge/Elavon payment architecture. For each site, what payment transactions and approximate volumes must be supported, and are separate Converge/Elavon merchant accounts already configured? Should the CMS use an Elavon-hosted payment page/Lightbox, redirect, or direct API integration, and what transaction data may return to or be stored by the CMS? Please clarify responsibility for sandbox access, PCI scope/SAQ, refunds or reconciliation, and accessible checkout testing.

Only historical society memberships are processed through Converge.

146. Newsletter platform and sender identity. Is the approximately 10,000-person audience one shared list or multiple agency/program lists, and what are the expected send frequency, peak volume, segmentation, approval, unsubscribe, bounce, and reporting needs? Must the vendor migrate subscriber data, consent records, templates, suppressions, and campaign history from an existing platform? Given the restriction on using State email domains as the originating domain, what sender domain/provider and SPF, DKIM, and DMARC ownership should be assumed?

The State sends out multiple newsletters to a variety of lists; frequency is usually several times a week. Each send can have anywhere from several hundred emails to multiple thousand. Lists are typically generated each time an email goes out so there is no unsubscribe ability. The current mechanisms for sending newsletters are either through staff emails or through listserv.sd.gov. Reporting needs are open rates.

147. Microsite model and governance. How many microsites should be included at launch and over the contract term, and are they expected to use subdirectories, subdomains, or separate domains? Please clarify which features may vary by microsite (branding, navigation, permissions, content types, analytics, payments, newsletters), who may create them, and whether each microsite requires separate BIT review, Cloudflare/DNS configuration, accessibility validation, and development/UAT coverage.

The State anticipates no more than five, temporary microsites at any one time. BIT will scan anything that involves new coding. The state anticipates using a standard template for microsites.

148. Power BI and State data access. For Power BI, ESRI, Tableau, and the State data repository, is the requirement limited to embedding public dashboards, or must the CMS expose its own content, analytics, form, payment, or newsletter data for ingestion? Please identify the required datasets, refresh frequency, authentication method, API or flat-file preference, metadata/data-dictionary expectations, retention needs, and whether the State requires direct database access in a State-hosted deployment.

The State cannot identify all databases at this time.

149. Training, maintenance, and operating model. Please distinguish the required 90-day post-launch support from the maintenance agreement expected during the five-year contract. What staff groups and approximate counts require author, approver, administrator, accessibility, and technical training, and is train-the-trainer acceptable? For long-term operations, please identify expected service levels and ownership for help desk escalation, Drupal/core/module updates, security patches, accessibility monitoring, vulnerability remediation, backups/DR tests, minor enhancements, and the optional renewal years.

The State defers to the expertise of the vendor to submit an appropriate proposal.

150. Section 3.1.8 requires “State hosted architecture,” yet Section 4.4 defines vendor-hosted requirements and Section 6 invites vendor-hosted cost proposals. Is vendor hosting an acceptable primary option, or is State hosting mandatory?

The State will evaluate all proposed solutions.

151. What does the state-hosted environment consist of (on-prem VMware, state cloud provider/region, Kubernetes or other container platform)? Are Docker containers supported? Are Linux VMs available?

State –hosted environment is Azure. Containers are supported, but a PaaS architecture is preferred

152. Are Redis 8 (with Search/JSON modules) and Node.js 22/24 on the State's standard software list, or will BIT evaluate them as non-standard software under 4.3.5?

These will be evaluated as part of the State’s Technical Review for selected vendors.

153. What HA/DR does the State provide for state-hosted solutions (RTO/RPO), and does the State's disaster recovery plan cover state-hosted deliverables?

This has not been determined by the State.

154. For load balancing (4.3.3): does the State provide the load balancers, and is a horizontally scaled stateless app tier over a replicated data tier an acceptable architecture?

Load balancing will be determined based of the proposed solution architecture. s. A horizontally scaled, stateless application tier deployed over a replicated data tier is an acceptable architecture for solutions hosted within the State’s cloud environment.

155. Are the dev and UAT environments (3.3) hosted in State infrastructure, and who bears their infrastructure costs?

BIT Dev, UAT and Production environments should have the same hosting infrastructure. If the environments are hosted in the state cloud, then the state bears the infrastructure cost.

156. Where is TLS terminated (Cloudflare, State load balancer, or the application)?

Yes TLS will be terminated in Cloudflare

157. What are current/peak traffic volumes (page views, concurrent sessions) per site, for sizing and load testing?

Doe.sd.gov (2025): 283,000 users Library.sd.gov (2025): 7,000 users.

158. What platforms are the three current sites on, and can the State provide a content inventory (pages, documents, images, total storage) per site?

The State does not currently host these websites on a platform. There is no existing CMS.

The state will determine pages and documents to retire prior to migration. As it currently exists:

DOE.sd.gov -- 451 pages, 13,300 documents History.sd.gov -- 416 pages, 1,776 documents Library.sd.gov -- 171 pages, 321 documents

159. Are there dynamic applications or databases behind the current sites (directories, search tools, dashboards) that must be migrated or integrated?

Educational Directory -- https://doe.sd.gov/ofm/edudir.aspx

160. Is a content freeze or dual-run period expected during migration, and who signs off migrated content?

The State’s communication team will sign off on go live for migrated content. The state expects the old website(s) to be operational up until the moment the new website(s) go live. Any break in service must be minimal and approved by the state in advance.

161. Must existing deep URLs be preserved/redirected, or only the three root domains?

The State expects all URLs to be preserved.

162. Is a visual redesign of doe.sd.gov, history.sd.gov, and library.sd.gov expected as part of this scope, or should the offeror plan for a like-for-like “lift and shift” of existing content, layout, and branding onto the new CMS platform?

The State anticipates a “lift and shift” of existing content and branding.

163. What are typical transaction volumes for the e-commerce capabilities across the three sites?

Estimated 200-250, this varies greatly.

164. Does the State's Converge/Elavon account support hosted payment pages/redirect checkout so card data never touches the CMS? What PCI DSS scope does the State expect the offeror to carry?

Yes, No PCI should be stored on the website.

165. Does the State have an existing bulk-email platform (e.g., GovDelivery) the CMS should integrate with, or must the solution include sending, list management, and bounce/opt-out handling for ~10,000 recipients?

The State currently uses listserv.sd.gov to send out bulk emails. The state will evaluate any alternative solutions presented.

166. Per 4.2.12, what originating email domain should newsletters use, and who manages its SPF/DKIM/DMARC?

Azure communication services for outbound only.

167. Which languages are required, and is on-page machine translation acceptable versus maintained multilingual content?

On-page machine translation is acceptable.

168. Does the State have a standardized analytics product (GA4, Siteimprove, etc.) to integrate, or must analytics be native to the CMS? Does “document tracking” mean download counts per document?

PowerBI is our standard analytics product. Document tracking can include download counts per document.

169. For PowerBI/ESRI/Tableau access: is scheduled API or flat-file extraction into the State data repository sufficient, or is direct database connectivity required? What refresh frequency is expected?

The State prefers API integration. The refresh frequency will be mutually agreed upon to meet reporting requirements.

170. Confirm the State's SSO is Microsoft Entra ID via OAuth 2.0/OIDC. Is SSO required only for CMS editors/admins, or do any public-facing features require citizen login?

If the solution requires logins for public facing features, then the State’s SSO (OIDC Only) must be used. Local accounts are not allowed.

171. Is a third-party identity broker between the CMS and the State's SSO acceptable for a state-hosted deployment, or must the application federate directly with the State's identity endpoint?

The application must federate directly with the State’s identity Provider.

172. Beyond the 4 administrators, how many total editors/contributors are expected across the three sites?

The State does not have an estimate of the total number of editors or contributors at this time.

173. Does the State support SCIM provisioning from its directory, or should onboarding be driven by SSO group claims?

The State supports, and prefers, the use of SCIM for provisioning.

174. If AI features are optional modules, may the offeror propose the solution with AI disabled? Are cloud AI services (e.g., Azure OpenAI in a US region) permissible if enabled?

Any use of AI must be evaluated and approved by the State.

175. Is there an incumbent vendor or platform under consideration, and is a budget range available?

There is no incumbent vendor or platform. The state will evaluate all proposals submitted.

176. Does the State intend to sole-source and directly contract the awarded scope of this RFP with the winning offeror, or will the resulting contract be executed through a third-party or cooperative purchasing entity (e.g., a state term contract, NASPO ValuePoint, or similar vehicle)?

The winning offeror will result in a contract directly with the winning bidder.

177. For state-hosted deliverables, how far before go-live must the build be delivered for the State's vulnerability scan, and what is the remediation/re-scan cycle?

1-2 months to allow for remediation and rescan.

178. What support level/SLA is expected after the 90-day post-launch period for the remainder of the contract term (the “maintenance agreement” in 1.2.2)?

The Vendor should propose and will be negotiated if awarded.

179. Section 1.4 caps email submission (including attachments) at 20MB. Given the required system diagram, solution diagram, cost proposal, resumes, and audited financials, is a secure upload portal or split-email process acceptable if the complete package exceeds that limit?

Yes, both are acceptable.

180. Section 5.6 asks for system and solution diagrams as separate documents. Do these count toward the 2-page Executive Summary limit in Section 5.2, or are they excluded as attachments?

They can be excluded as attachments.

181. Section 5.4 requires a Microsoft Project schedule as a separate Excel attachment. Is this schedule required at proposal submission, or is a high-level timeline sufficient at proposal stage with the detailed MS Project schedule delivered after award/kickoff?

A high-level timeline is sufficient for proposal.

182. Is there an existing brand/style guide (colors, typography, logo usage) for the DOE, History, and Library sites that the mock templates in Section 1.2.2 should follow, or is establishing/refreshing that branding part of the offeror's scope?

The State expects the sites to conform with existing branding.

183. Is there a current maintenance or support contract in place for any of the three existing sites, and if so, does its expiration date create a transition dependency the project plan should account for?

No.

184. Section 1.12 allows for 3 one-year renewal periods beyond the initial 5-year term (Sept 2026–Aug 2031). Should the cost proposal include pricing for those optional renewal years, or only the initial term?

The State will evaluate…