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

Our government contracts and procurement attorneys counsel businesses on legal and compliance issues encountered when doing business with government entities.

Government Contracts + Public Procurement

Government Contracts and Procurement Attorneys

Band 1: National: Government Contracts

Tier 1: Government Contracts

Readers Choice Award: Government Contracting

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.

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

Marking Commercial Technical Data After Flight Safety

Is Change Around the Corner? One Proposal to Forge Sweeping Changes to Defense Contracting

FAR Reform Now Underway

Deregulating Federal Procurement: Implications of Three Recent Executive Actions

Kickstarting AI in the Federal Government: OMB’s Policy to Implement Executive Order 14179

LinkedIN

FedRAMP Director Pete Waterman recently unveiled the “FedRAMP 20x” plan – a proposal designed to reimagine and reformulate the FedRAMP authorization process for federal government use of cloud-based products and services. Engagement with stakeholders is a key part of the initiative, as is reducing bureaucratic reviews of formulaic spreadsheets in favor of a more streamlined and dynamic authorization process.The Federal Risk and Authorization Management Program, or FedRAMP, is a process used by the federal government to ensure that cloud service offerings meet certain cybersecurity requirements before agencies can use them. FedRAMP modernization has been in process for a while, as discussed in our <a href="https://www.mofo.com/resources/insights/240812-fedramp-to-the-future" target="_blank">article</a> from late last year.The current re-envisioning appears to have coincided with the start of the Trump administration, and come into more concrete focus in the past few weeks.Key features of the plan include the following:Status quo for the immediate term. The current FedRAMP “Rev 5” agency authorization process (described in detail <a href="https://www.fedramp.gov/rev5/agency-authorization/" target="_blank">on this webpage</a>) will remain in effect. As stated on the newly updated <a href="https://www.fedramp.gov/" target="_blank">FedRAMP.gov</a> website: “The traditional FedRAMP Agency Authorization process is the only path to FedRAMP authorization today and it’s not going away any time soon!” Waterman estimates that the current agency authorization backlog of products in the queue awaiting authorization can cleared by the end of April. The authorization process will remain the only active path to FedRAMP authorization until a new process is officially developed and launched. Agencies and the FedRAMP program management office (PMO) will continue processing new authorization requests going forward until further notice.Stakeholder engagement as a driver of change. The FedRAMP PMO is coordinating internally with its agency partners and plans to engage with industry stakeholders through what it has called “FedRAMP 20X Community Working Groups.” The schedule for these public working group sessions, as well as additional details about how to participate and how the process will work, are available <a href="https://www.fedramp.gov/20x/working-groups/" target="_blank">online</a>. The goal of these working groups is for industry to help develop a modernized authorization process that is less complicated and bureaucratic and that incorporates continuous developments and commercial improvements. As envisioned, government and industry will collaborate to transform the process together. FedRAMP then will set standards that enable private industry to create solutions.Movement toward automated processes. One goal of the FedRAMP revisions is to use automation to expedite the authorization process. Manual compliance checklists against standard security baselines will be replaced with automated security validation of key security indicators. Examples of key indicators to be validated include:<ul><li>Federal information is encrypted when stored and transmitted.</li><li>Phishing-resistant multi-factor authentication is required.</li><li>Zero trust architecture is in place.</li><li>High-risk events are logged and audited.</li></ul>Expedited review for low impact offerings. Companies seeking FedRAMP Low authorization might expect to speed through that process in a matter of weeks. In Waterman’s presentation he contrasted the prior “Two years and $500k to get FedRAMP Low” with the anticipated “Two weeks and $5k to get FedRAMP Low.”Opportunities for Infrastructure as a Service (IaaS) and Platform as a Service (PaaS) offerings to host other companies’ cloud services. IaaS and PaaS platforms with current FedRAMP authorizations can leverage their services to allow other companies to deploy their offerings on these trusted platforms, and provide ways to validate the security of the new offerings, so they can be authorized quickly. This structure would be most useful for simple offerings with minimal third-party integrations and services provided online only.ConclusionThe FedRAMP PMO’s efforts to move to a common sense authorization process could have huge benefits for industry and federal agencies alike. A novel approach to FedRAMP could result in hundreds of new approvals a year, providing agencies with expedited access to the latest and greatest technology. Reduction of authorization-associated costs and elimination of barriers, such as the requirement for an agency sponsor, would also be expected to dramatically increase cloud service providers’ interest in the pursuit of FedRAMP authorization. Although the devil will be in the details, and maintaining the security of federal government data and information should remain a paramount concern, FedRAMP 20x has the makings of a rare win-win for government and the tech community.

FedRAMP 20x: Reformulating 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

230502-gov-con-blog-graphic.jpg

FedRAMP 20x: Reformulating the Authorization Process

230502-gov-con-blog-graphic

The Federal Acquisition Regulation (FAR) Council issued its long awaited <a href="https://www.federalregister.gov/documents/2025/01/15/2024-30437/federal-acquisition-regulation-controlled-unclassified-information" target="_blank">proposed rule</a> on Controlled Unclassified Information (CUI) on January 15, 2025. The proposed rule establishes a common form to be used by all federal agencies at the contract formation stage to identify contract‑related CUI, prescribes requirements for contractor protection of CUI, and creates a formal reporting process for security incidents involving CUI. Below, we examine these and several other noteworthy aspects of the proposed rule and their implications for contractors.Historical ContextAs defined in the proposed FAR rule, CUI is “information that the Government creates or possesses, or that an entity creates or possess for or on behalf of the Government, that a law, regulation, or Governmentwide policy requires or permits an agency to handle using safeguarding or dissemination controls.” This is consistent with the statutory definition of CUI established by the National Archives and Records Administration (NARA), which defines CUI as “[a]ll unclassified information throughout the executive branch that requires any safeguarding or dissemination control.” 32 C.F.R. § 2002.The federal government has long recognized the need to protect sensitive but unclassified information. In 2010, President Obama issued <a href="https://obamawhitehouse.archives.gov/the-press-office/2010/11/04/executive-order-13556-controlled-unclassified-information" target="_blank">Executive Order 13556</a>, establishing the CUI Program and designating NARA as its executive agent. In September 2016, NARA published a <a href="https://www.federalregister.gov/documents/2016/09/14/2016-21665/controlled-unclassified-information" target="_blank">final rule</a> codifying uniform policies for marking, safeguarding, disseminating, and disposing CUI. The FAR Council then opened FAR Case 2017-016 to develop parallel acquisition regulations and contractor clauses. It has taken until now, however, to issue the proposed regulations. In the interim, the Department of Defense (DoD) established its own CUI protection requirements in the form of <a href="https://www.acquisition.gov/dfars/252.204-7012-safeguarding-covered-defense-information-and-cyber-incident-reporting." target="_blank">DFARS 252.204-7012, Safeguarding Covered Defense Information and Cyber Incident Reporting</a>. Other agencies have also issued CUI regulations or created special clauses for use in select contracts. This inconsistent and uneven approach to CUI handling has created confusion and compliance uncertainty among the contractor community, which must protect sensitive information from potential security vulnerabilities. The proposed regulation seeks to remedy this situation by standardizing the federal government’s approach to CUI.The Proposed Rule’s Framework for Identifying and Handling CUIThe proposed rule applies broadly to nearly all federal contracts, including those for commercial products and services, except those solely for the sale of commercial off-the-shelf products. We have classified these major changes into the following categories: (1) identifying requirements (in the standard form); (2) safeguarding requirements; (3) incident reporting; and (4) additional notable provisions and next steps.Identification of Requirements: Understanding Standard Form XXXAt the heart of the proposed rule is Standard Form XXX (SF XXX), which will inform contractors of their CUI protection obligations from the outset of the procurement process. The form will be included in all solicitations and contracts that may involve CUI, and contractors must prepare their own SF XXX, tailored from the prime contract version, when flowing down CUI requirements to applicable subcontractors.Each SF XXX will identify what information under the contract is considered CUI and establish any contract-specific compliance requirements. For each contract, the form will specify all required privacy measures, security controls, and agency-specific security measures—dependent on whether federal or non-federal information systems will process the CUI. The form will also identify who can access CUI and under what conditions, personnel training requirements, and incident reporting procedures.Notably, even if there is no CUI identified, new FAR clause 52.204-YY, Identifying and Reporting Information That Is Potentially Controlled Unclassified Information, must be incorporated into solicitations and contracts. The clause applies when the SF XXX indicates that no CUI will be involved in contract performance. The clause requires contractors to notify the relevant contracting officer within 8 hours if potential CUI is discovered but that CUI is not listed on an SF XXX or not properly marked.In addition, the proposed rule places an obligation on contractors to mark as CUI proposal information, proprietary business information, and certain other types of information in proposal submissions and other CUI that it creates in performance of the contract.Safeguarding RequirementsThe proposed rule establishes comprehensive requirements for safeguarding CUI, introducing new obligations for contractors of civilian agencies that are similar to, but not the same as, the existing DoD requirements under DFARS clause 252.204-7012.<a href="#_ftn1" target="_self">[1] </a>Applicable safeguarding requirements vary based on whether contractors handle CUI on federal or contractor systems, the type of CUI involved, and whether the contract involves critical programs.For CUI on federal information systems, contractors must implement NIST SP 800-53 security controls and meet any additional CUI requirements listed in SF XXX. If cloud services are used, they must, at minimum, comply with FedRAMP Moderate baseline standards.For CUI on non-federal information (i.e., contractor or subcontractor) systems, contractors must implement NIST SP 800-171 Revision 2 security controls and follow any additional requirements specified in Form SF XXX for higher security levels.<a href="#_ftn2" target="_self">[2]</a> To demonstrate compliance, contractors must maintain system security plans documenting their implementation of NIST SP 800-171 controls and submit these plans to their government customers upon request. Contractors can only use cloud-based products and services for performance of contracts involving CUI that meet FedRAMP Moderate baseline standards. They must also allow government validation of security measures, according to NIST SP 800-171A standards. For certain critical programs, contractors may need to implement enhanced security requirements from NIST SP 800-172.<a href="#_ftn3" target="_self">[3]</a>As noted above, additional safeguarding and handling requirements beyond these baseline standards may be required and reflected in solicitations and contracts in the form of agency- and contract-specific security requirements.The proposed rule also requires annual CUI training for contractor employees and states that no contractor employee may handle CUI without first completing the required training and meeting any additional prerequisites for access. Contractors must maintain training documentation and provide it upon request to the contracting officer. These requirements flow down to subcontractors that will handle CUI.Incident Reporting RequirementsFor non-federal facilities and systems, the proposed rule establishes an 8-hour reporting requirement for suspected or confirmed “CUI incidents,” defined very broadly as “improper access, use, disclosure, modification, or destruction of CUI, in any form or medium.” Contractors must report to the agency website or point of contact identified in SF XXX.When a CUI incident occurs, contractors must determine what CUI was or could have been improperly accessed, construct a timeline of user activity, and assess the methods used to access the CUI. For incidents involving information systems, contractors must preserve and protect images of all affected systems and relevant monitoring data for 90 days after submitting the CUI incident report, unless the government declines interest or requests the data and media sooner.The reporting requirements apply to subcontractors at any tier that have access to CUI as well. Subcontractors must notify their prime contractor or next-higher-tier subcontractor within 8 hours of discovery of a suspected or confirmed CUI incident.<a href="#_ftn4" target="_self">[4]</a>Cloud service providers with FedRAMP authorization must follow FedRAMP-specific reporting requirements in addition to those set forth in the proposed contract clauses.Incidents occurring at federal facilities must be reported in accordance with applicable agency procedures.Importantly, the incident reporting rule specifies that, while the mere fact of a report does not create liability, “[i]f the Contractor is determined to be at fault for a CUI incident (e.g., not safeguarding CUI in accordance with the contract requirements), the Contractor may be financially liable for Government costs incurred in the course of the response and mitigation efforts in addition to any other damages at law or remedies available to the Government for noncompliance.” This provision is part of a continuing trend of the government seeking to hold contractors to account for failure to meet security and cybersecurity obligations.  Additional Notable Provisions and Next StepsIn addition to the changes described above, the proposed rule does away with the previously used term “federal contract information” (FCI) and replaces it with a revised definition of “covered Federal information” that clarifies that this category does not include CUI or classified information. As with FCI previously, “covered Federal information” is subject to the protections of the updated FAR 52.204-21, Basic Safeguarding of Covered Contractor Information Systems.In a helpful clarification for contractors, the new definition of CUI specifically excludes information that the contractor possesses or has on its systems that was not created for and/or is not possessed on behalf of, a federal agency. In the past, many contractors questioned how and whether CUI markings apply to their own internal information. This provision makes clear that contractors have no obligation to mark or protect internal information that, in other contexts, might be CUI.Interestingly, the procedure for completion of the SF XXX form specifies that it is the agency “requiring activity,” not the contracting officer, that is required to identify CUI and applicable requirements. It remains to be seen what guidance and training will be provided across government to prevent over-identification—a common issue currently—and encourage consistency across agencies.Also, although CUI can be identified later in the contracting process via modification, the proposed rule leaves open the possibility of a contractor request for equitable adjustment to account for newly added requirements that increase contract compliance costs.The proposed changes formally integrate CUI protection requirements into the federal procurement process and transform the previously piecemeal approach to CUI into a cohesive framework. Nonetheless, the devil is in the details, and contractors are sure to have thoughts about the proposed rule. The FAR Council has even asked interested parties to weigh in on specific questions, including how they believe they will handle competing incident reporting timelines across the federal government and how these additional requirements might impact pricing. Comments should be submitted to the Regulatory Secretariat Division on or before March 17, 2025, to be considered for the final rule.President Trump’s <a href="https://www.whitehouse.gov/presidential-actions/2025/01/regulatory-freeze-pending-review/" target="_blank">regulatory freeze</a>, announced on January 20, 2025, does not impede the FAR Council’s ability to solicit and review comments from industry on the proposed rule, but it does preclude the FAR Council from promulgating a final rule at least until approved by the cognizant appointees of the new administration.<a href="#_ftnref1" target="_self">[1]</a> It remains to be seen how (or whether) DoD will harmonize the differences between the DFARS and this proposed rule.<a href="#_ftnref2" target="_self">[2]</a> The rule notes that the current NIST SP 800-171 version, Rev. 3, is available, but purposefully declines to apply it until further study. However, the FAR Council adds that it anticipates future rulemaking to update to Rev. 3 or future versions of the NIST special publication.<a href="#_ftnref3" target="_self">[3]</a>These enhanced requirements are expected to only apply to a limited subset of contractors; FAR estimates that 160 contractors would be affected.<a href="#_ftnref4" target="_self">[4]</a> This is a notable deviation from the DFARS 252.204-7012 incident reporting process, which requires subcontractors to report directly to the government. The revised process puts the burden on prime contractors to further report subcontractor incidents.

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

iko_roke_blog_150x150.png

iko_roke_common_640x280.jpg

iko_roke_heroretina_2700x1160.jpg

iko_roke_mobileretina_750x1040.jpg

iko_roke_social_600x600.jpg

Associate

Roke Iko is an associate in the Litigation Department in Morrison & Foerster’s Washington, D.C. office.
Roke assists clients in the full range of government contracts litigation and compliance matters

Roke Iko

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

protests-and-litigation-600-300x148

Proposed Regulation on Controlled Unclassified Information Standardizes Process for CUI Identification and Handling Across Federal Agencies

Citing the threats posed by foreign adversaries and criminal organizations, and seeking enhanced accountability for companies that provide software and cloud services to the federal government, the Biden administration released a new, sweeping Executive Order (“E.O.”) on cybersecurity last week. With mere days left in office, President Biden signed the “<a href="https://www.federalregister.gov/documents/2025/01/17/2025-01470/strengthening-and-promoting-innovation-in-the-nations-cybersecurity" target="_blank">Executive Order on Strengthening and Promoting Innovation in the Nation’s Cybersecurity</a>” on January 16, 2025. The new E.O., No. 14144, is something of a bookend to Biden’s 2021 cybersecurity order with a very similar name, <a href="https://www.federalregister.gov/documents/2021/05/17/2021-10460/improving-the-nations-cybersecurity" target="_blank">E.O. 14028</a>, with the new E.O. reflecting more ambitious goals and more onerous requirements for government contractors, software developers, and cloud service providers (“CSPs”). In a bit of good news for the technology industry, the E.O. encourages federal agencies to expand acceptance of digital identification, and to deploy commercial artificial intelligence (“AI”), end point detection, encryption, and other tools for use in cyber defense activities.Below we highlight the major provisions of the E.O. of relevance to software producers and CSPs whose products and services are sold to federal agencies. Although the E.O. came at the tail end of the previous administration, the Trump administration is not likely to materially reject the proposed changes.Efforts To Strengthen Software Supply Chain SecuritySoftware Attestation and ArtifactsBeginning in 2024, software developers have been required to complete a <a href="https://www.cisa.gov/secure-software-attestation-form" target="_blank">secure software development attestation form</a> in order to sell (or have others resell) their software products to the federal government. The E.O. builds on this requirement, and suggests a number of additional requirements to ensure that software providers continue to adopt secure software acquisition and development practices, so as to reduce vulnerabilities and threats to government systems and information. The E.O. suggests that although software providers make commitments to security as part of their contracts and attestations, they “do not fix well-known exploitable vulnerabilities. . .which puts the Government at risk of compromise.”Among the proposed changes to ensure that software developers are following required practices is an expansion of secure software development attestation requirements, to add the obligation that software producers provide accompanying high-level validation artifacts along with their machine-readable attestations, and also a list of federal government customers. The list of customers is to include all civilian agencies that use the software product, but not Department of Defense (“DoD”) or intelligence agency customers. All of this information is to be provided to the Cybersecurity and Infrastructure Security Agency (“CISA”) via its centralized Repository for Software Attestation and Artifacts (“RSAA”). (We have previously noted that creation of such a centralized repository creates security challenges of its own as the repository would be an obvious target for bad actors and foreign adversaries.)In addition, the E.O. recommends that CISA develop a review and audit process to verify the completeness and accuracy of all attestations submitted to the RSAA and that the agency regularly validate a sample of completed attestations. The National Cyber Director is to publicly post the validation results and encouraged to refer any attestations that fail validation to the Attorney General and contracting agencies for appropriate action. (This is yet another example of continued government efforts to use the threat of False Claims Act liability to hold software developers to account.)These requirements are not self-executing. Rather, the Federal Acquisition Regulatory Council (“FAR Council”) must first develop and adopt contract language implementing these changes. Interestingly, for the requirement for artifacts and lists of customers, the E.O. suggests rapid action on the part of the FAR Council (within 120 days) and issuance of an interim final rule to amend the FAR versus undergoing the full proposed rule notice and comment period. It remains to be seen whether the Trump administration views this and other proposed changes with the same level of urgency.Other Secure Software Acquisition PracticesThe E.O. directs CISA to update the common software development attestation form based on yet-to-be-provided guidance from the National Institute of Standards and Technology (“NIST”) in select areas. For its part, NIST is asked to provide direction to software producers on deploying patches and updates securely and reliably, through a revision to NIST Special Publication 800-53, “Security and Privacy Controls for Information Systems and Organizations.” NIST also is tasked with developing “practices, procedures, controls, and implementation examples” of secure and reliable development and delivery through an update to NIST Special Publication 800-218, “Secure Software Development Framework.” In a tortured regulatory process, the Office of Management and Budget (“OMB”) will incorporate select practices from the two revised NIST publications into a revised version of OMB Memorandum M-22-18, “Enhancing the Security of the Software Supply Chain through Secure Software Development Practices.” CISA will conform the common software attestation form to the revised OMB Memorandum.The E.O. also suggests means for agencies to integrate cybersecurity into the acquisition life cycle, by taking cybersecurity into account in acquisition planning, source selection, responsibility determinations, security compliance evaluations, contract administration, and evaluations of contractor performance. In other words, cybersecurity should become a significant consideration in all procurements and in assessing contractor past performance.Other recommendations seek guidance from CISA and OMB to agencies on the use of security assessments and patching of open-source software, and best practices for contributing to open-source software projects.Minimum Cybersecurity Practices for All Federal ContractorsRecognizing that managing cybersecurity risks is now a necessary part of everyday industry practice for all companies, regardless of the product or service they sell, the E.O. directs NIST to provide guidance on common industry cybersecurity practices and security controls within 240 days of the E.O. Based on the resulting NIST guidance, the FAR Council is tasked with amending the FAR to require: (i) that all contractors follow minimum cybersecurity practices, and (ii) that vendors of internet-of-things products (wireless interconnected smart products) sold to the federal government carry <a href="https://www.fcc.gov/CyberTrustMark" target="_blank">United States Cyber Trust Mark</a> labeling. To date, such labeling has been entirely voluntary, so this reflects a new requirement for applicable contractors. The new recommended security practices are likely to go beyond the current 15 minimum security requirements found in <a href="https://www.ecfr.gov/current/title-48/chapter-1/subchapter-H/part-52/subpart-52.2/section-52.204-21" target="_blank">FAR 52.204-21</a>, “Basic Safeguarding of Covered Contractor Information Systems,” which apply to nearly all government contractors and subcontractors.New Obligations for Providers of FedRAMP-Authorized Products and ServicesRecognizing that private industry may be best positioned to advise on measures to ensure the security of government information, and that such information is often in the hands of CSPs, the E.O. directs the head of the Federal Risk and Authorization Management Program (“FedRAMP”), which authorizes cloud products for use by the government, to develop policies and practices that incentivize or require FedRAMP CSPs “to produce baselines with specifications and recommendations for agency configuration of agency cloud-based systems.” In addition, the E.O proposes that FedRAMP security requirements be updated to incorporate guidelines for the secure management of access tokens and cryptographic keys. Providers of FedRAMP-authorized solutions will need to address these new requirements to maintain their authorizations, and companies seeking authorization in the future will also need to take additional requirements into account in assessing the security postures of their products and services.Opportunities for the Tech IndustrySeveral sections of the E.O. emphasize that the federal government must adopt proven commercial practices and products to fortify government networks. The government cannot do this without purchasing and implementing commercial solutions in areas of AI, endpoint detection and response, credentialing, phishing-resistance, threat hunting, muti-factor authentication, among others. In particular, the E.O. calls out needed improvements with respect to civil space systems and federal communications networks (including internet routing, email, voice, and video conferencing).With respect to AI, the E.O. calls for the development of pilot programs to use advanced AI models for cyber defense and for the sharing of government data sets with the academic community to advance AI cyber defense research.The E.O. encourages expanded use of digital identification documents, including mobile driver’s licenses. It suggests that such documents be accepted as proof of identification for federal benefits programs, and proposes that agencies consider awarding grants to states to assist in the more rapid adoption of such technologies.In sum, the E.O. as envisioned presents opportunities for future sales of commercial cybersecurity products and services to government agencies. Technology companies should think strategically about how they can best position their products to be the options of choice throughout the federal government.Miscellaneous Provisions of NoteSection 8 of the E.O. focuses on specific concerns that relate to “national security systems” and “debilitating impact systems,” as designated by the DoD and intelligence community. These may present additional opportunities for contractors.Another section of the E.O. suggests that NIST, CISA, and OMB work together to establish a pilot program of a “rules-as-code approach” for machine-readable versions of policy and guidance that OMB, NIST, and CISA publish and manage regarding cybersecurity. “Rules-as-code approach” is defined as “a coded version of rules (for example, those contained in legislation, regulation, or policy) that can be understood and used by a computer.” This is an intriguing concept that could ease regulatory compliance for agencies and contractors.The final section of the E.O. expands on a 2015 Obama E.O. that allows for the seizure of assets of persons engaging in malicious cyber-enabled activities. The expansion covers persons operating outside the United States who use technology to create “a threat to the national security, foreign policy, or economic health of financial stability of the United States.” A long list of examples of prohibited activities falling within this prescription follows.Key TakeawaysAs noted above, it is not clear whether all of the recommendations and policy changes proposed in this E.O. will be implemented by the Trump administration. This E.O. is not among those President Trump <a href="https://www.whitehouse.gov/presidential-actions/2025/01/initial-rescissions-of-harmful-executive-orders-and-actions/" target="_blank">rescinded</a> on day one. Sources have reported that the transition team was consulted as the E.O. was finalized. It is also noteworthy that in recent days the FAR Council has announced that certain proposed regulations likely to be reversed by the Trump administration have been abandoned, including those relating to <a href="https://www.mofo.com/resources/insights/250116-proposed-greenhouse-gas-far-clause" target="_blank">greenhouse gas emissions reporting</a> and pay equity for government contractors. Altogether this suggests that the E.O. has at least some support going forward.In any event, the E.O. is not enforceable on its own, and various agencies and the FAR Council will need to further develop and implement its recommendations.  A temporary freeze on new regulatory activity will further delay this effort. The eventual rulemaking process may very well alter the final product, and there may not be a period of notice and comment for all suggested regulatory changes.As always in the ever-changing cybersecurity regulatory environment, companies that provide software and cloud services to the government must be vigilant in understanding the rules that apply and the potential exposure for failure to meet requirements.

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

12_30_cybersecurity_07.jpg

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

Biden’s Final Cybersecurity Order Proposes Significant Changes, All to Be Implemented by the Incoming Administration

On December 23, 2024, President Biden signed the Source Code Harmonization and Reuse in Information Technology Act (“SHARE IT Act” or “the Act”), which provides a formal mechanism for federal agencies to store and share custom-developed source code across the federal government by storing it in private or publicly accessible repositories. The Act applies to source code for noncommercial software that is developed exclusively with government funding, while commercial software and commercial off-the-shelf (COTS) software are expressly exempt from the Act’s requirements.Under the standard data rights clauses of the Federal Acquisition Regulation (FAR) and Department of Defense FAR Supplement (DFARS), the government generally obtains “unlimited rights” in noncommercial software first produced in the performance of a government contract (in the language of the FAR) or developed exclusively with government funds (in the language of the DFARS). These rights permit the government to use, reproduce, and disclose the software and related data freely, and permit others to do all of the same, including by distributing copies to the public and performing or displaying the software and data publicly (with a limited exception for copyrighted computer software). Notably, though, these unlimited rights are limited to usage rights, and do not include a right to delivery of software or any particular software code; those rights must be specified separately in the contract.The SHARE IT Act signals a policy shift toward maximizing the government’s benefit from its unlimited rights by directing agencies to take steps to secure delivery of unlimited rights source code and share that code across the federal government. As discussed above, the Act’s directive applies to source code produced in the performance of a contract with an agency or otherwise exclusively funded by the government. The Act expressly includes both source code for which the government “could obtain unlimited rights” and source code written for a software project, module, plugin, script, middleware, or application programming interface.To enable governmentwide access to source code, the SHARE IT Act requires agencies to store such source code in public repositories or private repositories accessible to authorized users within the government. If source code is stored in public repositories, the public will be free to access that source code. The SHARE IT Act leaves to the agencies the task of establishing guidance or criteria for determining when source code should be privately versus publicly stored. As public records, such source code may be subject to Freedom of Information Act (FOIA) requests, but the SHARE IT Act clarifies that it should not be construed as requiring disclosure of otherwise exempt information, and all standard exemptions to FOIA, including trade secrets and confidential commercial information, will still apply.The SHARE IT Act will not be implemented immediately; it applies to source code that is developed or revised under a contract awarded pursuant to a solicitation issued more than 180 days after enactment (i.e., on or after June 21, 2025), and FAR revisions necessary to implement the Act must be implemented within one year of the Act’s passage (i.e., by December 23, 2025, if timely). While the FAR Council begins developing new regulations pursuant to the SHARE IT Act, contractors should expect that any source code they develop specifically for government agencies in the future will be subject to the Act, and readily shared among agencies. Although this is currently the right of the government under the unlimited rights FAR and DFARS provisions, the implementation of a formal mechanism for exchange of source code all but guarantees significant and more widespread sharing within the federal government. Procurement strategies and negotiations should take this into account.Thomas Lee, an associate in our Washington, D.C. office, contributed to the writing of this article.

SHARE IT Act Requires Agencies to Share Custom-Developed Source Code Throughout the Government

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

lee_thomas_blog_150x150.png

lee_thomas_common_640x280.jpg

lee_thomas_heroretina_2700x1160.jpg

lee_thomas_mobileretina_750x1040.jpg

lee_thomas_social_600x600.jpg

Thomas Lee

230622-cybersecurity.jpg

SHARE IT Act Requires Agencies to Share Custom-Developed Source Code Throughout the Government

230622-cybersecurity

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.

FedRAMP to the Future

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

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

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