Attch_0013_ACWS_DISA_SRF_Form_2016_05_20.docx

Unclassified

ACWS Attachment 0013 DISA SRF Form Solicitation Number: W52P1J-16-R-0058

ARMY CONTRACT WRITING SYSTEM

(ACWS)

Attachment 0013 ACWS_DISA_SRF_Form

1) Risk Reduction Phase

2) Builds 1 – N Phase (NIPRnet Only) Version 1.01 20 May 2016 Solicitation Number: W52P1J-16-R-0058

Prepared By:

Product Manager Army Contract Writing System (ACWS)

Changes:

· Minor edits to replace “RFP” with proposal

· Added Form #2 to provide Offerors a place to list Hosting Requirements for the Build 1 – N Phase (NIPRNet Only), the Host Requirements for SIPRNet will not be addressed until after Task Order 0001 is awarded.

· Inserted a new Interface List (embedded .pdf)

· Made edits to the Project Description for Risk Reduction and Build 1 – N phases

· Reminder: This combined form shall be submitted in Vol V, for Government planning purposes and is Not Evaluated.

Enterprise Information Services (EIS) Service Request Form (SRF) Server Hosting

Instructions: SRF Form #1 Risk Reduction Phase Offeror (SI) shall complete Yellow Highlighted area as noted below.

Form Part 1 - Project Overview The Project Overview captures key data about the project in a concise summary format.

· Section 1. System/Application Name – Completed by Government. Is unique and descriptive to avoid confusion with other systems. This is the official name registered in the Department of Defense (DoD) Information Technology (IT) Portfolio Repository (DITPR).

· Section 2. Partner – Completed by Government. The entity with authoritative control over requirements, and usually the entity funding the effort.

· Section 3. Project Title – Completed by Government. A unique name given to the project that is descriptive of the service being requested (e.g., New [Partner system] production web server, [Partner system] Test environment).

· Section 4. EIS Tracking Number – Completed by Government.

· Section 5. Priority. Completed by Government

· Section 6. Designated Hosting Site – Completed by Government. For existing workload indicate the hosting site.

· Section 7. Managing Site – Completed by Government. For existing workload indicate the managing site.

· Section 8. Project Description – Completed by Government. An executive summary of what is achieved through the implementation project and salient project attributes that may influence cost, technical, schedule or Information Assurance (IA) risk. The description must address at least the following topics. Any additional relevant information about the project should also be included.

· Partner’s goal

· Any known IA risks and potential impacts

· Major elements of the solution (e.g., Test and Development [T&D], Continuity of Operations [COOP], Partner equipment, etc.)

· Major phases of the project, as well as timeframes

· Any other unusual requirements or concerns (can be technical, political, etc.)

· Section 9. System/Application Description – Completed by Government. Should provide an overview of the key functional and technical elements of the system and describe what the system will do and look like at the conclusion of implementation. This content can sometimes be extracted from the existing IA accreditation package system description or other system documentation.

· Section 10. Operational Impact – Completed by Government.

· Sections 11, 12, 13, 14, 15 – Completed by Government.

· Sections 16-25. Accreditation Status – Completed by Government and Portions for SI to provide response and return with Proposal. Indicates if the workload has an Interim Authority to Test (IATT), Interim Authority to Operate (IATO document their plan to obtain an accreditation decision.

· Section 26. Completed by Government. Application Development Environment. Required after contract award. Development is the process by which something passes by degrees to a different stage (particularly a more advanced or mature stage). The definition includes many phases of the development lifecycle. Development of applications or software will be performed only on Security Technical Implementation guide (STIG) compliant platforms.

· Section 27. SI to provide response and return with Proposal. Critical Plans. Required after contract award. In accordance with DoD regulatory guidance, every organization or DoD information system-level IA program is required to have an appointed IA Manager (IAM) who develops and maintains critical plans related to IA architecture, IA requirements, IA objectives and policies; IA personnel; and IA processes and procedures.

· Section 28. SI to provide response and return with Proposal. Reviews/Assessments – Required after contract award. Every organization or DoD information system-level IA program is required to regularly and systematically assess the IA posture of information systems, IA services and supporting infrastructures through combinations of self-assessments, independent assessments and audits, formal testing and certification activities, host and network vulnerability or penetration testing, and IA program reviews.

· Section 29. Tool Compatibility – Completed by Government. The Enterprise System Management (ESM) software is the backbone of monitoring and reporting capabilities within the Defense Enterprise Computing Centers (DISAs) and is the key component in feeding the Network Operations (NetOps) environment. Under the sponsorship of the Enterprise-wide IA and Computer Network Defense Solutions Steering Group (ESSG), the Host Based Security System (HBSS) solution will be attached to each host in DoD.

· Section 30. SI to provide response and return with Proposal. Open Source Software (OSS) – Required after contract award. software for which the human-readable source code is available for use, study, reuse, modification, enhancement, and redistribution by the users of that software.

· Sections 31 - 34. Special Compliance Information – Completed by Government. used in the Service Level Agreement (SLA) to identify applications wherein the application data may require special compliance in cases of audit readiness or data calls. An application is not limited to containing only one type of Special Compliance Information; every category that pertains should be indicated. The categories are below:

· Personally Identifiable Information (PII) – refers to data such as people’s names, birth dates, and social security numbers. Training systems would qualify if they record the student’s name and SSN.

· Health Insurance Portability and Accountability Act (HIPAA) – refers to health information regarding patient medical records.

· Financial Systems – contribute, directly or indirectly, to an organization's financial statement. This includes machines that store or process information about assets, payments, financial obligations, or anything else that contributes to financial statement reporting. Examples include ATAAPS, DJMS, and most DFAS applications. If a system merely tracks and reports this type of information, but in no way contributes to a financial statement, it is not a financial system.

· Nuclear Information – indicate if the data being processed contained any information regarding nuclear weapons or warfare.

· Section 35. Data Access – Completed by Government. Used to identify applications wherein access via commercial or NIPRnet may require unrestricted, restricted, or private access.

· Section 36. CAC Enabled – Completed by Government.

· Sections 37-42. Completed by Government and Portions for SI to provide response and return with Proposal. Special Audits, Inspections, Assessments, and Tests – used in the SLA to identify workloads wherein the application requires additional audit services above the standard audit support provided. An application is not limited to containing only one type of Special Audit, Inspection, and Test; every category that pertains would be indicated. The categories are below:

· Statement on Standards for Attestation Engagements Number 16 (SSAE 16) – effectively replaces Statement on Auditing Standards Number 70 (SAS 70) that addresses engagements undertaken by a service auditor for reporting on controls at the service organization. The service auditors test and provide an opinion report on the fairness of presentation, suitability of design, and operating effectiveness of the service organization. Two types of SSAE 16 reports are to be issued, a Type 1 and a Type 2. Additionally, SSAE 16 requires that the service organization provide a description of its "system" along with a written assertion by management. Financial Improvement and Audit Readiness (FIAR) Guidance mandates reporting entities are responsible for ensuring that all key processes, systems, internal controls and supporting documentation impacting their financial reporting objectives are audit ready.

· Federal Information System Controls Audit Manual (FISCAM) – provides guidance for performing effective and efficient Information System (IS) control audits, either alone or as part of a performance audit, a financial audit, or an attestation engagement, including communication of any identified IS control weaknesses; and inform financial, performance, and attestation auditors about IS controls and related audit issues. Even though FISCAM is a manual, organizations refer to audits as FISCAM.

· Payment Card Industry (PCI) Data Security Standard (DSS) – a proprietary information security standard for organizations that handle cardholder information for the major debit, credit, prepaid, e-purse, Automatic Teller Machine (ATM), and Point of Sale (POS) cards. Defined by the Payment Card Industry Security Standards Council, the standard was created to increase controls around cardholder data to reduce credit card fraud via its exposure. Validation of compliance is done annually.

· C&A – set of procedures and assessments leading to a determination of the suitability of the system to operate in the targeted environment. C&A consists of procedures which encompass the entire life cycle of the system; is required before operations begin and at least every three years thereafter or whenever major security-relevant changes occur; and involves an annual IA Controls review.

· Incident Response – federal agencies are required to have in place cyber incident handling mechanisms in accordance with the FISMA (reference a) and Appendix III, Office of Management and Budget (OMB) circular No. A-130, “Management of Federal Information Resources” (reference b).

· Penetration Testing – to enhance the security posture of the DoD network enclaves with the goal to discover weaknesses in systems and/or enclaves before the adversaries discover them. Properly executed vulnerability and penetration tests can identify planning shortfalls, vulnerabilities, deviations from doctrine, and assist administrators in determining the correct countermeasures to mitigate detected weaknesses and enhance their security posture.

Section 43. Points of Contact. Completed by Government.

Sections 44 -47. Target Dates. Completed by Government. Negotiated with the Partner and represent schedule estimates. The Customer Management Executive (CME) team should be sensitive to these dates and proactively communicate with the Partner, as early as possible, whenever the dates are threatened.

Sections 48-51. Risk Assessment. SI to provide response and return with Proposal.

Form Part 2 - Implementation and Cutover Support Requirements The Implementation and Cutover Support Requirements section is intended to capture information and facts that have a material impact on the system implementation.

Section 1. Implementation Contacts. Completed by Government and Portions for SI to provide response and return with Proposal.

Section 2. Migration Requirements. SI to provide response and return with Proposal.

Section 3. Cutover Requirements. SI to provide response and return with Proposal.

Section 4. Performance Metrics. SI to provide response and return with Proposal.

Form Part 3 - Technical Requirements These sections collect details of your requirement that can be directly compiled into a functional specification for your EIS-Standard requirements and will help us assess your requirements better if they are non-standard. Consult the Service Catalog for additional details on our standard services or contact your CME team with questions about filling out this service request.

Note: The best method to add rows to any table in the SRF is as follows:

· Open the File tab, click “Info,” click the “Protect Document” drop-down, and select “Restrict Editing.” In the box that pops up on the right-hand side of the page, click on “Stop Protection.”

· Carefully highlight the entire last row in your table of choice, including the small ‘blank’ space just beyond the outside of the gridline.

· Right-click and select <Insert> and then select <Insert Rows Above>. A new, blank row is now added to your table.

· To populate the new row with a title and those grey input fields, copy a populated row and paste it into your new row. Change the title accordingly.

· Follow the instructions in the first bullet again, but this time click on “Yes, Start Enforcing Protection” in the box that opens on the right-hand side of the page. Do not enter a password and click “OK.”

Note: Check boxes cannot be used in the form unless the Restrict Editing function is turned on.

Form Part 4 - Standard and Optional Rate-Based Services The Implementation and Cutover Support Requirements section is intended to capture information and facts that have a material impact on the system implementation.

### END OF INSTRUCTIONS SRF Form # 1 of 2 ###

Risk Reduction (Only) Part 1 - Project Overview Project Version Control

Type of Server Requirement:

(select all that apply) |_| New Workload |_| Addition To, or Modification of, Existing DISA Workload |_| Federal Data Center Consolidation Initiative (FDCCI) Project Version:

1.

Date:

SRF Development History

Baseline Change Request (BCR) History

Part 1 - Project Overview Project Identification

9. Project Description – Describe project details, dependencies, and constraints below. Attach any relevant design specifications or documentation to this section.

This ACWS IDIQ contract will procure a COTS-CWS and management solution over a 5-year, up to 10-year, ordering period. Task Order 0001 will initiate the Risk Reduction phase and additional Task Orders will continue through Development & Deployment, to Operations & Support (Reference DoDI 5000.02, Model 3).

The Army Contract Writing System (ACWS) will be the Army's single, next-generation, enterprise-wide contract writing, management, execution, and close-out software system. ACWS will facilitate the standardization of Army Procurement business processes and improve data exchange and business process workflow with selected Army Enterprise Resource Planning (ERP) systems. As a financial feeder system, ACWS will meet the compliance requirements of the Federal Financial Management Improvement Act (FFMIA) of 1996.

The ACWS solution will meet the full scope of Army Contracting requirements and processes, including unique requirements in secure and non-secure locations, unique requirements supporting combat or non-combat contingencies, those within or outside the borders of the Continental United States, those supporting grants and assistance agreements, and those performing weapons systems, construction, installation, and other specialized contracting activities.

When deployed, ACWS will be used by approximately 10,000 end users in Government entities at approximately 300 different locations in support of installation, construction, medical services, expeditionary, transportation, and research and development contracting requirements.

See Attachment 0001 ACWS Statement of Objectives.

10. System/Application Description

Risk Reduction Environment: For the Risk Reduction phase of the contract (12 month period), ACWS will require a hosting environment for the “Out of the Box” COTS CWS Solution to support achieving the objectives as detailed in the Task Order 0001 Statement of Objectives.

11. Operational Impact

Availability [Uptime / (Uptime + Scheduled Downtime + Unscheduled Downtime)]

Restorability (Reliability) Recovery Time Objective (RTO) Recovery Point Objective (RPO) RTO = 24 Hours RPO = 12 Hours RTO = 8 Hours RPO = 6 Hours

Maintainability Mean Time To Repair (MTTR)

|_| Classified |X| Sensitive |X| NIPRNet |_| SIPRNet |_| Partner DAA Accredited Enclave (CDAE)

|_| IATT

|_| IATO

|_| ATO

|X| Not Accredited This system will be assessed for accreditation in accordance with the DoD Risk Management Framework.

SI provide prior accrediting information as applicable.

|_| Configuration Management Plan |_| Risk Management Plan |_| Vulnerability Management Plan |_| Patch Management Plan |_| Incident Response Plan |_| Continuity of Operations Plan |_| Disaster Recovery Plan |_| DoD 8500.2 IA Control Review Location of Review:

|_| Application Security and Development Review Location of Review:

|_| Privacy Impact Assessment Location of Assessment:

30. Tool Compatibility

HBSS |X| Yes |_| No |_| Unknown ESM Software |X| Yes |_| No |_| Unknown

Special Compliance Information (select all that apply)

|X| Restricted (authenticated .com) |X| Private (access from .mil only) |X| Yes |_| No

Special Audits, Inspections, Assessments, and Tests (select all that apply)

Target Dates Initial Operation Environment (IOE) Date – date that Operating Environments (OEs) are turned over to the application administrators for application load Initial Operating Capability (IOC) Date – date that OEs are configured for production users

Risk Assessment Note: IA risk can only be determined by the IA Technical Advisor

|_| High |_| Medium |_| Low |_| High |_| Medium |_| Low |_| High |_| Medium |_| Low

52. Enter Details of Any “High” or ‘Medium” Risks Noted:

SI to complete #48 – 51 with known information. Use the Risk Management Framework to define RISK.

Part 2 - Implementation and Cutover Support Requirements

1. Implementation Contacts

2. Migration Requirements

(e.g., DB Export, Flat File, OVA Image) File Transmission Method (Offline Copy, Online Copy (SFTP), Array-to-Array Replication, Application Replication) Migration Method (Import, Overlay, Mirror, OVA)

3. Cutover Requirements

4. Performance Metrics

Part 3 - Technical Requirements

1. Partner Disposition – Which of these statements best describes the Partner’s view of their technical requirements?

Other (fill in here): SI: Please review the objectives for the Risk Reduction efforts as detailed in the Task Order 0001 Statement of Objectives and make appropriate recommendation for this environment.

(“P” or R”)

SI to complete for what is known.

If T&D is a requirement, indicate the Zone where the workload will reside.

|_| Zone A |_| Zone B |_| Zone C |_| Zone D

3. OE Storage Requirements – Specify the storage that is required by each OE (usable storage in GB)

Total Usable Storage Required (in GBs):

4. Web Interfaces – Identify URLs required and their attributes Public – Any service intended to provide unclassified and non-sensitive information accessible from outside the NIPRNet, to include anonymous access.

Restricted – Any service intended to be accessible from the Internet and serves sensitive information to a limited set of users. Access controls are in place to limit the user set who can access the service.

Private – Any service meant to be accessed only from the NIPRNet or SIPRNet, respectively (.mil only).

(see definitions above) Load-balanced to Multiple Web Servers (Yes/No)

5. External System Communication Requirements – List the OEs that require communication with any external system. Specify the ports and protocols used by each. This does not include external access for administration by privileged users.

6. Internal System Communication Requirements – List the OEs that require communication with other OEs within the enclave. Specify the ports and protocols used by each.

7. Software Requirements – List all application software, tools and accessories. Do not include EIS-provided Enterprise Systems Management (ESM) software.

8. Open Source Software Requirements – List all open source software used. For open source, indicate whether or not the software has been DAA-approved. List additional information (i.e. licensing, vendor support, etc.) in the Notes column.

Software Vendor Software Name Version Information

9. User Authentication Requirements

Does user authentication / authorization require access to a remote resource (e.g., LDAP, AD)? |X| Yes |_| No

If Yes, who will manage the authentication / authorization database? CAC Enabled verified by Global Address List

10. Networking & Security

Describe any specific data protection requirements (e.g., data at rest) specified by the data owner.

N/A at this time. SI to complete for what is known.

Describe any interconnection requirements among DoD applications operating at different classification levels (e.g., SIPRNet to NIPRNet or vice versa).

NA at this time. SI to complete for what is known.

Describe any system-to-system interfaces with government agencies, commercial companies, foreign countries, etc.

See attached embedded file (ACWS Interfaces May 2016.pdf)

Characterize anticipated aggregate bandwidth requirements (data center inbound/outbound). (SI to Complete)

Load Balancing: Describe any local or global application and/or server load balancing requirements. (SI to Complete)

11. Local High Availability Requirements – Does the system require any specific local high availability feature for any specific OEs or functions (e.g., clustering, Oracle RAC)?

|_| Yes |_| No

If Yes, please elaborate on the requirement (if possible identify the OEs to be clustered and the type of clustering required, e.g., active, passive, RAC) below:

SI comment if needed.

12.

Remote or Second Site High Availability Requirements – Does the system require remote or second site high availability feature for any specific OEs or functions (e.g., remote failover, clustering, Oracle RAC)?

|_| Yes |_| No

If Yes, please elaborate on the requirement (if possible identify the OEs to be clustered and the type of clustering required, e.g., synchronous, asynchronous, RAC) below:

If comment if needed.

Part 4 - Standard and Optional Rate-Based Services

1. Core Services – Every workload hosted in the DISA is assessed Basic Services.

2. Optional Services – Standard solutions must include “Hardware Services” and may include any of the “Optional” service shown below. Review and check any requested optional services:

Application Support – Tier 2 Service Desk support of a dedicated application. Examples include running special jobs on behalf of users, re-running aborted jobs, loading new releases of functional-user software, etc. If application support is selected, it will be applied to all OEs associated with a Partner’s workload except for DISA-provided or Web Administration OEs.

Database Administration – Includes the labor to provide Database Administration support and to ensure databases comply with security guidelines. It only applies to Database servers.

Oracle Grid Control – Provides the EIS standard web based database monitoring and management interface to Partner DBAs. It is included if the Partner is paying for Database Administration, but can be selected as an option by those Partners who elect to perform their own DBA support. It is billed at 10 percent of the Database administration rate.

Database Software Maintenance – Maintenance of Oracle database software. Costs associated with this include the software maintenance and not the license itself. Note: DB Software Maintenance is a required service if EIS provides Oracle licenses.

24 x 7 System Administration – Provides seven days a week, 24 hours a day (24x7), full system administration support. Standard system administration support is part of Basic Services.

24 x 7 Application Support –Provides seven days a week, 24 hours a day (24x7), full application support. Select this option if the standard 8x5 with two hour after-hours response time is insufficient.

24 x 7 Database Administration – Provides seven days a week, 24 hours a day (24x7) full database administration support. Select this option if the standard 8x5 with two-hour after-hours response time is insufficient.

3. Conditional Services – Conditional services may be required depending upon the optional services selected. Review and check any applicable conditional services that apply:

Capacity Planning Reporting – Partners who maintain their own hardware and do not pay the Hardware Services rate may elect to receive capacity planning reports billed at 10 percent of the Hardware Services rate.

4. Service Continuity – If remote site COOP support is required, please select one of the options below:

(RTO = 5 days, RPO = 7 days) – MAC III applications only

(RTO = 5 days, RPO = 8 hours) – MAC III applications only

(Threshold RTO = 24 hours, RPO = 12 hours)

(RTO and RPO = 8 hours)

(RTO = 30 minutes, RPO = 1 Sec)

Note any special considerations related to your Service Continuity requirement here and provide more detailed specifications in the Non-Standard Requirements section, if applicable:

ACWS will be a collaborative effort between DISA and the ACWS PdM to successful implement and cutover to the Disaster Recovery environment.

No single points of failure on critical assets: redundant power supplies on servers, switches, and critical network components, dual comm paths but no clustering in the initial phase.

Establish/Select secondary data center locations for disaster recovery services. Data center services will include network, backup/recovery, and storage infrastructure to support both primary and secondary environments.

## End of SRF Form #1 Risk Reduction Phase ##

Enterprise Information Services (EIS) Service Request Form (SRF) Server Hosting

Instructions: Builds 1 – N DISA SRF Form (NIPRnet Only) Offeror (SI) shall complete Yellow Highlighted area as noted below.

Form Part 1 - Project Overview The Project Overview captures key data about the project in a concise summary format.

· Section 1. System/Application Name – Completed by Government. Is unique and descriptive to avoid confusion with other systems. This is the official name registered in the Department of Defense (DoD) Information Technology (IT) Portfolio Repository (DITPR).

· Section 2. Partner – Completed by Government. The entity with authoritative control over requirements, and usually the entity funding the effort.

· Section 3. Project Title – Completed by Government. A unique name given to the project that is descriptive of the service being requested (e.g., New [Partner system] production web server, [Partner system] Test environment).

· Section 4. EIS Tracking Number – Completed by Government.

· Section 5. Priority. Completed by Government

· Section 6. Designated Hosting Site – Completed by Government. For existing workload indicate the hosting site.

· Section 7. Managing Site – Completed by Government. For existing workload indicate the managing site.

· Section 8. Project Description – Completed by Government. An executive summary of what is achieved through the implementation project and salient project attributes that may influence cost, technical, schedule or Information Assurance (IA) risk. The description must address at least the following topics. Any additional relevant information about the project should also be included.

· Partner’s goal

· Any known IA risks and potential impacts

· Major elements of the solution (e.g., Test and Development [T&D], Continuity of Operations [COOP], Partner equipment, etc.)

· Major phases of the project, as well as timeframes

· Any other unusual requirements or concerns (can be technical, political, etc.)

· Section 9. System/Application Description – Completed by Government. Should provide an overview of the key functional and technical elements of the system and describe what the system will do and look like at the conclusion of implementation. This content can sometimes be extracted from the existing IA accreditation package system description or other system documentation.

· Section 10. Operational Impact – Completed by Government

· Sections 11, 12, 13, 14, 15 – Completed by Government.

· Sections 16-25. Accreditation Status – Completed by Government and Portions for SI to provide response and return with Proposal. Indicates if the workload has an Interim Authority to Test (IATT), Interim Authority to Operate (IATO document their plan to obtain an accreditation decision.

· Section 26. Completed by Government. Application Development Environment. Required after contract award. Development is the process by which something passes by degrees to a different stage (particularly a more advanced or mature stage). The definition includes many phases of the development lifecycle. Development of applications or software will be performed only on Security Technical Implementation guide (STIG) compliant platforms.

· Section 27. SI to provide response and return with Proposal. Critical Plans. Required after contract award. In accordance with DoD regulatory guidance, every organization or DoD information system-level IA program is required to have an appointed IA Manager (IAM) who develops and maintains critical plans related to IA architecture, IA requirements, IA objectives and policies; IA personnel; and IA processes and procedures.

· Section 28. SI to provide response and return with Proposal. Reviews/Assessments – Required after contract award. Every organization or DoD information system-level IA program is required to regularly and systematically assess the IA posture of information systems, IA services and supporting infrastructures through combinations of self-assessments, independent assessments and audits, formal testing and certification activities, host and network vulnerability or penetration testing, and IA program reviews.

· Section 29. Tool Compatibility – Completed by Government. The Enterprise System Management (ESM) software is the backbone of monitoring and reporting capabilities within the Defense Enterprise Computing Centers (DISAs) and is the key component in feeding the Network Operations (NetOps) environment. Under the sponsorship of the Enterprise-wide IA and Computer Network Defense Solutions Steering Group (ESSG), the Host Based Security System (HBSS) solution will be attached to each host in DoD.

· Section 30. SI to provide response and return with Proposal. Open Source Software (OSS) – Required after contract award. software for which the human-readable source code is available for use, study, reuse, modification, enhancement, and redistribution by the users of that software.

· Sections 31 - 34. Special Compliance Information – Completed by Government. used in the Service Level Agreement (SLA) to identify applications wherein the application data may require special compliance in cases of audit readiness or data calls. An application is not limited to containing only one type of Special Compliance Information; every category that pertains should be indicated. The categories are below:

· Personally Identifiable Information (PII) – refers to data such as people’s names, birth dates, and social security numbers. Training systems would qualify if they record the student’s name and SSN.

· Health Insurance Portability and Accountability Act (HIPAA) – refers to health information regarding patient medical records.

· Financial Systems – contribute, directly or indirectly, to an organization's financial statement. This includes machines that store or process information about assets, payments, financial obligations, or anything else that contributes to financial statement reporting. Examples include ATAAPS, DJMS, and most DFAS applications. If a system merely tracks and reports this type of information, but in no way contributes to a financial statement, it is not a financial system.

· Nuclear Information – indicate if the data being processed contained any information regarding nuclear weapons or warfare.

· Section 35. Data Access – Completed by Government. Used to identify applications wherein access via commercial or NIPRnet may require unrestricted, restricted, or private access.

· Section 36. CAC Enabled – Completed by Government.

· Sections 37-42. Completed by Government and Portions for SI to provide response and return with Proposal. Special Audits, Inspections, Assessments, and Tests – used in the SLA to identify workloads wherein the application requires additional audit services above the standard audit support provided. An application is not limited to containing only one type of Special Audit, Inspection, and Test; every category that pertains would be indicated. The categories are below:

· Statement on Standards for Attestation Engagements Number 16 (SSAE 16) – effectively replaces Statement on Auditing Standards Number 70 (SAS 70) that addresses engagements undertaken by a service auditor for reporting on controls at the service organization. The service auditors test and provide an opinion report on the fairness of presentation, suitability of design, and operating effectiveness of the service organization. Two types of SSAE 16 reports are to be issued, a Type 1 and a Type 2. Additionally, SSAE 16 requires that the service organization provide a description of its "system" along with a written assertion by management. Financial Improvement and Audit Readiness (FIAR) Guidance mandates reporting entities are responsible for ensuring that all key processes, systems, internal controls and supporting documentation impacting their financial reporting objectives are audit ready.

· Federal Information System Controls Audit Manual (FISCAM) – provides guidance for performing effective and efficient Information System (IS) control audits, either alone or as part of a performance audit, a financial audit, or an attestation engagement, including communication of any identified IS control weaknesses; and inform financial, performance, and attestation auditors about IS controls and related audit issues. Even though FISCAM is a manual, organizations refer to audits as FISCAM.

· Payment Card Industry (PCI) Data Security Standard (DSS) – a proprietary information security standard for organizations that handle cardholder information for the major debit, credit, prepaid, e-purse, Automatic Teller Machine (ATM), and Point of Sale (POS) cards. Defined by the Payment Card Industry Security Standards Council, the standard was created to increase controls around cardholder data to reduce credit card fraud via its exposure. Validation of compliance is done annually.

· C&A – set of procedures and assessments leading to a determination of the suitability of the system to operate in the targeted environment. C&A consists of procedures which encompass the entire life cycle of the system; is required before operations begin and at least every three years thereafter or whenever major security-relevant changes occur; and involves an annual IA Controls review.

· Incident Response – federal agencies are required to have in place cyber incident handling mechanisms in accordance with the FISMA (reference a) and Appendix III, Office of Management and Budget (OMB) circular No. A-130, “Management of Federal Information Resources” (reference b).

· Penetration Testing – to enhance the security posture of the DoD network enclaves with the goal to discover weaknesses in systems and/or enclaves before the adversaries discover them. Properly executed vulnerability and penetration tests can identify planning shortfalls, vulnerabilities, deviations from doctrine, and assist administrators in determining the correct countermeasures to mitigate detected weaknesses and enhance their security posture.

Section 43. Points of Contact. Completed by Government.

Sections 44 -47. Target Dates. Completed by Government. Negotiated with the Partner and represent schedule estimates. The Customer Management Executive (CME) team should be sensitive to these dates and proactively communicate with the Partner, as early as possible, whenever the dates are threatened.

Sections 48-51. Risk Assessment. SI to provide response and return with Proposal.

Form Part 2 - Implementation and Cutover Support Requirements The Implementation and Cutover Support Requirements section is intended to capture information and facts that have a material impact on the system implementation.

Section 1. Implementation Contacts. Completed by Government and Portions for SI to provide response and return with Proposal.

Section 2. Migration Requirements. SI to provide response and return with Proposal.

Section 3. Cutover Requirements. SI to provide response and return with Proposal.

Section 4. Performance Metrics. SI to provide response and return with Proposal.

Form Part 3 - Technical Requirements These sections collect details of your requirement that can be directly compiled into a functional specification for your EIS-Standard requirements and will help us assess your requirements better if they are non-standard. Consult the Service Catalog for additional details on our standard services or contact your CME team with questions about filling out this service request.

Note: The best method to add rows to any table in the SRF is as follows:

· Open the File tab, click “Info,” click the “Protect Document” drop-down, and select “Restrict Editing.” In the box that pops up on the right-hand side of the page, click on “Stop Protection.”

· Carefully highlight the entire last row in your table of choice, including the small ‘blank’ space just beyond the outside of the gridline.

· Right-click and select <Insert> and then select <Insert Rows Above>. A new, blank row is now added to your table.

· To populate the new row with a title and those grey input fields, copy a populated row and paste it into your new row. Change the title accordingly.

· Follow the instructions in the first bullet again, but this time click on “Yes, Start Enforcing Protection” in the box that opens on the right-hand side of the page. Do not enter a password and click “OK.”

Note: Check boxes cannot be used in the form unless the Restrict Editing function is turned on.

Form Part 4 - Standard and Optional Rate-Based Services The Implementation and Cutover Support Requirements section is intended to capture information and facts that have a material impact on the system implementation.

###…