Alston & Bird Consumer Finance Blog

data breach

Wave Goodbye to the Waiver Debate: Court Holds Data Breach Investigation Report Not Work Product from the Start

By ,

Litigants in data breach class actions often fight over whether a data breach investigation report prepared in response to the breach is protected by the work-product doctrine. Common areas of dispute include whether the report was prepared in whole or in part for business—not legal—purposes, and whether the report relays facts that are not discernable from other sources. The fight becomes even more complicated, however, when the company that suffered the data breach is required to provide the report to regulators.

For example, in the mortgage industry, mortgagees regulated by the Multistate Mortgage Committee (MMC) are required to provide a “root cause report” following a data breach. Similarly, under Mortgagee Letter 2024-10, FHA-approved mortgagees must notify HUD of a cybersecurity incident and provide the cause of the incident. These reporting obligations involve production of information to regulators that typically overlaps with the content of data breach investigation reports.

Traditionally, one might think that disclosure of an investigation report (or its contents) to a regulator was a question of waiver. But recently, a federal district court in the Southern District of Florida bypassed the waiver analysis entirely by holding that reports provided to regulators weren’t protected by the work-product doctrine because they were primarily created for regulatory compliance rather than in anticipation litigation, even though, factually, they weren’t originally created for the purpose of regulatory compliance.

What Happened?

In a recent decision in a data breach litigation against a national mortgage loan servicer, the court considered whether investigative reports prepared by cybersecurity firms were protected under the work-product doctrine. These reports were initially withheld from discovery on the familiar grounds that they were prepared in anticipation of litigation following a data breach. But the plaintiffs argued that because the reports were disclosed to mortgage industry regulators, any work-product protections were waived.

Rather than address the waiver issue, the court analyzed whether the documents were privileged in the first place under the dual-purpose doctrine, which assesses whether a document was prepared in anticipation of litigation or for other business purposes. Under this doctrine (adopted by the First, Second, Third, Fourth, Sixth, Seventh, Eighth, Ninth, and D.C. Circuits), a document is protected if it was created “because of” the anticipated litigation, even if it also serves an ordinary business purpose. Notably, the court found that the reports were primarily created to comply with regulatory obligations, specifically those imposed by the MMC, even though they’d initially been prepared in anticipation of litigation. In the court’s view, the unredacted submission of the reports to the MMC, when demanded, evidenced that the predominant purpose for their creation was regulatory compliance.

The court ended with the suggestion that the defendants could have avoided this issue by creating a separate document for regulatory compliance, omitting sensitive findings related to litigation. Aside from this suggestion, there does not appear to be a legal framework under the which the disclosed reports would have been protected work product, at least in the court’s view.

Why Does it Matter?

The district court’s decision creates a new challenge for breach victims seeking to protect investigation reports from disclosure under the work-product doctrine. A key purpose of the doctrine is to allow parties to engage in pre-litigation investigations without the fear of disclosure. Data breach victims dealing with regulators have historically had to manage the risk that disclosing investigation reports (in whole or in part) to regulators could result in litigation over whether work-product protections were waived. But the decision appears to raise the stakes. The risk of disclosure is not limited to a waiver analysis, where parties can defend the disclosure based on the circumstances of the compelled disclosure and can rely on law requiring the narrow construction of privilege waivers. Now, parties must also consider whether using a report for a non-litigation purpose after the fact will lead to the conclusion that the report wasn’t prepared for litigation at all and therefore not privileged in the first place.

What Do I Need to Do?

Because this decision is by a federal district court, this is an area that should be monitored to determine whether a trend develops around the court’s rationale. And in the interim, the best option seems to be to follow the court’s suggestion: create separate documents for regulatory compliance and litigation purposes.

It is, of course, important to maintain a good relationship with regulators to try to circumvent these issues, but the two-report approach is a practical way to preempt the issue entirely. The reality is that many litigation-related items do not need to be submitted in a regulatory report. For example, an emerging issue in the cybersecurity space is whether following a data breach, the company that suffered the breach should bring claims against other related parties. Analyzing the merits of this type of litigation is plainly covered by the work-product doctrine but is not needed for regulatory reports. Thus, by following the two-report approach, sensitive findings related to that potential litigation can be omitted from the regulatory report, preserving the work-product protection for the litigation-related document. This approach could help companies navigate the complexities of dual-purpose documents and maintain the intended protections of the work-product doctrine.

Ginnie Mae Imposes Cybersecurity Incident Notification Obligation

By ,

What Happened?

On March 4, 2024, Ginnie Mae issued All Participant Memorandum (APM) 24-02 to impose a new cybersecurity incident notification requirement. Ginnie Mae has also amended its Mortgage-Backed Securities Guide to reflect this new requirement.

Effective immediately, all Issuers, including subservicers, of Ginnie Mae Mortgage-Backed Securities (Issuers) are required to notify Ginnie Mae within 48 hours of detection that a “Significant Cybersecurity Incident” may have occurred.

Issuers must provide email notification to Ginnie Mae with the following information:

  • the date/time of the incident,
  • a summary of in the incident based on what is known at the time of notification, and
  • designated point(s) of contact who will be responsible for coordinating any follow-up activities on behalf of the notifying party.

For purposes of this reporting obligation, a “Significant Cybersecurity Incident” is “an event that actually or potentially jeopardizes, without lawful authority, the confidentiality, integrity of information or an information system; or constitutes a violation of imminent threat of violation of security policies, security procedures, or acceptable use policies or has the potential to directly or indirectly impact the issuer’s ability to meet its obligations under the terms of the Guaranty Agreement.”

Once Ginnie Mae receives notification, it may contact the designated point of contact to obtain further information and establish the appropriate level of engagement needed, depending on the scope and nature of the incident.

Ginnie Mae also previewed that it is reviewing its information security requirements with the intent of further refining its information security, business continuity and reporting requirements.

Why Is It Important?

Under the Ginnie Mae Guarantee Agreement, Issuers are required to furnish reports or information as requested by Ginnie Mae.  Any failure of the Issuer to comply with the terms of the Guaranty Agreement constitutes an event of default if it has not been corrected to Ginnie Mae’s satisfaction within 30 days.  Moreover, Ginnie Mae reserves the right to declare immediate default if an Issuer receives three or more notices for failure to comply with the Guarantee Agreement.  It is worth noting that an immediate default also occurs if certain acts or conditions occur, including the “submission of false reports, statements or data or any act of dishonestly or breach of fiduciary duty to Ginnie Mae related to the MBS program.”

Ginnie Mae’s notification requirement adds to the list of data breach notification obligations with which mortgage servicers must comply. For example, according to the Federal Trade Commission, all states, the District of Columbia, Puerto Rico, and the Virgin Islands have enacted legislation requiring notification of security breaches involving personal information. In addition, depending on the types of information involved in the breach, there may be other laws or regulations that apply. For example, with respect to mortgage servicing, both Fannie Mae and Freddie Mac impose notification obligations similar to that of Ginnie Mae.

What Do I Need to Do?

If you are an Issuer and facing a cybersecurity incident, please take note of this reporting obligation. For Issuers who have not yet faced a cybersecurity incident, now is the time to ensure you are prepared as your company could become the next victim of a cybersecurity incident given the rise in cybersecurity attacks against financial services companies.

As regulated entities, mortgage companies must ensure compliance with all the applicable reporting obligations, and the list is growing.  Our Cybersecurity & Risk Management Team can assist.

FTC Approves New Data Breach Notification Requirement for Non-Banking Financial Institutions

By , , , ,

On October 27, 2023, the FTC approved an amendment to the Safeguards Rule (the “Amendment”) requiring that non-banking financial institutions notify the FTC in the event of a defined “Notification Event” where customer information of 500 or more individuals was subject to unauthorized acquisition.  The Amendment becomes effective 180 days after publication in the Federal Register.  Importantly, the amendment requires notification only to the Commission – which will post the information publicly – and not to the potentially impacted individuals.

Financial institutions subject to the Safeguards Rule are those not otherwise subject to enforcement by another financial regulator under Section 505 of the Gramm-Leach-Bliley Act, 15 U.S.C. 6805 (“GLBA”). The Safeguards Rule within the FTC’s jurisdiction include mortgage brokers, “payday” lenders, auto dealers, non-bank lenders, credit counselors and other financial advisors and collection agencies, among others.  The FTC made clear that one primary reason for adopting these new breach notification requirements is so the FTC could monitor emerging data security threats affecting non-banking financial institutions and facilitate prompt investigations following major security breaches – yet another clear indication the FTC intends to continue focusing on cybersecurity and breach notification procedures.

Notification to the FTC

Under the Amendment, notification to the FTC is required upon a “Notification Event,” which is defined as the acquisition of unencrypted customer information without authorization that involves at least 500 consumers. As a new twist, the Amendment specifies that unauthorized acquisition will be presumed to include unauthorized access to unencrypted customer information, unless the financial institution has evidence that the unauthorized party only accessed, but did not acquire the information.  The presumption of unauthorized acquisition based on unauthorized access is consistent with the FTC’s Health Breach Notification Rule and HIPAA, but not state data breach notification laws or the GLBA’s Interagency Guidelines Establishing Information Security Standards (“Interagency Guidelines”).

As mentioned above, individual notification requirements for non-banking financial institutions will continue to be governed by state data breach notification statutes and are not otherwise included in the Amendment. The inclusion of a federal regulatory notification requirement and not an individual notification requirement in the Amendment is a key departure from other federal financial regulators, as articulated in the Interagency Guidelines which applies to banking financial institutions, and the SEC’s proposed rules that would require individual and regulatory reporting by registered investment advisers and broker-dealers.

Expansive Definition of Triggering Customer Information

Again departing from pre-existing notification triggers of “sensitive customer information” in the Interagency Guidelines or “personal information” under state data breach reporting laws, the FTC’s rule requires notification to the Commission if “customer information” is subject to unauthorized acquisition. “Customer information” is defined as “non-public personal information,” (see 16 C.F.R. 314.2(d)) which is further defined to be “personally identifiable financial information” (see 16 C.F.R. 314.2(n)).

Under the FTC’s rule, “personally identifiable financial information” is broadly defined to be (i) information provided by a consumer to obtain a service or product from the reporting entity; (ii) information obtained about a consumer resulting from any transaction involving a financial product or service from the non-banking financial institution; or (iii) information the non-banking financial institution obtains about a consumer in connection with providing a financial product or service to the consumer. Unlike the Interagency Guidelines which defines “sensitive customer information” as a specific subset of data elements (“customer’s name, address, or telephone number, in conjunction with the customer’s social security number, driver’s license number, account number, credit or debit card number, or a personal identification number or password that would permit access to the customer’s account”) (see 12 CFR Appendix F to Part 225 (III)(A)(1)), the FTC’s definition of “personally identifiable financial information” is much broader.

For example, “personally identifiable financial information” could include information a consumer provides on a loan or credit card application, account balance information, overdraft history, the fact that an individual has been one of your customers, and any information collected through a cookie. As a result of this broad definition, notification obligations may be triggered for a wider variety of data events, as compared to data breach notifications for banking financial institutions under the Interagency Guidelines or state data breach notification laws. As a result, non-banking financial institutions should consider reviewing and revising their incident response procedures so that they can be prepared to conduct a separate analysis of FTC notification requirements under the Amendment, as distinct from state law notification requirements.

No Risk of Harm Provision

Although the FTC considered whether to include a “risk of harm” standard for notifying the Commission, it ultimately decided against including one to avoid any ambiguity or the potential for non-banking financial institutions to underestimate the likelihood of misuse. However, numerous state data breach reporting statutes contain risk of harm provisions that excuse notice to individuals and/or state regulators where the unauthorized acquisition and/or access of personal information is unlikely to cause substantial harm (such as fraud or identify theft) to the individual.  This divergence between FTC notifications and state law has set the stage for the possibility that a reporting non-banking financial institution could be required to report to the FTC, but not to potentially affected individuals and/or state attorneys general pursuant to state law.

Timing and Content for Notice to FTC

Non-banking financial institutions must notify the Commission as soon as possible, and no later than 30 days after discovery of the Notification Event. Discovery of the event is deemed to be the “first day on which such event is known…to any person other than the person committing the breach, who is [the reporting entity’s] employee, officer, or other agent.” The FTC’s timeline is similar to the timeline dictated for notifying state Attorney Generals under most state data breach notification laws (either explicitly or implicitly), but a key difference from the Interagency Guidelines, which requires notification to the bank’s primary federal regulator as soon as possible.

The notification must be submitted electronically on a form located on the FTC’s website (https://www.ftc.gov), and include the following information, which will be available to the public: (i) the name and contact information of the reporting financial institution, (ii) a description of the types of information involved in the Notification Event, (iii) the date or date range of the Notification Event (if available), (iv) the number of consumers affected or potentially affected; (v) a general description of the Notification Event; and (vi) whether law enforcement official (including the official’s contact information) has provided a written determination that notifying the pu of the breach would impede a criminal investigation or cause damage to national security.  Making this type of information regarding a data security incident available to the public is not part of any current U.S. regulatory notification structure.

Law Enforcement Delays Public Disclosure by FTC, Not FTC Reporting

A law enforcement delay may preclude public posting of the Notification Event by the FTC for up to 30 days but does not excuse timely notification to the FTC.  A law enforcement official may seek another 60 days’ extension, which the Commission may grant if it determines that public disclosure of the Notification Event “continues to impede a criminal investigation or cause damage to national security.”

NY DFS Releases Revised Proposed Second Amendment of its Cybersecurity Regulation

By , , ,

The New York Department of Financial Services (“NY DFS”) published an updated proposed Second Amendment to its Cybersecurity Regulation (23 NYCRR Part 500) in the New York State Register on June 28, 2023, updating its previous proposed Second Amendment, which was published November 9, 2022. While the language proposed is largely similar to the previous draft, which we previously summarized, NY DFS incorporated a number of changes as a result of the 60-day comment period.

Below we outline some of the key revisions to the proposed Second Amendment of NY DFS’s Cybersecurity Regulation compared to the previously issued version from November 9, 2022:

  • Risk Assessment (§§ 500.01 & 500.09). NY DFS previously proposed (in the November 2022 draft) to revise the definition of “Risk Assessment,” which NY DFS has repeatedly emphasized is a core and gating requirement for compliance with the Cybersecurity Regulation, permitting covered entities to “take into account the specific circumstances of the covered entity, including but not limited to its size, staffing, governance, businesses, services, products, operations, customers, counterparties, service providers, vendors, other relations and their locations, as well as the geographies and locations of its operations and business relations.” By contrast, the newly proposed definition more formally defines the components of and inputs to the risk assessment: “Risk assessment means the process of identifying, estimating and prioritizing cybersecurity risks to organizational operations (including mission, functions, image and reputation), organizational assets, individuals, customers, consumers, other organizations and critical infrastructure resulting from the operation of an information system. Risk assessments incorporate threat and vulnerability analyses, and consider mitigations provided by security controls planned or in place.” The revised definition omits the explicit reference to tailoring and customization currently found in § 500.09.  The removal of this language and codification of the risk assessment’s general parameters suggests that although risk assessments can and should be customized to some extent, NY DFS may expect risk assessments to address a more standard set of components that as a general framework is not open to customization.
    • In addition, NY DFS removed the requirement that Class A companies (which are generally large entities with at least $20M in gross annual revenue in each of the last two fiscal years from business operations in New York, and over 2,000 employees, on average over the last two years, or over or over $1B in gross annual revenue in each of the last two fiscal years from all business operations) use external experts to conduct a risk assessment once every three years.
  • Multi-factor Authentication (“MFA”) (§ 500.12). NY DFS continues to stress the importance of MFA in the newly revised draft of the proposed Second Amendment by broadening the requirement (relative to the current MFA requirements and proposed draft from November 2022) and bringing it in alignment with the FTC’s amended Safeguards Rule. In the revised language, MFA is explicitly required to “be utilized for any individual accessing any of the covered entity’s information systems,” (with limited exceptions, outlined below); NY DFS removed from § 500.12(a), (1) the pre-requisite that MFA be implemented based on the covered entity’s risk assessment, and (2) the option of implementing other effective controls, such as risk-based authentication. By doing so, NY DFS appears to strongly recommend MFA implementation across the board, despite retaining the limited exception if the CISO approves in writing a reasonably equivalent or more secure compensating controls (and such controls must be reviewed periodically, and at least annually).
    • For covered entities that fall under the limited exemption set forth in § 500.19(a), which are generally smaller covered entities (based on number of employees and/or annual revenue), MFA must at least be utilized for (1) remote access to the covered entity’s information systems, (2) remote access to third-party applications that are cloud-based, from which nonpublic information is accessible, and (3) all privileged accounts other than service accounts that prohibit interactive logins. As with all other covered entities, the CISO may approve, in writing, reasonably equivalent or more secure compensating controls, but such controls must be reviewed periodically, and at least annually.
  • Incident Response Plan (“IRP”) and Business Continuity and Disaster Recovery Plan (“BCDR”) (§ 500.16). NY DFS added an additional requirement that a covered entity’s IRP include requirements to address the root cause analysis of a cybersecurity event, describing how the cybersecurity event occurred, the business impact from the cybersecurity event, and remediation steps to prevent reoccurrence. NY DFS clarified that the IRP and BCDR must be tested at least annually, and must include the ability to restore the covered entities “critical data” and information systems from backup (but NY DFS does not define “critical data”). As noted in our previous summary, the concept of BCDR is new as of the Second Amendment and not currently in effect in the existing regulation.
  • Annual Certification of Compliance (§ 500.17(b)). NY DFS maintains its current requirement of an annual certification of compliance by a covered entity, but has adjusted the standard for certification from “in compliance” to a certification that the covered entity “materially complied” with the Cybersecurity Regulation during the prior calendar year.  Although NY DFS does not define material compliance, this revision should provide some flexibility for covered entities to complete the certification.  Going forward, covered entities would be presented with two options: (i) submit a written certification that it “materially complied” with the regulation (§ 500.17(b)(1)(i)(a)); or (ii) a written acknowledgment that it did not “fully comply” with the regulation (§ 500.17(b)(1)(ii)(a)), while also identifying “all sections…that the entity has not materially complied with” (§ 500.17(b)(1)(ii)(b)).  It is unclear how NY DFS intends for covered entities to parse the distinction between material compliance and a lack of full compliance, but the requirement for the covered entity to list each section with which it was not in material compliance suggests that it may expect a section-by-section analysis of material compliance for purposes of completing the certification process.
  • Penalties (§ 500.20). Interestingly, NY DFS added that it would take into consideration the extent to which the covered entity’s relevant policies and procedures are consistent with nationally-recognized cybersecurity frameworks, such as NIST, in assessing the appropriate penalty for non-compliance with the Cybersecurity Regulation.  DFS maintains its proposed amendment that a “violation” is: (1) the failure to secure or prevent unauthorized access to an individual’s or entity’s NPI due to non-compliance or (2) the “material failure to comply for any 24-hour period” with any section of the regulation.

The revised proposed Second Amendment are subject to a 45-day comment period, ending August 14, 2023.

SHIELD Act Overhauls New York’s Data Breach Notification Framework

By

On October 23, 2019, New York’s new breach notification provisions came into effect, a result of New York’s passage of the Stop Hacks and Improve Electronic Data Security Act (SHIELD Act) in July. That Act overhauled New York’s data privacy framework, expanding the list of data elements that are considered “private information” while growing the types of incidents and covered entities that may trigger New York’s notification requirement. The SHIELD Act also imposes a new legal obligation for owners and licensors of private data to comply with the Act’s “reasonable security requirement.” Some regulated businesses, like those in the healthcare and financial industries, will be deemed compliant with the SHIELD Act’s reasonable security requirement if they already comply with laws like HIPAA or the GLBA. In an attempt to mitigate its potential burdens on smaller operations, the SHIELD Act explicitly defines small businesses, for whom the Act’s “reasonable security requirement” will be assessed with regard to factors like a business’s “size and complexity.”

The SHIELD Act’s breach notification provisions went into effect on October 23, 2019, while the new data security requirement goes into effect on March 21, 2020.

The Act’s main provisions are described below.

Expanding the Types of Incidents and Entities Covered Under Breach Notification:

The SHIELD Act expands the pool of incidents which trigger mandatory notification to data subjects.  Prior to the SHIELD Act, New York required individual notifications only when certain private information was acquired by an unauthorized individual. Under the SHIELD Act, New York now requires individual notifications where such information is either accessed OR acquired. In deciding whether such information has been unlawfully accessed under the statute, the Act directs businesses to consider whether there exist any “indications that the information was viewed, communicated with, used, or altered by a person without valid authorization or by an unauthorized person.”  So now under the SHIELD Act, if an unauthorized entity merely views information and does not download or copy it, New York requires individual notifications.

The SHIELD Act also expands which entities may be required to make disclosures under New York’s notification requirement. Previously, New York required notifications only from those entities which conducted business in New York and owned or licensed the PI of New York residents.  Under the SHIELD Act, New York’s notification requirement applies more broadly to any business which owns or licenses the private information of New York residents, regardless of whether it conducts business in state.
Expanding the Definition of Private Information

Not only does the SHIELD Act expand the types of breaches which may trigger notifications, it further expands New York’s definition of private information (“PI”) by incorporating biometric data and broadening the circumstances in which financial data is considered PI.  The Act defines biometric data as that which is “generated by electronic measurements of an individual’s unique physical characteristics,” such as fingerprints, voice prints, and retina or iris images.  And while account numbers and credit/debit card numbers were previously only considered PI in combination with security codes and passwords that permitted access to financial accounts, now under the SHIELD Act, such information is considered PI under any circumstances where it could be exploited to gain access to an individual’s financial accounts, even when security codes and passwords remain secure.

Under the SHIELD Act, New York now joins those states that protect online account usernames and e-mail addresses when stored in combination with passwords or security questions that could provide access to online accounts.  The Act does not require usernames and e-mail addresses to be paired with other personal information, beyond that needed to access an online account, to constitute PI.

Clarification of Substitute Notice by E-mail:

Prior to the passage of the SHIELD Act, New York more broadly permitted notification by e-mail when the notifying business had access to the e-mail addresses of all affected data subjects. The SHIELD Act, however, creates a new exception where notice by e-mail is no longer permissible when the breached information includes the data subject’s e-mail address in combination with a password or security question and answer.  This provision appears aimed at preventing businesses from notifying by e-mail when the notification itself may be sent to a compromised account.

Breach Notification Content Requirements and Exemptions:

The SHIELD Act expands the required content of notifications by requiring a business to include the telephone numbers and websites of the relevant state and federal agencies responsible for providing breach response and identity theft services.

On the other hand, the Act also carves out new exceptions in the case of inadvertent disclosures or where notification may already be required under another statute. The SHIELD Act exempts businesses from New York’s breach notification requirement if information was disclosed inadvertently by persons authorized to access the information and the business reasonably determines that such exposure will not likely result in the misuse of information or other financial or emotional harm to the data subject.  Such determinations, however, must be documented in writing and maintained by the disclosing company for at least five years.  If the disclosure affects more than five hundred New York residents, a business availing itself of this exemption must provide the written determination of non-harmfulness to the New York Attorney General within ten days of making the determination.

The Act further exempts certain businesses from making additional notifications where they are already required to notify under other federal or state laws.  Under the SHIELD Act, no further notice is required if notice of a breach is made under any of the following:

1)      Title V of the Gramm-Leach-Bliley Act (GLBA)
2)      the Health Insurance Portability and Accountability Act (HIPAA) or Health Information Technology for Economic and Clinical Health Act (HITECH);
3)      New York Department of Financial Services’ Cybersecurity Requirements for Financial Services Companies (23 NYCRR 500), or;
4)      any other security rule or regulation administered by any official department, division, commission, or agency of the federal or New York state governments.

Reporting HIPAA and HITECH Breaches to the State Attorney General:

Any covered entity required to provide notification of a breach to the Secretary of Health and Human Services under HIPAA or HITECH must also notify the New York Attorney General within five business days of notifying HHS.  Thus, while the SHIELD Act exempts HIPAA and HITECH regulated companies from re-notifying affected individuals, it nevertheless requires an additional notification to the state Attorney General.

Creation of the Reasonable Security Requirement:

Effective March 21, 2020, the SHIELD ACT imposes a new “reasonable security requirement” on every covered owner or licensor of New York residents’ private information. The SHIELD Act requires businesses to develop and maintain reasonable administrative, technological, and physical safeguards to ensure the integrity of private information.

Reasonable administrative safeguards include:

(1) Designating one or more employees to coordinate security; (2) Identifying reasonably foreseeable internal and external risks; (3) Assessing the sufficiency of the safeguards in place to control identified risks; (4) Training and managing employees in the security program practices and procedures; (5) Selecting service providers capable of maintaining safeguards, and requiring those safeguards by contract; (6)Adjusting the security program to account for business changes or other new circumstances.

Reasonable technical safeguards include:

(1) Assessing in network and software design risks; (2) Assessing risks in information processing, transmission, and storage; (3) Detecting, preventing, and responding to attacks or system safeguards; (4) Regular testing and monitoring of key controls, systems, and procedures.

Reasonable physical safeguards include:

(1) Assessing the risks of information storage and disposal; (2) Detecting, preventing, and responding to intrusions; (3) Protecting against unauthorized access or use of private information during data collection, transportation, and destruction; (4) Disposing of private information within a “reasonable amount of time after it is no longer needed for business purposes by erasing electronic media so that the information cannot be read or reconstructed.”

Applying the Reasonable Security Requirement to Small Businesses:

The SHIELD Act makes special provision for small businesses, presumably to avoid overly burdening them. Under the statute, a small business is defined as any business with “(I) fewer than fifty employees; (II) less than three million dollars in gross annual revenue in each of the last three fiscal years; or (III) less than five million dollars in year-end total assets.”  While small businesses are still subject to the reasonable security requirement, their safeguards need only be “appropriate for the size and complexity of the small business, the nature and scope of the small business’s activities, and the sensitivity of the personal information” the small business collects about consumers.

Implications of the SHIELD Act’s Security Requirement for Compliant Regulated Entities:

Just like businesses may be exempted from the SHIELD Act’s notification requirements if they comply with another statute, businesses may also be deemed to be in compliance with the SHIELD Act’s reasonable security requirement if they are already subject to and in compliance with the following data security requirements:

1)      Title V of the GLBA;
2)      HIPAA or HITECH;
3)      23 NYCRR 500, or;
4)      Any other security rule or regulation administered by any official department, division, commission, or agency of the federal or New York state governments.

Penalties for Noncompliance:

The SHIELD Act increases the penalties for noncompliance with New York’s notification requirements. Previously, businesses faced a fine of the greater of $5,000 or $10 dollars per instance of failed notification, so long as the latter did not exceed $150,000.  Now, penalties may grow as large as $20 per incident with a maximum limit of $250,000.

The Act also lengthens the time in which legal actions for failure to notify may commence from two years to three years. This time is measured from either the date on which the New York Attorney General became aware of the violation, or the date a business sends notice to the New York Attorney General, whichever is first. Regardless, in no case may an action be brought “after six years from the discovery of the breach by the company unless the company took steps to hide the breach.”

The SHIELD Act empowers the New York Attorney General to sue both for injunctions and civil penalties when businesses fail to comply with the Act’s reasonable security requirements. It explicitly excludes, however, any private right of action under the reasonable security requirement provisions.