SOW_AMEND_0002.docx

TABLE OF CONTENTS

SECTION A STANDARD FORM 1449

PART 1 – Addenda to Standard Form 1449

SECTION B DESCRIPTION OF SUPPLIES OR SERVICES

B-1—Prices/Cost B-2—Description of Supplies or Services B-3—Scope of Work B-3.1 Technical Support Services B-3.2 Software licenses B-3.3 Administrative Services B-3.4 Government Furnished Supplies B-3.5 Implementation Support B-3.6 End User Training B-3.7 Card readers B-3.8 Current Environment

B-4 E-COMMERCE SOFTWARE MANDATORY REQUIREMENTS

B-5 GATEWAY SERVICES MANDATORY REQUIREMENTS

B-6 PAYMENT CARD INDUSTRY STANDARDS AND REQUIREMENTS

B-10 IMPLEMENTATION

B-18 BACK UP AND DISASTER RECOVERY

B-19 HELP DESK

B-20 SCHEDULED OUTAGES

B-21 NEW NATIONAL SUPPORT CENTER (NSC)

PART II CONTRACT CLAUSES AND TERMS AND CONDITIONS

SECTION D FAR CLAUSES

SECTION E SSA CLAUSES

PART III – CONTRACT DOCUMENTS, EXHIBITS, ATTACHMENTS

SECTION F – LIST OF ATTACHMENTS

Part IV -- SOLICITATION PROVISIONS

SECTION G REPRESENTATIONS, CERTIFICATIONS, AND OTHER STATEMENTS OF OFFERORS OR RESPONDENTS

SECTION H INSTRUCTIONS TO RESPONDENTS

SECTION I EVALUATION FACTORS FOR AWARD

ATTACHMENTS

· Attachment No. 1 -- Applicability of SSA’s Accessibility Requirements to EIT Solutions

· Attachment No. 2 – List of SSA Field Offices

· Attachment No. 3 – Payment Coupon Scan Line Format

· Attachment No. 4 – Vantiv Key Confidentiality Agreement

· Attachment No. 5 – Mutual Nondisclosure (VAR Certification

· Attachment No. 6 – Instructions to Contractors Applicable to Section 508

· Attachment No. 7 – Small Business Subcontracting Model Plan

· Attachment No. 8 – SSA Authorization Letter

· Attachment No. 9 – SSA Evaluation Questionnaire

SOW Amendment No. 2 Solicitation No. SSA-RFP-13-0015

PART I - Addenda To Standard Form 1449 In accordance with Federal Acquisition Regulation (FAR) 12.302 and 12.303, this Part I contains addenda to the Standard Form 1449. The addenda, provides for the continuation of the schedule and description of the supplies and services to be acquired.

PART B-1- PRICES/COSTS

The Contractor shall furnish the necessary supplies and services to perform the work described in SECTION B of this Contract.

The resultant contract will be an Indefinite Delivery/Indefinite Quantity-type contract that allows for Task Orders which are either Firm Fixed type or Labor Hour type or A Combination of Labor Hour AND Firm Fixed Price.

The life of the contract is 5 years, which includes Phase 1 for 6 months and Phase 2 for 6 months, as well as 4 additional years.

Pricing Tables

In accordance with FAR Part 15.2, the contractor is required to insert pricing in accordance with the instructions in Section H: Instructions to Respondents.

The Government will evaluate the proposal by adding the total price of all items included in the following pricing tables.

TABLE B-1 – TOTAL

Table B-1.1 -- Base Year Price(s) (Consists of Phase 1 and 2) Table B-1.2 -- Year 2 Price(s) Table B-1.3 -- Year 3 Price(s) Table B-1.4 -- Year 4 Price(s) Table B-1.5 -- Year 5 Price(s) Table B-1.6 – SUMMARY All Items Amendment No. 2 Solicitation No. SSA-RFP-13-0015 REVISED RFP

ATTACHMENT NO. 2

TABLE B-1 SUMMARY TABLE

B-1.1 - Base Year As described in B-2 - Phase 2

TOTAL FOR ALL FIVE YEARS

Table B-1.1 - Base Year - Contract Year 1 PHASE 1 (Months 1-6)

PHASE 1 - TESTING IN 21 PILOT SITES

Technical and Administrative Services

End-User Training Materials

TOTAL BASE YEAR - Contract Year 1 - PHASE 1

Table B-1.1 - Base Year Pricing Table PHASE 2 (Months 7-12)

PHASE 2 - ROLL-OUT TO REMAINING FIELD OFFICES

Technical and Administrative Services

TOTAL BASE YEAR - Contract Year 1 - PHASE 2

Table B-1.2 - Year 2 (Months 13-24)

Technical and Administrative Services

TOTAL Year 2

Table B-1.3 - YEAR 3 (Months 25-36)

Technical and Administrative Services

TOTAL Year 3

Table B-1.4 - Year 4 (months 37-48)

Technical And Administrative Services

TOTAL Year 4

Technical and Administrative Services

TOTAL Year 5

Table B-1.5 - Year 5 (months 49-60)

Table B-1.6 - SUMMARY TABLE

Technical and Administrative Services

End-User Training Materials

TOTAL ALL ITEMS

B-2– DESCRIPTION OF SUPPLIES OR SERVICES

B-2.1 IDENTIFICATION

Social Security Administration (SSA) Office of Financial Policy and Operations Office of Financial / Administrative Systems 6401 Security Boulevard Baltimore, Maryland 21235

B-2.2 MISSION OF THE OFFICE

The Office of Financial Policy and Operations (OFPO) has operational responsibility for SSA’s accounting, payment, and travel operations and preparation of the agency’s financial reports, including the annual financial statements. OFPO also has agency-wide responsibility for SSA’s financial policies and procedures, internal control programs, financial management and related administrative systems, cost accounting and cost analysis programs, certification and accounting for all benefit payments, debt management program and the domestic and international direct deposit programs for delivery of benefit payments.

The Office of Financial/Administrative Systems (OFAS) provides systems analysis and support for the design development, and implementation of SSA’s financial management systems and their integration with related administrative and programmatic processes. These systems include:

· The Social Security Online Accounting and Reporting System (SSOARS). This is SSA’s core accounting system and uses Oracle’s Federal Financials Commercial Off- the-Shelf Software, and includes the SSOARS Financial Information System and SSOARS Noetix for reporting purposes

· Agency Administrative systems, including the Third Party Payment, Purchase Card, Payroll Operational Data Store, and the Electronic Document Management Systems, and

· Electronic Government (E-Gov) initiatives, including E-Gov Travel and the related Financial Management Lines of Business.

OFAS is also responsible for:

· Information Technology (IT) Planning Process support, serving as the focal point for IT project and budget planning for OFPO and OFAS,

· OFPO’s Local Area Network support, including maintaining Active Directory for OFPO, installing, maintaining and troubleshooting workstations and peripheral equipment, and technical support and evaluation of administrative IT products, and

· OFPO Component Security officer function, including Top Secret© administration and SSOARS System Administration.

B-2.3 OVERVIEW

SSA provides services to its customers through a network of approximately 1,300 field offices throughout the United States and its territories. Field offices assist individuals who are applying for or receiving benefits under several SSA programs, and they also process and maintain information related to individuals’ Social Security records. In certain situations, SSA is authorized by statute and regulations to charge fees for providing information to individuals or third parties. Generally, the regulations allow SSA to recover its costs for searching, copying, and certifying information in its system of records. The fees compensate SSA for its work so the Social Security trust funds do not bear the costs of such activities.

In 2009, the SSA Office of the Inspector General (OIG) issued an Audit Report (A-04-09-19041) entitled, Field Office Procedures for Charging and Collecting Fees. The objective of the audit was to determine whether (1) SSA policies and procedures for charging and collecting fees at field offices were adequate and (2) field offices complied with existing guidance. The report concluded that agency policies, procedures, and field office practices did not ensure a consistent determination and collection of fees. The report recommended that SSA clarify fee collection policies and procedures, adopt standardized fees for commonly received requests, provide training for staff, and develop an automated system to assist field office staff and managers with processing and collecting fees for non-programmatic services.

At the direction of the Commissioner, the agency is developing a streamlined remittance process and an automated system solution to collect fees for non-programmatic services. The system is the Social Security Electronic Remittance System (SERS). SERS will be implemented in two phases with a total implementation schedule of one year. The adoption of standardized fees and the implementation of SERS will ensure the agency’s compliance with both the OIG audit recommendations and the requirements of OMB Circular A-25, User Charges.

A key part of SERS is an E-Commerce software solution. This software will be integrated with SSA’s accounting system, SSOARS, which is based on Oracle’s E-Business Suite (EBS) Financials Software (see Section B-3 ). The solution will provide all of the components necessary to provide Intranet and Internet services in a secure environment. The application will manage orders, create transactional documents, process payments, provide management information reports, and pass accounting events to SSOARS.

SERS will be used when customers request several different types of documentation. Field office personnel will enter requests into the system on an existing PC workstation to create an order. SERS will accept the following payment methods: branded plastic cards and checks. Unless otherwise noted, all references in this document to methods of payment in SERS should be read to include both branded plastic cards and paper checks. Branded plastic cards are those with official industry logos (e.g., VISA or Master Card) and include credit, debit, and gift cards. A check includes personal checks, business checks, corporate drafts, travelers’ checks and money orders.

The overall solution will incorporate the following:

· E-Commerce Software and Integration Services - this is the software that serves as the “sales register” for the “sale” of services by SSA to members of the public. This software will be integrated with SSA’s accounting system, SSOARS, which is based on Oracle’s E-Business Suite (EBS) Financials Software (see Section B-3). The solution will provide all of the components necessary to provide Intranet and Internet services in a secure environment. . The application will manage orders, create transactional documents, process payments, provide management information reports, and pass accounting events to SSOARS.

· Gateway Services for the initial step in card reader transactions - Using the latest in encryption technology, the Gateway contractor will send encrypted branded plastic card data to the United States Department of the Treasury’s (“Treasury” ) designated payment processor, Vantiv LLC (Vantiv), for immediate authorization processing and will return approval information back to the card reader. The card reader then initiates a transaction with the E-Commerce Software in order to complete the order. No plastic card information will be stored in SERS or in the SSOARS database, and requisite encryption or tokenization functionality is required and is the responsibility of the Gateway contractor. Any proposed solution must eliminate the exposure of SSA’s internal network to the network scans required by the Payment Card Industry-Data Security Standards (PCI-DSS).

· Card readers - The SERS contractor shall provide the actual devices, including those for the initial deployment, and replacements, as needed, during the course of this award. The contractor will be responsible for integrating these card readers, and handling the data processed by these devices. SSA will be responsible for installing the devices in field offices so that members of the public and Field Office personnel can use them.

· Check scanners - the devices are to be provided by the U.S. Department of Treasury. The SERS contractor, however, will be responsible for integrating these scanners and handling the data processed by the scanners. SSA will be responsible for installing the devices in the field offices.

B-3 SCOPE OF WORK

The Contractor shall provide all of the software licenses, software maintenance, training, technical support, and administrative management of Contractor personnel for this effort. The Contractor will install and configure the software and configure the hardware in SSA’s IT environment. No contractor travel will be required to any field office. The Contractor shall be able to provide support and technical expertise in the following areas:

B-3.1 TECHNICAL SUPPORT SERVICES: The Contractor shall provide technical experts to support the out-of-the-box implementation and integration of the solution. The Contractor shall implement, integrate, and support the Software according to the mandatory requirements in this Section. The Contractor’s solution must support the following functions that represent the high-level design for SERS:

· Inventory: Create and manage the items/documents requested by SSA customers or third parties. The inventory provides underlying structure for all orders.

· Configuration Tool: A flexible rules engine that will be used to define the flow and ordering capabilities of the software.

· Order Management: Create a transactional document specifying the items requested and includes the total amount due which integrates with the Accounts Receivable module in SSOARS.

· Accounts Receivable (AR): Track accounting and status of all requests from Order Management. Create a receipt and an accounting record for all paid orders and integrate with the General Ledger in SSOARS.

· General Ledger: Process all accounting for SERS requests including plastic cards which are transferred automatically from AR as well as settlements received by the processor.

B-3.2 SOFTWARE LICENSES: The Contractor shall provide software licenses (development, validation, pre-production) to support approximately 50 users for Phase 1. For Phase 2, the Contractor shall provide software licenses to support an unlimited number of users. See Section B-10.1

B-3.3 ADMINISTRATIVE SERVICES: The Contractor shall provide all management and administrative services required for the support and supervision of Contractor personnel.

B-3.4 GOVERNMENT-FURNISHED SUPPLIES: The Government will provide office space, furniture, equipment, telephone services, and computer-processing time to accomplish work performed on-site at SSA as outlined in each Task Order.

B-3.5 IMPLEMENTATION SUPPORT: During the installation of the software on-site at SSA headquarters, the Contractor shall supply on-site training on the software installation process. This training shall consist of the Contractor discussing with an anticipated 4-6 SSA personnel each step in the written instructions as the steps are being performed. This training shall also include written documentation on the configuration and maintenance of solution after it has been installed. At the present time, SSA anticipates needing such onsite support only during Phase 1.

The contractor will provide updates to this documentation as upgrades, enhancements or other changes are made to the software or other products.

B-3.6 End-User Training Materials:

The contractor will provide SSA-specific training materials on the use of SERS in any one of the following formats, as specified at the Task Order level:

· The contractor will provide a written SERS User Guide in an electronic format that instructs system users on how to use the system will be provided . The Guide will document step-by-step instructions on how the system works from end-to-end, and should include text, process flows, diagrams, and screen shots. The guide should cover both system software and hardware, and include tutorials, a glossary, and Frequently Asked Questions. The Guide will be provided electronically to SSA in MS-Word format.

· The contractor will provide web-based training that will be available to SERS users to take advantage of distance learning via the SSA Intranet web-based training. The web-based training will replicate the written materials in the SERS User Guide and will allow users to access this information from their desktop computer. This training method will permit users to “walk-through” the system in a self-paced manner by entering data and navigating through system fields and screens.

· The contractor will provide SERS training in a Video On Demand (VOD) format. The VOD training will cover the same material as the SERS user guide, and will visually demonstrate the use of the total SERS solution. The VOD training will be prepared in an acceptable SSA format (see table below).

Prior to the preparation of any training materials, the contractor will meet with appropriate SSA staff to discuss content, format, and other pre-production issues to ensure that training materials meet SSA’s needs.

Acceptable VOD formats are:

240 x 180

3 window Articulate Has slides

shockwave-flash 120 to 240 kbps

B-3.7 CARD READERS

The Gateway Services contractor must provide the plastic card readers required to process branded plastic cards as part of an overall solution. Card readers proposed by the contractor must be PCI Personal Identification Number (PIN) Transaction Security, Version 3. See Section B-7 for additional requirements on card readers.

B-3.8 CURRENT ENVIRONMENT

The following represents the current SSA SSOARS environment.

B-4 E-COMMERCE SOFTWARE MANDATORY REQUIREMENTS

The contractor’s solution shall:

a. Accept customer transactions entered on a card reader and from a check scanner.

b. Accept branded plastic card information by entering it directly into the card reader, or by swiping a branded plastic card on a card reader.

c. Communicate with third-party payment processors for real-time authorization and end of day settlement processing.

d. Operate on a standard SSA PC/workstation. The current minimum specifications for an SSA Win7 workstation are: Intel Dual Core processor @ 3.00 GHz, 4.0 GB RAM; 160 Gb hard drive; Nvidia Quadro NVS 290 PCI video card, max res 2048x1536 @ 75 Hz; 256 MB memory; 22 inch wide screen monitor; and a 32-bit Win7 operating system.

e. Provide a single logical database within SSOARS, and avoid duplication of data and the additional costs of maintaining multiple databases.

f. Have an infrastructure that works with SSA’s existing infrastructure and information technology (currently UNIX-based and Oracle Database).

g. Utilize COTS software with no customization required. It may be configured or extended, but these configurations and extensions must not interfere with ease of maintenance or upgrade to both the E-Commerce application and the SSA SSOARS applications.

h. Implement, out of the box, Single Sign-On that allows users to access the E-Commerce software using their SSA LAN credentials or a Federal Personal Identity Verification (PIV) smart card, either via direct certificate authentication or through well-established trust mechanisms such as Kerberos or SPNEGO, without the need for a separate SERS User ID and password. SSA currently uses Microsoft Active Directory as the repository against which users can be validated.

i. Embed rules in the application without the need for additional programming.

j. Manage orders, create transactional documents, process payments, and pass accounting transactions in real-time to SSOARS.

k. Warehouse or inventory orders to be fulfilled at a later date.

l. Handle requests originating from the Intranet and Internet.

m. Annotate on the order that payment has been accepted, that it has been posted to the accounting system, and in the case of NSF checks, that payment has been rejected.

n. Generate alerts or contain workflow processes to notify the field office employee that an order must be filled.

o. Generate an invoice.

p. Generate receipts that contain a unique alpha/numeric field that can be used to trace the order to the invoice, payment, and applicable programmatic system (i.e., the system that contains the source information that is being requested).

q. “Remember” the requestor’s name, address, telephone number, and email address, and include this information in a local drop-down or search list so that it can be readily recalled and not have to be re-entered for the same requestor. However, the system must not store credit card numbers, dates of birth, or Social Security Numbers.

r. Enter the name and last four digits of the SSN of the person whose information is being requested.

s. Identify the SSA user’s component (e.g., region, area, field office) without the user entering this information.

t. Process customer transactions by the public and third parties for walk-in, mailed, or faxed requests.

u. Automatically transmit collection data to the Accounts Receivable module in SSOARS in real-time.

v. Support secure transactions that will include card encryption and tokenization capabilities that comply with existing PCI-DSS and Payment Application-Data Security Standards (PA-DSS).

w. Be in compliance with FIPS 140-2, “Security Requirements for Cryptographic Modules,” National Institute of Standards and Technology guidance in Special Publication 800-53, “Recommended Security Controls for Federal Information Systems and Organizations.”

x. Support the use of Point-to-Point Encryption (P2PE) as defined by the PCI Security Standards Council. Have the capability to encrypt the branded plastic card information in accordance with the PCI DSS P2PE standards. The solution must meet Level 2 or higher compliance with the cryptographic controls specified in FIPS 140-2, Security Requirements for Cryptographic Modules.”

y. Process cancellations, modifications, and re-invoicing in instances where the customer wishes to cancel or modify a transaction. Also, must be able to process reversals for transactions that are timed out or are unsuccessful due to network issues, power failures, etc. The reversals must be performed in real-time with no manual intervention required.

z. Support real-time integration between SERS and SSOARS. This shall be a technology or technologies that work with SSOARS’ existing server and database technology stack (currently UNIX-based and Oracle Database). These internal interfaces must be implementable out of the box, with no customization required for SERS to communicate with SSOARS. Any configurations must adhere to the change control processes identified in requirement 6.4 of the PCI-DSS.

aa. Support real time communications with other SSA applications and databases. The interfaces to other SSA systems must support, at a minimum, Mainframe-based systems, (e.g., CICS applications, Cold Fusion applications, WebSphere Applications), Linux/Unix based systems, and Windows based systems. External interfaces must be based on non-proprietary protocols.

ab. Be UNIX-based and supportable within the current SSOARS technology environment. SSA will not support an additional hardware platform for the implementation of SERS. Any required infrastructure must be supportable within the current SSOARS Unix-based environment.

ac. Configure additional SSA workloads and collection types listed in Section B-10.2.

ad. Ensure that the scanned check amount matches what is entered by users in SERS and alerting the user if it does not match.

ae. Flag duplicate entries in the check scanning process.

af. Receive a file from Treasury to perform reconciliations of data that is transmitted from SERS to Treasury.

ag. Configure to work with Treasury’s check scanning devices.

ah. Be capable of transmitting check information (both data and image) to Treasury’s OTCNet Application. http://www.fms.treas.gov/otcnet/index.html

ai. Have the capability to create two separate image files: one for administrative fees to be retained centrally and sent to Treasury and a second file for program debt that contains the check image and the payment stub scan line (see format in Attachment 3) to be forwarded to SSA’s Mid-Atlantic Program Service Center.

aj. Index check image files to perform searches based on key data on the check image.

ak. Verify scanned check information against a Treasury Negative Check Database maintained on SSA’s network.

al. Produce Management Information (MI) Reports that provide number of fees by type, office location, and process that were invoiced, receipted, abandoned, (i.e., requestor withdrew request during transaction), collected, and not collected (due to NSF check).

am. Produce MI reports or dashboards that provide the total amount billed, total amount receipted, total amount collected, total amount due and total number of services performed by type, area, office and customer.

an. Produce MI Reports that are only available to authorized users, e.g., a regional office may access any office’s information within their region but not in any other region. An Area Director may access only those field office reports and data that come under that person’s jurisdiction. A field office can only access its own data and reports. Authorized Headquarters components may access all data.

ao. Execute a Key Confidentiality Agreement and a Mutual Nondisclosure Agreement with Vantiv. See Attachments 4 and 5.

ap. Address how post-implementation support and maintenance will be handled.

aq. Whenever a request is made “remotely” (i.e. a person is not actually present) and the payment is rejected/denied, the system shall be capable of generating an SSA-composed form letter to the requestor advising that the branded plastic card or check submitted for payment was rejected/denied.

B-5 GATEWAY SERVICES MANDATORY REQUIREMENTS

This solution must be fully integrated with the E-Commerce solution described in Section B-4. The contractor’s solution shall:

a. Provide a secure branded plastic card transaction processing solution. Secure transactions must include card encryption and tokenization capabilities that comply with PCI- DSS, PA-DSS, P2PE, and SSA Security Standards. Additional, detailed information on PCI Standards and Requirements is found in Section B-6 below.

b. Not expose any existing systems to PCI audits and network scans.

c. Provide the necessary functionality for the application to connect securely to the banking system, serving as the middleware communications module for payment card authorizations and settlement files.

d. Feature a card reader that has the capability to accept any type of branded plastic card.

e. Feature a card reader that has the capability for a customer to enter manually their card number if the branded plastic card fails to be read by the device.

f. Feature a card reader capable of accepting a signature.

g. Feature a card reader that is “plug and play” (i.e., when installing or replacing these devices, no configuration or installation of software other than self-installing drivers should be required).

h. Include the card reader as part of the total solution. As specified in each Task Order, the contractor will ship the card readers to the SSA field offices listed in Attachment 2. Details on stocking “Hot Standby” card readers are located in Section B-22.

i. Integrate the E-Commerce software to Vantiv for real-time authorization / funds capture at the point-of-sale.

j. Provide the communication between the E-Commerce application and the card reader to initiate payment processing and to receive authorization.

k. Utilize COTS software. It may be configured or extended, but these configurations and extensions must not interfere with ease of maintenance or upgrade of the Gateway Services or the E-Commerce and SSOARS applications.

l. Automatically build a list of transactions that have been authorized and delivered, and create a settlement file.

m. Transmit the settlement file to the processor and track the processor’s acceptance.

n. Automatically settle branded plastic card transactions periodically (minimum of daily) with Vantiv.

o. Process reversals, e.g., instances where the customer wishes to cancel the transaction, and for transactions that are timed out or are unsuccessful due to network issues, power failures, etc. The reversals must be performed in real-time with no manual intervention required.

p. Store no branded plastic card account numbers anywhere on SSA’s workstations or network.

q. Handle recurring payments without storing any branded plastic card information on the SSA side

r. Require no additional servers for the proposed solution.

s. Be offered by a contractor who is an active Vantiv Certified Partner.

t. Accept a 3DES key from Vantiv.

u. Allow SSA to order additional replacement card readers as needed. See Section B-7 Card Readers and B-22 Hot Standbys.

v. Address how post-implementation support and maintenance will be handled.

w. Feature a card reader that includes, at a minimum, a 2-year “Parts and Labor” warranty.

x. The Gateway Services must be provided for the entire 60 month contract period.

B-6 PAYMENT CARD INDUSTRY STANDARDS AND REQUIREMENTS

The Contractor’s proposed total solution, for software, card readers, and services must be compliant with the requirements and practices of the Payment Card Industry-Data Security Standard (PCI-DSS) Refer to https://www.pcisecuritystandards.org/.

Fourteen days after award, the contractor must submit to the COTR their most recent Report on Compliance (ROC) of PCI-DSS compliance, including the results of hardware and software reviews against applicable PCI-DSS standards. The report must address their progress on the PCI-DSS standards listed immediately below. Please note: these standards will be in place for the solution throughout the life of the contract.

PCI-DSS-related standards:

a. Meet Point-to-Point Encryption (P2PE) and tokenization technology for “card present” and “card not present” scenarios.

b. Provide third-party key management capability.

c. Meet PCI Personal Identification Number (PIN) Transaction Security requirements for all PIN Entry Devices (PEDs).

d. Be Payment Application Data-Security Standard (PA-DSS) certified.

e. Comply with all binding federal information security guidance and standards including FIPS 140-2, “Security Requirements for Cryptographic Modules,” and National Institute of Standards and Technology guidance in Special Publication 800-53, “Recommended Security Controls for Federal Information Systems and Organizations.”

f. Comply with PCI-DSS requirements for any modifications made to the base software, e.g., any modifications must adhere to the control processes in Requirement 6.4 of the PCI-DSS.

g. Support retention and purging of data.

h. Meet the requirements of Section 2.2.1 of PCI-DSS that specify that servers perform only one primary function each.

i. Meet the requirements of Section 9.4. of PCI-DSS that specify the capability to capture an audit trail for transactions, including the capability to reconstruct a transaction from the audit trail.

j. Meet the requirements of Section 10.3 of the PCI-DSS that specify that the following data be captured for all system components for every event: user ID, type of event, data and time, success or failure; name of affected data, system component or resource

k. Include an Incident Response Plan (IRP) for the SSA cardholder data. The IRP should include the following: type of incidents in which data has been compromised (lost, leaked, or stolen) and appropriate responses; entities to be notified (SSA, card issuing banks, card brands, Federal Trade Commission, and/or individuals), under what circumstances, and the associated timeframes for notification; if data compromised is the result of a malicious attack, identify the attack vector and take steps to address the relevant vulnerability, and if data compromised is the result of human (personnel) error, define the appropriate recourse. The IRP should include a notification provision that all incidents will be reported to SSA within one hour.

l. Comply with the Privacy Act; Federal Information Security Management Act (FISMA); Office of Management and Budget “Breach Notification Policy”, and OMB Memorandum M-06-19, “Reporting Incidents Involving Personally Identifiable Information and Incorporating the Cost for Security in Agency Information Technology Investments, July 12, 2006.”

m. Meet the requirements of Section 3.1 of PCI-DSS that specify that a limited amount of data be stored; acceptable methods of disposal; and a stipulation that cardholder data be retained only as long as required for legal and regulatory purposes.

n. Meet the requirements of Section 3.3 of PCI-DSS that specify that the solution not display Primary Account Number (PAN) data except for employees and businesses with a legitimate business need.

B-7 CARD READERS

The contractor must provide the plastic card readers required to process branded plastic cards as part of an overall solution. Card readers proposed by the contractor must be PCI PIN Transaction Security, Version 3.

SSA requires the contractor to provide two card readers for each field office as specified in each Task Order. At a minimum, one reader will be installed near the “front counter” service area for walk-in customers, and one reader will be installed in the “back office” for operation by SSA field office personnel. In the event of heavy usage in an individual field office, SSA reserves the right to increase that number as needed.

The contractor shall include in the price a warranty for 2 years, which includes parts and labor.

Additionally each Regional Office will maintain a supply of “Hot Standby” card readers for replacement purposes. Details on stocking “Hot Standby” card readers is located in Section B-22. There are currently 10 Regional Offices (see http://www.socialsecurity.gov/regions/). The Government will be able to reorder additional replacements as and when needed.

B-8 CHECK SCANNERS

Check scanners will be provided by the Department of Treasury via an Inter-Agency Agreement with SSA.

As indicated in the, Section B-4, the contractor must ensure that the solution is capable of being configured to work with the check scanners, and of transmitting check information (both data and image) to Treasury’s OTCNet Application. In no instance will this contractor be responsible for “tweaking” the actual check scanners.

For security reasons, the complete Treasury file layout specifications are not included in this Statement of Work. SSA will make the full details about the file layouts and any other specifications for transmitting check data to Treasury available to the SERS contractor within 1 week after award. The following description is provided for some of the Department of Treasury documents OTCNet Interface Specification Summary The purpose of the document is to identify how to send check data in batches to Treasury’s application, get acknowledgements back on those batches, download returned transaction data, and download deposit ticket data.

The document describes the process and the required security settings to allow negotiation of connections to the Treasury application.

The document describes the web services that are used to upload batch files, get acknowledgement of the batch files uploaded, download a returned transaction database, and download deposit ticket data.

The document describes the data schemas supported by the Treasury application.

· Batch Transmission Schema – xsd

· Batch Acknowledgement does not have an xsd.

· Base – xsd (referred to by other schemas)

· Returned Transaction Data – xsd

· Deposit Ticket Data – xsd

The document describes the following Web Service Definition Languages (WSDLs) supported by the Treasury application.

· POS wsdl Note: There are data encryption expectations defined in this specification which must be met.

The specifications for the check scanners are:

B-9 LEVEL OF EXPERTISE/LABOR CATEGORIES

A. LEVEL OF EXPERTISE

The contractor shall provide the needed expertise and level of experience necessary to successfully meet the Agency’s objectives. In addition to the basic qualifications, the qualifications of personnel assigned to each task performed under this contract shall include the specific expertise required for performance under the task order.

B. LABOR CATEGORIES

This space is RESERVED for the labor categories that will be incorporated into the final award.

B-10 IMPLEMENTATION

B-10.1 PHASED IMPLEMENTATION SCHEDULE

SERS will be implemented in two phases. Phase 1 includes installation, integration, and validation, which, if successful, will be followed by implementation in 20 SSA field offices and in the Office of Finance at SSA Headquarters. The field office locations will be determined after award. Phase 1 will demonstrate the functionality of the contractor’s solution and a successful resolution of all functional and technical issues. A nationwide rollout to all field offices will follow in Phase 2, as specified at the Task Order level. The full rollout in Phase 2 is contingent on a positive outcome in Phase 1.

Contractor labor will only be required at SSA Headquarters in Woodlawn, Maryland. No contractor labor or travel will be required at field office locations.

It is SSA’s expectation that the implementation schedule for the approximately 1,300 field offices will be as follows:

Testing in 20 pilot field sites and one office at SSA Headquarters

· Approximately 40-50 card readers will be delivered.

· Approximately 2,560 card readers will be delivered for the six month period.

B-10.2 IMPLEMENTATION TASK REQUIREMENTS

In addition to providing the E-Commerce Software and Gateway Services, the Contractor must perform the following implementation tasks:

· Integration of the Software into SSA’s existing SSOARS environment to support branded plastic card and check processing.

· Implementation will take place in accordance with the schedule above in Section B-10.1. .

· Define and configure of up to 25 items for use with the Software. Currently, these items are: copy an Electronic Folder, copy a Paper Folder, Letter Forwarding, Third Party Manual SSN Verification, Regional Office Certification, OCO Certification, and W2/W3 requests.

· Design, develop, document, implement, and test configurations to the existing SSOARS financial modules to support the SERS implementation. These configurations must support the SERS implementation and not negatively impact existing SSOARS functionality in these modules. Contractor is responsible for implementing these changes in development and validation lifecycle environments and is responsible for the preparation of a detailed document defining how to implement these same changes in our pre-production and production environments. Pre-Production and production implementation will be performed by SSA’s remote Application Database Administrators (ADBAs) and SSA staff with contractor assistance and guidance.

The existing SSOARS modules are:

· Oracle Receivables

· Oracle Payments

· Oracle Payables

· Oracle General Ledger

· Oracle Purchasing

· Oracle Federal Vertical

· Provide documentation in accordance with the contractor’s Proposed Project Management Plan in B-15.

B-11 MANAGEMENT INFORMATION REPORTING FUNCTION

SERS will require a reporting function for the production of Management Information (MI) Reports. These MI Reports shall be an output of the E-Commerce software once implemented and are not to be confused with Monthly Status reports that will be generated “manually” by the contractor to the COTR to report on project implementation. (See B-17).

At a minimum, the solution must capture the following data elements for use in MI Reports:

· Total transaction counts;

· Type of transaction (card reader or check scanner);

· Type of request (1st or 3rd party);

· Time-frames (fiscal year, quarter, month, and week ending; current and previous fiscal years-to-date; the ability to choose a range of week-ending dates);

· Organizational hierarchies (agency, region, office, area, and zip code levels, and component-level breakouts);

· Totals (e.g., the number of branded plastic card transactions plus the number of check scanner transactions should equal the overall number of transactions for any given period).

· MI should also be scalable to accommodate any changes, including the addition of non-standardized reports in the future. The MI reporting feature should be provided in such a way that end-users can configure individual “dashboards” or web pages to report on any of the above information.

B-12 ORACLE CERTIFIED PARTNER

The Prime Contractor must be an Oracle Certified Partner, at the Gold Level or higher.

B-13 SECURITY REQUIREMENTS

All on-site contractor personnel working under the authority of this contract must obtain a Security/Clearance Background Check in accordance with SSA’s System Security and Suitability Procedures. All Contractor personnel must obtain a level 5C- Moderate Risk-Public Trust designation. The terms and conditions for receiving and maintaining security clearance are found in Section E-3, E-4, E-5, E-6 and E-7.

The regulatory authorities for the personnel security are found in Executive Order 10450, Executive Order 12968, OMB Circular A-130, The Computer Security Act of 1987 and Title 5, Code of Federal Regulations (CFR) Parts 731,732, and 736.

In the event any contractor personnel does not have a current, SSA accepted security clearance at the time of award of the order, those individuals must undergo an appropriate Background Check in accordance with the requirements of Section E-3.

B-14 SOFTWARE ACCEPTANCE TESTING

SSA will conduct acceptance tests to validate the successful installation of the E-Commerce software and Gateway Services. The acceptance tests will verify that the contractor’s solution meets the requirements identified in the Statement of Work, and that test transactions will work from end-to-end in the system. Acceptance tests will be conducted during Phase 1 before proceeding with Phase 2.

These tests follow industry Standard System Development Life Cycle testing. Pre-Production end-to-end testing will include integration and load testing, and is conducted with contractor assistance by SSA’s Division of Integration and Environmental Testing (DIET). This testing provides assurances that all applications, configurations and systems changes are documented, tested and coordinated resulting in a complete integration into SSA’s production environment.

B-15 PROJECT MANAGEMENT PLAN AND MONTHLY STATUS REPORTS

B-15.1 Project Management Plan

Within 14 days of Contract Award, the contractor will provide to SSA a SERS Project Management Plan for Task Order 0001. This Plan must include :

· Deliverables, which shall include at a minimum

· Requirements Document

· System Design Document

· Configuration/Integration Plan

· Test Plan that includes test scripts to validate the entire business process.

· Road Map - The Road Map must cover the following topics:

· Technology architecture that details hardware and software required at each SSA field office, SSA Data Center and the responder’s Data Center.

· Detailed description of the flow of a transaction from the point…