PR9041__Addendum_1.pdf

PR9041

Cybersecurity Governance, Risk & Compliance Solution

ADDENDUM 1

DATED: August 13, 2026

The RFP has been amended as stated below (or on the following page).

In your Proposal submittal, you MUST note this Addendum was received OR YOUR PROPOSAL MAY BE CONSIDERED NON- RESPONSIVE. If additional information is required regarding this RFP, please feel free to contact the buyer of record at asegura@ouc.com. Thank you for your participation in this RFP.

All proposals must be submitted no later than 2:00 PM EST on August 27, 2026.

Questions/Clarifications:

1. Does this include IT as well as OT systems or limited to IT?

• This is limited to IT Systems. OT compliance is managed by another department.

2. Could OUC identify the incumbent GRC platform or solution provider, if any, and confirm whether this procurement is intended to replace an existing solution or implement a new platform?

• Our department does not have an existing GRC platform.

3. Could OUC provide additional information regarding the primary business objectives, operational challenges, or pain points that prompted this procurement?

• The objectives are listed in Section 1.2 of the solicitation. Our overall goal is to have a more efficient method of tracking, managing, and reporting risk..

4. Will the selected vendor be required to migrate data from an existing GRC platform or other repositories? If so, could OUC provide a high-level overview of the expected migration scope?

• There is no expected migration as we track through spreadsheets, MS365 tools.

5. Could OUC identify any enterprise applications or systems that are expected to integrate with the proposed solution, beyond those described in the solicitation?

• We prefer integration capabilities that are not solution specific; however, at a minimum, we would like to Integrate with Halo ITSM and BitSight (if your solution does not offer risk scoring capabilities)..

6. Could OUC provide an estimated number of users (e.g., administrators, business users, reviewers, approvers, and read-only users) that should be considered for licensing and implementation planning?

• We anticipate a primary and back-up administrator. Estimated users (identified as a risk owner, required to update status, or accept a risk) is no more than 200. Read-only users are expected to be less than 30.

7. In addition to the frameworks referenced in the solicitation, are there any other regulatory, cybersecurity, or utility-specific frameworks that OUC expects the proposed solution to support?

• No but we recommend you list any other capabilities (e.g., HIPPA, PCI, or other compliance standards).

8. Is there a preferred project start date, target go-live date, or expected implementation timeframe that vendors should consider while preparing the implementation plan?

• This is dependent on the implementation plan and resources needed from IT. We would like to start in September / October.

9. Does OUC anticipate implementing all required capabilities in a single phase, or would a phased implementation approach be acceptable?

• This is most likely dependent on the solution. If a phased approach for a specific solution is the vendor’ recommendation for successful implementation and we agree the approach is feasible, this would be acceptable.

10. Considering that the scope is limited to a cybersecurity GRC software platform and related implementation and professional services, will OUC consider granting an exemption from the Pollution Liability Insurance requirement where such coverage is not applicable to the services being provided?

• Yes; this is standard language in our template and does not apply to a GRC solution

11. If a proposer includes a technology partner or software OEM as a subcontractor, may the proposer rely on the partner's product experience, implementation experience, project references, and key personnel qualifications to demonstrate the required experience and qualifications?

• Yes; however, the proposer will be accountable for overall performance and must disclose use of a subcontractor in the proposal / contract.

12. Current or prior incumbent vendor(s) providing a Cybersecurity Governance, Risk, and

Compliance (GRC) platform, enterprise risk management software, or third-party risk management (TPRM) solution — including any vendor previously providing a comparable GRC or cyber risk platform — to OUC

13. Contract term and expiration date of any active or recently expired agreement for these or similar cybersecurity GRC or enterprise risk management platform services

14. Historical contract value or annual spend associated with the current or prior GRC or cybersecurity risk management platform engagement

• Our department does not have an existing GRC platform

15. Scope of services provided under any active or prior contract, including specific products or platform names, license types, user counts, supported frameworks (e.g., NIST CSF, or other regulatory frameworks), integration components, third-party risk intelligence feeds, and any related implementation, training, or professional support services covered

16. Any publicly releasable award information, including prior solicitation numbers, award notices, contract documents, or bid tabulations associated with a previous procurement for cybersecurity GRC, enterprise risk management, or third-party risk management platform services at OUC

17. Have you guys reviewed any manufacturers/vendors yet and are interested in anything in particular at this time? I know there is nothing in place but curious what you have looked at?

• The RFP was issued to evaluate different approaches, functionality, and best solutions to meet our needs. We do not have a particular vendor in mind; we would like to see available options.

18. Do you require a FedRamp environment?

• We are not a Federal Agency and do not require a FedRamp environment. When evaluating solutions, FedRAMP certification, SOC 2, ISO/IEC 27001, and other independent security certifications are preferred.

19. What was driving the need for this platform? Mostly compliance with a certain standard Orlando is implementing?

• The primary driver is to establish a centralized and scalable capability for managing cybersecurity risk. The solution should support Third-Party Risk Management (TPRM), Criticality Impact Assessments (CIA), Preliminary Risk Analyses (PRA), Threat Risk Assessments (TRA), a centralized cybersecurity risk register, configurable workflows, reporting, dashboards, and related risk treatment and monitoring activities. The objective is to improve consistency, automation, traceability, and visibility across OUC's cybersecurity risk management processes.

20. Is the platform selection part of the proposal or expecting bidders to come up with recommended platform along the solutioning?

• The platform selection is central to the proposal.

21. Sounds like automation and integrations would help a lot. Do you have a top 5 product list you'd want to integrate with?

• Microsoft 365 is a priority integration. OUC would also like the solution to provide native integrations and/or standards-based APIs that support integration with Microsoft Entra ID, SIEM/security monitoring, vulnerability management, IT service management/ticketing, third-party risk intelligence, procurement/vendor management, and applicable asset management systems. Halo ITSM is a potential integration. OUC is interested in understanding the proposer's available out-of-the-box integrations, API capabilities, and ability to support additional integrations as the program matures. Specific Phase 1 integrations and implementation priorities may be further defined with shortlisted vendors.

22. Is the requirement that OUC be able to map risks, controls, assessments, and evidence to supported frameworks and manage multiple frameworks concurrently expected to be operational at Phase I go-live, or is this a capability OUC wants to explore for future consideration, with no impact on the initial TPRM implementation scope?

• Yes. OUC expects framework and control mapping to be part of the core functionality available in Phase 1. Where the solution provides established assessment questionnaires or content libraries, such as SIG, CAIQ, or similar industry-standard content, OUC expects the applicable mappings to supported frameworks to be available out of the box and offered by the vendor.

• OUC also expects the solution to support mapping of OUC's internal cybersecurity policies, standards, controls, risks, assessments, and evidence to applicable frameworks. OUC recognizes that configuration may be required to establish OUC-specific mappings during implementation. The solution should support managing multiple frameworks and mappings concurrently as the program matures.

23. If included in Phase I, how many frameworks (e.g., NIST, ISO) does OUC intend to map risks, controls, assessments, and evidence to at go-live?

• OUC does not intend to prescribe a specific number of frameworks that must be configured at go-live. The solution should provide out-of-the-box support and mappings for the industry-standard frameworks and assessment content included with the proposed platform. OUC expects to establish mapping between its internal cybersecurity policies, standards, and controls and applicable supported frameworks as part of implementation. The solution must support multiple frameworks concurrently and allow additional frameworks and mappings to be added as the program matures.

24. For any additional frameworks anticipated beyond Phase I, should those be priced now as part of the initial proposal, or treated as a separate future-phase cost?

• Vendors should identify the framework and assessment content libraries included in the base subscription and clearly identify any additional licensing, subscription, or professional services costs associated with adding or maintaining additional frameworks. Vendors should also identify any costs associated with configuring and maintaining mappings between OUC's internal cybersecurity policies, standards, and controls and supported frameworks. OUC expects the solution to support adding and mapping additional frameworks as the program matures. Where applicable, vendors should distinguish between one-time implementation / configuration costs and recurring subscription or content-library costs.

25. Can you elaborate on the current nature of your application infrastructure?

• We will share this information with vendors that are selected for the next phase (demonstrations).

26. Is your infrastructure mostly comprised of cloud-based applications or on-premise systems?

• Both.

27. Does OUC leverage a vulnerability/asset management platform such as Tenable or Rapid7 that we can integrate with to extract data-sets at the control level?

• Yes. OUC utilizes vulnerability and asset management capabilities. OUC expects the proposed solution to support integration with applicable vulnerability and asset management platforms through native integration and/or standards-based APIs.

Specific platforms, data elements, and integration priorities may be provided to shortlisted vendors. Vendors should describe their supported integrations and capabilities for importing or associating applicable vulnerability, asset, and control-related information with risks, assessments, findings, and remediation/treatment activities.

28. (Microsoft Ecosystem Integration): Regarding technical evaluation and system compatibility, does OUC give preference to cloud-hosted GRC platform solutions that offer native, API-level integration with the Microsoft Security ecosystem (e.g., Microsoft Defender, Entra ID, Purview) to automate control validation and evidence collection?

• Yes. Microsoft 365 and Microsoft Entra ID are priority integration capabilities. OUC values native and/or standards-based API integration with applicable Microsoft security and information-protection capabilities where those integrations can improve workflow automation, evidence collection, control validation, identity management, or risk visibility. Vendors should identify available out-of-the-box Microsoft integrations, API capabilities, associated functionality, and any additional licensing or implementation costs.

29. (Exhibit 1 - Backup Frequency Standard): In Exhibit 1, Section 2.1.d (Data Management - Backup), there are checkboxes for backup frequencies (Hourly, Daily, Weekly, Monthly).

Could OUC clarify if a standard daily automated backup with encrypted offsite replication meets OUC’s operational and business continuity requirements for the cloud-hosted GRC platform?

• We would like proposers to state their backup frequencies to allow for comparison with other vendors.

30. (Minimum Qualifications & Corporate Registration): Section 1.4 (Item 9.b) states that non-registered Bidders must be registered with the Florida Department of State (Sunbiz) by the time the Notice of Intent to Award is issued. Please reconfirm that submitting proof of active Sunbiz registration upon receipt of the Notice of Intent to Award fully satisfies this requirement without penalty or deduction of points during the initial proposal evaluation.

• Submitting proof of active Sunbiz registration upon receipt of the Notice of Intent to Award fully satisfies this requirement without penalty or deduction of points during the initial proposal evaluation.

31. OT / ICS Scope - Please confirm whether the platform is intended to support only enterprise IT and business risk management activities, or whether Operational Technology (OT) and Industrial Control System (ICS) environments are also within scope. If OT is in scope, please identify any planned use cases involving electric and water utility operational environments, including SCADA, EMS/DMS, generation, transmission, distribution, or water operations.

• The initial implementation will focus on enterprise IT cybersecurity risk management; however, OUC intends to extend the same cybersecurity risk management and TPRM processes to applicable OT/NERC assets. OUC does not intend to establish separate IT and OT risk management processes within the platform. The proposed solution should support both IT and OT risk use cases using configurable workflows, assessment tiering, and risk-based assessment requirements. Applicable NERC assets may require enhanced or full assessment workflows based on OUC-defined risk, criticality, data, and regulatory requirements.

Specific OT/NERC use cases and implementation sequencing will be further defined as the program matures.

32. Compliance Framework Requirements - Please identify the compliance and cybersecurity frameworks that must be supported at go-live and over the contract term, including any requirements for NERC CIP, NIST 800-53, NIST 800-82, IEC 62443, ISO 27001, AWIA, or other utility-specific standards.

• OUC expects the solution to support multiple cybersecurity, risk, and compliance frameworks concurrently. At a minimum, OUC is interested in support for NIST Cybersecurity Framework (CSF), NIST SP 800-53, ISO/IEC 27001, and applicable NERC CIP requirements. The solution should also be capable of supporting additional frameworks and utility-specific requirements, such as NIST SP

800-82, CIS Controls, IEC 62443, and other applicable regulatory or industry frameworks as OUC's program matures. Vendors should identify the frameworks and versions available out of the box, available mappings between frameworks, any associated content-library licensing costs, and the process for adding or updating frameworks. OUC's use of a supported framework or mapping does not necessarily indicate that OUC is seeking certification or asserting compliance with that framework.

33. Third-Party Risk Management Scope - Please confirm whether third-party risk management requirements include support for utility supply chain cybersecurity programs, including NERC CIP-013 processes, or whether the scope is limited to enterprise vendor risk management.

• OUC intends to use the TPRM process for both enterprise IT and applicable OT/NERC third parties. The same overall risk-based TPRM process is expected to apply; however, applicable NERC assets may require enhanced or full assessment workflows based on OUC-defined risk, criticality, data, and regulatory requirements.

The solution should support configurable assessment tiering and workflows to accommodate these requirements. Vendors should identify and separately price any additional NERC CIP-specific content libraries, functionality, licensing, or professional services required.

34. Asset Scope and Record of Authority - Please define the asset population expected to be managed within the solution and identify the authoritative source systems for those assets.

Examples may include CMDBs, IT asset management systems, OT asset inventories, vulnerability management platforms, or native solution records.

• The GRC solution is not intended to replace OUC's authoritative asset management systems. The solution should support associating risks, assessments, controls, findings, and remediation activities with applicable business systems, applications, and other in-scope assets. Where appropriate, OUC would prefer the ability to integrate with authoritative asset inventory or asset management systems rather than maintain duplicate asset records within the GRC platform. Additional details regarding source systems may be provided to shortlisted vendors.

35. Hosting and Security Requirements - Please identify any hosting, data residency, security, or administrative access requirements that may impact solution architecture, including cloud deployment restrictions, geographic hosting requirements, or limitations on support personnel access.

• OUC requires that OUC data be hosted, stored, processed, and transmitted within the United States. Hosting within a Florida region is preferred, where available, but is not mandatory. The proposed solution must meet the security requirements defined in the RFP and applicable OUC security standards. Vendors should identify the proposed hosting location(s), cloud region(s), and any locations from which OUC data may be accessed, processed, or supported.

36. Deployment Model - Please confirm which deployment models will be considered, including

SaaS, single-tenant cloud, private cloud, government cloud, or on-premises deployments.

• OUC prefers a secure Software-as-a-Service (SaaS) cloud solution. Government cloud is preferred where available but is not mandatory. The proposed solution must meet the security, hosting, and U.S. data residency requirements defined in the RFP.

37. Integration Requirements - Please identify the systems expected to integrate with the solution at initial implementation, including identity management, ITSM, CMDB, ERP, procurement, vulnerability management, and any OT asset management or monitoring platforms.

• OUC's priority integration capabilities include Microsoft 365, Microsoft Entra ID for identity/SSO, SIEM/security monitoring, vulnerability management, Halo ITSM, third-party risk intelligence, PASS/procurement, and applicable asset management systems. OUC expects the proposed solution to provide native integrations where available and standards-based APIs to support additional integrations. Specific Phase 1 integrations, sequencing, and data-exchange requirements may be further defined with shortlisted vendors. OT is currently out of scope.

38. Existing Platform and Data Migration - Please identify any incumbent GRC, risk, compliance, or third-party risk management platforms currently in use and indicate whether migration of historical records, assessments, evidence, findings, and vendor data is required.

• OUC does not currently have an enterprise GRC platform for cybersecurity risk management. Procurement currently uses a customer-built procurement automation sourcing system (PASS), which contains historical vendor and assessment information and will remain an existing system of record.

OUC does not anticipate replacing PASS as part of this implementation. As a possible future project to increase efficiency, OUC expects the proposed GRC solution to support integration with PASS to enable the Third-Party Risk Management (TPRM) process. Your solution must support common industry-standard integration methods, including modern API-based interfaces, to ensure seamless interoperability with our existing systems

39. Environment Requirements - Please confirm the required environments (e.g., Development, Test, Training, Sandbox, Production) and whether non-production environments are expected to be included within the proposed solution.

• OUC requires a Production environment and a separate non-production environment (e.g., Sandbox, Test, or equivalent) that allows OUC to configure, develop, and test workflows, integrations, questionnaires, risk models, framework mappings, automation, and other system changes without impacting the Production environment. Vendors should describe the non-production environments included with the proposed SaaS solution, their intended uses, any limitations, and any additional associated costs.

40. Demonstration and Pilot Expectations - Please clarify expectations for vendor demonstrations or pilots, including evaluation criteria, required use cases, expected duration, and whether OUC-provided data will be used during the evaluation process.

• When demonstrations are scheduled, we will send out a script with applicable use cases.

41. User and Vendor Volumes - Please provide estimated user counts by role and approximate third-party/vendor volumes to support solution sizing, licensing, and implementation planning.

• OUC anticipates approximately 2–3 ECRM users who will regularly administer the solution and perform risk and third-party risk assessments. However, the solution must also support a broader population of occasional business users across OUC who may need to access the platform to provide information, complete assigned questionnaires or attestations, respond to assessment requests, review findings, or participate in applicable risk and TPRM workflows.

• The number of occasional business users has not yet been determined and may vary based on business demand. Vendors should clearly describe their licensing model for administrative/power users, occasional or business users, and external third-party users, including any associated licensing limitations or costs.

42. Implementation Timeline - Please provide the anticipated project timeline, including target award date, implementation start date, and desired go-live objectives.

• OUC anticipates beginning implementation in October. OUC's objective is to have core Phase 1 functionality operational by the end of the year. OUC recognizes that implementation may require a phased approach and expects vendors to propose a realistic implementation schedule based on their methodology, dependencies, resource requirements, and recommended sequencing.

43. From our review of Sections 1.7 and 1.8 of the RFP and the documents supplied as Exhibits, it is not clear to us what documentation is expected to be used as base of the contact negotiation. As per Section 1.7, OUC requests Bidder to submit its terms and conditions for review, while Section 1.8 refers to OUC’s sample contract, the General Terms and Conditions (Exhibit 3) and Software License Terms and Conditions, so please confirm what terms are expected to be used as base for the contract negotiation.

• OUC’s Terms and Conditions will serve as the baseline for contract negotiations. If the supplier has additional terms—such as an End User License Agreement (EULA) or other solution-specific requirements--those may be incorporated into the final agreement, subject to OUC’s review and approval.

44. If OUC’s terms (as per Sect. 1.8 of the RFC) are to be used as base of the contact negotiation

(OUC’s Sample Contract and/or the General Terms and Conditions (Exhibit 3), and Software License Terms and Conditions are to be used, will UOC entertain proposed edits and deviations by Bidder and at what stage are these to be presented? Note that Section 3.20 of the RFP indicate that the expectation is for the Contract is to be executed by Bidder within 10 business day of receipt from OUC.

• Please note them on the exception's page, on the compliance submittal forms.

Proposals which include excessive or erroneous exceptions, or are considered to be incomplete, could be considered irregular and disqualified from being made part of the evaluation and rankings.

45. As per Section GC 15.0 of the General Term and Conditions document, Supplier is to pay all sales, use and other taxes. Please confirm if Bidder may invoice OUC for said sales, use and other similar taxes as separate invoice line items.

• As a statutory utility, OUC is tax-exempt.

46. RFP Page 5, Section 1.1 – Scope of Work Summary / Pages 21–23, Detailed Scope of Work & Requirements - Please provide OUC’s approximate total employee population and the number of employees expected to participate in the solution as risk owners, control owners, assessors, approvers or remediation owners

• OUC has not established a specific number of employees who will require access to the solution. OUC anticipates approximately 2–3 ECRM users who will regularly administer the solution and perform cybersecurity risk and third-party risk assessments. The solution must also support a broader population of occasional business users who may participate as risk owners, control owners, assessors, approvers, remediation owners, delegates, questionnaire respondents, or other workflow participants. The number of occasional business users will vary based on business demand. Vendors should describe how these different user types are accommodated within their licensing model and identify any associated licensing limitations or costs.

47. RFP Pages 21–23, Detailed Scope of Work & Requirements / Page 24, Price Schedule - Please provide the anticipated number of users by category, including:

• Please also clarify whether OUC prefers named-user, concurrent-user or another licensing model.

• Platform administrators

• Full or frequent users

• Occasional business users

• Executive or read-only users

• External third-party users

• OUC anticipates approximately 2–3 ECRM administrative/power users who will regularly administer the solution and perform cybersecurity risk and third-party risk assessments. Additional users may include occasional business users, risk owners, delegates, control owners, remediation owners, approvers, executive/read-only users, and external third-party users. The number of users within these categories has not yet been finalized and may vary based on business demand.

• OUC does not currently prescribe a named-user or concurrent-user licensing model.

Vendors should recommend the licensing approach that provides the best value and scalability for OUC's anticipated usage pattern and clearly describe licensing requirements and costs for administrators/power users, frequent users, occasional business users, executive/read-only users, and external third-party users. Vendors should identify any limitations associated with named users, concurrent users, workflow participants, external users, or other licensing metrics.

48. RFP Pages 21–22, Third-Party Risk Management

• OUC currently anticipates a baseline of approximately 52 third-party cybersecurity risk assessments annually. Assessment volumes are expected to increase as the TPRM program matures and workflow automation improves. The total population of third parties to be maintained or monitored within the solution has not yet been finalized. The frequency and depth of assessments and reassessments may vary based on the third party's risk profile and applicable OUC requirements.

Vendors should clearly describe any licensing, pricing, or technical limitations based on the number of third parties, assessments, questionnaires, reassessments, or monitored vendors.

49. What third party monitoring platforms does OUC want to integrate with?

• OUC currently utilizes third-party cybersecurity risk intelligence/security-rating capabilities. OUC expects the proposed solution to support integration with external third-party risk intelligence and security-rating platforms through native integrations and/or standards-based APIs. Specific platforms and integration priorities may be provided to shortlisted vendors. Vendors should identify the third-party risk intelligence platforms they support natively, available API integration capabilities, and any additional licensing or implementation costs.

50. RFP Pages 21–22, Integration and External Vendor Risk Intelligence Integration - How many integrations does OUC expect as part of the initial implementation? Please identify the systems or platforms to be integrated at go-live and distinguish them from potential future integrations.

party risk intelligence, PASS/procurement, and applicable asset management systems. OUC expects the proposed solution to provide native integrations where available and standards-based APIs to support additional integrations. Specific platforms, integration sequencing, and data-exchange requirements may be further defined with shortlisted vendors.

51. RFP Pages 21–22, External Vendor Risk Intelligence Integration - Does OUC currently use a third-party cybersecurity rating or continuous vendor-monitoring service? If so, please identify the platform and describe the data OUC expects to exchange with the proposed GRC solution.

third-party risk intelligence and security-rating platforms through native integrations and/or standards-based APIs. Specific platforms and integration priorities may be provided to shortlisted vendors. Vendors should identify the third-party risk

52. RFP Pages 21–22, Integration - Please identify any anticipated integrations with identity management, ticketing, asset/CMDB, procurement, vendor management, vulnerability management, SIEM, business intelligence or document-management systems.

party risk intelligence, PASS/procurement, and applicable asset management systems. OUC expects the proposed solution to provide native integrations where available and standards-based APIs to support additional integrations. Specific Phase 1 integrations, sequencing, data elements, and data-exchange requirements may be further defined with shortlisted vendors. Vendors should identify available native, configurable, and API-based integrations and any associated licensing or implementation costs.

53. RFP Page 5, Scope of Work Summary / Pages 21–22, Enterprise Risk Management and TPRM - What systems, spreadsheets, databases or repositories are currently used to manage enterprise risk, cybersecurity risk, third-party risk, controls, evidence and remediation?

• OUC does not currently have an enterprise GRC platform for cybersecurity risk management. Cybersecurity risk management processes are currently largely manual. Procurement uses PASS, which contains historical vendor and assessment information and will remain an existing system of record. Enterprise Risk Management and Internal Audit are managed separately and are not the primary focus of this implementation.

54. RFP Page 5, Scope of Work Summary – Data Transfer - Please describe the anticipated data-migration scope, including source systems, approximate record and attachment volumes, historical-data requirements and preferred file formats.

• OUC does not currently anticipate requiring a full migration of all historical PASS records into the GRC platform. However, OUC expects the solution to support integration with PASS and the ability to access, reference, or exchange relevant historical vendors and assessment information where appropriate. Specific historical-data and migration requirements, including applicable records, attachments, source formats, and import requirements, will be defined during implementation.

55. RFP Page 23, Content Libraries and Framework Support - In addition to NIST CSF and ISO, which specific regulatory, cybersecurity or utility frameworks must be included at go-live— for example, NERC CIP, NIST 800-53, CIS Controls or other OUC-specific control libraries?

• OUC expects the solution to provide out-of-the-box support for multiple cybersecurity and compliance frameworks. Priority frameworks include NIST Cybersecurity Framework (CSF), NIST SP 800-53, ISO/IEC 27001, and applicable NERC CIP requirements. OUC also values support for NIST SP 800-82, CIS Controls, IEC 62443, and other applicable utility or cybersecurity frameworks. OUC does not intend to prescribe that every supported framework be fully configured at initial go-live. Vendors should identify the frameworks, versions, content libraries, and cross-framework mappings included with the proposed solution and any additional licensing or implementation costs.

56. RFP Page 5, Scope of Work Summary / Page 23, Scalability and Extensibility - Does OUC have a target implementation start date, initial go-live date and preferred sequence of use cases? Please identify the capabilities considered mandatory for Phase 1.

• OUC anticipates beginning implementation in October, with the objective of having core Phase 1 functionality operational by the end of the year. Phase 1 should prioritize enterprise IT cybersecurity risk management capabilities, including TPRM, configurable cybersecurity risk assessments and workflows, centralized cybersecurity risk tracking, dashboards and reporting, framework/control mapping, and applicable foundational integrations. OUC is open to phased implementation and expects vendors to recommend the most effective sequencing based on dependencies, business value, and implementation methodology. Applicable OT/NERC capabilities may be expanded in subsequent phases using the same overall cybersecurity risk management process.

57. Existing Third-Party Risk Intelligence Solution and Required Integrations OUC indicated during the pre-response conference that it currently uses a solution to monitor and quantify supplier or third-party risk and may retain that solution. Please identify the existing platform and confirm whether integration with it is required as part of the initial implementation.

Please also identify the other integrations that must be included in base implementation pricing and available at initial go-live, including any required SIEM, endpoint-security, Microsoft Entra ID, SharePoint, or Documentum integrations. For each required integration, please describe the expected data exchanged and whether the integration is one-way or bidirectional.

capabilities and expects the proposed solution to support integration with external third-party risk intelligence and security-rating platforms through native integrations and/or standards-based APIs. OUC's broader priority integration capabilities include Microsoft 365, Microsoft Entra ID for identity/SSO, SIEM/security monitoring, vulnerability management, Halo ITSM, PASS/procurement, and applicable asset management systems. Specific Phase 1 platforms, data elements, integration direction, and sequencing may be further defined with shortlisted vendors. Vendors should identify available native integrations, API capabilities, anticipated implementation approach, and any additional licensing or

58. Third-Party Risk Management Volume and External Access For implementation and licensing purposes, please provide approximate volumes for: Active third parties or suppliers to be managed New third-party assessments conducted annually Recurring reassessments conducted annually Third-party questionnaires or assessment templates Internal third-party risk management users Please also confirm whether external suppliers must access the selected platform directly to complete questionnaires and upload supporting documentation, or whether OUC personnel will enter or import supplier responses.

• OUC currently anticipates a baseline of approximately 52 third-party cybersecurity risk assessments annually. Assessment volumes are expected to increase as the TPRM program matures and workflow automation improves. The total third-party population and recurring reassessment volumes have not yet been finalized. OUC anticipates approximately 2–3 ECRM users who will regularly administer the solution and perform risk and third-party risk assessments. OUC also expects external third parties to be able to participate in applicable TPRM workflows, including responding to questionnaires and requests for information and uploading supporting documentation. Vendors should describe their secure external-user experience, licensing model, and associated costs.

59. Data Migration Scope Please provide the approximate migration scope for the initial implementation, including the number of source spreadsheets or systems and estimated volumes of risks, assessments, third parties, controls, findings, remediation actions, and supporting documents. Please also confirm whether OUC expects migration of historical closed records or only currently active records, and whether OUC will provide extracted and cleansed source data in mutually agreed import templates.

• OUC does not currently anticipate requiring a full migration of all historical PASS records into the GRC platform. However, OUC expects the solution to support integration with PASS and the ability to access, reference, or exchange relevant historical vendor and assessment information where appropriate for a possible future enhancement. Specific historical-data and migration requirements, including applicable records, attachments, source formats, and import requirements, will be defined during implementation.

60. Target Implementation Schedule OUC requires bidders to provide an implementation Gantt chart. Does OUC have a target production go-live date or desired implementation duration, or should bidders propose a recommended schedule based on their implementation methodology and stated assumptions?

• OUC anticipates beginning implementation in October and would like core Phase 1 functionality operational by the end of the year. Vendors should propose a recommended phased implementation schedule, including key milestones, dependencies, OUC resource requirements, configuration, integration, testing, training, UAT, and production deployment. OUC is open to reasonable sequencing recommendations based on the vendor's implementation methodology.

61. Price Schedule Clarifications The Price Schedule lists Years 1, 2, and 3 but labels the corresponding total as “Total Years 1-2.” Please confirm that the label should read “Total Years 1-3.” Additionally, the Excel formula for the Years 4-5 discount calculates the discount using only the Year 5 amount rather than the Years 4-5 subtotal. Please confirm that bidders may correct the formula to apply the discount percentage to the full Years 4-5 subtotal. Please also confirm that bidders may add rows as necessary to distinguish license categories, implementation services, optional integrations, and other separately priced options while retaining the required five-year total contract value.

• You are correct; please make necessary corrections as appliable and you may add rows as necessary to distinguish license categories, implementation services, optional integrations, and other separately priced options while retaining the required five-year total contract value.

62. Attachment G (Data Classification Standard): Exhibit 1, Section 2.1(f) references the "OUC Data Classification Standard, Attachment G," but Attachment G is not listed among the attachments in Section 5 of the RFP (page 20) and does not appear in VendorLink. Will OUC post the Data Classification Standard, or confirm it does not apply to this solicitation?

(Reference: Exhibit 1, page 3, Section 2.1(f); RFP Section 5, page 20)

• OUC will identify and provide the applicable security exhibits and requirements associated with this RFP as appropriate. If the Exhibit is not available on VendorLink, OUC will share the standards with short-listed or the awarded vendor (as appropriate). The standard is

63. Security Exhibits: The Attachment A "Security" row (page 23) states the solution "Meets requirements defined in Security Exhibits." Which documents constitute the "Security Exhibits," and are they available in VendorLink? (Reference: Attachment A, page 23, Security)

• OUC will identify and provide the applicable security exhibits and requirements associated with this RFP, as appropriate. Vendors are expected to comply with the applicable security requirements and identify any exceptions or proposed deviations in their response.

64. IT standards and security questionnaire: Exhibit 1, Section 2 references OUC's password standard and hardware/software standards, and a "detailed questionnaire on the vendor's security controls." Can OUC provide these standards and a copy of the questionnaire so they can be addressed in the proposal? (Reference: Exhibit 1, page 1, Section 2)

• Applicable OUC security standards and detailed security assessment requirements may be provided to shortlisted vendors or the selected vendor, as appropriate.

Vendors are expected to demonstrate that the proposed solution can meet the security requirements defined in the RFP and support OUC's security due-diligence process.

65. User and license counts: Attachment B requests license counts "if applicable." Approximately how many total users, administrators, and risk owners should bidders size for, and does OUC want specific user tiers priced? (Reference:

Attachment B, page 24)

• OUC anticipates approximately 2–3 ECRM administrative/power users. The solution must also support a broader population of occasional business users who may participate in risk and TPRM workflows, executive/read-only users, and external third-party users. The number of users within these additional categories has not yet been finalized. Vendors should clearly describe and separately price, where applicable, their available user tiers and identify any licensing limitations or costs associated with each user type.

66. Existing tooling and migration: Is OUC replacing an existing GRC tool or a manual process? If replacing a tool, what data-migration volume should bidders assume for the demo or pilot and the implementation? (Reference: Section 1.1, page 6)

• OUC is not replacing the existing enterprise GRC platform. Cybersecurity risk management processes are currently largely manual. Procurement uses a custom built application, which contains historical vendor and assessment information and will remain an existing system of record. Please refer to OUC's response to Question #22 regarding the anticipated relationship between PASS and the proposed GRC solution.

67. Third-party population: For the Third-Party Risk Management scope, approximately how many third parties or vendors will be managed in the platform? (Reference: Attachment A, pages 21-22, TPRM)

TPRM program matures and workflow automation improves. The total population of third parties to be maintained or monitored within the solution has not yet been finalized. The frequency and depth of assessments and reassessments may vary based on the third party's risk profile and applicable OUC requirements.

Vendors should clearly describe any licensing, pricing, or technical limitations

68. External risk-intelligence service: Attachment A ("Integration," page 22) references integration with external third-party risk-intelligence or security-rating services. Does OUC currently subscribe to a specific service, and if so, is integration to that service expected in Year 1? (Reference: Attachment A, page 22, Integration) third-party risk intelligence and security-rating platforms through native integrations and/or standards-based APIs. Specific platforms and Phase 1 integration priorities may be provided to shortlisted vendors. Vendors should identify supported native integrations, API capabilities, and any additional licensing or implementation costs.

69. Delivery model: Is a vendor-hosted cloud (SaaS or managed) solution OUC's preferred delivery model, or will on-premises or other hosting options be evaluated differently?

(Reference: Exhibit 1)

• OUC prefers a secure Software-as-a-Service (SaaS) cloud solution. Government cloud is preferred where available but is not mandatory. The proposed solution must meet the security, hosting, and U.S. data residency requirements defined in the RFP and applicable OUC security standards. Vendors should clearly describe their proposed hosting and delivery model.

70. Data residency: Exhibit 1, Section 2.1(c) requires OUC data to be stored and transmitted only within North America. Does OUC accept a solution hosted in a Florida (Orlando-area) data center as fully meeting this requirement? (Reference: Exhibit 1, page 3, Section 2.1(c))

• OUC requires that OUC data be hosted, stored, processed, and transmitted within the United States. Hosting within a Florida region is preferred, where available, but is not mandatory. A Florida-hosted solution would satisfy the geographic hosting preference provided the proposed solution also meets all applicable security, architecture, availability, and other requirements defined in the RFP.

71. Security attestation: Exhibit 1, Section 2.1(f) references a minimum certification "such as

PCI, SSAE 16, ISO 27001." Will OUC accept a SOC 2 Type II or SSAE-18 attestation for the hosting facility and provider in satisfaction of this requirement? (Reference: Exhibit 1, page 3, Section 2.1(f))

• OUC will accept SOC 2 Type II, ISO/IEC 27001 certification, FedRAMP authorization, or other equivalent independent security assurance documentation, subject to OUC review. Vendors should identify the security certifications, attestations, and independent assurance reports applicable to the proposed SaaS solution and hosting environment and provide applicable documentation upon request.

72. Breach-notification window: Exhibit 1, Section 2.5(c) requires notification "within 4 hours of the discovery." Please confirm this is measured from confirmed discovery by the vendor and applies to breaches involving OUC data. (Reference: Exhibit 1, page 4, Section 2.5(c))

• OUC's four-hour notification requirement applies upon discovery of a security event or suspected breach that affects or may affect OUC data, systems, services, or the confidentiality, integrity, or availability of OUC information. OUC expects timely preliminary notification and does not require the vendor to complete its full investigation before notifying OUC. Additional information should be provided as it becomes available.

73. Penetration testing and monitoring: Exhibit 1, Section 2.5(a)-(b) provides for OUC penetration testing and monitoring of its hosted environment. For a hosted solution, will these be conducted against the OUC-dedicated scope under a mutually agreed rules-of-engagement? (Reference: Exhibit 1, page 4, Section 2.5(a)-(b))

• OUC recognizes that penetration testing of a SaaS environment must be coordinated to protect the security and availability of the service and other tenants. OUC is open to mutually agreed rules of engagement and appropriate tenant/application-scoped testing. Vendors should describe their penetration-testing policies, customer testing restrictions, available independent penetration-test reports, and the process for coordinating OUC-authorized security testing.

74. Terms and conditions: Sections 1.7 (page 8) and 3.9 (page 14) and Exhibits 1-3 address terms and conditions. Will OUC entertain negotiation of the cloud-hosted and software-license terms during the negotiation phase, and what format is preferred for proposing alternative SaaS or subscription terms without a proposal being deemed non-responsive?

(Reference: Section 1.7, page 8; Section 3.9, page 14; Exhibits 1-3)

• We recommend you reference any license terms and conditions (or add as appendix) in your response. After a selection is made, the OUC Legal department will review and negotiate any terms and conditions as needed. If an agreement cannot be reached, then the second-placed vendor (based on the bid tab scoring) will be considered.

75. Software publisher treatment: For Section 2.2.2.3 (subcontractor list, page 9), where a bidder proposes a commercial software platform from a third-party software publisher, delivered under the bidder's own hosting and services, does OUC consider that publisher a "subcontractor," or a named commercial product? (Reference: Section 2.2.2.3, page 9)

• OUC generally treats a third-party software publisher as a named commercial product rather than a subcontractor. Final classification will be confirmed during evaluation and contract review.

76. Format limits: For Section 4 (Proposal Submittal Format, page 20), are there any page limits, font, or margin requirements for the Tab 3 Response to Requirements, or is length at the bidder's discretion? (Reference: Section 4, page 20)

• Please use your discretion to provide all information relevant to providing a responsive proposal.

77. Demo and pilot logistics: For the demo or pilot (Section 1.1, page 6), will OUC provide a defined test dataset and a target date window for shortlisted vendors, and is a web-based demonstration acceptable in lieu of on-site? (Reference: Section 1.1, page 6)

• The buyer will reach out to short-listed vendors to schedule a demo. Web-based demonstrations are acceptable and preferable.

78. Assessment types — Attachment A references preliminary risk assessments, threat-based risk assessments, and criticality/impact assessments. Can OUC describe the intended inputs, scoring approach, and expected outputs for each, and share any current templates or examples? Reference: p. 21, Section 2 – Functional and Non-Functional Requirements:

“Risk Assessment” (Attachment A – Detailed Scope of Work & Requirements).

• OUC expects the proposed solution to support configurable assessment workflows, questionnaires, scoring methodologies, assessment tiering, approvals, and risk-based selection of the appropriate level of due diligence.