Attachment 1_SOW for SAP.pdf

STATEMENT OF WORK

PROJECT NAME: SINGLE POINT OF ENTRY, PLATFORM, AND PROCESS FOR

REQUESTING ACCESS TO RESTRICTED-USE MICRODATA – STANDARD

APPLICATION PROCESS ONLINE PORTAL

1. REQUIRING ORGANIZATION

National Science Foundation Division of the National Center for Science and Engineering Statistics Directorate for Social, Behavioral and Economic Sciences 2415 Eisenhower Avenue Alexandria, VA 22314

2. INTRODUCTION AND OVERVIEW

The 2018 Foundations for Evidence-Based Policymaking Act, also referred to as the Evidence Act, requires that a Standard Application Process (SAP) be developed for requests for confidential data from federal statistical agencies. This legislation applies to statistical agencies that are covered under the Confidential Information Protection and Statistical Efficiency Act (CIPSEA). This standard process includes a single point of entry for data requests, a single application, and a standard set of criteria used to evaluate each application. This standard process is designed to streamline the application process and make it easier for data users to apply for data from federal agencies.

In addition to the legislation, a policy provides guidelines for the implementation of this standard process. This policy, M-23-04, was issued by OMB in 2022 and includes required functionality for the SAP, governance, and criteria used to review applications for confidential data.

In order to operationalize this Standard Application Process, an online portal researchdatagov.org was created and officially rolled out in December of 2022. This SAP portal is intended to serve as the ‘front door’ to apply for access to confidential data from 16 federal statistical agencies and units.

The SAP creates a single application portal for applying for access to federal confidential data assets from the nation’s federal statistical agencies and units. It standardizes the application forms, determination criteria, and review timeframes across agencies when applying for access to any federal restricted-use data asset.

By streamlining data discovery and standardizing the application process, the SAP promotes civic engagement, increases transparency, and supports private-sector decision-making, basic research, and policymaking at the federal, state, local, and tribal levels.

https://www.whitehouse.gov/wp-content/uploads/2022/12/M-23-04.pdf http://www.researchdatagov.org/

Applicants are able to:

• Browse a metadata inventory of confidential data assets

• Determine whether the confidential data asset is appropriate for their use case

• Apply for that data using a common application

• Track application status/progress and results

Individuals interested in applying for access to restricted data go to the online portal. Once there, they can search for data using an extensive metadata catalog of data offered by the statistical agencies. The catalog provides information about each dataset, such as a description of the data, what agency holds the data, who needs to approve, information about how it was collected, and technical documentation. Once the data is selected, the applicant completes an online application describing who will be working on the research and the nature of the research. Once the application is completed, they submit the application, and the application is routed to the agencies whose data is being requested for their review. Agencies then review and provide feedback and an approval or denial, based on standard criteria.

3. PURPOSE

The purpose of this procurement is to support the National Center for Science and Engineering Statistics (NCSES) portal page for recognized statistical agencies and units1, as well as a platform and standard process for requesting access to restricted-use microdata. NCSES is a recognized statistical agency and part of the National Science Foundation’s (NSF’s) Directorate for Social, Behavioral and Economic Sciences (SBE). This role—outlined in the America COMPETES Reauthorization Act of 2010 (Section 505)—directed NCSES to serve as a central federal clearinghouse for the collection, interpretation, analysis, and dissemination of statistical data.

The Evidence Act, enacted in January 2019, emphasizes collaboration and coordination to advance data and evidence-building functions in the Federal Government. While anchored on existing principles underlying Federal policies and data investment infrastructure, the Evidence Act creates a new paradigm by calling on agencies to significantly rethink how they currently plan and organize evidence-building, data management, and access functions to ensure an integrated and direct connection to data and evidence needs. Currently, Federal agencies each have their own processes, procedures, and user interfaces for providing access to data.

This project supports both the Evidence Act and NCSES’s clearinghouse role in leading a consolidation and standardization effort across the Federal statistical system. The goals of this project are to:

• Maximize standardization and efficiencies through a single-entry point portal

• Improve the experience of external parties requesting microdata

• Improve the data management experience for statistical agencies and units

1 These are statistical agencies and units recognized by the Office of Management and Budget (OMB) under the Confidential Information Protection and Statistical Efficiency Act (CIPSEA).

To accomplish these goals, the project requires a single portal for requesting access to restricted-use microdata: a single system that is shared amongst statistical agencies and units to create efficiencies as a shared resource for providing this critical function.

This project meets the requirement to provide an internet-based managed-service for all statistical agencies and units. The service will provide a portal page for statistical agencies and units where prospective data users (to include individuals and those associated with specific projects) may submit requests for restricted-use microdata. This service shall allow external parties to submit a request to access restricted-use data from statistical agencies and units. The service will provide agencies with user accounts for the purpose of approvals (e.g., enabling an agency’s reviewers to log into the portal and post their evaluations of applications). Prospective data user requests and associated application materials will be accessible to and transmitted electronically to the appropriate agency for review in the same system.

Critical features associated with the requirements include:

• Internet based, web-accessible through modern browsers.

• Ability to support at least 16 federal agencies with scalability for the addition of new agencies as needed.

• Scalable architecture that can support a minimum of 500 submissions per hour and 100 concurrent users.

• Ability to control access to request documents (i.e., the application for data) based on cognizant/responsible agency, i.e., Inherent Security Controls such as Cyber, Information, Access, etc., modifiable to any unique federal agency requirements.

• Ability to automatically control routing, processing, and distribution of data request information and supporting documents.

• Ability for agency-initiated actions (i.e., allow, block, delete, redact), and User/Project initiated actions (i.e., allow, block, delete, redact).

• Ability within the system to provide opportunities for application tracking, project reviews, appeals, project reviews, credentialing, and transparent metrics on the process, including aggregate metrics and metrics by agency.

• Ability within the system for the application to allow for skip patterns to account for variation in agency requirements.

• Intuitive User Interface with modern design standards and 508 compliance.

• Adherence to federal and agency security standards and protocols, including the ability to provide secure account credentials, digital signatures, encrypt data at rest and in transit, and handle moderate level data.

• Establishment and allowance of secure, trusted connections with other organizations to allow request processing by both the cognizant owner and steward of requested data.

• Ability to provide approval levels/certification and/or credentialing to data requestors, projects, or both.

4. OBJECTIVE/SCOPE

An online portal does currently exist (researchdatagov.org) with some of the functionality described in this project for the Standard Application Process (SAP).

The objective of this project is to develop a new online SAP portal that allows users to search for confidential data held by federal statistical agencies, apply for access to that data, and allows data providers to review those applications and render a decision. This portal supports the implementation of Section 3583 of the Foundations for Evidence-based Policymaking Act of 2018.

The new online SAP portal will also extend beyond the current online portal’s capabilities. This includes the expansion to non-statistical and state agencies in the future as well as additional functionality and higher workloads. The new online SAP portal will allow users to access a metadata catalog of federal statistical agency data assets. Users will be able to apply for access to data by completing an application and submitting it to the relevant agencies. Data providers will be able to access these applications, review them, provide feedback when needed, and render a final decision.

5. TECHNICAL REQUIREMENTS

5.1 TECHNICAL REQUIREMENTS – SAP ONLINE PORTAL

5.1.1 Website / Software capabilities, key features and security

1) A public-facing online portal that is accessible to members of the public.

2) Hosted by contractor in a secure environment that meets all FISMA moderate requirements.

3) Launches from a .gov website URL address. Requirements for operating a .gov domain https://get.gov/domains/requirements/

4) Adherence to federal and agency security standards and protocols, including the ability to provide secure account credentials and digital signatures.

5) Is compatible/interoperable with the Federal data register from Title 2 (Open Data Act)

6) Is transferable to either government or another vendor.

7) Intuitive User Interface with modern design standards and 508 compliance.

8) Includes Role-Based Access Control (RBAC) for assigning permissions to users based on their role within their organization and the SAP.

9) One online platform that contains three different components: data user Application

Portal, data owner Reviewer Portal, Metadata Manager Portal and an Administrator Portal

a. Data User: Applicant Portal

i. Public facing portal for researcher applications.

b. Data Owner: Reviewer Portal

i. Fed Gov agency private portal for reviewing applications.

ii. Fed Gov interagency communication on data user applications

c. Metadata Manager Portal file://ad.nsf.gov/NSF/Divisions/NCSESPUB/DACQA/SAP%20Contract/researchdatagov.org https://get.gov/domains/requirements/

i. Fed Gov Agency private portal for updating agency metadata

d. Administrator Portal

i. NCSES agency private portal for providing real time copy edits, run reports, and other basic admin functions to online portal.

10) Is scalable to include additional agencies/data providers, users, and datasets over time.

11) Provides flexibility for requirements changes when modifications to the portal functionality need to be made, such as changes to the application or adding additional data providers.

12) Can leverage technology, such as Application Program Interfaces (API), to allow for information transfer between the portal and agency project tracking systems for metadata and project application information.

13) A metadata catalog with information about confidential data assets, including documents such as technical documentation. The required metadata fields will be provided by NCSES. Metadata can be viewed and downloaded by all users in different formats.

a. A solution for ingesting metadata into online portal so that it is public facing.

14) Implementation of a reporting system with a dashboard that allows the derivation of key aggregate metrics associated with the portal usage (e.g., number of submitted applications, review determination aggregations, etc).

15) A full suite of publicly-available metrics that include:

a. Aggregate summary metrics on total applications under review, approved, and disapproved;

b. Aggregate summary metrics by agency;

c. Project-level reporting.

16) A public facing interactive metrics dashboard that displays overall agency metrics and public reporting.

17) Ability for Fed Gov agency admins to login and provide real time copy edits to website.

18) Ability for Fed Gov interagency communication on data user applications requesting access to data from multiple agencies.

19) Scalable architecture that can support a minimum of 500 submissions per hour and 100 concurrent users.

20) Stores restricted-use microdata request metadata, including determinations, and modifies as necessitated by statistical agency or unit requirements.

21) Is developed based on usability testing with data users, metadata editors, application reviewers, and Project Management Office (PMO).

22) Is developed through working with the PMO to develop priorities based on the needs of the government and user testing outcomes. This process will be iterative with priorities potentially shifting over time and new priorities arising.

23) Ability to provide a smooth transition of data from current portal (researchdatagov.org) to new online portal.

5.1.2 Data user features (Individuals submitting applications on SAP)

1) An application with a simple interface that allows users to request access to confidential data from federal statistical agencies. The application fields will be provided by NCSES.

The application must allow:

a. Users to indicate parameters for data selected, such as years or geographic area, based on available metadata.

b. Skip patterns and upload of documents depending on specific criteria including but not limited to metadata fields, agency, and/or dataset selection

c. Allow for users to save their application, close and return;

d. The ability to make changes to all fields, including datasets selected, after an application has been initiated;

e. Print and/or download the application and its content.

2) Ability for an applicant to request an application appeal for a negative determination with a disposition workflow.

3) Amendment functionality that includes:

a. Ability of a user to make changes to an application post-approval;

b. Routing of that application to applicable agencies for review and disposition.

4) Provides data requestors and projects with a metadata inventory to enable selection of the appropriate dataset(s) for user needs.

5) Provides data requestors and projects the option to download or print request application materials.

6) Provides requestors and projects up-to-date information on each microdata request, including the number of applications at each stage of the process, determinations, and timeframes associated with each step.

7) Ability for a portal user to file an appeal for an agency for non-compliance with the SAP policy with a disposition workflow.

8) The system must support PDF, Excel and Word file formats for all document uploads and downloads. There is no limit on file size

9) No titled data will be stored within the portal. FEDRAMP certification is not required.

The system will contain non-sensitive personally identifiable information.

5.1.3 Data owner features (Fed Gov agency staff reviewing applications on SAP)

1) An application workflow that allows agency data owners to review applications requesting access to their data. This includes the ability to:

a. View an application within the system;

b. Download an application, including one or more options that allow for export of the application information into agency project tracking systems;

c. Record an approval or rejection of an application through the assessment of various criteria. In the case of a rejection, agencies must be able to indicate the review criteria on which the rejection is based. Agencies must be able to record comments with those comments visible by the agency and applicant after the final disposition is recorded.

d. Prior to a final disposition, agencies must be able to request one or more revise and resubmits, requiring that the applicant make changes to the application before a determination is made. The agency data owner must be able to record feedback in the portal in order to communicate the necessary changes to the applicant. A history of this feedback must be maintained and be accessible by data providers and applicants.

2) Application deadlines or review windows for some agencies. This feature would include the ability for each agency to queue applications until a deadline is reached, at which point they would begin reviewing applications.

3) Internal communication/collaboration portal that allows government agencies to communicate and collaborate on SAP Applications that request datasets from multiple agencies.

4) Ability for multiple data providers to review the same application concurrently, provide feedback to applicants, and each render a final determination.

5) Implementation of varying review periods depending on the data selected and reviews required. Includes ability to implement a limited review period for some agencies who do not review applications year-round and the ability for an agency to request a time extension.

6) Allows agencies to request an application extension, record a decision in the portal, and modify the review period for an approved extension.

5.1.4 Universal user key features (Features that both Data Users and Data Owners need)

1) Implementation of a notification system that informs both the applicant and the agency data owner of the submission of an application, key milestones in the application review process, and the remaining time in review period. Additional notifications may be needed at certain points in the workflow.

2) Maintenance of a review history with application versions, including comment histories.

3) Routes requests upon submission, to the appropriate statistical agency or unit for adjudication.

4) Prospective data user and project requests and associated application materials will be accessible to and transmitted electronically to the appropriate agency for review in the same system.

6. DESCRIPTION OF WORK

The Contractor shall provide services from an existing capability as a Vendor-hosted, managed service. This requires a common, publicly accessible application with functions to include but not limited to, an appeals process, application tracking, and transparent metrics on the process, applications received, and disposition. The service will serve as a single portal for prospective data users to request access to restricted-use microdata. The service will enable the ability to manage data requests and to deliver requests to appropriate statistical agencies and units for adjudication. The service will also provide approval levels/certification to data requestors and projects.

6.1 Project Management

The contractor shall provide project management to oversee the successful completion of all tasks in the statement of work.

6.2 Planning (Roadmap)

Within 1 month after the contract has been awarded, the contractor shall provide the Contracting Officer Representative (COR) a roadmap for this contract. The contractor will develop project-specific milestones and schedules. The contractor will provide monthly updates on the status of NCSES’s desired milestones and goals. The contractor will provide quarterly presentations and an annual presentation to the COR and NCSES Leadership to outline past year outcomes and upcoming quarterly or yearly milestones and goals.

6.3 Risk Management

The contractor shall produce a risk management plan and maintain and review projects, schedules and resources and report risks on a monthly or time-sensitive basis that impact the overall project and how to avoid and/or correct it. The plan must include identification of risks, an assessment of probability of occurrence and impact, risk management, and risk reporting and monitoring.

6.4 Documentation

The contractor shall draft and maintain technical documentation for all products developed in this project. Documentation shall be delivered with every major product release and approved by the NCSES COR.

6.5 Communication Management

The contractor shall propose and implement a communication plan outlining a communication protocol in at least the following areas: status meetings and reports, system documentation, system monitoring and reporting, and interacting and coordination with NCSES staff and contract-related personnel. As needed, the contractor shall work with the COR and other key staff to suggest communication strategies to alert, inform, coordinate, update and brief NCSES staff, including Leadership, on any new or ongoing projects and initiatives. The communication plan shall be delivered within the first 6 months of the contract award. COR approval of the communication plan is required.

6.6 Financial Management, Resources and Procurement of Software

The contractor will manage the contract budget and maintain a detailed financial record of their costs. The contractor will propose a financial management plan, including invoice submission procedures and a proposal for a monthly financial report to the COR. The monthly financial report will include, at a minimum, the monthly break-down of the actual labor costs, projected labor costs, and other direct costs for the entirety of the contract. The contractor is required to notify the COR when 75% of obligated funds have been spent. The financial management reports will be incorporated in the monthly, quarterly, and year-end deliverables. The contractor will work with the COR and NCSES staff to identify requirements and manage the procurement of software and services needed for this work. The contractor will also propose a resource plan, included in the proposal submission, that includes staffing and other resources needed to achieve NCSES milestones goals and known projects.

6.7 Transition Activities

An initial transition from the current portal will be required. A transition and integration of the existing database will be needed. As such, a transition plan is required to be delivered to NCSES within 2 months of contract kickoff.

To ensure the smooth transition-out of the project to a potential new contractor at the end of this contract, the contractor will develop and execute a COR approved transition-out plan for the project to a new contractor. This plan will be delivered 1 month after award. A strategy for system and website portability and transferability should be included in the proposal submission.

7. PERIOD OF PERFORMANCE

One 24-month base period, plus three 12-month option years.

8. PLACE OF PERFORMANCE

The place of performance will be offsite from NSF headquarters. The place of performance location is to be determined by the contractor. The work conditions and hours are to be determined by the Contractor. No work can be performed outside the United States, including accessing government data and email.

9. GOVERNMENT FUNISHED RESOURCES

The Government will provide all necessary information, data and documents to the Contractor for work required under this contract.

10. CONTRACTOR FURNISHED RESOURCES AND PROPERTY

The Contractor shall furnish all facilities, materials, equipment and services necessary to fulfill the requirements of this contract, except for the Government Furnished Resources specified in this SOW.

11. DELIVERY AND PERFORMANCE INFORMATION

Listed below are the deliverables due during the period of performance.

Section Reference Deliverable Due date 12 Post Award Kickoff Meeting Withing 15 calendar days of contract award

Status Update Meetings Weekly or Bi-Weekly as agreed upon by COR and Contractor

6.2 Roadmap 1 month post award

6.7 Transition plan from current SAP portal to

new SAP portal 2 months post award 11 Quality Control Plan (QCP)

2 months post award

6.3 Risk management plan As agreed upon the roadmap

6.4 Documentation As agreed upon the roadmap

6.2 Monthly reporting Monthly

6.6 Financial Management Reports Monthly, Quarterly, and Annual 12 Google Analytic / Usage Metrics Reports Monthly and Ad Hoc

6.1 Maintain the environment and provide

customer support in establishing project spaces and supporting user access, user training, and “helpdesk” support

Ongoing from launch through end of the performance period

6.2 SAP website wireframes As agreed upon the roadmap

12 Initial Design As agreed upon the roadmap

6.2 Usability Testing As agreed upon the roadmap

6.2 Interactive Metrics Dashboard As agreed upon the roadmap

6.2 Final Design As agreed upon the roadmap

6.2 Implementation of SAP website As agreed upon the roadmap

6.2 Continued support of the website as needed As agreed upon the roadmap 12 Final Report End of Period of Performance

All deliverables will be delivered to and approved by the COR.

Offerors should propose tasking and associated costs in three (3) phases outlined below.

Time ranges are estimates and offerors can propose modifications.

• Phase 1 - Build the SAP software platform and (~6 months or less)

• Phase 2 – Operational Testing of the Secure Compute Environment (~2 months) – estimate 100 users (government and non-government)

• Phase 3 – Demonstrate/Enhance the Secure Compute Environment (through August 9, 2027) – estimate 500 users (government and non-government)

If there are existing tools, software, and technologies that can achieve the stated goals of the SAP website build, then the offeror should use them and avoid developing custom-built tools, software, and technologies. If new tools are required, the offeror should provide a clear explanation for why existing technologies in the market are insufficient. All technology and software developed should be easily portable with minimal constraints imposed by proprietary software and have suitable APIs for plug and play.

If any information technology (IT), websites, and/or cloud technologies are procured or developed as a part of the SAP website build, then the offeror must ensure that these solutions comply with NSF and/or federal IT security, information management, and data security requirements. Coordination with NSF’s Division of Information Systems (DIS) may be required as well as other Offices of Security at federal agencies, as needed.

The Government will provide the content for the SAP website build.

One copy of each report will be submitted to the Contracting Officer Representative (COR). The contractor will deliver each report in a mutually agreed upon format. Deliverables are to be transmitted with a cover letter, on the prime contractor’s letterhead, describing the contents.

Only the Contracting Officer Representative (COR), or Contracting Officer (CO) has the authority to inspect, accept, or reject all deliverables. Final acceptance of all deliverables will be provided in writing, or in electronic format, to the PM or CO within 30 days from the end of the task order.

The contractor will establish and maintain a complete Quality Control Plan (QCP) within 60 days of contract award to ensure the services are performed in accordance with PWS and commonly accepted commercial practices. Strategies for quality control should be included in the proposal submission. The contractor will develop and implement procedures to identify, prevent and ensure non-recurrence of defective services. The government reserves the right to perform inspections on services provided to the extent deemed necessary to protect the government’s interests. The contractor must control the quality of the services and deliverables provided in support of this project and maintain substantiating evidence that services conform to contract quality requirements and furnish such information to the government if requested. The QCP will include a quality control matrix (QCM). The QCM will reflect the quality approach of the vendor as it applies to the key areas of the offeror’s proposed Technical Appendix (TA).

12. DESCRIPTION OF DELIVERABLES

The following are some of the requirements for the deliverables listed in the preceding table:

• Kick-off Meeting - The objectives of the meeting shall include introducing key task participants, explaining their roles, and reviewing the tasks to ensure a common understanding of task requirements and objectives for all participants.

• Status Update Meetings – The contractor will provide status updates to the Contracting Officer's Representative (COR) every week or every two weeks as agreed upon with the

COR.

• Initial design - The Contractor shall provide the COR, and other key stakeholders as determined by the COR, an initial design for the portal, webpage, and proposed process.

The design should provide evidence that it meets security requirements and is scalable.

• Bimonthly Status Report - The Contractor shall provide the Bimonthly Status Report to the COR, and others at the discretion of the COR. The report shall include a summary of current weekly activity to include Microdata metadata acquisitions, routing systems for microdata request and project metadata storage systems, action items, status of past action items, planned activity, open issues, problems or delays encountered and proposed solutions for correcting the problems or delays, and hours worked by Contractor personnel. The report should be in Microsoft Word format unless directed otherwise by the COR.

• Usage Metrics Report - The Contractor shall provide a monthly Usage Metrics Report to the COR. The report shall include a summary of the number of new accounts that were created, the number of requests for microdata and the number of requests that were transmitted to each agency. In addition, the report will include information on customer satisfaction with the service and timelines associated with prospective data user and project requests.

• Final Report (FR) - The Contractor shall provide the Final Report to the COR. The report shall include a summary of bimonthly Status Reports and review current state and potential changes that were made to meet the government’s needs. The report should be in Microsoft Word format unless directed otherwise by the COR.

13. DELIVERABLES ACCEPTANCE CRITERIA

All contractor-produced documents and documentation (‘work products’) shall meet the following general acceptance criteria. Final inspection and acceptance of all work performed, reports and other deliverables will be performed at the place of delivery by the NCSES COR.

The COR will inspect the draft and final work products and deliverables within five (5) business days after receipt for completeness, accuracy, appropriateness, and format and return them to the Contractor for correction or augmentation as required. If corrections are required, the contractor shall make corrections and resubmit work product or deliverable within five (5) days after receipt of rejected deliverable from the Government. Final acceptance will be provided by the COR in writing to the Contractor after final approval.

• Accuracy—Work products and deliverables shall be accurate in presentation, technical content, and adherence to accepted elements of style as described through government-provided standards.

• Technical Content—Work products shall provide expert comments on procedures, specifications, and data review.

• Clarity—Work Products shall be unambiguous and relevant. Any/all diagrams shall be easy to understand and be relevant to the supporting narrative.

• Consistency to Requirements—All work products must satisfy the requirements of this statement of work.

• Format—Work products shall be submitted in hard copy (where applicable) and in electronic form using NSF’s standard word processing software.

• Completeness—Work products shall be comprehensive and entirely developed as described through government-provided standards.