US flag signifying that this is a United States Federal Government website An official website of the United States Government This site is currently in alpha. Learn More.

How to List Your Product

The following items are required to be listed on Apps.Gov to maintain the integrity and quality of product offerings:

  • The product must be hosted or provide hosting in the cloud.
  • The product must be a type of service (e.g. SaaS, PaaS, IaaS).
  • The product must have a tier that can be purchased. If you are a free service, all you need is a federally-compatible Terms of Service (agency dependent), see here.

If you meet these requirements and would like to be listed on Apps.Gov, please follow the steps below:

  1. Click on the button below which will navigate you to the Apps.Gov open-source git repository. In the README.md section, you'll find instructions on how to add your product.
  2. Once submitted, the Apps.Gov team will review the pull request (submission) and respond to the POC with a decision.
  3. If approved, follow on information will be requested to appropriately list the product.

Market Size

Based on 2014 data from the Office of Personnel Management, the federal government consists of

4.2 million employees

which includes 2.67 million civilians and 1.5 million uniformed military personnel. Additionally, the proposed 2016 IT spend by the federal government is set to

$79.8 billion

an 1.8% increase from 2015. This includes big spenders like the Department of Defense ($30.7 billion) and the Department of Health and Human Services ($11.4 billion), followed closely by Homeland Security ($6.2 billion), Treasury ($4.5 billion), and Veterans Affairs ($4.4 billion). Read the full FY2016 IT budget proposal here.

Procurement

Below you'll find a list of the various government-wide procurement options agencies can use to buy your software. There are many types of contract vehicles, but Apps.Gov is focused on listing Governmentwide Acquisition Contracts (GWACs) AND contracts that allow for purchasing across the federal government to maximize market reach for products listed.

Micro-Purchase Threshold

Have a product that costs under $3,500/year? Agencies and the subsequent purchase card holders can make a purchase using their government procurement card. However, if the total cost of the service/product exceeds the threshold, alternative contract vehicle options will need to be explored. To learn more, please visit https://www.acquisition.gov/far/html/Subpart%2013_2.html.

Schedule 70

Schedule 70 is an indefinite delivery/indefinite quantity (IDIQ) multiple award schedule, which allows federal, state, local and tribal government entities to procure new and emerging technologies from companies offering IT products and services. Over $15 billion dollars in procurement is available annually to over 5000 customers, with 85% small businesses.

To participate in the IT Schedule 70, please review the information at http://www.gsa.gov/portal/content/104506 and contactfastlane@gsa.gov for more information. If interested in participating, depending on the level of dedicated resources by the company, time to complete can range from 30 to 60 days. Plain language regarding the Schedule 70 process can be found at http://www.gsa.gov/portal/category/100406

Generally, the required documentation overview can be noted below (not limited to):

Administrative

  • Pathway to Success Training
  • Systems for Awards Management (SAM) registration
  • Duns & Bradstreet Past Performance Survey
  • Digital Certificate
  • Certified Financial Statements (Income Statement, Balance Sheet, and GSA Form 527)
  • Any Potential Local, State, or Federal Business Procurements

Technical

  • Technical Proposal
  • Cloud Proposal

Pricing

  • Price Proposal Template
  • Supporting Pricing Documentation
  • Price Narrative
  • Commercial Price List or Market Rate Sheet

NASA SEWP

The NASA Solutions for Enterprise Wide Procurement (SEWP) is a multi-award GWAC vehicle focused on commercial IT products and product based services. There are 147 pre-competed Contract Holders that serve as vendors of IT technologies.

To be procured using the SEWP contract vehicle, a government contracting officer will submit a Request for Quote (RFQ) to the SEWP team, which is then sent out to the 147 vendors. They will identify the appropriate technology, negotiate terms, and compete the prices, which will then be returned to the government contracting officer for selection. The turn around for this process is estimated to take 4-7 business days.

If you'd like to preemptively list your product with SEWP vendors to expedite the RFQ process, please reach out to help@nasa.gov.

NIH NITAAC

The National Institute of Health (NIH) NIH Information Technology Acquisition and Assessment Center is an Office of Management and Budget (OMB) GWAC for IT procurement, which consists of: CIO-SP3, CIO-SP3 Small Business and CIO-CS. If you have questions, please reach out to the NITAAC team via NITAACsupport@nih.gov.

Reviews

Federally-compatible ToS

When selling to the federal government, companies will often be required to negotiate a federal-compatible Terms of Service. A list of approved negotiated ToS can be found at digitalgov.gov, which may not be fully encompassing. Additionally, because negotiated TOS are often determined at the agency level (requiring agency legal review), there are POCs for each agency, identified here.

Privacy Threshold Analysis

A Privacy Threshold Analysis (PTA) document is a form used for all information technology systems that are going through the certification and accreditation (C&A) process required under the Federal Information Security Management Act (FISMA), to determine whether they properly maintain personally identifiable information (PII). The PTA includes a description of the system, what PII, if any, is collected or used, and from whom.

Privacy Impact Assessment

When personal information on individuals is collected and used as a part of a system, the product team is required to conduct a Privacy Impact Assessment (reference: E-Government Act of 2002). A PIA or Adapted PIA may need to be written for any IT system that collects, stores, and makes retrievable people’s personally identifiable information. Further work and approval from the agency’s Chief Privacy Officer may be required. The PIA explains:

  • The information collected is used only for the intended purpose;
  • The information is timely and accurate;
  • The information is protected according to applicable laws and regulations while in GSA’s possession;
  • The impact of the information systems on individual privacy is fully addressed; and
  • The public is aware of the information GSA collects and how the information is used.
  • Further work and approval from the agency’s Chief Privacy Officer may be required.

Systems of Record Notice (SORN)

Regulates the collection, maintenance, use, and dissemination of personally identifiable information (PII) about people (referred to as a “system of records”) by the government. A SORN may be required when collecting, storing, and making retrievable people’s personally identifiable information. More information regarding SORNs can be found here.

  • A System of Record is created when a group of information is collected and stored in a way that can be retrieved by the name of an individual, or by any number, symbol, or other unique identifier assigned to that individual.
  • The Privacy Act requires that any system of record be publicized via a SORN, which is a notice published to the Federal Register for public comment. This process lasts a minimum of 60 days.
  • Further work and approval from the agency’s Chief Privacy Officer may be required.

Authority to Operate

Governed by the Federal Information Security Management Act of 2002, or FISMA, each agency will require an Authority to Operate (ATO) before an IT system is approved to be used within an organization or agency. The ATO represents the agency conducting an appropriate security review of the IT system. There are various types of ATOs, which have different requirements, noted below.

Agency ATO

Agency ATOs are issued and approved at the agency head or delegated authority level. The process in which agencies follow to appropriately assess an IT system may vary based on the controls and mechanisms for each agency.

FedRAMP

The Federal Risk and Authorization Management Program, or FedRAMP, is a government-wide program that provides a standardized approach to security assessment, authorization, and continuous monitoring for cloud products and services. This approach uses a “do once, use many times” framework that saves an estimated 30-40% of government costs, as well as both time and staff required to conduct redundant agency security assessments. FedRAMP is the result of close collaboration with cybersecurity and cloud experts from the General Services Administration (GSA), National Institute of Standards and Technology (NIST), Department of Homeland Security (DHS), Department of Defense (DOD), National Security Agency (NSA), Office of Management and Budget (OMB), the Federal Chief Information Officer (CIO) Council and its working groups, as well as private industry.

The cloud systems can take one of three paths to become FedRAMP compliant: JAB Provisional Authorization (P-ATO), Agency Authorization, and Cloud Service Provider (CSP) Supplied Package. No matter which path a CSP has taken — JAB, Agency, or CSP Supplied — all cloud systems listed here have demonstrate FedRAMP compliance and can be leveraged by any agency. Additional details for each path is listed below.

  • JAB Provisional Authorizations: Cloud systems listed under the FedRAMP P-ATO path have undergone a rigorous technical review by the FedRAMP PMO, been assessed by a FedRAMP accredited 3PAO, and received a P-ATO from the DHS, DOD, and GSA CIOs.
  • Agency FedRAMP Authorizations: Cloud systems listed under the Agency Authorization have worked directly with a customer agency to achieve a FedRAMP compliant ATO that has been verified by the FedRAMP PMO.

    FedRAMP Compliant (In PMO Review) is a designation for Agency ATO Authorization Packages only. This designation signifies that the CSP’s cloud system has been granted an ATO by an agency and has submitted all required documentation for review to the FedRAMP PMO. Once the FedRAMP PMO completes an Initial Review of the package the CSP will be listed as FedRAMP Compliant.
  • CSP Supplied Packages: Cloud systems listed under the CSP Supplied Package path have submitted to the FedRAMP PMO a completed Security Assessment Package (SAP) that has been assessed by a FedRAMP accredited 3PAO.

Additional Testing

To assist government buyers in making informed descisions when procuring cloud products, below is a list of some additional tests.

FedRAMP Ready

FedRAMP Ready is a milestone step that ensures that a CSP’s documentation meets the FedRAMP PMO’s minimum quality and security standards. CSPs must pass an Initial Review of their SSP before being listed as FedRAMP Ready on fedramp.gov. The SSP includes twelve attachments that must also be evaluated during the Initial Review:

  • FIPS Pub 199
  • E-Authentication Template
  • Information System Security Policies and Procedures
  • Configuration Management (CM) Plan
  • Control Implementation Summary (CIS)
  • CIS Worksheet
  • IT Contingency Plan (CP)
  • Incident Response Plan (IRP)
  • Privacy Threshold Analysis (PTA) / Privacy Impact Analysis (PIA)
  • User Guide
  • Rules of Behavior (ROB)
  • Signature Page
A CSP can be listed as FedRAMP Ready on fedramp.gov for maximum of one year.

FedRAMP Ready CSPs have proven they are ready for agency or FedRAMP PMO detailed reviews required to become FedRAMP Compliant and gives agencies the confidence that the SSP documentation meets the FedRAMP PMO’s quality and security standards that are necessary to initiate the assessment and authorization process with the JAB.

FedRAMP Infrastructure

This designation is for CSPs who are currently hosted on FedRAMP approved infrastructure. This does not represent FedRAMP approval, only a designation to help further inform a government buyer.

DHS Software Assurance Marketplace (SWAMP)

The Software Assurance Marketplace (SWAMP) is committed to bringing a transformative change to the national software assurance landscape by providing a national marketplace that provides continuous software assurance capabilities to researchers and developers. By providing Software Assurance (SWA) researchers, tool developers, tool users, and educators who train our workforce a suite of secure and dependable analysis services, SWAMP will reduce the number of vulnerabilities deployed in software. To learn more, please visit https://www.dhs.gov/science-and-technology/csd-swamp.

NCCoE Review

The National Cybersecurity Center of Excellence (NCCoE) at the National Institute of Standards and Technology (NIST) works with experts from industry, government, and academia to address businesses’ most pressing cybersecurity problems with practical, standards-based solutions using commercially available technologies. We seek problems that affect an entire sector, or multiple sectors. We then identify applicable standards and best practices and collaborate with creators of commercial, off-the-shelf products to use them in developing example solutions in our labs. Finally, we publish NIST Cybersecurity Practice Guides (Special Publication series 1800), which include all of the information and instruction businesses need to deploy the use of secure, standards-based solutions. To learn more, please visit https://nccoe.nist.gov/.

ICD 503

Intelligence Community Directive 503 (ICD 503), “Intelligence Community Information Technology Systems Security Risk Management, Certification and Accreditation,” is the relevant guidance for the risk management and certification of information systems across the IC. This standard specifically requires the IC to use NIST or CNSS standards for security certification assessment and testing. CNSS Policy No. 22, “Policy on Information Assurance Risk Management for National Security Systems,” specifically points to FISMA for security audit controls. To learn more, please visit http://www.dni.gov/files/documents/ICD/ICD_503.pdf.

HIPAA

The Health Insurance Portability and Accountability Act of 1996 (HIPAA; Pub.L. 104–191, 110 Stat. 1936, enacted August 21, 1996) was enacted by the United States Congress and signed by President Bill Clinton in 1996. It has been known as the Kennedy–Kassebaum Act or Kassebaum–Kennedy Act after two of its leading sponsors.[1][2] Title I of HIPAA protects health insurance coverage for workers and their families when they change or lose their jobs. Title II of HIPAA, known as the Administrative Simplification (AS) provisions, requires the establishment of national standards for electronic health care transactions and national identifiers for providers, health insurance plans, and employers (source: Wikipedia). To learn more, please visit http://www.hhs.gov/hipaa/for-professionals/security/laws-regulations/.

PCI

The Payment Card Industry Data Security Standard (PCI DSS) is a proprietary information security standard for organizations that handle branded credit cards from the major card schemes including Visa, MasterCard, American Express, Discover, and JCB. Private label cards – those which aren't part of a major card scheme – are not included in the scope of the PCI DSS.

The PCI Standard is mandated by the card brands and administered by the Payment Card Industry Security Standards Council. The standard was created to increase controls around cardholder data to reduce credit card fraud. Validation of compliance is performed annually, either by an external Qualified Security Assessor (QSA) that creates a Report on Compliance (ROC) for organizations handling large volumes of transactions, or by Self-Assessment Questionnaire (SAQ) for companies handling smaller volumes (source: Wikipedia). To learn more, please visit https://www.pcisecuritystandards.org/.