iTRAK Attachment E - Service Level Agreement Requirements Final.pdf

Attachment E: Service Level Agreement Technical Requirements

SLA Requirements

Req ID # Requirement Source Mandatory or Value-Added

SLA-01: Infrastructure Support

SLA-01-01: General

SLA-01-01-01 Additional products needed to meet the SLAs will be the responsibility of the contractor. The contractor will also be responsible for the production control functions of the systems.

NSF

Requirement

M

SLA-01-01-02 The contractor will provide the data network designed and built in accordance with industry best practices.

NSF

Requirement M

SLA-01-01-03 The contractor will provide hardware, manage access to, and control the configuration of firewalls, switches, load balancers, and intrusion detection systems.

NSF

Requirement

M

SLA-01-01-04 The contractor must enforce the appropriate Configuration Management policies and practices as requested by NSF.

NSF

Requirement M

SLA-01-01-05 The contractor shall honor NSF’s requests to update or change access ports, Virtual IPs, and other configuration items.

NSF

Requirement M

SLA-01-01-06 The contractor shall honor NSF’s requests to update or change physical connectivity and changes to the physical network architecture as requested.

NSF

Requirement

M

SLA-01-02: Facilities

SLA-01-02-01 The contractor shall supply appropriate provisions for power, power conditioning, and power continuity.

NSF

Requirement M

SLA-01-02-02 The contractor shall supply appropriate NSF M provisions for air conditioning and ventilation. Requirement

SLA-01-02-03 The contractor shall provide appropriate space for racks and rack door openings.

NSF

Requirement M

SLA-01-02-04 The contractor shall supply appropriate fire detection and control.

NSF

Requirement M

SLA-01-03: Hardware

SLA-01-03-01 The contractor is responsible for providing the hardware and a detailed design of the system.

NSF

Requirement M

SLA-01-03-02 The contractor shall provide at minimum environments for Development, Integration, Testing (Staging and Acceptance), Training, Production, and Disaster Recovery.

NSF

Requirement

M

SLA-01-04: Connectivity

SLA-01-04-01 The proposed secure transmission facility must be compliant with Information Processing Standard (FIPS) 140-2.

NSF

Requirement M

SLA-01-04-02 The contractor will also be responsible for the configuration and maintenance of each DNS entry for the servers. NSF will supply valid DNS names as required.

NSF

Requirement

M

SLA-01-04-03 VPN connections to the servers from any remote location needs to be within the secure internet tunnel.

Secure internet tunnel” means a point to point Virtual Private Network (VPN) connection.

A virtual private network (VPN) is a secure way of connecting to a private Local Area Network

Network bandwidth requirements is 100K per user per second (for concurrent users)

NSF

Requirement

M

SLA-01-04-04 Additional network connections to selected recovery site only from selected primary site.

NSF

SLA-01-04-05 All connections entering the NSF selected network will possess a source Internet Protocol (IP) (TCP / IP) address range that is:

a) An American Registry of Internet Numbers (ARIN) registered address,

b) Registered to the customer (NSF)

NSF

Requirement

M

SLA-01-04-06 The IP address will be registered to the customer or related to the customer by reference from the IP address owner.

NSF

Requirement M

SLA-01-04-07 Connectivity entering the selected network will pass through several layers of network and server-based controls including Intrusion Detection Systems (IDS), packet filtering systems, and proxy filtering systems, as appropriate.

NSF

Requirement

M

SLA-02: Application Management

SLA-02-01: Software

SLA-02-01-01 The contractor will be responsible for the administration of the COTS.

NSF

Requirement M

SLA-02-01-02 The Contractor’s responsibility for application trouble-shooting includes providing trouble-shooting logs and other data, re-starts/recycling.

NSF

Requirement

M

SLA-02-01-03 The Contractor will make every reasonable effort to remain current with all software versions, patches or new releases. Appropriate testing is required to ensure that business functionality is not compromised by updates.

Patching and version upgrade functions for infrastructure software components will be done by the Contractor. Planned upgrades must be communicated to NSF in advance so they can complete regression testing prior to changes being implemented.

NSF

Requirement

M

SLA-02-02: Configuration Management

SLA-02-02-01 The contractor would provide a Configuration and Change Management Plan and gain approval from NSF. The Change Management Plan will include a description of how the contractor will inform NSF of all changes applied to the system. Changes to the User Interface and the system interfaces to the NSF applications need to be approved by NSF at time when changes are identified and prioritized.

NSF

Requirement

M

SLA-02-02-02 The contractor will maintain standard process and documentation for any functional changes.

An impact analysis document should be maintained for every change. All changes would be implemented only upon approval from NSF.

NSF

Requirement

M

SLA-02-02-03 The contractor should maintain a tool to capture version control and changes to the base requirements. The contractor is responsible for the software, licenses, and maintenance of the tool. The contractor will provide the required audit information to NSF.

NSF

Requirement

M

SLA-02-02-04 The Contractor should plan with appropriate documentation on all software upgrade, modifications, patches or any other system changes and get approval on the Release schedule from NSF.

NSF

Requirement

M

SLA-02-02-05 The Contractor shall certify applications are fully functional and operate correctly as intended on systems using the US Government Configuration Baseline (USGCB) (formerly Federal Desktop Core Configuration (FDCC)).

The USGCB common security configurations are available from the National Institute of Standards and Technology’s Web site at http://checklists.nist.gov .

NSF

Requirement

M

SLA-02-02-06 Applications designed for normal end users shall run in the standard user context without elevated privileges.

SLA-02-02-07 The Contractor shall implement software implementation, operation, maintenance, update, and/or patching in a manner that does not alter the configuration settings from the NSF approved configurations.

NSF

Requirement

M

SLA-02-02-08 The contractor will regularly provide NSF the detailed list of the implemented Production requests.

NSF

Requirement M

SLA-02-02-09 Where a system or application is approaching the End of Service Life (EOSL), where the vendor will no longer support the software or equipment, the Contractor will prepare a plan to migrate to a supported platform or version.

NSF will review the plan and approve it, or request modifications.

NSF

Requirement

M

SLA-03: System Performance

SLA-03-01: Capacity

SLA-03-01-01 System should support 561 individual and 100 concurrent users with a minimum of 4000 transactions a day. The contractor shall provide an incremental approach to adding users and costs.

NSF

Requirement

M

SLA-03-02: Availability

SLA-03-02-01 The system will be available 24 hours a day, 365 days a year. (99.95 % uptime for production) with the exception of scheduled down time agreed upon between the contractor and the NSF. Planned outages should be communicated to NSF at least six weeks in advance.

NSF

Requirement

M

SLA-03-02-02 Monitoring and metric reporting will be done by the contractor.

NSF

Requirement M

SLA-03-02-03 System performance and metric data must be provided to NSF on a regular basis.

SLA-03-02-04 Planned downtime must not correspond with core business hours of the iTRAK Users, 7 a.m.

EST to 8 p.m. EST Monday through Friday or during end of fiscal year processing.

NSF

Requirement

M

SLA-03-03: Integration

SLA-03-03-01 Each business transaction should be processed in iTRAK and sent back to the NSF systems with 2 seconds on a near real-time scenario.

NSF

Requirement M

SLA-03-03-02 In a near real-time scenario, upon failure to communicate the response to NSF systems, the system should make 5 consecutive tries within a duration of 60 seconds before throwing any exceptions.

NSF

Requirement

M

SLA-03-03-03 iTRAK should provide proper reconciliation reports for all business transactions through the interface.

NSF

Requirement M

SLA-03-03-04 The interfaces should be available 24x7x365 except on planned outages.

NSF

Requirement M

SLA-03-03-05 The interfaces should be able to support 50 concurrent transactions without performance degradation.

NSF

Requirement M

SLA-03-03-06 All changes to the interfaces endpoints should be documented and communicated to NSF at least 8 weeks in advance.

NSF

Requirement M

SLA-03-03-07 The data load from iTRAK to NSF staging area should happen on a daily basis (every 24 hours) or near/real time or on demand basis.

NSF

Requirement M

SLA-03-03-08 Supporting documentation (data dictionary, data model) on the data should be provided to

NSF.

NSF

Requirement M

SLA-03-03-09 Any planned outages should be notified to NSF at least 6 weeks in advance.

NSF

Requirement M

SLA-03-03-10 All production incidents should be responded with 2 hours. The incidents should be documented and communicated to NSF via proper communication channels and escalated to the IT Help Center.

SLA-03-03-11 The data transport mechanism should be secured per FIPS 140-2.

NSF

Requirement M

SLA-04: Security

SLA-04-01: General Security

SLA-04-01-01 The Contractor shall be responsible for Information Technology security for all systems used in performance of this contract, or those which are connected to a Government network.

This clause is applicable to all or any part of the contract that includes information technology resources or services in which the Contractor must have physical or electronic access to NSF’s information, including sensitive information and personally identifiable information, contained in unclassified systems that directly support the mission of the Agency.

This includes information technology, hardware, software, and the management, operation, maintenance, programming, and system administration of computer systems, networks, and telecommunications systems.

NSF

Requirement

M

SLA-04-01-02 1) Contractor provisioning and utilization of Information, systems, technology, and data in the performance of this contract shall be managed in compliance with security and privacy laws, regulations, guidance, and direction including but not limited to the:

a. Federal Information Security Management Act (FISMA);

b. National Institute of Standards and Technology (NIST) guidance;

c. Federal Information Processing Standards (FIPS) on information security;

d. Applicable Office of Management and Budget (OMB) memoranda;

NSF

Requirement

e. NSF policies, procedures and guidance.

SLA-04-01-03 The use of common security configurations is mandatory. This requirement must include all common security configurations for computing and networking systems, as available, to Contractor products and services delivered under this contract.

NSF

Requirement

M

SLA-04-01-04 The Contractor shall validate all common security configurations utilizing National Institute of Standards and Technology approved Security Content Automation Protocol (SCAP) validated tools.

NSF

Requirement

M

SLA-04-01-05 The default NSF requirement for NIST common security configurations is 100% compliance by the Contractor.

NSF

Requirement M

SLA-03-04-06 The Contractor shall not deviate from the NIST common security configurations without written authorization from NSF. The Contractor shall follow NSF's approval protocol when requesting deviation. A Contractor request for deviation does not imply an obligation for NSF approval.

NSF

Requirement

M

SLA-04-02: Physical Security

SLA-04-02-01 The Contractor shall maintain the systems required for this agreement, including any operational support systems in secure, access-controlled facilities.

NSF

Requirement

M

SLA-04-02-02 These facilities will comply with all required fire protection codes.

SLA-04-02-03 The storage facility must meet the following requirements:

a. Magnetic media protection must meet standards set by:

i. NFPA- The National Fire Protection Association

ii. NIST- The National Institute of Standards and Technology

iii. UL - Underwriters Laboratories

b. Fire detection and suppression must meet

UL and NFPA guidelines. U.L. Standards Listing:

i. UL 72: - Test for Fire Resistance of Record Protection Equipment

ii. UL 155: -Tests for Fire Resistance of Vault and File Room Doors

c. NFPA Standards Listing:

i. NFPA 232 Protections of Records

ii. NFPA 232A Guide for Fire Protection of Archives and Records Centers

iii. NFPA 80 Standard for Fire Doors and other openings

iv. NFPA 80A Recommended Practice for

Protection of Buildings from Exterior Fire Exposures

v. NFPA 12A Standard on Halon 1301 Fire Extinguishing Systems

vi. NFPA 72 National Fire Alarm Code

vii. NFPA75 Standard for the Protection of

Information Technology Equipment

d. NIST Standards listing:

i. NIST Pub 500-101 Care and Handling of Computer Magnetic Storage Media

ii. NIST Pub 500-199 Data Storage Risks, and Procedures to minimize

iii. NIST Pub 800-53 Security and Configuration Management

iv. Vault environment must meet the following temperature and humidity requirements:

v. Temperature: maintain between 60 and 70 degrees Fahrenheit

NSF

vi. Humidity: Maintain between 35 and 45 percent relative humidity

SLA-04-03: Monitoring

SLA-04-03-01 The contractor shall offer continuous monitoring and management of all servers, infrastructure software, networking equipment, and the application web interface.

NSF

Requirement

M

SLA-04-03-02 In case of detection of anomalies, the contractor shall provide appropriate notification to its own personnel assigned to NSF and to personnel designated by NSF. Staff from the contractor shall respond to the issue in a timely manner and work to correct it. The contractor shall provide reports detailing anomaly correction activities to NSF.

NSF

SLA-04-03-03 The contractor will perform a monthly vulnerability assessment with administrative credentials for all NSF-related systems (OS, databases and application software.) These scan results; along with any explanatory notes will be provided to NSF. These reports will be due within 24 hours for “Critical” exposures, and included on a monthly report for “High” and “Medium”

NSF defines “Critical” as a vulnerability that is being actively and widely exploited, with loss of control of either the machine or the data on it as a consequence.

The definitions of High, Medium and Low are defined for Common Vulnerabilities and Exposures (CVE) in the National Vulnerability Database (NVD) at http://nvd.nist.gov run by the National Institute of Standards and Technology (NIST)

NSF

Requirement

M

SLA-04-03-04 Where the scan reveals an exposure rated “Critical”, the Contractor shall implement remediation within 2 days. For “High” or “Moderate”, the Contractor shall implement remediation within 30 days.

NSF

Requirement

M

SLA-04-03-05 The contractor shall offer continuous monitoring and management of all servers, infrastructure software, networking equipment, and the application web interface. Contractor shall provide appropriate notification to its own personnel and to personnel designated by NSF for anomalies.

NSF

Requirement

M

SLA-04-03-06 The system must provide detailed logging and auditing capabilities, such as recording users' log-in and log-out events, as well as logging changes to data identified by NSF as important or sensitive data.

NSF

SLA-05: Data

SLA-05-01: Protection of Sensitive Information

SLA-05-01-01 All Contractor personnel are responsible for recognizing sensitive information and avoiding inappropriate or accidental access, use, or disclosure in accordance with NSF IT policies.

NSF

Requirement

M

SLA-05-01-02 Personally identifiable information (PII) refers to information which can be used to distinguish or trace an individual’s identity, such as their name, social security number, biometric records, etc., alone or when combined with other personal or identifying information which is linked or linkable to a specific individual, such as date and place of birth, mother’s maiden name, etc. All Contractor personnel are responsible for recognizing personally identifiable information and avoiding inappropriate or accidental access, use, or disclosure in accordance with NSF IT policies.

The Contractor is expected to provide a solution for masking data that meets NSF policy.

NSF

Requirement

M

SLA-05-01-03 The Contractor must not use or redistribute any and all NSF information except as specified in the Contract.

NSF

Requirement M

SLA-05-01-04 All Contractor personnel with access to the systems or applications covered under this contract must have training appropriate to their role. As well, they must complete annual Security Awareness Training (SAT), and the Contractor will provide certification to NSF that all personnel have successfully completed the

SAT.

NSF

SLA-05-01-05 In addition, personnel with enhanced access (security administrators, domain administrators, system administrators, DBAs, etc.) must also take at least one day (8 hours) of specialized security training per year. The course taken, date completed, and confirmation that the course was passed will be provided to NSF as part of the annual security assessment. This information will be included as part of NSF’s FISMA evaluation should the systems and applications in the contract be included in the FISMA review.

NSF

Requirement

M

SLA-05-01-06 The system must store sensitive data, including credit card numbers and Social Security Numbers, at the database level in an encrypted form using industry-standard encryption methods with 128-bit and higher encryption keys.

NSF

Requirement

M

SLA-05-02: Privacy Impact Assessment

SLA-05-02-01 Consistent with the E-Government Act of 2002 and in OMB Memorandum M-03-22, the Contractor will conduct a privacy impact assessment for the information system.

NSF

Requirement

M

SLA-05-02-02 PIAs are conducted to ensure that there is no collection, storage, access, use, or dissemination of identifiable information from or about members of the general public and businesses that is not needed or authorized, and that identifiable information that is collected is adequately protected. PIAs may address issues relating to the integrity and availability of data handled by a system, to the extent these issues are not already adequately addressed in a System Security Plan.

NSF

Requirement

M

SLA-06: Continuity of Operations

SLA-06-01: Backup/ Recovery

SLA-06-01-01 Daily and Weekly full backups must be taken by the contractor. A copy of the weekly backups must be created and stored in an approved facility.

NSF

Requirement

M

SLA-06-01-02 Requested restores by the NSF must be completed as soon as possible considering the restore media type and amount of data requested.

NSF

Requirement

M

SLA-06-01-03 All databases and software required to operate the systems will be backed up whenever changed, and backups retained for periods of time sufficient to ensure that restoration prior to a failure can be accomplished.

NSF

Requirement

M

SLA-06-01-04 Copies of the backups must be stored in a secure facility offsite from the primary systems.

NSF

Requirement M

SLA-06-01-05 Routine restoration of deleted files must not be dependent on the off-site versions.

NSF

Requirement M

SLA-06-02: Disaster Recovery

SLA-06-02-01 The Contractor must provide a contingency plan based on the NSF evaluation of the acceptable outage tolerance, using NIST SP 800-34 as guidance.

NSF

Requirement

M

SLA-06-02-02 The Contractor shall also provide a disaster recovery plan providing for complete recovery of Production environment services within 48 hours of the occurrence of a disaster. The DRP shall detail definitions of a disaster and level of service provided after a disaster recovery has occurred.

Recovery Time Objective (RTO) is within 48 hours.

Recovery Point Objective (RPO) is the back up of data up to the last 24 hours.

NSF

Requirement

M

SLA-06-02-03 All contingency and disaster recovery plans will be tested at least annually in coordination with

NSF M

the NSF exercises. Requirement

SLA-06-02-04 All facilities shall have power source appropriate to the criticality of the hosted systems, which may include battery power, on-site generators, and provision for re-fueling in the event of an extended power failure.

NSF

Requirement

M

SLA-07: User Support

SLA-07-01: Trouble Ticking, Tracking, Escalation

SLA-07-01-01 The Contractor’s responsibility for application trouble-shooting includes providing trouble-shooting logs and other data, re-starts/recycling.

NSF

Requirement

M

SLA-07-01-02 The contractor shall offer an automated mechanism for submitting and tracking support requests. The contractor shall indicate in its SLA what type of support request can be made, the maximum amount of time that will expire before work will commence on requests, and the maximum volume of support requests that can be submitted. These values will be agreed upon with the contractor before implementation.

NSF

Requirement

M

SLA-07-01-03 The contractor shall offer mechanisms for escalating support requests outside the normal support request mechanism if either a support request waits in queue for an excessive amount of time, or if the requestor feels that emergency actions are required. The contractor will have local representation in the Washington DC metropolitan area available for meeting.

NSF

Requirement

M

SLA-07-02: Help Desk Support

SLA-07-02-01 The contractor must provide Tier I, II, and III level support with the exception of business related issues, which need to be forwarded to NSF' Division of Financial Management (DFM).

The contractor will need to define issue escalation criteria as well as provide reports detailing the tracking of user calls.

SLA-07-02-02 Help Desk support for end users will be available five days a week, 7:00am – 7:00pm EST; excluding Federal holidays. Interactive Voice Response available 24x7.

NSF

Requirement

M

SLA-08: Audit

SLA-08-01: Right to Audit

SLA-08-01-01 The Contractor shall provide access to NSF designated personnel, including the Office of Inspector General, to the Contractor’s and sub- Contractors’ facilities, installations, operations, documentation, databases and personnel used in performance of the Contract. Access shall be provided to the extent required to carry out a program of IT inspection, investigation and audit to safeguard against threats and hazards to the integrity, availability and confidentiality of NSF data or to the function of computer systems operated on behalf of the NSF, and to preserve evidence of computer crime.

NSF

Requirement

M

SLA-08-01-02 NSF will provide two weeks’ notice for routine reviews, but reserves the right for immediate access in the event of a security incident

NSF

Requirement M

SLA-08-01-03 NSF intends to conduct reviews in conjunction with the annual Financial Audit and Federal Information Security Management Review (FISMA) evaluation.

NSF

Requirement

M

SLA-08-01-04 Access to Contractor personnel and systems is to be provided at no additional cost to NSF.

NSF

Requirement M

SLA-08-01-05 In the event of a security incident, NSF will negotiate cost sharing based on the results of the investigation.

SLA-08-01-06 Contractor personnel may be required to participate in NSF’ Computer Incident Response Team (CIRT) process.

The CIRT is a very important part of security.

If there is a serious security incident involving malicious software, a virus or hack into a system that results in the loss of availability, integrity or confidentiality of NSF data, a team consisting of NSF’s IT Security Officer (and others) and the vendor’s security or operations team must meet to remediate and report the issue. This is called the Computer Incident Response Team and is essential for system security.

NSF needs to be informed of any “incident” that potentially affects NSF data. NSF must work closely with the vendor to resolve the issue.

NSF

Requirement

M

SLA-08-01-07 The contractor shall provide assurance that the proper security practices are in place. NSF will periodically scan the applicable systems for vulnerabilities. NSF will provide two weeks’ notice prior to any scans, and will supply the Contractor with the results. Should the scan identify unremediated vulnerabilities, the Contractor will treat the remediation activities as an urgent change, however no additional charge to NSF will apply, as routine remediation falls under standard system maintenance.

NSF

Requirement

M

SLA-09: Reporting

SLA-09-01: Management Reporting

SLA-09-01-01 The Contractor shall provide routine reporting to NSF management on the security posture, outstanding vulnerabilities and remediation efforts, and other metrics as required by NSF.

NSF

Requirement

M

SLA-09-01-02 The reporting periods will include monthly, quarterly and annual documents. NSF will define which category each report falls into.

SLA-09-01-03 Reporting may include, but is not limited to, metrics such as patch management statistics, operating systems and application configuration compliance, vulnerability scan results and remediation status, Plan-of-Action-and- Milestones tracking, incidents, system administrator certification statistics, and security training statistics.

NSF

Requirement

M

SLA-09-01-04 Timing

a. The C&A activities will be done prior to service commencement (go live into Production,) and periodically thereafter as required by Federal or NSF policies. This is currently every three years.

b. On the years where a full C&A is not performed, there will still be a security assessment performed in accordance with the guidance in NIST SP 800-37.

c. Further details on timing are in the “Scheduling” section.

NSF

SLA-09-01-03 Requirements

a. The Contractor shall conform to all NSF policy guidance and reporting requirements regarding certification and accreditation of IT systems.

b. Certification and accreditation roles and responsibilities:

i. NSF shall perform all the certification activities as outlined in NIST SP 800-37, while the contractor will provide full support and documentation to NSF for this effort, in compliance with OMB Circular A-130

ii. Unless otherwise specified by NSF, NSF shall fulfill the roles of “Senior Agency Information Security Officer” and “Authorizing Official” as outlined in NIST SP 800-37 Appendix D.

c. Accreditation boundaries:

i. For all contractor-owned systems, NSF shall establish accreditation boundaries and certification schedules.

d. Certification Package

i. The Certification Package shall include at a minimum:

1. System categorization (FIPS 199)

2. Final IT System Security Plan

(SSP)

3. Security assessment report (risk assessment)

4. Plan of action and milestones, and

5. Disaster recovery/contingency plans.

e. The Contractor shall provide, implement and maintain an IT System Security Plan (SSP) using the process identified in NIST SP 800-37.

The IT SSP must comply with OMB Circular A- 130, Appendix III and recommendations in the NIST Special Publications 800-18, 800-30, 800- 34, 800-47, 800-50, 800-53, 800-53a, 800-61, and 800-70, as amended, extended, or superseded.

(1) The Contractor shall include an

NSF

interconnection security agreement (ISA) as appropriate for any connections to the NSF network.

(2) The Contractor shall submit an annual certification to the NSF Contracting Officer that the IT SSP remains valid.

f. Ongoing Tasks

i. Where the C&A security review identifies deficiencies, Plans of Actions and Milestones (POA&Ms) will be developed by the Contractor to address those deficiencies.

ii. Where the technology does not exist or is economically unjustifiable to address deficiencies, an Acceptance of Residual Risk (AORR) will be prepared by the Contractor for NSF approval. NSF may, at its sole discretion, accept or reject the AORR.

iii. Monthly status reports on the progress of implementing all POA&Ms will be prepared by the Contractor, and delivered to NSF.

SLA-09-01-04 Schedule

a. NSF and the Contractor shall jointly prepare and submit a Certification Package for the Contractor system to NSF Senior Management, per the following protocol:

i. Within 1 week of the contract being awarded NSF will provide the Contractor with a list of information required in order to complete the Security Risk Assessment (SRA).

ii. The Contractor shall submit the requested information and a completed System Security Plan (SSP), contingency and disaster recovery plans for NSF review and accreditation determination within 120 days prior to the "go live" date.

iii. NSF will review the Certification Package and the Contracting Officer will provide the Contractor with a determination of suitability: accepted or returned unaccepted for rework and resubmission. Accreditation follows acceptance.

iv. 120 days prior to the "go live" date the Contractor must submit the final versions of their sections of the Certification Packages to the NSF Contracting Officer for all CO and CO- Int systems.

1. Contractor Owned – Contractor owned IT systems used in the support of performance of this Contract that are other than incidental in nature (CO).

2. Contractor Owned – Interconnected: All Contractor owned systems that are directly connected with NSF owned networks or IT systems (CO-Int).

v. Failure to receive NSF approval of a Certification Package constitutes non-compliance and the Contracting Officer shall respond with administrative actions as allowed by the terms and conditions of the contract.

vi. Failure to receive NSF approval of a Certification Package constitutes non-compliance and the Contracting Officer shall

NSF

respond with administrative actions as allowed by the terms and conditions of the contract.

b. For the sustaining (Operations & Maintenance) contract period of performance, which begins with the conclusion of the formal contract start-up/initial transition period, the Contractor shall prepare and submit updates to the Certification Packages to the Contracting Officer for NSF review and accreditation decision as follows:

i. For all CO and CO-Int systems, NSF shall establish certification schedules, update milestones, and shall publish and maintain a master certification schedule showing all systems. This schedule shall be provided annually to the Contractor and shall be used to monitor Contractor performance.

ii. The Contractor shall update any outstanding POA&Ms, SSPs and other documents that may be required by NSF to show that an effective continuous monitoring and defect management regime is in place.

iii. Failure to receive NSF approval of a Certification Package constitutes non-compliance and the Contracting Officer shall respond with administrative actions as allowed by the terms and conditions of the contract.