I. Introduction
Cybersecurity has become one of the most discussed issues facing the public and private sectors, as advancements in technology lead to more complex cyber threats facing both the government and businesses. Yet, even the biggest and most sophisticated companies can fail to properly defend themselves and the information that they are tasked with safeguarding. For example, Verizon Business Network Services LLC (Verizon), a component of one of the United States’ well-known cellphone service providers, found itself in a settlement agreement with the Department of Justice for violations of the False Claims Act. The settlement dealt with allegations that Verizon falsely certified that its methods of connecting federal agencies to public Internet or other external networks satisfied cybersecurity controls required by General Services Administration contracts. With these cybersecurity flaws in place, federal employees seeking to connect to public networks were at risk of having controlled information intercepted on these networks, placing sensitive government information in danger. Verizon learned of this failure and disclosed it, mitigating future incidents by acknowledging shortcomings, but was still required to pay $4,091,317 in a settlement with the Department of Justice.
It is impossible to describe the modern world without referencing some form of technology, with one of the most important inventions today being the Internet. With the amount of information currently being produced on the Internet daily, it is difficult, if not impossible, for a person to fully comprehend everything. Two zettabytes (two billion terabytes) of information existed in 2010, with that number expected to be at 181 zettabytes in 2025 as more devices are linked to the web and demand continues to grow following the impact of the COVID-19 pandemic. It therefore is not a bold statement to say that the Internet has become an integral part of not just our individual lives, but also how industries and the government function. Unfortunately, this reliance on technology has exposed new vectors for attacks, ranging from an individual to entire nation-states being able to slow down or compromise information technology (IT) systems. The Center for Strategic and International Studies (CSIS) has cataloged significant cyber incidents since 2006, focusing on major targets such as governments or events that cause over a million dollars in loss. Even with this reduced scope, CSIS identified over thirty incidents between January 2024 and July 2024. As populations become more technologically literate and the skills to engage in malicious activities become easier to acquire, governments need to remain wary of these attacks by increasing and promoting legislation or regulations to combat cybersecurity threats.
State and local governments also need to adapt to evolving technology, with issues being exacerbated by a lack of a centralized decision-maker even within a single state due to different agencies’ requirements. Government contractors must deal with fifty different states, the agencies within these governments, and countless local governments, which might all have different regulations that seek the same goal. Due to these varying standards, the different solutions used by governments lead to less effective security. To help deal with this fragmentation of standards in other sectors of government procurement, the American Bar Association (ABA) published the Model Procurement Code (MPC or Code) in 1979, with an amended version following in 2000. This new revision attempted to provide answers for the rise of technology in the procurement system and the challenges that came along with these developments.
One solution to dealing with fragmented cybersecurity standards is by using the MPC as a vehicle for these standards. The next MPC edition published by the ABA should tackle the issue of cybersecurity by providing state and local governments with a baseline for their own procurement systems. The foundation for these standards could come from the New York Department of Financial Services (NYDFS) cybersecurity regulations, which establishes minimum security standards while not being overly restrictive and, therefore, not falling behind when technology advances. While these regulations are designed around the financial industry, the general principles and solutions presented could be adapted to government procurement with little difficulty. In addition, the ABA could create a committee to regularly update any standards that are implemented due to the dynamic nature of cybersecurity, as waiting two decades between revisions would fail to utilize new developments in the field.
This Note, in Part II, will first go over the relevant background information about the MPC, select federal cybersecurity standards, and provide a brief overview of some methods that states currently use to handle cybersecurity and procurement. The impetus behind creating the MPC and the reasons for amending it in 2000 will be covered, along with its deficiencies in dealing with cybersecurity. Federal cybersecurity standards and current state implementations will be discussed to provide a reference point to contrast with the NYDFS regulations. Part III of this Note will go over the establishment of the NYDFS cybersecurity regulations, their amendments, and how each section operates. Three settlement agreements will be examined as examples of enforcement actions taken by the NYDFS and how the regulations apply in practice, with the importance of certain regulations highlighted in the agreements. Part IV will cover why these regulations should be used as a foundation for cybersecurity standards, specifically focusing on the universal coverage of the regulations and the benefits of standardizing such regulations. Part V will discuss how these standards could be adapted into the MPC.
II. Background
This section will first cover the basics of cybersecurity and the standards used at a federal level to provide context for how state and local governments set their own cybersecurity programs. Some of these programs will then be examined, with three main approaches (standards within a procurement code, establishment of a dedicated body to create standards, or delegation of procurement authority to an information technology department) to the issue highlighted. Lastly, this section will cover a brief history of the MPC and its revision in 2000, noting the lack of cybersecurity standards or guidance in the Code.
A. Federal Cyber Security Standards
While a broad and complex field, “[c]ybersecurity refers to the practice of protecting systems, networks, and programs from digital attacks.” These attacks can range from disrupting daily business procedures to extortion through ransomware by locking a user out from their files. Cybersecurity often intersects with other sections of law, such as data privacy, where computer security and procedures are impacted by the requirements in these laws. In defining what cybersecurity entails, a standard model known as the “CIA Triangle” or “CIA Triad” serves as the foundation for most frameworks in this field. The CIA Triad refers to the three pillars of cybersecurity: “Confidentiality, Integrity, and Availability.”
Confidentiality refers to the concept of “least privilege” in that information should be shared only on a “need-to-know basis” to prevent unnecessary access by individuals who are not required to utilize that information. “Least privilege” would entail each user or service on a network only having enough access to accomplish their jobs and utilizing procedures such as authorization or identification as supporting privacy controls. Integrity centers around ensuring that the information a person or system receives or tries to access has not been tampered with in transit or while in storage. One method of ensuring integrity is through the use of “one-way-hashes” that convert data into a unique “hash” (typically a fixed-string of characters) based on the data itself. This hash is sent along with the data, allowing the recipient to hash the data themselves and compare the results to ensure that the data received is the same as the data sent. Availability, the final component of the Triad ensures that the services of an organization are available for users to access, tying into both protection from digital attacks and physical incidents that can damage a server, such as an earthquake. In the digital world, one of the more common attacks on availability involves ransomware attacks that encrypt a user’s files unless a ransom is paid, with no guarantee of decryption actually occurring.
Federal cybersecurity programs and procedures center around the protection of “Controlled Unclassified Information” (CUI), which includes information that, while not being classified, requires protection and confidentiality. This program began in 2010 because of the patchwork system in place for protecting sensitive information by federal agencies, which had different classifications and procedures for handling information, leading to confusion when it came to dissemination. The CUI program today seeks to prevent unauthorized access to materials classified as CUI, incorporating the cybersecurity standards set out by the National Institute of Standards and Technology (NIST) for both federal and non-federal systems. NIST Special Publication (SP) 800-171 is the relevant publication for government contractors who are tasked with storing, processing, or transmitting said information CUI on their systems, while NIST SP 800-53 covers security and privacy controls for information systems more generally.
At first glance, it might seem prudent to adopt these NIST standards directly into the MPC, requiring contractors to comply with these standards as part of any solicitation requirements. While the standards do provide guidance on recommended security and privacy controls, they are just one example of a cybersecurity standard. The International Organization for Standardization in ISO/IEC 27001:2022 also sets out standards for information security and privacy protection, but like those from NIST, they are technical standards best used by the relevant security personnel. Instead, these standards should be used as acceptable options for contractors seeking to comply with cybersecurity requirements, establishing systems that either directly follow or are comparable to the NIST/ISO standards.
The Federal Acquisition Regulation (FAR) also covers a contractor’s obligations when handling “covered contractor information system[s],” referring to any information system that “processes, stores, or transmits Federal contract information.” This is enforced by another FAR clause that requires the contractor and any subcontractor to apply a list of basic safeguarding requirements to protect information, with any subcontractors involved also being subject to the same requirements. However, this clause does not relieve the contractor of any specific safeguarding requirements set out by the CUI program, meaning that the basic requirements within the contract may not be enough if certain types of information are being handled by the contractor. This model has been followed by some states for their own cybersecurity regimes, incorporating security requirements within state procurement codes.
Federal agencies can also have their own standards for cybersecurity. The Department of Defense’s (DoD) Cyber Maturity Model Certification (CMMC) program is one prominent example due to the frequency and complexity of attacks that defense contractors need to work with. Contractors are placed into one of three tiers that have their own standards and assessment needs depending on the nature of the information that the contractor will have to handle. The CMMC program is also currently under revision. The proposed changes seek to further enforce security requirements against contractors by verifying that the relevant standards and obligations are being followed.
The Government also utilizes a program known as the Federal Risk Assessment and Management Program (FedRAMP) in dealing with cybersecurity, specifically for cloud-based software services used by agencies. FedRAMP is managed by the General Services Administration (GSA), which authorizes products and services for agency use that handle unclassified information. A Cloud Service Offering (CSO) can be authorized by the GSA through the Joint Authorization Board (JAB), which is composed of the GSA, the DoD, and the Department of Homeland Security (DHS). Alternatively, a Cloud Service Provider (CSP) can be authorized directly through an agency to pursue an Authority to Operate. Both these approaches require authentication by an accredited Third Party Assessment Organization (3PAO) and are subject to continuous monitoring in order to ensure compliance with FedRAMP standards.
Federal standards have helped inform the decisions made by state and local governments when it comes to their own cybersecurity programs, with one example being the creation of an analogous entity to FedRAMP named the State Risk Assessment and Management Program (StateRAMP) with a similar mission of standardizing cybersecurity requirements—discussed in more detail in the next section. State and local governments have for at least a decade looked at federal priorities for cybersecurity, with increased federal attention leading to states prioritizing cybersecurity themselves.
B. Current State Practices
Given that there is no unifying standard among states or even their agencies, each state is free to adopt any policies and procedures they desire for dealing with cybersecurity when it comes to procurement. As a general classification, the main approaches that states have taken when tackling these issues are either to create standards within their procurement codes, establish a body within their administrative service departments to create standards, or delegate procurement responsibility to a dedicated IT department. StateRAMP also serves as a way to provide a similar service for states on a voluntary basis, like FedRAMP does for federal agencies.
Some states have chosen to deal with cybersecurity issues directly within their procurement codes by creating departments that deal with IT procurement or establish security standards. Connecticut has a dedicated Division of Information Technology within its Department of Administrative Services led by a Chief Information Officer (CIO). Through the CIO, the Commissioner of Administrative Services is responsible for identifying optimal IT systems for state agencies, approving proposed acquisitions of hardware or software, and several other responsibilities relating to IT procurement. In addition to creating the CIO position, another Connecticut statute creates obligations for contractors to safely handle “public record[s],” a term that includes any information that is created or used by a contractor in performance of their contract. Contractors are prohibited from disclosing public records if the state agency is also prohibited from sharing them according to either federal or state law. The statutes do not directly reference cybersecurity or establish technical standards, but set up a similar system to the CUI Program with protected information the government wants to safeguard.
Other states set out security standards that procuring departments follow. Maryland requires its Department of Information Technology to include “basic security requirements” in any contract that contemplates third-party access to state telecommunication infrastructure or services. These requirements themselves need to be consistent with a widely recognized security standard; the state cites NIST SP 800-171, ISO 27001, and the CMMC as examples of acceptable standards. Maryland has also established a program leveraging its purchasing power to ensure local governments are able to receive favorable rates for IT or cybersecurity services from contractors. Leveraging the state’s power to ensure that local governments can still provide adequate protection while not bankrupting themselves is important, considering the growing increase of technology in even municipal and county-level governments.
Illinois also deals with cybersecurity within its procurement code, setting out broad categories for what counts as a prohibited or authorized cybersecurity product. The statute prohibits state agencies from purchasing any products that federal agencies are prohibited from purchasing because of a U.S. Department of Homeland Security Binding Operational Directive. It also authorizes state agencies to purchase items from the authorized list run by the StateRAMP.
An alternative option for dealing with cybersecurity issues related to IT procurement has been to delegate some authority to a state’s IT Department or equivalent agency. This delegation can range from being responsible for the procurement itself or having the final say in whether a procurement can go through, with denial for failing to include basic security requirements being a possibility. Utah’s CIO is tasked with establishing a list of authorized vendors that can do business with government entities, limiting the procurement department from contracting with non-authorized companies. It also gives preference for solutions that comply with federal guidelines and frameworks like FedRAMP and NIST.
New Mexico has its Department of Information Technology run by a state secretary who acts as a CIO. As part of their office, the secretary is vested with several powers in dealing with IT procurement. While not directly responsible for procuring IT resources, the secretary is responsible for promulgating rules for oversight of IT procurement and ensuring that current resources are used efficiently in compliance with the Procurement Code. The secretary also has the responsibility of approving any requests subject to the Procurement Code before final approval, which gives them the ability to cancel procurements that may not meet minimum security standards.
States also have the opportunity to work with StateRAMP in an attempt to recognize some common standards for cybersecurity, with several states participating in the program in addition to some local governments. The program is managed by an eponymous non-profit organization with the goal of establishing a common standard for companies to become authorized to conduct business with governments to fulfill technological needs. StateRAMP operates similarly to FedRAMP in that a product needs to be authorized by a third-party (the 3PAO previously mentioned) and is subject to continuous monitoring for compliance with standards while on an Authorized Products List. The security standard used by StateRAMP is NIST SP 800-53 Rev. 5, which sets out standards for security and privacy controls for information systems and organizations.
This fragmentation of methods and standards is problematic both for ease-of-business by companies and for general security reasons. Businesses seeking to work on government contracts may need to tailor their cybersecurity systems to each specific jurisdiction, leading to the kind of procurement waste that the MPC sought to eliminate as competition is reduced. Security also remains an issue as small governments may lack the organizational experience required for such a complicated topic, and gaps between jurisdictions (or even agencies within jurisdictions) can be exploited by bad actors.
C. The Model Procurement Code
Responding to growing fragmentation in state procurement, the ABA’s MPC was first adopted on February 13, 1979, following years of work by several organizations, including the Public Contracts Section and State and Local Government Law Section of the ABA. In the 1970s, the demand for an MPC began to increase, and two main objectives were identified for any reform attempts: eliminating waste in procurement and eliminating corruption in procurement administration. The finalized Code sought to achieve these objectives by being a short and all-inclusive document that could be implemented and modified by longer regulations, should the need arise. It also was designed to elevate state and local procurement to a higher standard than prior procurement systems implemented in the states. Since 1979, sixteen states and thousands of local jurisdictions have fully adopted the MPC as the foundation of their procurement codes, and several other states have partially adopted the MPC.
First adopted in 1979, the MPC failed to keep up with developments that affected the procurement world. A revision of the Code began in 1997 and was adopted in 2000, with one of the goals being to adapt to technological changes in the procurement sphere. The need for governments to purchase things like computers, networks, and the software or hardware necessary to maintain them were driving forces for this change. This would be accomplished by encouraging “the competitive use of new technologies” in public procurement and reducing transaction costs across the field.
While the MPC does set these goals and acknowledges the need for reform when it comes to technology, it does not substantively tackle some of the issues that come with technology in government procurement. The most notable gap is a lack of standards relating to cybersecurity. Digital security measures, in general, are not even referenced within the code, lacking even vague guidelines for states to implement. The MPC tries to encourage the development of procurement related to technology, but, because it was reformed early in the digital age, the code still lags behind the realities of procurement today, with the issue only becoming worse due to the exponential growth of technology such as the Internet. It has been twenty-four years since the last time the MPC has been reformed, and it is clear that the code needs some level of reform to handle modern procurement issues.
III. The NYDFS Cybersecurity Regulations
The MPC can serve as a vehicle for cybersecurity reform, but, given the lack of its own standards, it still requires another source to pull from when it is updated. While every method above has its strengths and weaknesses, the NYDFS cybersecurity regulations establish adaptable and comprehensive standards and would be an ideal source for the MPC to draw on.
A. Purpose and Establishment of Regulations
The NYDFS Cybersecurity Regulations were first proposed in 2016 in response to the growing threat that cybercriminals posed to the financial system. Cybercriminals threatened to cause financial damage to department-regulated entities and their consumers, using private information for further illicit purposes. The finance industry, in particular, like the defense industry, was prime to be a significant target for cybersecurity threats given the nature of the information handled, requiring government attention. While the NYDFS noted that the private marketplace was already beginning to respond to these threats, certain minimum standards had to be established for regulated entities that could serve as a baseline for cybersecurity. The regulations were put in force on March 1, 2017, and enforcement of these security baselines began to occur for financial service companies operating in New York. In making these regulations, the goal of the NYDFS was to set a security floor for companies to follow, while at the same time not demanding extremely specific policies so that cybersecurity programs could adapt to new technology and the risks associated with its usage.
The NYDFS was well aware that the regulations first implemented in 2017 were not suited for the changes in the cybersecurity landscape. The Department noted that threat actors were becoming more sophisticated and prevalent, leading to cyberattacks becoming more common and effective as the barrier to entry for anyone attempting an attack was lowered. While it was becoming more expensive to deal with the damages caused by cyberattacks, organizations were also able to take preventative measures at a reasonable cost to manage cyber risk. In addition, because the regulations had been in effect for five years and given that the NYDFS had the opportunity to investigate cybersecurity incidents, NYDFS was now better equipped to see what organizations could do to mitigate risk effectively.
The amendments enacted in 2023 built upon the established regulations through several key changes in the regulatory scheme that considered business size, the nature of data being handled, and other factors in determining what security measures need to be implemented by businesses. These changes focused on things such as “[e]nhanced governance requirements; [a]dditional controls to prevent initial unauthorized access to information systems . . .; [r]equirements for more regular risk and vulnerability assessments,” and several reporting/notification requirements for security incidents. Part of these amended regulations includes more security requirements on a “Class A company,” which NYDFS defines as any financial institution with at least $20 million in gross annual revenue from operations in New York and either employing “over 2,000 [people] averaged over the last two fiscal years”; or earning “over [$1 billion] in gross annual revenue in each of the last two fiscal years.” One example of this heightened requirement is that, in addition to limiting access privileges for accounts that do not need to work with certain systems, Class A companies must either find an automated way to block commonly used passwords from their systems or have their Chief Information Security Officer (CISO) determine this is infeasible and find an alternative method to provide equal security. This emphasis on Class A companies requiring stronger levels of security is important given the large amount of money these companies are responsible for, with trillions held by financial and insurance institutions within New York. While some of these requirements might be more expensive to implement, Class A companies, as defined, are sophisticated institutions that can afford the cost given the level of damage that might occur if a company dealing with billions of dollars suffers a cybersecurity incident.
B. Overview of Certain Regulations
One of the key reasons for the success of these cybersecurity regulations has been certain prescriptive requirements and specific programs to be implemented, rather than the typical language of “reasonableness,” which leads to confusion and uncertainty about what programs need to be established. This begins with defining who is covered by the regulations in the financial industry, with the definition being simple but far-reaching. A “covered entity” for the purposes of the regulations refers to any person required to operate under a license, registration, or other authorization under Banking Law, Insurance Law, or Financial Services Law. Essentially, if an individual or company interacts in some way with the financial industry, they need to comply with, at minimum, the standards set out within the regulations. Class A companies must comply with additional requirements. While the definition of a covered entity is broad, the regulations do provide some exemptions for small businesses and entities that only occasionally participate in the New York market. However, despite subsection 500.19 labeled as “Exemptions,” this does not absolve exempted entities from all cybersecurity responsibilities. So, while a small business might not have to conduct penetration tests of their systems every year, they are still required to utilize multifactor authentication (MFA) for their systems. This requirement balances out the desire for strong cybersecurity systems with the practicality that small businesses are likely not in a position to conduct thorough penetration testing, but implementing MFA would still provide a degree of security without placing a major burden on them.
Once a company has been established as a covered entity for the purposes of the regulations, it is responsible for implementing a cybersecurity program to protect the “confidentiality, integrity, and availability of [its] information systems and nonpublic information stored on those information systems.” This requirement directly recalls the CIA Triad as the foundation of any cybersecurity program that a covered entity needs to implement, with the specifics further on in the regulations targeting at least one aspect of the Triad. The cybersecurity program has several core functions that it must accomplish to meet regulatory standards. These core functions include identifying internal and external risks to a covered entity’s system, utilizing defensive infrastructure and policies to protect the system, detecting cybersecurity events and responding to them, being able to recover from any event to resume normal operations, and fulfilling any reporting obligations imposed by regulations. Class A companies are obligated to design and independently audit their programs based on their risk assessment programs, and every covered entity is required to document their program to be made available should the government request it.
Every covered entity, whether a small business or a Class A company, is also required to conduct a risk assessment on its information systems to help design an effective cybersecurity program and find deficiencies in current practices and procedures. This risk assessment must occur as often as reasonably necessary, but it must occur at a minimum annually or whenever a change in business or technology leads to a material change in the entity’s cybersecurity risk. This ensures that companies, at minimum, keep up to date with any developments that occur with technology that bad actors could exploit if the assessment schedule is too slow, and helps discover any issues that might have developed within the company since the last assessment internally, including a lapse in cybersecurity training for employees. These assessments must be documented and include criteria for evaluating and categorizing threats against the covered entity, assessing the level of protection they currently have, and describing how identified risks will be mitigated or accepted. This last point is important as sometimes the risk is accepted by entities if the alternative security procedures would be too complicated or costly to implement for the information it would protect. Having complicated systems for every piece of information could potentially decrease security due to the overcomplexity involved.
Following the risk-assessment procedure, covered entities are required to establish a program for dealing with vulnerability management for their cybersecurity procedures. At a minimum, the policies and procedures for vulnerability management require that penetration testing of information systems from inside and outside the systems’ boundaries occur by a qualified party at least annually. Penetration testing requires an individual or organization, often a dedicated company with ethical hackers, to attempt to access a target company’s systems, whether through purely digital means or even physically entering the premises, depending on the test parameters. The results of such a test are then shared with the entities, identifying strengths and weaknesses of the security system so that improvements can be made. In addition to penetration testing, entities are also required to conduct automated scans of their systems at a rate determined by their risk assessment or whenever there are any material system changes.
In the event of a cybersecurity incident, the regulations also set out two important steps a covered entity needs to take. The covered entity first needs to enact its incident response plan, which is then followed by providing notice of the incident to the Superintendent of Financial Services. The incident response plan needs to include items such as delegation of responsibility and decision-making to certain employees, the ability to recover from backups of information systems, and the ability to document and correct the reasons for the event occurring that can be implemented in future programs. There also needs to be a business continuity and disaster recovery plan to ensure that the covered entity’s information systems can continue to operate despite a cybersecurity incident. This includes determining which systems are critical to operating the business’s day-to-day operations, establishing procedures to quickly recover data, and creating backups of critical systems. These plans and their associated backups must be tested at a minimum annually, with the results potentially revising the plan implemented. At the same time, a covered entity is required to provide notice within seventy-two hours of any cybersecurity incident to the Superintendent, updating them with any material changes that may occur surrounding the situation. Covered entities are also obligated to provide a notice of compliance every year to the Superintendent that they are complying with the requirements set out in these regulations, either confirming compliance or explaining why they have failed to comply and what remediation is occurring.
As mentioned above, a key part of the NYDFS’s regulations is that specific security standards are described along with the general programs that have been laid out so far. One example is the requirement for MFA when accessing any information systems of a covered entity or, at minimum, establishing an equivalent or superior form of security that must be reviewed annually. MFA is the requirement that user accounts require more than just a password to access. This can come in the form of an email with a one-time code, the same code coming from a dedicated app, or requiring a fingerprint to be scanned. This heightens security by preventing a bad actor from accessing an account by just discovering a user’s password. This threat is exacerbated by the fact that likely sixty percent of Americans reuse passwords, while thirteen percent utilize the same password for every account. MFA prevents this breach from spreading, as the additional security layer would also need to be breached to access an account, which significantly increases security with little effort. Utilizing MFA remains an important part of any cybersecurity program, which is why the NYDFS explicitly included it as a technical standard within the regulations to require covered entities to utilize it because of its efficacy. Despite this effort, between January 2020 and July 2021, the Department found that 18.3 million consumers were impacted by cybersecurity incidents where MFA failures occurred, leading to a guidance letter being issued by the Department to provide insight on common mistakes and practices that occur with MFA.
In the event of a covered entity failing to meet its obligations under the regulations imposed, the Superintendent is authorized to pursue an enforcement action against the breaching entity. The regulations define a breach as either a failure to secure or prevent unauthorized access to nonpublic information because of a failure to comply with the regulations or a material failure to comply for twenty-four hours with the regulations. This method of enforcement means that a covered entity following the regulations and having a robust cybersecurity program would not be held liable for any cybersecurity incidents since the regulations themselves were unable to anticipate such an event. At the same time, a covered entity could be held liable for failing to comply with the regulations even if no information was leaked, forcing compliance to prevent even the possibility of an incident from taking place.
C. Enforcement Case Studies
The NYDFS has had success with the enforcement of these regulations, with multiple settlement agreements coming from enforcement actions taken by the Superintendent. For example, one case involved OneMain Financial Group, LLC (OneMain), a licensed lender and mortgage servicer that operates within New York. Following several alleged cybersecurity incidents, OneMain was forced to pay a fine of $4.25 million dollars, in addition to reinforcing its cybersecurity program through a settlement with NYDFS. The Department noted several violations of cybersecurity regulations, such as failing to review user access privileges, failing to provide cybersecurity personnel sufficient training, and failing to implement and maintain policies that adequately addressed business continuity. The Department found that the continuity policies and procedures of OneMain were insufficient and documented poorly, ultimately leading to a violation of 23 N.Y. Comp. Codes R. & Reg. § 500.03(e). Internal audits by OneMain in 2018 and 2019 discovered issues related to user access privileges, such as local administrative users sharing accounts, some of the said accounts utilizing the default onboarding password, and passwords being stored on shared drives without adequate protection. Cybersecurity personnel were also improperly trained. Specifically, a lack of secure coding training increased the risk of developing an application with a security vulnerability due to failure to keep up with evolving threats.
This enforcement action serves as an example of the way cybersecurity reform should be implemented in the MPC when it comes to establishing standards for companies to follow. 23 N.Y. Comp. Codes R. & Reg. § 500.03 is specific enough that companies are put on notice of particular issues they need to cover—in OneMain’s case, business continuity—but also broad enough to allow companies to determine the best method to accomplish this and keep up with new developments. The MPC could have a similar approach to this issue because it lets companies adapt to new developments and implement solutions that fit their own needs instead of a “one-size-fits-all” policy.
Another example of an enforcement action that took place was a settlement with EyeMed Vision Care LLC (EyeMed), a licensed insurance provider in New York. Following a cybersecurity breach in 2020, EyeMed was forced to revamp its policies and procedures in addition to paying a penalty of $4.5 million. The incident occurred when EyeMed discovered an unauthorized individual had gained access through a phishing attack to an email account associated with enrollment following a series of emails being sent out from the compromised mailbox. A phishing attack takes the form of a bad actor sending a fraudulent message with the goal of gathering sensitive data from an individual or organization. The compromised mailbox was discovered only when further phishing emails were sent out, which had the likelihood of being more effective due to the bad actors’ possession of protected information, making any emails sent appear more legitimate. Several regulations were broken in conjunction with this incident by EyeMed, including a failure to implement MFA in a timely manner, which exposed accounts to unnecessary risk. EyeMed also failed to conduct a risk assessment that complied with the standards set out in the regulations, leading to vulnerability not being discovered and remedied. Allowing nine employees to access the same account with shared credentials also created another security risk by failing to manage user access privileges and making it unclear how the breach took place.
EyeMed helps serve as a case study for the specific requirements set out in the NYDFS regulations, prescribing certain security measures for companies to adopt beyond what they feel is necessary or reasonable. MFA is explicitly required by the regulations, which EyeMed lacked, and thus exposed protected information despite potentially being easily averted by following the regulations. Cybersecurity reforms to the MPC should pay attention to this consent order and the regulation itself. Requiring certain security standards, in addition to giving companies options on how to pursue their own security, helps set the security floor that the NYDFS regulations hope to achieve and the MPC should emulate.
One of the most notable examples of enforcement occurred against Carnival Corporation and several of its affiliated companies, referred to as “Carnival Companies.” The Carnival Companies were listed as covered entities due to their licenses to sell life insurance, accident and health insurance, and variable life insurance in New York. A cybersecurity incident was reported in 2020 to the Superintendent, but it initially occurred in 2019 when spam emails were sent internally from a compromised email account. Three further cybersecurity incidents occurred in 2020 and 2021, including a ransomware attack, malware being deployed through a phishing attack, and another compromised email address sending phishing emails. All of the incidents mentioned had nonpublic information exposed, likely downloaded by the bad actors involved. Carnival Companies’ incident response plan violated the regulations from the outset because the first incident was not reported promptly to the Superintendent, with the notice requirement being omitted from the plan. MFA was also not implemented by Carnival Companies, and training for employees was deemed inadequate due to the number of incidents occurring from employees falling for phishing attacks, both in violation of the regulations. Additionally, because of these deficiencies in their cybersecurity program, despite timely certification in accordance with the regulations, Carnival Companies were found to have improperly certified compliance because of the failures mentioned. Carnival Companies were required to pay a fine of $5 million in addition to surrendering its licenses to operate the relevant insurance companies in New York.
Along with the security regulations and framework discussed in prior cases, the enforcement of compliance requirements in the NYDFS regulations from this case presents another aspect that MPC reform could draw upon. Requiring these compliance notices allows enforcement actions to take place against companies that may have been delinquent in prior years, as Carnival Companies showcased that false certifications are a separate enforcement action in addition to the regulations broken by the breach itself. The regulations here also allow companies to be transparent about their cybersecurity status and create a timeline for mediation, ensuring that companies that are attempting to follow the regulations in good faith are not punished compared to those companies that lie and lead to damage being done.
IV. Why Should the MPC Apply the NYDFS Regulations?
Even after analyzing some of the strengths of the NYDFS regulations, why should the MPC adopt them, and is the MPC even the right forum for these standards? This section covers why the MPC would be a viable option for implementing cybersecurity standards for state and local government procurement. The benefits of standardization are also discussed to showcase why standardization should even occur in the first place instead of sticking with the status quo.
A. Promoting Universal Cybersecurity Standards and Coverage
One of the key benefits of utilizing the MPC as a vehicle for procurement reform is its ability to be universally adopted by any state or local jurisdiction and to be made to fit the individual needs and policies of the relevant jurisdiction. In fact, the original designers of the MPC debated over whether to create a uniform code like the Universal Commercial Code instead of a model code when establishing a system for governments to implement. The reason for choosing a model code hinged on this variability among jurisdictions when it came to procurement organization. Utilizing a model code instead of a uniform code allowed states to implement policies and procedures that worked with their own systems, since they lacked enough uniformity to the point where a universal code could be established.
In the context of cybersecurity, using the MPC as the vehicle for reform would help avoid yet another patchwork of standards for contractors. A major reason for the reform in 2000 was the growing variability among states following the initial publication of the MPC when it came to adapting to purchasing new goods and services, leading to ad hoc decisions with little coordination. States currently have their own procedures for IT procurement and cybersecurity as previously discussed, so imposing a set code may not be the most effective way to implement widespread cybersecurity regulation. The MPC has already been adopted by sixteen states and thousands of local jurisdictions that, prior to its implementation, had varied procurement policies and procedures. Given that the MPC was able to provide a framework for a jurisdiction’s entire procurement system, the addition of cybersecurity to the code would be a minor task in comparison.
Utilizing a model code instead of a uniform code would also make the regulations prescribed more flexible and easier to change as standards evolve and new threats emerge for companies to deal with. While it is easy to observe and point out the issues with any cybersecurity framework that relies on terms such as “reasonableness,” these frameworks are at least able to evolve and be applied broadly without being constrained by prior regulations. The NYDFS regulations explicitly warn about the issue of creating an “overly prescriptive” system that fails to match new risks and threats, but, at the same time, note the importance of creating some sort of minimum cybersecurity standards that companies need to reach. Any jurisdiction utilizing the MPC with standards similar to those found in the NYDFS would, therefore, have that same security floor and let contractors know what to expect when doing business.
The MPC, being the medium for cybersecurity regulations, benefits from the MPC’s age because it is already in need of an update. The latest edition was the 2000 revision, which makes the current Code twenty-four years old, compared to being eighteen when initial revisions began. The ABA is already undertaking a reform process that began in 2021, indicating that there will be an updated version of the MPC within the next few years. This time line is advantageous for implementing some type of cybersecurity program for state and local procurement since such issues are likely to be discussed at any reform conference or meeting by procurement professionals, given the importance of IT procurement for governments. By “tacking on” cybersecurity to an already established and successful program that needs to handle these issues anyway, there is no need to establish a hypothetical “Model Cybersecurity Code.”
The MPC also benefits from its creator’s central position: the ABA. The ABA’s unique position as a national, neutral organization allows it to access resources and organizations that a single state, and especially a single local government, might not be able to access easily. This position was referred to by the members of the 2000 Revision Project as “[t]he greatest contribution of the 1979 Code,” since the MPC could act as a neutral ground for professionals from across the industry to participate and enhance the final product. Rather than allowing a state or local government to potentially miss critical information by not having certain people contribute to their cybersecurity program, the ABA provides a forum for a developed conversation among experts from across the country in a highly publicized forum. This is a level of publicity that a county or even smaller state might not be able to get due to already strained cybersecurity budgets, leading to a less developed program.
Overall, incorporating cybersecurity regulations into the MPC takes advantage of the MPC’s central, neutral position that has already been established through successful implementation in other jurisdictions. Cybersecurity, when it comes to procurement, should therefore take advantage of an already created code to help set universal regulations.
B. Standardization of Cybersecurity and Its Benefits
The key benefit of creating a standardized set of cybersecurity rules for state and local governments is that it allows companies to easily compete among different jurisdictions without worrying about different security standards. This goes back to the argument for similar regulations among state procurement codes in general by the MPC and was a critical part of why the revised version was amended in response to growing costs accrued from a less competitive pool of offerings. If companies have to tailor their programs to each state because different jurisdictions have different notions of what a “reasonable cybersecurity program” should entail, compliance costs will increase. Companies would then be forced to either adopt overcomplicated cybersecurity systems or stop participating in such contracts, reducing competition, driving up the cost, and reducing opportunities for small businesses to compete, given that large companies would likely be able to shoulder the cost more effectively. Eliminating waste in procurement was one of the main objectives of the MPC, along with the goal of saving the taxpayer’s money. While the focus of the original MPC had been to accomplish this outcome by establishing proper procurement procedures instead of the varied systems that states had been utilizing, the same principle applies here as well. Promoting competition is one of the main pillars of any procurement system because of the benefits that stem from having access to the widest range of competitors. Contractors are motivated to perform well and lower their costs when a contract is competitive, saving taxpayers money by selecting the source with the best value from this competition. For cybersecurity, this means creating a standardized system of regulations that allow companies to participate in a larger market space because transferring their business does not require an overhaul of their systems. Implementing this system with a model code instead of a uniform code also carries with it the benefits of flexibility in that companies will be aware of the security floor that they need to reach to participate in government contracts, but still leaves states the ability to tweak regulations for their own policy reasons that are based on MPC principles.
The benefits of standardization and the push towards standardizing cybersecurity regulations have already been occurring at the federal level with the CUI Program, which had federal agencies suffer from the same issues of variability that states currently experience. Agencies suffering from ad hoc policies and procedures when it came to handling sensitive information caused issues when it came to marking, safeguarding, and disseminating information. Without a single standard, agencies were left to a patchwork of standards that impeded how they handled information, and the CUI Program was therefore implemented to balance sharing information without unnecessary burdens. This can be analogized to state cybersecurity programs, with the states being the agencies and the problems with handling information being compliant with the various regulatory schemes in place. Rather than having each agency utilize its own standards, the CUI Program has them follow the NIST standards to help promote this unity, with even the NYDFS regulations considering such standards when deciding on the level of enforcement against a breaching entity.
Another major example of standardization in cybersecurity has been the implementation of FedRAMP in the federal government and the extent to which StateRAMP has been adopted by states. For FedRAMP, consolidation of authorization of federal cloud services helped reduce costs to the end user and the various agencies by reducing duplicative efforts to establish contracts, inconsistencies with standards, and cost inefficiencies that come about from these issues. By having a single entity determine how the federal government handles cloud-based services, the government is able to leverage its buying power as a unit rather than individual agencies with their funds. It follows that this plan results in a lower overall cost to the system and, ultimately, the taxpayer, as funds are used more efficiently due to contractors now dealing with a single, consistent buyer rather than a patchwork of agencies. States utilizing a common cybersecurity standard could also experience a similar decrease in cost as companies would no longer have to handle different cyber compliance programs like they did for agencies before the CUI Program. StateRAMP also helps accomplish this goal with its standardized programs and Authorized Products List, which even accepts FedRAMP certification in addition to its own certification program to highlight a company’s cybersecurity protocols. Participating states can take advantage of this authorization with the knowledge that certified companies meet minimum standards, and companies do not need to worry about adjusting their systems because one contract took place in Maine and another in Colorado.
Standardization of cybersecurity regulations through the MPC ultimately benefits every party involved in the transaction. States get a better deal by opening the marketplace to companies that otherwise would have avoided participating; companies save money by utilizing a standard cybersecurity framework; and taxpayers benefit from not having funds wasted through a lack of competition.
V. Adapting the Regulations to Government Procurement
However effective the NYDFS regulations might be, they were created to regulate the financial services industry and, therefore, tailored to the particular needs imposed by the industry. This section covers how the government contracts industry can mold the NYDFS regulations for itself, preserving the key principles while focusing on issues experienced by government contracts. Additionally, this section covers how the MPC can deal with two major issues related to imposing cybersecurity regulations: rapidly evolving cybersecurity standards and concerns over the ability of small businesses to comply with these standards.
A. Utilizing a Financial Regulation for Government Procurement
The NYDFS regulations set out a solid foundation for other organizations to take advantage of when developing their own cybersecurity regulations, but the regulations were ultimately designed to be used by the financial industry. However, several key principles from the regulations can be incorporated, even if the government contracts world has different requirements, including:
• Plain language that makes it easy for covered entities to understand the requirements imposed, with technical standards available as necessary,
• Flexible requirements that set out minimum security standards for covered entities that provide protection but do not impose excessively rigid standards and prevent adaptation to new cybersecurity issues,
• Having each company design its own security system based on the potential attacks that it might be facing, allowing different levels of protection based on the information that needs to be protected.
The most glaring feature that would need to be addressed when applying these regulations to government procurement would be how to determine which companies need to comply with the regulations. The NYDFS regulations accomplish this by having every covered entity that requires a license to work in the financial sector automatically be captured by the regulations. Unless there exists some exemption, each covered entity needs to maintain a cybersecurity program to operate in New York. Government procurement, especially at the state level, ostensibly does not have an analogous licensing system into which these requirements can be incorporated. This does not necessarily mean that using a financial sector law is impossible as a standard for government procurement. Mandatory disclosure rules for federal contractors can be analogized to the mandatory disclosures of publicly traded companies. In the financial context, the information symmetry between shareholders and officers led to the requirement that officers disclose certain information to balance out the relationship, which is analogous to contractors being forced to disclose information to the government because of their own information imbalance. The precedent for using a financial sector rule and applying it to government procurement does exist; it is just the manner in which it can be implemented.
The best method of ensuring compliance with any regulations within the MPC would be creating a certification process that can be analogized to the NYDFS licensing requirements. Contractors would be required to submit to a certification process to ensure that they comply with the standards set out in any proposed MPC regulations, at a minimum placing them on notice that such regulations and the penalties for failing to follow them exist. Certification could range from how the NYDFS requires a notice of compliance to the Superintendent (which in the procurement context could be the state’s IT department or procurement equivalent) to requiring full 3PAO certification like with FedRAMP or StateRAMP. Both options have their pros and cons, such as the notice requirement relying on trusting that the company is actually following regulations rather than the knowledge that an outside party has confirmed that a company is following regulations. However, this self-certification is cheaper than requiring a certification from a 3PAO and the continuous monitoring that would follow, even if security would at least be confirmed by a source other than the company.
An alternative method of ensuring security compliance for contracts—suggested by the MITRE Corporation—is to use security as an evaluation factor for competitive source selection, with better security leading to a higher overall score. This would be one part of their overall goal of elevating security as an evaluation metric because of the risks that poor cybersecurity programs carry with them when the cost is instead prioritized. While this method has some benefits, it is likely not the best one to use for state and local procurement. MITRE’s focus is exclusively on utilizing the DoD’s contracting leverage to ensure more contractors focus on security by rewarding said contractors through security being the “4th pillar” of acquisition objectives. For the DoD, making cybersecurity a significant factor in procurement makes sense, as national security and cybersecurity are closely interlinked in this field.
Applying the MITRE proposal to state and local procurement would not be the best method of implementing cybersecurity because of this increased expense. All cybersecurity programs carry with them some risk that can be calculated with any number of formulas, with the most basic being to multiply how much a single incident would cost by the number of times it would occur in a year. Not all information is created equal, and imposing significant security standards that come with a high cost would harm both competitiveness and over-secure systems for no reason. One of the options for a cybersecurity program when it comes to managing risk is simply acceptance that incidents will occur, which is not always the best option but exists for certain cases. As a practical example, a person’s home likely has something within it that costs over $5,000 that the person would like to keep from getting stolen. But how much did they spend on the lock to their front door? What about their windows? It is likely that they do not have a $5,000 lock or window system installed for the same reason some cybersecurity programs do not provide perfect protection: expense.
While MITRE’s proposal does make sense for the contractors the DoD has to work with when it comes to state and local procurement, this overemphasis on security might end up harming the system by imposing too many costs and complications for the company’s backend with reduced benefits. Instead, using the NYDFS notice of compliance system or a certification program like FedRAMP or StateRAMP can balance out the need for security while at the same time either creating a method of enforcement for false certifications or having a 3PAO independently confirming security requirements.
B. Rapidly Developing Cybersecurity Standards
One of the key reasons why implementing cybersecurity regulations is so difficult is that the field advances at an extremely rapid rate, meaning that regulations passed could become no longer effective the same day that they are implemented. The reality is that these advancements progress exponentially, and, thanks to events such as the COVID-19 pandemic, technology could evolve “ten years in . . . [ten] weeks,” leaving advice that was once applicable to be ineffective or even dangerous to cybersecurity programs. It used to be the case that frequent password changes were advised by corporations and this was thought to help reduce the risk of a cybersecurity incident. However, this replacement has been shown to instead have downsides as users rotate through easy to remember passwords with minor changes. Because of this, NIST suggests that passwords only be reset once a year or following a security incident, as hackers are able to predict simple changes to passwords like changing “samplepassword1” to “samplepassword2.” This is just one example of many that require specialized advice from cybersecurity professionals who need to stay up-to-date on current trends in cybersecurity, adjusting advice given based on the efficacy of prior practices.
A solution to this issue would be the creation of an ongoing committee within the next MPC Revision Project dedicated to cybersecurity to create tweaks to the regulations when new developments occur. The ABA already issues formal opinions that provide guidance for lawyers on what to do with groups like the Standing Committee on Ethics and Professional Responsibility. Formal Opinion 483 dealt with data breaches and a lawyer’s responsibilities when it comes to protecting a client’s information from cyberattacks, requiring development of specific, proactive plans to stop breaches and mitigate any damage that might occur. Given the complexity of cybersecurity, it is likely that a dedicated group of experts would be required to establish regulations properly for any reform, and this group could stay on afterward to provide guidance for cybersecurity and the MPC like other committees already do. Guidance letters for best practices by either state and local governments or contractors could be issued, helping define and reshape terms as technology develops.
In addition to a committee, any proposed regulations could be pegged to an external technical standard. Following the NYDFS principles of establishing minimum standards that contractors are required to adhere to, in whatever method they determine is best for them, with limited technical requirements, gives space for standards to develop in case of any enforcement action. Utilizing the technical standards provided by NIST could serve as a reference point for any proposed regulations so that contractors have an idea of what is expected of them by state and local governments. As stated previously, the NYDFS already uses the NIST standards to determine the level of punishment a covered entity would experience following a failure to protect personal information, with policies and procedures such as the NIST standards serving as a mitigating factor. NIST SP 800-171 could be used as a standard and adapted with references to CUI being changed to state or local government information, or NIST SP 800-53 could be set as the standard, given that it already applies to information systems and organizations.
The yearly self-certification of compliance can also be used as a tool to advance cybersecurity regulations, giving contractors the opportunity to inform governments of new developments and adapt their policies to any changes that have been made. While requiring MFA for covered entities, the NYDFS regulations allow companies with a CISO not to utilize MFA. Instead, reasonably equivalent or superior controls can be implemented so long as (at minimum) an annual review is conducted of such controls. These reviews could then be shared with the hypothetical committee to determine which controls contractors should implement as standards evolve.
Systems that deal with cybersecurity will run into issues of becoming obsolete as technology develops. However, by having the ability to respond quickly to these developments and issue guidance to contractors when necessary, these issues can be mitigated and information safeguarded compared to the drawn-out process of passing new statutes or even administrative regulations.
C. Small Business Concerns
Implementing any sort of cybersecurity program will come with a cost as personnel need to be hired, systems established, and existing employees trained in new policies. To help mitigate some of these costs, the ABA itself could help train small businesses in cybersecurity or partner with other groups that can provide training resources, allowing more businesses to participate and ultimately lowering costs as competition increases. While large companies may be able to handle these additional costs in complying with regulations, small businesses may not have the resources to implement robust cybersecurity programs. These concerns are not new, and the regulations and programs discussed consider small businesses when implementing any standards. The NYDFS regulations have a specific carve-out for small businesses, with the qualifying factors requiring either having less than twenty employees, making under $7,500,000 in gross annual revenue, or possessing less than $15,000,000 in assets. Certain policies and procedures, such as penetration testing, do not need to be implemented, but others like MFA do need to be included, balancing some level of security with the financial strain a full cybersecurity system might have on a three-person operation. Recognizing that a small business might still need assistance in learning about cybersecurity and the systems that need to be implemented, the NYDFS established a resource page to help give information to small businesses. This includes a toolkit that allows businesses to avoid having to set up security systems from scratch, giving them a foundation to work, on rather than risking the creation of a flawed system from the outset.
StateRAMP also recognizes the issues that come from having small businesses be subject not just to an initial security certification but the continual monitoring that follows. To combat this, StateRAMP established the “Progressing Security Snapshot Program” to help facilitate the certification of small businesses that would otherwise be unable to participate. The idea is that small businesses can receive quarterly security snapshots and consult with StateRAMP experts to improve their “cyber credit score,” providing some form of verification for these businesses while progressively working on the strength of their security program. This proposal would allow small businesses to begin to enter markets where cybersecurity is required but also not be faced with the cost of a complete security overview at the start of their business venture.
Ultimately, there will be some impact on businesses when it comes to compliance, both big and small. With this recommendation that the ABA participate in this process being implemented, the impact should be lessened, and support provided for businesses that need assistance when it comes to the complex field of cybersecurity.
VI. Conclusion
In conclusion, when the MPC is inevitably reformed to meet current procurement standards, it should address the issue of cybersecurity in state and local procurement. This reform could utilize the NYDFS cybersecurity regulations because of their ability to balance out broad standards for companies to implement and specific technical requirements to ensure a minimum threshold of cybersecurity is met by these companies. The MPC would be the best vehicle for this process because of its current success as a model code. This would be a net benefit as standardization of cybersecurity across different jurisdictions encourages more competition, lowers prices, and provides more security as technology becomes more important in government procurement.
