The following items are required to be listed on Apps.Gov to maintain the integrity and quality of product offerings:
If you meet these requirements and would like to be listed on Apps.Gov, please follow the steps below:
Based on 2014 data from the Office of Personnel Management, the federal government consists of
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
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.
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.
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 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 firstname.lastname@example.org 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):
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 email@example.com.
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.
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.
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.
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:
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.
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 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.
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.
To assist government buyers in making informed descisions when procuring cloud products, below is a list of some additional tests.
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:
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.
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.
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/.
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.
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. 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/.
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/.