36C10B24Q0701 FINAL .pdf

PAGE 1 OF 1. REQUISITION NO.

2. CONTRACT NO. 3. AWARD/EFFECTIVE DATE 4. ORDER NO. 5. SOLICITATION NUMBER 6. SOLICITATION ISSUE DATE

a. NAME b. TELEPHONE NO. (No Collect Calls) 8. OFFER DUE DATE/LOCAL

TIME

9. ISSUED BY CODE 10. THIS ACQUISITION IS UNRESTRICTED OR SET ASIDE: % FOR:

SMALL BUSINESS

HUBZONE SMALL

BUSINESS

SERVICE-DISABLED

VETERAN-OWNED

SMALL BUSINESS

WOMEN-OWNED SMALL BUSINESS

(WOSB) ELIGIBLE UNDER THE WOMEN-OWNED

SMALL BUSINESS PROGRAM

EDWOSB

8(A)

NAICS:

SIZE STANDARD:

11. DELIVERY FOR FOB DESTINA-

TION UNLESS BLOCK IS

MARKED

SEE SCHEDULE

12. DISCOUNT TERMS

13a. THIS CONTRACT IS A

RATED ORDER UNDER

DPAS (15 CFR 700)

13b. RATING

14. METHOD OF SOLICITATION

RFQ IFB RFP

15. DELIVER TO CODE 16. ADMINISTERED BY CODE

17a. CONTRACTOR/OFFEROR CODE FACILITY CODE 18a. PAYMENT WILL BE MADE BY CODE

TELEPHONE NO. UEI: EFT:

PHONE: FAX:

17b. CHECK IF REMITTANCE IS DIFFERENT AND PUT SUCH ADDRESS IN OFFER

18b. SUBMIT INVOICES TO ADDRESS SHOWN IN BLOCK 18a UNLESS BLOCK BELOW IS CHECKED

SEE ADDENDUM

19. 20. 21. 22. 23. 24.

ITEM NO. SCHEDULE OF SUPPLIES/SERVICES QUANTITY UNIT UNIT PRICE AMOUNT

(Use Reverse and/or Attach Additional Sheets as Necessary)

25. ACCOUNTING AND APPROPRIATION DATA 26. TOTAL AWARD AMOUNT (For Govt. Use Only)

27a. SOLICITATION INCORPORATES BY REFERENCE FAR 52.212-1, 52.212-4. FAR 52.212-3 AND 52.212-5 ARE ATTACHED. ADDENDA ARE ARE NOT ATTACHED.

27b. CONTRACT/PURCHASE ORDER INCORPORATES BY REFERENCE FAR 52.212-4. FAR 52.212-5 IS ATTACHED. ADDENDA ARE ARE NOT ATTACHED

28. CONTRACTOR IS REQUIRED TO SIGN THIS DOCUMENT AND RETURN _______________ 29. AWARD OF CONTRACT: REF. ___________________________________ OFFER

COPIES TO ISSUING OFFICE. CONTRACTOR AGREES TO FURNISH AND DATED ________________________________. YOUR OFFER ON SOLICITATION

DELIVER ALL ITEMS SET FORTH OR OTHERWISE IDENTIFIED ABOVE AND ON ANY (BLOCK 5), INCLUDING ANY ADDITIONS OR CHANGES WHICH ARE

ADDITIONAL SHEETS SUBJECT TO THE TERMS AND CONDITIONS SPECIFIED SET FORTH HEREIN IS ACCEPTED AS TO ITEMS:

30a. SIGNATURE OF OFFEROR/CONTRACTOR 31a. UNITED STATES OF AMERICA (SIGNATURE OF CONTRACTING OFFICER)

30b. NAME AND TITLE OF SIGNER (TYPE OR PRINT) 30c. DATE SIGNED 31b. NAME OF CONTRACTING OFFICER (TYPE OR PRINT) 31c. DATE SIGNED

AUTHORIZED FOR LOCAL REPRODUCTION (REV. NOV 2021)

PREVIOUS EDITION IS NOT USABLE Prescribed by GSA - FAR (48 CFR) 53.212

7. FOR SOLICITATION

INFORMATION CALL:

STANDARD FORM 1449

SOLICITATION/CONTRACT/ORDER FOR COMMERCIAL PRODUCTS AND COMMERCIAL SERVICES

OFFEROR TO COMPLETE BLOCKS 12, 17, 23, 24, & 30

36C10B24Q0701 08-23-2024

Mike Frank 848-377-5110 08-30-2024

1PM EST

36C10B

Department of Veterans Affairs

Technology Acquisition Center

23 Christopher Way

Eatontown NJ 07724

X 100

X

541519

$34 Million

N/A

X

See Delivery Schedule

36C10B

Technology Acquisition Center

36C10A

Technology Acquisition Center

Financial Services Center

PO Box 149971

Austin TX 78714-8971

VA.Gov Innovate, Iterate, and Run (IIR)

X X

Khosbayar Rentsendorj

Contracting Officer

36C10B24Q0701

Table of Contents

SECTION A

A.1 SF 1449 SOLICITATION/CONTRACT/ORDER FOR COMMERCIAL PRODUCTS AND

COMMERCIAL SERVICES

SECTION B – CONTINUATION OF SF1449 BLOCKS

B.1 GOVERNING LAW CLAUSE

B.2 SOFTWARE LICENSE, SOFTWARE MAINTENANCE AND SOFTWARE TECHNICAL

SUPPORT

B.3 CONTRACT ADMINISTRATION DATA

B.4 PRICE/COST/DELIVERY SCHEDULE

B.5 PERFORMANCE WORK STATEMENT

SECTION C - CONTRACT CLAUSES

C.1 52.252-2 CLAUSES INCORPORATED BY REFERENCE (FEB 1998)

C.2 52.204-21 BASIC SAFEGUARDING OF COVERED CONTRACTOR INFORMATION

SYSTEMS (NOV 2021)

C.3 52.212-5 CONTRACT TERMS AND CONDITIONS REQUIRED TO IMPLEMENT

STATUTES OR EXECUTIVE ORDERS—COMMERCIAL PRODUCTS AND

COMMERCIAL SERVICES (MAY 2024)

C.4 52.217-7 OPTION FOR INCREASED QUANTITY – SEPARATELY PRICED LINE

ITEM (MAR 1989)

C.5 52.227-19 COMMERCIAL COMPUTER SOFTWARE LICENSE (DEC 2007)

C.6 VAAR 852.204-71 INFORMATION AND INFORMATION SYSTEMS SECURITY (FEB

2023)

C.7 852.219-73 VA NOTICE OF TOTAL SET-ASIDE FOR VERIFIED SERVICE-DISABLED

VETERAN-OWNED SMALL BUSINESSES (JAN 2023)

C.8 VAAR 852.219-75 VA NOTICE OF LIMITATIONS ON SUBCONTRACTING—

CERTIFICATE OF COMPLIANCE FOR SERVICES AND CONSTRUCTION (JAN 2023) ... 66

C.9 VAAR 852.232-72 ELECTRONIC SUBMISSION OF PAYMENT REQUESTS (NOV

2018)

C.10 VAAR 852.237-75 KEY PERSONNEL (OCT 2019)

C.11 VAAR 852.239-76 INFORMATION AND COMMUNICATION TECHNOLOGY

ACCESSIBILITY (FEB 2023)

C.12 VAAR 852.242-71 ADMINISTRATIVE CONTRACTING OFFICER (OCT 2020)

SECTION D - CONTRACT DOCUMENTS, EXHIBITS, OR ATTACHMENTS

SECTION E - SOLICITATION PROVISIONS

E.1 52.252-1 SOLICITATION PROVISIONS INCORPORATED BY REFERENCE (FEB

1998)

E.2 52.204-24 REPRESENTATION REGARDING CERTAIN TELECOMMUNICATIONS

AND VIDEO SURVEILLANCE SERVICES OR EQUIPMENT (NOV 2021)

E.3 52.204-29 FEDERAL ACQUISITION SUPPLY CHAIN SECURITY ACT ORDERS—

REPRESENTATION AND DISCLOSURES (DEC 2023)

E.4 52.209-7 INFORMATION REGARDING RESPONSIBILITY MATTERS (OCT 2018)

E.5 52.212-3 OFFEROR REPRESENTATIONS AND CERTIFICATIONS—COMMERCIAL

PRODUCTS AND COMMERCIAL SERVICES (MAY 2024)

E.6 52.216-1 TYPE OF CONTRACT (APR 1984)

E.7 52.233-2 SERVICE OF PROTEST (SEP 2006)

E.8 VAAR 852.233-71 ALTERNATE PROTEST PROCEDURE (OCT 2018)

E.9 VETCERT VERIFICATION REQUIREMENT FOR SERVICE-DISABLED VETERAN

OWNED SMALL BUSINESSES (SDVOSBs)

E.10 BASIS FOR AWARD

E.11 ADDENDUM to FAR 52.212-1 INSTRUCTIONS TO OFFERORS--COMMERCIAL

ITEMS

SECTION B – CONTINUATION OF SF1449 BLOCKS

B.1 GOVERNING LAW CLAUSE

Federal law and regulations, including the Federal Acquisition Regulations (FAR), shall govern this

Contract/Order. Commercial license agreements may be made a part of this Contract/Order but only if both parties expressly make them an addendum hereto. If the commercial license agreement is not made an addendum, it shall not apply, govern, be a part of or have any effect whatsoever on the Contract/Order;

this includes, but is not limited to, any agreement embedded in the computer software (clickwrap), any agreement that is otherwise delivered with or provided to the Government with the commercial computer software or documentation (shrinkwrap), or any other license agreement otherwise referred to in any document. If a commercial license agreement is made an addendum, only those provisions addressing data rights regarding the Government’s use, duplication and disclosure of data (e.g., restricted computer software) are included and made a part of this Contract/Order, and only to the extent that those provisions are not duplicative or inconsistent with Federal law, Federal regulation, the incorporated FAR clauses and the provisions of this Contract/Order; those provisions in the commercial license agreement that do not address data rights regarding the Government’s use, duplication and disclosure of data shall not be included or made a part of the Contract/Order. Federal law and regulation including, without limitation, the Contract Disputes Act (41 U.S.C. § 7101 et seq.), the Anti-Deficiency Act (31 U.S.C. § 1341 et seq.), the Competition in Contracting Act (41 U.S.C. § 3301 et seq.), the Prompt Payment Act (31 U.S.C. §3901 et seq.), Contracts for Data Processing or Maintenance (38 U.S.C. § 5725), and FAR clauses 52.212-4, 52.227-14, 52.227-19 shall supersede, control, and render ineffective any inconsistent, conflicting, or duplicative provision in any commercial license agreement. In the event of conflict between this Clause and any provision in the Contract/Order or the commercial license agreement or elsewhere, the terms of this Clause shall prevail. Claims of patent or copyright infringement brought against the Government as a party shall be defended by the U.S. Department of Justice (DOJ). 28 U.S.C. § 516. At the discretion of

DOJ, the Contractor may be allowed reasonable participation in the defense of the litigation. Any additional changes to the Contract/Order must be made by contract/order modification (Standard Form

30) and shall only be effected by a warranted Contracting Officer. Nothing in this Contract/Order or any commercial license agreement shall be construed as a waiver of sovereign immunity.

B.2 SOFTWARE LICENSE, SOFTWARE MAINTENANCE AND SOFTWARE

TECHNICAL SUPPORT

(1). Definitions.

a) Licensee. The term “licensee” shall mean the U.S. Department of Veterans Affairs (“VA”) and is synonymous with “Government.”

b) Licensor. The term “licensor” shall mean the Contractor having the necessary license or ownership rights to deliver license, software maintenance and support of the computer software being acquired. The term “Contractor” is the party identified in Block 17a on the SF1449. If the

Contractor is a reseller and not the Licensor, the Contractor remains responsible for performance under this Contract/Order.

c) Software. The term “software” shall mean the licensed computer software product(s) cited in the

Schedule of Supplies/Services.

d) Maintenance. The term “maintenance” is the process of enhancing and optimizing software, as well as remedying defects. It shall include all new fixes, patches, releases, updates, versions and upgrades, as further defined below.

e) Technical Support. The term “technical support” refers to the range of services providing assistance for the software via the telephone, email, a website or otherwise.

f) Release or Update. The term “release” or “update” are terms that refer to a revision of software that contains defect corrections, minor enhancements, or improvements of the software’s functionality. This is usually designated by a change in the number to the right of the decimal point (e.g., from Version 5.3 to 5.4). An example of an update is the addition of new hardware.

g) Version or Upgrade. The term “version” or “upgrade” are terms that refer to a revision of software that contains new or improved functionality. This is usually designated by a change in the number to the left of the decimal point (e.g., from Version 5.4 to 6).

(2). Software License.

a) Unless otherwise stated in the Schedule of Supplies/Services, the Performance Work Statement or

Product Description, the software license provided to the Government is a perpetual, nonexclusive license to use the software.

b) The Government may use the software in a networked environment.

c) Any dispute regarding the license grant or usage limitations shall be resolved in accordance with the Disputes Clause incorporated in FAR 52.212-4(d).

d) All limitations of software usage are expressly stated in the Schedule of Supplies/Services and the

Performance Work Statement/Product Description.

(3). Software Maintenance and/or Technical Support.

a) If the Government desires to continue software maintenance and support beyond the period of performance identified in this Contract/Order, the Government will issue a separate contract or order for maintenance and support. Conversely, if a contract or order for continuing software maintenance and technical support is not received, the Contractor is neither authorized nor permitted to renew any of the previously furnished services.

b) The Contractor shall provide software support services, which includes periodic updates, enhancements and corrections to the software, and reasonable technical support, all of which are customarily provided by the Contractor to its commercial customers to cause the software to perform according to its specifications, documentation or demonstrated claims.

c) Any telephone support provided by Contractor shall be at no additional cost.

d) The Contractor shall provide all maintenance services in a timely manner in accordance with the

Contractor’s customary practice or as defined in the Performance Work Statement or Product

Description. However, prolonged delay (exceeding two business days) in resolving software problems will be noted in the Government’s various past performance records on the Contractor

(e.g., www.cpars.gov).

http://www.cpars.gov/

e) If the Government allows the maintenance and support to lapse and subsequently wishes to reinstate it, any reinstatement fee charged shall not exceed the amounts that would have been charged if the Government had not allowed the subscription to lapse.

(4). Disabling Software Code.

The Government requires delivery of computer software that does not contain any code that will, upon the occurrence or the nonoccurrence of any event, disable the software. Such code includes but is not limited to a computer virus, restrictive key, node lock, time-out, or other function, whether implemented by electronic, mechanical, or other means, which limits or hinders the use or access to any computer software based on residency on a specific hardware configuration, frequency of duration of use, or other limiting criteria. If any such disabling code is present, the Contractor agrees to indemnify the

Government for all damages suffered as a result of a disabling caused by such code, and the contractor agrees to remove such code upon the Government’s request at no extra cost to the Government. Inability of the Contractor to remove the disabling software code will be considered an inexcusable delay and a material breach of contract, and the Government may exercise its right to terminate for cause. In addition, the Government is permitted to remove the code as it deems appropriate and charge the Contractor for consideration for the time and effort expended in removing the code.

(5). Manuals and Publications.

Upon Government request, the Contractor shall furnish the most current version of the user manual and publications for all products/services provided under this Contract/Order at no cost.

B.3 CONTRACT ADMINISTRATION DATA

1. Contract Administration: All contract administration matters will be handled by the following individuals:

a. CONTRACTOR: TBD

b. GOVERNMENT: Contracting Officer, Khosbayar Rentsendorj

Technology Acquisition Center

2. CONTRACTOR REMITTANCE ADDRESS: All payments by the Government to the contractor will be made in accordance with:

[X] 52.232-33, Payment by Electronic Funds Transfer—System For Award Management, or

[ ] 52.232-36, Payment by Third Party

3. INVOICES: Invoices shall be submitted in arrears:

a. Quarterly [ ]

b. Semi-Annually [ ]

c. Other [X] After Government inspection and acceptance.

4. GOVERNMENT INVOICE ADDRESS: All Invoices from the contractor shall be submitted electronically in accordance with VAAR Clause 852.232-72 Electronic Submission of Payment Requests.

5. ACKNOWLEDGMENT OF AMENDMENTS: The offeror acknowledges receipt of amendments to the Solicitation numbered and dated as follows:

AMENDMENT NO DATE

6. Purchase Order for Billing Purposes: TBD

7. ARM Approval: TBD

B.4 PRICE/COST/DELIVERY SCHEDULE

LINE

ITEM

DESCRIPTION QTY UNIT

UNIT

PRICE

TOTAL PRICE

0001 VA.gov Iterate, Innovate, and Run

POP: 12 months

This Firm-Fixed-Price (FFP) Contract

Line Item (CLIN) includes all labor, material, and/or travel required for the successful completion of the services detailed in the PWS.

Quantity of 1 EA equals one (1) 2-week iteration.

PSC: DA01

26 EA $ $

0001AA Delivery and Monitoring Report and

Roster

Due on the fifth of every month. See

PWS 6.1.

Electronic submission to: VA COR, and Government Product Owner.

Inspection: Destination

Acceptance: Destination

12 EA NSP NSP

Total Base Period Price $

OPTIONAL TASK

This is an optional task, FAR 52.217-7, Option for Increased Quantity – Separately priced Line

Item (MAR 1989). Work shall not commence until, and unless, a formal modification is issued by the Contracting Officer.

0002 Transition Support (Optional Task)

This FFP CLIN can be exercised IAW

52.217-7 and shall include up to four

(4) 2-week sprints of transition support and delivery of a Transition Support

Package within seven days upon optional task exercise. See PWS 5.1.

Quantity of 1 EA equals one (1) 2-week iteration.

PSC: DA01

Inspection/Acceptance: Destination

4 EA $ $

0002AA Transition Support Package IAW 1 EA NSP NSP

PWS 5.1

Due 7 days after optional task exercise.

Electronic submission to: VA COR, and Government Product Owner.

PSC: DA01

Inspection/Acceptance: Destination

Total Contract Price $

B.5 PERFORMANCE WORK STATEMENT

PERFORMANCE WORK STATEMENT (PWS)

DEPARTMENT OF VETERANS AFFAIRS

VA Office of the Chief Technology Officer

VA.gov Iterate, Innovate, and Run

Date: 8/16/2024

PWS Version Number: 1.0

1.0 BACKGROUND

1.1 MISSION OF THE REQUESTING BUSINESS OFFICE

In 2017, the Department of Veterans Affairs (VA) Office of the Chief Technology Officer

(OCTO) partnered with VA Central Office and all three VA Administrations to identify a vision statement for enhancing VA’s digital presence for Veterans. That vision is known as the Digital

Modernization Vision and is supported by a group of VA executives known as the Digital

Modernization Council. This council is chaired by the Chief Technology Officer.

The VA Digital Modernization Vision defined in July 2017:

VA will deliver self-service tools on par with top private sector companies and will have the best online experience in the Federal Government. Every digital service will be customized to the individual using it. Interacting with VA digital services will feel like navigating TurboTax, not filling out a form.

In addition to this vision, the team that runs VA.gov (OCTO-Digital Experience) has a vision and mission that describes our idea of the state of the world and our role in making it happen.

Our Vision: Every Veteran is guaranteed access to self-service benefits and accurate data

Our Mission: Continuously deliver high-quality digital experiences for the benefit of all

Veterans and their families

1.2 PROBLEM WE ARE TRYING TO SOLVE

VA anticipates that the recently passed Promise to Address Comprehensive Toxics (PACT) Act, better known as the PACT Act legislation, will significantly increase the claims backlog, traffic to VA.gov, and drive change requests for dozens of existing VA health, benefit, and claims products.

Today, there are over 200 active products on VA.gov. Most of these products have been created by contract teams supporting OCTO, or the previous Digital Service at VA team, within the last

7 years. These products cover a range of benefit types, but primarily they are self-service tools for Veterans seeking health, disability, pension, education, and housing benefits. While there are currently over 30 active product teams on VA.gov, this multitude of active products poses a significant challenge. There simply are not enough active teams to both develop new products and iterate on the existing ones. Additionally, there are several critical products and processes without clear ownership in the current Veteran Facing Services (VFS) structure that require attention. These product teams will help to fill that gap for VA.gov.

1.2 ADDITIONAL CONSIDERATIONS ON THE PROBLEM SPACE

This team will fill a critical gap in the VA.gov ecosystem, which will require new definitions of ownership for certain products. Today, the OCTO Portfolios and Crews understand which products they “own” and which they believe they are not accountable for. A portion of this work will involve the conversations required to establish clear ownership of all VA.gov products and the identification of full list of products that required ownership by this VA.gov Innovate, Iterate, and Run (IIR) team. This also applies to processes that may not be clearly defined today in the

VA.gov Platform governance structure or collaboration cycle.

This team will fall under the newly created Core Veteran Experiences Crew within the OCTO

Digital Experience Portfolio. This may impact the focus and scope of the team’s work moving forward.

2.0 APPLICABLE DOCUMENTS

In the performance of the tasks associated with this Performance Work Statement, the Contractor shall comply with the following:

1. 44 U.S.C. § 3541-3549, “Federal Information Security Management Act (FISMA) of

2002”

2. “Federal Information Security Modernization Act of 2014”

3. Federal Information Processing Standards (FIPS) Publication 140-2, “Security

Requirements for Cryptographic Modules”

4. FIPS Pub 199. “Standards for Security Categorization of Federal Information and

Information Systems,” February 2004

5. FIPS Pub 200, “Minimum Security Requirements for Federal Information and

Information Systems,” March 2006

6. FIPS Pub 201-2, “Personal Identity Verification of Federal Employees and

Contractors,” August 2013

7. 10 U.S.C. § 2224, "Defense Information Assurance Program"

8. 5 U.S.C. § 552a, as amended, “The Privacy Act of 1974”

9. Public Law 109-461, Veterans Benefits, Health Care, and Information Technology

Act of 2006, Title IX, Information Security Matters

10. 42 U.S.C. § 2000d “Title VI of the Civil Rights Act of 1964”

11. VA Directive 0710, “Personnel Security and Suitability Program,” June 4, 2010, https://www.va.gov/vapubs/index.cfm

12. VA Handbook 0710, “Personnel Security and Suitability Program,” May 2, 2016, https://www.va.gov/vapubs/index.cfm

13. VA Directive and Handbook 6102, “Internet/Intranet Services,” August 5, 2019

14. 36 C.F.R. Part 1194 “Information and Communication Technology Standards and

Guidelines,” January 18, 2017

15. Office of Management and Budget (OMB) Circular A-130, “Managing Federal

Information as a Strategic Resource,” July 28, 2016

16. 32 C.F.R. Part 199, “Civilian Health and Medical Program of the Uniformed

Services (CHAMPUS)”

17. NIST SP 800-66 Rev. 1, “An Introductory Resource Guide for Implementing the

Health Insurance Portability and Accountability Act (HIPAA) Security Rule,”

October 2008

18. Sections 504 and 508 of the Rehabilitation Act (29 U.S.C. § 794d), as amended, January 18, 2017

19. Homeland Security Presidential Directive (12) (HSPD-12), August 27, 2004

20. VA Directive 6500, “VA Cybersecurity Program,” February 24, 2021

21. VA Handbook 6500, “Risk Management Framework for VA Information Systems

VA Information Security Program,” February 24, 2021 https://www.va.gov/vapubs/index.cfm https://www.va.gov/vapubs/index.cfm http://www.va.gov/vapubs http://www.va.gov/vapubs

22. VA Handbook 6500.2, “Management of Breaches Involving Sensitive Personal

Information (SPI),” March 12, 2019

23. VA Handbook 6500.5, “Incorporating Security and Privacy into the System

Development Lifecycle,” March 22, 2010

24. VA Handbook 6500.6, “Contract Security,” March 12, 2010

25. VA Handbook 6500.8, “Information System Contingency Planning,” April 6, 2011

26. VA Handbook 6500.10, “Mobile Device Security Policy,” February 15, 2018

27. VA Handbook 6500.11, “VA Firewall Configuration,” August 22, 2017

28. OIT Process Asset Library (PAL), https://www.va.gov/process/ . Reference Process

Maps at https://www.va.gov/process/maps.asp and Artifact templates at https://www.va.gov/process/artifacts.asp

29. One-VA Technical Reference Model (TRM) (reference at https://www.va.gov/trm/TRMHomePage.aspx)

30. VA Directive 6508, “Implementation of Privacy Threshold Analysis and Privacy

Impact Assessment,” October 15, 2014

31. VA Handbook 6508.1, “Procedures for Privacy Threshold Analysis and Privacy

Impact Assessment,” July 30, 2015

32. VA Handbook 6510, “VA Identity and Access Management,” January 15, 2016

33. VA Directive and Handbook 6513, “Secure External Connections,” October 12,

34. VA Directive 6300, “Records and Information Management,” September 21, 2018

35. VA Handbook, 6300.1, “Records Management Procedures,“ March 24, 2010

36. NIST SP 800-37 Rev 2, “Risk Management Framework for Information Systems and

Organizations: A System Life Cycle Approach for Security and Privacy,” December

37. NIST SP 800-53 Rev. 5, “Security and Privacy Controls for Federal Information

Systems and Organizations,” September 23, 2020 (includes updates as of

12/10/2020)

38. VA Directive 0735, “Homeland Security Presidential Directive 12 (HSPD-12)

Program,” October 26, 2015

39. VA Handbook 0735, “Homeland Security Presidential Directive 12 (HSPD-12)

Program,” March 24, 2014

40. OMB Memorandum 05-24, “Implementation of Homeland Security Presidential

Directive (HSPD) 12 – Policy for a Common Identification Standard for Federal

Employees and Contractors,” August 5, 2005

41. OMB Memorandum M-19-17, “Enabling Mission Delivery Through Improved

Identity, Credential, and Access Management,” May 21, 2019

42. OMB Memorandum, “Guidance for Homeland Security Presidential Directive

(HSPD) 12 Implementation,” May 23, 2008

43. Federal Identity, Credential, and Access Management (FICAM) Roadmap and

Implementation Guidance, December 2, 2011, (NOTE: Part A of the FICAM

Roadmap and Implementation Guidance, v2.0, was replaced in 2015 with an updated

Architecture (https://arch.idmanagement.gov/#what-is-the-ficam-architecture)

44. NIST SP 800-116 Rev 1, “Guidelines for the Use of Personal Identity Verification

(PIV) Credentials in Facility Access,“ June 2018

45. NIST SP 800-63-3, 800-63A, 800-63B, 800-63C, “Digital Identity Guidelines,” updated March 02, 2020

46. NIST SP 800-157, “Guidelines for Derived PIV Credentials,” December 2014 https://www.va.gov/process/ https://www.va.gov/process/maps.asp https://www.va.gov/process/artifacts.asp https://www.va.gov/trm/TRMHomePage.aspx https://arch.idmanagement.gov/#what-is-the-ficam-architecture

47. NIST SP 800-164, “Guidelines on Hardware-Rooted Security in Mobile Devices

(Draft),” October 2012

48. Draft National Institute of Standards and Technology Interagency Report (NISTIR)

7981, “Mobile, PIV, and Authentication,” March 2014

49. VA Memorandum, VAIQ #7100147, “Continued Implementation of Homeland

Security Presidential Directive 12 (HSPD-12),” April 29, 2011 (reference https://www.voa.va.gov/documentlistpublic.aspx?NodeID=514)

50. IAM Identity Management Business Requirements Guidance document, May 2013, (reference Enterprise Architecture Section, PIV/IAM (reference https://www.voa.va.gov/documentlistpublic.aspx?NodeID=514)

51. VA Memorandum “Personal Identity Verification (PIV) Logical Access Policy

Clarification,” July 17, 2019, https://www.voa.va.gov/DocumentView.aspx?DocumentID=4896

52. Trusted Internet Connections (TIC) 3.0 Core Guidance Documents, https://www.cisa.gov/publication/tic-30-core-guidance-documents

53. OMB Memorandum M-19-26, “Update to the Trusted Internet Connections (TIC)

Initiative,” September 12, 2019

54. OMB Memorandum M-08-23, “Securing the Federal Government’s Domain Name

System Infrastructure,” August 22, 2008

55. Sections 524 and 525 of the Energy Independence and Security Act of 2007, (Public

Law 110–140), December 19, 2007

56. Section 104 of the Energy Policy Act of 2005, (Public Law 109–58), August 8, 2005

57. Executive Order 13834, “Efficient Federal Operations,” dated May 17, 2018

58. Executive Order 13221, “Energy-Efficient Standby Power Devices,” August 2, 2001

59. VA Directive 0058, “VA Green Purchasing Program,” July 19, 2013

60. VA Handbook 0058, “VA Green Purchasing Program,” July 19, 2013

61. Office of Information Security (OIS) VAIQ #7424808 Memorandum, “Remote

Access,” January 15, 2014, https://www.voa.va.gov/DocumentListPublic.aspx?NodeId=28

62. Clinger-Cohen Act of 1996, 40 U.S.C. §11101 and §11103

63. “Veteran Focused Integration Process (VIP) Guide 4.0,” January 2021, https://www.voa.va.gov/DocumentView.aspx?DocumentID=4371

64. VA Memorandum “Proper Use of Email and Other Messaging Services,” January 2, 2018, https://www.voa.va.gov/DocumentListPublic.aspx?NodeId=28

65. “DevSecOps Product Line Management Playbook” version 2.0, May 2021, https://www.voa.va.gov/DocumentView.aspx?DocumentID=4946

66. NIST SP 500-267B Revision 1, “USGv6 Profile,” November 2020

67. OMB Memorandum M-21-07, “Completing the Transition to Internet Protocol

Version 6 (IPv6),” November 19, 2020

68. Social Security Number (SSN) Fraud Prevention Act of 2017

69. Section 240 of the Consolidated Appropriations Act (CAA) 2018, March 23, 2018

70. Full VA.gov product list in the VFS Product Directory: https://depo-platform-documentation.scrollhelp.site/getting-started/vfs-product-directory https://www.voa.va.gov/documentlistpublic.aspx?NodeID=514 https://www.voa.va.gov/documentlistpublic.aspx?NodeID=514 https://www.voa.va.gov/DocumentView.aspx?DocumentID=4896 https://www.cisa.gov/publication/tic-30-core-guidance-documents https://www.voa.va.gov/DocumentListPublic.aspx?NodeId=28 https://www.voa.va.gov/DocumentView.aspx?DocumentID=4371 https://www.voa.va.gov/DocumentListPublic.aspx?NodeId=28 https://www.voa.va.gov/DocumentView.aspx?DocumentID=4946 https://depo-platform-documentation.scrollhelp.site/getting-started/vfs-product-directory https://depo-platform-documentation.scrollhelp.site/getting-started/vfs-product-directory

3.0 SCOPE OF WORK

3.1 OVERVIEW OF WORK

These teams will support many VFS on VA.gov to fulfill the VA obligation to the PACT Act.

They will own, maintain, and improve existing products that currently do not have an owner or a dedicated VFS team. The teams will focus primarily on making small and medium sized improvements to these products, fixing bugs, and making updates based on changes to platform tooling and the VA design system. Example products include the VA.gov performance dashboard and Veteran Status tools.

This team will be expected to support experiences on both the VA.gov web platform and the VA

Health and Benefits mobile application. Product, design, and engineering direction will be influenced by the shifting focus of VA products from a primarily web-based responsive experience to a native mobile experience.

3.2 DEVELOPMENT METHODOLOGY AND WORKING PRINCIPLES

The contractor’s support and solutions shall follow the practices described in the Digital Services

Playbook (https://playbook.cio.gov). The contractor shall be thoroughly familiar with the concepts in each play and implement them in its approaches and support. The contractor shall design, develop, configure, customize, and deploy solutions to some of VA’s most pressing challenges. Once deployed, the contractor shall provide production support of the solution as required. The contractor shall provide support to projects that are building brand new systems as well as projects that are building on top of, or replacing, existing systems. The contractor shall be thoroughly familiar with current and emerging technologies, Software-as-a-Service products, services, various programming languages and processes required to deliver high-quality products.

When applicable to the current effort, the Contractor shall:

General

1. Deliver high-quality, usable, functional products that help users accomplish their tasks.

2. Follow the Digital Services Playbook (https://playbook.cio.gov).

3. Cultivate positive, trusting, and cooperative working relationships with all persons supporting the work, including government employees and other vendors.

4. Participate in Communities of Practice activities for Product, Design, Engineering, and Data where applicable.

Product

5. Work in self-contained, cross-functional teams capable of delivering complete products, including research, design, architecture, engineering, support, and documentation.

6. Incorporate agile practices and ceremonies into all work, such as sprint planning, daily standups, sprint review, retrospective, user stories/epics, backlog grooming, and estimating activities.

https://playbook.cio.gov/ https://playbook.cio.gov/

7. Establish goals, objectives, key performance metrics, and make bets to improve user outcomes. Bets are hypotheses that could impact established metrics and they encourage acceptance of uncertainty in the software development process.

8. Push new features and incremental improvements to production early and often, applying phased release practices with product health and performance targets.

9. Build applications and platforms with the intent of enhancing and sustaining that application until relieved by the Government or another team.

10. Collect customer feedback, hold product impact reviews, provide or support tiered troubleshooting and on-call operations, and complete postmortem incident reports.

11. Measure and improve performance against DevOps Research and Assessment metrics including deployment frequency, lead time for changes, change failure rate, and time to restore service.

Design

12. Understand the users' entire experience. Create personas, customer journeys, service blueprints, problem space definitions, affinity maps, and flow diagrams (as appropriate) to ensure the digital service is cohesive with the offline experience.

13. Actively involve users in the design of digital solutions by incorporating best practices for design, user research, and usability testing.

14. Personalize solutions for the user by leveraging known information to create a seamless, tailored user experience.

15. Optimize for mobile-first and ensure all solutions are equally available on both mobile and desktop.

16. Follow all user interface design and content guidelines and standards defined in the

VA Design System and VA Content Style Guide (https://design.va.gov/) including the use of plain language to maintain a consistent look, feel, and voice across public facing sites and services.

17. Incorporate robust accessibility principles into design, development, and testing for all web applications to deliver high-quality digital experiences to all users that meet or exceed current W3C Web Content and Accessibility Guidelines (WCAG).

Engineering

18. Use widely adopted or industry-standard programming languages and frameworks.

19. Follow software development best practices including peer review, test coverage, portability, and clear documentation.

20. Run unit tests, integration tests, functional tests, load tests, and accessibility tests on

100% of functionality delivered.

21. Leverage cloud-based infrastructure, platforms, and services to improve scalability, reliability, performance, and maintainability.

22. Continuously integrate code from development teams, run automated testing, promote code through multiple environments, and automate high frequency deployments.

23. Monitor infrastructure health, application performance, and user outcomes. Ensure observability of the system/application/service status and leverage alerting integrations.

24. Maintain the confidentiality, integrity, and availability of sensitive information, including user information by following widely accepted or industry-standard methods, including Zero Trust security principles.

25. Ensure configuration and sensitive data, including data the VA defines as sensitive, are not present in source code.

https://design.va.gov/

26. Deliver all code not containing configuration or sensitive data to an open-source repository. Share your documentation, development processes, and lessons learned publicly.

27. Use established VA internal tools including source code management, team communication, developer toolkits, and analytics products.

28. Make use of existing platforms to build and deploy software, such as the VA.gov

Platform and Lighthouse Delivery Infrastructure, wherever possible.

29. Adopt and follow VA Application Programming Interface (API) standards contained in the Lighthouse Hub

(https://hub.lighthouse.va.gov/docs/default/component/lighthouse-api-standards/).

30. Make application data available for use across the VA enterprise with versioned

RESTful APIs and discoverability in the Lighthouse API hub

(https://hub.lighthouse.va/cataloghttps://developer.va.gov/ to meet Fast Healthcare

Interoperability Resources standards where applicable.

4.0 OBJECTIVES

4.1 PRODUCT VISION

Every product on VA.gov has clear ownership and is regularly reviewed for success against established product outcomes.

4.2 DESIRED USER OUTCOMES

Specific user outcomes vary by product. Iteration on existing products requires reassessing the current user needs.

4.3 DESIRED BUSINESS OUTCOMES

The Digital Experience team wants:

• Every active product listed in the VFS Product Directory with an owner and complete data.

• Identification of user experience and technical issues with current products which have not been reviewed in the past year.

• The ability to iterate on any product in the VFS Product Directory based on a backlog or new user and business generated issues.

• Capacity to implement changes that apply globally to all VFS products (such as design system updates) to products that do not have a current active product team assigned.

4.4 OUTCOMES WE WANT TO AVOID

The Digital Experience team wants to avoid:

• Additional bureaucracy, this team is not intended to serve in a coordination or leadership role across the existing VFS infrastructure, modify the VA.gov

Platform Governance, or increase administrative burden on existing teams.

• An IIR team with so many priorities that they cannot make a meaningful impact.

The scope of this issue is not fully clear, therefore the IIR team will need to help https://hub.lighthouse.va.gov/docs/default/component/lighthouse-api-standards/ https://hub.lighthouse.va/catalog identify the list of products and services that require an owner and prioritize which products require the most urgent iteration and which will require additional capacity or time to address.

4.5 POTENTIAL MINIMUM VIABLE PRODUCT FEATURES AND EPICS

Discovery on the VA.gov product ecosystem to establish owners of all products and identify the

“last update” date for these products. We need to know which products have not been measured for success against user outcomes in the past year and which require the most urgent iterations.

The following products and services do not have clear owners today and may be candidates for this team’s initial scope. This list is not exhaustive:

• Veteran Status Card

• VFS Product Directory

• Performance Dashboard

• New Account Onboarding Experience

5.0 PERFORMANCE DETAILS

The Contractor shall provide VA with 2-week iterations of agile software delivery. The agile delivery Iterations shall be supported by multi-disciplinary teams with appropriate skillsets to support the following services: product and delivery management, systems architecture/infrastructure, systems security, systems monitoring, software development, shared front-end and other code libraries, shared tooling, support services, user research, user experience strategy, information architecture, interaction and visual design, content writing, DevSecOps, data analytics, and platform operations and management.

Before each 2-week iteration, during iteration/sprint planning and continuously throughout the period of performance, the contractor shall propose a “definition of done” for the upcoming sprint which details the specific work items and deliverables to be completed during the sprint and shall gain approval on each “definition of done” from the Product Owner (PO) and

Contracting Officer’s Representative (COR) prior to the start of each sprint. The “definition of done” defined during sprint planning will be informed by a continuously prioritized backlog of work items towards the goals and outcomes listed in the PWS. The contractor’s invoice for that sprint will be certified when the definition of done has been approved by the PO and COR. Any item(s) that were initially included in the definition of done, but not delivered, must be discussed with the PO/COR to ensure their removal from the definition of done was appropriate and justified, prior to the invoice being certified.

Additional Information

SCRUM teams will be considered acceptable when they can effectively work. This may include some resources that are staffed, but not cleared. This will be case by case basis and worked out with the COR. For the initial team to be deemed ready to work, all members of the team will have a Personal Security Adjudication Center letter in order to obtain access to working tools such as GitHub and Slack that do not require VA network access. Access to Amazon Web

Services requires Electronic Questionnaires for Investigations Processing release date.

5.1 PERIOD OF PERFORMANCE (POP) AND BUDGET ESTIMATE

The Period of Performance (PoP) shall be one (1) 12-month Base Period.

In addition to Labor, the Government requires Other Direct Costs for the following software applications in use by the current IIR team:

• BigQuery. Based on current use of the BigQuery product for VA.gov the following estimates apply. Over the last 12 months, the average monthly cost was approximately $14,000 a month, the average for the last 3 months was approximately $18,000 a month. The Government estimates that this product will cost between $200,000 and $240,000 for the duration of this Pop. Transition

Support (Optional Task)

Transition of a product to a new contractor or the Government is sometimes necessary. It is critical to the continued functionality of OCTO products that all contractors are diligent in transitions between teams to ensure there is no disruption in Veteran services. The most important factors in these transitions are the availability of well written documentation and good faith communications. This optional task shall be for a period of up to four (4) 2-week sprints, if exercised by the Government and can be exercised any time during the contract period of performance. The Contractor must submit a Transition Support Package within (7) days upon optional task exercise. The Transition Support Package shall consist of at least the following, and is critical to the successful transition in OCTO, and must be available in the relevant GitHub repository:

1. All documentation

2. All access to the platform (if applicable) and anything interacting with the platform or application, for which the incoming vendor will require access

3. All relevant information necessary for Developer onboarding – interaction with 3rd party tools, downstream services, application interactions outside va.gov

In consult with the relevant OCTO PO and COR, the Contractor shall create a list of all relevant stakeholders both inside OCTO, across VA, and outside VA (if relevant). The contractor shall ensure frank and open communication between all staff of the exiting and incoming contractors.

At a minimum the outgoing contractor shall ensure the incoming contractor has access to the following:

1. Product documentation including product outlines/briefings, objectives and key results, roadmaps and active epics/stories, stakeholder landscape maps, decision records, and analytics

2. Developer documentation including READMEs, set-up instructions, diagrams, relevant databases and services.

3. Design documentation including prototypes, user research reports, design decisions for products in production, early designs for incomplete products, content strategy, and records of interactions with the collaboration cycle.

4. Access to accounts for third-party products such as tooling or SaaS products that will be taken over by the new team.

Although not exhaustive, the following are typical interactions which the contractor shall support during transition:

1. A handoff coordination meeting between the leads of the incoming and outgoing teams

2. Community of Practice specific orientations to the available documentation allowing the outgoing team to ask questions

3. Conversations about the stakeholder landscape and typical communication patterns

4. Demonstrations of specific functionality in the application

5. Any routine steps that the contractor currently performs to observe and maintain the health of a system (production or otherwise) must be documented and reviewed with the government.

Deliverable:

A. Transition Support Package

5.2 CONTRACT TYPE

The effort shall be proposed on a Firm-Fixed-Price basis.

5.3 KEY PERSONNEL

Product Manager – This contract requires an experienced product manager that is capable of taking several competing product backlogs, identifying the most pressing issues, establishing clear sprint goals, and shipping results every sprint.

Delivery Manager – Due to the volume of issues in the backlog for these many products, this contract requires an experienced delivery manager that can ensure product teams are delivering at the highest possible capacity each sprint. The nature of this work will often require team members to context switch between products, the delivery manager needs to minimize this burden and support the product manager to constantly be planning several sprints ahead.

5.4 KICKOFF MEETING

The Contractor shall hold a kickoff meeting within 10 days after the start of the period of performance. The Contractor shall present, for review and approval by the Government, at a minimum the details of the intended approach, work plan, and onboarding plan. The Contractor shall specify dates, provide a link to a Teams meeting as the meeting shall be held virtually, agenda

(shall be provided to all attendees at least five calendar days prior to the meeting), and meeting minutes (shall be provided to all attendees within three calendar days after the meeting). The

Contractor shall invite the Contracting Officer, Contract Specialist, COR and the VA Program

Manager/PO.

6.0 QUALITY ASSURANCE SURVEILLANCE PLAN (QASP)

6.0 PRODUCT SPECIFIC OBJECTIVES AND KEY RESULTS

The Government is open to discussion with the vendor about appropriate QASP metrics for this contract after award.

6.1 RECURRING DELIVERABLES

Delivery and Monitoring Report and Roster: The Contractor shall provide a single monthly report, detailing and providing links to all stories, epics and other work completed. This includes a plain language description of all work accepted by the Government PO and COR at the end of each sprint. This report shall include, in plain language, additional details about the project status, sprint team velocity, sprint team goal completion, and highlight project risks. The report shall also highlight and provide links to key infrastructure and application monitoring data. The report shall also include details with links to documentation for any critical incidents or outage events that resulted in service outages or significant service degradations. The Contractor shall attach or provide links to postmortem documentation for all critical incidents or outage events.

Should there not be any reported incidents during the reporting period, a link to the relevant monitoring tools is sufficient. The specific data points and format of this monthly report shall be determined by the Contractor in collaboration with the VA Program Manager/PO and COR.

Lastly, the Contractor shall submit a roster to the COR that includes the Status of Government

Furnished Equipment (GFE) for all GFE all staff, as applicable.

7.0 DATA AND OPEN SOURCE REQUIREMENTS

The Government shall receive Unlimited Rights to data first produced in performance of this contract in accordance with FAR 52.227-14, “Rights In Data-General” (MAY 2014). This includes all rights to source code and any and all documentation created in support thereof.

License rights in any Commercial Computer Software shall be governed by FAR 52.227-19, “Commercial Computer Software License” (DEC 2007). Any data delivered shall be submitted and protected in accordance with VA Handbook 6500.

VA intends that the software delivered under this contract will be publicly posted without restriction. To the extent that the Contractor(s) seeks to incorporate into the software delivered under this contract any software that was not first produced in the performance of this contract, VA encourages the Contractor(s) to incorporate either software that is in the public domain, or free and open source software that qualifies under the Open Source Definition promulgated by the Open Source Initiative. In any event, the Contractor(s) must promptly disclose to VA in writing, and list in the documentation, any software incorporated in the delivered software that is subject to a license fee.

8.0 OTHER ADMINISTRATIVE ITEMS

8.1 PLACE OF PERFORMANCE

Efforts under this task order can be performed at any location within the United States. All work locations must be able to accommodate the Hours of Work specified in Section 8.3.

8.2 TRAVEL

Travel is anticipated for this task order. The full Contractor team will be expected to travel one time within the 12-month PoP, within the continental United States, for an all-hands meeting. All travel costs shall be included in the Offeror’s firm-fixed-price.

8.3 HOURS OF WORK

The contractor shall set their own work hours. However, contractors may be required to attend meetings with Government personnel between standard east coast work hours (typically 9am –

5pm ET). In the event of a security incident or technical outage, the team may be expected to provide on-call support or additional working hours 24/7.

9.0 GENERAL REQUIREMENTS

9.0 ENTERPRISE AND IT FRAMEWORK

9.1 VA TECHNICAL REFERENCE MODEL

The Contractor shall support the VA enterprise management framework. In association with the framework, the Contractor shall comply with OIT Technical Reference Model (VA TRM). The

VA TRM is one component within the overall Enterprise Architecture (EA) that establishes a common vocabulary and structure for describing the information technology used to develop, operate, and maintain enterprise applications. Moreover, the VA TRM, which includes the

Standards Profile and Product List, serves as a technology roadmap and tool for supporting OIT.

Architecture & Engineering Services (AES) has overall responsibility for the VA TRM.

9.2 FEDERAL IDENTITY, CREDENTIAL, AND ACCESS MANAGEMENT (FICAM)

The Contractor shall ensure Commercial Off-The-Shelf (COTS) product(s), software configuration and customization, and/or new software are Personal Identity Verification (PIV) card-enabled by accepting HSPD-12 PIV credentials using VA Enterprise Technical Architecture

(ETA), https://www.ea.oit.va.gov/EAOIT/VA_EA/Enterprise_Technical_Architecture.asp, and

VA Identity and Access Management (IAM) approved enterprise design and integration patterns, https://www.oit.va.gov/library/recurring/edp/index.cfm. The Contractor shall ensure all

Contractor delivered applications and systems comply with the VA Identity, Credential, and

Access Management policies and guidelines set forth in VA Handbook 6510 VA Identity and

Access Management, VA Handbook 0735 Homeland Security Presidential Directive 12 (HSPD-

12) Program, and align with the Federal Identity, Credential, and Access Management Roadmap and Implementation Guidance v2.0.

The Contractor shall ensure all Contractor delivered applications and systems provide user authentication services compliant with the National Institute of Standards and Technology

(NIST) Special Publication (SP) 800-63-3, VA Handbook 6500 Appendix F, “VA System

Security Controls”, and VA IAM enterprise…