Attachment I Statement of Work.docx

ADMISSIONS TECHNOLOGY

FOR UNITED STATES COAST GUARD ACADEMY (USCGA)

STATEMENT OF WORK

1.0 GENERAL.

1.1 SCOPE. The purpose of this Statement of Work (SOW) is to acquire Platform as a Service (PaaS) admissions technology for the U.S. Coast Guard Academy (USCGA) Admissions Division, capable of storing student, volunteer, educator and high school data; assessing outcomes; and delivering the technology needed to carry out marketing, communication, recruiting, selection, and enrollment processes.

1.2 BACKGROUND.

1.2.1 History. The Academy has used commercially hosted college admission platforms to fulfill its technology requirements since 2003. Migration from one platform to another takes one year of implementation. The basic capabilities sought are unchanged. They are:

· Communication and recruitment CRM (Customer Relationship Management) system configured for higher education and volunteer management

· Online admission applications configured for higher education

· Application management and decision systems configured for higher education

1.2.2 Current System. USCGA’s current PaaS is hosted by Campus Management and consists of three modules - Connect, Apply Yourself, and Application Review. Connect functions as the CRM for students, educators, and volunteers. The remaining modules are the online application and admission decision management platforms.

1.2.2.1 Programs. USCGA enrolls a about 1,000 full time students. Each year, about 2,100 applications are received from applicants seeking appointments in one of nine academic programs of study. Admission by major does not presently occur but this may change in the future if USCGA creates a proposed “School of Engineering and Science.” All enrolled students, even those with college credits, matriculate as first year, full time. USCGA does not award graduate degrees or certificates, only Bachelor of Science degrees.

1.2.2.2 Integrations. Current integrations are cumbersome and expose data to inadvertent disclosure. Data resides in two separate data bases, one that supports the application process, and one that supports CRM processes. Some application and decision data moves in one direction each night, from the application data base to the CRM. If a student record does not already exist in the CRM, Connect creates a new record using bridged data. Access to the complete student record is only possible by logging into each data base.

· Standardized test scores (from The College Board and ACT/NRCCUA) and medical qualification data (from the Department of Defense Medical Examination Review Board, or DODMERB) are imported to Connect and the legacy student information system known as REGIS. Each day, admissions staff export this data from REGIS then import it into the application data base.

· Connect collects and stores student data received from Front Rush (athletic recruiting data base).

· Staff manually import new student records from a variety of sources including YouVisit.com, Intersect, Cappex, search, business reply cards and so on. Students may also submit inquiry data via the Academy website, using a Connect data collection form. This data goes straight into the CRM data base.

· Connect hosts personalized urls (PURLS) for students, volunteers, and educators. In practice students use the PURLs primarily to monitor the status of their application.

· USCGA is tuition/room and board free and does not award financial aid in the traditional sense. Integration with financial aid awarding is not required.

· USCGA does not charge a fee for application but does collect fees for its one-week summer program. An integrated fee collection system does not currently exist but is desirable.

1.2.2.3 Applications. USCGA uses three applications. Two are for admission and the third is for its one-week summer program, known as AIM. These arrangements are also cumbersome.

· The online admission application is hosted in Apply Yourself and is open from August to mid-January each cycle.

· This application is modified and then reposted in early February for AIM, remaining open until April 1st. Client-generated configuration errors have plagued operations when moving from the admission application to the AIM application. Separate applications for the undergraduate program and AIM is desirable, along with the ability to simultaneously post both.

· USCGA admits about eight international cadets each year from an applicant pool of about 35. The application is a PDF form that is emailed to candidates. Full integration with the regular online application is desirable in the future.

1.2.2.3.1 It is possible that during the upcoming period of performance USCGA will begin to admit by major. Therefore, the next PaaS shall be able to enable this process change.

1.2.2.3.2 It is possible that during the upcoming period of performance the U.S. Congress will legislatively change the admission process by imposing a nomination system similar to what is used by the other federal service academies. Therefore, the next PaaS shall be able to track congressional offices, their nominees, nomination status; and associate this data with student records.

1.2.2.3.3 USCGA does not accept the Common Application now but might in the future. Therefore, the next PaaS should be compatible with the Common Application.

1.2.2.4 Customer and User Records. Currently USCGA maintains the following records in its CRM.

· 703 client/volunteer user accounts, of which 312 are active

· 1,500 educator records

· 2,000 volunteer records

· 208,747 student records (inquiries & applicants); 445,050 (also including prospects)

· About 19,000 new student records are created each admission cycle

1.2.2.5 Relationship to the Department of Defense (DOD). The U.S. Coast Guard abides by certain information security standards promulgated by DOD. These requirements are stated in this SOW and referenced in Section 6.0.

1.3 CONTRACTOR PERSONNEL.

1.3.1 Program Manager. The Contractor shall provide a Program Manager (PM) who is responsible for all Contractor work performed under this Contract. The PM is further designated as Key by the Government (See SOW1.4).

1.3.1.1 The PM is the main point of contact for the Contracting Officer and the Contracting Officer’s Representative (COR). It is anticipated the PM and alternate will be an experienced employee. The name of the PM, and the name(s) of any alternate(s) who shall act for the Contractor in the absence of the PM, will be provided to the Government as part of the Contractor's proposal. During any absence of the PM, only one alternate shall have full authority to act for the Contractor on all matters relating to work performed under this Contract. The PM and alternate shall be able to read, write, speak and understand English. Additionally, the Contractor shall not replace the PM without prior acknowledgement from the Contracting Officer.

1.3.1.2 The PM shall be available to the COR via telephone between the hours of 08:30 AM and 4:00 PM EST, Monday through Friday, with the exception of federal holidays and weather closings, and will respond to a request for discussion or resolution of problems within two hours of notification.

1.3.2 Qualified Personnel. The Contractor shall provide qualified personnel to perform all requirements specified under this Contract.

1.3.2.1 Contractor and Sub-Contractor employees performing work under this contract shall be lawful citizens or lawful permanent residents of the United States.

1.3.3 Employee Identification. Contractor employees visiting Government facilities shall wear an identification badge that displays the Contractor name, the employee’s photo, name, and badge expiration date. Visiting Contractor employees shall comply with all Government escort rules and requirements. All Contractor employees shall identify themselves as Contractors when their status is not readily apparent and display all identification and visitor badges in plain view above the waist at all times.

1.3.4 Employee conduct. Contractor employees shall present a professional appearance at all times and their conduct shall not reflect discredit upon the United States, the Department of Homeland Security, or the United States Coast Guard.

1.3.5 Removing Employees for Misconduct or Security Reasons. The Government may, at its sole discretion, direct the Contractor to remove any Contractor employee from U.S. Coast Guard facilities for misconduct or security reasons. Removal does not relieve the Contractor of the responsibility to continue providing the services required under this Contract. The Contracting Officer will provide the Contractor with a written explanation to support any request to remove an employee.

1.3.6 Conflict of Interest. The Contractor shall not employ any person who is an employee of the United States Government if that employment would or would appear to cause a conflict of interest.

1.3.7 Access to Personally Identifiable Data (PII). Contractor employee access to PII stored in the CRM shall be limited to those with a need to know in order to perform their duties.

1.4 KEY PERSONNEL.

Before replacing any individual designated as Key by the Government, the Contractor shall notify the Contracting Officer no less than 15 business days in advance, submit written justification for replacement, and provide the name and qualifications of any proposed substitute(s). All proposed substitutes shall possess qualifications equal to or superior to those of the Key person being replaced. The Contractor shall not replace Key Contractor personnel without acknowledgement from the Contracting Officer. The Government may designate additional Contractor personnel as Key in this Contract. (See HSAR Clause 3052.215-70).

1.5 CLASSIFIED INFORMATION.

Contractor access to classified information is not required under this contract.

1.6 PERIOD OF PERFORMANCE.

The period of performance for this contract is the base year plus option for up to nine years, awarded on an annual basis, commencing on date of award.

1.7 PLACE OF PERFORMANCE.

The primary place of performance will be the Contractor’s facilities.

1.8 HOURS OF OPERATION. It is anticipated Contractor employees shall perform work between the core hours of 8:30 AM and 4:00 PM EST, Monday through Friday (except Federal holidays and weather closings). However, there may be occasions when Contractor employees shall be required to work other than normal business hours, including weekends and holidays, to fulfill requirements under this contract.

1.9 TRAVEL.

Contractor travel beyond the minimum local commuting area of 50 miles from the primary place of performance may be required to support this contract. The Government will not reimburse the Contractor for travel to the primary place of performance. All travel required by the Government outside the local commuting area(s) will be reimbursed to the Contractor in accordance with the Federal Travel Regulations (FTR). The Contractor shall be responsible for obtaining COR approval (electronic mail is acceptable) for all reimbursable travel to include a budgeted amount in advance of each travel event.

1.10 KICK-OFF MEETING.

The Contractor shall attend a Kick-Off Meeting with the COR not later than five business days after the date of award. The purpose of the Kick-Off Meeting, which will be chaired by the Contracting Officer, is to discuss technical and contracting objectives of the statement of work and review the Contractor's project plan. The Kick-Off Meeting will be held by teleconference.

1.11 IMPLEMENTATION PLAN.

The Contractor shall provide a draft Implementation Plan at the Kick-Off Meeting for Government review and comment. The Contractor shall provide a final Implementation Plan to the COR not later than five business days after USCGA feedback is received. USCGA will provide feedback within 15 business days of receipt of the Implementation Plan. Contractor will lead the implementation process.

1.11.1 Offerors will explain their implementation process and provide references to project leaders at colleges that recently completed or are in the process of implementing the proposed CRM on their campuses.

1.11.2 Offerors shall document how the below list of implementation tasks are performed, differentiating between the work Contractor can or will do, versus what the Government is expected to do; flexibility possible in the proposed arrangement; pricing and the basis for pricing if any of the tasks listed below are not part of the proposed scope of work performed by the Offeror.

· Building web forms for data collection, including the application for admission and inquiry form

· Attribute definition and configuration

· Report building

· Data migration

· Event migration

· User account creation and role/permission assignment

· Import export configuration

· Standard query builds

· Custom query builds

· Email template build

· Testing

1.12 REPORTS.

The Program Manager shall provide a monthly status report to the COR and Contracting Officer via electronic mail on the 10th of the month for the previous calendar month (i.e. 10 March for February), or alternatively with a monthly invoice if that is the agreed upon billing cycle. The report includes an itemized list of projects and deliverables (if any), and accounting of funds. The Program Manager shall review the status and results of Contractor performance with the COR on an as required basis. The Government has seven business days to respond if not in concurrence with the report. The COR may chose to waive these reports.

1.13 PROGRESS MEETINGS.

The Program Manager shall be responsible for keeping the Contracting Officer and COR informed about Contractor and system status throughout the performance period. The Program Manager shall review the status and results of Contractor performance with the COR IAW with Section 1.12.

1.14 GENERAL REPORT REQUIREMENTS.

The Contractor shall provide all written reports in electronic format with read/write capability using applications that are compatible with Coast Guard Standard Workstation III (Windows XP and Microsoft Office Applications).

1.15

1.16 DATA RIGHTS.

The Government owns all USCGA data stored in the PaaS. Upon termination of this contract, the Contractor will delete all USCGA data from its records.

1.17 SECTION 508 REQUIREMENTS

1. When providing installation, configuration or integration services for ICT, the Contractor shall not reduce the original ICT item's level of Section 508 conformance prior to the services being performed.

2. When providing maintenance upgrades, substitutions, and replacements to ICT, the contractor shall not reduce the original ICT’s level of Section 508 conformance prior to upgrade, substitution or replacement. The agency reserves the right to request an Accessibility Conformance Report (ACR) for proposed upgrades, substitutions and replacements prior to acceptance. The ACR should be created using the on the Voluntary Product Accessibility Template Version 2.2 508 (or successor versions). The template can be located at https://www.itic.org/policy/accessibility/vpat

3. When providing Platform as a Service (PaaS) or Software as a Service (SaaS), the contractor shall ensure services conform to the applicable Section 508 standards (including the requirements in Chapter 5 for software and WCAG Level A and AA Level 2.0 success criteria for web and software. When the requirements in Chapter 5 do not address one or more software functions, the Contractor shall ensure conformance to the Functional Performance Criteria specified in Chapter 3.) The agency reserves the right to request an Accessibility Conformance Report (ACR) for PaaS and SaaS offerings. The ACR should be created using the Voluntary Product Accessibility Template Version 2.2 508 (or later). The template can be located at https://www.itic.org/policy/accessibility/vpat

4. When providing cloud hosting services (Infrastructure as a Service, Platform as a Service, Software as a Service, etc.) the Contractor shall ensure user administrative screens, dashboards and portals used to configure, and monitor cloud services conform to the Section 508 standards.

5. The Contractor shall ensure cloud hosting services shall not reduce the level of Section 508 conformance for ICT migrated by DHS to the cloud hosting environment.

6. When developing or modifying ICT, the Contractor is required to validate ICT deliverables for conformance to the applicable Section 508 requirements. Validation shall occur on a frequency that ensures Section 508 requirements is evaluated within each iteration and release that contains user interface functionality.

7. When modifying, installing, configuring or integrating commercially available or government-owned ICT, the Contractor shall not reduce the original ICT Item’s level of Section 508 conformance.

8. When developing or modifying web based and electronic content components, except for electronic documents and non-fillable forms provided in a Microsoft Office or Adobe PDF format, the Contractor shall demonstrate conformance to the applicable Section 508 standards (including WCAG 2.0 Level A and AA Success Criteria) by conducting testing using the DHS Trusted Tester for Web Methodology Version 5.0 or successor versions, and shall ensure testing is conducted by individuals who are certified by DHS on version 5.0 or successor versions (e.g. “DHS Certified Trusted Testers”). The Contractor shall provide the Trusted Tester Certification IDs to DHS upon request. Information on the DHS Trusted Tester for Web Methodology Version 5.0, related test tools, test reporting, training, and tester certification requirements is published at https://www.dhs.gov/trusted-tester.

9. When developing or modifying ICT deliverables that contain the ability to automatically generate electronic documents and forms in Microsoft Office and Adobe formats, or when the capability is provided to enable end users to design and author web based electronic content (i.e. surveys, dashboards, charts, data visualizations, etc.), the Contractor shall demonstrate the ability to ensure these outputs conform to the applicable Section 508 standards (including WCAG 2.0 Level A and AA Success Criteria). The Contractor shall demonstrate conformance by conducting testing and reporting test results based on representative sample outputs. For outputs produced as Microsoft Office and Adobe PDF file formats, the Contractor shall use the test methods published under “Accessibility Tests for Documents”, which are published at https://www.dhs.gov/compliance-test-processes. For outputs produced as web based electronic content, the Contractor shall use the DHS Trusted Tester for Web Methodology Version 5.0, or successor versions. This methodology is published at https://www.dhs.gov/trusted-tester

10. Contractor personnel shall possess the knowledge, skills and abilities necessary to address the accessibility requirements in this work statement.

1.17.2 Section 508 Deliverables (include in the SOW, PWS, or SOO)

1. Section 508 Test Plans: When developing or modifying ICT pursuant to this contract, the Contractor shall provide a detailed Section 508 Conformance Test Plan. The Test Plan shall describe the scope of components that will be tested, an explanation of the test process that will be used, when testing will be conducted during the project development life cycle, who will conduct the testing, how test results will be reported, and any key assumptions.

2. Section 508 Test Results: When developing or modifying ICT pursuant to this contract, the Contractor shall provide test results in accordance with the Section 508 Requirements for Technology Services provided in this solicitation.

3. Section 508 Accessibility Conformance Reports: For each ICT item offered through this contract (including commercially available products, and solutions consisting of ICT that are developed or modified pursuant to this contract), the Offeror shall provide an Accessibility Conformance Report (ACR) to document conformance claims against the applicable Section 508 standards. The ACR shall be based on the Voluntary Product Accessibility Template Version 2.0 508 (or successor versions). The template can be found at https://www.itic.org/policy/accessibility/vpat. Each ACR shall be completed by following all of the instructions provided in the template, including an explanation of the validation method used as a basis for the conformance claims in the report.

4. Other Section 508 Documentation: The following documentation shall be provided upon request for ICT items offered through this contract:

· Documentation of features provided to help achieve accessibility and usability for people with disabilities.

· Documentation on how to configure and install the ICT Item to support accessibility.

· Documentation of core functions that cannot be accessed by persons with disabilities.

· Documentation of remediation plans to address non-conformance to the Section 508 standards

1.18 GLOBAL DATA PROTECTION REGULATION (GDPR) COMPLIANCE. As a sovereign entity, the Government is exempt from the provisions of the European Union’s GDPR. However, as a matter of best-practice, the Government intends to acquire a PaaS that is GDPR compliant. Offerors will document in writing whether or not the platform is GDPR compliant.

1.19 CAN-SPAM COMPLIANCE. Platform shall be CAN-SPAM compliant. Offeror will document in writing how the platform is designed to help users reduce the adverse consequences of spam marking.

1.20 OTHER COMPLIANCE CONSIDERATIONS. The Government is obligated to comply with relevant provisions of References 6.3 – 6.5 noted below concerning the protection of PII.

2.0 GOVERNMENT TERMS & DEFINITIONS.

2.1 Admission Partners: Volunteers who help the USCGA Admissions staff recruit students

2.2 Applicant: A person who seeks admission to USCGA by submitting the admissions application

2.3 ACAS: Assured Compliance Assessment Tool

2.4 Cadet: An undergraduate student enrolled at USCGA

2.5 CAN-SPAM Act: Controlling the Assault of Non-Solicited Pornography and Marketing Act

2.6 Customer Relations Management System (CRM): A data base that stores data for purposes of recruiting and communicating with others

2.7 Communications Flow: A sequence of electronic, print, or internet based messages that are coordinated with each other to achieve a specific purpose in the process of recruiting a student

2.8 Contractor: The organization awarded this contract

2.9 Contracting Officer (KO): Person with the authority to enter into, administer and terminate contracts on behalf of the Government and to make related determinations and findings

2.10 Contracting Officer’s Representative (COR): Person designated in writing by a contracting officer to perform liaison between the Contractor and the contracting officer on contract technical matters

2.11 Customers: Students, volunteers, and educators with records stored in the data base.

2.12 DHS: Department of Homeland Security

2.13 DISA: Defense Information Security Agency

2.14 DOD: Department of Defense

2.15 DODMERB: Department of Defense Medical Examination Review Board. This organization coordinates the medical examinations which applicants are required to submit for admission

2.16 GDPR: General Data Protection Regulation (European Union standard)

2.17 GFI: Government Furnished Information

2.18 GFM: Government Furnished Materials

2.19 Government: The Government” in this SOW shall be interpreted to mean an authorized Government representative as designated by the KO

2.20 IA: Information Assurance

2.21 ICT: Information Communications Technology.

2.22 Information Technology Services (IT): The USCGA staff component that manages USCGA’s technical infrastructure

2.23 Inquiry: A student who expressed interest in USCGA

2.24 IP: Internet Protocol

2.25 Lead: An inquiry or applicant of interest to USCGA

2.26 NIST: National Institute of Standards and Technology

2.27 Offeror: An organization seeking award of this contract

2.28 PURLS: Personalized URL for communicating with students based on variable data

2.29 Readers: Admissions representatives who read and score applications for admissions and/or programs

2.30 REGIS: USCGA’s Student Information System

2.31 Source Code: A text field identifying the information source from which contact with a prospective student originated or occurred

2.32 STIG: Security Technical Implementation Guide

2.33 Users: Government employees and volunteers authorized to use the PaaS.

3.0 GOVERNMENT FURNISHED PROPERTY AND INFORMATION.

The Government will provide the following property and information to the Contractor for work required under this Contract:

· Content necessary to populate PURLs and forms, including applications

· Source Codes

· Logons for Connect, Apply Yourself, and Application Review

· Copies of filter criteria

· Copies of email communications

· USCGA branded artwork and color palette

· Export formats

· Data that will migrate to the new platform

· Website links

4.0 CONTRACTOR FURNISHED PROPERTY.

The Contractor shall furnish all facilities, materials, equipment and services necessary to fulfill the requirements of under this Contract, except for the Government Furnished Property specified in this work statement.

5.0 REQUIREMENTS. The Contractor shall furnish the necessary qualified personnel, materials, facilities, and services to provide the services and products on time, as required under this Contract.

5.1 ACCOUNT MANAGEMENT. The Contractor shall organize and provide management, supervision, personnel labor, material and equipment (except for Government furnished items) required to carry out this SOW.

5.2 DESIGN AND INTEGRATION. The PaaS offered by the Contractor shall be a commercial product designed to support college admission operations. The PaaS shall be web-enabled, hosted, maintained and supported by the Contractor in a secure environment. The PaaS shall be browser agnostic relative to those used commonly in the United States.

5.2.1 Offeror shall document in writing the tools and technologies used to build the CRM including coding languages, software engines, and the data base itself.

5.2.2 Data shall reside in a single data base, separated from the data of other Contractor clients.

5.2.3 PaaS will be capable of storing up to 800,000 records and handling up to 1,000 user accounts. The PaaS shall allow users to differentiate between “types” of records (ie, populations), specifically, students, educators, organizations, volunteers, and users.

5.2.3.1 The records of individuals shall be assigned a system generated, unique user ID other than Social Security Number.

5.2.3.2 PaaS shall ideally display, update, and store or access a comprehensive data base of U.S. high schools using the naming and numbering convention of the College Entrance Examination Board. PaaS shall allow customers to access this data base in order to submit profile and application data using data collection forms. PaaS shall permit users to add organizations to its data base.

5.2.3.3 Offerors shall document how the PaaS integrates with other data streams including:

· Standardized test score data from The College Board and ACT/NRCCUA

· Medical qualification data from DODMERB

· Commercially hosted platforms such as Naviance, Cappex, and Front Rush

· The Common Application

5.2.4 Interfaces. Platform shall present a uniform and consistent visual interface for customers and users.

5.2.4.1 Customer interface. Customers (students, volunteers, and educators) shall have access to a password protected, institutionally branded, internet accessible customer interface with the following features:

· Display of customer account, event registration, application, and profile information

· Responsive design that dynamically adapts to the customer’s device

· Login credential reset option and profile management features

· Auto-generated audit trail appended to individual records

5.2.4.2 User interface. Users shall have access to a password protected, permission based, internet accessible user interface to access, manage and configure the Government’s instance of the PaaS. Features shall include:

· Uses admissions terminology

· Configuration tools to customize displays

· Configurable dashboards to provide information relevant to the user’s roles

· Access to PaaS operational capabilities contingent on permission level

· Administrative console to manage user accounts and permission levels or roles

5.2.4.1 Users Enterprise Architecture Requirements.

The solution architecture and provided services shall be in compliance with DoD Information Impact Level 4, as outlined within the DoD Cloud Computing Security Guide (SRG) version v1r3.

(Reference: Cloud Computing SRG 5.1.5.1)

The solution shall be designed in alignment with the DoD Secure Cloud Computing Architecture (SCCA). DISA’s Secure Cloud Computing Architecture (SCCA) is a suite of enterprise-level cloud security and management services. It provides a standard approach for boundary and application-level security for Information Impact Level 4 level data hosted in commercial cloud environments.

ATO: The system shall have an Authority to Operate (ATO) in accordance with FISMA RMF within an Objective of nine (9) months; and Threshold of 12 months of contract award.

The Cloud Service Provider (CSP) will support the development of the solution’s ATO package. The CSP will develop and deliver the following documents utilizing templates provided by the USCG:

· System Architecture and Data Flow Diagram (Microsoft Visio)

· Ports Protocols and Service Management (PPSM)

The CSP will provide inputs to the USCG to the following documents on as needed basis in order to finalize the solution’s ATO package:

· System Security Plan (SSP)

· Plan of Actions and Milestones (POA&M)

5.3 OPERATIONAL CAPABILITIES. The PaaS offered by the Contractor shall deliver the following operational capabilities designed for admission users.

· Record creation and management

· Query building, export, foldering, and management

· Attribute and source code creation, configuration, and management

· Data collection and storage

· Admission application creation and management

· Application distribution, review/scoring, and management

· Event and interview creation and management including a searchable online registration interface for customers

· Communication system consisting of broadcast email and text

· Customizable behavioral and/or predictive scoring system

· Customizable reporting and assessment package

· Access to a support system

· Access to user training

· Account creation and management tools

· Hierarchical system of configurable user permissions and or roles to manage access to data and features

5.4 SECURITY. Contractor shall at all times prevent the unauthorized disclosure of PII. If unauthorized disclosure occurs, the Contractor will notify the COR immediately and in no case more than four hours after discovery. The Contractor will take immediate steps to mitigate the consequences of the disclosure. The Contractor will notify the COR of the full extent and nature of the disclosure as soon as practically possible.

5.4.3 The Contractor shall conduct a monthly ACAS or Nesses vulnerability assessment, or equivalent, and provide the results of the scan for review. Contractor will correct vulnerabilities based on mutual review with the Government, in a timely manner commensurate with level of risk.

5.4.4 Transmitted data. The PaaS shall use the latest DOD approved encryption algorithm to protect transmissions of data communicated over the web and within the system itself, using a FIPS 140-2 validated cryptomodule or most current equivalent.

5.4.5 Data at rest. Offerors shall document in writing the security practices used to guard against disruption, loss, and theft, such as:

· Password management

· IP restriction

· Role hierarchies, object level hierarchies, sharing rules and permission sets

· Password security

· Session time-out

· Login rules

· Anti-virus software and scans

· Cloud storage

5.4.6 Detection and Response. Offerors shall document in writing the detection and response practices in use, such as:

· Anti-virus software

· Independent third-party security audits and scans for malicious activity

· Scanning protocols

· Digital intrusion systems

· Disaster and recovery response protocols

5.4.7 Physical Security. Offerors shall document in writing the physical security measures in place to protect assets.

5.5 DATA HYGIENE. The PaaS shall deliver user-controlled capabilities for managing data:

· Data import and export interfaces and an audit trail

· Manual and automated record de-duplication

· File-foldering and archiving

· Customizable attributes and drop-down fields

· Bulk edits and bulk deletions of individual records

· Automated date/time audit trails when records are accessed, created or changed

· Option for users to append notes to records of individuals

5.6 COMMUNICATION. The PaaS shall have the following basic communication capabilities:

· Broadcast and ad-hoc email design, storage, programming and delivery

· Broadcast and ad-hoc text design, storage, programming and delivery

· Capability to design new email by duplicating older copy

· Campaign building and management

· Outcome metrics including but not limited to delivery rate, click throughs, views, unsubscribe requests, bounce rates; and analytics for campaign results

· Automated communication audit trail appended to student records

5.7 APPLICATION AND APPLICATION REVIEW

5.7.1 PaaS shall be able to host up to eight applications for admissions or programs at one time. PaaS shall permit status tracking for each application independent of other applications that may also associated with an individual’s record. Elements of each record currently include the items listed below, and may be subject to change.

· Data submitted by online form collection

· Medical qualification data

· Standardized test score data

· Recommendations

· Transcripts

· Essays

· Physical Fitness Exam form or scores

· Interview reports

· Record of the file distribution process

· Decision data resulting from the file review process

· Fee payment integration

5.7.2 Application data collection forms will prepopulate selected data fields when properly credentialed customers login to an application. Application will employ dynamic / conditional logic design and permit users to configure questions and response fields. PaaS will allow customers to start, save, and return to the application where s/he left off at a later time without loss of data.

5.7.3 Applications will render in responsive design that dynamically adapts to customer devices.

5.7.4 Based on permission levels, users will have the option to print applications in an easy to read file format such as PDF.

5.7.5 Features shall include an internet enabled file review system that allows the system manager (user) to batch, distribute files to readers (users); set deadlines; manage results and outcomes.

5.7.6 The review system in the PaaS shall allow the system manager (user) to define a scoring system, collect and store scores for individual records.

5.7.7 The PaaS shall ideally include a closed system for communicating privately with readers (a subset of users).

5.8 EVENT MANAGEMENT. The PaaS shall have the following basic capabilities:

· Manage on and off campus events; and interviews

· Integrated/automated reminder, confirmation and messaging system

· An online event registration portal with both calendar and search function

· Registration forms

· Ability to create a new individual record in the CRM for those who register for an event but have no existing record in the CRM; and to ensure that the individual is associated with her/his proper population (student, educator, volunteer)

· Ability to append PDF forms to event related communication

5.9 SYSTEM AVAILABILITY. The PaaS shall be available to users at least 98% of the time during the 18 contiguous hours of typical peak use, and at least 96% of the time off peak. The Contractor will notify the Government of planned outages at least 24 hours in advance.

5.10 TRAINING. Contractor shall provide training resources designed for users to efficiently acquire the skills needed to make optimal use of the PaaS based on assigned roles or permissions, and to locate instructions about using the PaaS independently.

5.10.1 The Contractor shall conduct on-site training for new users in New London before the system goes live.

5.11 SUPPORT. Contractor shall host a technical support system for users that is owned, operated, and staffed by the parent firm.

5.11.1 The support system shall operate during the core hours noted in this SOW and offer the option to prioritize requests, and/or escalate requests in order to differentiate between urgent and routine matters.

5.11.2 The support system shall include the option for user-to-support staff phone calls during core hours.

5.11.3 The support system shall acknowledge receipt of a support request within two working hours of receipt, track and display the status of support requests, and confirm when requests have been satisfied. Users will have the option to correspond real time or near real time with the support staff handling the request during the active phase of the response.

5.12 DEVELOPMENT ROADMAP. Offeror shall document the lifecycle plan for the platform and provide copy of the current development roadmap.

5.12.1 The Contractor shall update the Government periodically concerning its development plans and allow the COR to contribute input to development plans if the Contractor allows other clients to do so.

5.12.2 The Contractor shall provide no less than 36 months written notice if the PaaS is to be discontinued or replaced. If this date falls within the contracted period of performance in Section 1.16, the Contractor will also provide a migration plan to an equivalent or better platform, at no additional cost to the Government, unless such option is waived by the Government.

5. 13 ANCILLARY SERVICES AND CAPABILITIES. Offerors shall identify other services or capabilities not specifically required in this SOW in its response to this request.

6.0 REFERENCES.

· Section 508 Accessibility Standards

· Federal Information Security Management Act (FISMA)

· Department of Defense Instruction (DODI) 8510.01 Risk Management Framework (RMF) for DoD Information Technology (IT)

· DHS 4300A – Sensitive Systems Handbook

· NIST 800-53 (series) – Security and Privacy Controls for Federal Information Systems and Organizations

· NIST 800-146 – Cloud Computing Synopsis and Recommendations

· FIPS PUB 140-2, “Security Requirements for Cryptographic Modules”

· Department of Defense Directive Number 5400.11 dated October 29, 2014, “DoD Privacy Program”

7.0 DELIVERABLES.

7.1 DELIVERABLE ACCEPTANCE, REVISION, AND REJECTION.

All deliverables shall be submitted to the COR on the schedule contained in Section 7.0 unless otherwise specified. As a minimum, deliverables shall be free of defect and information therein shall be able to be validated.

Reports, documents, and narrative-type deliverables will be accepted when all discrepancies, errors or other deficiencies identified in writing by the Government have been corrected.

The COR will provide written acceptance, comments and/or change requests, if any, within ten (10) business days from receipt by the Government of the initial deliverable. Upon receipt of the Government comments, the Contractor shall have five (5) business days to incorporate the Government's comments and/or change requests and to resubmit the deliverable.

If written acceptance, comments and/or change requests are not issued by the Government within thirty (30) calendar days of submission, the draft deliverable shall be deemed acceptable as written and the Contractor may proceed with the submission of the final deliverable product. Absent written notification, final deliverables will be construed as accepted.

Non-conforming products or services will be rejected. All notifications of rejection will be accompanied with an explanation of the specific deficiencies causing the rejection. If the deficiencies cannot be corrected within 30 days, the Contractor will immediately notify the Contracting Officer of the reason for the delay and provide a proposed corrective action plan within ten (10) working days of the notification.