MDR_PWS.pdf

PDF 116 KB Posted

Attached to
MarkLogic Master Data Repository (MDR) and Support Services Federal contract opportunity
Solicitation number
RC051920150146
Issued by
DOD Washington Headquarters Service

About this file

PWS

View the file

Other files for this federal contract opportunity

Other files attached to MarkLogic Master Data Repository (MDR) and Support Services, newest first.
File Type Posted
MDR_Brand_Name_JA_Redacted.pdf PDF
Responses_to_Questions4.docx DOCX document
Responses_to_Questions3.docx DOCX document
Responses_to_Questions.docx DOCX document
Responses_to_Questions.docx DOCX document
MDR_Brand_Name_JA_Redacted.pdf PDF
MDR_RFQ_Attachments.doc DOC document
MDR_RFQ.pdf PDF

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

Performance Work Statement Master Data Repository Technology and Implementation Support

1. BACKGROUND

The Defense Technical Information Center (DTIC) has the responsibility to develop, coordinate and enable a strong scientific and technical information program for the Assistant Secretary of Defense, Research and Engineering (ASD(R&E)) and the DoD Scientific & Technical (S&T) enterprise. Its aim is to maximize the availability and use of technical information and products resulting from defense-funded technical activities while ensuring restrictions in national security, export control and intellectual property rights are safeguarded.

DTIC has collected and managed content in a number of data repositories to serve the DoD S&T mission. Each repository was established to serve a particular product, often with separate input, storage, document management, security control, and dissemination systems. Dissemination systems include search, collaboration, and analytics products to support S&T researchers, scientists, engineers, analysts, and decision makers. The data repositories and dissemination systems were implemented with a variety of technologies. The data itself is both structured and unstructured. The structured data exists in a variety of schemas without standardization. It consists of several million records primarily describing documents, research projects, people, and organizations, but also artifacts such as blogs and discussions from collaborative tools. The unstructured data is in a variety of formats and in some cases lacks descriptive metadata. The scale of the unstructured data is also a few million documents. Current growth rate is approximately 50,000 new records and 50,000 new documents per year, but is expected to increase with the advent of additional planned collections.

While these repositories and systems have been instrumental in the S&T enterprise, their diversity has resulted in substantial effort and cost to maintain and enhance each separate stack.

It has also proven costly for each new product that needs to harvest, store, manage, control, integrate, and disseminate all of their data, either for search or analytics. This environment hinders creation of new data sets, data gap mitigation, uniform access control, analytics, data quality improvement, taxonomy enhancement, syndication, federation, and data governance.

DTIC’s goal is to consolidate, unify, manage, control, search, analyze, and disseminate scientific and technical data using a single tool. Consolidation of the data into a single tool will ease and facilitate analysis, management, and control. A single tool is desired to replace the numerous legacy technologies; reduce the number of required skill sets; reduce risk by eliminating many processes, interfaces, and points of integration; and gain efficiencies by applying policies, features, validation rules, and data quality improvements once rather than in multiple data flows.

The tool must also provide better functionality than some of DTIC’s existing technologies, namely:

• Storage that can quickly ingest diverse structured and unstructured data without time-consuming preliminary data model standardization.

• Access control, integrated with the data store that will ensure the security of its information but can be more responsive to changing policies and new data sets.

• Search that supports simple and complex queries across structured and unstructured data, delivers fast, accurate, and precise results, can quickly respond to requests for new features, and is integrated with semantic technologies.

• Semantic capabilities for storing and querying RDF triples.

• Analytic and visualization capabilities that can be quickly implemented across minimally normalized data to offer new insights on Department of Defense science and technology research.

• Input systems that can be easily spun up for new data calls and whose data can be integrated, searched, controlled, and analyzed in the same system.

2. SCOPE

The scope of Master Data Repository effort includes the following:

A. The MarkLogic Server, as described in Section 3 of this PWS.

B. Initial support services for establishing an implementation of the product as described in Section 4 of this PWS.

3. PRODUCT

The Contractor shall provide the MarkLogic Server, a Master Data Repository (MDR) Product, that possesses the following capabilities to meet DTIC’s requirements:

Functional:

A. Data Ingest and Storage

1. Quickly ingest structured data with diverse schemas without having to establish a common data model and without losing the structure of the ingested data. Ingested data shall be immediately searchable. NoSQL solution required.

2. System will be able to pull data directly from a variety of databases (Oracle, MySQL, and MS SQL Server) and from data dumps in a variety of potential formats (XML, CSV, JSON).

3. Quickly ingest unstructured data (e.g. full text documents) in a variety of formats (PDF, Word, PPT, etc.) and make it immediately searchable.

4. Quickly ingest RDF triples.

5. Establish connectors to continually harvest data from repositories that must remain independent.

6. Index content from website crawls.

7. Easily modify data mappings, fields, models, and schemas, both after ingest and optionally during ingest, to enhance functionality.

8. Easily scale up to incorporate new data sets

9. Replace some of the existing databases and unstructured data repositories (file systems) by becoming the primary store of that data.

10. Support SQL queries, inserts, and updates to potentially replace databases behind select in-house input systems.

B. Search

1. Treat the full text of a document and the metadata describing the document as a single item in search results.

2. Offer simple search of structured and unstructured data, separately and together.

3. Search specific metadata elements/fields. Easily and quickly add new search fields across diverse collections.

4. Support Boolean operators, proximity operators, phrase searching, and nesting in the general index and when limiting to specific fields.

5. Automatically search stems of words to finding singular and plural forms.

6. Support truncation and wildcard searching.

7. Search date and number ranges.

8. Enable building complex queries combining Boolean operators, multiple levels of nesting, field searching, full text searching, phrase searching and truncation using a simple search language.

9. Enable scrolling or paging through all results from a search, not limiting to only the first few thousand results.

10. Return exact counts of search results, not rough estimates, regardless of scale of results.

11. Enable sorting by relevance, date, or alphabetically by fields like Title or Organization.

12. Recommend similar results.

13. Enable browsing/selecting search terms from an ingested authority file/ontology

(e.g. list of organizations).

14. Ingest a thesaurus or taxonomy (provided by DTIC) to expand searches to synonyms and related terms.

15. Autocomplete/suggest search terms as the user types in a search query.

16. Enable system administrators to tune the relevance algorithm (e.g. by frequency, occurrence in specific metadata fields, etc.).

17. Offer users option to limit a search to only structured data (excluding indexes of full-text/unstructured data).

18. Allow users to save search strategies to rerun ad hoc or periodically.

19. Save and export metadata search results in a variety of formats (PDF, CSV, and

BibTex).

20. Offer facets/navigators/clusters, based on specific metadata or extracted entities, for browsing results.

21. Return a sub-second response for simple search queries.

22. Enable saving of user search preferences.

23. Offers APIs for other applications to search the data

24. Search by geographic location.

25. Highlight search terms in results.

26. Store logs of user search queries.

27. Incorporate results from other search engines.

C. Access Control.

1. Apply role-based access control of search and input users at collection, document, and metadata element levels.

2. Apply role-based access control of search and input users to query, analysis, input, and edit functionality.

3. Apply role-based access control of developers’ access to structured and unstructured data by collection.

4. Apply complex access control rules based on multiple markings within the metadata such as distribution limitation, distribution reason, and classification.

5. Query LDAP for user attributes and access rights.

6. Store logs of users’ data accesses.

7. Offer APIs for other applications to inquire specific user’s access rights for specific data.

8. Control access to the data by other agencies and applications (i.e. include access control in a search API).

9. Easily modify rules to accommodate new policies and new collections.

D. Data Linkage.

1. Establish relationships/links across data sets with diverse schemas.

2. Enable exposing data gaps and inconsistencies across content and implementing strategies to mitigate those gaps.

3. Enable inferring new or missing data from relationships in diverse data sets.

4. Easily add new fields/element types to individual collections to fill data gaps.

5. Enable construction of new composite entities using specific elements from multiple data sets with diverse schemas. For example, integrate user registration data, access rights, search/access/input history, authorship, saved searches, and bibliographies into a single profile for each user.

E. Analysis and Visualization.

1. Support Analytics requests for statistical queries within collections and across linked data.

2. Respond to analytic queries across millions of metadata records in seconds.

3. Support visualization of data through charts, graphs, and maps.

4. Support third party Business Intelligence tools.

5. Store logs of analytics requests.

6. Generate metrics on use of the input, search, and analytics modules of the repository.

F. Semantic Search

1. Provide for storage of ontologies and RDF triples developed by DTIC or third party tools.

2. Offer search of RDF triples integrated with search of metadata and full text.

3. Support SPARQL queries.

4. Support visualization of semantic relations of data.

G. Document Management

1. Enable input, editing, and management of data by users and internal staff.

2. Ensure data is immediately exposed in search after input/edit/approval.

3. Support workflows for document management.

4. Support document versioning.

5. Allow end users to tag data or enhance data.

6. Enable schema and content validation of data feeds.

7. Enable field validation in manual input forms.

8. Enable users to select input values from values in an existing ingested taxonomy or collection (e.g. select Organization from ingested taxonomy of organizations).

9. Enable users to load batches of records (e.g. as XML, JSON, CSV).

10. Provide ACID transactions to ensure data integrity.

11. Support simultaneous read and write (Multiversion concurrency control)

H. Data Governance and Quality Improvement.

1. Enable applying universal and collection specific data governance across ingested and inputted content.

2. Enable validation of manual inputs and XML uploads.

3. Enable quality analysis and improvement of ingested legacy data.

I. Publishing

1. Export metadata on demand and on periodic schedule in a number of formats

(XML, HTML, Sitemap, CSV, OAI, MARC, etc.) along with its associated unstructured full text data (PDF, Word, PPT, etc.).

2. Offer APIs for trusted sources to export data on demand.

J. Application Development

1. Easily spin-up front-ends for search, analysis, or input of data for existing or new collections.

Non-functional:

K. Security

1. Meet requirements of DoD Security Technical Implementation Guides (STIG) and DoD Risk Management Framework (RMF).

L. Availability

1. Support clustered architecture on staging and production environments for high availability and disaster recovery.

2. Provide option for database replication.

3. Provide installations on NIPR Development, Staging, and Production environments with full data sets on both Staging and Production.

4. Provide installations on SIPR Staging, and Production environments with full data sets on both Staging and Production.

M. Cloud

1. Offer on premise and cloud solutions

2. Easily transition licenses between on premise and cloud solutions.

N. Technical

1. Support SQL and SPARQL.

2. Offer REST APIs.

3. Support Java and JavaScript application development.

4. Run on virtual machines with network storage.

5. Run on Linux, Solaris, and Windows.

4. SUPPORT SERVICES TASKS

The Contractor shall be directly responsible for ensuring the accuracy, timeliness, and completion of all requirements under this effort, none of which are considered inherently governmental functions as defined in FAR 2.101 or Subpart 7.5. In accordance with FAR 37.104, Personal Services are prohibited and will not be performed under this contract. A key concept throughout this PWS is for the Contractor to assist in shaping the technology base for DTIC’s future. Development will occur concurrent to DTIC's agile development and testing team.

The Contractor shall perform the following tasks which include, but are not limited to:

A. Data Ingest and Storage

1. Ingest structured and unstructured data from DTIC’s primary collections (see

Data Details below) without extensive upfront data normalization effort.

2. Ingest data from DTIC’s database of saved searches and bibliographies.

3. Ingest application and web log data.

4. Establish connectors and processes to periodically ingest updates from legacy repositories that DTIC chooses to persist outside of the MDR.

5. Ingest associated RDF triples generated by DTIC or third party semantic tools.

6. Modify and transform data as needed to meet specific use cases.

B. Search

1. Implement search service for DTIC’s frontend user interfaces to call with queries and return with search results. Ensure it supports Boolean operators, proximity operators, phrase searching, and complex nesting in the general index and when limiting to specific fields.

2. Implement display service for DTIC’s frontend user interfaces to call with requests for specific metadata records and documents.

3. Implement full text searching.

4. Implement option to search only metadata (excluding the full text index).

5. Implement default option to search both full text (unstructured data) and metadata (structured data).

6. Enable field searching of each single field within each collection and for a limited set of common fields across collections.

7. Implement date and number range searching.

8. Implement combined search fields that may search single fields in some databases but multiple fields in others (e.g. Authors, Organizations, Subjects, and Identifying Numbers).

9. Optimize performance for commonly searched fields (e.g. Title, Author, Organization, Report Date, Creation Date, Program Element Number, etc.).

10. Ensure that the metadata record describing a full text document, and the full text document(s) itself, are treated as a single item in search results but as separate items for access control.

11. Implement stemming, truncation and wildcard searching.

12. Implement sort of search results by relevance, date, and alphabetically by title and organization.

13. Ingest a subject thesaurus or taxonomy provided by DTIC to expand searches to synonyms and related terms.

14. Store logs of user search queries.

15. Implement auto-completion of search terms based on logs of previous searches.

16. Create service for web front end to store search queries, to retrieve and display saved search strategies to the user, and to rerun searches on demand or on schedule.

17. Create service for web front end to store specific user selected search results to review at a later date, add to, delete, and export in a variety of formats.

18. Implement facets/navigators/clusters of 3-5 metadata elements in search results for users to filter search results.

19. Return sub-second response for simple search queries.

20. Create web service for web front end to store, reference, and modify users’ UI preferences.

C. Access Control.

1. Implement role-based access control of search and analysis queries at collection, document, and metadata element levels. Integrate into service for search queries and display of data. Access control will be based on rules for controlling Scientific and Technical Information, markings of data in the MDR, and user attributes.

2. Implement controlling developers’ access to code and data stored in MDR.

3. Implement query of DTIC’s LDAP for user attributes and access rights.

4. Implement storage of logs of users’ requests for structured and unstructured data and whether or not access was granted.

D. Data Linkage.

1. Support DTIC efforts to link data, identify data gaps, implement mitigation strategies, and construct composite entities.

E. Analysis and Visualization

1. Implement service for analytics requests within collections and across linked data to retrieve statistics on content, user, and log data.

2. Assist implementation of visualization of results from analytics requests through charts, graphs, and maps.

3. Implement storing logs of analytics requests.

4. Implement service to query access logs in order to display the number of times each item in a search results list has been viewed by previous users.

F. Semantic Search

1. Implement search of RDF triples (generated by DTIC or third party semantic tools) integrated with search of metadata and full text.

2. Assist with creation of SPARQL queries for new analytics requests.

G. Document Management

1. Implement service for document management staff to edit ingested data.

2. Implement service for search and analytics users to enhance content found through DTIC’s interfaces.

H. Data Governance and Quality Improvement.

1. Implement scripts to correct/improve/standardize data in select elements.

I. Publishing

1. Implement service to export metadata in XML, CSV, HTML, and PDF with associated full text files for records selected through search queries.

2. Implement service to publish metadata in XML or HTML with associated full text and Sitemap indexes.

J. Application Development

1. Offer guidance to DTIC developers generating new front-ends for potential new projects.

Non-functional:

K. Security

1. Integrate the system with DTIC’s SSO environment (CA Siteminder).

2. Assist with documenting system security plan and integrating MDR into

DTIC’s Risk Management Framework.

L. Availability

1. Install, configure, optimize the product in NIPRnet development, staging, and production environments on premise at DTIC or in DTIC’s chosen cloud provider

2. Install, configure, optimize the product in SIPRnet staging and production environments on premise at DTIC

3. Implement clustered environments on staging and production.

M. Cloud

1. Assist with transitioning implementations between on premise and cloud environments.

N. Support

1. Provide annual maintenance support.

2. Provide training classes.

3. Fully document code written to fulfill above requirements.

4. Document technical architecture of implementation.

5. DATA

The following tables describe the data to ingest and manage in the Master Data Repository

(MDR).

NIPR/SIPR* DATA

Collection # of ‘records’

Avg size of record

# of attachments

(bins)

Avg size of attachment

Total size of attachments

Growth rate Type of storage

Technical Reports

2250000 486k 920000 PDFs

4 MB 4.2 TB 30000

records & attachments /yr (going down to records/yr with advent of New Technical Reports below)

Oracle and file mount

TEMS

(technical reports)

1300000 122k 470000 PDFs

3 MB 2 TB 20000

records & attachments /yr

MySQL and file mount

URED/RS

(research projects)

330000 100k nominal n/a n/a 15000/yr MySQL

IRDarchive (research projects)

170000 100k 170000 PDFs

500k 0 Oracle and file mount

R-2 (budget requests)

11000 200k 11000 PDFs

500k 5.5 GB 1000/yr XML

P-40 (budget requests)

1000 200k 1000 PDFs 500k 500MB 1000/yr XML

DoDTechsp ace (collaborati ve tool)

50000 (500

MB)

10000 500k 10000/yr MySQL

New search and access logs n/a 1 kb 0 n/a n/a 3000000/yr MDR

Saved search and bibliograph

10000 (128

MB)

10k 0 n/a n/a Oracle y database

Weblog summary reports n/a n/a 0 n/a n/a 2 GB/yr XML

New Technical Reports (begins 2015)

0 n/a 0 n/a n/a 30000 records & attachments /yr

DLA cloud

New Open Access articles (begins 2015)

0 n/a 0 n/a n/a 30000 records & attachments /yr

DLA cloud

LDAP 30000 10k 0 n/a n/a 17000/yr LDAP

DoDTechip edia (collaborati ve tool)

80000 500k MySQL

Defense Communiti es (collaborati ve tool)

62000 500k MySQL

AULIMP

(journal article metadata)

347000 0 n/a n/a MARC/HT ML on file system

SCAMPI

(journal article metadata)

136000 0 n/a n/a MARC/HT ML on file system

NDIA

(briefings)

0 n/a 10000 PDFs

200k 1000/yr File system

DTTIS

(cooperativ e agreements

1000 n/a n/a n/a 50/yr Oracle

Internationa l

3500 0 n/a n/a 10/yr Oracle

Agreements

* SIPR data is same scale and type as NIPR.

6. REPORTS

Monthly Progress Report. The contractor shall provide a monthly written status report documenting task support, issues, and progress. The report shall detail contractor activities during the reporting month and plans for the following two months. The report shall include a summary of work performed and deliverables completed, current, or projected problems and issues and their resolution, an explanation of deviations from the last month’s projections, and any recommendations related to the effort. Documentation of how the code affects the MDR functionality and the user interface when applicable; and lessons learned.

Progress Reviews will be performed as directed by the Contracting Officer’s Representative (COR) and will generally summarize the status and progress of all activities being performed by the contractor. If work results in User Interface functionality, a demo may be required. Progress reviews will take place at those locations requested by the COR. Specific dates for progress reviews will be agreed between the COR and the contractor’s Program Manager.

7. DELIVERABLES AND PERFORMANCE

General quality measures are critical to mission success and will be applied with 100% surveillance to each deliverable received by the Contractor under this PWS. All work products shall be complete, accurate, and timely to reflect the technical work associated with each project.

All work products and any required corrections shall be submitted in accordance with dates as determined by the Contracting Officer or duly authorized representative.

Acceptable Quality Levels of Contractor Activities:

Attributes Acceptable Quality Level (AQLs)

(1) Completeness Deliverables shall be 95% complete on first submission and 100% complete on final submission.

(2) Accuracy Deliverables shall be 95% complete on first submission and 100% complete on final submission.

(3) Timeliness All deliverables shall be completed on schedule.

(4) Professionalism Communications and interactions with client/customers are always courteous and professional.

Deliverables:

DELIVERABLE DUE FORMAT

Non-Disclosure NLT 7 days after award and upon replacement of personnel

Microsoft Word with original employee signature

Weekly Progress Report Friday Microsoft Word

Monthly Progress Report NLT 10th of each month Microsoft Word

Final Progress Report NLT the last business day of the month

Microsoft Word

Manpower Reporting Annually, NLT October 31st Electronically at http://www.ecmra.mil/

Progress Reviews As directed by COR PowerPoint presentation

Architecture diagram As directed by COR

Electronic Format - Microsoft Word or MS Office appropriate software

Code and documentation for Section 4 tasks

As directed by COR Electronic Format - Microsoft Word or MS Office appropriate software;

code/text files as needed

Manpower Reporting

The contractor shall report ALL contractor labor hours (including subcontractor labor hours) required for performance of services provided under this contract via a secure data collection site. The contractor is required to completely fill in all required data fields using the following web address:

http://www.ecmra.mil/ <http://www.ecmra.mil/> .

Reporting inputs will be for the labor executed during the period of performance during each Government fiscal year (FY), which runs October 1 through September 30. While inputs may be reported any time during the FY, all data shall be reported no later than October 31 of each calendar year, beginning with 2013. Contractors may direct technical questions to the help desk at:

http://www.ecmra.mil <http://www.ecmra.mil> . [Reference: DPAP memorandum of 28 November 2012, "Enterprise-wide Contractor Manpower Reporting Application."]

QUALITY ASSURANCE SURVEILLANCE PLAN (QASP)

http://www.ecmra.mil/ http://www.ecmra.mil/ http://www.ecmra.mil/

All work to be performed under this contract is subject to Government surveillance at any time either on-site or virtual. That surveillance may be performed as in-process inspection, preliminary inspection, and/or final inspection. The method of inspection may include visual inspection of the work products and/or impromptu status discussions.

The COR shall:

a. Conduct surveillance of the activities/deliverables under their purview.

b. Provide in-process clarification of the tasks previously identified.

c. Review the monthly progress report relative to paragraph 5 above and clearly indicate any work products found to be unacceptable.

d. Report any performance problems (e.g. non-compliance with contract requirements, failing to meet AQLs) that they observe or discover to the Contracting Officer immediately.

e. Accept conforming work products.

The COR shall not:

a. Supervise Contractor employees.

b. Accept Non-conforming work products without the express written approval of the

Contracting Officer.

8. TYPE OF CONTRACT AND PERIOD OF PERFORMANCE

The period of performance for support services will be a base period of 6 months with (3) 6-month option periods. The period of performance for annual maintenance will be a base period of 12 months with (2) 12-month options.

9. PLACE OF PERFORMANCE

DTIC expects that 95% of the work to be performed at the Government site:

Defense Technical Information Center located at the Andrew T. McNamara Building at 8725 John J. Kingman Road, Fort Belvoir, VA 22060-6218

The Contractor will be required to perform work at the on-site location during Federal mandated core hours which state that employees are not allowed to start work before 0600 and cannot end their normal work day earlier than 1500.

Contractor personnel shall support on-site and off-site meetings, at the request of the DTIC government representative, in person. Other means of support for meetings may include virtual, video or telephone conferencing capabilities

Government Holidays:

New Year’s Day – 1 January Martin Luther King, Jr.’s Birthday – 3rd Monday in January President’s Day – 3rd Monday in February

Memorial Day – Last Monday in May Independence Day – 4 July Labor Day – 1st Monday in September Columbus Day – 2nd Monday in October Veteran’s Day – 11 November Thanksgiving Day – 4th Thursday in November Christmas Day – 25 December

Any other day designated by Federal Statute, Executive Order or a Presidential proclamation.

When a holiday falls on a Sunday, the following Monday will be observed as a legal holiday. When a holiday falls on a Saturday, the preceding Friday is observed as a holiday by the U. S. Government. If the area in which a contract employee is scheduled to work is closed due to the holiday and the employee is not required to report in, payment will not be made for those hours. Closures of the installation due to inclement weather or other such acts of God shall be handled in the same manner.

Closures. During anticipated closure of the facility due to Command declared training holidays or during unplanned closure of the facility due to natural disasters, military emergencies, severe weather, or otherwise, the Contractor shall not invoice the Government for services not performed and the Government will not be liable to the contractors for any such closures.

10. SECURITY

The work will be performed on Non-secure Internet Protocol Router Network (NIPR) and Secret Internet Protocol Router Network (SIPR) systems.

The Government requires security clearances of at least Interim Secret for performance under this contract. A general, contract level DD Form 254 is provided.

The contractor shall bear the cost of any security clearances required for performance.

The Contractor shall ensure required levels of security and privacy are maintained for Contractor and sub-Contractor access to DTIC. Additionally, Contractor staff with Information Assurance responsibilities shall comply with the requirements stated in DoD 8570.01-M as detailed below.

The Contractor shall ensure that personnel accessing information systems have the proper and current information assurance certification to perform information assurance functions in accordance with DoD 8570.01-M, Information Assurance Workforce Improvement Program.

The Contractor shall meet the applicable information assurance certification requirements, including: (1) DoD-approved information assurance workforce certifications appropriate for each category and level as listed in the current version of DoD 8570.01-M; and (2) Appropriate operating system certification for information assurance technical positions as required by DoD 8570.01-M.

Upon request by the Government, the Contractor shall provide documentation supporting the information assurance certification status of personnel performing information assurance functions.

Contractor personnel who do not have proper and current certifications shall be denied access to DoD information systems for the purpose of performing information assurance functions.

Security clearances and Public Trust levels required for contractors will vary by labor category and position. All contractor personnel are required to meet and maintain security and certification requirements as described in DoD 5200.2-R and DoD 8570.01-M prior to in-processing and for the duration of their work on this contract.

In accordance with security requirements, all Contractor staff within classified spaces shall be prepared to perform limited escort of personnel without a badge within their local area.

Contractors will be familiar with DoD rules and regulations on the proper handling of Personally Identifiable Information (PII) and perform their duties in compliance with same.

Privacy and Security. This work effort involves the Contractor having access to and/or the safeguarding of classified information/material. The security policies, procedures and requirements stipulated in the National Industrial Security Program (NISP), National Industrial Security Program Operating Manual (NISPOM) and supplements thereto are applicable to include the following security requirements and/or guidance whenever contract performance will occur on a DoD-controlled facility or activity.

11. CONTRACTOR QUALITY CONTROL

The contractor shall perform all technical and administrative planning, coordination, analysis and tracking of the diverse activities and disciplines provided by the contractor to meet the requirements. The contractor shall manage and control contract resources to assure completion of all tasks within schedule and performance requirements.

12. CONTRACTING OFFICER’S REPRESENTATIVE (COR)

The COR shall be the focal point for administration matters related to performance. Only the Contracting Officer can make changes and any such changes are not effective unless directed in writing by the Contracting Officer. CORs will be appointed in writing and a copy of the appointment letter will be provided to the contractor.

13. RIGHTS

The Government will retain rights to all data produced in the course of developing, deploying, and training, using, and supporting DTIC on this effort.

Vendor source code delivered with product licenses will remain the property of the vendor.

The Government will retain rights to all new code produced in the course of supporting DTIC on this effort.

14. NON-DISCLOSURE AGREEMENT

The NDA will be due no later than 7 days after award.

Defense Technical Information Center

Nondisclosure Agreement

I, _________________________, agree not to disclose any sensitive or proprietary information that is presented, discussed or made accessible during my participation on Contract HQ0034- XX-X-XXXX that will expire on XXXXX XX, XXXX.

I understand that information I may become aware of or possess as a result of my support to the Defense Technical Information Center may be either proprietary or sensitive. It is my responsibility to ensure proper use and protection from unauthorized disclosure of this information.

“Sensitive or proprietary information" includes such information submitted by a contractor marked as proprietary, advanced procurement information (e.g., future requirements, statements of work, and acquisition strategies), source selection information (e.g., bids before made public, source selection plans, and rankings of proposals), trade secrets and other confidential business information (e.g., confidential business information submitted by a contractor), attorney work product, information protected by the Privacy Act (e.g., social security numbers, home addresses and telephone numbers), and other sensitive information that would not be released by DTIC under the Freedom of Information Act (e.g., program, planning and budgeting system information).

I agree not to appropriate such information for my own use or to release or disclose it to third parties unless specifically authorized to do so. I also understand that I must protect proprietary information from unauthorized use or disclosure for as long as it remains proprietary and refrain from using the information for any unauthorized purpose.

This nondisclosure agreement shall continue in effect until XXXX XX, XXXX or until two years after the date when I last have access to sensitive or proprietary information from this contract, whichever is later. Upon expiration of this agreement, I have a continuing obligation not to disclose any sensitive or proprietary information to any person or legal entity unless that person or legal entity is authorized by the Head of the Agency, the Head of the Contracting Activity, the

Contracting Officer or the Contracting Officer’s Technical Representative to receive such information. I understand that violations of this agreement are subject to administrative, civil criminal sanctions.

I understand that any unauthorized use, release or disclosure of nonpublic information in violation of this agreement will subject me to administrative, civil or criminal remedies as authorized by law.

Signature: _______________________ DATE: _________________

PRINTED NAME: ________________________________________

TITLE: _________________________________________________

EMPLOYER: NAME OF CONTRACTOR

Examples of sensitive information include, but are not limited to:

(a) Unclassified information that requires special handling (for example, Limited Distribution, Encrypt For Transmission Only, and scientific and technical information protected under the Technology Transfer Laws and Arms Export Control Act).

(b) Controlled Unclassified Information (CUI) is unclassified information to which access or distribution limitations have been applied according to national laws, policies, and regulations of the United States Government (U.S. Government). It includes U.S. information that is determined to be exempt from public disclosure according to DODD 5230.25, DODD 5400.7, and so on, or that is subject to export controls according to the International Traffic in Arms Regulations (ITAR) or the Export Administration Regulations (EAR). Because CUI does not qualify for formal classification, it should be afforded OPSEC measures for additional protection because of its vulnerability as unclassified information.

(c) Information that must be protected under applicable laws such as the Privacy Act.

(d) Freedom of Information Act (FOIA)-exempt information specifies nine categories of information that can be withheld from release if requested by the public (See Information Exempt from Release Under the Freedom of Information Act. The category of information that is especially vulnerable is personal information (names, Social Security Numbers, birth dates, and so forth.) Lists of names and accompanying sensitive information of personnel assigned to a unit, organization, or office in the Department of the Defense are prohibited on the World Wide Web. Discretionary release of names and duty information of personnel who frequently interact with the public by nature of their positions and duties-such as general officers and senior executives, PAOs, or other personnel designated as official command spokespersons is permitted.

(e) Unclassified information designated For Official Use Only (FOUO) is a designation that is applied to unclassified information that may be exempt from mandatory release to the public under the FOIA. FOUO is not a classification as FOUO information is unclassified, but is not to be released to the public without undergoing a FOIA and/or legal review. FOUO will be the standard marking for all unclassified products that meet one or more of the exemptions of FOIA, and which if released to the public, could cause harm to DoD operations or personnel. Examples include but are not limited to: force protection, movement and readiness data, tactics, techniques, and procedures (TTPs), proprietary information and information protected by copyright, pre-decisional documents, draft publications, and information concerning security systems.

Penalties References

Export Control Under 22 USC. 2778 the penalty for unlawful export of items or information controlled under the ITAR is up to 2 years imprisonment, or a fine of $ 100,000, or both. Under 50 USC, Appendix 2410, the penalty for unlawful export of items or information controlled under the EAR is a fine of up to $1,000,000, or five times the value of the exports, whichever is greater; or for an individual, imprisonment of up to 10 years, or a fine of up to $ 250,000, or both.

Theft of Trade Secrets Under 18 USC. 1832 theft of trade secrets is “without authorization copies, duplicates, sketches, draws, photographs, downloads, uploads, alters, destroys, photocopies, replicates, transmits, delivers, sends, mails, communicates, or conveys trade secret information;”

A defendant convicted of economic espionage can be imprisoned for up to 15 years and fined $500,000 or both. Corporations and other organizations can be fined up to $10 million. A defendant convicted for theft of trade secrets under Section 1832 can be imprisoned for up to 10 years and fined $500,000 or both. Corporations and other entities can be fined no more than $5 million.

Title 41 USC 423 - Procurement Integrity provides both civil and criminal penalties. The criminal penalty is up to five years imprisonment. The civil penalty is a fine up to $100,000.

Title 12 USC 3417 – Right to Financial Privacy, Civil Penalties.

Title 18 USC 1831–39 - Protection of Trade Secrets [Chapter 90].

Title 18 USC 1905 – Disclosure of Confidential Information.

15. CONTACTS

DTIC:

Andrew Pedrick Andrew.J.Pedrick.civ@mail.mil 703-767-7337

File details come from the government source that posted it. Updated .