Draft_PWS.docx

PERFORMANCE WORK STATEMENT (PWS)

Payment Processing System Requirements 2032L226N00005

1. BACKGROUND

Federal agencies increasingly require the ability to securely collect, process, and manage payments in a manner that aligns with modern digital service expectations, evolving public user needs, and federal compliance requirements. Payment interactions are a critical component of public service delivery and must support a wide range of use cases, including one-time transactions, recurring payments, refunds, and financial reconciliation.

The Government seeks a payment processing capability that enables seamless integration into Government-managed digital experiences while maintaining strong security, privacy, and financial controls. This includes the ability to support both current and emerging payment methods, provide real-time visibility into transaction activity, and ensure accurate and auditable financial operations.

In addition, federal systems must operate within a complex regulatory environment requiring adherence to standards for cybersecurity, accessibility, privacy, and financial management. As such, the Government requires a solution that not only meets current compliance obligations but is adaptable to evolving federal policies, security requirements, and technology advancements.

This requirement is intended to provide a flexible, scalable, and secure payment processing capability that supports mission delivery today while remaining adaptable to future needs, minimizing rework and avoiding Contractor or technology lock-in.

2. PURPOSE AND SCOPE

This document specifies outcome-focused requirements for a secure, hosted payment processing solution supporting embedded checkout, server-side payment flows, refunds, vaulting, reconciliation, reporting, and administrative management. It balances measurable outcomes (performance, security, accessibility, continuity) with baseline controls required for federal operations. The intent is to describe the results the Government needs rather than prescribe a single technical implementation approach.

3. OUTCOMES AND ACCEPTABLE CONTROLS MODEL

The Government requires the Contractor to achieve the outcomes described in this document. The Contractor’s technical approaches shall meet those outcomes while meeting the identified baseline controls and measurable acceptance criteria. Baseline controls (e.g., PCI DSS, Section 508, incident notification timelines) are identified where regulatory or legal obligations exist and are not negotiable.

Other conditions that apply to this requirement are: Government retains authority over financial reporting and reconciliation; solution must integrate with existing federal financial management processes; and Treasury and federal financial regulations apply.

4. TASKS

4.1 Embedded Checkout - Outcome: Users must be able to complete payments within the Government User Interface (UI) with an experience that is secure, accessible, and integrated within the UI without requiring redirection to Contractor-hosted pages.

Acceptance Criteria:

· Users can complete payment flows in the Government UI with no material accessibility barriers (keyboard navigation, screen reader compatibility, and WCAG 2.1 AA conformance for payment flows).

· Checkout appearance can match Government branding to a degree that does not impair usability.

· Payment fields validate user input and surface actionable errors.

· Supported payment methods (card networks and major digital wallets) are available to users where browser/device capabilities allow.

Supplemental Clarification:

· The embedded checkout shall support fine-grained control over the styling of individual payment form elements, subject to provider and payment-network security constraints.

· Apple Pay and Google Pay shall be supported where device and browser capabilities allow.

Baseline Controls:

Section 508/WCAG 2.1 AA conformance required (VPAT provided).

Secure collection of payment data (PCI scope minimized through tokenization or equivalent).

Payment data must be transmitted using encrypted connections (TLS 1.2+).

Payment experience must be consistent with public trust expectations, including clear identification of the Government and secure handling of user interactions.

No third-party branding or messaging.

4.2 Payment Intent Lifecycle - Outcome: The Government can reliably initiate, modify, confirm, and reconcile payment requests via secure server-side flows with clear event-state semantics.

Acceptance Criteria:

· Server-side initiation and lifecycle transitions are observable, auditable, and recoverable.

· Idempotent handling prevents duplicate charges during retries.

· Metadata and line-item detail are preserved for invoicing and reconciliation.

· APIs must use industry-standard, non-proprietary protocols (e.g., REST, JSON, OAuth2 or equivalent).

Supplemental Clarification:

· The solution shall support creation of a server-side payment object, payment intent, or equivalent resource with amount, currency, metadata, and line-item detail.

· The solution shall return a frontend confirmation secret, token, or equivalent value when client-side confirmation is required.

· The Government shall be able to update a payment object before confirmation, including metadata and save-card preferences.

· The Government shall be able to confirm a payment using a previously saved payment method, subject to any required regulatory step-up authentication.

· The Government shall be able to cancel a payment that has not been committed or completed.

· The solution shall provide an observable lifecycle model comparable to: requires confirmation, requires action, processing, succeeded, failed, and canceled, or an equivalent documented state model.

Baseline Controls:

Data formats must be fully documented and not restricted to proprietary schemas.

The solution must not require the use of Contractor-specific tools to access or interpret Government data.

APIs must support idempotency for state-changing operations.

Sensitive PAN data must not be stored in cleartext; tokenization or equivalent required.

APIs must support integration with external financial systems (e.g., ERP, general ledger systems).

· All API interactions must be authenticated and authorized using secure mechanisms (e.g., OAuth2 or equivalent).

· All APIs are versioned and maintained with backward compatibility or defined deprecation timelines.

4.2A Supported Payment Methods and Statement Descriptor - Supplemental Addition: The solution shall explicitly support Visa, Mastercard, American Express, and Discover, and shall support a custom statement descriptor or equivalent payer-statement configuration subject to network and processor rules. The offeror shall identify any relevant length, character, or processing constraints.

4.3 Refunds Reconciliation & Financial Integrity - Outcome: The Government can process refunds and maintain complete financial traceability across the transaction lifecycle.

Acceptance Criteria:

· Refunds (full and partial) are:

· Idempotent

· Traceable to original transactions

· Reflected in settlement and reconciliation reports

· Reconciliation artifacts include:

· Transaction-level exports

· Refund linkage

· Fee breakdowns

· System supports:

· Daily reconciliation workflows

· Detection of mismatches between authorized, captured, and settled amounts Supplemental Clarification:

· Multiple partial refunds against the same original transaction shall be supported.

· The provider shall prevent cumulative refunds from exceeding the original captured amount.

Baseline Controls:

· Idempotency for refund endpoints.

· Immutable transaction records with audit traceability.

· Financial records must be consistent and non-repudiable across transaction lifecycle.

4.4 Saved Payment Methods - Outcome: Returning customers can reuse stored payment credentials without repeatedly entering full Primary Account Number (PAN) data, while the Government retains control over opt-in and consent.

Acceptance Criteria:

· Users can save and select payment methods; masked attributes remain visible for admin and user clarity.

· Vaulted credentials enable server-side confirmations where regulatory flows allow.

Supplemental Clarification:

· Customers shall be able to save a payment method during checkout through an explicit opt-in mechanism.

· The solution shall support a setup flow that vaults a card without charging it.

· Stored payment method attributes available to the Government and customer shall include last four digits, brand, expiration month and year, and a fingerprint or equivalent deduplication identifier.

· The Government shall be able to retrieve all saved payment methods associated with a customer, set a default saved payment method, and delete or detach a saved payment method.

· Server-side confirmation with a saved card should not require additional frontend interaction except where step-up authentication or similar regulatory controls apply.

Baseline Controls:

· Vaulting must use secure tokenization; provider must document token mapping and safeguards.

· Stored credentials must comply with PCI DSS requirements for cardholder data storage.

· Strong customer authentication must be supported where required (e.g., regulatory flows).

4.5 Webhooks and Notifications — Outcome: Asynchronous events are delivered reliably to Government endpoints and allow the Government to maintain an authoritative state for payments, refunds, and disputes.

Acceptance Criteria:

· Events required for operational workflows (payments, refunds, disputes, chargebacks) are delivered with documented retry mechanics and verifiable signatures.

· Missed events can be recovered via APIs and are reconciled in daily reports.

Supplemental Clarification:

· The required event set shall include payment succeeded, payment failed, refund completed, refund failed, payment method added, and payment method removed.

· Webhook delivery logs shall be available for operational troubleshooting and audit.

Baseline Controls:

HMAC signing or equivalent for webhook integrity.

Documented webhook retry policy and dead-letter handling.

4.5A Reconciliation and Recovery - Supplemental Addition: The Government shall be able to retrieve a payment object, payment intent, or equivalent resource by ID to determine status, requested amount, and received amount; retrieve or list all refunds associated with a given payment; and retrieve checkout session details, or an equivalent resource, including checkout status, payment status, and linked payment identifier, to support manual recovery when webhook delivery fails.

4.6 Settlement & Funds Disbursement - Outcome: The Government receives funds from processed transactions in a predictable, transparent, and auditable manner aligned with defined settlement schedules.

Acceptance Criteria:

· Settlement timing (e.g., T+1, T+2) is defined, consistent, and reportable

· Payout reports clearly distinguish:

· Gross transaction amounts.

· Fees (interchange, assessments, processor fees).

· Net disbursed amounts.

· Failed or delayed settlements are:

· Detectable via reporting or API.

· Accompanied by reason codes and remediation guidance.

· The Government can reconcile payouts to underlying transactions without manual reconstruction.

Baseline Controls:

· Daily settlement reporting (API or export).

· Traceability from individual transaction → batch → payout.

· Settlement processes must ensure financial integrity and reconciliation consistency across all transactions.

· The Contractor must clearly define its role in funds handling, including whether it operates as a payment processor, fiscal agent, or intermediary.

· Funds must be handled in compliance with Treasury requirements and applicable federal financial management regulations.

· The solution must support clear segregation of Government funds and prevent commingling where prohibited.

4.7 Disputes & Chargeback Management - Outcome: The Government can effectively manage disputes and chargebacks in compliance with card network rules and minimize financial loss.

Acceptance Criteria:

· The system provides:

· Notification of disputes and chargebacks.

· Dispute status tracking and lifecycle visibility.

· The Government can:

· Submit evidence through API or dashboard.

· Track outcomes (won/lost).

· Dispute data is included in reporting and reconciliation.

Baseline Controls:

· Timely notification of disputes (near real-time or batch within defined SLA).

· Retention of dispute records per card network requirements.

· Dispute handling must comply with card network rules and regulatory requirements.

4.8 Administrative & Reporting Outcomes - Government administrators can search, audit, act upon transactions, and obtain reconciliation data necessary for financial controls.

Acceptance Criteria:

Transaction search/filter within dashboard and via API.

Exportable settlement and reconciliation reports (CSV/API).

Audit logs for admin actions with retention per Government policy.

Government can place data under legal hold without Contractor intervention.

Audit logs can be exported in bulk for audit, investigation, or legal review.

Baseline Controls:

Role-based access controls for administrative functions.

Immutable, tamper-evident audit logs with defined retention (e.g., 7 years unless Government specifies otherwise).

Audit logs must support legal hold requirements, preventing alteration or deletion when preservation is required.

Audit data must be exportable in standard formats to support eDiscovery.

Audit logs and transaction records must be retained in accordance with federal records management requirements.

4.9 Financial Reporting & Fee Transparency — Outcome: The Government can fully understand and validate all financial movements, including fees, settlements, and adjustments.

Acceptance Criteria:

· Reports provide:

· Itemized fee breakdowns.

· Gross vs. net settlement views.

· Adjustments and corrections.

· Data is exportable in machine-readable formats (CSV/API).

· Reporting supports audit and financial review without Contractor dependency.

Baseline Controls:

· No opaque or bundled fee reporting.

· Consistent reconciliation identifiers across all reports.

4.10 Security & Compliance – Outcomes: Government data and transaction processing are protected to federal standards; the Contractor demonstrates ongoing control maturity.

Acceptance Criteria:

· Evidence of compliance (PCI AOC, SOC 2 Type II) provided and current.

Offerors shall identify whether current PCI AOC and SOC 2 Type II reports cover the specific hosted services and service components proposed for Treasury, including any carve-outs, bridge periods, or material exclusions.

· Documented vulnerability management and incident response processes.

· The solution aligns with Zero Trust Architecture principles, including identity-centric access, least privilege enforcement, and continuous validation of access.

· Contractor must notify the Government of any material changes to security posture, compliance status, or control environment.

Baseline Controls:

PCI DSS Level 1 Attestation of Compliance (AOC).

Cryptographic protection and key management practices that prevent unauthorized disclosure.

Incident notification as specified in Attachment A.

Encryption of data in transit and at rest to federal-accepted standards.

System must be authorized at FedRAMP Moderate or higher, or demonstrate ability to achieve authorization within a Government-approved timeline.

Solution must support FISMA compliance and align with NIST SP 800-53 controls.

Provider must define and document a shared responsibility model for all applicable security controls.

Access controls must enforce least privilege and continuous authentication/authorization validation.

Identity federation and authentication must support federal identity standards (SAML/OIDC).

Multi-factor authentication required for all privileged access.

Support for federated identity (SAML 2.0, OIDC, or equivalent), including compatibility with federal identity providers (e.g., Login.gov or Government IdP).

Multi-factor authentication (MFA) required for privileged and administrative access.

Support for PIV/CAC authentication where applicable.

The system must support immediate revocation of user and system access upon Government request.

Access changes must propagate across all components without undue delay.

4.11. Accessibility – Outcomes: All public-facing payment flows meet accessibility requirements and do not create barriers for users with disabilities.

Acceptance Criteria:

· VPAT demonstrating WCAG 2.1 AA (or equivalent) for payment flows.

· Accessibility testing evidence (manual + automated) in UAT.

Baseline Controls:

· All public-facing interfaces must comply with Section 508/WCAG 2.1 AA.

· Accessibility must not be degraded by any supported payment method.

4.12 Operational & Service - Outcomes: The payment service operates with high availability, predictable performance, and responsive support to minimize mission impact.

Acceptance Criteria:

· Documented uptime metrics and historical performance data supporting the Contractor’s availability claims.

· Defined response and mitigation commitments for incidents by severity.

· Monthly operational reporting including SLA performance and incident RCA.

· Performance expectations apply consistently across all supported payment methods, including mobile and alternative payment options.

· The system must support burst traffic and high-volume events (e.g., filing deadlines, public campaigns) without material degradation in performance.

Supplemental Clarification:

· Offerors shall provide representative current production annual transaction volume, peak sustained transaction levels, customers of similar size or regulatory complexity, and historical availability metrics for the prior 12 months.

· Offerors shall describe current incident response, customer support, disaster recovery, and business continuity capabilities relevant to Treasury-scale payment operations.

· Contractor provides evidence of load testing and scaling behavior under peak conditions.

Baseline Controls:

· System must meet defined availability and performance SLAs.

· Contractor must provide incident response and support capabilities aligned with SLA commitments.

The following targets represent desired performance objectives. Service Level Agreements (SLAs) in Section 6 define the minimum enforceable thresholds and associated remedies.

Targets:

· Target availability objective: 99.99% annual uptime (Contractor may propose equivalent measures).

· Performance objective: median authorization latency ≤ 500 ms; 95th percentile ≤ 2 seconds under defined test conditions.

Treasury's desired availability objective for Contractor-controlled payment APIs and embedded checkout components is 99.999 percent annual uptime, and offerors shall clearly identify any gap between this objective and their current commercial commitments.

Payments should normally complete within 1 to 2 seconds under defined operating conditions, and offerors shall distinguish Contractor-controlled latency from latency attributable to issuers, payment networks, customer devices, or general Internet conditions outside the Contractor's control.

Performance objectives must be maintained under defined peak load conditions.

4.13 Observability & Operational Transparency - Outcome: The Government has sufficient visibility into system behavior to monitor performance, diagnose issues, and validate SLA compliance.

Acceptance Criteria:

· Access to:

· Real-time dashboards or metrics.

· Transaction-level logs.

· Webhook delivery logs.

· Ability to:

· Trace individual transactions across lifecycle stages.

· Diagnose failures without Contractor intervention.

· The Government must have direct, self-service access to reporting and dashboards without Contractor intervention.

Baseline Controls:

· Log retention aligned with audit and records preservation requirements, including support for legal hold scenarios.

· Unique identifiers for traceability across systems.

4.14. Business Continuity & Recovery Outcomes: The Contractor maintains resilience sufficiently to prevent material disruption and to recover within acceptable timeframes.

Acceptance Criteria:

· Documented RTO and RPO and test evidence (annual DR test results).

· Cross-AZ or cross-region resilience appropriate to the proposed architecture.

· Encrypted backups and restore verification.

· Payment retry and idempotency mechanisms prevent duplicate charges during transient failures.

· Graceful degradation is defined for partial outages (e.g., wallet unavailable but cards functional).

· Regional failover is documented where applicable.

Baseline Controls:

· Provide DR plan and latest DR test report.

· RTO and RPO commitments (Contractor proposes values consistent with outcome).

· System must support high availability and failover mechanisms.

· Backups must be encrypted and regularly tested.

4.15 Privacy & Data Governance - Outcomes: Government data is used only to provide contracted services, remains under Government ownership, and is protected per federal privacy requirements.

Acceptance Criteria:

· Data residency statements and sub processors are disclosed, including their roles and locations.

· Contractor must provide advance notification (e.g., 30–60 days) of any new or changed sub processors.

· Sub processors must be contractually bound to equivalent security, privacy, and compliance obligations (including FedRAMP where applicable).

· Government must have the ability to review and object to new sub processors where mission or compliance risk is introduced.

· Data export and certified deletion processes defined.

· Support for data subject requests where applicable.

· Token portability is supported where feasible (ability to migrate stored payment methods).

· Full transaction history export available upon request without proprietary constraints.

Baseline Controls:

· All sub processors must meet equivalent federal security and privacy requirements, and responsibility for compliance remains with the primary contractor.

· Handling of FIPS 199 impact levels.

· Data tagging/classification.

· CUI handling (where applicable).

· Data must be retained and deleted in accordance with Government-defined retention schedules.

· Contractor must provide certified data destruction upon request or contract termination.

· Data must not be retained beyond authorized periods.

· Government data must be stored and processed within approved geographic regions (e.g., United States or Government-defined locations).

· Any cross-border data transfer must be explicitly authorized by the Government.

4.16 Fraud & Risk Management - Outcomes: The Contractor provides tools and controls enabling the Government to detect, prevent, and manage fraudulent activity while preserving legitimate transactions.

Acceptance Criteria:

· Support for AVS, CVV checks, and 3D Secure flows where appropriate.

· Configurable velocity rules and risk scoring.

· Dispute handling workflow and evidence submission capability.

· Real-time or near real-time fraud scoring.

· Ability to configure rules (velocity, geolocation, device fingerprinting where applicable).

· Support for step-up authentication (e.g., 3DS) based on risk signals.

Baseline Controls:

· Fraud detection mechanisms must be implemented to prevent unauthorized transactions.

· Risk controls must not degrade legitimate transaction processing.

4.17 Implementation & Transition – Outcomes: The Contractor delivers a practical implementation plan that minimizes Government effort and risk during onboarding and provides orderly transition at contract end.

Acceptance Criteria:

· Sandbox available in <10 business days after contract signing (or Contractor-proposed equivalent).

· Clear project plan with milestones, roles, and testing gates.

· 90-day transition assistance and data export in machine-readable formats upon termination.

· Backward-compatible API versioning or defined deprecation policy.

· Migration support for:

· Historical transaction data.

· Stored payment credentials (where permitted).

· API and system changes are backward compatible, or Contractor provides clear versioning and deprecation schedules.

· The solution supports incremental enhancement without requiring full system reimplementation.

· Contractor must support integration with existing Government financial and reporting systems without requiring significant customization.

· The solution must support the addition of new features, services, or payment capabilities during the contract lifecycle without requiring re-architecture or replacement of the core system.

Baseline Controls:

· Contractor must support data portability and transition without proprietary restrictions.

· Contractor must provide transition assistance at contract end.

· The solution supports integration with third-party systems without restriction or additional licensing barriers.

· The Government can extract all data in non-proprietary, machine-readable formats without Contractor dependency.

· The contractor must provide complete data export in a structured, non-proprietary format within a defined timeframe (e.g., ≤ 30 days) upon request or contract termination

· The contractor must ensure continuity of operations during transition to a successor provider

4.18 Modern & Accessible Payment Methods — Outcome: The Government provides payment experiences that align with modern consumer expectations by supporting commonly used, streamlined, and mobile-accessible payment methods, while ensuring full compliance with federal accessibility and security requirements.

Acceptance Criteria:

· The solution supports payment methods commonly used by the public, including mobile device-based payment options (e.g., digital wallets or equivalent technologies), where applicable.

· Payment experiences are optimized for use on mobile devices, including responsive design and compatibility with common mobile browsers and operating systems.

· The Contractor demonstrates the ability to incorporate new or emerging payment methods over time without requiring significant re-architecture or disruption to existing services.

· All supported payment methods meet applicable federal accessibility requirements (e.g., Section 508/WCAG 2.1 AA) and do not introduce barriers to users with disabilities.

· Payment flows are usable and accessible across desktop and mobile devices without degradation in functionality.

· The solution uses a modular architecture that allows new payment capabilities to be added without major system redesign.

· Configuration-driven changes are supported where feasible, minimizing the need for custom development.

· New payment methods or features can be introduced without disruption to existing integrations.

· As newly available or enhanced payment capabilities become available, these are offered to the Government during the contract period Supplemental Clarification:

· All amounts shall be processed in U.S. dollars (USD), unless the Government expressly authorizes an alternative.

· The solution shall support line-item-level pricing, including individual rates, fee line items, and adjustment line items, and preserve that detail through APIs and exports used for invoicing and reconciliation.

Baseline Controls:

· Any implemented payment methods must comply with applicable security and regulatory requirements (e.g., PCI DSS).

· Mobile and alternative payment methods shall not degrade accessibility, usability, or security of the overall payment experience.

4.19 Data, Funds, and Transition Controls — Outcome: The Government retains full control over its data, funds, and operational continuity throughout the contract lifecycle, including during transition or termination, while ensuring compliance with federal security, privacy, and financial management requirements.

Acceptance Criteria:

· The Government can access and retrieve all transaction, reporting, and operational data at any time without requiring Contractor intervention.

· The contractor provides clear, documented visibility into end-to-end funds flow, including processing, settlement, and disbursement activities.

· The Government can transition to a successor provider without material disruption to payment processing, reporting, or reconciliation capabilities.

· The contractor supports the addition of new capabilities or service enhancements during the contract lifecycle without requiring replacement of the core system.

Baseline Controls:

· Data Ownership: All Government data remains the sole property of the Government. The contractor shall not use Government data for any purpose other than fulfilling contractual obligations.

· Data Portability (Execution): Upon request or contract termination, the contractor must provide a complete export of Government data (including transactions, refunds, settlements, audit logs, and associated metadata) in a structured, non-proprietary format within a defined timeframe (e.g., ≤ 30 days).

· Data Retention & Deletion (Enforcement): Data must be retained and disposed of in accordance with Government-defined retention schedules. The contractor must provide certified data destruction upon request or contract termination and must not retain Government data beyond authorized periods.

· Access Revocation: The system must support immediate revocation of user and system access upon Government request, with changes propagated across all system components without undue delay.

· Data Location Enforcement: Government data must be stored and processed within approved geographic regions as defined by the Government. Any cross-border data transfer must be explicitly authorized.

· Funds Handling Transparency: The contractor must clearly define and document its role in funds handling (e.g., payment processor, fiscal agent, or intermediary) and ensure that all funds are handled in accordance with Treasury requirements and applicable federal financial management regulations. The solution must support appropriate segregation of Government funds and prevent unauthorized commingling.

· Operational Continuity During Transition: The contractor must ensure continuity of services during transition to a successor provider, including support for parallel operations where necessary to prevent disruption.

· Auditability of Data and Funds: The Government must be able to audit data handling, access, and funds flow processes. Supporting documentation and system access must be provided upon request.

· Capability Expansion Protection: Newly available or enhanced capabilities offered by the contractor during the contract period must be made available to the Government under commercially reasonable terms, without replacement of the core system.

· Sub processor Alignment: Sub processor requirements and obligations are defined in Section 4.15, and the contractor remains fully responsible for compliance and performance.

5. DELIVERABLES

The contractor shall provide the following deliverables to support operation, oversight, compliance, and integration of the payment processing services. Additional or more specific deliverables may be defined at the task order level.

All deliverables shall be provided in non-proprietary, machine-readable formats where applicable and shall not require the use of Contractor-specific tools for access.

To the extent practicable, the contractor is encouraged to provide a customer-facing portal or equivalent capability that enables the Government to access operational, financial, and reporting data in near real-time. Such capability shall support on-demand access and the ability to export data in machine-readable formats without requiring Contractor intervention.

Note: Where frequency is stated as “on-demand,” this shall mean that the Government has direct, self-service access to the information through a customer-facing dashboard, portal, or equivalent capability, without requiring Contractor intervention.

Additional deliverables shall include documentation and access necessary to support payment-object retrieval, refund retrieval, checkout-session or equivalent recovery workflows, and webhook delivery troubleshooting.

6. SERVICE LEVEL REQUIREMENTS (SLAs)

The following service levels represent baseline performance expectations applicable across all orders under this contract. Specific service levels, thresholds, and remedies may be refined or expanded at the order level based on mission needs.

Attachment A - CYBER INCIDENT REPORTING REQUIREMENTS FOR

INFORMATION AND COMMUNICATION TECHNOLOGY (ICT) CONTRACTS

1.0 DEFINITIONS

1.1 Cyber Incident:[footnoteRef:1] An occurrence that (1) actually or imminently jeopardizes, without lawful authority, the integrity, confidentiality, or availability of information or an information system; or (2) constitutes a violation or imminent threat of violation of law, security policies, security procedures, or acceptable use policies. [1: See 44 U.S.C. 3552(b)(2).]

1.2 Breach of Personally Identifiable Information (PII):[footnoteRef:2] The loss of control, compromise, unauthorized disclosure, unauthorized acquisition, or any similar occurrence. [2: See OMB-17-12, Preparing for and Responding to a Breach of Personally Identifiable Information.]

1.3 Data: Other than commercial products and services. Examples of data include technical information such as research and engineering data, engineering drawings, and associated lists, specifications, standards, process sheets, manuals, technical reports, technical orders, catalog-item identifications, data sets, studies and analyses and related information, and computer software executable code and source code.

2.0 GENERAL

The contractor shall conduct support activities in compliance with all applicable laws and regulations governing the interception, monitoring, access, use, and disclosure of electronic communications and data. The requirements for safeguarding and cyber incident reporting outlined herein do not supersede or replace the contractor’s obligations under any other applicable U.S. government statutory or regulatory requirements related to safeguarding or cyber incident reporting. These include but are not limited to Executive Orders 14144 and 14028; guidance from the Office of Management and Budget (OMB); and directives from the Cybersecurity and Infrastructure Security Government (CISA), including Binding Operational Directives (BODs) and the Known Exploited Vulnerabilities (KEV) Catalog.

The contractor shall maintain an internal cyber incident response plan that includes procedures for escalation, containment, coordination with third parties, and compliance with Treasury and CISA reporting obligations. Treasury reserves the right to review this plan upon request.

The contractor shall support and integrate with Treasury’s enterprise Continuous Diagnostics and Mitigation (CDM) solution, providing near-real-time telemetry and logging data as required. Upon request, the contractor shall provide Treasury access to relevant event logs, security metrics, or detection outputs consistent with OMB M-21-31.

For contractor-hosted systems, telemetry and logging outputs shall be made available for ingestion into Treasury’s enterprise CDM environment or other designated security information and event management (SIEM) solution.

3.0 INCIDENT REPORTING PROCESS

The following process shall be followed in the event of any suspected incident affecting the Treasury data and assets held or managed by the contractor, the infrastructure or assets of the contractor, or those infrastructure or assets of any disclosed or undisclosed partners, subcontractors, supporting entities, or original equipment manufacturers (OEM), including those engaged through resellers if not directly contracted.

For avoidance of doubt, this obligation extends to any incident involving third-party environments, systems, or services integrated with or supporting contractor operations that could reasonably pose risk to Treasury information systems or data, irrespective of contractual privity or disclosure status. This process also applies to all information and communication technology (ICT) systems operated by or on behalf of the Department and its Bureaus, offices, and affiliated organizations, as well as systems within the Departmental Offices or Department-wide systems. Unless otherwise specified, the following requirements apply to all suspected incidents, regardless of severity, impact, or origin.

Reporting obligations extend to any connected or integrated system (including API-linked, federated, or managed services) that provides access to or exchanges data with Treasury systems, whether hosted by the contractor or a third party.

These reporting requirements are in addition to any other statutory reporting requirement for cyber incidents, including but not limited to those imposed by the Cyber Incident Reporting for Critical Infrastructure Act of 2022, or any future implementation regulations issued by the Cybersecurity and Infrastructure Security Government (CISA).

If a contractor has a reasonable suspicion to conclude that a cyber incident or breach of PII may have occurred affecting its own infrastructure, or that of its partners, subcontractors, other supporting entities, or OEMs, the contractor shall:

· Immediately notify the Treasury Shared Services Security Operations Center (TSOC) at 202-927-9777 (24x7) and email: soc@treasury.gov; additionally

· notify Bureau Security Operations Center (SOC) (will be provided as a POC in the award), and

· make notification to the contracting office (CO and CS), contracting officer's representative (COR), and program manager or other Technical POCs (TPOC) via email as identified in the award.

· Required written notifications shall be made via secure email using a commercially accepted standard cyber incident report forms or formats.

· The contractor shall make notification within 24 hours after a suspected incident occurs or is identified. [NOTE: Refer to section 1.0 Definitions for Cyber Incident and Breach of Personally Identifiable Information (PII).]

· The contractor remains responsible for ensuring that any incident identified by its subcontractors, OEMs, or supporting entities is reported to Treasury within the required 24-hour timeframe. Internal reporting arrangements among the contractor and its supply chain shall be sufficient to ensure compliance with this requirement.

· Within 24 - 48 hours, the contractor shall provide a preliminary incident summary that minimally reports the scope of the incident, the impact, initial response, and status of the incident.

· Within 5 – 7 calendar days following containment, the contractor shall provide an incident report that includes, at a minimum, the items identified below. The contractor shall begin providing information as it becomes available and shall not wait until the end of the 5 to 7 day period to begin reporting.

· Name of company

· Identification of affected contracts

· Identification of subcontractors, partners, or other supporting entities involved in contract performance

· Their level of involvement or area of responsibility

· Whether they were subject to or the originator of the incident

· Date and time of the incident (initial detection and estimated onset)

· Method of detection (e.g., EDR alert, user report, SIEM correlation, third-party notification)

· Location of affected systems or assets (logical or physical, if applicable)

· Nature of the attack (e.g., ransomware, phishing, insider threat)

· Identification of affected systems and data

· Classification of compromised data (e.g., PII, CUI, FTI, HIPAA, proprietary)

· A description of the impacted data and the number of records impacted and/or the number of individual’s PII potentially compromised

· Compromised credentials, if applicable

· Scope of the breach, is applicable

· Level of impact on operations and/or a detailed impact assessment

· Detailed damage assessment

· Encryption status of data at the time of the attack

· Evidence of the attack, including related log data, NetFlow, or packet captures

· Details on the attacker’s tactics, techniques, and procedures (TTPs)

· Indicators of compromise (IOCs) identified

· Copies of any internal incident report(s), if available and permitted

· Encryption status at the time of the attack

· Analysis of backup and preserved data

· Review logs

· Analysis of backup and preserved data

· Review of system and network logs

· Root cause analysis conducted

· Chain-of-custody status for any preserved forensic evidence

· Remediation and mitigation activities undertaken or planned

· Recommendations for Treasury or federal partners, if applicable

· Responsible contractor point(s) of contact (name, title, phone, email)

· Statement confirming preservation of relevant forensic evidence for at least 90 days

· Summary of any external disclosures (e.g., CISA notification under CIRCIA)

· Within 30 days after resolution of the incident, the contractor shall provide a full post-incident report that minimally includes a final summary of the incident with all pertinent facts, remediation activities employed and that will be employed in the future, and lessons learned, in addition to recommendations for the Treasury to consider for preventing future incidents. A brief to Government leadership may also be required at this stage. The contractor shall update this report with any changes occurring within two years after delivery of the report to the TSOC.

Cooperation and Responsiveness: The contractor, partners, subcontractors, supporting entities, and OEM shall fully cooperate with all requests for information, data, and assistance, responding as promptly as security requirements allow.

The contractor shall participate in Treasury- or CISA-directed cyber threat information sharing initiatives, including sector-specific information sharing and analysis centers (ISACs) and the Joint Cyber Defense Collaborative (JCDC), and must act on urgent threat intelligence, alerts, or mitigation directives without delay.

Protection of Proprietary and Sensitive Data and Authorized Release of Information: If the required contractor data includes sensitive or proprietary information, the contractor shall clearly mark it accordingly.[footnoteRef:3] The Government will handle such information in accordance with applicable law, including the Trade Secrets Act (18 U.S.C. § 1905), the Freedom of Information Act (5 U.S.C. § 552) exemptions, and other relevant statutes and regulations, to protect against unauthorized disclosure, misuse, or access. [3: Contractors should clearly mark materials concerning information systems vulnerability information “CUI//ISVI” and any proprietary business information “CUI//SP-PROPIN”. Additional standard marking guidance can be found at https://www.archives.gov/cui/registry/category-list.]

Notwithstanding the above, information obtained from the contractor or derived from information obtained from the contractor, regardless of whether its creation was by or for the Treasury, is authorized to be released outside of Treasury for the following purposes: (1) to entities with missions that may be affected by such information; (2) entities that may be called upon to assist in the diagnosis, detection, or mitigation of cyber incidents; (3) to government entities that conduct counterintelligence or law enforcement investigations; (4) for national security purposes; (5) service contractors directly supporting Treasury information technology systems or processes; (6) any lawful government purpose or activity subject applicable statutory, regulatory, and policy based restrictions on the government’s use and release of such information, and (7) to support public vulnerability disclosures or secure software ecosystem practices in accordance with EO 14144, provided appropriate protections are in place.

Preservation of Forensic Evidence: The contractor shall preserve and protect forensic images of all known affected information systems identified and all relevant monitoring/packet capture data for at least 90 days from the submission of the cyber incident report to allow Treasury to request the media or decline interest. Preservation shall be in a forensically sound manner and maintain chain-of-custody documentation, to ensure evidentiary integrity in the event of law enforcement or counterintelligence review.

Upon request by any element of the Treasury, the contractor shall provide access to additional information or equipment that may be necessary to conduct forensic analyses.

Ongoing Reporting and Supplemental Updates: The contractor shall be responsible for providing updates and supplemental information as requested by any element of the Treasury.

Third-Party and Supply Chain Incident Reporting: Contractors shall ensure all subcontractors, OEMs, cloud service providers, software Contractors, and other entities in their operational or technical supply chain are contractually obligated to notify both the contractor and Treasury of any cybersecurity incident, compromise, or breach of PII that could reasonably affect Treasury systems, networks, or data—whether or not Treasury data is directly hosted, processed, or confirmed as impacted.

Such reporting shall follow the same timelines and content requirements defined herein. The contractor shall not defer or delay Treasury notification pending third-party validation or confirmation.

Failure of any subcontractor or supplier to provide timely notification does not relieve the contractor of responsibility for Treasury reporting obligations.

Treasury Declared Incidences: When the Treasury Chief Information Officer (CIO) declares a cybersecurity incident—regardless of whether the contractor has independently detected, confirmed, or been made aware of the issue—the contractor shall immediately acknowledge receipt of the declaration and provide full cooperation.

The contractor shall furnish, upon request, the same level of detail, evidence, and technical access required for contractor-identified incidents, including logs, system images, and personnel access.

This includes delivering the same level of detail, documentation, and technical assistance required for contractor-identified incidents, including logs, forensic images, personnel access, and any other supporting data. The contractor shall respond with urgency and in good faith, providing all requested information and access without delay, subject only to applicable security restrictions.

3.1 Additional Requirements For Software-As-A-Service (SaaS) and Software Providers

SaaS and software providers shall proactively monitor for, assess, and disclose any security vulnerabilities, misconfigurations, weaknesses, or known risks—whether identified internally, through third-party sources, coordinated vulnerability disclosure programs, or government advisories.

At the time of award and…