J.1-B Contract Data Requirements List (CDRL).pdf
PDF 1 MB Posted
- Attached to
- Space Flight Systems Development and Operations Contract III (SpaceDOC III) Final RFP Federal contract opportunity
- Solicitation number
- 80GRC022R0016
View the file
Other files for this federal contract opportunity
Show all 25
On GovTribe
Work with this file on GovTribe
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
RFP 80GRC022R0016 Attachment J.1-B
Space Flight Systems Development and Operations
Contract III (SpaceDOC III)
Contract Data Requirements List
(CDRL)
January 6, 2022
REVISION AND HISTORY PAGE
REV.
DESCRIPTION
PUB.
DATE
Draft Draft CDRL for SpaceDOC III
1/6/23
SECTION 1 - Contract Data Requirements
1.1 Scope
a) The Contract Data Requirements List (CDRL) is the basic contractual document, which governs data required by and for the contract.
b) The contractor shall furnish data described by the Data Item Description (DID) included herein and listed on the Contract Data Requirements List (CDRL) for each item of data requested as a deliverable in the Base Order (BO) /Delivery Order (DO). DIDs that are identified as Contract Level (noted in ALL CAPS) will be required to be delivered as part of the proposal and/or shortly after contract award. DIDs that are not contract level and not called out in a specific Base Order/Delivery Order Statement of Work will not be required.
c) All data shall be prepared, maintained, and delivered to NASA in accordance with the requirements of this document.
1.2 Contract Data Requirements List (CDRL)
The CDRL provides a complete listing of the data requirements of the contract. The CDRL contains the following:
a) The data item description number.
b) The data item title.
c) The data item approval code defined as follows:
1. Code NDA [NASA Document with NASA Approval]: The initial submission and all subsequent changes require approval of the NASA contracting officer or designee.
2. Code A [Approval]: The initial submission and all subsequent changes require approval of the NASA contracting officer or designee prior to implementation
3. Code I [Information]: Deliverables are sent to NASA for information purposes only. NASA will request changes on deliverables where errors or omissions are noted through the use of Review Item Discrepancies (RID), if necessary.
4. Code S [Surveillance]: Document and/or data need not be delivered to NASA but should be immediately made available for information upon request or during surveillance activities.
Base Order/Delivery Order instructions may supersede these approval codes with COR approval.
1.3 Data Items Description
a) Each data requirement listed on the CDRL is defined by a DID.
1. The DID describes the purpose and required content of the data item and provides specific format and preparation instructions as necessary. Each DID page has a “Reference” item box. This reference item box may refer to a standard or a guidance document or may be empty. Some DIDs will mandate the format and standard to be used and will be identified in the "Preparation Instructions" otherwise, the reference is for guidance purposes. The "Related Documents" item box refers to other data deliverables that will most likely have supporting information that should be referenced with minimal duplication of information.
2. In many cases, the contractor shall propose the standard to be used that meets the DID requirement most cost effectively. Much of the information requested in the DIDs may already exist in contractor documentation and format processes. The Government strongly encourages the contractor to utilize existing documents and formats whenever it will meet the requirements of the DID.
3. A proposed standard is expected for each and every CDRL DID. In some cases, a single standard may be applicable to more than one CDRL item, and, therefore, may be proposed in response to multiple CDRL items. If no standard exists, the contractor shall indicate how they will generate one.
1.4 Distribution and Delivery
The contractor shall distribute and deliver data according to contract requirements and provisions.
An electronic copy of the transmittal letter and the deliverable document master copy will be deposited into the Government’s electronic storage drop box and notification of document drop shall be provided by e-mail to:
SpaceDOC III Configuration Management Office (E-mail address to be supplied)
For BO/DO level DID’s, copies of the transmittal letter, deliverable document signature pages, and electronic copy of the entire document shall be provided to:
NASA Project Manager (Address and e-mail address to be supplied with the BO/DO)
For BO/DO level DID’s, copies of the transmittal letter only, without the enclosures shall be provided to CO and COR at the emails below. For the contract level DID’s, an electronic copy of the entire document shall be provided to CO and COR at the emails below:
SpaceDOC III Contracting Officer Paige E. Foreman Paige.E.Foreman@nasa.gov
SpaceDOC III Contracting Officer Representative (COR) (Address and e-mail address to be supplied with the BO/DO)
1.4.1 Definition of Deliverables
The following defines the content of the items identified above and shall be provided for each data item submission:
a) Original Document – Is the official final document which is signed electronically by all parties and maintained by the contractor’s Configuration Management organization. The contractor retains signed originals until the completion of the project, when all original document records are transferred to the Government for archiving.
b) Master Copy - Is the official file copy submitted in the form in which it is intended to be distributed and will be signed by the contractor’s Configuration Management organization. The Master Copy is suitable for reproduction and is a copy of the original, signed document.
c) Electronic Data Delivery - Formats for electronic media delivery are defined in paragraph 1.5 of this document.
1.4.2 Deliverable Fidelity
The following defines the document fidelity used to describe the delivered product:
a) Document Formats:
1. The NDA document is formatted as a NASA document with an appropriate cover sheet and has a NASA approval signature entry, identifying NASA’s approval signatures. These documents shall be submitted for NASA review and approval. For NASA-formatted documents, the cover page shall contain only the NASA logo and NASA/GRC address, the document title and number, revision status, and the date of the document release, unless specific guidance to deviate from that format for a particular project has been provided by the government. NASA signature approvals will be limited to the COR or the applicable NASA Project Manager, unless otherwise specified in the BO/DO instructions.
2. Non-NASA Documents Requiring Government Approval, but do not require the NASA
Approval format. Identified on the CDRL as A by the corresponding DID. The NASA signature is included on the document signature page with the following heading, “Accepted by”. These documents should also identify NASA involvement in the document change process. These documents shall be submitted for NASA review and approval. NASA signature approvals will be limited to the COR or the applicable NASA Project Manager, unless otherwise specified in the BO/DO instructions.
3. Information (I) and Surveillance (S) documentation deliverables do not require NASA format or
NASA approval.
4. Non-DID Items are documentation deliverables not identified in the CDRL but are called out in an individual BO/DO and specified as requiring NASA approval. For these documents, the Government will provide the Contractor with DIDs or a description of the requirement and acceptance criteria with the BO/DO request. As a NASA approved document, the document must also specify NASA’s involvement in the document change process.
b) Documents
1. Draft: Format and structure of the document is complete. The document details are being developed and should reflect current design/concept. To Be Determined (TBD) items are allowed, even to the extent that an entire section can be a TBD, provided no concept has been developed for that area.
2. Preliminary: All sections are addressed, and significant detail provided. Some level of TBDs and TBRs are acceptable where data is not yet available. Whenever possible, TBRs should include a “bracketed” value that reflects the best current thinking for a particular value or approach. Example: TBR [120 C]. A table of TBDs and TBRs with expected closure date will be included in an appendix of the document
3. Final: The document is complete. TBDs are allowed only on a case-by-case basis with approval of the Government project manager. Updates to the “final” document are controlled and classified as document revisions.
4. Current: Documents specifically called out in the SOW or CDRL that the Contractor is required to update periodically to reflect changes and re-submit to the Government for review.
c) Drawings
1. Working Level: Draft drawings in the early development stage. Geometrically complete but may be missing dimensions, labeling, and notes.
2. Baselined: A version of a design that has been established as a basis for reference, for a specified purpose, at a specified point in time. It is controlled and traceable. A baseline may or may not be an approved version of the design.
3. Released: A version of a design that has been approved for a specified purpose, at a specified point in time. It is controlled and traceable. The design version shall be reviewed and approved by all responsible individuals before being released.
1.5 Delivery Media
a) The contractor will keep all documents and data in original native format. There are two media in which data will be documented and are defined as:
1. Hard Copy - Data typed, drawn or printed on paper by common, conventional practices. When data necessitates the use of Hard Copy media, the data shall be scanned from the original at a resolution to convey the same detail as the original and delivered to NASA as electronic media in Portable Document Format (PDF) file format. Scanned Electronic media showing actual signatures may be used in lieu of electronic signatures.
2. Electronic - Data that is generated into a software application and can be stored in electronic storage devices. Electronic copies should have an indication of the signature and the date signed.
b) The contractor shall maintain native formats of all data. The electronic data delivery shall be in the following formats:
1. Portable Data Format (PDF) - The preferred format, documents may be delivered via a PDF format that is readable by Adobe Acrobat PDF reader or any Microsoft Office 365 product format or later. Microsoft Project 2016 or later.
2. Drawing formats are defined in the appropriate DID.
c) Any unique documentation delivery instructions shall be specified in the BO/DO. Additionally, all BO/DO and CDRL data shall be delivered via electronic transfer into the Government’s electronic storage drop box.
1.6 Documentation Change Procedures
The contractor shall issue Documentation Change Notices (DCNs) whenever changes or updates occur in final versions of data items that have been delivered to NASA.
a) Change tracking shall be used to indicate changes or updates when the document needs to be reviewed again by NASA.
b) When major changes to a document are made, a complete revision of the document shall be issued and delivered to NASA in accordance with the original instructions for the data item. Any changes to documents requiring NASA approval shall first be submitted to NASA for approval before the changes become effective.
c) Documentation title pages should reflect that Government approval is pending until Government approval has occurred. Upon Government approval, the contractor will revise the title page and signature page will be revised by the contractor to reflect the final, approved version. Current versions of documents shall be made available to the Government via the contractor CM system.
The contractor will notify the Government that the final version with updated title page and signature page has been posted in the contractor CM system.
1.7 Approval of Documentation
1.7.1 Types of Approvals
There are three types of NASA approvals that can be exercised in accordance with the following descriptions:
a) NASA Formatted Documents with Government Approval: CDRL DIDs developed as a NASA document with NASA approval signatures, identified on the CDRL as NDA by the corresponding DID. Typically documents requiring this approval are distributed to the BO/DO manager, they are documents that identify high level system requirements, verification plans and reports, integration agreements, interface control documents, integration schedules, safety documentation, or operations protocols.
b) Non-NASA Documents Requiring Government Approval: CDRL DIDs requiring NASA approval, but do not require the NASA Approval format, identified on the CDRL as A by the corresponding DID. These documents are typically contract-level documents describing contractor processes or internal design activities that require NASA approval. They do not have to be identified as a NASA document, however, require a NASA approval signature.
c) Non-DID Items: Documentation deliverables not identified in the CDRL but are called out in an individual BO/DO and specified as requiring NASA approval. These documents may be unique deliverables not specified in the CDRL, with significant scope that require NASA approval. For those documents, the Government will provide the Contractor with DIDs or a description of the requirement and acceptance criteria with the BO/DO request. Additionally, any documents specified in the contractor responses to design review Request for Action (RFA) and RIDs will require NASA approval. As a NASA approved document, the document must also specify NASA’s involvement in the document change process.
Accepted forms of signature are defined as a traditional signature (electronic or ink) or an e-mail from the signatory stating approval of the document. The e-mail shall be attached to the document.
1.7.2 Process for Document Approval
Document approval is provided by NASA if the requirements specified in the DID are met, and the document fidelity meets the definition in Section 1.4.2. Any documentation with a requirement for NASA approval shall be in accordance with the following:
a) Documents (draft, preliminary and final) may be submitted to the Government for approval either as part of a review package, or on an individual basis. If submitted as part of a review package, the Government will provide approval, approval with modification, or disapproval of each document within 30 calendar days of the review. If documents are submitted individually, or resubmitted following a disapproval, within thirty (30) calendar days after receipt of the document and/or data, the COR will provide (in writing or other agreed to process with the Contractor) to the Contractor whether the documents are “Approved”, “Disapproved”, or “Approved with modifications”.
b) Government approvals of Draft and Preliminary documents with an NDA or an approval code will be provided to the Contractor in writing, but not via signature on the document signature pages.
The document signature pages will be used only for approvals of Final level documents.
c) For documents that are “Disapproved” or “Approved with modifications”, rationale for rejection or conditional acceptance is provided to the Contractor, who shall have thirty (30) calendar days, for Draft or Preliminary level documents as specified by the Government, after receipt to correct the document and returned it to the Government. At that point, the Government has another 30 days to approve the document, and the approval process is repeated.
d) In the event that documents, or data marked "Approved" or "Approved with modifications," reflect information which is not in full conformance with the contract requirements, the Contractor shall notify the Contracting Officer immediately, since any approval of documents or data is not to be construed as a change in contract requirements.
e) Approval by the Government shall not be construed as complete approval but will indicate only that the general method or data is satisfactory. Approval of the documents or data will not relieve the Contractor of the responsibility for any error that may exist. If previously approved portions of a document are disapproved by the Government at a later date due to reason other than requirement changes (editorial, format, programmatic), an impact assessment will be performed by the contractor.
f) In the event that after 30 days no response is received from the Government, a delinquent document or data report will be generated and sent to the COR. The COR will provide in writing to the Contractor whether the documents or data are “Approved”, “Disapproved”, or “Approved with modifications”. If no response is received after thirty (30) calendar days of submitting the report, the Contractor may consider the document approved.
Typically for documents provided for design review, the Government will screen the documents for acceptability and will notify the Contractor in writing whether they are approved for submittal to the design review process. The Government will also provide general comments for those documents considered not acceptable. Any document screened and considered not acceptable will be updated by the contractor prior to the review, or as agreed between the Contractor and Government. This screening should take place generally within 15 calendar days of document receipt to allow the Contractor time for document improvements.
Contractor deliverables, requiring Government approval, are considered to be received on time provided that; 1) the document is received by the NASA BO/DO Project Manager on or before the contractual due date; and 2) that the document is approved by the Government during the initial review and approval process described above.
1.7.3 Non-Deliverable Document Requirements
The development of space flight hardware requires certification of the hardware in meeting the numerous requirements (quality, safety, materials, etc.). Some of the documentation that is obtained in the build process must be retained (electronic or physical) to support final certification of the hardware for flight (Acceptance Data Packages (ADPs), Verification Reports, Certification of Flight Readiness (CoFR) Documentation). The documentation is not delivered to the Government in a DID however, the documentation, such as material certifications, inspection reports, vendor certifications, etc. shall be retained by the contractor and made available to the Government by request.
Best practices shall be used to allow for ease of obtaining these records in a timely manner when necessary, such as an audit or failure investigation.
Title:
CONTRACTOR FINANCIAL MANAGEMENT REPORTING
DID No : CD-01
Reference:
NFS 1852.242-73 NASA Contractor Financial Management Reporting NPR 9501.2E NASA Contractor Financial Management Reporting
GRC 52.242-96 NASA CONTRACTOR FINANCIAL MANAGEMENT REPORTING –
SUPPLEMENTAL REQUIREMENTS (JUN 2021)
Purpose:
To provide monthly data necessary for reporting costs, projecting costs, evaluation of Contractor cost and fee data and planning, monitoring, and controlling project resources.
Related Documents:
CD-02 Technical Reporting and Management Reviews
Preparation Information:
The report shall be in accordance with the NFS 1852.242-73 entitled “NASA Financial Management Reporting (NASA Form 533 reports) as supplemented by GRC 52.242-96 NASA Contractor Financial Management Reporting and NPR 9501.2E entitled “NASA Contractor Financial Management Reporting.
NPR 9501.2E provides basic requirements and instructions to assist in the preparation of Contractor Financial Management Reports (NASA Form 533 reports). NPR 9501.2E may be accessed through the NODIS Library at http://nodis3.gsfc.nasa.gov/
533 reporting is required at the Base/Delivery Order level and summarized at the CLIN 0001-0014 and contract levels.
533M reporting:
1. The Contractor 533 reporting structure for each individual Base/Delivery Order and for CLINs 0001-0014 and contract level summaries shall be in accordance with GRC 52.242-96 entitled NASA Contractor Financial Management Reporting – Supplemental Requirements. Variance reporting is as follows:
VARIANCE REPORTING REQUIREMENTS
Title of Variance Definition Threshold
Actual vs.
Estimated Cost
Any variance at the total contract level between a previous estimated month-specific expenditure and the actual expenditure reported for the same month.
For example: The March 533M reported an estimated total contract expenditure for April of $100K, and subsequent April 533M reported actual total contract costs of $88K, which is a variance of 12%
10%
Actual vs.
Planned to Date
Any variance at the total contract level between the planned cost to date and the actual cost to date
The lesser of 10% or $100K
Contractor Final Estimate vs.
Contract Value
Any variance at the total contract level between the contractor’s current final cost estimate and the current contract value.
The lesser of 5% or $100K
(Additional variance reporting requirements may be added at the discretion of the Contracting Officer)
2. The Contractor 533 reporting structure shall include 1) a summary at the contract level, 2) a summary at the CLIN level and 3) individual reports for each Base/Delivery Order issued. Base/Delivery Order reports shall be consistent with each Base/Delivery Order WBS and Base/Delivery Order schedule.
Base/Delivery Order reports do not need boxes 3, 4, 5 and 9b to be completed on the 533. At the initiation of each Base/Delivery Order, the Contractor and Government shall meet to establish the detail of 533 reporting that will be required by the Government.
3. For the CLIN 0001 and 0014 summary level reports, the FFP orders can be reported as a single row.
FOR BASE AND DELIVERY ORDER SCHEDULE VARIANCES: Milestone variances of +/- 2 months shall be assessed and reported monthly.
The Contractor shall continue to maintain the following requirements:
1. Unfilled Orders Outstanding for Base Orders and Delivery Orders
Reporting of unfilled order in column 10 of the NF 533M is optional, as directed by the NASA Contracting Officer. Amounts of unfilled orders shall, however, always be included in the values shown in columns 8 and 9 of the reports, as appropriate. The amount of unfilled orders outstanding is the difference between cumulative costs incurred to date and amounts obligated to suppliers and subcontractors. A prime or subcontractor’s unfilled orders include open purchase orders (including negotiated changes), against which materials have not been received nor services rendered, and the difference between a subcontractor’s actual costs reported by the prime and fund limitations for the subcontractor. A fund limitation is often less than the total estimated amount to be purchased, just as the amount reported in block 4, “Fund Limitation”, may be less than that reported in block 3, “Contract Value”, for the prime contract.
2. A Reconciliation of Changes from the original negotiated Base/Delivery Order baseline shall be included as part of the Contractor’s Narrative Remarks for the month in which the changes occur. Changes shall be reconciled first to the present Base/ Delivery Order value by including only negotiated changes (supplemental agreements) and then to the Contractor’s Estimated Final Cost by including changes authorized but not finalized. If the Contractor’s Estimated Final Cost includes any overruns or underruns, they should be fully identified and explained. In addition, the Contractor may have proposed changes which have not been approved by NASA but for which tentative costs have been determined. These items should be reported as changes “Under Consideration but not Authorized”.
3. New change order direction to Base/Delivery Orders may require identification of the cost effect on subdivisions of work. The Contractor shall identify shifting work from one WBS item to another. A current Base/Delivery Order change log shall also be provided on a monthly basis.
The requirements of this DID shall be flowed down to the major Subcontractors. Detailed Subcontractor 533 reporting shall be provided directly to the Government.
Due: The due date for the 533 Monthly and 533 Quarterly reports shall be the earlier of:
(A) 10 working days following the close of the contractor accounting period for the 533 Monthly report (or)
(B) 5 working days following the issuance of any voucher or invoice for contract operations cost reimbursement or Fee for the invoice service period that coincides or corresponds to the accounting period for the 533 Monthly report.
TECHNICAL REPORTING AND MANAGEMENT REVIEWS
DID No.: CD-02
Reference:
NASA/SP-2010-3403
Purpose:
To provide a monthly report that will be used to measure the Contractor's progress in completing the activities required by the contract.
Related Documents:
CD-01 Contractor Financial Management Reporting PM-02: Risk Management Plan
Preparation Information:
A. Base and Delivery Order Level Technical Reporting
The Contractor shall deliver Monthly Project Reports for each base and delivery order – The reports shall contain as a minimum; schedule, technical accomplishments, issues/risks/concerns (with mitigation strategies).
1. Schedule data shall include
a. A Report of contract milestones and other agreed upon tasks with explanations of proposed date changes.
b. A look-ahead to upcoming schedule activities or milestones for the upcoming reporting period(s)
c. Identification of critical path to the next base or delivery order milestone
d. Project Schedules shall:
i. Include critical path and near-term activities.
ii. Be in accordance with the scheduler's handbook NASA/SP-2010-3403
2. Technical Accomplishments data shall include
a. Describe the technical work that was completed during the reporting month including supporting photos and figures as available.
3. Issues, Risks, Concerns data shall include
a. Identification of obstacles or challenges that are already present (issues) with proposed resolution(s).
b. Identification of potential obstacles that may arise (risks) as well as mitigation strategies.
c. Identification of concerns that may not rise to the level of a formal risk.
d. Risk overview shall be in accordance with PM-02.
B. Contract Level Reporting/Management Reviews
The Contractor shall deliver:
1. Monthly Technical Report Summary - a listing of base and delivery orders with cost, schedule, and performance issues not resolved within the three (3) preceding reporting periods including associated issue resolution plans.
2. Monthly Management Review – The contractor shall attend a monthly management review with the Government and present:
a. a summary of contract activities associated with base and delivery orders which have met the criteria for B.1. above during any month of the preceding quarter,
b. key technical accomplishments
c. anticipated challenges for the following month and
d. a contract cost, schedule, and performance summary, including.
i. Funds remaining on each BO and DO
ii. BOs and DO’s at risk of exceeding their contract value
iii. Milestones at risk of exceeding the agreed upon dates
iv. Key personnel changes
Due: Monthly - All written reports shall be submitted by the 15th day of the month following the month being reported. The final report shall be submitted within 30 days after the completion of the effort under the contract. In addition, the schedule shall be updated NLT 30 calendar days after a CCR or contract MOD.
INFORMATION TECHNOLOGY SYSTEM SECURITY PLAN
DID No : CD-03
Reference:
Space Policy Directive 5 Cybersecurity Principles for Space Systems Executive Order 14028, Improving the Nation’s Cybersecurity Federal Information Security Modernization Act of 2014 NIST SP 800-53 Rev. 5 Security and Privacy Controls for Information Systems and
Organizations NIST SP 800-37 Risk Management Framework for Information Systems and Organizations NIST SP 800-137 Information Security Continuous Monitoring (ISCM) for Federal Information
Systems and Organizations FIPS 199 Standards for Security Categorization of Federal Information and Information Systems FIPS 200 Minimum Security Requirements for Federal Information and Information System FIPS 140-3 Security Requirements for Cryptographic Modules NPR 2810.1F Security of Information and Information Systems NPD 2810.1E NASA Information Security Policy NPR 7150.2D NASA Software Engineering Requirements NPD 1382.17K NASA Privacy Policy ITS-HBK-2810.19-01 Operational Technology ITS-HBK-AAStep0.v1.0.0 Step 0: Prepare Policy ITS-HBK-AAStep1.v1.0.0 Step 1: Categorize Policy ITS-HBK-AAStep2.v1.0.0 Step 2: Select Policy ITS-HBK-AAStep3.v1.0.0 Step 3: Implement Policy ITS-HBK-AAStep4.v1.0.0 Step 4: Assess Policy ITS-HBK-AAStep5.v1.0.0 Step 5: Authorize Policy ITS-HBK-AAStep6.v1.0.0 Step 6: Monitor Policy ITS-HBK-2810.05-2B System and Service Acquisition ITS-HBK-2810.09-01 Incident Response and Management ITS-HBK-2810.14-03D System and Information Integrity ITS-HBK-1382.07-01 Privacy Awareness and Training
Purpose:
The purpose of the plan is to document the cybersecurity controls employed for all information systems and resources used in support of the SpaceDOC III contract.
Related Documents:
Non applicable Preparation Information:
The Information System Security Plan shall include, at a minimum, the following:
Documentation of the security measures implemented for each information system used in support of or in the execution and delivery of the SpaceDOC III contract. At a minimum, this documentation shall include the following elements:
a) General description of the information system.
b) Security controls consistent with NIST SP 800-53 rev.5.
c) Processes and documentation for risk identification, mitigation, and acceptance
d) Identification and documentation of an authorizing official to grant an Authority to Operate
(ATO) to the information system, as well as the authority to approve risk mitigation and acceptance for the information
e) Identification and documentation of the security roles and assigned individuals to those roles, such as but not limited to the information system owner, the information system security officer, and the chief information security officer.
f) Periodic review cycle and frequency for NASA insight of cybersecurity documentation including cyber risk mitigation processes.
g) Opportunity for a periodic site validation visit, annually at a minimum.
h) Any supporting documentation, including system diagrams, boundary conditions, and dependencies
i) Process for third party audit of systems to include providing NASA a summary report.
Preliminary – Due 6 months after contract award Submission Frequency: As required for any significant update or changes to the system; with a documented annual review at a minimum
INFORMATION TECHNOLOGY SECURITY MANAGEMENT PLAN
DID No : CD-04
Reference:
NFS 18-.470-4(b) NPD 2810.1E NASA Information Security Policy NPR 2810.1F Security of Information and Information Systems and associated handbooks Federal Information Security Management Act of 2002 ("FISMA", 44 U.S.C. § 354); amended by
Federal Information Security Modernization Act of 2014 Purpose:
This plan shall describe the processes and procedures that will be followed to ensure appropriate cybersecurity controls are used to protect the confidentiality, integrity and availability of NASA data that is developed, processed, stored, or transmitted under the SpaceDOC III contract at the Glenn Research Center.
Related Documents:
Non applicable Preparation Information:
The Information Security Management Plan shall include, at a minimum, the following:
a) Contractor’s information security POC(s) and roles and responsibilities for the POC(s).
b) Process for meeting security authorization requirements, including development and maintenance of IT security plans, implementation and validation of controls, security assessments, remediation, authorization, and continuous monitoring for any corporate owned system processing NASA data, including but not limited to ITAR, EAR, and PII sensitive information.
c) Process for ensuring the supply chain risk mitigation.
d) Process for information security incident management and response, including coordination with NASA Security Operations Center (SOC).
e) Process for ensuring personnel screening include the steps for performing appropriate verifications through background checks commensurate with the sensitivity of work being performed.
f) Process for addressing foreign national access to company-owned or NASA-owned data.
g) Process for sharing executive summaries resulting from audits of corporate owned IT
Systems.
h) Process for the use of mobile devices, mobile media, the encryption at rest, marking of media, and sanitization methods employed to protect NASA data.
i) Process for ensuring all subcontractors abide by the IT security management approaches proposed through this DID.
Preliminary – Due 30 days after contract award Final – Due 60 days after contract award or after contract modification or change in company processes affecting plan
SPACEDOC III MANAGEMENT PLAN
DID No.: PM-01
Reference:
NPR: 7120.5, NASA Space Flight Program and Project Management Processes and
Requirements NPR: 7120.8, NASA Research and Technology Program and Project Management
Requirements Purpose:
The SpaceDOC III Management Plan shall describe the contract implementation approach, including the systems and processes, to provide overall coordination of contract management activities. It describes the structure and environment within which the contract and subcontract management operates.
Related Documents:
PM-02: Risk Management Plan PM-03: Software Management and Development Plan PM-04: Configuration and Data Management Plan PM-09: Systems Engineering Management Plan PA-01: Safety and Mission Assurance Plan
Preparation Information:
The Contractor shall provide information giving NASA insight into staffing, organizational structure, approaches, and processes used to manage activities across the SpaceDOC III contract. The plan shall cover all aspects of contract and subcontract management for the SpaceDOC III contract including, but not limited to, the following:
a. Narrative and graphical descriptions of the management approaches used to accomplish and monitor contractual tasks including the establishment and implementation of a review board process
b. Narrative description of roles and responsibilities of the contract’s key personnel
c. Management approach for Base Order and Delivery Order work plan development and execution
d. Management approach to routinely review project Base Orders (BOs) and Delivery Orders (DOs) internally to address cost, schedule, technical progress, concerns, and issues including:
• Management approach to processes, plans and procedures for cost, schedule, and technical baseline control and systems engineering including a process for change order review, approval and implementation
• Controls applicable to any tasks and activities exceeding established cost or schedule plans including requirements for providing recovery plans
• Description of performance reporting to NASA in preparation for major milestone reviews
e. Management support system method, tools, and implementation
f. Methods for accommodating Government surveillance.
g. Approach to interfaces with other contractors or entities that are necessary and pertinent to the accomplishment of contractual tasks, including such things as data, analyses, equipment, software deliverables, schedules, interfaces, and other technical/managerial interactions.
h. Approach to establishing and implementing agreements and/or cooperative relationships with associate contractors or with any other parties necessary for the completion of the work under this contract.
i. Assessment of risks inherent in the management approach, including a process for incorporating lessons learned from previous applicable contracts and continuous improvements
j. Acquisition strategy including a description of the procurement process and the make/buy decision process
k. Describe Contractor to Subcontractor interfaces. Describe how communication between the
Contractor's technical representatives and the Subcontractor's technical counterparts would be facilitated while maintaining contractor supervisory controls (at both the overall contract and project levels). Describe the processes to be utilized for determining when a subcontract should be utilized and managing the subcontractor’s costs and products.
l. Description of the approach for providing regularly scheduled Contract level reviews
m. Description of facility (office, manufacturing, testing, etc.) capabilities in support of the
SpaceDOC III contract
n. Approach to data rights and intellectual property (IP). Approach to how licensing agreements will be negotiated and how that data/IP will be treated, specifically identifying any requested special license agreements.
o. Approach to managing NPR 7120.8 and NPR 7120.5 projects
This Plan shall be included as a separate document.
Draft – Due with proposal submittal Preliminary – Due 60 days after contract award
Final – Due 30 days after review and comment of the preliminary Plan by the COR or their designee
RISK MANAGEMENT PLAN
DID No : PM-02
Reference:
NPR 8000.4, Agency Risk Management Procedural Requirements
Purpose:
The purpose of risk management is to identify risks early in the program so that appropriate abatement plans can be implemented to reduce the consequences of the risk or likelihood that the risk will occur.
The Risk Management Plan provides the overall approach, coordination, structure, and environment within which risk management processes for the SpaceDOC III contract reside and addresses how NASA risk requirements are to be implemented by the Contractor through the Base and Delivery Order implementation.
This document describes the methodologies and processes used to identify, analyze, control, and communicate the Base and Delivery Order’s risks. The identification, characterization, mitigation plan, and mitigation responsibilities associated with specific risks are described and specific risk abatement strategies or contingency planning processes are discussed.
Related Documents:
PM-01: SpaceDOC III Management Plan PM-06: Contractor Base Order/Delivery Order Work Plan
Preparation Information:
The Risk Management Plan documents the process that the Contractor will follow to manage risk throughout the life cycle of the item covered in the Base and Delivery Order and provide government insight to risk management. “Risk” refers to anything that can prevent a team from meeting the Base and Delivery Order objectives. All forms of risk shall be managed. These include technical (hardware and software), programmatic, supportability, cost, and schedule risks.
The Risk Management Plan shall provide descriptions of the processes to provide management at all levels including 1) a disciplined system for early identification of technical uncertainties, 2) a disciplined assessment of current project status, 3) key indicators of mission success, 4) methods and procedures for integrating this process with NASA’s approach to Continuous Risk Management, and 5) tools to be used to store and track risks. The plan shall describe the basis for taking action to control risk and for measuring the effectiveness of that action. This plan shall address any differences in NPR 7120.8 risk management strategy vs. NPR 7120.5 where risk mitigation should be balanced with the need to conduct challenging research and technology development that will realize significant gains.
The plan shall as a minimum cover:
a.) Risk identification – The process to determine and define all risks.
b.) Risk analysis – The process to convert risk data into decision-making information. This process should include estimating the probability, impact and time frame of the risks, eliminating duplicates, identifying key decision points, and grouping similar risks, and prioritizing them according to consequences.
c.) Risk planning – The process to develop mitigation options and decide what to do with the risks.
d.) Risk tracking – The process to acquire, compile and report risk status data, including risk indicators and mitigation actions. Appropriate risk metrics shall be identified so that the Government can evaluate the quality of the risk management.
e.) Risk control – The process covering decisions to re-plan mitigation, close risks, invoke contingency plans or continue to track risks. The plan shall define roles and responsibilities, typical milestones/reviews, and describe the key risk control activities.
f.) Communications and documentation – The process by which terms a – e are communicated and documented and communicated to all team members.
The plan shall also identify the information to be documented for each risk. For risks having both a high probability and high impact/severity, the plan shall require, as a minimum, the following:
(1) Description of the risk
(2) Primary consequence should the undesirable event occur
(3) Estimate of probability of occurrence and the fidelity of the estimate
(4) Significant cost impacts, given its occurrence
(5) Significant schedule impacts, given its occurrence
(6) Significant safety impacts, given its occurrence
(7) Potential mitigation measure not already taken and the cost to implement them
(8) Characterization of the risk as acceptable or unacceptable with rationale.
Final – Due 30 days after review and comment on the preliminary plan by the COR or their designee
Note: Project unique Risk Management Plans may be required, as specified by individual BO/DOs
Software Management and Development Plan
DID No : PM-03
Reference:
NPR 7150.2 NASA Software Engineering Requirements GRC-SW-TPLT-SMP Software Management Plan Template NASA-HDBK-2203 NASA Software Engineering Handbook
Purpose:
To establish specific software management policies, schedules and budget and define the processes and environment by which these policies and practices will be implemented. This plan is to cover new software development, modification, reuse, re-engineering, maintenance, and all other activities resulting in software products.
Related Documents:
PA-10: Software Assurance Plan and Metrics PM-01: SpaceDOC III Management Plan PM-02: Risk Management Plan PM-04: Configuration and Data Management Plan
The Contractor Software Management and Development Plan shall provide detailed information on activities, resources, and procedures necessary for successful planning and implementation of all software (flight, ground, support). For NASA Class A and B software, the Plan must contain all of the items listed in NASA-HDBK-2203, Topic 7.18 – Document Guidance, SDP-SMP – Software Development – Software Management Plan. For Class C, D, and E software, the Plan must contain at least the following:
• a high level software description and classification of each software CSCI per NPR 7150.2 Appendix E,
• at least one cost estimate,
• a schedule of activities with deliverables, milestones, and reviews with completion criteria,
• a description of the needed development and configuration management environments
(equipment and software)
• the chosen standards, languages, procedures, guidelines, software development lifecycle, and techniques,
• the verification approach (including what simulations and/or test environments and resources are needed),
• and milestones for developing and delivering software, including the support software.
Note that per the definition of software in NPR 7150.2, this Plan covers computer programs, source code, source code listings, design details, algorithms, processes, flow charts, firmware, formulae, and related material that would enable the software or a functionally equivalent software to be reproduced, recreated, or recompiled, regardless of the form or media on which such information is recorded
Draft – Due 60 days prior to SRR Preliminary – Due midway between SRR and PDR Final– Due 60 days before PDR, update as required 30 days after PDR
CONFIGURATION AND DATA MANAGEMENT PLAN
DID No.: PM-04
Reference:
NASA-STD-005 NASA Configuration Management (CM) Standard ISO 10007 Quality Management - Guidelines for Configuration Management NPR 7150.2 NASA Software Engineering Requirements (Software Configuration Management
Requirements only) MIL-HDBK-61 Configuration Management Guidance ANSI/EIA 649-B-2011 Configuration Management Standard GEIA-859, “Data Management
Standard” Purpose:
To identify and describe the Contractor processes and methods for Configuration Management (CM) to be used during the implementation of the contract and project/Base and Delivery Orders. This plan establishes the basis for a uniform and concise CM practice for all contractor-provided hardware/software/firmware elements and selected documentation in a manner that is responsive to appropriate, applicable requirements.
Related Documents:
PM-01: SpaceDOC III Management Plan PA-01: Safety and Mission Assurance Plan PM-03: Software Management and Development Plan PM-05: Engineering Change Proposals (ECPs)
Preparation Information:
The CM/DM plan shall describe the Contractor’s configuration and data management system in terms of applicable requirements, planned implementation methods, configuration management and planning, configuration identification, configuration change management, configuration status accounting, configuration verification and audit, schedules, and organizational structure as well as management tools to be used by the Contractor in the execution of this CM effort. The CM/DM plan shall also describe the functions, responsibilities, and authority for the accomplishment and implementation of configuration management to be performed during the full term of the contract. The CM/DM plan shall include hardware, software, and firmware aspects of configuration and data management. The plan shall specify the Contractor’s management policies and identify, by specific reference, standard practices, and detailed work instructions to be used in implementing the configuration management process. This plan shall include, but is not limited to, the following:
a. CM Organization (objectives, organizational structure, authorities, and responsibilities
(individual and organizational))
b. CM approach for managing subcontractor CM activities
c. CM interfaces to the Government CM function, including insight into major subcontractors
d. CM System Description (CM Standards, CM requirements stated or implied in particular, those driven by a flight carrier, Processes, Software CM processes, etc.)
e. CM Tools (software tools, techniques, and equipment necessary for the implementation of the specified software configuration management activities
f. CM Status Accounting (access to accurate, timely information about the product and its documentation, reports of status to the Government or its auditors, verifiable trace for all deliverable end item configurations)
g. Inventory Management (tracks flight equipment, GSE equipment, and other operational support hardware, etc.)
h. CM Schedule (sequence and coordination for the identified CM activities and for all events affecting the CM plan’s implementation)
i. CM maintenance information (identifies the activities and responsibilities necessary to ensure continued CM planning during the lifecycle of the contract)
The CM/DM Plan shall describe the data management approach for data generated and captured during execution of the Base Orders and Delivery Orders with descriptions of how the data will be generated, processed, distributed, analyzed and archived. With respect to data management the plan shall:
a. Define the data products to be managed and how they will be managed.
i. Develop consistent methods of transmitting, processing, and disposition of data
ii. Develop methods for the receipt of data
b. Describe the control method for non-controlled/configuration managed items (i.e., as-built hardware photos, videos, test data, technical review data, etc.)
c. Define the approach to retention of the data.
i. The types of records/data requiring retention.
ii. The retention processes.
d. Define access control to the data.
i. How to receive and evaluate requests for technical data
e. Define handling of Controlled Unclassified Information (CUI), EAR and ITAR data.
i. Data must be transmitted by secured means
ii. Data must be marked in Security Procedures and Guidelines
f. Describe Data Security/Backup Plan.
g. Define Data Formats (documents/drawings).
h. Describe how and what data will be transferred upon completion of the task/contract agreement.
i. Describe how contractual data deliverables will be addressed
Draft – Due 60 days after contract award Preliminary – Due 90 days after contract award Final – Due 30 days after review and comment on the preliminary plan by the COR or their designee
Project unique CM/DM Plans may be required, as specified in the individual BO/DOs
Engineering Change Proposals (ECPs)
DID No : PM-05
Reference:
EIA-649 National Consensus Standard for Configuration Management NPR 7123.1, NASA Systems Engineering Processes and Requirements
Purpose:
To document proposed changes to Government requirements or deliverables (Engineering Change Proposal).
Related Documents:
PM-01: SpaceDOC III Management Plan PM-04: Configuration and Data Management Plan PM-09: Systems Engineering Management Plan
Documentation of Change Proposals
The Contractor shall document each Engineering Change Proposal). This document should describe the applicable requirement and the reason(s) for the request. In addition to a description of the proposed change, the ECP shall contain sufficient information (as attachments, drawings, test results, etc.) to enable evaluation by NASA (or other oversight auditors) of the total impact of the proposed change.
The Contractor shall log and track each ECP from initiation to final disposition and closure within the Configuration Control system.
Delivery of ECPs
The Contractor shall deliver each change proposal to NASA for review and disposition. The status and disposition of all ECPs shall be accessible for review by NASA at scheduled reviews.
NASA may direct the Contractor to prepare ECPs under the “Changes” clause of the contract.
Each ECP shall be delivered for review to minimize the impact…
This is the start of the file's text. The full file is on GovTribe.
File details come from the government source that posted it. Updated .