Morrison Foerster’s Government Contracts Insights provides our in-depth analysis of developments and trends impacting government contracting. Through Insights, our attorneys offer a real-time assessment of the statutory, regulatory, legal, and business-related developments and trends that are shaping the industry. We also examine a full array of non-U.S. public procurement issues, mindful that our clients compete in a global marketplace.Morrison Foerster’s nationally recognized Government Contracts and Public Procurement practice represents the world’s leading companies in the aerospace and defense, intelligence, cybersecurity, information technology, financial and professional services, education, healthcare, infrastructure, and logistics support sectors. We are enlisted to address our clients’ most complex and important legal issues. Our work includes contract and subcontract negotiation and other transactional matters, business and regulatory compliance counseling, internal investigations, bid protests, and a wide array of enforcement and litigation matters. Our clients range from Fortune 50 companies to small and medium-sized companies just entering the public sector. We advise both U.S. and non-U.S. companies involved in municipal, state, federal, and non-U.S. procurement matters.<h2>ABOUT MORRISON FOERSTER</h2>Morrison Foerster is a leading global law firm that transforms complexity into advantage for its clients. Our clients include some of the largest financial institutions, banks, consulting and accounting firms, and Fortune 100, technology, and life sciences companies. Highlighting the firm’s commitment to client service, leadership in market-changing deals and impact litigation, and values-based culture, Morrison Foerster has been repeatedly recognized as one of the top 10 firms on The American Lawyer’s A-List. Year after year, the firm receives significant recognition from Chambers and The Legal 500 across their various guides, including Global, USA, Asia‑Pacific, Europe, UK, Latin America, and FinTech Legal. Our lawyers passionately care about delivering legal excellence while living our values. Morrison Foerster has a long-standing commitment to creating a culture that respects and celebrates differences, while providing an inclusive environment. The firm has achieved Mansfield Certification Plus since 2018 as a result of successfully reaching at least 30 percent women, communities of color, and LGBTQ+ lawyer representation in a notable number of current leadership roles and committees. The firm also has a long history of commitment to the community and society through providing pro bono legal services, including litigating for civil rights and civil liberties, improving public education and fostering the wellbeing of children, advocating for veterans, promoting international human rights, enforcing the right to asylum, and safeguarding the environment.

Social

Search

GAO Protest Timeline

govcon-gao-protest-timeline-thumb.jpg

Govcon GAO Post Award Protest Timeline Article

Contract Disputes Act Claim Timeline

govcon-contract-disputes-timeline-thumb.jpg

The Bayh-Dole Act

govcon-bayhdole-thumb.jpg

Anatomy of a Protest

govcon-federalclaimsprotest-thumb.jpg

Allowability of Legal Costs

govcon-allowabilityoflegalcosts-thumb.jpg

Procurement Integrity Act

240715-procurement-integrity-act-resized.jpg

Govcon-Resources

Tina is Co-chair of Morrison Foerster’s Government Contracts & Public Procurement practice. She represents a wide variety of government contractors including information technology, defense, biotechnology, and pharmaceutical companies, with a focus on general contract counseling and compliance, particularly concerning intellectual property, and cybersecurity matters and federal grant funding.Tina counsels contractors on compliance with federal, state and local acquisition and ethics regulations and with the evolving myriad of requirements pertaining to data security and cybersecurity. She has been involved with numerous internal investigations and compliance reviews, and with mandatory and voluntary disclosures to agencies, and litigation of False Claims Act matters.Tina routinely advises clients concerning:<ul><li>Prime-subcontractor relationships</li><li>Sources of supply and country of origin requirements</li><li>Price reductions and price reporting issues</li><li>Organizational conflicts of interest</li><li>Safeguarding of intellectual property and other proprietary interests</li><li>Licensing and data rights issues</li><li>Handling of classified materials and controlled unclassified information</li><li>Agency suspension and debarment proceedings</li></ul>She also assists clients with due diligence and other activities related to the acquisition of government contracting concerns, and with the drafting and negotiation of teaming agreements, subcontracts, licensing agreements, and cooperative research and development agreements. She also assists clients applying for federal grants (including SBIR and STTR agreements), and those who seek to obtain other transactional authority agreements, as well as those competing for state and local government work.Tina’s litigation experience includes government contracts claims litigation in federal courts and before boards of contract appeals, bid protests before the Government Accountability Office and the Court of Federal Claims, and complex disputes in federal courts, including civil fraud and False Claims Act litigation and reverse Freedom of Information Act litigation.Prior to joining Morrison Foerster, Tina worked at another large national firm and as a trial attorney in the Office of the General Counsel of the Navy, Navy Litigation Office.<h4>Representative Experience</h4><ul><li>Negotiation of largest CHIPS Act federal funding agreement between multinational semiconductor corporation and U.S. Department of Commerce.</li><li>Negotiated prime contract and major subcontracts related to the Department of Energy’s next generation supercomputer program, including extensive IP rights negotiations and negotiation of associated patent rights waivers.</li><li>Negotiated series of other transaction authority agreements with DARPA and associated subcontracts with more than a dozen research universities on behalf of a firm biotech client, including complex IP rights allocations and material transfer agreements.</li><li>Assist clients with FedRAMP authorization process and with development of license agreements for software products sold to federal, state and local government agencies.</li><li>Cyber incident response counseling to some of the largest companies and organizations impacted by security incidents.</li><li>Advises clients on Bayh-Dole reporting of inventions and IP strategies for contracts and grants.</li><li>Conducts due diligence for major government contract mergers and acquisitions.</li></ul>

reynolds_tina_blog_150x150.png

reynolds_tina_common_640x280.jpg

reynolds_tina_heroretina_2700x1160.jpg

reynolds_tina_mobileretina_750x1040.jpg

reynolds_tina_social_600x600.jpg

Partner

Tina is co-chair of Morrison Foerster’s Government Contracts & Public Procurement practice. She counsels a wide variety of government contractors on compliance with federal acquisition and ethics regulations. She drafts and negotiates contracts on their behalf and has been involved with numerous internal investigations and compliance reviews, and with bid protest, contract claims, and False Claims Act litigation. She also advises on M&A transactions involving government contractors.

Tina D. Reynolds

Jim Tucker is of counsel in Morrison Foerster’s Government Contracts and Public Procurement Practice Group and is based in the firm’s Washington, D.C. office.Jim’s practice runs the gamut of litigation and counseling in federal procurement matters, with an emphasis on bid protests, Cost Accounting Standards disputes, and small business matters. He has represented both protesters and awardees in scores of protests before the Government Accountability Office, the Court of Federal Claims, and procuring agencies, in acquisitions ranging from small business procurements to multibillion-dollar contracts of global significance. His representative protest matters span the aerospace sector, the Intelligence Community, base operations and logistics, healthcare, nuclear and environmental work, and information technology and software acquisitions. His protests have included both classified and unclassified programs. In addition to prevailing in published decisions, Jim has also secured favorable corrective action on behalf of clients in a wide variety of protests that were resolved without a published decision.Jim’s work also focuses on disputes over cost allowability and compliance with the Cost Accounting Standards, and he has appeared before the Armed Services and Civilian Boards of Contract Appeals, in size and status protests before Small Business Administration (SBA) area offices, and appeals before the SBA Office of Hearings and Appeals. Jim regularly counsels clients on contract interpretation, organizational conflicts of interest, and small business compliance.Jim graduated with high honors from the George Washington University Law School, where he focused his studies on federal procurement law, was a member of the Law Review, and interned with the General Services Administration’s suspension and debarment office. Jim also holds a degree in theology magna cum laude from the Pontifical Gregorian University in Rome and a bachelor’s degree in classical languages and literature summa cum laude from the University of Kentucky, where he graduated Phi Beta Kappa.

tucker_james_blog_150x150.png

tucker_james_common_640x280.jpg

tucker_james_heroretina_2700x1160.jpg

tucker_james_mobileretina_750x1040.jpg

tucker_james_social_600x600.jpg

Of Counsel

Jim maintains an active practice in bid protests before the Government Accountability Office and contracting agencies and counsels clients in contract disputes and compliance obligations.

Jim Tucker is of counsel in Morrison Foerster’s Government Contracts and Public Procurement Practice Group and is based in the firm’s Washington, D.C. office. Jim’s practice runs the gamut of litigation and counseling in federal procurement matters, with an emphasis on bid protests, Cost Accounting Standards disputes, and small business matters.

James Tucker

<div style="margin-bottom: 15px;" class="videoWrapper"><iframe class="sticky-video" title="Meet Alex Ward, Government Contracts Practice Co-Chair" src="https://www.youtube-nocookie.com/embed/TkliwdSlTaQ?rel=0" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen="1" title="iframe"></iframe></div>J. Alex Ward is co-chair of Morrison Foerster’s Government Contracts and Public Procurement group. His practice covers a full range of government contracts matters, including investigations, bid protests, claims, general litigation, corporate transactions, and counseling. Alex strives in all matters is to provide his clients the highest level of efficient and effective representation.Alex represents contractors in internal and external investigations, disclosures to the government, and qui tam litigation, with great success in reducing or eliminating his clients’ exposure through active engagement with the government. His work in this area includes obtaining numerous declinations and dismissals of False Claims Act cases in their earliest stages, sparing his clients the cost, risk, and exposure of litigation.He has also served as lead counsel in dozens of bid protests involving military and civilian agency procurements of a wide range of products and services, including all manner of pre- and post-award protests in the GAO, the U.S. Court of Federal Claims, and state tribunals, as well as appeals to the U.S. Court of Appeals for the Federal Circuit and size protest appeals before the SBA’s Office of Hearings and Appeals.Alex handles all aspects of the claims process, from the initial assessment and drafting of requests for equitable adjustment through litigation in the Boards of Contract Appeals and the Court of Federal Claims. Alex’s practice also covers the full gamut of other controversies confronting government contractors, including prime-sub, teaming partner, employer-employee, competitor, and indemnification disputes. His litigation work also includes a wide variety of pro bono engagements, in which he has represented both individual and institutional clients in matters ranging from immigration and criminal defense to sustainable procurement and protection of the environment.Prior to joining the firm, Alex served in the U.S. Army as a commissioned officer and an Assistant to the General Counsel of the Army responsible for civil works and international matters, and as a clerk for judges on the U.S. Courts of Appeals for the Armed Forces and the D.C. Circuit. He is a member of the Boards of the Morrison & Foerster Foundation and the Chesapeake Bay Foundation and of Law360’s Government Contracts Editorial Board.

ward_alex_blog_150x150.png

ward_alex_common_640x280.jpg

ward_alex_heroretina_2700x1160.jpg

ward_alex_mobileretina_750x1040.jpg

ward_alex_social_600x600.jpg

Alex is co-chair of Morrison Foerster’s Government Contracts and Public Procurement practice. His practice covers a full range of government contracts matters, including bid protests, claims, investigations, corporate transactions, and counseling.

J. Alex Ward

favicon.ico

favicon-16x16.png

favicon-32x32.png

apple-touch-icon.png

MoFo Favicons

Morrison Foerster’s Government Contracts Insights blog provides an in-depth analysis of news, developments, and trends impacting government contracting and procurement. Through Insights, attorneys from our nationally recognized Government Contracts and Public Procurement practice will offer a real-time assessment of the statutory, regulatory, legal, and business-related developments that are shaping the industry. This blog will also examine a full array of U.S. and non-U.S. public procurement issues, mindful that our clients compete in a global marketplace.Read about our <a href="http://govcon.mofo.com/editors/">Authors</a>.Never miss a post. Subscribe to get real-time updates.

Brad is a partner in Morrison Foerster’s Litigation Department, Managing Partner of the Austin office, and Chair of the firm’s Israel practice. He is the former Co-Chair of the firm’s Global Litigation Practice and the Government Contracts + Public Procurement Practice.

Bradley Wine

gov-con-feature-image-thumb1.jpg

Welcome to the Government Contracts Insights Blog

Welcome to the Government Contracts Insights Blog

gov-con-feature-image_(1)1.jpg

The United States Capitol building

Morrison Foerster’s Government Contracts Insights blog provides an in-depth analysis of news, developments, and trends impacting government contracting and proc

Announcements & Press

Blog - Terms of Use

Blog - Privacy Policy

Blog - Blog Disclaimer

Blog - Attorney Advertising

morrison-foerster-blog-logo.png

Provides insights and reports on the most current class actions lawsuits and product liability issues that affect consumer-facing companies.

Class Dismissed Blog

Class Dismissed

Looks behind the headlines to explore the trends, identify the opportunities, analyze the issues, and provide guidance for science and technology-based companies.

MoFo Tech

Mofo Tech

News and thought leadership from lawyers who are adding value to the legal profession and the communities we call home.

  External-Link

MoFo + Blog

Mofo+

Stay on top of emerging issues and stay informed of developments related to the law and business of social media.

Socially Aware

Our Government Contracts Insights blog provides in-depth analysis of developments and trends impacting U.S. government contracting and non-U.S. public procureme

Government Contracts Insights

  Linkedin

MoFo LinkedIN

Blog - Govcon RSS

Stay Connected

Never miss a post from Government Contracts Insights. Enter your email below to stay up-to-date.

Subscribe

The latest updates and analysis from Morrison Foerster

Morrison Foerster - Footer

Blogs -  Home Button

Home

Blog - Topics

Acquisition Regulations

Artificial Intelligence + Robotics

Compliance

Coronavirus

Cybersecurity & Data Privacy

Data Rights

Defense

Domestic Preferences

False Claims Act

Federal Procurement

Foreign Corrupt Practices Act

Grants

Health Care

Intellectual Property

International Public Procurement

Labor & Employment

Mergers & Acquisitions

National Security

Protests & Litigation

Resources

Schedule Contracting

Small Business

Topics

Blog - Editors

Editors

Blog - About

About

Blog - Subscribe

More

James A. Tucker

The Tortured Regulations Department: SBA’s New Rule and Its Effect on Investments

Bid Protest Spotlight: Standing, Relationships, Responsibility

House’s Passage of the SAMOSA Act Signals Policy Shift Towards Government-Wide Enterprise Software Licensing

New DFARS Regulation on Small Business Affiliate Past Performance

Bid Protest Spotlight: Unclear Criteria, Data Rights, Conflicts

LinkedIN

The Federal Risk and Authorization Management Program (FedRAMP), the program for authorization of cloud services for sale to the federal government that has been around since 2011, is getting an upgrade. On July 25, 2024, the Office of Management and Budget (OMB) issued a memorandum titled “<a href="https://www.whitehouse.gov/wp-content/uploads/2024/07/M-24-15-Modernizing-the-Federal-Risk-and-Authorization-Management-Program.pdf" target="_blank">Modernizing the Federal Risk and Authorization Management Program</a>” (the “July OMB Memorandum”), which rescinds and replaces the December 8, 2011 OMB Memorandum, “<a href="https://www.whitehouse.gov/wp-content/uploads/legacy_drupal_files/omb/assets/egov_docs/fedrampmemo.pdf" target="_blank">Security Authorization of Information Systems in Cloud Computing Environments</a>.” The July OMB Memorandum provides an updated “vision, scope, and governance structure for FedRAMP” in light of developments in the federal cybersecurity landscape and cloud marketplace, and it sets the stage for significant changes to FedRAMP over the coming months and years.­­­­One significant impact to cloud service providers (CSPs), including those with new artificial intelligence products and services, will be the changes to the FedRAMP authorization process. As the federal government pivots from government-specific cloud software services to commercial offerings, and as those offerings expand, it will be even more important to authorize additional technologies quickly and efficiently.  Governance StructureThe General Services Administration (GSA) has long held the lead agency role in administering and operating the FedRAMP Program Management Office (PMO), and that will continue to be case in the updated FedRAMP framework. As part of the FedRAMP update, however, the GSA will also be supported by the FedRAMP Board, which replaces the Joint Authorization Board (JAB) from the original FedRAMP. The FedRAMP Board is a governance body responsible for reviewing and approving FedRAMP policies, and for bringing together federal technology leaders to expand FedRAMP’s capacity for authorizing cloud services. The FedRAMP Board consists of at least one official from each of the GSA, the Department of Homeland Security (DHS), and the Department of Defense (DoD), as well as up to four additional officials from other agencies who are appointed by the OMB in consultation with the GSA. The GSA and the FedRAMP Board will also be supported by two advisory bodies:  the Federal Secure Cloud Advisory Committee (FSCAC) and the FedRAMP Technical Advisory Group (TAG). The FSCAC has both government and private-sector members and makes recommendations to the GSA regarding how to make FedRAMP more effective. By contrast, the TAG consists exclusively of federal technology experts who serve as subject matter experts and resources for continuous monitoring, performance risk assessments, and technical reviews of authorization packages.FedRAMP Authorization PathsFedRAMP has historically offered CSPs two paths to obtaining FedRAMP authorization to operate (ATO):  (1) authorization through the JAB (“JAB Authorization”) or (2) an individual agency ATO. The JAB Authorization process was intended to streamline the procedure for specific cloud offerings based on the JAB’s pre-vetting of the offering’s security and risk posture. It allowed an agency sponsor to issue an ATO based on its understanding that the JAB has already reviewed and approved the offering for use. In practice, very few CSPs were able to take advantage of this process. The “Agency Authorization” process required an individual agency sponsor to assess the security posture of an offering and then issue an ATO. Additional agencies that wanted to use the offering had to undertake their own reviews prior to issuing an ATO; although, in practice, many agencies relied on the prior agency ATO as a baseline for their review. This longstanding authorization framework will now undergo some significant changes:<ul><li>JAB Authorizations will be replaced by Program Authorizations. The JAB Authorization process will no longer exist because the JAB, itself, will no longer exist.  Instead, CSPs can seek “Program Authorizations” for their offerings.  Program Authorizations will be signed by the FedRAMP Director and are intended “to allow the FedRAMP program to enable agencies to use a cloud product or service for which an agency sponsor has not been identified, but for which use by a number of Federal agencies could be reasonably expected should the CSO be authorized.” In other words, Program Authorizations will allow CSPs to have their offerings authorized for use even if there is no particular agency lined up as a customer. This is a potentially significant change, as it could enhance a CSP’s ability to market its offerings government-wide. At the same time, there is a practical question of whether CSPs will invest time and resources in obtaining FedRAMP authorization without at least one agency customer lined up (temporary authorizations, discussed below, could address this concern). According to FedRAMP, in the short term, Program Authorizations will be limited to “CSPs who were either queued or prioritized to work with the Joint Authorization Board (JAB), with a future focus on building out criteria and an approach for opening this path market-wide.”  See The Next Phase of FedRAMP, <a href="https://www.fedramp.gov/2024-07-26-the-next-phase-of-fedramp/" target="_blank">https://www.fedramp.gov/2024-07-26-the-next-phase-of-fedramp/</a> (last accessed Aug. 5, 2024). </li><li>Agency Authorizations will accommodate multiple agencies.  Although the current Agency Authorization process will remain largely intact, one significant change will be that Agency Authorizations will not be limited to a single sponsoring agency. Rather, “[a]uthorizations can also be conducted jointly by multiple agencies, to enable a cohort of agencies with similar needs to pool resources and achieve consensus on an acceptable risk posture for use of the cloud product or service.” The FedRAMP Board will be responsible for identifying federal agency technology leaders to form such authorization groups. Thus, as with Program Authorizations, Agency Authorizations should allow for greater adoption and use of offerings across the federal government.</li><li>FedRAMP will consider additional authorization paths.  Although the July OMB Memorandum only identifies Program Authorizations and Agency Authorizations as pathways for FedRAMP authorization, OMB has also indicated that FedRAMP will consider additional authorization methods that promote the availability and adoption of commercial cloud offerings without sacrificing FedRAMP security standards. Whether such alternatives actually materialize is an open question, but the OMB’s openness to new pathways signals a renewed focus on flexibility to align with the rapidly evolving commercial cloud sector.</li></ul>Additional CSO DesignationsUnder the current FedRAMP regime, cloud offerings could receive a designation that the offering is “FedRAMP Ready,” “FedRAMP In-Process,” or “FedRAMP Authorized.” The FedRAMP Ready designation means a third-party assessor has attested to a particular cloud offering’s security capabilities, and that that a Readiness Assessment Report has been reviewed and deemed acceptable by the FedRAMP PMO. See <a href="https://www.fedramp.gov/about-marketplace/#:~:text=FedRAMP%20In%20Process%20indicates%20a,listed%20on%20the%20FedRAMP%20Marketplace." target="_blank">FedRAMP Marketplace Designations</a>. It typically means the offering has a high likelihood of achieving a FedRAMP authorization. Id. The FedRAMP In-Process designation indicates a CSP is actively working towards obtaining a FedRAMP authorization for its offering. Id. And, of course, the FedRAMP Authorized designation means the CSP has successfully completed the FedRAMP authorization process for the cloud offering and that the offering is now available for agency use. Id.One of the primary purposes of the FedRAMP Ready and FedRAMP In-Process designations is to increase agency awareness of cloud offerings that are in the pipeline for FedRAMP authorization, while also bolstering the FedRAMP marketplace with more offerings. In furtherance of this goal, the July OMB Memorandum indicates that the updated FedRAMP process may include the creation of additional designations for offerings that do not yet have full FedRAMP authorization. In particular, FedRAMP will develop procedures for issuing “a time-specific temporary authorization,” which would allow agencies to “pilot” the use of new cloud services before they are FedRAMP Authorized for no longer than 12 months. This temporary authorization would terminate at the end of the 12-month pilot period unless the offering has a FedRAMP In-Process designation.This temporary authorization process is a potential gamechanger.  First, it likely boosts the value of obtaining a FedRAMP Ready designation because that designation will put agencies on notice of a CSP’s offering and make it more likely that agencies would pursue a temporary authorization to use the offering before it obtains FedRAMP authorization. Second, it is likely to incentivize more CSPs to enter the public sector marketplace because the lead time to work with federal agencies will be reduced significantly. The FedRAMP PMO still needs to provide further guidance on how the pilot program will work, but this will likely be a key area of interest for CSPs.Automation and EfficiencyThe July OMB Memorandum identifies several initiatives aimed at increasing efficiency in the FedRAMP authorization and continuous monitoring processes. One focal point is an emphasis on automation. For example, the updated FedRAMP processes will require submission of all artifacts required for authorization and continuous monitoring in machine-readable format using application programming interfaces, to the extent possible.  Moreover, to promote interoperability, FedRAMP will work with stakeholders, including OMB, the National Institutes of Science and Technology, and the Cybersecurity and Infrastructure Security Agency, to support the submission of security assessment artifacts and continuous monitoring information using Open Secure Control Assessment Language (OSCAL), or any succeeding protocol, as defined by FedRAMP.  FedRAMP will also be exploring the use of artificial intelligence tools as part of the FedRAMP security assessment and continuous monitoring processes. Initial steps will include piloting emerging technologies to determine feasibility and utility.FedRAMP is also examining ways to drive efficiency in the authorization process through reliance on existing security frameworks. Recognizing that “[p]erforming an additional assessment of each offering every time a product that uses an existing certification goes through the FedRAMP process unnecessarily slows the adoption of such cloud computing products and services by the Federal Government,” the GSA and FedRAMP Board will establish criteria for accepting widely recognized external security frameworks and certifications (e.g., ISO, SOC II) applicable to cloud products and services. FedRAMP will initially target external security frameworks for offerings that are FIPS 199 impact level low, but it may expand to higher impact levels if feasible.Continuous MonitoringThe FedRAMP update also contemplates changes to the continuous monitoring process. Perhaps most significant is the directive that the FedRAMP PMO revise the continuous monitoring process to “empower CSPs to deploy changes and fixes at their own pace, without requiring advance approval from FedRAMP or an authorizing official for individual changes to existing FedRAMP authorized products and services.” This directive could signal the end of the current significant change process, which requires CSPs to complete the FedRAMP Significant Change Request Form and provide it to the authorizing official for analysis at least 30 days prior to implementing a significant change.Transition Away from Government-Specific Cloud InfrastructureAnother notable aspect of the FedRAMP update is the desire to “use the same infrastructure relied on by the rest of CSPs’ commercial customer base.” FedRAMP wants to leverage shared infrastructure between the federal government and the private sector because the “Federal Government benefits from the investment, security maintenance, and rapid feature development that commercial cloud providers give to their core products to succeed in the marketplace.” In other words, FedRAMP wants to take advantage of CSP innovations, which may be slower to migrate to federal government-specific versions of offerings. Depending on how this priority is implemented, it could mean many CSPs will no longer need to develop federal government-specific versions of their commercial offerings. This could both expand the universe of offerings available to the government and create financial benefits and efficiencies for CSPs.Implementation of the July OMB MemorandumOMB is requiring FedRAMP to submit annual plans in the second quarters of fiscal years 2025 and 2026 detailing planned program activities for implementing the updated FedRAMP framework, including staffing plans and budget information. In addition, OMB has established the following benchmarks:<ul><li>Within 180 days of issuance of the July OMB Memorandum, each agency must issue or update agency-wide policy that aligns with the memorandum’s requirements and promotes the use of cloud computing products and services that feed FedRAMP security requirements.</li><li>Within 180 days of issuance of the July OMB Memorandum, GSA will update FedRAMP’s continuous monitoring processes and associated documentation.</li><li>Within one year of the issuance of the July OMB Memorandum, GSA will produce a plan, approved by the FedRAMP Board and developed in consultation with industry, to structure FedRAMP to encourage the transition of federal agencies away from the use of government-specific cloud infrastructure. As part of the plan development process, GSA will explore the use of emerging technologies in various FedRAMP processes, as appropriate.</li><li>Within 18 months of the issuance of the July OMB Memorandum, GSA will build on existing efforts to receive FedRAMP authorization and continuous monitoring artifacts through automated, machine-readable means, to the extent possible.</li><li>Within 24 months of the issuance of the July OMB Memorandum, agencies shall ensure that agency governance, risk, and compliance and system-inventory tools can ingest and produce machine-readable authorization and continuous monitoring artifacts using OSCAL, or any succeeding protocol, as identified by FedRAMP.</li></ul>ConclusionThe proposed changes to the FedRAMP authorization process and subsequent implementation have the potential to expedite and simplify the authorization process, which would benefit government agencies and CSPs alike. The current timeline for authorization can average more than a year, discouraging some CSPs from participating. The potential recognition of other standards for federal government purposes would also increase the availability of offerings available for sale to the government. Finally, the federal government’s recognition of the value, and even superiority, of commercial offerings that are not customized specifically for government purposes will bring even more efficiencies to the authorization process.

Tina is a partner in Morrison & Foerster’s Government Contracts practice. She represents a wide variety of government contractors including information technology, defense, biotechnology, and pharmace

Tina Reynolds

nandivada_sandeep_blog_150x150.png

nandivada_sandeep_common_640x280.jpg

nandivada_sandeep_heroretina_2700x1160.jpg

nandivada_sandeep_mobileretina_750x1040.jpg

nandivada_sandeep_social_600x600.jpg

Sandeep Nandivada is a partner in the Litigation Department of Morrison & Foerster’s Washington, D.C. office.

Sandeep N. Nandivada

Sandeep Nandivada

12_30_cybersecurity_07.jpg

DOJ Cyber-Fraud Initiative Highlights Potential Civil Liability for Failing to Meet Federal Cybersecurity Requirements

FedRAMP to the Future

An Overview of the Defense Department’s Long-Awaited Proposed Regulations for Its Cybersecurity Maturity Model Certification Program

protests-and-litigation-600-300x148.jpg

An Overview of the Defense Department’s Long-Awaited Proposed Regulations for Its Cybersecurity Maturity Model Certification Program

GAO Finds CIO-SP4 Solicitation Is Unduly Restrictive of Competition

The U.S. Department of Defense released a special holiday treat for government contractors and subcontractors last week in the form of long-promised proposed regulations for its Cybersecurity Maturity Model Certification (CMMC) program. 

The FAR Council’s Proposed Cybersecurity Overhaul: Lots of Questions, but Only Some Answers

The FAR Council’s Proposed Cybersecurity Overhaul: Lots of Questions, but Only Some Answers

In what can best be described as a tsunami of cybersecurity regulation, the Federal Acquisition Regulation (FAR) Council—consisting of the Department of Defense (DoD), General Services Administration (GSA), and National Aeronautics and Space Administration (NASA)—issued two proposed rules on October 2, 2023.

In the extensive chatter since the Federal Acquisition Regulatory Council (“FAR Council”) published an interim rule on the new Federal Acquisition Regulation (FAR) 52.204-27, “Prohibition on a ByteDance Covered Application,” commentators have almost universally advised that if a federal contractor’s employee uses a device in connection with a government contract in any way, TikTok is banned on that device.  These conclusions seem to rely on the common understanding of the term “information technology.”  But both the underlying congressional statute and the new implementing FAR clause adopt a specific statutory definition of “information technology” that is far more nuanced and far from clear in its scope.  Contractors may be ignoring this nuance and reading too much into the clause to their disadvantage.  Rather than assume the ban is more extensive than the text of the interim rule requires, contractors should use the notice-and-comment period to ask the FAR Council to clarify the rule’s intended scope.Statutory and Regulatory FrameworkThe No TikTok on Government Devices Act became law on December 29, 2022, as part of the <a href="https://www.congress.gov/bill/117th-congress/house-bill/2617/text">Consolidated Appropriations Act of 2023</a>, Public Law 117-328 (the “Act”).  The Act requires all federal agencies to follow Office of Management and Budget (OMB) guidance to ensure that TikTok, and any other successor applications or services developed or owned by ByteDance Limited, are removed from all federal information technology.  The Act covers “information technology” as defined in 40 U.S.C.§ 11101(6), which states: <div></div>The term “information technology”—(A) with respect to an executive agency means any equipment or interconnected system or subsystem of equipment, used in the automatic acquisition, storage, analysis, evaluation, manipulation, management, movement, control, display, switching, interchange, transmission, or reception of data or information by the executive agency, if the equipment is used by the executive agency directly or is used by a contractor under a contract with the executive agency that requires the use—(i) of that equipment; or(ii) of that equipment to a significant extent in the performance of a service or the furnishing of a product;(B) includes computers, ancillary equipment (including imaging peripherals, input, output, and storage devices necessary for security and surveillance), peripheral equipment designed to be controlled by the central processing unit of a computer, software, firmware and similar procedures, services (including support services), and related resources; but(C) does not include any equipment acquired by a federal contractor incidental to a federal contract.On February 27, 2023, the OMB released<a href="https://www.whitehouse.gov/wp-content/uploads/2023/02/M-23-13-No-TikTok-on-Government-Devices-Implementation-Guidance_final.pdf"> </a><a href="https://www.whitehouse.gov/wp-content/uploads/2023/02/M-23-13-No-TikTok-on-Government-Devices-Implementation-Guidance_final.pdf">Memorandum M-23-13</a> (“OMB Memorandum”), which provides guidance on implementing the Act’s mandates.  The OMB guidance also referenced the statutory definition of information technology in 40 U.S.C. § 11101(6), and noted (emphasis added): That definition reaches not only IT owned or operated by agencies, but also IT “used by a contractor under a contract with the executive agency that requires the use” of that IT, whether expressly or “to a significant extent in the performance of a service or the furnishing of a product.”  That definition does not, however, “include any equipment acquired by a federal contractor incidental to a federal contract.”OMB did not elaborate on what it means for a contract to “require[] the use” of particular IT, what a “significant extent” is, or what “incidental” means in this context.On June 2, 2023, the FAR Council published an<a href="https://www.federalregister.gov/documents/2023/06/02/2023-11756/federal-acquisition-regulation-prohibition-on-a-bytedance-covered-application"> </a><a href="https://www.federalregister.gov/documents/2023/06/02/2023-11756/federal-acquisition-regulation-prohibition-on-a-bytedance-covered-application">interim rule</a>, effective immediately, implementing the Act and OMB Memorandum and requiring inclusion of the new FAR 52.204-27 clause in solicitations issued on or after June 2.  The interim rule also calls for modification of indefinite-delivery contracts to apply the FAR clause to future orders, inclusion of the clause in existing contracts when options are exercised or the period of performance extended, and amendment of pending solicitations to add the clause by no later than July 3, 2023. In the “discussion and analysis” preface to the interim rule, the FAR Council stated, in an oft-quoted conclusion:  “The FAR clause at 52.204–27 prohibits contractors from having or using a covered application on any information technology owned or managed by the Government, or on any information technology used or provided by the contractor under a contract, including equipment provided by the contractor’s employees.”  88 FR 36431.  It also notes, however, that the interim rule “uses the statutory definition of ‘information technology’ because Public Law 117-328 does so.  This is different from the FAR definition of ‘information technology’ at 2.101, which excludes imbedded information technology.”  Id.Contributing to the perceived breadth of the interim rule, the FAR Council and Administrator for Federal Procurement Policy have decided to apply the new FAR clause to essentially all federal contracts, including contracts at or below the simplified acquisition threshold; contracts for commercial products and services, including commercially available off-the-shelf (COTS) items; and contracts at or below the micropurchase threshold.  The clause is also a mandatory flowdown in all subcontracts, including those for commercial products or commercial services.Open Questions Create Ambiguity in Application of the RuleAlthough Congress, the OMB, and the FAR Council all use the 40 U.S.C. § 11101(6) definition of information technology, none has explained what the definition means in this context.  This creates ambiguity in the application of the new FAR clause.  This is so because the definition does not encompass all contractor information technology, or even contractor information technology that may somehow relate to a covered contract.  Instead, the definition extends only to equipment that “is used by a contractor under a contract with the executive agency that requires the use— (i) of that equipment; or (ii) of that equipment to a significant extent in the performance of a service or the furnishing of a product.”  (Emphasis added.)  The rule also continues to carve out an exception for “equipment acquired by a federal contractor incidental to a federal contract.”  (Emphasis added.) Ambiguities abound, which prevent anyone from stating with certainty what the scope of this new rule is.  For example, what is the difference between an agency (i) requiring use of equipment, or (ii) requiring use of that same equipment to a significant extent?  The FAR Council, like Congress, joined these two requirements with a disjunctive “or,” so presumably they are intended to be two different categories of requirements.  But, if any contractually required use of the equipment triggers the ban, then required use “to a significant extent” are empty words that simply prohibit what is already prohibited under the first prong of the disjunction.  That is not the way statutes or regulations usually work, so the drafters almost certainly meant something other than what the text seems to say.[1]This mystery notwithstanding, it seems apparent that to meet the definition of “information technology” covered by the new FAR clause, a government agency must have required use of the equipment in connection with a government contract.  This happens with some regularity in terms of government-furnished equipment, or implicit requirements for contractors to use their own equipment to access government systems.  However, explicit agency directives do not generally extend to day-to-day use of company-issued laptops, or employees’ personal devices, to conduct all other work related to government contracts, such as email communications with customers.  Strictly applying the new clause’s text, a specific contractual requirement to use particular equipment would be necessary for the TikTok ban to apply.  There almost certainly would be no such requirement specified in a micropurchase order, or simplified purchase order for a COTS product.  It thus seems there is a significant disconnect between what most observers assume is an intended broad reach of the interim rule, and the textual definition of “information technology” in the rule itself. And what does the carve-out for “any equipment acquired by a federal contractor incidental to a federal contract” mean?  In the absence of an agency requirement for a contractor (or subcontractor) to use its own (or its employees’) information technology equipment in connection with a government contract, wouldn’t most contractor or bring your own device (BYOD) equipment fall within the “incidental” equipment exception? The authors of the congressional statute, the OMB Memorandum, and the interim rule adopted a narrow definition of “information technology” that is at odds with the much more extensive scope that most observers assume the “TikTok ban” has.  Lack of clarity in the statute, the memorandum, and the regulation is stymying contractors’ ability to know precisely what equipment is covered, and how they are supposed to implement the ban.  Ironically, the FAR Council, in concluding that the new clause imposes minimal burdens on contractors, states without providing any guidance:  “It will be particularly important for contractors to clearly explain to their employees when a covered application is prohibited on a personal device used in performance of a Federal contract.”  88 FR 36432.  If procurement attorneys and industry experts can’t explain with certainty what exactly is banned, it is unclear how businesses can be expected to explain it to their employees.   Issues for CommentThe FAR Council has invited industry to submit comments on the interim by August 1, 2023.  We urge impacted contractors, subcontractors, and the trade associations that represent them to accept that invitation.  Among the questions that require clarification are:<ul><li>If an agency does not specifically require use of specific information technology equipment, does that mean such equipment is not covered by the clause? </li><li>What would such a “requirement” look like?  For example, is it a requirement only if the contract itself (or a written order of the contracting officer) states the contractor must use the specific technology?</li><li>How can the clause apply to micropurchases when the mechanisms used for such purchases—primarily use of government purchase cards—often do not involve the flow down or transfer of any formal terms to the “contractor”?</li><li>Does the ban cover any device that sends, receives, or stores data generated in the performance of a government contract?  If so, why does the clause not say that?</li><li>What distinction is meant by use “(i) of that equipment; or (ii) of that equipment to a significant extent in the performance of a service or the furnishing of a product”?  Does the FAR Council mean to say that the equipment is covered only if the contractor is required to use it “to a significant extent” (whatever that means)?  Or is all equipment covered if a contract expressly requires its use, plus any implicitly required equipment only if the contractor actually uses it “to a significant extent”?    </li><li>What does “incidental to a federal contract” mean?  If a contract does not expressly require a contractor to acquire or use particular equipment, does that make the equipment incidental? </li><li>Is use of a personal or company device to answer email from government customers “incidental”?  What about a device occasionally used to take telephone calls from government employees who want to discuss contract performance?  What about devices employees use to log time they spend working on company projects, including covered contracts?</li><li>What about use of a personal or company device to market or sell a product to a government customer?</li><li>Are COTS product manufacturers expected to ban TikTok from every one of their employees’ devices if those employees are in any way involved in the development of a product that the U.S. government purchases?</li><li>In the BYOD context, how does the FAR Council expect contractors to enforce employees’ compliance with the rule?  Is it enough to institute the policy and provide training, or are contractors expected to conduct random checks of the applications employees have on their BYOD telephones?</li></ul>These are just a few of the many questions that spring to mind when reading the imprecise interim rule.  Without clarification and precision in language, some contractors will over-comply, others will under-comply, and no one will be able to figure out who is right. In addition to demanding clarification, industry should advocate for a common-sense balance between the federal government’s legitimate national security concerns and the actual threat posed by the potential presence of TikTok on some contractor employees’ personal devices.  Mitigation measures, such as use of container management features to isolate work-related programs from the remainder of an employee’s device, are a potential option.  Given the prevalence of BYOD policies, such measures are arguably more secure than a mere written policy requesting that employees not use certain apps on the own devices. At the end of the day, a well thought out final rule is needed for the government to address its real concerns about intrusive technology.  No one’s interests are served by broad-brush prohibitions that lack enforcement mechanisms and are difficult to comprehend or implement as written.[1] The OMB, in Memorandum M-23-13, appears to interpret the first prong to refer only to express contract requirements, whereas the second is intended to capture use that is not expressly required but nevertheless comprises a “significant extent” of contract performance.  But that is not what the statute or regulation says.

Jim Tucker is of counsel in Morrison & Foerster’s Government Contracts and Public Procurement Practice Group and is based in the firm’s Washington, D.C. office.
Jim’s practice runs the gamut of litiga

bell_locke_blog_150x150.png

bell_locke_common_640x280.jpg

bell_locke_heroretina_2700x1160.jpg

bell_locke_mobileretina_750x1040.jpg

bell_locke_social_600x600.jpg

Locke Bell is a partner in the firm’s Government Contracts & Public Procurement practice.

Locke Bell

230622-cybersecurity.jpg

230622-cybersecurity

In the extensive chatter since the Federal Acquisition Regulatory Council (“FAR Council”) published an interim rule on the new Federal Acquisition Regulation (FAR) 52.204-27, “Prohibition on a ByteDance Covered Application,” commentators have almost universally advised that if a federal contractor’s employee uses a device in connection with a government contract in any way, TikTok is banned on that device.  These conclusions seem to rely on the common understanding of the term “information technology.” 

When Does the So-Called TikTok Ban Really Apply to Contractors and Their Employees?

On May 10, 2023, the National Institute of Standards and Technology (“NIST”) released an <a href="https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-171r3.ipd.pdf" target="_blank">Initial Public Draft</a> of Revision 3 to NIST Special Publication (“SP”) 800-171, Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations. Although still in draft form, the document provides important guidance to federal government contractors and other companies that must use NIST SP 800-171 as a baseline for cybersecurity compliance. The draft Revision 3 was informed by public comments received by NIST, and NIST is seeking additional public comment on this revision.BackgroundNIST is responsible for developing information security standards and guidelines, including minimum requirements for federal information systems. SP 800-171 is used as a baseline of security requirements for protection of controlled unclassified information (“CUI”)—sensitive information that requires certain confidentiality, access, or dissemination controls—when that information resides outside of federal government systems (i.e., on contractor systems).  The requirements apply to those components of nonfederal systems that process, store, or transmit CUI or that provide protection for such components, and only where no other applicable law, regulation, or policy prescribes different or more specific safeguarding requirements.  The NIST SP 800-171 requirements are imposed via contractual vehicles or other agreements established between federal agencies and nonfederal organizations. Outside of government agreements, commercial parties also may require or rely upon the requirements of NIST SP 800-171 as a cybersecurity compliance standard.The requirements of SP 800-171 are derived from <a href="https://nvlpubs.nist.gov/nistpubs/fips/nist.fips.199.pdf" target="_blank">Federal Information Processing Standards (“FIPS”) 199</a>, Standards for Security Categorization of Federal Information and Information Systems; <a href="https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.200.pdf" target="_blank">FIPS 200</a>, Minimum Security Requirements for Federal Information and Information Systems; and <a href="https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r5.pdf" target="_blank">NIST SP 800-53</a>, Security and Privacy Controls for Federal Information Systems and Organizations. For purposes of CUI protection under NIST SP 800-171, NIST has assumed that the confidentiality impact value for CUI is no less than moderate under the FIPS categorization methodology.  To develop the NIST SP 800-171 controls, NIST started with the more rigorous NIST SP 800-53 controls for a moderate control baseline, which satisfy the minimum security requirements under FIPS 200. It then tailored those controls to eliminate those that are:  (i) primarily the responsibility of the federal government; (ii) not directly related to protecting the confidentiality of CUI; or (iii) expected to be implemented by organizations without specification by the federal government.  The NIST SP 800-171 security requirements are a subset of controls necessary for an information security program. Under Revision 2, 14 control families were present; but with Revision 3, they are organized into 17 control “families,” as follows:<table><colgroup data-width='672'><col style="width:30.357142857142854%"><col style="width:26.785714285714285%"><col style="width:42.857142857142854%"></colgroup><tbody><tr><td>Access Control</td><td>Maintenance</td><td>Security Assessment and Monitoring</td></tr><tr><td>Awareness and Training</td><td>Media Protection</td><td>System and Communications Protection</td></tr><tr><td>Audit and Accountability</td><td>Personnel Security</td><td>System and Information Integrity</td></tr><tr><td>Configuration Management</td><td>Physical Protection</td><td>Planning*</td></tr><tr><td>Identification and Authentication</td><td>Risk Assessment</td><td>System and Services Acquisition*</td></tr><tr><td>Incident Response</td><td></td><td>Supply Chain Risk Management*</td></tr></tbody></table>Families with an asterisk (*) have been added with Revision 3 to maintain consistency with the NIST SP 800-53B moderate control baseline.Section 3 of NIST SP 800-171 describes applicable requirements for each of these control families, including numerous subcategories of requirements within each family.  For each subcategory, there is a discussion section, with examples, as well as references to source controls from NIST SP 800-53 and a list of supporting publications. As discussed below, one of the proposed changes with Revision 3 is the addition of organization-defined parameters (“ODP”), which allow for additional flexibility for federal agencies by permitting them to set specific values for defined parameters. Once specified, these ODP become part of the requirement.Proposed Changes Introduced Through NIST SP 800-171, rev. 3In the draft Revision 3, NIST has proposed several significant changes from the prior version of the publication. The updates are designed to streamline and clarify requirements.  Below, we highlight some of the most consequential modifications.Elimination of the distinction between basic and derived security requirementsNIST has proposed to eliminate the distinction between basic security requirements from FIPS 200 and derived requirements from NIST SP 800-53.  NIST SP 800-171 previously required compliance with both basic and derived controls, but the revision now proposes to require compliance only with derived controls. This is due in part to NIST’s recognition that FIPS 200 requirements are very high-level and lack sufficient specificity to be useful. Updating of security controlsNIST has proposed to streamline security requirements by removing outdated and redundant requirements. It has also added new security requirements, thus keeping the number of security controls approximately the same.   Increase in specificity of security requirementsNIST has proposed to increase the level of detail of the various security requirements in order to remove ambiguity, improve effective implementation, and clarify the scope of assessments. This was likely in reaction to feedback that previous requirements were open to interpretation, which has made compliance and security assessments more challenging. Introducing specificity has the potential to make compliance with specific controls more onerous by reducing organizational flexibility with respect to protecting CUI, but it also may facilitate compliance by clarifying security requirements.Update of security requirements to reflect recent changes in NIST SP 800-53 and SP 800‑53BNIST has updated the security requirements and families in NIST SP 800-171 to reflect updates in, and better align with, NIST SP 800-53, rev. 5 and <a href="https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53B.pdf" target="_blank">NIST SP 800-53B</a>, Control Baselines for Information Systems and Organizations. This was in response to feedback that organizations are overwhelmed by the number of potentially applicable security and risk management frameworks for the public and private sectors. To facilitate the harmonization of requirements, NIST has provided as part of the revision a <a href="https://csrc.nist.gov/csrc/media/Publications/sp/800-171/rev-3/draft/documents/sp800-171r3-ipd-cui-overlay.xlsx" target="_blank">Prototype CUI Overlay</a>, which shows how the moderate control baseline in NIST SP 800-53B can be tailored at the control and control‑item levels to align with the NIST SP 800-171 security requirements.Introduction of ODPAs noted above, another significant proposal is the introduction of ODP for certain security requirements. ODP currently are present in NIST SP 800-53 to provide government agencies with flexibility to tailor security requirements to their specific needs. NIST is now proposing to introduce ODP to NIST SP 800-171 to give federal agencies similar flexibility to tailor requirements for protection of CUI. ODP would be reflected in NIST SP 800-171 through agency‑assigned parameters such as time periods and numbers of operations, as shown in the example below:<div data-reactroot=""><img src="https://media2.mofo.com/v3/images/blt5775cc69c999c255/bltef14ed99f31b244f/64626cd16606ca423795dff7/230515-govcon-graphic.PNG?format=auto&amp;quality=60" alt="govcon graphic"/></div>View a detailed analysis of the updates from <a href="https://csrc.nist.gov/publications/detail/sp/800-171/rev-3/draft" target="_blank">Revision 2 to Revision 3</a>.Next StepsPublic comments on the Initial Public Draft should be submitted to NIST by July 14, 2023.  NIST has indicated that it is specifically interested in feedback related to re-categorized controls, ODP, and the Prototype CUI Overlay. See a <a href="https://csrc.nist.gov/csrc/media/Publications/sp/800-171/rev-3/draft/documents/sp800-171r3-ipd-comment-template.xlsx" target="_blank">template for comments</a>.In the meantime, federal contractors and others who are bound by the NIST SP 800‑171 requirements should review the updated revision and associated materials and prepare to adjust their security controls and systems at such time as the newly revised publication is adopted by their customers.  We recommend particular focus on the three new control families and their requirements. In terms of timing, contractors should bear in mind that Revision 3 generally will not require regulatory changes and may be implemented through contract modifications. For example, the applicable Defense Federal Acquisition Regulation Supplement (“DFARS”) clause requires compliance with the version of NIST SP 800-171 “in effect at the time the solicitation is issued or as authorized by the Contracting Officer.” DFARS 252.204-7012(b)(2)(i). Similarly, we have seen the Department of Veterans Affairs include language in certain contracts that commits the parties to agree to negotiate in good faith the implementation of updated security requirements in FIPS or NIST SPs after contract execution. In other words, Revision 3 not only will begin to be required as soon as it moves from draft to final publication in all new procurements, but also may be adopted for existing contracts through contract modifications.Even for those companies not involved in federal contracting, changes to NIST security requirements very often are adopted by industry more broadly as best practices, so these updates should also be carefully considered by the private sector more broadly.

NIST Releases Revised Cybersecurity Controls and Requirements for Protection of Controlled Unclassified Information Resident in Contractor Information Technology Systems

NIST Releases Revised Cybersecurity Controls and Requirements for Protection of Controlled Unclassified Information Resident in Contractor Information Technology Systems

On May 10, 2023, the National Institute of Standards and Technology (“NIST”) released an Initial Public Draft of Revision 3 to NIST Special Publication (“SP”) 800-171, Protecting Controlled Unclassified Information in 

The Cybersecurity and Infrastructure Security Agency (CISA) of the Department of Homeland Security (DHS) recently published a <a href="https://www.cisa.gov/resources-tools/resources/secure-software-self-attestation-common-form" target="_blank">draft version</a> of a Secure Software Development Attestation Common Form. The draft Common Form is designed to confirm that software producers (i.e., the manufacturers/developers of software products) have followed minimum secure software development practices in compliance with guidance created by the National Institutes of Standards and Technology (NIST). Such affirmation was mandated by a White House Office of Management and Budget (OMB) memorandum issued September 14, 2022, as a prerequisite to acquisition of software by federal agencies. Interested parties have until June 26, 2023 to comment on the draft form.As we have <a href="https://govcon.mofo.com/topics/companies-selling-software-to-the-u-s-government-soon-must-attest-to-compliance-with-nist-guidance-on-software-supply-chain-security" target="_blank">previously advised</a>, the purpose of the self-attestation form is to enhance the security of the nation’s software supply chain, which has been proven vulnerable by incidents like the Colonial Pipeline and Solar Winds attacks. The Common Form marks one step towards increased transparency, stability, and security of the software acquired by the federal government, consistent with President Biden’s <a href="https://govcon.mofo.com/topics/210601-executive-order-on-cybersecurity" target="_blank">Executive Order 14028</a>, Improving the Nation’s Cybersecurity.What Does the Common Form Entail?The Common Form is composed of three sections. Section I requires a list of the software to which the attestation applies, including software product name, version number, and release/publish date. Section II collects information about the software producer (name, address, etc.) and the responsible primary contact. Section III requires a signed attestation by the Chief Executive Officer or delegate that affirms the producer complied with the standards and best practices established in NIST Special Publication (SP) <a href="https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-218.pdf" target="_blank">800-218</a>, “Secure Software Development Framework” (SSDF).Specifically, the form requires producers to attest:<ol><li>The software is developed and built in secure environments;</li><li>The software producer made a good-faith effort to maintain trusted source code supply chains;</li><li>The software producer maintains provenance data for internal and third-party source code incorporated into the software; and</li><li>The software producer employs automated tools or comparable processes that check for security vulnerabilities.</li></ol>Agencies may also include additional requirements, such as a request for a Software Bill of Materials (SBOM) or other artifacts or documentation. Agencies may require such additional documentation or artifacts be either attached to the Common Form or maintained and updated at another agency-designated location online. It is anticipated that the Common Form will be a fillable PDF that will be submitted electronically by the software producer to CISA.What Software Is Covered by the Attestation Requirement?The Common Form covers three categories of software, based on its development date. A Common Form attestation is required for all software developed after September 14, 2022, in order to sell to the federal government. The Common Form is also required for existing software modified after September 14, 2022 with major version changes (e.g., using a semantic versioning schema of Major.Minor.Patch, the software version number goes from 2.5 to 3.0). Finally, the Common Form is required for software for which the producer delivers continuous changes to the software code (such as software-as-a-service products or other products using continuous delivery/continuous deployment).Software freely obtained directly by a federal agency (e.g., freeware or open-source software) and software developed internally by federal agencies require no attestation. However, open-source elements incorporated by software producers into a software deliverable must be part of the software producer’s attestation.If the relevant software has been verified by a certified FedRAMP third-party assessor organization (3PAO) or other 3PAO approved in writing by an appropriate agency official in accordance with relevant NIST guidance, the software producer does not need to submit an attestation, but must provide relevant documentation from the 3PAO instead.If it cannot fully attest to compliance with the SSDF, a software producer must provide documentation identifying the practice(s) to which it cannot attest. The purchasing agency then must document the practices the agency has in place to mitigate resulting risks and require a plan of actions and milestones (POAM) from the software producer to address compliance gaps.What Is the Estimated Burden?DHS <a href="https://www.govinfo.gov/content/pkg/FR-2023-04-27/pdf/2023-08823.pdf" target="_blank">estimates</a> the total opportunity costs to all software producers of completion of the Common Forms will be $923,623 annually, based on BLS labor rates and the following estimates. DHS anticipates receiving 2,689 initial form submissions and 1,345 resubmissions of the form—due to major software changes—per year. Each initial submission will impose a three-hour burden on a quality assurance analyst or tester to understand requirements and the gather information. Additionally, DHS estimates a Chief Information Security Officer (CISO) will require 20 minutes to review, and approve, the release of information in each initial submission.DHS assumes that half of initial submissions will result in resubmission for a major software change or update. Each resubmission DHS estimates will require a software quality assurance analyst or tester an additional hour and 30 minutes to complete and a CISO 20 minutes to review. Failure to ensure the accuracy of the attestation may result in a far greater burden, including potential False Claims Act liability and suspension or debarment.Next Steps for Software ProducersAffected software producers, as well as resellers of software products, systems integrators, and other affected parties, are encouraged to submit comments on the draft Common Form, the information requested therein, and the feasibility of the attestation. DHS and CISA are particularly interested in comments regarding the practical utility of the proposed information collection: whether DHS accurately estimated the burden on the producers, and ways DHS might enhance the quality, utility, and clarity of the information collected. The practicality of the attestation’s application to open-source components of software products may be particularly ripe for comment.Once the Common Form is required, software producers should bear in mind that completion of the form is mandatory and that failure to provide any of the information requested may result in the inability to sell the software to the federal government. Further, providing false or misleading information may constitute a violation of the criminal False Statements Act or could result in a violation of the False Claims Act in connection with a sale.

Federal Government Provides Further Guidance and Draft Attestation Form for Software It Acquires

speidel_markus_blog_150x150.png

speidel_markus_common_640x280.jpg

speidel_markus_heroretina_2700x1160.jpg

speidel_markus_mobileretina_750x1040.jpg

speidel_markus_social_600x600.jpg

Associate

Markus Speidel is an associate in Morrison & Foerster’s Government Contracts & Public Procurement group, in Washington, D.C. Markus assists clients across a wide range of contract matters, including contract claims and disputes, bid protests, compliance counseling, and investigations.

Markus Gerhard Speidel

Markus Speidel

230502-gov-con-blog-graphic.jpg

Federal Government Provides Further Guidance and Draft Attestation Form for Software It Acquires

230502-gov-con-blog-graphic

The Cybersecurity and Infrastructure Security Agency (CISA) of the Department of Homeland Security (DHS) recently published a draft version of a Secure Software Development Attestation Common Form. 

Software companies that sell commercial software products to federal agencies soon must begin attesting to their compliance with guidance designed to enhance the security of the software supply chain. Under a new White House Office of Management and Budget (OMB) <a href="https://www.whitehouse.gov/wp-content/uploads/2022/09/M-22-18.pdf">memorandum</a> issued September 14, federal agencies must require software “producers” (i.e., the developers of software) to confirm their compliance with specific guidance created by the National Institutes of Standards and Technology (NIST). The OMB memorandum implements the software supply chain enhancements first suggested under Executive Order (EO) 14028, Improving the Nation’s Cybersecurity, on which we’ve previously <a href="https://govcon.mofo.com/topics/210601-executive-order-on-cybersecurity">commented</a>. For purposes of the memorandum, the term “software” includes firmware, operating systems, applications, and cloud-based software, as well as products that contain software. The new requirements apply to software developed after the memorandum’s effective date (more on this below), and to existing software if modified by major version changes. Once the policy is in full effect, federal agencies may only use software if the software producer has attested to compliance with the NIST guidance, subject to certain limited exceptions. The purpose of the new requirements is to protect federal information systems from cyberattacks by ensuring the integrity of software acquired by the government. The policy can be traced to the SolarWinds compromise that impacted multiple U.S. government systems and other similar security incidents.When do the new rules take effect?Under the scheme set forth in the OMB memorandum, agencies have 90 days (or until December 14) to inventory their existing software and 120 days (until January 14, 2023) to develop a process for communication with software vendors. Agencies must begin collecting attestation letters for “critical software”<a href="about:blank">[1]</a> within 270 days (by June 14, 2023) and for all other software within 365 days (by September 14, 2023). In other words, within the next year, any software company seeking to sell its products to the federal government will need to assess and come into compliance with the NIST guidance. Note, however, the memorandum does permit agencies to request extensions of the above deadlines. If past is prologue, the implementation timeline may well be expanded beyond a year.What is the relevant NIST guidance?The two publications collectively referred to as the “NIST Guidance” in the OMB memorandum are the <a href="https://csrc.nist.gov/Projects/ssdf">NIST Special Publication (SP) 800-218</a> – Secure Software Development Framework (SSDF) and the <a href="https://www.nist.gov/system/files/documents/2022/02/04/software-supply-chain-security-guidance-under-EO-14028-section-4e.pdf">NIST Software Supply Chain Security Guidance</a>.NIST SP 800-218 provides high-level guidance on how software producers can integrate security into the software development life cycle. The framework consists of four recommendations, each broken down into a series of more specific practices and more well defined tasks, followed by examples and references. The recommendations are:<ul><li>Prepare the organization, by ensuring that the people, processes, and technology are prepared to perform secure software development.</li><li>Protect the software, including all components from tampering and unauthorized access.</li><li>Produce well-secured software, with minimal security vulnerabilities in each release.</li><li>Respond to vulnerabilities, by identifying residual vulnerabilities and responding appropriately to address those vulnerabilities and prevent similar ones from occurring in the future.</li></ul>The publication takes the form of a chart, mapping out each recommendation, practice, and task. The executive summary clarifies that not all practices apply to every use case, and that organizations should adopt a risk-based approach to determine which practices are relevant, appropriate, and effective to mitigate the threats to their software development practices.The NIST Software Supply Chain Security Guidance provides additional direction, aimed primarily at agencies, to assist in integrating the SSDF into procurements. The guidance clarifies that although open-source software freely obtained by federal agencies falls outside the scope of the framework, open-source software that is bundled, integrated, or otherwise used as part of any third-party software purchased by agencies is covered by the SSDF. Additionally, the guidance applies to both on premises and cloud-hosted software. The guidance further recommends that agencies:<ul><li>Use the SSDF’s terminology and structure to organize communications about secure software development requirements.</li><li>Require attestation to cover secure software development practices performed as part of processes and procedures throughout the software life cycle.</li><li>Accept first-party attestation of conformity with SSDF practices unless a risk-based approach determines that second or third-party attestation is required.</li><li>Request high-level artifacts demonstrating conformance, when needed. </li></ul>How do I provide an attestation?The Department of Homeland Security’s Cybersecurity and Infrastructure Security Agency (CISA) has been directed to work with OMB to establish a “common form” suitable for use by multiple agencies. The form will provide a minimum level of assurance that the vendor followed NIST Guidance, and will include the software producer’s name, a description of the product or products the statement covers, and a statement attesting that the software producer followed NIST recommended secure development practices. Alternatively, a vendor may obtain a third-party assessment, provided by a certified FedRAMP Third-Party Assessor Organization (3PAO) or another assessor approved by the agency, in lieu of attestation. The OMB memorandum suggests that use of this process might be especially useful for open source software, or products incorporating open source software.Beyond the simple attestation form, agencies may also request artifacts in future solicitations, such as a complete Software Bill of Materials (SBOM), depending on the criticality of the software or the agency’s determination of need. To facilitate information sharing with the government, within the next two years CISA will establish a government-wide repository for software attestations and artifacts. As needed, CISA also will publish updated SBOM guidance for federal agencies.What if my software does not fully comply?In exceptional circumstances, and only for limited durations, agencies may seek a waiver of specific requirements from OMB, which will review the requests on a case-by-case basis. OMB will post specific instructions for submitting waiver or extension requests within 90 days.If a software producer cannot attest to its conformance with one or more practices from the NIST Guidance, the requesting agency shall require the software producer to identify those practices to which they cannot attest, to document measures in place to mitigate risks, and to develop a Plan of Action & Milestones (POA&M) to address remaining gaps. The POA&M and other documentation will not be posted publicly by either the vendor or the agency. If the software producer supplies this documentation and the agency finds the POA&M satisfactory, the agency may use the software despite the producer’s inability to provide a complete self-attestation.What if my company does not develop software, but uses third-party software in its products?The scope of the attestation requirement extends not just to stand alone software and cloud-based software-as-a-service offerings but also to other products that incorporate third-party software. Under the process as described, the attestation must come from the software “producer” itself. But companies that incorporate third-party software into their own products will have a vested interest in ensuring compliance by their essential software subcontractors, as the end products incorporating the software may not be sold to the government absent an attestation (or use of an alternative assessment methodology, or an agency waiver).ConclusionBy requiring software producers to attest to compliance with the NIST Guidance, the government aims to ensure that companies undertake a risk-based approach to secure software development, which ultimately will help ensure the overall security of federal information systems. Given the deadlines, all companies that sell (or want to sell) software to the government, whether directly or through resellers or other channels, should quickly assess their compliance with the NIST Guidance, develop action plans to address any gaps, and carefully document their activities. Some companies may be required to rethink development strategy for new products or major version upgrades. As with all recent government cybersecurity initiatives, dates may slip and the contours of the requirements may change around the edges, but the basic policy directive here is clear, and software producers that intend to keep the U.S. government as customers need to get on board. In addition, contractors whose products rely upon or incorporate software will need to ensure that the vendors upon which they are dependent are fully engaged in the attestation process.By implementing the policy through an attestation form rather than a contract clause, the government is making sure software producers are directly involved in the process, and are legally liable, under False Statements and False Claims Act authority, for any misrepresentations or misstatements. This was surely a deliberate decision to reinforce the seriousness of the issue and to help ensure more widespread compliance. As with any attestation or certification requirement, the new policy brings with it the potential for enforcement actions, whether initiated by the government or by False Claims Act qui tam relators. Software vendors therefore should pay particular attention to their compliance assessments and the representations that they make going forward.  <a href="about:blank">[1]</a> A <a href="https://whitehouse.gov/wp-content/uploads/2021/08/M-21-30.pdf" target="_blank">prior OMB memorandum</a> directed NIST to issue guidance of security measures for “critical software,” defined as any software that has, or has direct software dependencies upon, one of more components with at least one of these attributes:- is designed to run with elevated privilege or manage privileges; - has direct or privileged access to networking or computing resources; - is designed to control access to data or operational technology; - performs a function critical to trust; or - operates outside of normal trust boundaries with privileged access.

Companies Selling Software to the U.S. Government Soon Must Attest to Compliance with NIST Guidance on Software Supply Chain Security

Companies Selling Software to the U.S. Government Soon Must Attest to Compliance with NIST Guidance on Software Supply Chain Security

Software companies that sell commercial software products to federal agencies soon must begin attesting to their compliance with guidance designed to enhance the security of the software supply chain.

The Department of Justice (DOJ) has created a new <a rel="noopener" target="_blank" href="https://www.justice.gov/opa/pr/deputy-attorney-general-lisa-o-monaco-announces-new-civil-cyber-fraud-initiative">Civil Cyber-Fraud Initiative</a> to use the power of the False Claims Act (FCA) to initiate suits against federal contractors and grant recipients that fall short of their regulatory and contractual cybersecurity obligations. This initiative, announced on October 6, 2021, builds on the Biden administration’s efforts to protect federal government networks from cybersecurity threats and to promote notifications of incidents by federal contractors to their federal agency customers—efforts that were outlined in the President’s May 2021 <a rel="noopener" target="_blank" href="https://govcon.mofo.com/cybersecurity-and-data-privacy/executive-order-on-cybersecurity-expands-mandatory-breach-notification-and-supply-chain-security-requirements-for-government-contractors/">Executive Order on Improving the Nation’s Cybersecurity</a>.To learn more,<a rel="noopener" target="_blank" href="https://www.mofo.com/resources/insights/211012-doj-cyber-fraud-initiative.html"> read our client alert.</a>

DOJ Cyber-Fraud Initiative Highlights Potential Civil Liability for Failing to Meet Federal Cybersecurity Requirements

The Department of Justice (DOJ) has created a new Civil Cyber-Fraud Initiative to use the power of the False Claims Act (FCA) to initiate suits against federal 

This week, U.S. Senator Mark Warner (D-VA), chair of the Senate Intelligence Committee, and a broad group of bipartisan co-sponsors, introduced legislation that would require government agencies, contractors, and operators of critical infrastructure to report cyber incidents to the U.S. Cybersecurity and Infrastructure Security Agency (CISA) within 24 hours. The bill is a response to incidents like the SolarWinds and Colonial Pipeline hacks, which have put a fresh spotlight on the national security implications of cyber incidents and the need for greater information sharing. It expands on efforts by the Biden administration, such as the Executive Order on Improving the Nation’s Cybersecurity, to implement more expansive cyber breach notification requirements for entities that do business with the federal government. The bill, known as the Cyber Incident Notification Act of 2021, which has been previewed in the press for some time, has broad bipartisan and industry support and a strong chance of being enacted by Congress.Read the <a rel="noopener" target="_blank" href="https://www.mofo.com/resources/insights/210723-mandatory-cyber-breach-notification-bill.html">full client alert</a>.

11_23_li_tech3.jpg

U.S. Congress Introduces Bill that Would Require Mandatory 24 Hour Cyber Breach Notification for Government Agencies, Contractors, and Operators of Critical Infrastructure

U.S. Congress Introduces Bill that Would Require Mandatory 24 Hour Cyber Breach Notification for Government Agencies, Contractors, and Operators of Critical Infrastructure

11_23_li_tech3

This week, U.S. Senator Mark Warner (D-VA), chair of the Senate Intelligence Committee, and a broad group of bipartisan co-sponsors, introduced legislation that

On May 12, 2021, the Biden administration issued an ambitious Executive Order on Improving the Nation’s Cybersecurity (EO) declaring the prevention, detection, assessment, and remediation of cyber incidents to be a “top priority and essential to national and economic security.” Over 8,000 words long, the EO establishes a series of initiatives designed to better equip the U.S. federal government to respond to cybersecurity threats. The most notable provisions of the EO are as follows:<ul><li>It sets in motion changes to federal contracts that will add breach notification and information sharing requirements for government service providers and remove existing contractual barriers to threat information sharing by the private sector;</li><li>It establishes baseline security standards for the development of software sold to the government by all commercial suppliers; and</li><li>It provides minimum cybersecurity requirements for federal agencies, like the use of multifactor authentication and encryption, and helps to move the federal government toward secure cloud services and zero-trust architecture.</li></ul>The EO reflects the government’s heightened concerns about cyber threats, particularly following the SolarWinds, Microsoft Exchange, and Colonial Pipeline incidents. It also reflects the Administration’s efforts to leverage the buying power of the federal government to incentivize the software market to build security into the software development lifecycle, and to expand and enhance the information sharing between the private sector and the government.<h4>STATUS QUO</h4>Currently, federal contractors’ cyber incident reporting requirements are primarily based on a patchwork of agency-specific policies, regulations, and contract clauses. For example, the Defense Federal Acquisition Regulation Supplement (DFARS) requires reporting of incidents that affect “covered defense information,” while other agencies require reporting in the form of contract clauses or agency information security policies and only if agency-specific information or certain categories of information held by the agency (such as personally identifiable information or protected health information) have been compromised.The Federal Acquisition Regulation (FAR) has a basic safeguarding clause, FAR 52.204-21, that applies to nearly all federal contractor information systems. This clause currently stops short of requiring breach notification. Instead, it merely imposes basic safeguarding requirements and procedures amounting to good cybersecurity hygiene. By contrast, DFARS 252.204-7012, requires defense contractors to “rapidly report” – i.e., within 72 hours – any “cyber incident” following a review for evidence of compromise.In sum, many government contractors are already subject to security incident notification requirements, but they vary depending upon the agencies with which those companies contract, and the nature of the information traversing their information technology (IT) systems.<h4>THE EO’S CYBER INCIDENT REPORTING REQUIREMENTS</h4>The new EO seeks to expand existing cyber breach notification requirements by modifying contract terms to require all providers of IT and operational technology (OT) services to the federal government, including, but not limited to, cloud service providers, to share threat and security incident information with select executive departments and agencies responsible for investigation and remediation of cyber incidents. These include the Cybersecurity and Infrastructure Security Agency (CISA), the Federal Bureau of Investigation (FBI), and the other elements of the Intelligence Community (IC).To implement this process, the EO requires a review and update of the current FAR and DFARS contract requirements for IT and OT service providers. As revised, these clauses will be designed to ensure that covered contractors collect and preserve cyber incident and cyber threat-related information, and share such information with the designated government agencies. Moreover, the EO requires federal agencies to propose contract language to the FAR Council that would require information and communications technology service providers to report certain types of cyber incidents to federal agencies, and CISA in particular, within a prescribed period of time. Among the specifics requested by the White House are a maximum three days from detection reporting requirement for “the most severe cyber incidents.” The EO sets a rather aggressive timeline for the FAR Council to review and publish for public comment the proposed new regulations, which could mean that we will see proposed updates to the FAR before the end of the year.The EO also requires the removal of barriers that inhibit the sharing of threat information, such as contractors’ incident response data, within the federal government. The EO directs the Office of Management and Budget (OMB), in consultation with other agencies, to propose updates to contract language to ensure contracts do not contain obstacles to the sharing of threat and cyber incident information within government. Such sharing will improve prevention, detection, and response and also foster collaboration among agencies, the FBI and CISA in their investigations of cyber incidents.Finally, new standardized cybersecurity requirements for all government contractors may be considered and adopted by the FAR Council.Much work remains to be done before new clauses are implemented in federal contracts, but contractors are now on notice of a potential sea change on the horizon.<h4>OTHER POTENTIALLY SIGNIFICANT DEVELOPMENTS FOR GOVERNMENT CONTRACTORS</h4><h5>MODERNIZATION OF THE GOVERNMENT’S IT SYSTEMS AND OF THE FEDERAL RISK AND AUTHORIZATION MANAGEMENT PROGRAM (“FEDRAMP”)</h5>The EO calls for the modernization of the federal government’s approach to cybersecurity, including adoption of best practices like the use of multifactor authentication and encryption, movement towards zero-trust architecture, and acceleration of adoption of cloud service solutions. The EO requires agencies to take steps toward implementation of these goals. In addition, the EO establishes a framework for the modernization of FedRAMP, suggesting a potential revamping of the currently cumbersome FedRAMP authorization process used for vendors seeking permission to provide cloud service offerings to government customers. This modernization effort offers significant opportunities for software vendors and IT service providers to expand their reach within the government.<h5>ENHANCED SUPPLY CHAIN SECURITY</h5>The EO also seeks to enhance supply chain security, particularly for “critical software” that has or enables privileged or direct access to networking and computing resources. The EO directs the National Institute of Standards and Technology (NIST) to develop guidelines for software vendors and promulgate a list of secure software development lifecycle standards with which all commercial suppliers to the government must comply.Among the criteria to be examined and regulated will be: (1) the development environment, including examination of access controls and use of automated tools to maintain integrity; (2) the developers’ transparency regarding security data; and (3) the provenance of the software, including review of a software bill of materials (SBOM) for each product. There may also be procedures for agencies to request artifacts demonstrating product integrity and for software providers to participate in a vulnerability disclosure program.Only software that is compliant with these newly established rules will be eligible for federal procurement. Non-compliant software will be removed from all indefinite delivery, indefinite quantity contracts; federal supply schedules, federal government-wide acquisition contracts; blanket purchase agreements, and multiple award contracts. Legacy software must either meet the new requirements or be redesigned to do so.It is worth keeping in mind the broader context of these supply chain reforms as part of a coordinated response to recent high-profile attacks. U.S. intelligence agencies have already begun reviewing supply chain risks, especially those associated with Russian companies. Of particular concern are any back-end software designs and coding done in Russia or other untrustworthy countries with the capacity for sophisticated cyber intrusions. The EO thus requires the FAR Council to propose supply chain security requirements, to be applicable to all government contractors. Those products and services that do not meet the government’s requirements will not be able to be sold to federal agencies.<h4>OTHER CYBERSECURITY ENHANCEMENTS</h4>In addition to its requirements for enhanced information sharing and supply chain security, the EO advances several other measures aimed at bolstering federal cybersecurity coordination and standardizing responses to cyber incidents.These include:<ul><li>Establishment of a Cyber Safety Review Board to improve government remediation of significant cybersecurity incidents. The Board’s membership will be drawn from the Department of Defense and Justice, CISA, the National Security Agency (NSA), and the FBI, with representation from private sector cybersecurity and software suppliers as determined appropriate by the Department of Homeland Security.</li><li>Standardization of the federal cyber incident response playbook developed by CISA in conjunction with the OMB, agency chief information officers, the federal Chief Information Security Officer Council, the NSA, the Attorney General and the Director of National Intelligence, which will conform response processes across all federal agencies.</li><li>Development of government-wide federal/civilian Endpoint Detection and Response (EDR) approach to support CISA-managed cyber threat hunting, detection, and response.</li><li>Issuance of policy requirements for agency logging, log retention, log management, and centralization of top-level security operations within each agency to improve the government’s overall investigation and response capabilities.</li></ul><h4>IMPLICATIONS FOR GOVERNMENT CONTRACTORS</h4>Although the EO previews desired and forthcoming new requirements, full implementation of the new rules will take time. The EO simply puts contractors on notice of the government’s plan to adopt new heightened cybersecurity standards and reporting obligations that will be implemented in the near future. Because the responsible agencies, in conjunction with the FAR Council, must still work to implement the EO, contractors will have time to prepare to meet the new standards and the opportunity to comment on the proposed FAR regulations (a process that we will be monitoring closely).That being said, unlike the existing DFARS 252.204-7012 cyber incident notification requirements, the new requirements have the potential to directly affect nearly all government contractors. While the new requirements may simplify notification requirements for contractors by creating a federal government-wide standardized approach, companies that have not previously implemented rigorous cybersecurity measures and incident response protocols may find themselves unprepared for this new era of cybersecurity. The new rules will also force scrutiny of the development cycle and supply chain for software and service providers in a manner not previously seen. The stakes are high for IT companies with significant government sales, and the opportunities are potentially ripe for new contractors seeking to replace them.Markus Speidel, a Law Clerk in the Morrison & Foerster LLP Government Contracts + Public Procurement practice, contributed to this alert.

Executive Order on Cybersecurity Expands Mandatory Breach Notification and Supply Chain Security Requirements for Government Contractors

On May 12, 2021, the Biden administration issued an ambitious Executive Order on Improving the Nation’s Cybersecurity (EO) declaring the prevention, detection, 

Executive Order on Cybersecurity Expands Mandatory Breach Notification and Supply Chain Security Requirements for Government Contractors