47QMCA23Q0019_SOW_2023-06-01.docx

General Services Administration

Statement of Work for

Electronic Maintenance and Repair Authorization System (EMRAS)

June 1, 2023

1 Background

The General Services Administration (GSA), Federal Acquisition Service (FAS), Office of Travel, Transportation, and Logistics (TTL), Office of Fleet Management (GSA Fleet) provides motor vehicle products and services to the Federal Government. Excellent service and professional conduct are the norm and customer service excellence is a minimum expectation.

The services listed in this Statement of Work pertain to the Leasing Support Division, Accident Management and Maintenance Control Branch, which operates at the GSA Headquarters Building in Washington, D.C., as well as centers in Atlanta, GA, Fort Worth, TX, Kansas City, MO, Lompoc, CA, and San Juan, PR. This division, through the actions of over 80 procurement specialists at the Accident Management Center (AMC) and Maintenance Control Center (MCC), oversees the maintenance and repair for all vehicles in the GSA leased fleet. GSA Fleet AMC and MCC specialists, on an annual basis, approve 240,000 repair purchase orders of which approximately 50% are completed over the phone and 50% are completed via our current EMRAS. However, this ratio will continue to shift towards a greater percentage of repair orders being processed via the EMRAS as additional vendors use the platform. Further, it is anticipated that another 50,000 transactions currently covered by GSA Fleet's Service Card may also be coverable by this system. GSA Fleet has a current vendor database of approximately 100,000 vendors. These vendors range from large national chains (e.g., Pep Boys, Jiffy Lube, and Goodyear) to small independent local repair and body shops.

2 Scope

The contractor shall provide a commercially available off-the-shelf electronic real-time maintenance and repair (M&R) authorization system that will enable GSA Fleet to manage all maintenance and repair orders processed through the MCC and AMC. The solution may take the form of a cloud-based Software-as-a-Service (SaaS) or other alternative delivery mechanism.

Understanding that technology is ever evolving, GSA Fleet leaves open the possibility that the solution may undergo future evolutions that add or remove functionality. To the extent that the basic functionality of the product - the electronic transfer of M&R information in order to effect an authorization decision of said repair - does not change, GSA Fleet hopes that future changes will only enhance the provision of service. GSA Fleet would entertain discussions on such changes should they occur.

3 Requirements

The system shall, at a minimum, provide the follow functionalities:

A. Allow the electronic transmission of M&R records between GSA Fleet and commercial repair vendors.

B. The system shall integrate with GSA Fleet's Fleet Management System (FMS) and crosswalk external vendor codes into GSA Fleet's existing code structure (to be provided during implementation). Additionally, as GSA Fleet adds, updates, or changes its FMS, additional integration work/programming may be necessary.

C. The system shall allow for GSA Fleet's existing vehicle inventory and maintenance history to be loaded so that a complete M&R history is available upon demand.

D. GSA Fleet's existing asset identifiers (vehicle tag number, VIN, etc.) will be an available field within the vendor system.

E. The system shall allow for single sign-on by users.

F. The system shall allow for differing levels of permission, to include:

1) Manager - user who can authorize other users and has full use of the system

2) Analyst - user who cannot authorize repairs, but can access the system for viewing and for reports

3) specialist - user who can view and authorize repair orders, but not authorize users G. The system shall allow for Maintenance Control Center (MCC) specialists to be grouped by skill type.

H. The system shall provide a clean, intuitive, and user-friendly interface for users.

I. The system shall present a main screen listing open repair orders, items of note, and a search functionality/capability for finding repair orders - current or archived/closed.

J. The system shall have a "quick pick" functionality for selecting common repair items when creating a repair order (RO).

K. The system shall allow for GSA Fleet specialists to accept/decline repair orders at the line-item level.

L. The system shall allow for GSA Fleet specialists to view the available maintenance history for a vehicle - in the repair order screen or through direct query/search.

M. The system shall allow for preventive maintenance schedules to be established/maintained by varying vehicle classes (e.g., sedans, light trucks - gas, light trucks - diesel, medium truck, refrigerator truck, hybrids/EVs, buses, ambulances, etc.).

N. The system shall capture wear measurements for repairs involving the replacement of tires and brakes. These measurements shall be visible/available to the specialist and retained in the repair record.

O. The system shall allow for "reason for repair" to be captured at the repair order level.

P. The system shall allow for FMC specific “cause code” request(s) to be added.

Q. The system shall capture vendor product codes (e.g., tire brand/model, battery brand/model).

R. The system shall provide vehicle schematics at the component level.

S. The system shall allow for notes/comments to be entered by the specialist at a repair order level. These notes shall be visible to GSA Fleet specialists and, at the specialist's discretion, be able to be made available to the vendor.

T. The system shall allow for vehicle warranty information to be maintained.

U. Specialists shall be able to flag RO line items for possible coverage under warranty.

V. The system shall include a post-warranty capability.

W. The system shall allow ROs to be edited, amended, or corrected prior to payment.

X. The system shall maintain an audit trail of all actions and communication between GSA Fleet and the vendor for every M&R transaction recorded by the system. This data shall be maintained for a minimum of 75 months.

Y. The system shall allow for automated approvals of repair items at thresholds set, and managed, by GSA Fleet.

Z. The system shall integrate with commercially available price guides (e.g., Mitchells, All-Data, etc.).

AA. For each repair, the system shall provide real-time aggregated (cross-account) pricing information based on historical transactions.

AB. The system shall be capable of providing reports (scheduled and/or ad hoc). All daily and weekly reports shall also be aggregated to at least a monthly report to allow for analysis over longer timeframes. These reports include but are not limited to:

1) RO by shop type (national vs independent/local)

2) RO # by month

3) # of vendors registered but still calling (i.e., not using the system)

4) ROs created by shop type

5) Downtime

6) Shop created RO response time - how long we take to get a response back to the shop

7) Shop-created rejection %

8) Auto-approval by vendors

9) Auto-approval detailed analysis

10) Total auto-approvals

11) Vehicle fleet breakout, by make, then by model, model year, actual repair, spend

12) Open repair status - count

13) Regional pricing data (labor and parts)

14) Live RO status monitor - a report on ROs by current status

15) Top independent shops - numbers, savings in cost and time

16) Top national shops - numbers, savings in cost and time

17) Total savings AC. The offeror shall provide a listing of their current (as of response submittal) vendor network, to include corporate (business) name, number of locations, and type of integration (vendor Point-of-Sale or double entry keying).

AD. The offeror shall identify for which, if any, of their vendors does the system contain the vendor's sales catalog (of items, services, prices).

AE. The system shall allow for repair orders to be added/created by specialists in response to repairs phoned in (external to the system).

AF. The system shall allow for new vendors to be added/created by specialists in response to repairs phoned in (external to the system).

AG. The system shall be able to display all vendors existing within GSA Fleet's vendor database.

AH. The system shall possess a search function by which vendors can be researched.

AI. The offeror shall describe the process by which new vendors may be added to their network and made participating vendors in their system.

AJ. The system shall allow for the integration with GSA Fleet's fleet card provider payment information. The system shall NOT capture nor retain payment information.

AK. The system shall NOT retain personally identifiable information (PII) aside from that information provided by the vendor as the POC for the repair order.

AL. The system shall allow for integration of the incoming RO tickets into GSA Fleet's call/workflow (ACD) system.

4. Automated Data Transfer and Information Technology Security

GSA requires the vendor to have an established web service to accommodate an automated data exchange. The vendor must provide a Web service that is either SOAP based or RESTFul service, independent of platform, and with a loosely coupled software component designed to support interoperable machine-to-machine interaction over a network interacting with the Web service in a manner prescribed by means of JSON or XML-based messages conveyed using Internet transport protocols in conjunction with other Web-related standards. The vendor must allow for HTTPS, TLS > 1.1 and SSL security certificates for data encryption purposes. Vendor must provide GSA a Web Services Description Language (WSDL) specification that provides a framework for describing a Web service with HTTPS basic authentication specific to GSA (e.g., a user id and password). Each operation specifies the types of messages that the service can send or receive as part of that operation including specification for a message exchange pattern that indicates the sequence in which the associated messages are transmitted between the parties. Upon selection, the vendor must adhere to service level agreements between GSA on performance or response time.

The system shall comply with all applicable GSA and U.S. Government IT Security requirements as described in the following sections.

5. IT Security and Privacy Requirements

The U.S. General Services Administration (GSA) must provide information security for the information systems that support the operations and assets of the agency, including those provided or managed by GSA, another agency, contractor, or other source. The Federal Information Security Modernization Act of 2014 (FISMA of 2014) describes Federal agency security and privacy responsibilities as including "information systems used or operated by an agency or by a contractor of an agency or other organization on behalf of an agency." This includes services which are either fully or partially provided, including other agency hosted, outsourced, and cloud computing solutions. Agency information security programs apply to all organizations (sources) which possess or use Federal information - or which operate, use, or have access to Federal information systems (whether automated or manual) - on behalf of a federal agency, information systems used or operated by an agency or other organization on behalf of an agency.

Office of Management and Budget (OMB) Memorandum M-14-04 asserts that agencies are responsible for ensuring information technology acquisitions comply with the information technology security requirements in FISMA of 2014, OMB's implementing policies including OMB Circular A-130 and guidance and standards from the National Institute of Standards and Technology (NIST).

The offeror shall provide an indication of their willingness to, ability to, and experience with, obtaining a GSA IT Security Low Impact Software as a Service (LiSaaS) certification (for a SaaS or other cloud-based solution). This is an ANNUAL certification requirement undertaken by GSA IT Security. The offeror agrees to collaborate with GSA IT Security to facilitate this annual examination. This authorization is in lieu of the FedRAMP Tailored LiSaaS program - although a FedRAMP Tailored LiSaaS authorization would be an acceptable substitute for the GSA IT Security LiSaaS authorization at any time. Should, at some time forward, GSA's LiSaaS process be discontinued, GSA will notify the awarded vendor of said discontinuation and the offeror understands and agrees that they will move to a FedRAMP Tailored LiSaaS authorization within one year. If at any time, the vendor is either unwilling or unable to meet any of the process requirements, GSA may choose to cancel the contract and terminate any outstanding orders.

5.1 Low Impact Software as a Service (LiSaaS) – IT Security and Privacy Requirements

To be considered for the award, the contractor must comply with GSA IT's Low-Impact SaaS (LiSaaS) review. The successful vendor will need to ensure any software-as-a-service provided under this contract meets GSA security and privacy requirements prior to invoicing the government for services received under this contract. This includes working with GSA to ensure the Software-as-a-Service (SaaS) passes the current Low-impact-software-as-a- service (LiSaaS) approval process, as outlined in GSA IT Security Procedural Guide 16-75, Rev 5“Security Reviews for Low Impact Software as a Service (SaaS) Solutions” The review process is made up of two main parts: Voluntary Product Accessibility Template (VPAT) for 508 accessibility and security scanning/process reviews. These reviews are detailed in Section 3 of the aforementioned GSA IT Security Procedural Guide 16-75, Rev 5“Security Reviews for Low Impact Software as a Service (SaaS) Solutions” which is provided as a supplement to this SOW.

5.2 Assessment of the System

Maintenance of the security authorization to operate will be through continuous monitoring of security controls of the contractor’s system and its environment of operation to determine if the security controls in the information system continue to be effective over time in light of changes that occur in the system and environment. Through continuous monitoring, security controls and supporting deliverables are updated and submitted to GSA per the schedules below. The submitted deliverables (or lack thereof) provide a current understanding of the security state and risk posture of the information systems. They allow GSA Authorizing Officials (AOs) to make credible risk-based decisions regarding the continued operations of the information systems and initiate appropriate responses as needed when changes occur.

The contractor shall provide evidence in support of meeting the requirements for the review activities stated in GSA IT Security Procedural Guide 16-75 and as listed below.

A. Unique IDs for each person using the SaaS. Two factor authentication should be used.

B. System and security parameters deferred to customers, default settings must be changed.

C. Encryption of authentication credentials during transmission.

D. Results of web application vulnerability scans.

E. Results of operating system vulnerability scans.

F. Vendor's flaw remediation process.

G. Results of one of the following audits/certifications:

1) Service Organization Control (SOC) 2/Statements on Standards for Attestation Engagements (SSAE) 18

2) SysTrust/WebTrust

3) ISO/IEC 27001

4) Payment Card Industry Data Security Standard (PCI DSS)

5.3 Authorization of the System

The LiSaaS ATO will be valid for no longer than one (1) year. The vendor agrees to undergo the LiSaaS ATO process annually. If at any time, the vendor is either unwilling or unable to meet any of the process requirements, GSA may choose to cancel the contract and terminate any outstanding orders.

5.4 Reporting and Continuous Monitoring

In support of continuous monitoring the vendor shall maintain its audit report/certification, perform web application and operating system scans, and remediate flaws per the vendor's flaw remediation process. The vendor shall report if its audit report/certification renews or expires and if any of the other required activities cannot be supported.

5.5 Protection of Information

The contractor shall be responsible for properly protecting all information used, gathered, disclosed, or developed as a result of work under this contract. The contractor shall also protect all Government data, etc. by treating the information as sensitive. All information gathered or created under this contract should be considered as confidential information. It is anticipated that this information will be gathered, created and stored within the primary work location. If contractor personnel must remove any information from the primary work area, they should protect it to the same extent they would their proprietary data and/or company trade secrets. The use of any information that is subject to the Privacy Act will be utilized in full accordance with all rules of conduct as applicable to Privacy Act Information. Personnel shall adhere to the Privacy Act, Title 5 of the U. S. Code, Section 552a and applicable agency rules and regulations.

5.6 Data Ownership and Unrestricted Rights to Data

All Government data collected in the system is the property of the Federal Government. The Government will retain unrestricted rights to government data. The ordering activity retains all data collected by the system shall be provided by the contractor (system provider) as requested during the contract period and at the completion of the contract period.

Government data rights of software deliverables shall be in accordance with FAR 52. 227-19 Commercial Computer Software License and/or FAR 52. 227-14 Rights in Data - General. Ownership of data entered into any and all systems, system documentation, all deliverables produced in the performance of this contract, and other related system information shall reside with the Government.

The contractor shall place the following copyright notice on all materials, documents, deliverables, etc., developed during the performance of this contract:

For purposes of clarity, the intent of the government is for intellectual property to be vested in the federal government for work paid for by the federal government. All documents, graphics, and code created under this contract are the intellectual property of the federal government including, but not limited to, plans, reports, schedules, software code, software designs, graphics, etc. If the federal government implements under this contract open-source software and pays for the cost of the implementation of open-source software, the final changes and edits to the code and configuration (such as work to integrate plug-ins) are the intellectual property of the federal government.

5.7 Personally Identifiable Information

Personally identifiable information (PII) data is not in the scope of the acquisition and PII data is not expected to be stored in the vendor's SaaS solution. The contractor shall prepare a Privacy Threshold Analysis (PTA) to either document PII is not in scope, or determine which categories of information will be stored, processed, or transmitted by the system. The use of any information that is subject to the Privacy Act will be utilized in full accordance with all rules of conduct as applicable to Privacy Act Information.

Privacy data (should it come into scope) will require that the vendor's SaaS solution be FedRAMP authorized at least at the FIPS PUB 199 Moderate level.

5.8 Data Availability

The data must be available to the Government upon request within one business day or within the timeframe negotiated with the contractor and shall not be used for any other purpose other than that specified herein. The contractor shall provide requested data at no additional cost to the government.

5.9 Data Release

The contractor shall not disclose Customer Data to any government or third party or access or use Customer Data; except in each case as necessary to maintain the SaaS solution or to provide the SaaS solution to Customer in accordance with this contract, or as necessary to comply with the law or a valid and binding order of a governmental or regulatory body (such as a subpoena or court order). Unless it would be in violation of a court order or other legal requirement, the contractor will give the Government reasonable notice of any such legal requirement or order, to allow the Government to seek a protective order or other appropriate remedy.

5.10 Confidentiality and Nondisclosure

Personnel (contractor/subcontractor employee) working on any of the described tasks may, at Government request, be required to sign formal non-disclosure and/or conflict of interest agreements to guarantee the protection and integrity of Government information and documents. The contractor shall submit to the CS or COR a completed confidentiality and non- disclosure agreement form for each individual contractor/subcontractor.

Additionally, any information made available to the contractor by the Government shall be used only for the purpose of carrying out the provisions of this contract and shall not be divulged or made known in any manner to any persons except as may be necessary in the performance of the contract. In performance of this contract, the contractor assumes responsibility for protection of the confidentiality of Government records and shall ensure that all work performed by its subcontractors shall be under the supervision of the contractor or the contractor's responsible employees. Each officer or employee of the contractor, or any of its subcontractors to whom any Government record may be made available or disclosed shall be notified in writing by the contractor that information disclosed to such officer or employee can be used only for that purpose and to the extent authorized herein. Further disclosure of any such information, by any means, for a purpose or to an extent unauthorized herein, may subject the offender to criminal sanctions imposed by 18 U. S. C. §§ 1030.

5.11 Section 508 Compliance

Section 508 of the Rehabilitation Act, as amended by the Workforce Investment Act of 1998 (P.L. 105-220) requires that when Federal agencies develop, procure, maintain, or use information and communication technology (ICT), it shall be accessible to people with disabilities. Federal employees and members of the public who have disabilities must have access to, and use of, information and data that is comparable to people without disabilities.

Products, platforms and services delivered as part of this statement of work that are ICT, or contain ICT, must conform to the Revised 508 Standards, which are located at 36 C.F.R. § 1194.1 & Apps. A, C & D, and available at https://www.access-board.gov/ict/. For additional information see NASA’s publication Demystifying Section 508.

Applicable Section 508 ICT standards:

E205.1 General Electronic content shall comply with E205.

E205.2 Public Facing Electronic content that is public facing shall conform to the accessibility requirements specified in E205.4.

E205.3 Agency Official Communication Electronic content that is not public facing shall conform to the accessibility requirements specified in E205.4 when such content constitutes official business and is communicated by an agency through one or more of the following:

A. An emergency notification;

B. An initial or final decision adjudicating an administrative claim or proceeding;

C. An internal or external program or policy announcement;

D. A notice of benefits, program eligibility, employment opportunity, or personnel action;

E. A formal acknowledgement of receipt;

F. A survey questionnaire;

G. A template or form;

H. Educational or training materials; or I. Intranet content designed as a Web page.

E205.4 Accessibility Standard (WCAG 2.0) - Electronic content shall conform to Level A and Level AA Success Criteria and Conformance Requirements in WCAG 2.0 (Incorporated by reference, see 702.10.1).

E206.1 General. Where components of ICT are hardware and transmit information or have a user interface, such components shall conform to the requirements in Chapter 4.

E207.1 General Where components of ICT are software and transmit information or have a user interface, such components shall conform to E207 and the requirements in Chapter 5 Exception from E207.1 General: Software that is assistive technology and that supports the accessibility services of the platform shall not be required to conform to the requirements in Chapter 5.

E207.2 WCAG Conformance User interface components, as well as the content of platforms and applications, shall conform to Level A and Level AA Success Criteria and Conformance Requirements in WCAG 2.0 (incorporated by reference, see 702.10.1).

Exceptions from E207.2 WCAG Conformance:

· Software that is assistive technology and that supports the accessibility services of the platform shall not be required to conform to E207.2.

· Non-web software shall not be required to conform to the following four Success Criteria in WCAG 2.0: 2.4.1 Bypass Blocks; 2.4.5 Multiple Ways; 3.2.3 Consistent Navigation; and 3.2.4 Consistent Identification.

· Non-Web software shall not be required to conform to Conformance Requirement 3 Complete Processes in WCAG 2.0.

E207.3 Complete Process for Non-Web Software Where non-Web software requires multiple steps to accomplish an activity, all software related to the activity to be accomplished shall conform to WCAG 2.0 as specified in E207.2.

E208.1 General Where an agency provides support documentation or services for ICT, such documentation and services shall conform to the requirements in Chapter 6.

503.1 General Applications shall conform to 503.

503.2 User Preferences Applications shall permit user preferences from platform settings for color, contrast, font type, font size, and focus cursor.

Exception from E503.2 User Preferences: Applications that are designed to be isolated from their underlying platform software, including Web applications, shall not be required to conform to 503.2.

503.3 Alternative User Interfaces. Where an application provides an alternative user interface that functions as assistive technology, the application shall use platform and other industry standard accessibility services.

503.4 User Controls for Captions and Audio Description Where ICT displays video with synchronized audio, ICT shall provide user controls for closed captions and audio descriptions conforming to 503.4.

503.4.1 Caption Controls Where user controls are provided for volume adjustment, ICT shall provide user controls for the selection of captions at the same menu level as the user controls for volume or program selection.

503.4.2 Audio Description Controls. Where user controls are provided for program selection, ICT shall provide user controls for the selection of audio descriptions at the same menu level as the user controls for volume or program selection.

504.2 Content Creation or Editing Authoring tools shall provide a mode of operation to create or edit content that conforms to Level A and Level AA Success Criteria and Conformance Requirements in WCAG 2.0 (incorporated by reference, see 702.10.1) for all supported features and, as applicable, to file formats supported by the authoring tool. Authoring tools shall permit authors the option of overriding information required for accessibility.

504.2.1 Preservation of Information Provided for Accessibility in Format Conversion. Authoring tools shall, when converting content from one format to another or saving content in multiple formats, preserve the information required for accessibility to the extent that the information is supported by the destination format.

504.2.2 PDF Export. Authoring tools capable of exporting PDF files that conform to ISO 32000-1:2008 (PDF 1.7) shall also be capable of exporting PDF files that conform to ANSI/AIIM/ISO 14289-1:2016 (PDF/UA-1) (incorporated by reference, see 702.3.1).

504.3 Prompts. Authoring tools shall provide a mode of operation that prompts authors to create content that conforms to Level A and Level AA Success Criteria and Conformance Requirements in WCAG 2.0 (incorporated by reference, see 702.10.1) for supported features and, as applicable, to file formats supported by the authoring tool.

504.4 Templates. Where templates are provided, templates allowing content creation that conforms to Level A and Level AA Success Criteria and Conformance Requirements in WCAG 2.0 (incorporated by reference, see 702.10.1) shall be provided for a range of template uses for supported features and, as applicable, to file formats supported by the authoring tool.

602.1 General. Documentation that supports the use of ICT shall conform to 602.

603.1 General. ICT support services including, but not limited to, help desks, call centers, training services, and automated self-service technical support, shall conform to 603.

Applicable Functional Performance Criteria: All functional performance criteria apply when using an alternative design or technology that achieves substantially equivalent or greater accessibility and usability by individuals with disabilities, than would be provided by conformance to one or more of the requirements in Chapters 4-6 of the Revised 508 Standards, or when Chapters 4-6 do not address one or more functions of ICT.

Applicable requirements for software features and components: All WCAG Level AA Success Criteria, 502 Interoperability with Assistive Technology, 503 Application.

Application Applicable requirements for hardware features and components: All requirements apply.

Applicable support services and documentation: All requirements apply.

5.12 Additional Stipulations

A. Deliverables shall be labeled Sensitive but Unclassified (SBU) or contractor selected designation per document sensitivity. External transmission/dissemination of SBU to or from a Government computer must be encrypted. Certified encryption modules must be used in accordance with FIPS PUB 140-2, "Security Requirements for Cryptographic Modules."

B. The contractor shall cooperate in good faith in defining non-disclosure agreements that other third parties must sign when acting as the Federal government's agent.

C. The Government has the right to perform manual or automated audits, scans, reviews, or other inspections of the vendor's IT environment being used to provide or facilitate services for the Government. The contractor shall be responsible for the following privacy and security safeguards:

1) To the extent required to carry out a program of inspection to safeguard against threats and hazards to the security, integrity, and confidentiality of Government data, the contractor shall afford the Government access to the contractor's facilities, installations, technical capabilities, operations, documentation, records, and databases within 72 hours of the request. Access to support incident investigations, shall be provided as soon as possible but not longer than 72 hours after request.

2) Physical Access Considerations - If the SaaS provider is operated within an IaaS that is FedRAMP authorized (e. g., AWS); physical access to the physical datacenter environment will be governed by the terms of access allowed by the underlying infrastructure provider as defined in the FedRAMP A&A authorization package.

3) The program of inspection shall include, but is not limited to:

4) Authenticated and unauthenticated operating system/network vulnerability scans

5) Authenticated and unauthenticated web application vulnerability scans

6) Authenticated and unauthenticated database application vulnerability scans

7) Automated scans can be performed by Government personnel, or agents acting on behalf of the Government, using Government operated equipment, and Government specified tools. If the vendor chooses to run its own automated scans or audits, results from these scans may at the Government's discretion, be accepted in lieu of Government performed vulnerability scans. In these cases, scanning tools and their configuration shall be approved by the Government. In addition, the results of vendor-conducted scans shall be provided in full to the Government.

8) If new or unanticipated threats or hazards are discovered by either the Government or the contractor, or if existing safeguards have ceased to function, the discoverer shall immediately bring the situation to the attention of the other party.

D. The contractor shall comply with Section 1634 of Public Law 115-91 that prohibits use of any hardware, software, or services developed or provided, in whole or in part, by-

1) Kaspersky Lab (or any successor entity);

2) any entity that controls, is controlled by, or is under common control with Kaspersky Lab; or

3) any entity of which Kaspersky Lab has majority ownership.

5.13 Terms of Service (ToS)

Many terms found in commercial ToS or End User License Agreements (EULA) are not acceptable when the Government is the end user. The Office of Chief Information Officer (OCIO) requires that software and services within the GSA Enterprise have approved ToS or EULA.

The contractor's SaaS will undergo a formal review by GSA as part of the review/approval process. The contractor's ToS shall be found to be acceptable to the government or a modified ToS negotiated as part of the approval review, prior to final authorization.

5.14 References

GSA IT Security Procedural Guide 16-75, Rev 5“Security Reviews for Low Impact Software as a Service (SaaS) Solutions” FIPS PUB 199, “Standards for Security Categorization of Federal Information and Information Systems” Guide to Understanding FedRAMP GSA InSite

6.0 Invoice And Payment Information

The Contractor must obtain a GSA OCIO granting Authority to Operate under this contract prior to invoicing the government for services received.

The Contractor may invoice for items or services upon their delivery. Billing and payment must be accomplished in accordance with the contract/order terms and GSA payment procedures.

Initially, the Contractor must submit a copy of each invoice to the following individuals for review and approval. This review will ensure that the invoice is compliant with the terms of the contract and that the goods or services listed on the invoice have been received and accepted.

· TBD, Contracting Officer’s Representative (COR)

· Charlene Cardenas, Contracting Officer (CO), charlene.cardenas@gsa.gov

· Leresa Garrett, Contract Specialist (CS), leresa.garrett@gsa.gov Following review of each invoice, the CS or COR will notify the Contractor that the invoice is (1) approved for payment or (2) requires correction.

Once approved, either initially or following corrections, the Contractor must submit the invoice to the GSA Finance Office through the Department of Treasury’s, Invoice Processing Platform (IPP) web portal, https://ipp.for.fiscal.treasury.gov/ and then click on “Collector (Supplier)”.

The funding reference to use when submitting invoices in IPP is the Procurement Instrument Identifier (PIID) located in block 4 of the SF1449.

Once invoices are submitted by the Contractor, the government will make payment after verification that the goods or services listed on the invoice have been received and accepted.

If you have problems submitting your invoice in IPP, please contact one of the following, as applicable.

IPP General System, Login ID, password issues:

IPP Customer Support Helpdesk Ph: (866) 973-3131 email: IPPCustomerSupport@fiscal.treasury.gov

IPP Inquiries with payment issues:

Email: kc-gpitprograms@gsa.gov Contractor Performance Assessment Reporting During the period of performance of the contract. Contractor performance will be evaluated on an interim and final basis pursuant to FAR Subpart 42.15. The Contractor Performance Assessment Reporting System (CPARS) will be utilized for these reviews. Information on CPARS can be located at http://www.cpars.gov.