A1.03_Sources_Sought_Attach1_IDIQ_PWS_3Oct22.pdf

Indefinite Delivery/Indefinite Quantity (IDIQ) Contract Performance Work Statement (PWS) Disgorgement and Penalty System (DPS) Support

Table of Contents

1.0 GENERAL INFORMATION

1.1 Scope of Work

1.2 Background

2.0 GENERAL SUPPORT REQUIREMENTS

2.1 Project Management

2.1.1 Contractor Project Manager

2.1.2 Project Management Plan (PMP)

2.1.3 System Development Plan (SDP)

2.1.4 Project Work Breakdown Structure (WBS) and Schedule

2.1.5 Requirements Traceability Matrix (RTM)

2.1.6 Configuration Management (CM) Plan

2.1.7 Training Management Plan (TMP)

2.1.8 Project Status Reporting

2.1.9 Project Meetings

2.2 Contractor Key Personnel

2.2.1 Project Manager

2.2.2 Technical Lead Subject Matter Expert (SME)

2.2.3 Functional Lead

2.3 Systems Integration, Configuration, and Development

2.3.1 Notifications

2.3.2 Interfaces

2.4 Transition Support

3 ENVIRONMENTAL SUPPORT REQUIREMENTS

3.1 External Hosting

3.1.1 Environments

3.2 Development, Modernization, and Enhancements (DME) Support

3.2.1 Cloud Migration Support

3.3 Operations and Maintenance (O&M) Support

3.3.1 Help Desk Support

3.3.2 Response Time

3.3.3 Problem Escalation

3.3.4 Service Level Agreement

3.3.5 Scheduled Downtime

3.4 System Failure

3.5 Project Related Documents

4 DELIVERABLES

4.1 Marking

4.2 Place of Delivery – FOB Destination

4.3 Inspection and Acceptance

4.4 Schedule of Deliverables

5 SYSTEM PERFORMANCE STANDARDS

5.1 Procedures for Addressing Performance Issues

6 GOVERNMENT FURNISHED

7 ELECTRONIC AND INFORMATION TECHNOLOGY ACCESSIBILITY

7.1 Electronic and Information Technology Accessibility

1.0 GENERAL INFORMATION

1.1 SCOPE OF WORK

The Securities and Exchange Commission (SEC) requires hosting; Development, Modernization, and Enhancement (DME); Operations and Maintenance (O&M); and cloud migration support for the Disgorgement and Penalty System (DPS) to meet the required outcomes of ensuring the solution is stable, available, accessible, reliable, and high-performing. This support includes all component software and interfaces that comprise the DPS solution (e.g., Momentum, OpenText, and Pentaho) as a whole.

This PWS defines the scope of work for the ID/IQ contract. Each order under the ID/IQ contract will include a PWS, describing the actual work to be accomplished under the order.

1.2 BACKGROUND

The DPS solution was deployed in February 2020 to replace legacy systems and support the recording and tracking of disgorgements, penalties, and interest. DPS is hosted in CGI Federal, Inc.’s Federal Risk and Authorization Management Program (FedRAMP) certified Infrastructure-as-a-Service (IaaS) cloud at the CGI Phoenix Data Center (PDC). Currently, CGI provides infrastructure operations and application maintenance and support to manage the DPS solution.

DPS is mainly comprised of Momentum, a Commercial Off-the-Shelf (COTS) software product, and its document management solution, OpenText Content Server (OTCS). Momentum is a web-based system, developed using object-oriented design methodologies and development techniques. Momentum provides comprehensive federal financial management capabilities, document and records management, and an automated workflow engine. Momentum also features a scalable, system integration platform based on industry standards. OTCS is a document management solution that provides the foundational repository and information governance backbone for DPS. Within DPS, the Business Intelligence Reporting Tool (BIRT) is used to support built-in reports and the Pentaho Business Intelligence Server is used for ad hoc reporting.

DPS employs tablespace level encryption using Oracle Key Vaults (OKV) and Hardware Security Modules (HSM). The Oracle databases in all DPS production, non-production, and disaster recovery environments are encrypted at the tablespace level using the Transparent Data Encryption (TDE) available in Oracle 12.2.0.1 Enterprise Edition with the Oracle Advance Security feature. The TDE was set up using OKV and HSM to store the TDE Master Encryption Key.

Significant DPS interfaces are listed below:

Table 1-1: Significant DPS Interfaces

Name Source Brief Description

CourtLink LexisNexis

LexisNexis provides a daily Comma-Separated Values (CSV) file and associated Portable Document Format (PDF) documents for docket activity relating to civil court cases tracked by the

SEC.

Administrative Proceeding (AP) Drive SEC AP PDF documents are transferred from the SEC’s

AP shared folder location on a daily basis.

Hub SEC

Daily CSV file from SEC’s Hub application containing information for all debtors and case records. Used to update debtor and case (e.g., Action and Budget Program Activity Code (BPAC) numbers) information in DPS.

Cross-Servicing Next Generation (CSNG) Collection Report Treasury Weekly file detailing collections against SEC debts referred to Treasury’s Cross-Servicing program.

Treasury Offset Program (TOP)

Collection Report Treasury Weekly file detailing collections against SEC debts referred to TOP.

Collections Information Repository (CIR) Collections Treasury

Downloads files daily from Treasury for collections obtained via the Fedwire, OTC.net, and Pay.gov payment channels.

Weekly Civil Interest Rates

Federal Reserve Board

(FRB)

Interest rate updates for civil court judgments are obtained weekly from FRB’s website.

General Ledger and BPAC File Transfer to Department of Transportation’s (DOT)

Enterprise Service Center (ESC)

DPS

Daily transfer of DPS general ledger transactions and new BPAC activity to the DOT-ESC for loading into Delphi.

Treasury Referrals DPS Ad-hoc transfers of debt information to Treasury’s CSNG and TOP programs.

Delphi Reconciliation ESC – Delphi

Daily transfer of Delphi posting information to facilitate the reconciliation of Delphi activity to related DPS postings.

2.0 GENERAL SUPPORT REQUIREMENTS

2.1 PROJECT MANAGEMENT

The Contractor shall provide effective management and oversight of each of the following areas:

• Project Integration Management;

• Project Scope Management;

• Project Time Management;

• Project Quality Management;

• Project Human Resource/Project Team Management;

• Project Communications Management;

• Project Risk Management;

• ID/IQ Contract Management;

• Project Stakeholders Management;

• System Development Lifecycle (SDLC) Execution and Management;

• SEC System Development Framework (SDF) Document Management;

• System Configuration Management; and

• Transition Support.

2.1.1 Contractor Project Manager

The Contractor shall coordinate with the Contracting Officer’s Representative (COR) to provide regular project plan and schedule updates. The Contractor’s Project Manager shall be the Government’s primary point of contact, manage the day-to-day aspects of the project, and provide regular and appropriate updates to the COR.

2.1.2 Project Management Plan (PMP)

The Contractor shall develop, maintain, and execute a PMP. The PMP shall include, at a minimum, the following:

• The best practice project management methodologies the Contractor will use for managing project scope, schedule, quality, communications, risk and issues, and staffing/resources (including subcontractor management, if applicable);

• A risk and issue management plan with procedures/mechanisms for risk and issue identification, analysis, and mitigation/monitoring;

• A communications plan with procedures/mechanisms for stakeholder identification and engagement; and

• A Quality Control Plan (QCP) with procedures aligned with project requirements and performance expectations.

2.1.3 System Development Plan (SDP)

The Contractor shall develop, maintain, and execute a System Development Plan (SDP) in accordance with SEC Instruction (SECI) 6013.01(m), Federal Requirements, Security, and Accessibility for Information Systems.

2.1.4 Project Work Breakdown Structure (WBS) and Schedule

The Contractor shall develop, maintain, and execute a Project WBS and Schedule. The Project WBS and Schedule shall be task and functionality driven and shall include, at a minimum, the following:

• 100% of the estimated work-packages defined by the project scope and estimated for satisfying the requirements;

• A level of detail that clearly conveys the extent of the project work, is measureable, and clearly assigns responsibility for delivery of requirements, features, work-packages, and deliverables;

• Task names, activity descriptions, start dates, completion dates, supporting documentation, and resource names; and

• The SEC’s Office of Information Technology (OIT) SDLC phases.

The Contractor shall ensure that the timelines specified in the Project WBS and Schedule are appropriate for the size and scope of project; resources are adequately assigned; and all appropriate milestone and checkpoints are included.

2.1.5 Requirements Traceability Matrix (RTM)

The Contractor shall incorporate updates to an approved RTM, to include embedded or linked documentation for all design plans, test cases, and evaluation criteria for all functional and non-functional requirements listed in the approved RTM.

2.1.6 Configuration Management (CM) Plan

The Contractor shall:

• Develop, maintain, and execute a CM plan aligned with SEC policy and relevant federal requirements;

• Adhere to the approved CM plan in the management of the DPS design, development, testing, and implementation effort. In doing so, the Contractor shall perform each task in full compliance with the SEC’s CM/quality assurance processes and procedures. If there is a conflict between the approved CM plan and the SEC published standards, the standards take precedence. If the Contractor becomes aware of any deviations from the approved CM plan, the Contractor shall immediately notify the COR;

• Ensure that DPS work products and deliverables are controlled in accordance with all applicable SEC standards and the approved CM plan;

• Identify and manage the software product baseline, as well as project plans, throughout the full project lifecycle;

• Coordinate with the COR to identify the configuration items and other project materials to be controlled;

• Establish and maintain CM libraries, including the tracking of baselined versions of all deliverables;

• Provide access to items in the project libraries;

• Use established SEC tools and processes as a means for tracking problems, changes, builds, and other CM information;

• Electronically copy selected items from the Contractor’s CM libraries to an SEC-managed CM repository upon SEC request; and

• Support Functional Configuration Audits (FCA) and Physical Configuration Audits

(PCA) performed by the SEC’s OIT.

2.1.7 Training Management Plan (TMP)

The Contractor shall develop, maintain, and execute a TMP. The Contractor shall provide training as requested or when new functionality is introduced. The TMP shall:

• Detail how all project training requirements will be met by outlining the strategy, objectives, curriculum, and methodology to be used to deliver training, in support of, and as a deliverable for, the project; and

• Provide a roadmap of the activities required to support the development of training materials, coordination of training schedules, reservation of personnel and facilities, planning for training events, and other training-related tasks.

2.1.8 Project Status Reporting

2.1.8.1 Weekly Status Reports

The Contractor shall prepare and deliver weekly status reports that include tasks accomplished, tasks planned for the following week, issues, risks and a mitigation plan. The weekly status report shall include current funding remaining and expensed.

2.1.8.2 Monthly Status Reports

The Contractor shall prepare and deliver monthly status reports no later than the fifth business day of each month. The report shall include the following:

• Each System Change Request (SCR) that was closed for that reporting period;

• Fixes that went into production for the reporting period (including SCRs);

• Overview of financial information for the reporting period, including current funding remaining and expensed;

• Any issues that occurred or concerns identified during the reporting period;

• Tasks to be performed in the next reporting period;

• Deliverable completion status, to include a list of deliverables completed during the reporting period;

• Documents that were developed/created during the reporting period; and

• Updated Requirement Check List (RCL) to track the progress.

2.1.8.3 Requests for Information

The Contractor shall respond to requests for information from the COR, and record work performed in SEC tracking systems as designated by the COR.

2.1.8.4 Briefings

The Contractor shall prepare and deliver quarterly briefings that:

• Cover key project accomplishments, including milestones met and status of deliverables;

• Address matters that are essential to ensure overall success of the project including project status, project schedule, and an analysis of the risks that may affect successful project completion and other information deemed relevant to the project team.

2.1.9 Project Meetings

2.1.9.1 Kick-Off Meeting

As specified within individual orders, the Contractor shall participate in a kick-off meeting attended by key Contractor personnel, the Contracting Officer (CO), the COR, and other key SEC personnel to introduce project members and their roles and responsibilities, introduce the SEC “rules of the road,” and discuss the requirements of the system, the project schedule, testing expectations, testing environments, security requirements, connections, and restrictions, as well as other topics identified by the Contractor or CO/COR.

2.1.9.2 Status Meeting

The Contractor shall participate in weekly and monthly project status meetings attended by key Contractor personnel, the COR, and other key SEC personnel.

2.1.9.3 Meeting Minutes

The Contractor shall provide meeting minutes for the kick-off meeting, status meetings, and for any other meetings which they attend, as directed by the COR.

2.2 CONTRACTOR KEY PERSONNEL

In accordance with SECI 6010.01, Key Personnel, the Contractor shall designate specific senior level professional and managerial personnel as key personnel who are essential to the successful performance of work under this ID/IQ contract. The designated key personnel positions for this ID/IQ contract are:

2.2.1 Project Manager

The Project Manager shall:

• Have decision-making authority, to include the ability to bind the Contractor, and will serve as the Contractor’s representative responsible for resolving all issues, concerns, or problems related to performance of the ID/IQ contract/orders;

• Readily respond to SEC questions, concerns, and comments;

• Proactively alert the SEC to potential contractual issues; and

• Have, at a minimum:

o Three (3) years of experience managing implementations of similar scale and scope using the Contractor’s proposed COTS software;

o Eight (8) years of software implementation experience, including two (2) years of experience implementing software systems for federal or state/local government organizations; and o Experience responding to shifting priorities and managing multiple simultaneous tasks and schedules.

2.2.2 Technical Lead Subject Matter Expert (SME)

The Technical Lead SME shall:

• Serve as the System Architect and be responsible for architecting and managing all technical components of the implementation;

• Provide consultative input and guidance to the project’s engineering resources, as they implement the architecture and design and integrate DPS into the SEC environment;

• Work alongside the SEC’s internal and external contractors, to include ESC personnel supporting the SEC’s financial system, ESC/Delphi; and

• Have, at a minimum:

o Eight (8) years of experience in design, development, and implementation of COTS systems, including five (5) years with the Contractor’s proposed COTS software;

o Three (3) years of experience as a System Architect for implementations using the

Contractor’s proposed COTS software;

o Experience designing and implementing interfaces for financial management systems;

o Experience designing and implementing interfaces related to Oracle Federal

Financials; and o Implementation experience with the SDLC at a U.S. federal agency on the proposed

COTS software and other technologies proposed for this requirement.

2.2.3 Functional Lead

The Functional Lead shall:

• Provide consultative input and guidance to the project’s engineering and functional resources, as they implement the system, migrate data, deliver training, and lead and conduct testing efforts;

• Work alongside the SEC’s internal and external contractors, to include ESC personnel supporting the SEC’s financial system, ESC/Delphi; and

• Have, at a minimum, seven (7) years of experience implementing the proposed COTS software in a federal environment, including three (3) years in a Functional Lead and quality assurance consultant capacity configuring the COTS software (and associated business workflows and rules) to meet business requirements for clients.

2.3 SYSTEMS INTEGRATION, CONFIGURATION, AND DEVELOPMENT

• Configure the COTS software components of DPS;

• Perform the coding and unit test of customizations (if required), transaction workflows, interfaces, and conversion routines; and

• Develop associated system documentation, as required, per SEC policy/procedure and the approved CM plan.

The system configurations and customizations will be reviewed with, and verified by, the SEC project team, process owners, and other SEC subject matter experts, as required, prior to finalization and approval.

2.3.1 Notifications

As part of system configuration and customization, the Contractor shall provide notifications of planned changes and upgrades to the user interface to allow for Government review and approval.

2.3.2 Interfaces

• Code and unit test all required inbound interfaces into DPS, outbound interfaces from DPS, and data transformation routines required to support interfaces as detailed in the approved RCL. Any software code developed by the Contractor for DPS shall be developed using tools and languages approved by the SEC’s OIT and the Information Technology (IT) Architectural Group;

• During development, perform code walk-throughs in accordance with the approved CM plan;

• Control source code in accordance with the approved CM plan; and

• Provide knowledge sessions, clarify questions, and provide testing support to other SEC organizations that will develop interface components for DPS.

2.3.2.1 Internal Interfaces

The Contractor shall manage, maintain, and test data interfaces external to the SEC to ensure consistent secure data transmission between points. For data interfaces internal to the SEC, the SEC will code and unit test interface programs that extract data from SEC legacy applications, using the formats and protocols defined by the Contractor, for use in the transformation and load processes for each DPS interface. Additionally, the SEC will code and unit test interface programs that load data extracted from DPS into SEC legacy applications using the formats and protocols defined by the Contractor.

2.4 TRANSITION SUPPORT

• Develop a Transition Plan, including all technical documentation identified by the COR, to hand over the system to the SEC’s OIT Application Management Group for maintenance or to another contractor. At a minimum, the Transition Plan shall address the following:

o Methodologies for transitioning and ensuring a seamless transition;

o All system documentation (e.g., programmer’s guides, checklists, cheat sheets, informal notes) and system design and configurations;

o An orientation phase and program to introduce Government personnel, programs, and users to the Contractor’s team, tools, methodologies, and business processes;

o Knowledge transfer sessions;

o Shadowing sessions for incoming team;

o Change management issues to include methods of communicating to stakeholders;

o Resource requirements;

o Methods for delivering required metrics and statistics;

o Identification of risks and risk mitigation practices; and o Schedule for transition of services.

• Perform transition activities based on the Government-approved Transition Plan; and

• Ensure that all SEC data hosted at the Contractor’s facilities or stored/processed/transmitted on Contractor owned/managed equipment is returned to Government control, destroyed, or held until otherwise directed by the Government. The Government will retain unrestricted rights to Government data. The SEC retains ownership of any user created/loaded data and applications hosted on the Contractor’s infrastructure, as well as maintains the right to request full copies of these at any time.

Destruction of items shall be accomplished by following federal regulations.

3 ENVIRONMENTAL SUPPORT REQUIREMENTS

3.1 EXTERNAL HOSTING

• Provide an environment external to the SEC to host DPS, to include hardware, software, and all licenses for development, operations and maintenance, and developed solutions.

The hosting environment shall include development, staging, and production environments;

• Maintain the hardware and software in the hosting environment to current federal and SEC standards and ensure that all hardware and software remains within active Original Equipment Manufacturer (OEM) lifecycles;

• Provision the environments per the FedRAMP Authority to Operate(s) (ATO) and approved configuration and change management procedures and capabilities for Infrastructure-as-a-Service (IaaS);

• Provide full Disaster Recovery (DR) capability for the hosting environment in accordance with SECI 6013.01(n), Federal Requirements, Security, and Accessibility for Information Systems; and

• Protect all SEC data stored, processed, or transmitted by the Contractor per federal and SEC requirements and in accordance with SECI 6022.00, FedRAMP Requirements for Cloud-Based Services. All DPS data stored, processed, or transmitted by the Contractor shall remain fully and solely owned by the SEC, and will be accessible to authorized SEC users.

3.1.1 Environments

• Maintain development, staging, and production environments for DPS, as indicated in the table below;

• Within its hosting environment, maintain a dedicated production environment. The development and staging environments may be in shared environments, at the Contractor’s discretion;

• Document the hosting environment architecture and provide the documentation to the COR, when requested; and

• Document and package fixes, patches, and releases so that changes can be promoted among the environments in an orderly fashion. All changes to each environment shall comply with change control procedures and requirements, per SEC policy and the approved CM plan.

Table 3-1: Supported Environments

Environment Specific Instances

A. Development A.1 Development A.2 System Testing A.3 Data Migration

B. Staging

B.1 User Acceptance Testing (UAT) B.2 Training B.3 Integration Testing B.4 Quality Control Test Center (QCTC) Testing

C. Production C.1 Production C.2 Disaster Recovery (DR)

3.2 DEVELOPMENT, MODERNIZATION, AND ENHANCEMENTS (DME) SUPPORT

• Provide support for the implementation of DME requests. Potential DME requests are driven by user requirements for DPS and include, but are not limited to, developing workflows and interfaces to DPS;

• Provide all phases of the Software Development Lifecycle to include Planning, Requirements, Design, Build, Document, Test, Deploy, and Maintain; and

• Keep a back log of DME items, as they are presented by users. These items will provide opportunity for future DME deployments.

DME invoicing may be set by deliverable or project milestone instead of equal monthly installments. This will be identified within individual orders.

3.2.1 Cloud Migration Support

• Redesign and configure the DPS application and all of its components to make DPS cloud agnostic as much as possible. The current target cloud environment for the SEC is a version of the Amazon Web Services, Inc. (AWS) Cloud (AWS Cloud Environment at the SEC (ACES));

• Plan, design, and provide all work necessary to migrate all data and the DPS application and platform to a new SEC approved cloud environment; and

• Test and validate the correct operation of DPS in the new cloud environment.

3.3 OPERATIONS AND MAINTENANCE (O&M) SUPPORT

The Contractor shall perform all tasks necessary to provide for the O&M of DPS according to all federal and SEC requirements. Tasks include, but are not limited to, the following:

• Investigate reported incidents, which could come in through multiple sources including IT Service Management (ITSM) tickets, e-mails, and phone calls to the Contractor point of contact, develop solutions, and deploy fixes;

• Document Root Cause Analysis (RCA) for reported incidents;

• Record and track incidents in SEC’s JIRA (or equivalent software) ticketing system;

• Facilitate bi-weekly meetings to discuss outstanding JIRA tickets and actions needed for resolution;

• Prepare materials (e.g., PowerPoint slides) for and facilitate weekly Incident Review

Board (IRB) meetings to discuss the status of significant incidents/issues and other major events relating to DPS;

• Maintain DPS’ interfaces with internal (e.g., SEC FEEDS, AP Drive, etc.) and external (e.g., LexisNexis, Treasury, etc.) sources by:

o Working with the SEC to research and resolve interface errors on an as needed basis;

o Implementing and testing changes needed to maintain successful interface performance; and o Assisting the SEC in updating interface documentation (e.g., Memorandums of Understanding (MOUs), Interconnection Security Agreements (ISAs)) on an as needed basis;

• Provide DPS information in support of reviews, audits, and data calls;

• Actively monitor application performance and operations to identify circumstances that may lead to performance degradation or outages so that it can be addressed before the system is impacted;

• Identify opportunities to optimize application performance;

• Work with the SEC Server Team, Network Operation Center (NOC), and End User

Technology (EUT) and Database Group to provide solutions when system technical issues arise;

• Implement emergency patch releases, as necessary, to address critical issues;

• Implement quarterly COTS software patch releases or as required by the COTS vendor;

• Implement hot fix releases on an as needed bases;

• Perform system and regression testing in support of quarterly and hot fix releases;

• Support UAT for applicable tickets/issues addressed by quarterly releases and hot fixes by:

o Creating UAT scripts and loading into SEC’s JIRA application; and o Ensuring sufficient test data is available for end users to execute testing;

• Implement COTS maintenance releases required to keep system component versions up to date and prevent software end-of-life issues. The scope will be limited to technical upgrades, meaning migration of existing functionality and data to the new COTS release and regression testing, following the SEC SDF and/or SEC approved contractor internal SDLC procedures to deploy the new release into production. If the SEC decides to consume new functionality available in the COTS release, the implementation services required for it will be funded as an in-scope modification to an order;

• Store all code and documentation in an SEC-approved CM tool, per the approved CM plan;

• For all production software changes, create an SCR for each change that has to be presented to the Configuration Control Board (CCB); additional SCRs may be required that are outside the CCB review for audit tracking purposes for all system changes;

• Comply with the CCB procedures and tools, including use of SEC provided version control service management systems, per the approved CM plan;

• Provide support for security testing and reviews;

• Work with server teams to provide solutions to Security Group if application vulnerabilities are found during system scans or security testing;

• Provide continuous evaluation of system components to self-identify security vulnerabilities;

• Provide support for the resolution of any security vulnerabilities and a Plan of Actions &

Milestones (POA&M) that may result from self-identification, security tests, assessments, or audit findings;

• Provide support for the SEC OIT’s DR exercises, which includes making sure the application and all of the technology components that comprise it can operate and are available and accessible from either of the Commission’s data centers and conducting tests to confirm (on average, DR exercises occur once per year, including failover to one

(1) data center and failback to the other);

• Update all system documentation as required by the SEC’s SDF process or as needed to ensure that updated operating procedures, system changes, and resolution of vulnerabilities, POA&Ms, and audit findings are reflected;

• Support configuration changes to DPS reference data to include, but is not limited to, general ledger accounts, fund codes, and posting logic stemming from updates mandated by the SEC, Office of Management and Budget (OMB), and Treasury;

• Maintain scheduled jobs and related data extracts;

• Create new data extracts on an as needed basis as user needs arise; and

• Provide written instructions to help facilitate DPS configuration and report changes on an as needed basis.

3.3.1 Help Desk Support

The Contractor shall provide Tier 2 support for DPS. System users will contact the SEC Help Desk and DPS calls will be transferred to the Contractor. The hours of Tier 2 support shall be 0900 – 1700 Eastern Time, Monday – Friday, on federal business days.

3.3.2 Response Time

The Contractor shall respond to application issues within four (4) hours from the time of notification by the user during normal (non-emergency) operations.

3.3.3 Problem Escalation

• Diagnose and resolve problems that arise with the system;

• Provide the COR with a timetable for resolving reported service problems, as well as escalation procedures with remedies for unsolved problems; and

• Incorporate feedback from the COR and deliver a revised timetable and escalation procedures to the COR for review and approval.

3.3.4 Service Level Agreement

The system shall be available for use between 0600 – 2100 Eastern Time, Monday - Friday, excluding federal holidays, administrative leave, and during scheduled maintenance times, which shall be mutually agreed upon and approved by the SEC and the Contractor in advance. Routine maintenance shall occur during the system maintenance window of Saturday at 2200 to Sunday at 1100.

3.3.5 Scheduled Downtime

The Contractor has the right and responsibility to alter the hours of system availability to schedule emergency maintenance or operations activities. Routine maintenance or operations activities shall occur outside of the system availability window. The Contractor shall notify the COR by telephone and by e-mail at least 24 hours before scheduled system unavailability. The Contractor shall describe how SEC users will be notified of planned outages.

3.4 SYSTEM FAILURE

The Contractor shall immediately notify the COR in the event of a significant system failure and provide details on the nature of the failure, restorative options, and timeframe for restoration.

The Contractor shall use reasonable efforts to restore the service in the event of system failure as soon as possible.

3.5 PROJECT RELATED DOCUMENTS

The Contractor shall create, manage, and update the following project documents in accordance with SECIs 6013.01(l), Federal Requirements, Security, and Accessibility for Information Systems, and 6022.00, FedRAMP Requirements for Cloud-Based Services:

• Privacy Impact Assessment (PIA);

• Privacy Analysis Worksheet (PAW);

• Security Categorization Worksheet (SCW);

• Security Impact Analysis (SIA);

• RTM;

• Technical Design and Architectural Review Phase Gate;

• Technical Review Board (TRB);

• Detailed Architecture Design (DAD);

• QCTC Load and Stress Test Planning Questionnaire;

• UAT;

• IT System Contingency Plan (CP)/Information System Contingency Plan (ISCP)

• Authorization to Test (ATT) and Live Data Testing Questionnaire Template;

• Standard Operating Procedures (SOP);

• System Privacy Plan (SPP);

• MOU;

• ISA;

• Rehabilitation Section 508 Exception or Remediation Plan (Justification);

• System Security Plan (SSP); and

• Any other security, governance, or project documents as identified by the COR.

4 DELIVERABLES

4.1 MARKING

All deliverables shall:

• Clearly indicate the ID/IQ contract and order number for which the deliverable is being submitted; and

• Be marked in accordance with best commercial practice.

4.2 PLACE OF DELIVERY – FOB DESTINATION

Deliverables shall be e-mailed to the COR or delivered to the following address, as specified in individual orders:

U.S. Securities and Exchange Commission Station Place - Headquarters 100 F Street NE Washington, D.C. 20549

4.3 INSPECTION AND ACCEPTANCE

Inspection and acceptance will be performed by the COR.

• Use plain language for all written deliverables;

• Define, in a glossary, any terms-of-art and technical terms used in a deliverable;

• Submit all deliverables to the COR for review;

• Incorporate feedback from the COR and provide the COR with a final version of the deliverable for review and approval; and

• Obtain approval in writing from the COR for any and all changes to, or deviations from, the approved deliverable.

Contractor format is acceptable when approved by the COR. The COR will review all deliverables within five (5) business days, unless stated otherwise in individual orders.

4.4 SCHEDULE OF DELIVERABLES

Table 4-1: Schedule of Deliverables

No. PWS Ref. Deliverable Due Date/Frequency

1. 2.1.2 Project Management Plan (PMP) As Required

2. 2.1.3 System Development Plan (SDP) As Required

3. 2.1.4 Project Work Breakdown Structure (WBS) As Required

4. 2.1.4 Project Schedule As Required

5. 2.1.6 Configuration Management (CM) Plan As Required

6. 2.1.7 Training Management Plan (TMP) As Required

7. 2.1.8.1 Weekly Status Reports Weekly per Project Manager

8. 2.1.8.2 Monthly Status Reports Monthly per Project Manager

9. 2.1.8.4 Briefing Materials At Least Five (5) Business Days Before Briefing

10. 2.1.9.1 Kick-off Meeting Within Five (5) Business Days of Order Award

11. 2.1.9.3 Meeting Minutes

Within Two (2) Business Days After Meeting; Final Version To Be Submitted Within Two

(2) Business Days From Receipt of COR Feedback

12. 2.3 Transition Plan Start and Finish of Order

Project Initiation Phase

13.

3.5/

SECI 6022.00/

SDF Journey Map

Privacy Impact Assessment (PIA) As Required

14. 3.5/ SDF Journey Map Privacy Analysis Worksheet (PAW) As Required

15. 3.5/ SDF Journey Map Security Categorization Worksheet (SCW) As Required

16. 3.5/ SDF Journey Map Security Impact Analysis (SIA) As Required

Requirements Phase Gate

17. 2.1.5/3.5/ SDF Journey Map Requirements Traceability Matrix (RTM) As Required

Technical Design and Architectural Review Phase Gate. Phase Gate

18. 3.5/ SDF Journey Map Technical Review Board (TRB) As Required

19. 3.5/ SDF Journey Map Detailed Architecture Design (DAD) As Required https://sharepoint/sites/OIT/gov/sdlcpi/Pages/default.aspx https://sharepoint/sites/OIT/gov/sdlcpi/Pages/default.aspx https://sharepoint/sites/OIT/gov/sdlcpi/Pages/default.aspx https://sharepoint/sites/OIT/gov/sdlcpi/Pages/default.aspx https://sharepoint/sites/OIT/gov/sdlcpi/Pages/default.aspx https://sharepoint/sites/OIT/gov/sdlcpi/Pages/default.aspx

Development Phase Gate

20. 3.5/ SDF Journey Map

Quality Control Test Center (QCTC) Load and Stress Test Planning Questionnaire As Required

21. 3.3/3.5/ SDF Journey Map User Acceptance Testing (UAT) As Required

22.

3.5/

SECI 6022.00/ SDF

Journey Map

Information Technology (IT) System Contingency Plan (CP)/Information System Contingency Plan (ISCP)

Continuous, Reviewed Annually

23. 3.5/ SDF Journey Map

Authority to Test (ATT) and Live Data Testing Questionnaire Template As Required

Independent Testing Phase

24. 3.5/ SDF Journey Map Standard Operating Procedures (SOP) As Required

25. 3.5/ SDF Journey Map System Privacy Plan (SPP) As Required

26.

3.3/3.5/

SECI 6022.00/ SDF

Journey Map

Memorandum of Understanding (MOU) As Required

27.

3.3/3.5/

SECI 6022.00/ SDF

Journey Map

Interconnection Security Agreement (ISA) As Required

28. 3.5/ SDF Journey Map

Rehabilitation Section 508 Exception or Remediation Plan (Justification) As Required

29.

3.5/

SECI 6022.00/ SDF

Journey Map

System Security Plan (SSP) As Required

30. SECI 6022.00 Test Results Plan of Action and Milestones (POA&M) As Required

31. SECI 6022.00 Continuous Monitoring Plan (CMP) Continuous, Reviewed Annually

32. SECI 6022.00 FedRAMP Control Tailoring Workbook Continuous, Reviewed Annually

33. SECI 6022.00 Control Implementation Summary Table Continuous, Reviewed Annually

34. SECI 6022.00 Results of Penetration Testing As Required, At Least Annually

35. SECI 6022.00 Software Code Review Continuous, As Developed

36. SECI 6022.00

Interconnection Agreements/Service Level Agreements/Memorandum of Agreements

As Required, Reviewed Annually

37. SECI 6022.00 Security Assessment Report (SAR) As Required https://sharepoint/sites/OIT/gov/sdlcpi/Pages/default.aspx https://sharepoint/sites/OIT/gov/sdlcpi/Pages/default.aspx https://sharepoint/sites/OIT/gov/sdlcpi/Pages/default.aspx https://sharepoint/sites/OIT/gov/sdlcpi/Pages/default.aspx https://sharepoint/sites/OIT/gov/sdlcpi/Pages/default.aspx https://sharepoint/sites/OIT/gov/sdlcpi/Pages/default.aspx https://sharepoint/sites/OIT/gov/sdlcpi/Pages/default.aspx https://sharepoint/sites/OIT/gov/sdlcpi/Pages/default.aspx https://sharepoint/sites/OIT/gov/sdlcpi/Pages/default.aspx https://sharepoint/sites/OIT/gov/sdlcpi/Pages/default.aspx https://sharepoint/sites/OIT/gov/sdlcpi/Pages/default.aspx https://sharepoint/sites/OIT/gov/sdlcpi/Pages/default.aspx

5 SYSTEM PERFORMANCE STANDARDS

The tables below contains performance standard benchmarks for DPS components and related functionality. The Contractor shall develop and maintain the system to these baseline standards or better.

Table 5-1: System Performance Standards

DPS

Component Function/Process Performance Benchmark Comments

Document Management

Module

(DMM)

Log into Intake Inbox

The Intake Inbox shall render in no longer than 30 seconds upon initially accessing the Intake Inbox Screen

Open Intake Inbox Task - Metadata

Metadata shall be successfully displayed in no longer than 5 seconds after opening a task from the Intake Inbox

Opening of Attachments associated with Intake Inbox Tasks

The opening of attachments associated to a task shall successfully occur in no longer than 15 seconds for the first attachment opened for a session.

The rendering of the first page and thumbnails for an attachment shall occur in no longer than 5 seconds on all subsequent attachments opened after the first one per session.

The rendering of subsequent pages (after the first page has rendered) shall take no longer than 2 seconds when navigating backwards or forwards within attachment pages.

Save and Submit/Approve

(Route) Tasks Tasks shall successfully route in no longer than 5 seconds.

Auto Acquire Next Task

Upon completion of successfully routing a task from the Received Wizard Screen, the next task shall be automatically acquired and metadata loaded within 5 seconds, after the previous task finished routing.

Routing Merged Sets

When routing a set of merged tasks, the set shall route each item in the set within 5 seconds (i.e. each workflow routes individually as part of the set).

DMM Specific Item Searches (Search Bar)

No longer than 10 seconds.

Execution of Queries and

Reports (Advance Search)

No longer than 30 seconds. (Complex Queries/Reports taking longer than 30 seconds shall be scheduled)

Momentum

Log into DPS Inbox No lag time.

Open DPS Inbox Task No longer than 5 seconds.

Opening of Attachments associated with DPS Inbox Tasks

The opening of attachments associated to a task shall

Opening of Attachments

The opening of attachments associated to a task shall

Save &

(Route) DMM

Workflow Tasks

A DMM workflow task shall successfully route within 10 seconds.

Save &

(Route) Momentum Tasks

No longer than 5 seconds.

5.3 second Benchmark per “Collection against Accounts

Receivable (AR)” task from

Performance Testing

Momentum Specific Item

Searches No longer than 5 seconds.

4.5 second Benchmark per “Collection against AR” task from Performance

Testing

Execution of Momentum Queries and BIRT Reports

No longer than 30 seconds.

Complex queries/reports taking longer than 30 seconds shall be scheduled.

Batch Jobs See Attachment A, Batch Job Table below.

Pentaho

Ad-Hoc Queries not Exceeding the 100K Row Limit

No longer than 60 seconds.

Complex queries taking longer than 60 seconds shall be considered for a scheduled delivery.

Shared Reports not Exceeding the

100K row Limit No longer than 60 seconds.

Complex queries taking longer than 60 seconds shall be considered for a scheduled delivery.

Table 5-2: Batch Jobs

Batch Job Title Expected Time to Complete Comments

CSNG Collection 10 minutes Monday TOP Collection 10 minutes Thursday

General Ledger Recon Varies greatly – 10 minutes to 2.5 hours

Run Monday – Friday Times vary depending on the size of the file received from ESC with the Recon data limited to the past 4 months

General Ledger BPAC Export 10 minutes Run Monday – Sunday

TOP Referrals 10 minutes Run Monday – Friday CSNG Referrals 10 minutes Run Monday – Friday

AROVERDUE 50 minutes Run Monday – Friday, Weekend if last day of month

CIR Collection 10 minutes Run Tuesday – Saturday HUB Import 15 minutes Run Monday – Friday CourtLink 40 minutes Run Monday – Friday AP Drive 10 minutes Run Monday – Friday

General Ledger Query Details 10 minutes Run Monday – Friday

CNC

TDM

5.1 PROCEDURES FOR ADDRESSING PERFORMANCE ISSUES

• Identify instances of DPS processing times exceeding performance benchmarks in DPS

PROD;

• Log JIRA tickets for performance issues identified by the Contractor or the SEC; and

• Review instances of processing times exceeding performance benchmarks and identify root causes, determine necessary corrective actions, and implement corrective actions upon approval by the SEC.

6 GOVERNMENT FURNISHED

In accordance with SECI 6016.00, Supplies for Service Contracts, and as determined at the order level, phones and computers may be made available to off-site contractor personnel at the discretion of the SEC for use in the performance of their tasks and will be returned when no longer required or as directed by the SEC. An approved justification by the COR will be required for the issuance of Government furnished equipment.

7 ELECTRONIC AND INFORMATION TECHNOLOGY ACCESSIBILITY

7.1 ELECTRONIC AND INFORMATION TECHNOLOGY ACCESSIBILITY

Each Electronic and Information Technology (EIT) product or service furnished under this ID/IQ contract shall comply with the Electronic and Information Technology Accessibility Standards (36 CFR 1194). If the CO determines any furnished product or service is not in compliance with the ID/IQ contract, the CO will promptly inform the Contractor in writing. The Contractor shall, without charge to the Government, repair or replace the non-compliant products or services within the period of time to be specified by the Government in writing. If such repair or replacement is not completed within the time specified, the Government shall have the following recourses:

• The right to termination of the ID/IQ contract, delivery or task order, purchase or line item without termination liabilities pursuant to the ID/IQ contract termination clauses; or

• In the case of custom Electronic and Information Technology (EIT) being developed for the Government, the Government shall have the right to have any necessary changes made or repairs performed by itself or by another firm and the Contractor shall reimburse the Government for any expenses incurred thereby.

For every EIT product or service accepted under this ID/IQ contract by the Government that does not comply with 36 CFR 1194, the Contractor shall, at the discretion of the Government, make every effort to replace or upgrade it with a compliant equivalent product or service, if commercially available and cost neutral, on either the planned refresh cycle of the product or service, or on the ID/IQ contract renewal date, whichever shall occur first. In the event of a modification(s) to this ID/IQ contract/order, which adds new EIT products and services or revises the type of, or specifications for, products and services the Contractor is to provide, including EIT deliverables such as electronic documents and reports, the CO may require that the Contractor provide an update of information provided in the solicitation to identify EIT compliance. Under any maintenance agreement, the Contractor agrees to maintain compliance with Section 508 of the Rehabilitation Act of 1973 for all EIT.

In order to comply with 36 CFR 1194 Section 41, the Contractor shall submit all soft copies (e.g., user manuals, product documentation, etc.) in a format that will be readable using assistive technology, (e.g., screen reader). All imbedded charts, graphs, pictures, etc., must be accessible and understandable using a screen reader.

2.4 Transition Support