ADDENDUM OF SOLICITATION

1. SOLICITATION NO.

371-00013

2. ADDENDUM NO.

3. EFFECTIVE DATE

5/19/26

4. ISSUED BY

Texas Cyber Command Chief Procurement Office 1001W North Loop Blvd Austin, Texas 78756

5. NAME AND ADDRESS OF OFFEROR

6. The above numbered solicitation is amended as set forth in Item 7. The hour and date specified for receipt of Offers is extended, is not extended.

Offers must acknowledge receipt of this addendum prior to the hour and date specified in the solicitation or as amended, by one of the following methods:

(a) By completing Items 5 and 8, and returning 3 copies of the addendum; (b) By acknowledging receipt of this addendum on each copy of the offer submitted; or (c) By separate letter or e-mail which includes a reference to the solicitation and addendum numbers. FAILURE OF YOUR ACKNOWLEDGMENT TO BE RECEIVED AT THE PLACE DESIGNATED FOR THE RECEIPT OF OFFERS PRIOR TO THE HOUR AND DATE SPECIFIED MAY RESULT IN REJECTION OF YOUR OFFER.

If by virtue of this amendment you desire to change an offer already submitted, such change may be made by e-mail or letter, provided each e-mail or letter makes reference to the solicitation and this addendum, and is received prior to the opening hour and date specified.

7. DESCRIPTION OF ADDENDUM:

The purpose of this addendum is to extend the response due date and provide answers to vendors’ questions.

1. The deadline for submitting responses to the RFO has been extended to May 28, 2026 at 3:00 pm.

Responses must be submitted to txcc.procurement@txcc.texas.gov.

2. Answers to questions that were submitted to TXCC prior to the deadline of 5/6/26 are included on the following pages.

Except as provided herein, all terms and conditions of the solicitation, as heretofore changed, remain unchanged and in full force and effect.

8a. NAME AND TITLE OF SIGNER (Type or Print)

8b. OFFEROR

(Signature of Person Authorized to Sign) Date Signed mailto:txcc.procurement@txcc.texas.gov

RFO 371-00013 - Sovereign Terrain and Digital Border Defense

Vendor Questions and Answers

1. The RFO states that the solution may be deployed within TXCC-designated data centers, cloud environments, or hosting environments approved in writing by TXCC. Can TXCC clarify whether Vendors may propose a deployment model where the solution is installed, configured, operated, and managed entirely within TXCC-designated infrastructure, data centers, network environments, approved insertion points, without using a Vendor-owned or third-party cloud/hosting environment?

Answer: Answered in RFO documents, see RFO Section 2.2.

2. If a Vendor proposes an on-premises or TXCC-designated infrastructure deployment where TXCC provides the data center environment, network connectivity, approved insertion points, out-of-band management access, and related services, would the Vendor still be required to hold TX-RAMP Level 2 or FedRAMP Moderate authorization directly?

Answer: Answered in RFO documents, see RFO Section 10 and Attachment A Section 10.4(B)(xxiv).

3. Can TXCC clarify whether the TX-RAMP Level 2 or FedRAMP Moderate requirement applies only when the Vendor uses a Vendor-owned, subcontractor-owned, or third-party cloud/hosting environment to store, process, transmit, manage, or analyze TXCC data outside of TXCC-controlled infrastructure?

Answer: Answered in RFO documents, see RFO Section 10 and Attachment A Section 10.4(B)(xxiv).

4. If the proposed solution keeps TXCC traffic, metadata, logs, telemetry, and derived outputs within TXCC-designated infrastructure, but the Vendor provides remote administration, monitoring, maintenance, support, or managed services through TXCC-approved access methods, would that remote support model trigger the TX-RAMP/FedRAMP requirement?

Answer: Answered in RFO documents, see RFO Sections 2.2, 2.7, 10, and Appendix A Section 10.4(B)(xxiv). Remote support through TXCC-approved access methods does not, by itself, create a separate TX-RAMP requirement unless the service is a cloud computing service or hosted component that stores, processes, transmits, manages, or analyzes TXCC data outside TXCC-controlled infrastructure.

5. For Vendors proposing a TXCC-hosted, on-premises, appliance-based, or non-cloud architecture, what documentation should be submitted to demonstrate compliance with the deployment and security requirements? For example, should Vendors include an architecture diagram, data flow diagram, description of where TXCC data is stored and processed, remote access controls, security control narrative, patch management process, and roles/responsibilities matrix?

Answer: Answered in RFO documents, see RFO Sections 4 and 5.

6. Will TXCC extend the due date for responses to each RFO?

Answer: Responses are now due on Thursday, May 28th, 2026 @ 3:00 PM CT.

7. Is the full RFO response / bid package published on the TXCC website?

Answer: The complete RFO is posted in the Electronic State Business Daily (ESBD).

8. Are all submissions published on the TXCC website or only the winning (or partial winning) submission(s)?

Answer: Refer to Section 12.13 of the RFO.

9. Do we submit a redacted version with our original submission or only after contract award?

Answer: Refer to Section 12.13 of the RFO. The redacted version should be submitted with your original response since both successful and unsuccessful responses are subject to public information.

10. Is it possible to assert TPIA (TGC Section 552.110) protections over any / all of the proposal and thus limit the distribution or publishing?

Answer: Refer to Section 12.13.B of the RFO.

11. Can you confirm financials will not be publicly published?

Answer: Refer to Section 12.13.B of the RFO.

12. Is there a specified format for the Proposed Solution document or should we follow the RFO outline and use the file name nomenclature?

Answer: There is no preferred format for the Vendor’s Proposed Solution. Refer to Section

12.8.4 of the RFO.

13. Can you provide VPTS tracking requirements in advance?

Answer: Refer to Section 12.2.1.C of the RFO.

14. Do you have a mechanism for integrating commercial TOS into contracts?

Answer: The contract includes all terms and finalized scope of work as noted in the RFO and through any clarifications. Generic TOS are not allowed. A vendor can request certain terms in its proposal and TXCC may or may not accept them in the final contract depending upon what is requested.

Network Scope & Coverage (Primary Cost Driver)

15. How many distinct physical network locations (data centers, aggregation points, facilities) are currently in scope at contract start?

Answer: Depending on the solution architecture, it could be as few as two physical locations at the start.

16. What is the initial total monitored bandwidth (Gbps) TXCC expects the solution to support at Day 1?

Answer: An average of 30Gb/sec in both directions during business hours. It can go as high as 60Gb in each direction with the current architecture.

17. Is TXCC expecting:

a. Monitoring only at state-managed backbone points, or

b. Monitoring at agency-level network edges as well?

Answer: Initially, it would be the state backbone, but it could grow to include agency edge protection especially if the solution is multi-tenant allowing each entity to have access to just its network monitoring.

18. What is the estimated rate of expansion over the base contract term (e.g., number of new sites or bandwidth growth per year)?

Answer: Rate of expansion is difficult to forecast for this service. The state network current growth rate is about 5% per year.

19. Are local government or quasi-state networks anticipated to be added during the contract term, even if not initially authorized?

Answer: This will be reviewed and assessed as the project progresses.

IT vs OT Environment Coverage

20. Which OT environments (if any) are explicitly in scope at contract start?

Answer: Any OT environments currently operated by state agencies with internet access.

21. Are OT networks expected to be:

a. Passively monitored only, or

b. Inline / near-inline monitored with enforcement capability?

Answer: b. Inline/near-inline monitored with enforcement capability

22. Does TXCC require OT-specific protocol visibility (e.g., Modbus, DNP3, IEC), or is OT treated at a transport/flow level only?

Answer: Transport level only currently.

23. Are there separate authorization workflows anticipated for OT-related enforcement actions?

Answer: Initial solution is not constrained and can be proposed as necessary. As project progresses, this will be reassessed.

IP Space Control & Routing Authority

24. Can TXCC clarify the estimated size of TXCC-managed IP address space (IPv4 blocks) to be monitored and controlled?

Answer: The State of Texas owns 2.8 million public-facing IP addresses, not all are used, but most are advertised.

25. Will [Vendors] be expected to operate routing enforcement directly, or only recommend and execute TXCC-approved changes?

Answer: TXCC must approve any routing enforcement or changes.

26. Are BGP interactions or upstream provider coordination in scope, or is routing enforcement limited to TXCC-controlled infrastructure?

Answer: BGP interactions with upstream providers could be in scope. This would have to be coordinated with DIR, the providers, and TXCC.

27. How frequently does TXCC anticipate approved routing changes under normal operations?

Answer: Unknown at this time, but we do not anticipate a lot of routing changes.

Data Volume, Retention & Storage

28. What is the expected daily telemetry ingest volume (events/day or GB/day)?

Answer: Answered in RFO documents, see RFO Page 10, Section 2.3(T)(L)

29. What are TXCC’s data retention requirements for:

• Raw telemetry

• Enriched metadata

• Analytics outputs

• Audit logs

Answer: Currently it is 90 days, 2 years, 2 years, 2 years, but it could be subject to change.

30. Are different retention periods required for operational vs evidentiary data?

Answer: Effort endeavors to account for dynamic circumstances.

31. Will TXCC require warm or hot access to historical data for threat hunting and investigations?

Answer: Data can be warm or hot as long as it remains accessible and usable for 2 years.

Autonomous Enforcement Expectations

32. Which enforcement actions does TXCC anticipate approving for autonomous (policy-governed) execution during the base term?

• Flow blocking

• Rate limiting

• Quarantine

• Routing changes

Answer: All of the above except rate limiting.

33. Does TXCC expect autonomous enforcement to be:

• Enabled from initial go-live, or

• Phased in after acceptance milestones?

Answer: Autonomous enforcement should be assumed to phase in after acceptance, operational validation, approved playbooks, rollback procedures, logging, and written TXCC authorization

34. Are different approval models expected for different agencies or environments?

Answer: We would expect that state agencies could use the same approval process, but this is an open item.

Integration Scope

35. Which specific SIEM, logging, case management, and IAM platforms must be integrated at contract start?

Answer: TXCC is not identifying specific SIEM, logging, case-management, ticketing, or IAM products in the question response. Vendors must support integration with TXCC-approved tools using standards-based methods.

36. Are integrations expected to be:

• One-way (export), or

• Bi-directional (actionable workflows)?

Answer: At go-live, integrations should support near-real-time one-way export of logs, alerts, health metrics, and audit records. Bidirectional API actions or automated response workflows may be enabled only when approved by TXCC and governed by RBAC, MFA, least privilege, audit logging, and change control.

37. Does TXCC expect custom integration development, or use of standard protocols only?

Answer: TXCC is not identifying legacy or proprietary systems in the question response.

Vendors should describe support for heterogeneous enterprise environments, standards-based integration, and any assumptions or limitations for proprietary systems.

38. Are any legacy or proprietary systems anticipated to require special handling?

Answer: TXCC is not identifying legacy or proprietary systems in the question response.

Vendors should describe support for heterogeneous enterprise environments, standards-based integration, and any assumptions or limitations for proprietary systems.

Operational Model & Staffing

39. Does TXCC expect:

• Full vendor-operated 24x7 operations, or

• A hybrid model with TXCC analysts involved in daily operations?

Answer: Answered in RFO documents, see RFO Sections 2.3(l), 2.5, 6, and 7. The Vendor must provide 24x7 monitoring and support, while TXCC retains approval authority for authorized use, change control, and production enforcement under RFO Section 2.7.

40. Will TXCC provide on-site personnel, or will operations be entirely provider-staffed?

Answer: Operations may be remote for steady-state services where TXCC-approved access methods are used. On-site personnel should be assumed only as needed for installation, maintenance, break/fix, or TXCC-directed activities.

41. Are there expectations for surge staffing during incident response events?

Answer: The RFO does not define surge staffing levels. Vendors should identify incident-response surge capabilities, escalation paths, and optional pricing or assumptions for surge support.

Reporting & Analytics Expectations

42. What level of executive reporting is required?

• Operational metrics only

• Strategic risk posture

• Statewide cyber terrain visualization

Answer: Answered in RFO documents, see RFO Sections 1.2.1, 2.3(c), and 6. Reporting must support operational decision-making, incident response, compliance, executive oversight, capacity and performance trends, detection and response activity, and governance reviews.

43. How frequently are custom reports expected beyond standard SLA and operational reports?

Answer: Answered in RFO documents, see RFO Section 6. The RFO requires weekly implementation status reporting, monthly service reports after production commencement, and quarterly governance reviews; custom reports beyond those requirements should be proposed by the Vendor and approved by TXCC.

44. Are ad-hoc investigative analytics anticipated as part of steady-state service?

Answer: Answered in RFO documents, see RFO Sections 2.1, 2.3(c), and 3.1(d). Ad-hoc investigative analytics and threat hunting are within scope for TXCC-approved monitored data and environments.

Acceptance Criteria & Milestones

45. Can TXCC clarify formal acceptance criteria for:

• Network visibility

• Enforcement capabilities

• Analytics accuracy

• Reporting

Answer: Answered in RFO documents, see RFO Section 3.3.

46. Will partial acceptance be permitted by phase or capability

Answer: Partial acceptance may be considered only if documented in the TXCC-approved Project Work Plan, Acceptance Test Plan, or written TXCC approval. Vendors should not assume partial acceptance without TXCC approval.

47. How will acceptance testing be coordinated across multiple agencies or environments?

Answer: Acceptance testing across multiple agencies or environments will be coordinated through TXCC-approved project governance, the Project Work Plan, the Acceptance Test Plan, change management, and designated agency or environment points of contact as applicable.

Pricing Structure & Commercial Assumptions

48. Does TXCC prefer pricing to be expressed as:

• Fully bundled (turnkey) only, or

• Bundled with informational line-item cost detail?

Answer: Refer to RFO Section 8.D.

49. Should hardware be priced as:

• One-time capital cost,

• Amortized over the contract term, or

• Embedded within service pricing?

Answer: Answered in RFO documents, see RFO Sections 2.1 and 8(D). Exhibit D includes one cost for the turnkey solution, and additional cost breakdown must be itemized in the Vendor response.

50. Will TXCC consider volume or scope-based price adjustments for material changes in network size?

Answer: Answered in RFO documents, see RFO Section 8(B) and Appendix A Section 3.2.

Material scope or pricing changes require a TXCC-approved written contract amendment.

51. Are payment terms under current MSA? Will TXCC provide a proposed MSA for this effort?

Answer: The RFO states how TXCC will pay for services which aligns with state requirements.

If the vendor is proposing a certain cost methodology, it should include it in its proposal.

52. Are renewal-year pricing adjustments expected to reflect:

• Inflation,

• Scope growth, or

• Flat-rate continuation?

Answer: The vendor should propose a price based on its knowledge of its own market and company.

Out-of-Scope Clarification (Risk Management)

53. Are any of the following explicitly out of scope:

• End-user endpoint security

• Application-level security testing

• Vulnerability remediation outside network enforcement

Answer: Duties are limited to the scope of this RFO. End-user endpoint security, application-level security testing, and vulnerability remediation outside TXCC-approved network enforcement or approved scope should not be assumed unless expressly added by TXCC.

54. Is TXCC expecting tool replacement or coexistence with existing agency cybersecurity tools?

Answer: Answered in RFO documents, see RFO Section 2.4. The solution must integrate with TXCC systems and tools; vendors should not assume replacement of existing agency cybersecurity tools unless TXCC approves that approach.

Vulnerability Management Scope

55. Which asset classes are in scope for vulnerability management?

• Network infrastructure

• Security appliances

• Servers (on-prem/cloud)

• OT devices

• Applications/databases

Answer: The vulnerability-management scope is limited to capabilities necessary to identify, prioritize, report, and support mitigation of vulnerabilities within TXCC-approved monitored networks and environments. Vendors should not assume a general enterprise vulnerability-management program covering all asset classes unless TXCC adds that scope

56. Is coverage limited to TXCC-owned systems, or do agency-managed assets fall in scope?

Answer: Coverage is oriented on TXCC identified operational terrains.

57. Is the vendor expected to discover unknown or unmanaged assets, or only assess known inventory?

Answer: Search and discovery is a necessary mission requirement and outcome.

Vulnerability Discovery & Scanning

58. Does TXCC expect:

• Active scanning

• Passive assessment

• A hybrid model?

Answer: Default vulnerability discovery should rely on passive assessment and approved telemetry. Active scanning may be used only with written TXCC authorization, approved rules of engagement, defined scope, time windows, rate limits, notification, and safety controls.

59. Are authenticated scans required for any asset types?

Answer: The RFO does not require authenticated scans for specific asset types. If proposed, authenticated scans must be scoped, credentialed, logged, and approved by TXCC before use.

60. Are there environments where active scanning is prohibited?

Answer: Active scanning is prohibited outside TXCC-approved scope and should be avoided in safety-sensitive OT environments unless TXCC expressly approves defined rules of engagement and safety controls.

61. Is vulnerability assessment expected to be continuous or periodic?

Answer: Discovery drives periodicity.

Vulnerability Tooling & Integration

62. Does TXCC mandate specific vulnerability management tools, or may vendors propose integrated solutions?

Answer: No present constraints or restraints. TXCC will actively observe solutions (technology, process, etc.) in progress.

63. Should vulnerability findings be:

• Integrated into the cyber defense analytics platform, or

• Managed in a standalone system?

Answer: Both options apply.

64. Should native vulnerability intelligence be leveraged as part of the signal set?

Answer: No constraints.

Vulnerability Prioritization & Risk Context

65. Should vulnerabilities be prioritized by:

• CVSS score only, or

• Contextual risk (asset criticality, exposure)?

Answer: Both apply but solutions not constrained.

66. Does TXCC maintain an asset criticality framework available for prioritization?

Answer: TXCC is not publishing an asset criticality framework in the question response.

Vendors should support configurable asset criticality, tagging, and prioritization that can align to TXCC-approved criteria after award.

67. Are threat-informed vulnerability priorities required (active exploitation awareness)?

Answer: The Vendor is expected to identify, prioritize, report, and coordinate vulnerability-related findings within the RFO scope. Execution of remediation on TXCC or agency assets should not be assumed unless expressly authorized; approved defensive network mitigations may be executed under TXCC change control and playbooks.

Vulnerability Response & Remediation Boundaries

68. Is the vendor expected to:

• Identify and report vulnerabilities only

• Coordinate remediation

• Execute remediation actions?

Answer: The Vendor is expected to identify, prioritize, report, and coordinate vulnerability-related findings within the RFO scope. Execution of remediation on TXCC or agency assets should not be assumed unless expressly authorized; approved defensive network mitigations may be executed under TXCC change control and playbooks.

69. If remediation execution is expected:

• Which asset classes are in scope?

• Must remediation follow formal TXCC change control?

Answer: TXCC will coordinate follow-on actions.

70. Are emergency mitigation actions permitted under pre-approved playbooks?

Answer: TXCC will coordinate follow-on actions.

FedRAMP & Compliance (Vulnerability Management)

71. Which NIST 800-53 controls must vulnerability management explicitly support (e.g., RA-5, SI-2)?

Answer: At minimum, vulnerability-management support should align to applicable NIST controls (such as RA-5, SI-2, CA-7, CM-6, CM-8, AU-6, AU-12, IR-4, and IR-5), as applicable to the solution and final authority to operate requirements.

72. Are vulnerability scan results required as FedRAMP audit evidence, or metrics only?

Answer: The RFO does not specify whether vulnerability scan results are FedRAMP audit evidence or operational metrics. Vendors should support both operational reporting and exportable evidence artifacts when requested by TXCC. To satisfy the ATO requirements of the system, the vendor will need to present an SSP detailing how all security requirements are implemented.

73. Are patch timelines by severity formally defined and enforceable?

Answer: Answered in RFO documents, see RFO Section 2.5.

OT-Specific Vulnerability Expectations

74. For OT systems:

• Is non-intrusive assessment required?

• Are vendor advisories acceptable in lieu of scanning?

Answer: For OT systems, non-intrusive and passive-first assessment should be assumed.

Vendor advisories may supplement vulnerability identification but should not replace approved monitoring or assessment where TXCC authorizes such activity.

75. Are compensating controls required when OT vulnerabilities cannot be remediated?

Answer: Compensating controls should be proposed when OT vulnerabilities cannot be remediated promptly, including monitoring, segmentation, access control, alerting, change control, and documented risk acceptance as approved by TXCC.

Vulnerability Reporting & Governance

76. What vulnerability metrics are required for:

• SOC operations

• Management

• Executive leadership

Answer: Answered in RFO documents, see RFO Section 6.

77. Are trend and remediation effectiveness reports required?

Answer: Answered in RFO documents, see RFO Section 6.

78. How frequently are vulnerability reports expected?

Answer: Answered in RFO documents, see RFO Section 6.

79. Who is the system owner responsible for approving remediation?

Answer: TXCC will coordinate/direct.

80. Is there a formal risk-acceptance / exception process?

Answer: TXCC will coordinate/direct.

Vulnerability Management – Explicit Exclusions

81. Are the following explicitly out of scope unless added later?

• Application code analysis (SAST/DAST)

• Penetration testing / red teaming

• Configuration compliance beyond baseline checks

Answer: Application code analysis, penetration testing, red teaming, and configuration-compliance activities beyond baseline checks are out of scope unless expressly added or authorized by TXCC.

82. Should SaaS and third-party platforms be assessed, or only systems under TXCC authority?

Answer: Answered in RFO documents, see RFO Sections 1.2.1 and 2.7. SaaS and third-party platforms may be assessed only if they are within TXCC-approved scope and TXCC has legal and operational authority for the activity.

Project Rollout Strategy & Phasing

83. Does TXCC intend for deployment of the solution to occur as:

• A single statewide cutover, or

• A phased rollout across agencies, environments, or network segments?

Answer: Informed by results of project.

84. If a phased rollout is anticipated:

• What phasing model does TXCC envision (e.g., pilot → expansion → steady-state)?

• Are phases expected to be time-based, agency-based, capability-based, or a combination thereof?

Answer: Informed by results of project.

85. Are there any external drivers—such as fiscal cycles, legislative requirements, audit timelines, or operational readiness milestones—that affect rollout sequencing beyond the post award milestones defined in the RFO?

Answer: TXCC is not identifying external rollout drivers in the question response beyond the post-award milestones in the RFO. Vendors should identify assumptions and constraints and update the Project Work Plan as TXCC provides direction.

Agency Inclusion Scope (Initial vs. Future)

86. At contract start, will deployment be limited to TXCC-controlled or TXCC-authorized environments only, or will it include a defined subset of Texas state agencies?

Answer: Answered in RFO documents, see RFO Sections 1.2.1 and 2.7. Deployment is limited to TXCC-controlled or TXCC-authorized environments unless TXCC expressly approves participation by another eligible entity under applicable law.

87. If an initial subset of agencies is anticipated:

• Will TXCC identify those agencies prior to award, or

• Will selection occur post-award as part of rollout planning?

Answer: TXCC is not identifying an initial subset of agencies prior to award in the question response. Selection should be assumed to occur post-award as part of rollout planning unless TXCC provides additional written direction.

88. Should vendors assume the solution must be architected for immediate statewide scalability even if only a subset of agencies participates initially?

Answer: Answered in RFO documents, see RFO Section 3.2(d). The solution must support scalable expansion to additional TXCC-approved sites or bandwidth tiers without architectural redesign.

Agency Prioritization & Onboarding Order

89. How does TXCC anticipate prioritizing agencies or environments for inclusion in the initiative?

• Risk-based (e.g., critical infrastructure, high-value targets)?

• Network proximity or architectural readiness?

• Executive or statutory mandate?

• Voluntary early adoption?

Answer: Informed by results of project.

90. Will TXCC provide a prioritized onboarding list, or should vendors assume selection criteria when developing rollout and staffing plans?

Answer: Developed post award.

91. Should vendors plan to onboard multiple agencies in parallel, or does TXCC prefer a serialized onboarding approach to manage operational risk?

Answer: Developed post award.

Voluntary vs. Mandatory Agency Participation

92. Will participation in the initiative be mandatory for agencies once authorized by TXCC, or voluntary / option?

Answer: Answered in RFO documents, see RFO Section 1.2.1. The RFO does not require other governmental entities to purchase a specific product or service, and use outside TXCC-controlled or TXCC-authorized environments is permitted only when expressly approved by TXCC and applicable law.

93. If participation is voluntary:

• How should vendors plan for uneven onboarding velocity?

• Are vendors expected to support agency outreach, readiness validation, or onboarding coordination?

Answer: TXCC coordinates operational maneuver.

94. If participation is mandatory:

• Will TXCC manage agency change management and authorization centrally, or is vendor support expected?

Answer: TXCC coordinates operational maneuver.

Rollout Governance & Decision Authority

95. During rollout, who has final authority to:

• Approve agency onboarding timing?

• Authorize sensor placement and enforcement activation?

• Resolve conflicts between TXCC and participating agencies?

Answer: Answered in RFO documents, see RFO Sections 2.7 and 5. TXCC has final authority over approved environments, insertion points, change control, enforcement activation, and routing changes; rollout decisions must be documented in the TXCC-approved Project Work Plan and change-management process.

96. Will there be a formal rollout governance structure (e.g., steering committee), or will these decisions be made directly by TXCC operational leadership?

Answer: Answered in RFO documents. See RFO Section 6. Vendors must participate in quarterly governance reviews with TXCC; any additional steering committee or rollout governance structure will be established by TXCC as needed.

Phased Capability Enablement & Operational Readiness

97. Is TXCC expecting all capabilities (visibility, analytics, autonomous enforcement, routing) to be enabled simultaneously at go-live, or phased in as operational maturity is achieved?

Answer: All capabilities should be available at project start; TXCC coordinates operational maneuver.

98. Should vendors assume a graded enforcement model (monitor-only → recommend → enforce) during early rollout phases?

Answer: Yes.

Rollout Risk Management & Contingencies

99. If agency onboarding encounters delays due to policy, authorization, or technical readiness issues, should vendors:

• Pause rollout,

• Bypass the affected agency and proceed to others, or

• Maintain idle capacity pending resolution?

Answer: TXCC coordinates.

100. Are vendors expected to maintain buffer capacity to accommodate reprioritization or accelerated onboarding at TXCC’s direction?

Answer: Yes.

Commercial Implications of Rollout Sequencing

101. Given the no minimum spend contract structure, how should vendors align capacity planning with actual agency adoption rates?

Answer: Answered in RFO documents, see RFO Section 8(A)-(C). TXCC guarantees no minimum compensation; vendors should align capacity and investment to the base turnkey scope, purchase orders, and optional/tiered expansion pricing approved by TXCC.

102. Will TXCC provide post award adoption forecasts or planning assumptions to guide capacity and investment decisions?

Answer: Yes.

103. Will TXCC consider future contract modifications to reflect material changes in rollout speed, agency participation, or scale relative to initial assumptions?

Answer: Answered in RFO documents, see Appendix A – Standard Terms and Conditions, Section 3.2.

104. Will TXCC please extend the due date for the references, which were due on May 5, 2026?

Answer: Answered in Addendum 1.

105. RFO §§1.1, 2.3(g)-(h), and 2.7 require TXCC to take back Texas’ sovereign IP terrain, take over control of unallocated IPv4 Texas State Government IP Space, provide a routing solution, and use TXCC-approved change control and proof of authority for routing changes.

Should vendors interpret this requirement as a TXCC-approved passive darknet, canary, or sinkhole capability for state IP space, similar in concept to prior federal dark-address-space advertisement efforts, used to identify unauthorized use and generate threat intelligence? Or does TXCC expect vendors to route operational agency traffic through the in-scope address space? If operational traffic routing is intended, please specify the expected routing model, insertion points, traffic types, and required proof of address-space authority.

Answer: Vendors should not assume routing of operational agency traffic through in-scope address space unless TXCC expressly approves that model.

106. Given TXCC’s authority under Tex. Gov’t Code Chapter 2063 and the RFO’s description of a TXCC-managed defensive capability that may be used in TXCC-controlled or TXCC-authorized environments, will TXCC consider a procurement structure in which TXCC holds a single enterprise platform license and makes the TXCC-managed capability available, at no incremental platform-license cost to the participating entity, to eligible Texas governmental entities and TXCC-approved covered entities? May vendors price the platform license based on statewide TXCC-managed consumption rather than separate per-entity licensing, with TXCC retaining authority over eligibility, approval, onboarding, governance, and use?

Answer: Vendors may propose a statewide TX-managed consumption, enterprise, or tiered licensing model if it is compatible with the indefinite-quantity/no-minimum structure, the pricing schedule, and TXCC approval. TXCC retains authority over eligibility, onboarding, governance, use, and any participation by other entities.

107. Several RFO requirements point toward TXCC retaining custody and control of raw telemetry and evidence, including §2.6 data ownership, §2.3(r) auditability, §2.7 collection boundaries, and §10 cloud authorization requirements. Will TXCC consider a deployment architecture in which raw network telemetry, packet metadata, NetFlow/IPFIX records, security events, and audit logs are written directly to TXCC-owned or TXCC-controlled storage in a TXCC-approved environment, while the vendor platform processes correlated event-level data and threat findings without taking persistent custody of raw TXCC telemetry outside the TXCC-controlled storage tier? Under this model, may TXCC provision and control the storage infrastructure and retention policy, with the vendor responsible for software deployment, configuration, maintenance, analytics, and policy enforcement?

Answer: TXCC may consider an architecture in which raw telemetry and evidence are written to TXCC-owned or TXCC-controlled storage in a TXCC-approved environment while the vendor platform processes correlated event-level data and threat findings, provided the design satisfies the RFO data handling, security, auditability, support, retention, and TX- RAMP/FedRAMP requirements as applicable.

108. For the human incident-response layer above the platform’s automated detection and correlation functions, will TXCC consider an operating model in which TXCC authorizes, certifies, or maintains a roster of Regional Security Operations Centers or other approved response providers, including Texas-based and HUB-certified providers where applicable, to perform response activities using the TXCC-managed platform? Under this model, response providers would execute TXCC-approved playbooks, all response actions would be logged into TXCC-controlled evidence and audit repositories with chain-of-custody, and TXCC would retain real-time visibility across incidents through the unified dashboard and reporting functions required by the RFO.

Answer: TXCC may consider an approved response-provider model only if it is structured through the awarded contract, approved subcontracting arrangements, TXCC-approved playbooks, access controls, logging, chain of custody, and centralized TXCC visibility. The prime Vendor remains accountable for contract performance.

109. For smaller eligible entities, such as rural counties, school districts, special-purpose districts, smaller local governments, and smaller critical-infrastructure operators that may lack dedicated security infrastructure or personnel, will TXCC accept a tiered participation model in which those entities forward standards-based security events and telemetry, such as syslog, CEF, LEEF, IPFIX/NetFlow, cloud logs, application logs, and alerts from existing security or OT sensors, to the centrally operated TXCC-managed platform without deploying a separate SIEM or proprietary sensor stack at each entity? Under this model, the participating entity contributes available event streams, while TXCC’s centrally managed platform provides statewide threat intelligence, correlation, IOC matching, alerting, reporting, and an authorized response path. Would TXCC view this as satisfying §3.2(d)’s scalable expansion requirement for long-tail participation?

Answer: TXCC may consider a tiered participation model in which smaller eligible entities forward standards-based telemetry to the TXCC-managed platform, without deploying a separate SIEM at each entity, if the model satisfies TXCC-approved scope, legal authority, security, data handling, reporting, and response requirements.

110. RFO §3.3(c) references measured throughput and latency testing under an agreed traffic profile, and §3.2(d) requires scalable expansion. To allow vendors to size the proposed platform accurately across both large agencies and smaller participating entities, can TXCC provide the expected traffic profile for the initial deployment and anticipated expansion phases? Specifically, please provide, to the extent available: (a) aggregate expected event/log/flow volume across all in-scope Texas governmental entities and TXCC-approved covered entities; (b) expected volume distribution across large agencies, mid-tier entities, and smaller long-tail entities such as rural counties, school districts, special-purpose districts, municipalities, and smaller critical-infrastructure operators; (c) expected inbound traffic volume and traffic type for unallocated IPv4 Texas State Government IP space brought under TXCC management under §§2.3(g)–(h); and (d) the approximate number of ARIN organization IDs, IPv4 prefixes, and origin Autonomous Systems in scope, including any sub-delegated prefixes where another Texas entity retains independent routing or allocation authority. If these figures are not yet available, will TXCC allow vendors to propose separate sizing assumptions and pricing bands for large-agency, mid-tier, smaller long-tail, and sovereign-IP/dark-space monitoring use cases?

Answer: TXCC is not publishing aggregate traffic, event/log/flow volumes, sovereign-IP dark-space traffic, ARIN organization IDs, prefix lists, or origin AS details in the question response.

Vendors may propose sizing assumptions and pricing bands for large-agency, mid-tier, smaller long-tail, and sovereign-IP monitoring use cases, subject to TXCC evaluation.

111. Network Throughput: What is the maximum sustained throughput (Gbps) required at the primary data centers during peak Deep Packet Inspection (DPI) loads?

Answer: TXCC is not publishing a maximum sustained Gbps requirement for primary data centers in the question response. Vendors should state throughput assumptions and demonstrate performance under the TXCC-approved acceptance test profile.

112. Cloud Providers: Which specific cloud service providers (CSPs) are currently in scope for the "Sovereign Terrain," and are they hosted in Government-specific regions (e.g., Azure Government or AWS GovCloud)?

Answer: TXCC is not identifying specific cloud service providers or regions in the question response. Any hosted component must use TXCC-approved environments and comply with RFO Section 10 and Appendix A Section 3.9 as applicable.

113. Data Sovereignty: Are there specific Texas geographic requirements for the primary and secondary Data Lake storage locations to ensure data remains within state boundaries?

Answer: Answered in RFO documents, see Appendix A Section 3.9.

114. Existing Tooling: Which specific third-party sensors or legacy SIEM tools must be integrated into the SIEM fabric for the initial deployment phase?

Answer: Vendor proposals are welcome. Vendors must support standards-based integration with TXCC-approved tools identified during design and implementation.

115. Scaling: What is the anticipated growth percentage for network traffic and managed assets over the next 36 months to ensure the "turnkey" solution remains performant?

Answer: Informed by project. Vendors should design for scalable expansion under RFO Section 3.2(d), state assumptions, and provide operational/tiered pricing.

116. Deployment model: Would TXCC consider a cloud-delivered security architecture acceptable if all external components are fully disclosed, approved by TXCC, and hosted in a TX-RAMP Level 2 or FedRAMP Moderate-or-higher environment?

Answer: Yes. Answered in RFO documents, see Section 2.2 and Section 10.

117. Sensor model: Does TXCC require the proposed solution to provide physical or virtual sensors deployed by the vendor, or would TXCC also accept a solution that combines existing boundary controls, telemetry sources, and approved integrations to achieve the required visibility and analytics outcomes?

Answer: Answered in RFO documents, see RFO Section 1.2.1 (equivalent architectures and technical approaches are acceptable if they meet or exceed requirements) and RFO Section 2.4.

118. Routing scope: For the requirement to take over control of unallocated IPv4 Texas State Government IP space and provide a routing solution, does TXCC expect the vendor to operate native routing infrastructure directly, or would an approach that integrates with existing carrier, edge, or customer-managed routing components be acceptable?

Answer: TXCC allows either native routing infrastructure operated by the Vendor, integration with existing carrier/edge/customer-managed routing components, or a hybrid approach, so long as the Vendor demonstrates that the approach satisfies TXCC-approved routing, visibility, security, monitoring, and change-control requirements. The Vendor may not originate, re-home, advertise, withdraw, or alter routes for Texas address space without documented TXCC authority and an approved written change.

119. Inspection boundary: Can TXCC confirm whether the baseline scope is limited to telemetry, metadata, packet headers, flow records, routing data, and security event data, with payload/content inspection only required when separately authorized in writing?

Answer: Answered in RFO documents, see RFO Sections 2.3(l) and 2.7. The default collection boundary is telemetry, metadata, packet headers, flow records, routing data, and security event data; content collection or payload inspection beyond approved defensive use requires written TXCC authorization and General Counsel approval.

120. DPI requirement: Where the RFO references deep-packet inspection, decryption, traffic manipulation, and autonomous enforcement, are all of those functions mandatory on day one, or may vendors propose a phased approach in which certain capabilities are enabled only after TXCC approval and change control?

Answer: Answered in RFO documents, see RFO Sections 2.1, 2.3(a), 2.7, 3.1(b), 3.1(d), and 3.3.

The Vendor must support required capabilities, but production use of decryption, traffic manipulation, autonomous enforcement, payload inspection, and routing changes is subject to TXCC approval, policy governance, logging, reversibility, change control, and proof of authority as applicable.

121. Managed service responsibility: May the response be submitted by a prime contractor with OEM and subcontractor support, with 24x7 monitoring, maintenance, and support responsibilities shared across the team, so long as the prime remains fully accountable to

TXCC?

Answer: Answered in RFO documents, see RFO Sections 12.4, 12.5, and Appendix A Sections 10.7-10.8.

122. Scale assumptions: Can TXCC provide the expected number of sites, insertion points, bandwidth tiers, peak throughput ranges, and data retention assumptions needed for vendors to scope architecture and pricing accurately?

Answer: TXCC is not publishing exact site counts, insertion-point counts, bandwidth tiers, or retention volumes in the question response. Vendors should price the required base turnkey capability and state assumptions for site count, insertion points, throughput, storage, retention, and expansion. Vendors should also provide optional unit pricing or tiered pricing for additional TXCC-approved sites, bandwidth, and storage so TXCC can evaluate scalability.

123. Required integrations: Which integrations should be treated as mandatory at go-live versus optional/future-state for SIEM, case management, ticketing, IAM, administrative authentication, and other TXCC-approved tools?

Answer: At go-live, mandatory integrations must include export of logs, alerts, health metrics, audit records, and operational telemetry to TXCC-approved logging/SIEM and monitoring destinations; administrative authentication through TXCC-approved identity/MFA controls; and notification or ticket creation through TXCC-approved ticketing or case-management processes. Optional or future-state integrations may include bidirectional case management, SOAR workflows, EDR/SASE interoperability, custom API actions, and broader TXCC tool-stack integrations.

124. Global sensing architecture: For the requirement to leverage an existing deployed global sensing architecture, what level of proof is TXCC looking for—existing production references, architecture diagrams, operational metrics, or all of the above?

Answer: TXCC requires proof commensurate with the claim. Vendors should provide architecture diagrams, operational metrics, data sources, geographic or network coverage summaries, existing production references, evidence of contractual rights to use any partner sensing fabric, data-governance controls, and examples of how the sensing capability improves detection or reporting. Customer-identifying details may be redacted where necessary, but the Vendor must provide enough evidence for TXCC to evaluate maturity and scale.

125. Acceptance testing: Can TXCC share additional detail on the acceptance test profile, including target latency thresholds, failover criteria, traffic mix, and the specific response actions and dashboards that must be demonstrated?

Answer: The Acceptance Test Plan must demonstrate, at minimum, contracted throughput with inspection features enabled, measured latency under the approved traffic profile, HA/failover behavior, response actions, dashboards, audit logging, reporting, alerting, and integration with required destinations. TXCC does not prescribe one test tool in the question response; vendors may propose Ixia, Spirent, equivalent tools, synthetic traffic, or TXCC-approved sample data. Numeric latency targets, failover thresholds, and exact traffic mix should be finalized in the approved Acceptance Test Plan.

126. Does TXCC expect the proposed solution to cover both IT and OT environments at initial deployment, or can OT coverage be proposed as an expansion phase?

Answer: Initial deployment must focus on TXCC-designated IT/network boundaries unless TXCC identifies specific OT environments for inclusion. Vendors must demonstrate that the proposed architecture can support OT visibility and safety-aware monitoring where approved, but OT coverage may be proposed as a phased expansion. Any OT deployment must be passive-first unless explicitly approved, must avoid disruption to safety or control processes, and must follow TXCC-approved change control.

127. For hosted components, is TXCC requiring vendor platform authorization, underlying cloud authorization, or both for TX-RAMP / FedRAMP compliance?

Answer: For hosted components that store, process, transmit, manage, or analyze TXCC data, TXCC requires both an authorized hosting environment and an authorized vendor cloud service/platform, unless TXCC's procurement and security review determines that a specific component is not a cloud computing service or does not handle TXCC data. Underlying cloud authorization alone should not be treated as sufficient when the vendor's SaaS, managed platform, or analytics service also handles TXCC data.

128. Can TXCC clarify whether role-based access, MFA, provisioning/de-provisioning, and privileged access controls must be native in the proposed platform, or whether integration with TXCC’s existing IAM stack is acceptable?

Answer: Native controls or integration with TXCC's existing IAM stack are both acceptable if the proposed solution meets TXCC requirements for RBAC, MFA, least privilege, privileged access control, provisioning and de-provisioning, session accountability, and audit logging.

Integration with TXCC-approved identity and administrative authentication controls is preferred where feasible; the solution should not require replacement of TXCC's IAM stack unless TXCC expressly approves that approach.

129. Is TXCC open to solutions where autonomous enforcement is initially limited to advisory or reversible policy actions pending operational validation and written approval?

Answer: Yes. TXCC prefers autonomous enforcement to begin in advisory, monitor-only, simulation, or reversible low-risk modes pending operational validation and written TXCC approval. Production autonomous enforcement must require approved playbooks, risk review, logging, rollback procedures, exception handling, and change-control approval.

130. Can TXCC clarify the expected data retention period, preferred storage location, and any specific evidentiary handling or chain-of-custody standards vendors should price against?

Answer: TXCC has not established a fixed retention period or WORM/immutability requirement in the RFO for raw telemetry, parsed events, or forensic-grade artifacts. Vendors must propose configurable retention by data type and identify hot/searchable retention, archive retention, tamper-evident or immutable storage options, storage location, deletion/erasure procedures, and cost impacts. Forensic-grade artifacts, payload content, decrypted content, and preserved files must be retained only when directed by TXCC and for the duration specified by TXCC.

131. Can TXCC provide the expected quantity of monitored sites, internet access points, boundary locations, and remote collection points that should be included in the initial pricing model?

Answer: TXCC is not publishing specific quantities of monitored sites, internet access points, boundary locations, or remote collection points in the question response. Vendors must price the solution required by the RFO and may propose additional value added elements.

TXCC may…