QA_RFI 36C10B26Q0492 VAEC Brokerage.pdf
PDF 432 KB Posted
- Solicitation number
- 36C10B26Q0492
About this file
This is a Questions and Answers document for RFI 36C10B26Q0492 regarding the VA Enterprise Cloud (VAEC) Brokerage Service. The RFI issued July 2, 2026, with submission extended to July 6, 2026, seeks industry input on cloud brokerage services to expand Cloud Service Provider (CSP) offerings while maintaining centralized credit purchasing. The VA requires responses limited to 50 pages inclusive of all proposal sections and answers to 27 questions across four volumes. Vendors must address how their solution will enable scalable access to AWS and Microsoft Azure (currently operational) with capacity to onboard additional CSPs (OCI and GCP) within 12 months, leveraging FinOps Open Cost and Usage Specification (FOCUS) standards for transparent cost and usage reporting.
Key requirements include establishing a unified Cloud Brokerage Platform maintaining FedRAMP High authorization and SOC 2 Type II attestation, with AWS and Azure operational within six months of contract start. The Broker will manage cloud credit procurement, account setup, billing data validation, tagging enforcement, and financial allocation across multiple CSPs, supporting approximately 297 AWS accounts with 534+ applications and Azure accounts with 240+ applications (growing to over 1,000 total applications). The Broker's focus is credit procurement and cost allocation; optimization, dashboarding, and FinOps tooling remain with VA's existing FinOps program. VA will establish baselines and performance metrics during transition-in and assess acquisition strategy (contract vehicle, set-aside status) post-RFI. The VA currently spends over $100 million annually per established CSP and funds a credit pool that the Prime Contractor draws against quarterly, with VA maintaining root-access to payer accounts and direct enterprise support from CSPs.
View the file
Other files
| File | Type | Posted |
|---|---|---|
| 36C10B26Q0492_4.docx | DOCX document | |
| 36C10B26Q0492_2.docx | DOCX document | |
| 36C10B26Q0492 RFI VAEC Brokerage Service Amended 6.16.26.pdf | ||
| 36C10B26Q0492_1.docx | DOCX document | |
| 36C10B26Q0492.docx | DOCX document | |
| 36C10B26Q0492 RFI VAEC Brokerage Service.pdf |
On GovTribe
Work with this file
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
36C10B26Q0492 – VAEC Brokerage Service Questions and Answers - 0001
Request for Information - 36C10B26Q0492 VA Enterprise Cloud Brokerage Service
Questions and Answers - 0001
Date: July 2, 2026
The following questions have been submitted for RFI 36C10B26Q0492, VAEC Brokerage Service. See below Question and Answer table for further details. All questions submitted from June 2, 2026, through June 10, 2026, have been captured in this document.
Overall Feedback: This Request for Information (RFI) represents the initial step in identifying potential ideas to a key challenge facing VA Infrastructure Operations.
Specifically, this effort seeks industry input on how to expand the range of Cloud Service Provider (CSP) offerings available to stakeholders while maintaining a centralized credit purchasing model.
The objective is to enable scalable access to CSP environments while promoting efficiency, simplicity, and transparency in both consumption and cost for all users.
Vendors are expected to adhere to FinOps Open Cost and Usage Specification (FOCUS) standards to ensure consistent, transparent reporting of cloud costs and usage. Additionally, proposed approaches should demonstrate how the scale of VA demand can be leveraged to achieve more efficient cloud pricing and overall cost optimization without introducing unnecessary overhead or additional costs.
This solution must operate in alignment with other VA enterprise service contracts, including those supporting Infrastructure Engineering and Application Hosting.
Respondents should describe how their approach will enable close, transparent collaboration with these service providers to ensure coordinated delivery, shared visibility into usage and costs, and seamless integration across the VA cloud ecosystem. Responses to this RFI will help inform future acquisition strategies and solution approaches.
# Reference Question / Response
RFI Title Page Question: The title page of the RFI is labeled CUI and the pages are labeled CUI, however, there is no CUI designation indicator.
Question: Is it the Governments’ intent that the RFI is labeled as CUI?
Response: This was an unintentional marking. Please disregard.
2 Section 4.2 RFI Response Format;
Section 4.3 RFI Response Content Structure Pg. 38
Question: Section 4.2 states that the maximum count for the RFI is 40 pages with pages numbered sequentially. Section 4.3 Response Content says the response must be split into four volumes.
Would the Government confirm Response Content is alluding to the proposal sections?
VA Response: Please limit your responses to 50 pages inclusive of any proposal sections (e.g. past performance) as well as responses to the 27 questions.
3 Section 4.3 RFI Response Content Structure Pg. 38
Question: Section 4.3 asks for past performance information along with CPARS and/or letters of commendation.
Would the Government confirm that any CPARS or letters of commendation can be provided as an Appendix to the RFI?
VA Response: Please limit your responses to 50 pages inclusive of any proposal sections (e.g. past performance) as well as responses to the 27 questions.
4 Section 4.3 RFI Response Content Structure
Pg. 39
Question: Would the Government consider increasing the total allowable page count to 50 pages across all volumes to enable offerors to provide a comprehensive program-level vision and to more fully address the technical requirements as well as the 27 submitted questions?
VA Response: Please limit your responses to 50 pages inclusive of any proposal sections (e.g. past performance) as well as responses to the 27 questions.
5 Section 4.4 Submission Instructions
Pg. 40
Question: Would the Government consider an extension to the RFI submission date of June 30, 2026?
VA Response: VA has extended the RFI to July 6, 2026
6 Section 1 Statement of Objectives
(SOO)
Section 2 Performance Work Statement
(PWS)
Pgs. 3, 11
Question: With both approaches mentioned in the RFI – Would the Government clarify, does the VA intend to use a SOO (Offeror provided PWS with proposal) or a VA provided PWS with RFP as part of the acquisition strategy for this future opportunity?
VA Response: VA will consider RFI responses before determining the final strategy with respect to the format of the requirement. If industry has any recommendations, list the feedback in your response and the rationale.
7 SOO 1.2;
PWS 2.3.1.2,
2.3.2.2, 2.3.4.1;
SOO 1.4
Question: Section 1.2 references three FedRAMP High CSPs but names only AWS and Azure. Section 2.3.1.2 Requires the contractor to maintain the organizational structure of all four CSPs. The PWS treats Oracle Cloud Infrastructure (OCI) as a firm requirement (2.3.1.2, 2.3.2.2, 2.3.4.1) while Google Cloud Platform (GCP) appears as “if applicable.”
Question: To ensure VA receives a Broker capable of rapidly responding to emerging needs with additional CSPs in the future, given VA’s evolving requirements, would VA be open to revising the Objectives to require four CSPs?
VA Response: VAEC is currently comprised of AWS and Microsoft Azure. VA’s intent is that:
“The Contractor shall ensure the platform for AWS and Microsoft Azure is operational within 6 months of contract start and additional CSPs are onboarded and operational within 12 months.” Additional CSP’s would need to be proposed and evaluated through the solicitation process.
8 SOO 1.2; SOO
1.3, #9
Question: Section 1.2 references scope is limited to procurement and financial-allocation only and no optimization or FinOps tooling, however Section 1.3 #9, request cost optimization recommendations and AI predictive analytics, Section 1.4 requires Monthly FinOps reports with trend analysis and anomaly detection & real-time dashboards. These efforts are key pillars of a standard broker and FinOps team.
Is VA open to a solution that would encompass FinOps capabilities with the broker services?
VA Response: Vendors are welcome to present their suggested solutions or optimal approach to VA’s requirement. VA’s intent with the Cloud Broker’s job is to help VA manage cloud purchasing, account setup, billing data, tagging enforcement, and financial allocation across multiple cloud providers. The Broker will gather and validate billing data, enforce tagging policies, manage cloud accounts, and support VA governance processes. Their focus is on procurement, cost‑allocation, and providing clean, accurate data that VA’s FinOps team can use.
9 SOO 1.3, #7;
Pg. 6
Question: Section 1.3 #7 references with the VA SOC, Enterprise Security Architecture & CDM programs but does not provide sufficient background throughout the documents for the responders to provide a suitable solution.
Question: Can the Government provide clear requirements for the tools that will be integrated with the SOC and CDM programs?
VA Response: VA will take this observation into consideration for an upcoming solicitation.
10 SOO 1.4 (O-10);
SOO 1.6;
PWS 2.3.1.1;
PWS 2.8 (CDRL
015)
Question: The RFI describes a Cloud Brokerage Platform with mature FinOps and cloud-management capabilities, asks respondents to characterize it as proprietary, COTS, or hybrid (Question 1), and anticipates ongoing platform release notes (CDRL 015). Objective O-10 requires the platform to maintain SOC 2 Type II attestation throughout the period of performance, and Section 1.6 requires AWS and Azure operational within six months of contract start.
Because a SOC 2 Type II attestation requires an audit observation period over an operating system, does VA require an existing, commercially operating platform at the time of award, or will VA consider a platform that is developed or assembled after award?
We ask because Question 9 appears to contemplate platforms still pursuing authorization.
Clarification would help respondents understand whether the requirement favors established platform providers over integrators proposing a build-to-suit solution.
VA Response: Existing CSP’s (AWS and Azure) have an existing SOC I, II, III Attestations.
VA would require the Vendor to maintain the attestation. New CSP’s would require onboarding within 12 months.
11 SOO 1.4 O-1/O-
2;
PWS 2.3.2.1;
Sec. 5 Question 6/ Question 16
Question: To inform commitment sizing and credit expiration planning, can the VA please provide FY-to-date and prior-year cloud spend by CSP (AWS/Azure/OCI/GCP), plus forecast guidance?
VA Response: VAEC is currently comprised of AWS and Microsoft Azure only. A future solicitation would define the Not-To-Exceed (NTE) Credit ceiling limits per CSP.
12 SOO 1.4 (O-10);
PWS 2.3.5.1;
SOO 1.6; Sec. 5 Question 9
Question: Objective O-10 requires the brokerage platform to maintain FedRAMP High and SOC 2 Type II throughout the period of performance, and PWS 2.3.5.1 requires obtaining and retaining an ATO, while Section 1.6 requires AWS and Azure operational within six months.
Question A: Will the Government require offerors to hold an existing FedRAMP High authorization at award (or within six months), or will VA sponsor a platform with an authorization in process?
Question B: Would a VA ATO build upon a FedRAMP High P-ATO satisfy Objective O-10?
VA Response:
A. VA would prefer Vendors propose their preferred solution. VA will then evaluate and determine the requirement in the future solicitation.
B. It would depend on the proposed solution.
13 SOO 1.4 (O-1,
O-2);
PWS 2.3.2.1;
QASP 3.2
(Measures #4, #5)
Question: Objective O-1 measures a 40% credit-procurement cycle-time reduction against a baseline “established during transition-in,” and Objective O-2 sets 98% chargeback accuracy.
Neither objective has a stated current value.
Question A: Can VA share current annual cloud spend, current credit-procurement cycle time, current chargeback methodology and accuracy, and current tagging-compliance rate?
Question B: Will early-period targets be formally re-baselined following transition-in?
VA Response:
A. VA is not prepared to share its annual spend. However, in general terms, VA’s annual spend for existing CSP’s exceeds $100M annually for each established CSP.
B. The baseline would be established in the transition-in period.
14 PWS 2.3.2.4;
SOO 1.4 O-2
Question:
Question A: Which VA financial system(s) will consume chargeback/showback data (e.g., SAP/Oracle Financials)?
Question B: What data interface standards (file formats, cadence, validations) are required?
VA Response:
A. Currently VA uses IBM’s Apptio and Cloudability
B. VA incorporates each CSPs cloud native cost and usage reporting. The cadence and validation is daily.
15 SOO 1.5; SOO
1.4 (O-5, O-7, O-12);
PWS 2.3.2.2,
2.3.4.1; PWS
2.8 (CDRL 002,
003, 013);
QASP 3.2
(Measures #7, #9)
Question: Section 1.5 excludes new cost-visibility dashboards, optimization engines, RI/SP analytics, savings-plan governance, and policy-as-code layers that overlap existing VA tools.
However, Objectives O-5, O-7, and O-12; PWS Task Areas 2.3.2.2 and 2.3.4.1; CDRLs 002, 003, and 013; and QASP Measures #7 and #9 (including a 15% annual savings target) appear to require these same capabilities.
Question A: Where the exclusions and the requirements conflict, which governs?
Question B: Will VA provide an inventory of the existing FinOps and governance tools, with integration interfaces, that the Broker must integrate with rather than duplicate?
VA Response:
A. VA expects the Broker to help VA manage cloud purchasing, account setup, billing data, tagging enforcement, and financial allocation across multiple cloud providers.
The Broker will gather and validate billing data, enforce tagging policies, manage cloud accounts, and support VA governance processes. Their focus is on procurement, cost allocation, and providing clean, accurate data that VA’s FinOps team can use.
B. VA will be assessing the requirement to remove duplicative requirements. What the Broker will not do is just as important: they are not responsible for optimization, cost saving recommendations, dashboards, forecasting, AI analytics, anomaly investigation, or any FinOps tooling. Those duties stay with VA’s existing FinOps program.
16 PWS 2.2;
2.3.1.4, 2.3.4, 2.3.4.4, 2.3.5
Question: Within PWS §2.2 (Definitions), “Customer Journey” ends at provisioning and notes that “continuance into Sustainment and Operations Management are NOT within the scope of this PWS.” However, other sections require ongoing operations such as Platform Availability (99.9%) (§2.3.1.4), Governance monitoring (§2.3.4), Drift Detection (§2.3.4.4), and Security integration/incident response (§2.3.5).
Question: Can the government confirm that “sustainment and operations” responsibilities referenced in §§2.3.1.4, 2.3.4, 2.3.4.4, and 2.3.5 apply to:
(a) the Cloud Brokerage Platform itself (availability, security integration, and continuous compliance), and
(b) the Broker’s governance/policy-as-code and drift management across CSP control plane
VA Response:
VA will take these questions into consideration for revision for an upcoming solicitation.
17 SOO §1.2, §1.5
(Out of Scope)
PWS §2.3.2
(Credit Procurement &
Financial Management)
PWS §2.3.2.5
(Budget Forecasting and Anomaly Detection)
Question: How does the VA intend to delineate clear operational boundaries between the Cloud Brokerage Service and existing FinOps programs, particularly regarding cost optimization recommendations, reporting dashboards, and anomaly detection, to avoid duplication while still meeting requirements in Task Area 2?
Why ask this: The SOO and PWS repeatedly emphasize that the broker must not duplicate existing FinOps capabilities (e.g., dashboards, optimization tooling), yet several required tasks (e.g., forecasting, optimization recommendations, dashboards) appear to overlap with typical FinOps functions.
VA Response: VA will better define the boundaries prior to solicitation. If Vendors have best practices or suggestions, please include them in your response.
18 SOO §1.3(6)
(tiered reporting dashboard)
SOO §1.5, p.9 (prohibition)
PWS §2.8
CDRL-002, p.30 (“Monthly
FinOps Dashboard”)
Question: CDRL-002 requires the Contractor to deliver a “Monthly FinOps Dashboard” with cost trends, optimization recommendations, anomaly alerts, and savings realization, while SOO 1.5 prohibits the Broker from operating FinOps dashboards or reporting systems that duplicate current VA FinOps. Which specific dashboards and reports will the Broker own and deliver, and which remain VA FinOps deliverables that the Broker only supplies data to?
Why ask this: Two binding requirements name the same artifact in conflicting ways. CDRL-002 contents match the optimization and reporting functions SOO 1.5 excludes. The answer sets which reporting components enter Volume I, the WBS, and the cost basis, and it prevents a duplication finding at award.
VA Response: VA will assess SOO 1.3(6) to ensure it is not duplicated on another VA effort.
19 QASP §3.2 #9,
p.34 (15% savings AQL)
SOO §1.5
(optimization out of scope)
PWS §2.3.2.2
Question: QASP measure #9 holds the Contractor to a 15% annual cloud-spend reduction through optimization activities (RI/SP, rightsizing, waste elimination), yet SOO 1.5 places optimization engines and algorithms out of scope. Is the Broker contractually accountable for achieving the 15% savings target, and if so, how will VA measure Broker attributable savings when the optimization tooling belongs to the VA FinOps program?
Why ask this: A surveillance measure with a 15% target creates direct contract risk that the response must price and commit to or formally qualify. The Broker cannot accept a savings AQL for outcomes produced by tooling it does not own. The answer determines whether the supplier commits to the AQL, proposes a shared-attribution method, or recommends VA reassign the measure, and it drives the fee and risk posture in the cost volume.
VA Response: VA will assess QASP measure #9 for applicability and potential removal.
20 PWS §2.3.2.2,
p.16 (“recommend and/or execute”)
PWS §2.3.2.2
(savings realization report)
Question: PWS 2.3.2.2 states the Contractor shall “recommend and/or execute cost optimization strategies.” Does VA expect the Broker to recommend optimization actions only, or to also execute them in VA cloud environments, and against what on-demand baseline and time period will the monthly savings realization report measure actual savings?
Why ask this: The “and/or” wording leaves the most labor-intensive scope undefined, so effort and staffing cannot be sized from the text. Execution authority and the savings baseline set the FinOps Lead workload, the automation depth in the work breakdown structure, and the credibility of any savings commitment. The answer lets the supplier size the optimization-execution effort precisely rather than carry a wide cost range.
VA Response: VA will take this question into consideration for an upcoming solicitation.
21 SOO §1.3(1)-
(2), pp.5-6
PWS §2.3.2.1,
p.15
SOO §1.5
(RI/SP analytics out of scope)
Question: SOO 1.3(2) directs the Broker to execute Reserved Instance, Savings
Plan, Committed Use Discount, and Enterprise Discount Program strategies on VA’s behalf, while SOO 1.5 excludes RI/SP analytics. Does VA expect the Broker to purchase and hold these commitments on VA’s behalf, and if so at which account level, given that AWS prohibits partners from sharing Reserved Instances and Savings Plans across customers as of June 1, 2025?
Why ask this: Commitment-purchasing authority is both a scope boundary and a feasibility constraint that changes the procurement design. Cloud-provider partner policies limit how a broker can transact commitments, so VA and the Broker face the same constraints. The answer defines the procurement service the Broker builds, the appropriations controls it enforces, and the honest savings the response can claim.
VA Response: VA will assess SOO 1.3(1)-(2) to ensure it is not duplicated on another VA effort.
22 SOO §1.7, p.10 (FFP travel built into the CLIN)
PWS §2.8 (FFP
CLIN structure)
SOO §1.3(1)
(consumption model)
RFI §5,
Category C (pricing questions), Question 14
Question: The RFI references firm-fixed-price travel and an FFP CLIN structure while also describing a variable, consumption-based cloud model.
Can the government please clarify whether the VA's intent is to gather market research on industry standard pricing models or has it decided to solicit FFP?
Why ask this: The contract type sets the entire pricing model, the fee base, and how the supplier frames illustrative pricing in this response. A firm-fixed-price structure and a variable consumption model imply different risk allocation and different estimating methods. The answer lets the supplier align its Volume IV pricing framing now and build a realistic cost volume for the RFP rather than guess the Government’s intended structure.
VA Response: Vendors are encouraged to submit information on industry standard pricing models.
23 SOO §1.3(1)
(“procure … on behalf of the
VA”)
PWS §2.3.2.1,
p.15 (“executing credit purchases … in ccordance with Aapproved procurement authorities and appropriation constraints”)
Background ($50M+ annual cloud spend)
Question: How will the underlying cloud consumption (the $50M-plus annual credit spend) be funded and accounted for? Does the Contractor purchase cloud credits with contractor funds and invoice VA as a passthrough other direct cost, or does VA fund a credit pool the Broker draws against, and is that consumption inside or outside the brokerage contract value?
Why ask this: The funding mechanism determines whether the cloud spend sits on the Contractor’s books and whether it counts in the contract value, which changes the fee base and the working-capital exposure. Pass-through treatment and a VA-funded pool produce very different estimates and risk. The answer is decisive for any percentage-of-spend or fee calculation in the cost volume.
VA Response: Currently VA funds a credit pool that the Prime Contractor draws against. Due to the Volume of credits, VA and the Prime monitors the pool of credits and VA replenishes credits quarterly, ensuring the Government is not deficient.
24 PWS §2.5, p.28 (furnish all software licenses unless GFP in §2.4)
PWS §2.4
(Government- Furnished
Property)
PWS §2.3.1.1 /
§2.3.5.3 (ServiceNow, Splunk, SailPoint, Okta, AD/Entra)
Question: Which enterprise platform licenses and environments will VA furnish as Government-Furnished Property under PWS Section 2.4, specifically ServiceNow, Splunk, SailPoint, Okta, Active Directory and Entra ID, and the CSP organization accounts, and which must the Contractor license and fund?
Why ask this: The RFI references integration with these VA systems, but the Section 2.4 GFP list was not included in the package we received. Enterprise licensing at VA scale is one of the largest cost drivers, so the GFP boundary swings the estimate substantially. If the Broker must license ServiceNow, Splunk, and identity platforms at enterprise scale, the cost basis changes materially. The answer prevents both double counting Government-furnished items and under-pricing tools the Contractor must supply.
VA Response: VA will furnish the licensing mentioned above. If your solution requires software not currently at VA, the Vendor will need to provide that SW with their solution. Any additional SW will require TRM approval to be installed in the VA network.
25 PWS §2.3.1.1
(API integration)
SOO §1.3(8) /
PWS §2.3.6
(transition)
As-Is environment (existing request/provisio ning system of record)
Question: Will VA provide the incoming Contractor with access to, and integration with, the existing cloud request and provisioning system of record and its historical workflow data during transition, and does VA expect the Broker to integrate with that system or replace it? Will that system and data be treated as Government-Furnished Information?
Why ask this: The integrate-versus-replace decision changes the transition design, the interface count, and the data-migration risk, all of which drive cost and schedule. Preserving incumbent workflow data avoids a data-loss event the response must plan around. The answer defines the transition architecture and the integration effort the supplier sizes in the WBS.
VA Response: Yes, VA will provide access to the existing CSP provisioning process. Yes, this would be treated as Government-Furnished Information.
26 SOO §1.5, p.9 (“current VA FinOps efforts”)
PWS §2.3.2
(FinOps tasks)
Question: Which specific FinOps platform or tooling does the existing VA FinOps program operate today, and which functions does it perform, so respondents can scope clean-data interfaces to it without duplicating its capabilities?
Why ask this: The Broker must feed clean data to the existing FinOps program without recreating it, but the response cannot design that interface without knowing the platform in use.
Naming the tooling sharpens the scope boundary the whole strategy depends on. The answer lets the supplier define exact data hand-offs and avoid both duplication findings and integration rework.
VA Response: VA currently uses a combination of CSP Native Optimization Tools, Cloudability, Apptio, ServiceNow, and manual processes. The tools identify potential optimization opportunities, but do not implement the recommendations.
27 PWS §2.3.1.1
(“FedRAMP Highauthorized environment”)
PWS §2.3.5.1
(“obtain and retain an
ATO following
VA GRC”)
Att 6-6 SR04 (maintain ATO / cATO)
Question: Does VA require the brokerage platform itself to hold a FedRAMP High authorization listed on the FedRAMP Marketplace at the time of award, or is a VA agency ATO at the FedRAMP High baseline (inheriting controls from FedRAMP High infrastructure) acceptable, and will VA act as the sponsoring agency for the platform authorization?
Why ask this: This single distinction decides feasibility, the authorization timeline, and the platform design. A marketplace-listed High product and a VA agency ATO on High infrastructure carry very different schedules and costs. The answer determines whether the supplier proposes an inheritance-based authorization, pursues a sponsored High authorization, or both, and it sizes the largest single cost driver in the estimate.
VA Response: No, if the solution inherits existing FedRAMP status. If it is a separate SaaS solution, further discussion would be required.
28 SOO §1.4, p.7 (AWS+Azure operational within 6 months)
PWS §2.3.5.1
(ATO)
Att 6-6 SR04
Question: Does VA expect a full Authorization to Operate before the platform goes live, or will VA permit operation under an interim or conditional authorization during the six-month transition, with full ATO achieved by a defined milestone?
Why the ask: The authorization milestone collides with the six-month operational deadline, so the answer governs the transition schedule and its risk. A High-baseline authorization can take far longer than six months without inheritance or an interim path. The answer lets the supplier sequence the transition realistically and price the authorization effort against a known gate.
VA Response: If the Vendors solution is based on a new platform, then a Full ATO would be required.
29 PWS §2.3.5.5,
p.18 (“current VA Policy timeframes”)
QASP §3.2 #6,
p.34 (15-min P1 at 100% AQL)
Att 6-2 (P2 30 min, P3 2 bus.
hrs, P4 1 bus.
day)
PWS §2.6(5)
(NSOC report within 1 hour)
Question: Which incident-response standard is binding for the follow-on contract: the “current VA Policy timeframes” cited in PWS 2.3.5.5, the 15-minute Priority 1 response at 100% AQL in the QASP, or the Attachment 6-2 tiers (P2 30 minutes, P3 2 business hours, P4 1 business day)? How do these acknowledgment timeframes relate to the 1-hour NSOC incident-reporting requirement?
Why ask this: The documents state at least three different response commitments, so the response cannot set a defensible SLA without the binding figure. The 15-minute Priority 1 standard drives around-the-clock security-operations staffing. The answer sets the incident-response service level the supplier commits to and the staffing cost it carries.
VA Response: VA will be removing the Broker responsibility for Incident response requirements.
30 SOO §1.4 / §1.6
(AWS+Azure in 6 mo., additional CSPs in 12)
PWS §2.3.1.2
(names AWS
Organizations, Azure Management
Groups, GCP Folders, OCI
Compartments)
Question: In preparation for future growth, can the VA share its expected growth over the next 3 to 5 years?
Why ask this: The provider set and its priority drive the multi-CSP onboarding plan, the connector build, and the per-provider authorization effort. PWS 2.3.1.2 implies Google Cloud and Oracle Cloud Infrastructure, which the response would otherwise have to assume. The answer lets the supplier size onboarding to named providers rather than a placeholder assumption.
VA Response: VA Consumption has historically seen annual growth between 5-10% annual growth. Future growth will likely be in this same range, but is dependent on VA needs.
31 SOO §1.3(4)-(6)
/ PWS §2.3.3
(Customer
Journey, intake-to-provisioning)
PWS §2.3.1
(ongoing operations Task
Areas)
Question: Please clarify the boundary between the Customer Journey intake-to provisioning scope and the ongoing operations Task Areas. Does the Broker’s responsibility end once a resource is provisioned, with Day-2 operations and sustainment of the provisioned workloads remaining with VA or the application owners, and if not, what steady-state operational duties fall to the Broker?
Why ask this: The overlap risks conflating one-time onboarding with steady-state operations, which changes the recurring labor in every option year. Day-2 responsibility for provisioned workloads would expand scope and cost well beyond brokerage. The answer fixes the option-year staffing model and prevents an over- or under-scoped sustainment estimate.
VA Response: Yes, Broker’s responsibility ends once provisioned. Consumption analysis and reporting will continue to be Broker’s responsibility. Day-2 operations and sustainment will be covered under a separate effort.
32 QASP §3.2 #5,
p.34 (40% reduction
“from baseline established during transition-in”)
SOO §1.3(1)-(4)
(procurement, chargeback, provisioning)
Question: Can VA provide current-state baseline metrics for the functions the QASP measures, specifically the current credit-procurement cycle time, the current chargeback accuracy and variance, the current percentage of automated provisioning, and the current monthly volume of provisioning requests?
Why ask this: The 40% improvement target is measured from a transition-in baseline, so without today’s numbers the response cannot judge achievability or size the automation effort.
Baseline metrics turn a committed percentage into a defensible engineering target. The answer reduces estimating uncertainty and supports a credible performance commitment in the RFP.
VA Response: The baseline would be established in the transition-in phase.
33 PWS §2.3.1.2
(account hierarchies)
PWS §2.3.2.4
(chargeback to cost centers)
Background (757 applications, $50M+ spend)
Question: For sizing, how many CSP accounts and subscriptions does VA operate today across AWS and Azure, how many VA business lines and organizational cost centers will receive chargeback, and what application or account growth does VA project over the period of performance?
Why ask this: Account count, cost-center count, and growth are the dominant sizing drivers for governance, security monitoring, and chargeback, so the estimate depends on them. The current 757-application figure does not by itself size the managed-account population or the chargeback hierarchy. The answer lets the supplier size the recurring operations and the cost basis to real volumes.
VA Response:
AWS – 297 Accounts, 534+ Applications
Azure – XXX Accounts, 240+ Applications
Each application receives chargeback. VA expects the application count to reach >1000 applications.
34 Sources Sought Notice (NAICS 518210;
Set-Aside field blank)
RFI §5 (teaming and prime-vehicle list)
Question: For the follow-on procurement, does VA anticipate a full and open competition or a small-business set-aside under NAICS 518210, and does VA intend to compete it as a standalone contract or through an existing vehicle such as GSA MAS, NASA SEWP, or
OASIS+?
Why ask this: Set-aside status and the contract vehicle determine whether the supplier competes as a prime or must team, which shapes this response and the bid strategy. The Sources Sought notice leaves the set-aside field blank and the vehicle undetermined. The answer lets the supplier position teaming and prime-versus-subcontractor decisions before the RFP issues.
VA Response: VA intends to assess Vendor responses, capabilities, and recommendations prior to determining the acquisition strategy.
35 SOO §1 Question: Can the VA clarify whether performance under this requirement could create any Organizational Conflict of Interest (OCI) that may impact the awardee’s ability to compete for future, similar, or follow-on efforts? Please provide guidance on the VA’s preferred approach for identifying, mitigating, and managing any such OCI to ensure continued participation in related procurements?
VA Response: VA does not anticipate that this effort will create an OCI for other efforts.
36 Pg. 1 Question: We respectfully request an extension for this RFI due to the holiday on June 19th that many respondents must account for.
VA Response: VA will extend the RFI to July 6, 2026. Please do not expect further extension.
37 PWS Section 2.3.2.1
Question: Multi CSP Credit Procurement. In the past blocks of accounts were purchased and provisioned prior to being assigned. Once Assigned they would be renamed. What is the current estimate for provisioning per CSP per month? What is future estimate for provisioning per month?
VA Response: VA does not administer accounts as described above. Account provisioning and deprovisioning is dependent on future business needs and may vary.
38 Section 1.5 Scope
Boundaries / Out of
Scope Activities
Question: Section 1.5 states that cloud optimization tooling, FinOps dashboards, RI/SP analysis, and architecture onboarding accelerators are outside the scope of this effort because those capabilities already exist within VAEC. However, Sections 2.3.2 and 2.3.4 require the contractor to perform cloud optimization, forecasting, anomaly detection, governance reporting, and policy enforcement activities. Can the Government clarify the intended division of responsibilities between existing VAEC capabilities and the future Cloud Brokerage Service?
VA Response: VA will assess Sections 2.3.2 and 2.3.4 to ensure those requirements are not duplicated on another VA effort.
39 PWS Section
2.3.1.1 –
Platform Deployment and Configuration
Question: Can the Government clarify whether offerors are expected to provide a contractor-owned Cloud Brokerage Platform solution, or whether the successful contractor will configure, integrate, and operate a government provided platform capability?
VA Response: VA is not dictating the Cloud Brokerage Platform solution. Vendors should submit their optimal solution based on the requirements.
40 PWS Section
2.3.1.2 –
Multi-CSP Account and
Subscription
Management
Question: Can the Government clarify whether Oracle Cloud Infrastructure (OCI) and Google Cloud Platform (GCP) management capabilities are required at contract award, or whether these are anticipated future-state capabilities to be introduced during contract performance?
VA Response: VA’s current requirement is only to accommodate additional CSP’s beyond AWS and Microsoft Azure, should they be required.
41 PWS Sections 2.3.2, 2.3.3, and 2.3.4
Question: The Cloud Brokerage Service is expected to accelerate provisioning while simultaneously increasing governance, compliance review, financial oversight, and security controls. Has VA established baseline performance metrics identifying where delays currently occur within the onboarding and provisioning process, and which portions of the workflow are expected to be streamlined through this effort?
VA Response: Baselines performance metrics would be established in a phase-in period. As VA matures through the performance of this projected order, we will be defining workflow streamlining opportunities.
42 RFI 4.3 RFI
Response
Content Structure
Question: Can the government clarify whether each volume should be submitted as its own individual document? Or does the government intend for respondents to deliver one document containing all volumes of the response?
VA Response: Due to the page limit and ease of analysis, VA would recommend submitting one document.
43 General Question
Question: Will the future acquisition remain platform-neutral, or does VA expect offerors to propose a specific commercial automation platform?
VA Response: No, VA does not expect Vendors to propose a specific commercial automation platform.
44 General Question
Question: How will VA define “eligible new infrastructure provisioning” for measuring the Month 12 adoption target?
VA Response: Additional CSP’s beyond AWS and Microsoft Azure would be coordinated through the VA Contracting Office and the Vendor prior to adoption.
45 General Question
Question: Should reusable modules/blueprints focus primarily on new automation patterns, or is VA expecting conversion of existing legacy scripts into governed modules?
VA Response: VA is expecting the Broker to assess and recommend optimal solutions.
46 General Question
Question: Does VA prefer any policy-as-code framework, language, or standard, or should offerors propose one based on the selected platform?
VA Response: Vendors should provide a response that details their optimal solution based on the requirements.
47 General Question
Question: Which ServiceNow processes and data objects must be integrated, for example change, request, incident, task, approval, CMDB CI, or audit records?
VA Response: VA is not prepared to answer this question at this time.
48 4.4 Submission Instructions
Question: Where should respondents include Teaming Arrangement details within the RFI Response Structure? Does this count against page limitations?
RFI Language: [Teaming Arrangements] "Respondents planning to team or subcontract for significant portions of the work should identify team members and their respective roles in the response."
VA Response: VA would recommend addressing teaming arrangements in Volume II:
Management Approach.
49 4.3 RFI
Response Content Structure, Volume IV:
Market Research Questionnaire (Maximum 5 pages)
Question: "Section 5: Market Research Questions" consists of 4 pages of questions. Given the maximum 5 pages for Volume IV, would the Government consider extending the page limitations for this Volume?
RFI Language: "Complete responses to all market research questions presented in Section 5 of this document. Responses should be concise and directly address each question with specific, factual information."
VA Response: See question 2.
50 1.2 Background Question: Can the VA confirm what native CSP tooling they are currently leveraging (e.g., Azure Cost Management, AWS Cost Explorer, or FinOps dashboards), and how they envision those being used alongside, or replaced by the Cloud Brokerage platform?
RFI Language: "To avoid duplication, this RFI is not seeking solutions that recreate or replace existing FinOps dashboards, cost‑optimization tooling, tagging frameworks, or multi‑cloud visibility services."
VA Response: Currently, VA uses IBM’s Apptio and Cloudability for reporting purposes. VA incorporates each CSPs cloud native cost and usage reporting. VA recommends Vendors respond with their optimal solution. VA would envision retaining use of CSP cloud native optimization tools such as AWS Compute Optimizer or Microsoft Azure Advisor and Cost Management.
51 1.3 Scope Question: Can the VA confirm whether cloud credits/consumption and brokerage/managed services are expected to be priced and procured as separate line items, or if a bundled pricing model is preferred?
"Multi-CSP Credit and Commitment Procurement and Management. The Contractor shall procure, allocate, track, and reconcile cloud credits, reservations, and financial commitments across all managed CSP environments on behalf of the VA."
VA Response: VA prefers a cost model that provides transparent cost allocation between Brokerage fees and CSP credit pricing. Vendors are encouraged to recommend the best industry standard based on VA’s requirements.
52 5: Market Research Questions, Category C:
Pricing and Commercial Models
Question: Can you provide spend for AWS, Azure, GCP, and Oracle environments. And estimated growth metrics?
RFI Language: Question 17. What is your approach to cost optimization, and what measurable savings have you achieved for customers of similar scale (700+ applications, $50M+ annual cloud spend)? Provide specific metrics and case studies where possible.
VA Response: See Question 13.
53 1.4 Objectives Question: Will additional CSPs be added during the contract?
"Establish a unified Cloud Brokerage Platform supporting a minimum of two (2) FedRAMP High-authorized CSPs (AWS and Microsoft Azure) with capacity to onboard additional CSPs."
VA Response: VA is planning for the possibility of onboarding additional CSPs throughout the lifecycle of this contract.
54 N/A Question: Are CSP Premium/Enterprise support tiers required? Direct support from CSP or Partner Led?
RFI Language: General - Technical Support
VA Response: VA Currently has direct CSP access to Enterprise Support. VA would expect continued support direct from the CSP.
55 N/A Question: Does the VA require root-access of payer accounts?
RFI Language: General - Technical Support
VA Response: Yes.
56 5: Market Research Questions, Category C:
Pricing and Commercial Models
Question: Will the VA consider an AWS Private Pricing (PPA) Commitment contract?
RFI Language: "Question 15. What enterprise discount programs, volume commitments, or strategic pricing arrangements can you facilitate across CSPs? Describe your negotiating leverage with major CSPs and any existing strategic partner agreements."
VA Response: Vendors are encouraged to provide recommendations on how to best meet VA needs considering the objectives VA has presented. If there is an advantage to an AWS PPA, you should detail that in your response.
57 N/A Question: Is AWS Government Competency required for bidders?
RFI Language: General - CSP Certifications
VA Response: CSP Competency is preferred but not anticipated to be a contractual requirement at this time.
58 Acquisition Structure
Question: Does the Government anticipate setting aside the resulting solicitation for small business or a socioeconomic category, such as SDVOSB, VOSB, 8(a), or WOSB, or does the Government expect the acquisition to remain full and open?
VA Response: VA is in the market research phase and will assess the results of the RFI to help determine if this requirement is a candidate for a set-aside.
59 Acquisition Structure
Question: What contract vehicle or vehicles is the Government considering for the resulting solicitation, such as T4NG2, Alliant 2, CIO-SP4, SEWP, or open market?
VA Response: VA is in the market research phase and will assess the results of the RFI to help determine the most appropriate contract vehicle.
60 CSP
Procurement Authority and Funding Mechanism
Question: Please clarify the intended role of the Cloud Broker in procuring and managing CSP credits and commitments.
VA Response: Please assess the requirements of the RFI and provide your optimal solution or recommendation for meeting VA’s need.
61 CSP
Procurement Authority and Funding Mechanism
Question: Will the Broker hold CSP enterprise agreements, Enterprise Discount Programs, or reseller/channel partner relationships directly, or will VA remain the contracting party with the Broker managing allocation, tracking, and reconciliation?
VA Response: VA requests Vendors provide their recommended approach for the arrangement between VA, the Broker, and the CSP.
62 CSP
Procurement Authority and Funding Mechanism
Question: What funding mechanism does the Government anticipate for CSP credits, such as pass-through reimbursement, cost-reimbursable CLINs, or VA-obligated funds managed through Broker-supported processes?
VA Response: VA anticipates established ceilings for each CSP and is looking for Vendor recommendations that will result in optimal credit management and visibility. VA would anticipate quarterly up-front credit commitments.
63 CSP
Procurement Authority and Funding Mechanism
Question: What types of Reserved Instance/Savings Plan commitments would the Broker be authorized to recommend or execute on VA's behalf, including no-upfront versus all-upfront commitments, one-year versus three-year terms, dollar thresholds, and required approval gates?
VA Response: VA has previously been approved for one-year up-front Reserved Instances (RI’s)/Savings plans due to the typical option year structure, annual appropriations, and how they relate to the Anti-Deficiency Act. VA has executed RI’s/Savings plans at both the application level and at the enterprise level. VA would like to see what a Broker can offer for the longer-term RI’s/Savings plans.
64 Fiscal Compliance for Multi-Year Cloud Commitments
Question: Reserved Instances and Savings Plans may involve one-year or three-year commitments that cross fiscal years. How does VA intend to fund and obligate these commitments in accordance with the Bona Fide Needs Rule and the Anti-Deficiency Act?
VA Response: See question 63.
65 Fiscal Compliance for Multi-Year Cloud Commitments
Question: Will the Broker execute commitments only after VA obligates funds, or is the Broker expected to carry any financial exposure between VA funding cycles?
VA Response: VA does not anticipate financial exposure between VA funding cycles. VA would anticipate quarterly up-front credit commitments.
66 FinOps Scope Boundary and QASP Savings Measures
Question: Sections 1.2, 1.3, and 1.5 appear to limit the Broker's role to cloud credit procurement, allocation, and chargeback, while excluding duplication of existing VA FinOps dashboards, optimization engines, tagging frameworks, and related tooling. However, CDRL 002, CDRL 013, QASP Standard 9, and Objectives O-5 and O-12 appear to measure the Broker on FinOps dashboards, cost optimization recommendations, and annual savings outcomes.
Please clarify the intended scope boundary.
VA Response: Please refer to the introductory Paragraph for the intended scope.
67 FinOps Scope Boundary and QASP Savings Measures
Question: Is cost optimization within the Broker's scope, and if so, what activities may the Broker perform without duplicating the existing VA FinOps program?
VA Response: The Broker would be expected to conduct credit rate optimization reporting.
68 FinOps Scope Boundary and QASP Savings Measures
Question: Will the Broker be held accountable under the QASP for savings outcomes if optimization tooling and dashboarding are outside the Broker's scope?
VA Response: No.
69 FinOps Scope Boundary and QASP Savings Measures
Question: Will CDRL 002 be satisfied by providing data to a Government-operated dashboard, or must the Broker host and operate a separate dashboard deliverable?
VA Response: The Broker would be expected to feed data into the Government-owned centralized dashboard.
70 FinOps Scope Boundary and QASP Savings Measures
Question: Will the solicitation include a RACI, interface control document, or similar mechanism defining the boundaries between the Broker and existing VA FinOps capabilities?
VA Response: VA will take this recommendation into consideration for an upcoming solicitation.
71 Incumbent Support and Baseline Establishment
Question: Is any portion of the contemplated scope currently performed by an incumbent contractor or by VA staff?
VA Response: Forecasting is currently being conducted by VA Staff.
72 Incumbent Support and Baseline Establishment
Question: Objective O-1 requires a 40% reduction in cloud credit procurement cycle time from a baseline established during transition-in. Please provide the approximate current cycle time, if known, and clarify whether current-state data will be made available to offerors for proposal sizing.
VA Response: VA will be reviewing this requirement and may remove or amend it for the subsequent solicitation.
73 Incumbent Support and Baseline Establishment
Question: If an incumbent currently supports any portion of this scope, will VA provide for parallel operations during transition-in?
VA Response: Each existing CSP has differing contractual relationships which will impact transition. VA would only support credit availability during a transition.
74 Landing Zone Responsibility
Question: PWS Section 2.3.3.3 requires the Broker to deploy and maintain landing zones, and the Cloud Solutions Architect labor category references landing zone architecture and IaC framework design. Please clarify the intended landing zone scope.
VA Response: VA will assess this requirement for revision.
75 Landing Zone Responsibility
Question: For existing AWS and Azure environments, are landing zones already deployed and authorized, with the Broker expected to inherit and operate them, or is the Broker expected to rebuild them during transition-in?
VA Response: VA will assess this requirement for revision.
76 Landing Zone Responsibility
Question: For additional CSPs onboarded after award, will VA furnish target landing zone architectures and security baselines, or will the Broker be responsible for designing them?
VA Response: The Broker would be expected to collaborate with VA and the CSP for target landing zone architectures and security baselines.
77 Landing Zone Responsibility
Question: Is the Broker expected to develop new reference architectures, or adopt VA-furnished designs from IO Architecture and Security?
VA Response: The Broker would adopt VA-furnished designs from IO Architecture and
Security.
78 Day-2 Operations Boundary
Question: The Customer Journey definition in PWS Section 2.2 appears to exclude sustainment and operations management after deployment. However, the PWS also includes help desk support, P1-P4 incident-response SLAs, vulnerability management for 'brokerage-managed infrastructure,' and drift remediation responsibilities. Please clarify the intended operational boundary.
VA Response: VA will take this observation into consideration for an upcoming solicitation.
79 Day-2 Operations Boundary
Question: At what point does the Broker's provisioning responsibility end?
VA Response: See Question 31.
80 Day-2 Operations Boundary
Question: After provisioning, who owns patching, configuration maintenance, ongoing drift remediation, and day-2 operations: the Broker, the requesting VA program office, or another O&M contractor?
VA Response: Operations such as patching, configuration maintenance and ongoing drift remediation would fall under VA responsibility.
81 Day-2 Operations Boundary
Question: What does the Government consider 'brokerage-managed infrastructure' as distinct from program-owned workloads?
VA Response: VA would require Vulnerability management of their solution, but not VA-owned systems/applications.
82 ATO Scope and Authorization Strategy
Question: Please clarify the authorization strategy for the brokerage platform and managed cloud environments.
VA Response: All solutions that process, store, transmit, or interface with VA-sensitive data must comply with applicable federal and VA security requirements including FedRAMP, VA Handbook 6500, and all associated ATO processes.
83 ATO Scope and Authorization Strategy
Question: Will the brokerage platform require its own Authority to Operate separate from the existing VAEC ATO, or may it operate under an extension of the VAEC authorization?
VA Response: If not already authorized, the Broker platform would require an ATO.
84 ATO Scope and Authorization Strategy
Question: Are managed CSP environments expected to inherit the existing VAEC ATO, or will separate authorizations be required?
VA Response: Separate ATO’s would be required for all CSP’s.
85 ATO Scope and Authorization Strategy
Question: Is continuous ATO expected for the brokerage platform, managed CSP environments, or both?
VA Response: Continuous ATO is not expected for the CSP environments. Continuous ATO applicability for the brokerage platform would need to be determined.
86 ATO Scope and…
This is the start of the file's text. The full file is on GovTribe.
File details come from the government source that posted it. Updated .