Performance Work Statement (PWS) Draft Capacity aas a Service (CaaS).pdf

M00264-26-RFI-003

Draft Performance Work Statement – Capacity as a Service (CaaS)

1.0 Introduction

The Marine Corps Installations Command (MCICOM), G-6 Installation Systems Branch (ISB), seeks to acquire Capacity as a Service (CaaS) to support its Research, Development, Testing, and Evaluation (RDT&E) core infrastructure, laboratory environments, and data centers. CaaS is defined as an agile, on-demand, on-premise solution that delivers scalable computing, networking, and storage resources tailored to mission requirements across a variety of systems and applications.

2.0 Background

In alignment with the Data Center Optimization Initiative (DCOI), which mandates the reduction of data center footprints and the enhancement of Information Technology (IT) efficiency across Federal agencies, ISB is implementing a CaaS model to modernize its hosting capabilities. The DCOI emphasizes cost reduction, improved cybersecurity, adoption of best practices, and increased energy efficiency.

As a provider of IT solutions to the Department of Defense (DoD) and Department of the Navy (DoN), ISB requires a flexible and responsive infrastructure that supports dynamic project needs. The CaaS solution will enable ISB to rapidly provision infrastructure for new initiatives, scale resources to meet evolving demands, and decommission capacity when no longer required—thereby optimizing resource utilization and cost-effectiveness.

The selected CaaS solution must deliver timely, scalable, and cost-efficient computing, networking, and storage capabilities at Government-specified locations, ensuring operational readiness and mission alignment.

3.0 Scope

The Contractor shall furnish an on-premise Capacity as a Service (CaaS) by delivering and installing compute, networking, and storage hardware at designated Government facilities in support of ISB-managed networks and data centers. Refer to Section 8.0 – Contract Information for the list of supported locations.

Under this contract, the Government shall have the ability to request discrete, fit-for-purpose hardware capabilities from a catalog of vendor-provided offerings. Pricing shall be structured per hardware unit (e.g., per switch, server, or storage device). Upon order, the Contractor shall deliver, rack, and prepare the specified hardware for Government use. Operational control of the equipment shall transfer to the Government upon installation and acceptance.

The Government reserves the right to scale services up or down at any time by submitting new orders or deactivating existing ones. Billing terms and conditions are defined in Section 8.0 – Contract Information.

This requirement does not constitute a Cloud or Infrastructure as a Service (IaaS) contract. The Government retains full operational management of all delivered capacity. The Contractor shall be responsible for the procurement, delivery, installation, de-installation, and lifecycle maintenance of all hardware. Equipment shall be delivered as bare-metal systems, without pre-installed operating systems or virtualization layers. Embedded firmware or feature licenses necessary for hardware functionality may be included. All equipment must conform to the form, fit, and functional specifications outlined in the applicable Delivery Order (DO). Refer to Section 10.0 for Service Level Agreement (SLA) requirements.

4.0 Hardware and Software Interface Requirements

The Contractor shall furnish platform hardware (host/server systems) capable of supporting the Operating Systems (OS) specified in Table 4.0. While the OS itself is not a deliverable under this contract, all platforms must be fully compatible with the listed OS environments and associated interface protocols.

Table 4.0 – Platform Compatibility and Interface Requirements

Platform Type Supported Operating Systems Required

Interfaces

X86_64 CPU Windows Server, Red Hat Linux, SUSE Linux Enterprise Server, Solaris, VMware vSphere Enterprise Plus

FC, FCoE, 10/40 GbE

Itanium CPU HP-UX FC, FCoE, 10/40 GbE

SPARC CPU Solaris FC, FCoE, 10/40 GbE

IBM AIX AIX FC, FCoE, 10/40 GbE

NAS Must interface with all listed CPU platforms FC, FCoE, 10/40 GbE

SAN Must interface with all listed CPU platforms FC, FCoE, 10/40 GbE

Note: The Government reserves the right to request emerging or specialized capacity types not listed above (e.g., hardware accelerators, next-generation interconnects, disaggregated memory/storage architectures) as they become commercially viable and mission-relevant. Any such additions shall be proposed and approved via separate Delivery Orders (DOs).

5.0 Performance Requirements

The Contractor shall deliver modular, enterprise-grade capacity solutions to support Government data center operations. These solutions shall include compute, storage, and network hardware components, each provided as discrete, scalable units capable of seamless integration into existing Government-managed environments without service interruption.

All capacity types shall meet the following baseline performance criteria:

• Be physically delivered, racked, and made operational on Government premises

• Include enterprise-class features appropriate to their function (e.g., high availability, fault tolerance, virtualization support)

• Be modular and vendor-agnostic, enabling incremental scaling without requiring wholesale replacement

• Support non-disruptive configuration changes and capacity adjustments where feasible

• Integrate with existing physical and virtual infrastructure across compute, storage, and network domains

• Comply with applicable DoD standards for cybersecurity, data protection, and system interoperability

Detailed requirements for specific capacity types are outlined in Sections 5.1 through 5.7.

5.1 Enterprise Storage Capabilities

The Contractor shall provide high-availability, modular storage hardware solutions designed to meet mission-critical performance, scalability, and resiliency requirements. These solutions must be suitable for Tier I and Tier II data center environments supporting virtualization, application hosting, analytics workloads, and long-term data retention.

5.1.1 Required Capabilities:

• Multi-controller architecture with active-active data access paths

• RAID-based data protection, including support for advanced configurations (e.g., RAID 10, RAID 6, parity-optimized schemas)

• Logical storage pooling, thin provisioning, and non-disruptive scalability

• Replication features including synchronous, asynchronous, snapshot, and point-in-time copy support

• Automated data tiering based on performance and usage policies

• Compatibility with heterogeneous environments (Windows, Linux, VMware, UNIX)

• Support for Fibre Channel (FC), FCoE, and other standard SAN interconnects

• Data-at-rest encryption compliant with FIPS 140-2 or FIPS 140-3, validated through NIST’s Cryptographic

Module Validation Program (CMVP)

• Secure data sanitization in accordance with NIST SP 800-88 Rev. 1

• Support for logical units (LUNs), NVMe namespaces, or equivalent constructs ≥50TB, with total raw system capacity ≥6PB

• Optional support for read/write mirroring across geographically dispersed systems

• Data deduplication and compression features to optimize capacity and reduce replication overhead

• Support for shared multi-tenancy environments, where applicable

All systems shall be vendor-neutral, scalable, and interoperable with existing Government infrastructure.

Performance tiers (e.g., high-throughput/high-IOPS vs. high-capacity configurations) shall be available upon request to meet specific mission requirements.

5.2 Network Attached Storage (NAS) Capabilities

The Contractor shall provide modular NAS solutions designed to support high-performance file sharing, scalable unstructured data storage, and general-purpose data access across both virtualized and traditional server environments.

5.2.1 Required Capabilities:

• Support for NFS (v3 and v4.1) and CIFS/SMB protocols

• Verified compatibility with Windows, Linux, VMware, and UNIX clients

• Confirmed support for VMware vSphere datastores, including required locking and concurrency mechanisms

• Multi-VLAN support and tenant-level resource segregation

• Thin provisioning and non-disruptive capacity expansion

• RAID protection with node-level fault tolerance

• Snapshot, point-in-time replication, and asynchronous/synchronous copy features

• Secure deletion compliant with NIST SP 800-88 Rev. 1 or equivalent standards

• Data-at-rest encryption compliant with FIPS 140-2 or FIPS 140-3, validated by NIST’s CMVP

• Support for mid- to high-performance storage media, including SSD, SAS, and high-capacity SATA

• High-availability clustering support for NAS controllers

• Scalability to 50+ front-end ports supporting 10GbE or greater for NFS/SMB traffic

• Support for individual volume sizes ≥300TB

NAS solutions shall be modular, scalable, and suitable for a range of use cases including archival storage, VMware data stores, user file hosting, and backup target repositories.

5.3 SAN Switching and Fabric Capabilities

The Contractor shall provide enterprise-grade SAN switching solutions that are modular, scalable, and suitable for high-performance data center environments.

5.3.1 Required Capabilities:

• Director-class SAN chassis with redundant power supplies and support for multiple switching blades

• Hardware and/or OEM software enabling integration of four or more SAN directors into a unified managed fabric

• Switching blades with ≥48 ports, supporting speeds of 8 Gbps or greater (16 Gbps preferred)

• Fixed-port SAN switches with appropriate port densities and speeds for mid-scale deployments

• Management software for zoning, performance optimization, health monitoring, and fabric diagnostics

• Compatibility with Government-installed storage arrays and compute platforms

• Full support for VMware ESXi environments, including VMFS-backed shared storage over Fibre Channel

• Support for VMware multipathing configurations (e.g., Round Robin, Fixed, Most Recently Used), compliant with VMware’s Hardware Compatibility List (HCL) and best practices

5.4 General Hardware and Delivery Requirements

The Contractor shall deliver hardware-based capacity solutions—including compute, storage, and network components—that are fully integrated, scalable, and capable of installation and operation on Government premises without service disruption.

5.4.1 Physical Design and Redundancy Requirements:

• Rack-mounted or blade-based systems compatible with standard 19” data center racks

• Modular architecture allowing flexible ordering of individual components (e.g., switches, servers, blades)

• Redundant, hot-swappable power supplies and fans to minimize downtime due to hardware failure

• Support for multi-tenancy and logical resource separation where applicable

• Compatibility with standard interconnect protocols including Ethernet, Fibre Channel, and FCoE

5.4.2 Operational and Management Capabilities:

• Support for remote management interfaces (e.g., IPMI, iDRAC, iLO, or equivalent)

• Non-disruptive capacity changes and firmware updates, where supported and required

• High-availability ratings: enterprise-class systems targeting ≥99.999% uptime; all others ≥99.95%, exclusive of scheduled maintenance

• Secure out-of-band console access (e.g., Serial over IP, KVM-over-IP), with authentication controls and encrypted management traffic where applicable

• Optional intelligent power management features (e.g., monitored/switched PDUs) upon Government request

• Integration support for remote power control solutions for out-of-band operations

5.4.3 Cabling Standards and Documentation:

• All cabling shall be clearly labeled at both ends per industry best practices and Government naming conventions

• Labels must include destination port, equipment identifier, and circuit designation; they must be durable, legible, and resistant to environmental degradation

• Post-installation documentation shall include cabling diagrams and rack elevation summaries

• Cable routing shall follow professional data center standards to ensure airflow, accessibility, and maintainability

• Cables must be bundled, secured, and routed using appropriate cable management hardware; loose or obstructive cabling is noncompliant

• Rack doors must close and lock without obstruction

5.4.4 Installation and Physical Media Retention:

• Physical installation shall be performed by the Contractor; logical configuration shall be performed by the Government unless otherwise agreed in writing

• All storage media shall be handled in accordance with the requirements in Section 6.0 – Media Control.

5.4.5 Optional Environmental Monitoring Components:

At the Government’s request, the Contractor may provide environmental monitoring components (e.g., appliance servers for power management, cabinet telemetry systems) that directly support the operation, safety, or monitoring of ordered capacity.

5.4.6 Licensing and Subscription Scope:

• Hardware-based solutions may include feature licenses required for core functionality (e.g., HA clustering, secure boot, base encryption modules); these shall be included with the base offering

• No subscription-based software services (e.g., threat feeds, DPI engines, AI toolkits, software-defined storage platforms) shall be provided unless explicitly priced and ordered via Delivery Order (DO)

• The Contractor shall identify all included feature licenses and document activated functions upon delivery

• OEM support entitlements (e.g., firmware updates, diagnostics, security patches) are considered part of the hardware lifecycle and are not restricted by this clause.

5.4.7 Installation Scheduling and Decommissioning:

• Standard installation hours: 0600–1800 local time, Monday through Friday

• Off-hours or weekend installation shall be supported upon Government request

5.5 Compute Hardware Capabilities

The Contractor shall provide physical compute capacity across multiple performance tiers to support a broad range of workloads, from basic services to memory-intensive enterprise applications.

5.5.1 General Requirements:

• Compatibility with common virtualization platforms (e.g., VMware vSphere, Microsoft Hyper-V, KVM)

• Support for booting from local SSD or SAN-based storage

• All CPU cores presented to the operating system shall offer consistent instruction set support and performance characteristics suitable for virtualized and compute-intensive workloads

• Architectures utilizing heterogeneous core designs (e.g., performance vs. efficiency cores) may be evaluated for workload compatibility

5.5.2 Indicative Capacity Tiers (non-prescriptive):

Tier Configuration Entry Tier Dual-socket, multi-core CPU systems with 32–64GB RAM Standard Tier Dual-socket, multi-core CPU systems with 128–256GB RAM High Memory Tier Dual- or quad-socket systems with 512GB–1TB+ RAM

Tier Configuration

Specialty Tier Configurable systems with GPU acceleration, high core count, or optimized for AI/ML workloads

5.5.3 Specialty Tier Requirements:

• GPU-accelerated compute nodes compatible with CUDA (e.g., NVIDIA A100, H100, L40S, L4)

• High-speed interconnects such as PCIe Gen5, NVLink, or InfiniBand

• NVMe-based local storage for low-latency, high-throughput access

• Enhanced power and cooling configurations for high-density deployments

• Compatibility with Government-supplied AI/ML software stacks (e.g., PyTorch, TensorFlow)

All compute nodes shall support a minimum of three functionally segregated and redundant network paths (e.g., management, storage, public traffic), implemented via discrete NICs or bonded interfaces as appropriate.

5.6 Network Hardware Capabilities

The Contractor shall provide enterprise-grade and mid-tier networking hardware to support scalable, high-performance data center connectivity.

5.6.1 Required Capabilities:

• Modular and fixed-port switches supporting 10/25/40/100GbE as applicable

• Core and aggregation switches with high availability, stacking, or clustering support

• VLAN tagging, link aggregation, port mirroring, and Quality of Service (QoS) policy enforcement

• Compatibility with Government Layer 3 routing and segmentation practices

• Optional support for hardware-based encryption and deep packet inspection (if requested)

• Delivery of all required optics, transceivers, and cabling per physical design specifications

5.6.2 Advanced Networking and Security Components (as required):

• Fabric Extenders (FEX) for scalable top-of-rack port expansion under centralized control

• Next-Generation Firewalls (NGFW) with application-layer inspection, intrusion prevention, SSL/TLS decryption, and policy-based controls

• Network Access Control (NAC) appliances/modules supporting device posture assessment and integration with identity stores (e.g., Active Directory, LDAP)

• Application Gateways or virtual appliances for Layer 7 load balancing, reverse proxy, and traffic routing

• Web Application Firewalls (WAF) providing real-time HTTP/HTTPS inspection and OWASP Top 10 protections

• Application Delivery Controllers (ADCs), such as F5 BIG-IP or equivalent, supporting SSL offloading, health monitoring, and advanced traffic management

All devices shall be compatible with the Government’s network architecture and zoning models, and may be deployed inline or in service-chained configurations. Solutions shall include all required cabling, optics, rack components, and installation support. Software subscriptions shall be scoped separately unless explicitly ordered.

5.7 Interoperability and Integration Support

All Contractor-provided infrastructure shall be interoperable with existing Government platforms and environments.

5.7.1 Required Capabilities:

• Compatibility with current chipsets, operating systems, and virtualization stacks as defined in Table 4.0

• Dual-stack IPv4/IPv6 support in conformance with DISR standards and vendor documentation

• Hardware-based health monitoring and threshold alerting via local interfaces (e.g., IPMI, Redfish, SNMPv3)

• Installation of cloud-connected monitoring agents, OEM telemetry software, or remote diagnostic utilities that transmit data off-premises is strictly prohibited

The Contractor shall coordinate with Government personnel during onboarding to validate compatibility, perform integration testing, and provide connection specifications as required.

5.8 OEM Support Access and Escalation Paths

The Contractor shall maintain active Original Equipment Manufacturer (OEM) support contracts for all hardware and components delivered under this contract for the full duration of their operational lifecycle at Government facilities. OEM support shall include:

• 24x7 access to vendor technical assistance

• Access to firmware updates and security patches

• Eligibility for part replacement and Return Material Authorization (RMA) services

• Maximum response time of five (5) business days for part replacement and issue resolution

Accelerated support tiers (e.g., 4-hour or next-business-day RMA) are preferred for high-availability systems but are not mandatory unless specified in the applicable Delivery Order (DO).

All OEM support interactions—including technical assistance, case management, and access to diagnostic data— shall be restricted to U.S. citizens located within the United States, unless prior written authorization is granted by the Government. The Contractor shall ensure that all vendor-provided support services comply with DoD security requirements and do not involve foreign nationals accessing Government systems, data, or equipment serial numbers.

If the Government is not authorized or elects not to engage directly with the OEM (e.g., Cisco, NetApp, Dell), the Contractor shall act as the designated support liaison. Responsibilities include:

• Responding to Government-reported issues

• Initiating and managing OEM support cases on behalf of the Government

• Relaying technical guidance, updates, and replacement instructions in a timely manner

The Contractor shall ensure that any required authentication credentials, access tokens, or serial number registrations necessary to access vendor documentation, firmware repositories, or case management systems are either:

• Provided directly to ISB personnel, or

• Actively managed by the Contractor with full Government visibility into support status and updates

No delivered capacity shall lapse into an unsupported state without prior written notification to the Government and an opportunity to renew or replace affected components. If OEM support for a component is discontinued (e.g., end-of-life or end-of-service), the Contractor shall notify the Government in writing no less than ninety (90) calendar days in advance and propose a plan for replacement, upgrade, or risk mitigation. No Sub-Line Item Number (SLIN) shall remain billable while in an unsupported state without written Government concurrence.

5.9 Capacity Lifecycle: Acceptance, Deactivation, and Removal

This section defines the requirements and criteria for Government acceptance of delivered capacity, as well as the conditions and procedures for deactivation and removal. These definitions apply to all ordering and delivery timelines in Section 10.0 and are used in conjunction with the billing provisions in Section 8.0.

5.9.1 Acceptance

The Government shall perform acceptance of delivered capacity within five (5) business days of confirmation that the equipment is physically installed and ready for use. Billing terms associated with acceptance are defined in Section 8.0 – Contract Information.

5.9.2 Deactivation

Deactivation is defined as the termination of service for a specific SLIN, independent of physical equipment removal. Billing terms associated with deactivation are defined in Section 8.0 – Contract Information. Refer to Section 10.0 for applicable Service Level Agreement (SLA) details.

5.9.3 Equipment Removal

Upon deactivation, the Contractor shall coordinate with the Government to schedule physical removal of the associated hardware from ISB facilities. Removal shall occur within thirty (30) calendar days of deactivation unless otherwise directed in writing. Equipment may not be abandoned or left onsite without Government authorization.

The Government reserves the right to deny removal access if the Contractor fails to comply with required sanitization, labeling, or logistics coordination protocols. All removal activities shall be logged and documented for accountability and inspection purposes.

5.10 Equipment Movement

Movement is defined as the relocation of equipment within the same Government facility. This may be required due to:

• Data center reconfiguration

• Power or HVAC outages

• Infrastructure upgrades

• Phase transitions

• Hot/cold aisle reconfigurations

• Natural disaster response

The Contractor shall support intra-site equipment movement as directed by the Government, ensuring proper handling, reinstallation, and documentation.

5.11 Engineering and Technical Support Services

The Contractor shall provide Engineering and Technical Support Services on an as-needed basis to assist the Government in maintaining and optimizing its operational infrastructure. These services may include support for the delivery, installation, relocation, configuration, integration, and troubleshooting of hardware and related systems within the Government’s IT environment.

All Technical Support Services shall be performed under separately priced Contract Line Item Numbers (CLINs) and initiated only upon receipt of formal written authorization from the Contracting Officer (KO) or Contracting Officer’s Representative (COR). Each engagement shall be structured as a task-based, Firm Fixed Price (FFP) effort with a clearly defined scope of work.

5.11.1 Representative Technical Support Activities

Examples of authorized support activities include, but are not limited to:

• Hardware Relocation (Move): Deinstallation, transport, and reinstallation of Contractor-provided equipment within or between Government facilities, including power cycling and cabling adjustments.

• Hardware Reconfiguration: Modifications to rack layout, cable routing, or equipment placement to accommodate changes in facility infrastructure, electrical systems, or HVAC constraints.

• Installation Support: Execution of non-standard setup procedures such as RAID configuration, BIOS tuning, network uplink establishment, or integration into fabric or cluster environments.

• Integration Support: Assistance with onboarding delivered capacity into existing platforms, including virtualization environments, storage fabrics, or compute clusters.

• Troubleshooting Support: Hands-on technical assistance to identify, isolate, and resolve infrastructure-related faults or performance issues affecting supported capacity.

5.11.2 Software-Adjacent Infrastructure Support

Upon request by the Government, the Contractor may provide technical assistance for Government-owned platforms and applications (e.g., Citrix, Splunk, Windows Server, Linux, virtualization stacks) when such support is directly related to the integration, configuration, or operational readiness of infrastructure delivered under this contract. This may include:

• Resolving compatibility issues

• Performing initial configuration

• Assisting with capacity onboarding to ensure functional alignment within the broader IT environment

Support may also include diagnostic guidance or interoperability assistance for infrastructure-dependent software platforms. For example, integrating Citrix StoreFront with a Government-furnished F5 BIG-IP appliance in lieu of a NetScaler, provided such activity is necessary to activate or optimize ordered capacity.

The Contractor shall not assume ongoing operational responsibility for any application or platform. End-user support, software licensing management, and general-purpose system administration are explicitly excluded from the scope of Technical Support Services.

Preventive maintenance, software patching, release management, and long-term system administration are not authorized under this CLIN. No services shall commence without formal tasking, documented scope approval, and written authorization from the Contracting Officer (KO) or Contracting Officer Representative (COR). Informal, sales-driven, or verbally requested services shall not be initiated under this contract.

5.12 Meeting Requirements

The Contractor shall participate in recurring meetings with the Government to support contract execution, performance monitoring, and issue resolution. Required meetings include:

• Kickoff Meeting: Conducted shortly after contract award to establish scope, tasking procedures, and points of contact.

• Program Review Meetings: Held at least semi-annually, or more frequently upon request, to review delivery timelines, capacity utilization, SLA performance, risk factors, and future requirements.

• Ad Hoc Coordination: Additional meetings or teleconferences may be scheduled by either party to address emergent issues or tasking needs. All meetings shall be coordinated in advance and mutually agreed upon.

The Contractor shall ensure that appropriate technical and program personnel are available to participate in these meetings, as required by the agenda.

6.0 Security Requirements

The Contractor shall comply with all applicable Department of Defense (DoD), United States Marine Corps (USMC), and local site security policies governing physical access, information assurance, and the handling of media and equipment.

6.0.1 Media Control

All writeable storage media (e.g., hard drives, SSDs, flash memory, tapes) provided under this contract shall remain the property of the Government. No media shall be removed from Government facilities. Failed or decommissioned media shall be returned to the Government for secure destruction in accordance with DoD and ISB security protocols.

6.0.2 Prohibited Devices

In accordance with DoD CYBERCOM CTO 10-084, the use of USB flash/thumb drives is strictly prohibited. The Contractor shall ensure that such devices are not utilized in any operational processes.

6.0.3 Personnel Eligibility and Access

All Contractor personnel performing under this contract must:

• Be U.S. citizens

• Be escorted by authorized Government personnel while onsite, unless otherwise approved in writing

• Undergo identity verification and background screening appropriate to the facility’s security level

• Refrain from accessing Government systems, data, or storage media unless explicitly authorized

DISS registration or security clearance may be required for specific tasks involving classified environments or unescorted access, at the Government’s discretion.

6.0.4 Access Coordination

The Contractor shall coordinate all physical access to ISB-managed data centers with the designated site Point of Contact (POC) or Data Center Manager. Access shall be requested via Visit Authorization Requests (VARs) submitted through the Defense Information System for Security (DISS). Contractor personnel must comply with all entry/exit control procedures and wear appropriate identification while onsite.

6.0.5 Foreign Nationals

Foreign nationals are prohibited from accessing ISB facilities or information systems under this contract.

6.0.6 Security Training and Compliance

The Government shall provide initial and recurring security briefings. Contractor personnel must comply with all security protocols and may be removed from the facility or contract for violations.

6.0.7 Government Right of Removal

The Government reserves the right to request the immediate removal of any Contractor personnel whose conduct or performance is deemed inconsistent with mission requirements or the interests of the Government. Removal requests shall be documented by the COR and endorsed by the KO.

6.0.8 Classified Work and DD254 Requirements

Performance under this contract is not expected to involve classified information or systems by default. However, in the event that a specific task requires access to classified material, systems, or facilities, the Government will issue a DD254 (Department of Defense Contract Security Classification Specification) to define the applicable security requirements.

If a DD254 is issued, the following conditions shall apply:

• The Contractor shall maintain a Facility Clearance (FCL) at the classification level specified in the DD254 throughout the applicable performance period.

• All personnel requiring access to classified information shall possess the appropriate clearance level (e.g., Secret, Top Secret, TS/SCI) as identified in the DD254. Interim clearances may be accepted at the Government’s discretion.

• Visit Authorization Requests (VARs) shall be submitted through the Defense Information System for Security (DISS).

• The Contractor shall designate a Facility Security Officer (FSO) responsible for coordinating all security matters with the Government Security Representative.

• Classified material handling, if required, shall comply with DoDM 5200.01, including:

o Use of GSA-approved storage containers o Secure communication channels (e.g., SIPRNet) o Authorized destruction methods (e.g., burn bags, disintegrators, cross-cut shredding)

• Personnel shall comply with DoDM 5200.02 reporting requirements, including:

o Adverse information reporting o Foreign travel notification and approval o Changes in personnel status affecting clearance eligibility

No work involving classified systems, data, or materials shall begin unless a valid DD254 is in place and approved by the Contracting Officer (KO).

7.0 Transition Strategy

The Contractor shall support both the initial onboarding of services and the orderly transition of responsibilities at contract conclusion. All transition-related activities shall be documented and submitted in accordance with the Contract Data Requirements List (CDRLs) defined in Section 9.0, specifically:

• CDRL A003 – Onboarding Transition Strategy

• CDRL A004 – Offboarding Transition Strategy

7.0.1 Onboarding Transition Plan (CDRL A003)

Within fourteen (14) calendar days of contract award, the Contractor shall submit a comprehensive Onboarding Transition Strategy. This plan shall include:

• Projected delivery and installation timelines for the initial Delivery Order (DO)

• Sequenced steps for hardware capacity onboarding

• Site-specific coordination and access requirements

• OEM support activation procedures

• Designated points of contact for Contractor and Government coordination

The Government shall review and approve the plan prior to execution. No onboarding activities shall commence without written approval.

7.0.2 Offboarding and Contract Closeout Plan (CDRL A004)

No later than ninety (90) calendar days prior to the conclusion of the final period of performance, the Contractor shall submit a draft Offboarding Transition Strategy. The plan shall include:

• Inventory of all active SLINs and installed hardware

• Status of open support tasks and pending deactivations

• Decommissioning and equipment removal procedures

• Documentation turnover and badge return protocols

• Coordination timeline for final Government acceptance

The final version shall incorporate Government feedback and serve as the authoritative roadmap for service termination or transition to follow-on efforts. The Contractor shall maintain continuity of service through the end of the contract.

8.0 Contract Information

8.0.1 Contract Type and Pricing Model

Firm Fixed Price (FFP) unit pricing for each catalog item of hardware-based capacity, delivered under a Capacity as a Service (CaaS) model. Each item of compute, storage, or network capacity shall be represented as an independent Contract Line Item Number (CLIN).

For new capacity types or hardware models introduced post-award, the Contractor shall provide pricing justification based on commercial list pricing, GSA schedule rates, or other verifiable industry benchmarks. The Government reserves the right to request discount rationales and reject pricing that deviates materially from market norms.

8.0.2 CLIN Structure

• Each Contract Line Item Number (CLIN) represents a major category of deliverables (e.g., Compute Hardware, Storage Hardware, Network Hardware, Technical Support Services).

• Within each CLIN, individual deliverables shall be defined at the unit level for ordering, billing, and lifecycle tracking purposes.

• Each unit-level deliverable shall:

o Correspond to a discrete physical asset (e.g., server, storage shelf, network switch) that can be independently delivered, activated, and deactivated.

o Be uniquely identifiable and traceable from delivery through deactivation.

• Bundling, pooling, or partial billing of unit-level deliverables is prohibited unless specifically authorized in the applicable Delivery Order (DO).

• New capacity types or hardware models introduced after contract award shall require prior Government approval and pricing justification based on verifiable industry benchmarks (e.g., commercial list pricing, GSA schedule rates).

8.0.3 Ordering Process

The Contractor shall accept orders for hardware-based capacity only when issued via an authorized Government Delivery Order (DO) under this contract. Each Delivery Order (DO) will specify:

• Contract Line Item Number (CLIN) and Sub-Line Item Number (SLIN)

• Unit type and quantity

• Delivery location(s) as defined in Section 8.0.7

• Required delivery timeframe

• Any site-specific installation or access requirements

No work, procurement, or shipment shall begin without a valid, Government-issued DO. Informal requests, verbal agreements, or sales proposals do not constitute authorization to proceed.

8.0.4 Pricing Model

Pricing shall be per unit, tied to a CLIN, and invoiced only for capacity explicitly ordered, delivered to the designated performance location, and formally accepted for use by the Government. Bundled services, unrequested overprovisioning, or pooled resource billing are prohibited.

8.0.5 Billing Lifecycle

• Acceptance: Billing shall commence upon formal Government acceptance of the delivered unit.

• Deactivation: Billing shall cease within three (3) business days of a Government-issued deactivation notice, regardless of when the unit is physically removed.

• No charges shall apply to unused or excess capacity beyond what was requested and accepted.

• All invoices shall reflect only the units and dates confirmed by the Government.

8.0.6 Invoice Requirements

• The Contractor shall operate on a standard monthly billing cycle, accommodating months of 28, 29, 30, or 31 days.

• Invoices shall be generated from contract order data maintained by the Government and shall include:

o CLIN and unit-level deliverable identification.

o Acceptance Date for each billed unit.

o Deactivation Date for any unit deactivated during the billing period.

• Draft invoices shall be submitted to the Government for review and approval prior to final submission and Payment processing.

• No invoice shall be considered valid without Government approval of the associated unit activity and billing details.

8.0.7 Funding and Ownership

This contract is funded under Operations and Maintenance (O&M) appropriations. The Government shall not take ownership of any hardware acquired under this contract. All equipment remains the property of the Contractor and is provided as an operational capability for the duration of its use.

8.0.8 Performance Locations

Hardware shall be delivered, installed, and made operational at the following Government facilities:

Location SMO Code Marine Corps Information Technology Center (MCITC), Kansas City, MO 660015

Location SMO Code Newlin Hall, Marine Corps Base Quantico, VA 652366

8.0.9 Government Coordination and Oversight

A designated Contracting Officer’s Representative (COR) shall serve as the primary point of contact for order validation, capacity tracking, and coordination of acceptance and deactivation activities. The Contractor shall coordinate all site access, installation schedules, and issue resolution through the COR.

8.0.10 Contract Modifications and Extension Clause

This contract may be modified by mutual agreement to accommodate emerging capacity requirements, including new hardware types or advanced compute capabilities (e.g., AI accelerators, edge devices). The Government reserves the right to exercise option periods or issue a follow-on contract to extend or evolve service delivery based on operational needs and Contractor performance.

8.0.11 Period of Performance

The contract shall consist of:

• One (1) year Base Period

• Four (4) one-year Option Periods

9.0 Deliverables

CDRL # Deliverable Frequency Reference A001 Monthly Capacity Order & Status Report Monthly PWS 10.3 A002 SLA Compliance Summary Quarterly PWS 10.3 A003 Onboarding Transition Strategy Within 2 weeks of award PWS 7.0.1 A004 Offboarding Transition Strategy 90 days before contract end PWS 7.0.2 A005 Ordering Process Description Within 2 weeks of award PWS 8.0.3 A006 Ad-hoc Reports (as requested by ISB) As Required PWS 10.3

10.0 Service Level Agreement (SLA)

These SLAs apply exclusively to Contractor-controlled tasks related to hardware delivery and lifecycle management. They do not extend to network uptime, system performance, or application availability, which are managed by the Government post-acceptance.

10.0.1 Ordering and Delivery Timelines

Ordering procedures are defined in Section 8.0.3; this section defines associated delivery timelines.

• New Hardware Orders: Delivered, racked, powered, and confirmed “ready for use” within forty (40) business days of Government order acceptance, unless otherwise negotiated. Contractor shall proactively notify the Government of any anticipated delays.

• Add-On Capacity (e.g., drives, memory, NICs): Delivered and installed within twenty (20) business days, subject to availability.

• Order Validation: Contractor shall confirm order accuracy and availability within three (3) business days of receipt

10.0.2 Incident Response (Delivery and Installation Phase)

• Acknowledgment of Delivery Issues: Within one (1) business day of Government notification.

• Corrective Action Implementation: Within three (3) business days of acknowledgment.

• Hardware Replacement (Defective on Arrival): Replacement parts shipped within five (5) business days of Contractor confirmation following Government notification.

10.0.3 In-Service Hardware Failure Response (Post-Acceptance)

Upon notification of a hardware fault (e.g., CPU, NIC, SSD, PSU, motherboard), the Contractor shall:

• Acknowledge the issue within one (1) business day

• Initiate diagnostic coordination with the Government and OEM

• Provide timely updates and corrective actions to restore service

10.1 OEM Validation, Replacement Coordination, and Degraded Capacity Management

10.1.1 OEM Validation and Liaison Responsibilities

OEM liaison responsibilities are defined in Section 5.8.

10.1.2 Replacement Delivery and Installation

Upon OEM approval of a hardware replacement, the Contractor shall ensure delivery and installation of the replacement component within five (5) business days, or as otherwise dictated by OEM part availability. The Contractor shall coordinate all on-site replacement activities with the Government and confirm that the affected system is restored to “Ready for Use” status.

10.1.3 Billing Suspension for Inoperable Capacity

If a SLIN is rendered inoperable and cannot perform its intended function, the Government may request suspension of billing for the affected SLIN until full functionality is restored. The Contractor shall not be penalized for delays attributable to documented OEM investigation timelines but is expected to pursue resolution with reasonable urgency.

10.1.4 Lifecycle Refresh and End-of-Support Mitigation

The Government reserves the right to require refresh or replacement of any SLIN that:

• Has exceeded five (5) years in service, or

• Is no longer supported by the OEM

If the Contractor cannot propose a replacement or mitigation strategy acceptable to the Government, the SLIN may be deactivated and removed from billing.

10.1.5 Degraded Capacity Exception

The Government may declare a SLIN non-functional if hardware degradation materially impacts usability, even if the component remains technically operational. Examples include:

• Persistent failover behavior

• Performance throttling

• Unrecoverable fault conditions affecting availability or predictability

Upon notification and verification, the Contractor shall coordinate remediation or replacement. Billing may be suspended for the affected SLIN until performance is restored to acceptable levels.

10.2 Force Majeure and Catastrophic Events

In the event of a catastrophic incident affecting one or more performance locations (e.g., natural disaster, fire, flood, terrorism, or other force majeure event), the Government may suspend billing for impacted capacity effective the date of the incident. The Contractor shall:

• Notify the Government within five (5) business days of the event

• Make reasonable efforts to resume service or coordinate recovery actions

Resumption of service, equipment replacement, or related recovery efforts shall be addressed via modified Delivery Orders (DOs) or separate tasking, as appropriate. The Contractor shall not be held liable for SLA violations or delivery delays directly resulting from such events, provided timely notification and good-faith recovery efforts are demonstrated.

10.3 SLA Monitoring and Compliance

Service Level Agreement (SLA) compliance shall be monitored through the following deliverables:

• CDRL A001 – Monthly Capacity Order & Status Report

• CDRL A002 – SLA Compliance Summary Report

Repeated or unresolved SLA violations may result in formal notice from the Contracting Officer’s Representative (COR) and may impact:

• Future Delivery Orders (DOs)

• Contract extension decisions

• Performance evaluations

If the Contractor incurs three (3) or more unresolved SLA violations within a six-month period, the Government may impose additional oversight requirements, suspend future tasking, or decline to exercise option periods.

11.0 Other Pertinent Information and Special Considerations

11.0.1 Facility Support

The Government shall provide the necessary facility infrastructure to support Contractor-provided hardware, including:

• Floor space

• Power and HVAC

• Uninterruptible Power Supply (UPS) connectivity

The Contractor shall coordinate all physical installation requirements—including power draw, rack layout, cabling routes, and environmental dependencies—with the COR prior to delivery. The Government shall not be responsible for providing specialized or proprietary infrastructure components beyond standard commercial-grade facility support.

All hardware installations must conform to applicable Government safety, cabling, and floor load guidelines.

12.0 Hours of Operation

12.0.1 Normal Business Hours

• 0600 to 1800 (local time), Monday through Friday, excluding Federal holidays.

12.0.2 After-Hours Support

All other times, including weekends and Federal holidays, are considered After Hours. Contractor activities such as deliveries, installations, or coordination that must occur outside of Normal Business Hours shall be scheduled in advance and approved by the COR and designated site Point of Contact (POC). The Government will make reasonable accommodations for After-Hours support when necessary to minimize operational disruption, but all such activities require prior written authorization.

13.0 Contractor Quality Control Plan (QCP)

Within thirty (30) calendar days of contract award, the Contractor shall submit a Quality Control Plan (QCP) outlining internal procedures for ensuring compliance with all contract requirements. The QCP shall include:

• Methods for monitoring service delivery and SLA adherence

• Procedures for identifying and correcting deficiencies

• Roles and responsibilities of Contractor personnel involved in quality assurance

• Communication protocols for reporting issues to the Government

• Documentation and recordkeeping practices

The QCP shall be reviewed and approved by the COR and updated annually or upon request.

14.0 Risk Management and Mitigation

The Contractor shall identify potential risks to service continuity and propose mitigation strategies. Risk categories may include:

• Supply chain delays or part shortages

• OEM support discontinuation

• Facility access restrictions

• Environmental or infrastructure constraints

The Contractor shall maintain a risk register and provide updates during Program Review Meetings. High-impact risks shall be escalated to the COR with proposed contingency plans.

15.0 Data Rights and Intellectual Property

All documentation, configuration data, diagnostic reports, and support records generated under this contract shall be made available to the Government upon request. The Government shall retain unlimited rights to:

• SLIN configuration and performance data

• OEM case records and support transcripts

• Installation and integration documentation

The Contractor shall not restrict access to any operational data necessary for sustainment, transition, or audit purposes.

16.0 Environmental and Safety Compliance

The Contractor shall comply with all applicable federal, state, and local environmental regulations, as well as Occupational Safety and Health Administration (OSHA) standards. This includes:

• Safe handling and disposal of electronic components

• Compliance with facility-specific cabling and floor load requirements

• Use of appropriate personal protective equipment (PPE) during installation and removal activities

Any safety incidents shall be reported to the COR within one (1) business day.

17.0 Training and Knowledge Transfer

Upon request, the Contractor shall provide technical documentation or informal training sessions to Government personnel to support:

• SLIN onboarding and configuration

• OEM support procedures

• Diagnostic and troubleshooting workflows

Training shall be scoped and priced as a separate Technical Support Services task and must be approved by the KO or COR prior to execution.

Appendix A – Technical Reference Materials (Optional)

This appendix may include:

• Rack layout templates

• Cabling standards and labeling conventions

• SLIN configuration examples

• OEM support activation workflows

• Sample diagnostic logs or ticket formats

These materials shall be provided by the Contractor upon request and updated as needed to reflect current practices.

Appendix B – Definitions and Acronyms

Term Definition

CLIN Contract Line Item Number – a major category of deliverables (e.g., Compute Hardware, Storage Hardware).

Term Definition SLIN Sub-Line Item Number – an individual, measurable unit of capacity or hardware within a CLIN.

CaaS Capacity as a Service – a delivery model in which hardware is provided as an operational capability, not as Government-owned property.

COR Contracting Officer’s Representative – the designated Government official responsible for technical oversight.

KO Contracting Officer – the official with authority to bind the Government contractually.

CDRL Contract Data Requirements List – a formal list of deliverables required under the contract.

OEM Original Equipment Manufacturer – the vendor responsible for hardware support and warranty services.

VAR Visit Authorization Request – a formal request for facility access submitted via DISS.

DISS Defense Information System for Security – the system used to manage personnel security and access.