A recent GAO decision denying a contractor’s protest because of cybersecurity concerns offers contractors four lessons on how to avoid making the same mistakes.

I.  Background Facts and Decision

Syneren Technologies Corporation was one of 20 contractors who responded to a Navy RFP to award an ID/IQ contract for IT systems and software to support human resource operations involving a variety of business enterprise services. The work was to be performed at a government facility and involved DoD and Navy information, including personally indentifiable information (“PII”). Not surprisingly, the RFP required compliance with various DoD and Navy cybersecurity policies, specifically various software accreditation requirements.

For the net recruiting placement and alignment (“NetRPA”) development and modernization task, Syneren proposed using a particular software that was not accredited for use at the Navy datacenter and failed to provide any meaningful explanation as to how the software would be accredited. The decision suggests that Syneren did not know whether the software even met the solicitation’s cybersecurity requirements when it submitted its proposal.

The Navy rejected Syneren’s proposal with several weaknesses and a deficiency for Syneren’s proposed use of unaccredited software. Syneren protested the decision, arguing, in part, that the solicitation did not require it to address the accreditation process prior to award or explain how it would attain accreditation. The GAO rejected Syneren’s arguments and upheld the Navy’s decision. (In re: Syneren Tech. Corp.)

II.  Lessons for Contractors Proposing IT and Software Solutions to the Government

Here are four lessons for contractors based on this decision.

Lesson 1: Expect heightened cybersecurity scrutiny if the solicitation applies to DoD systems or PII of armed services members. 

The pain from the 2014 U.S. Office of Personnel Management (“OPM”) data breach remains. At that time, attackers exfiltrated personnel files of 4.2 million former and current government employees and the security clearance background files of 21.5 million individuals, including the fingerprint data of 5.6 million of these individuals. (See The OPM Data Breach Report.) In this decision, the Navy argued that “rigorous cybersecurity requirements are applied to DoD and … Navy systems … because of their potential impact on national security … [especially] when personally identifiable information (PII) data is present.” If the solicitation touches on these areas, expect heightened scrutiny.

Lesson 2: If possible, propose IT systems and software that meet the DoD cybersecurity requirements.

While your team may have invented a new IT system or software that can easily answer the government’s needs, it won’t mean much if it can’t pass the government’s rigorous cybersecurity requirements. Like privacy by design, security by design suggests that cybersecurity should be incorporated into your solutions from the beginning of the design process. If you do this, you may have a better understanding of whether your solution meets the particular cybersecurity requirements at the time of solicitation and you may more easily identify any potential cybersecurity gaps that you might be able to address to meet the solicitation’s requirements.

Lesson 3: If you propose software that does not meet with the solicitation’s cybersecurity requirements, explain in a meaningful way how compliance will be achieved.

The solicitation in the Syneren case stated that proposals must contain all pertinent information in sufficient detail so that government evaluators are able to meaningfully evaluate the offeror’s proposal and must demonstrate that the offeror has valid and practical solutions for all requirements. If you know your proposed solution does not meet the solicitation’s cybersecurity requirements, you should explain in detail how compliance will be achieved or why a particular cybersecurity compliance requirement is not applicable.

Lesson 4: If you propose software that is undergoing accreditation to meet the solicitation’s cybersecurity requirements, provide a meaningful explanation of the time and cost associated with achieving compliance.

The Navy took issue with Syneren’s proposal because it not only failed to comply with the solicitation’s cybersecurity requirements, but it also failed to reflect an adequate understanding of both the time and cost associated with achieving compliance. The Navy explained that accreditation of Syneren’s proposed software could take as long as 24 months. The last thing a purchasing agency wants is a surprise, and a proposed solution that may not be fully available for two years is a big surprise.