Hello everyone, and thank you for attending this CLE regarding incident response counseling concerning data privacy and cybersecurity. My name is Spencer Pollock. You have myself and Eric Benson. We are both attorneys. Data privacy and cybersecurity attorneys with McDonald Hopkins. Just a brief background on both Eric and I and our group. Our group has approximately 32 data protection and cybersecurity attorneys on our national team. We've handled over 10,000 privacy and cybersecurity incidents. We've counseled about over 1500 companies with regulatory investigations. We've conducted over 750 breach response workshops, and we specialize in over 20 industries, including accounting, automotive, banking, drug and pharmacy, financial services, food services, franchises, healthcare, higher education, hospitality, information technology, insurance, manufacturing. Municipalities. Nonprofits. Professional services. Property management. Real estate. Retail. Staffing, telecommunications and utilities. Basically, we are a one stop shop for any and all type of companies that are need assistance with privacy, compliance or data breach counseling. So just to step back to really where we are, about 15 years ago, the world changed and the world changed because information became currency. And criminals determine that they no longer needed to walk into a bank to get money. They only needed to crack into your computer, into your servers, because they figured out that information has become so valuable. Information such as Social Security numbers, driver's license, bank account, health information, anything that can really lead to identity theft, financial harm or embarrassment. And so they started leveraging that about 15 years ago and extorting companies. And from there. The law shifted and the law started becoming much more stringent and regulated when it comes to protecting our information. So the loft saw this threat. And they responded. And the purpose behind laws is mainly to address threats and harms and create deterrence and punishment to protect people, to protect from those harms. And so we saw an influx of new laws coming in. And with all these new laws, you get massive amounts of liability. Massive amounts of responsibility. And then a huge need for legal services to protect companies in these instances. And to help companies become more compliant. So when we start looking at these laws. The big part is to think about really what information was impacted. Where are people located and what industry are they in? Because that's going to dictate the legal requirements that obligate. A company when it comes to a data breach, notification or privacy requirements, and they're going to vary between health care. Uh glba. The Gramm-Leach-Bliley Act, which is financial services, potential insurance data security laws, potentially government contracting rules, or just primarily state data breach notification laws. And so that really is going to dictate the course of investigations. And so today we're going to really walk you through helping you understand the response aspect to determine whether or not an incident has become a breach. And there's three primary phases, investigation and verification phase, the notification phase and the remediation phase. And so Eric's going to start by covering the investigation and verification phase. Thanks, Spencer. So I'll pick it up from here with with a discussion of, broadly speaking, the common types of cybersecurity and data privacy incidents that we see often as cybersecurity and data privacy attorneys. Um, this slide doesn't cover every, every potential, you know, incident that that could involve, you know, an impact to protected information. But it gives us a, you know, an understanding of, of broad themes around that. Um, perhaps most commonly would, would be an incident that would involve um, intrusion into an organization's system. So frequent flyer incidents in that realm would include ransomware. For example, this is when a unauthorized actor launches malware against an organization's systems to encrypt data and hold that data for ransom. Where the privacy piece comes into play in the privacy legal analysis comes into play is whether or not is an analysis of whether or not the bad actor either took data from the environment in the in the process of launching the ransomware, or perhaps they access the data while in the environment or some kind of combination of both or neither. Um. Another example of a common type of incident involving unauthorized access to or to an organization's systems would be a business email compromise event. This is when an attacker finds their way into an organization's email tenant, accesses one or more email accounts. And if the if if one of those accounts contains protected information, it may or may not rise to the level of a data breach. We'll explore that further in the presentation. But so broadly speaking, you know, if you if you if you look at at an at an event that involves unauthorized access to to a company's systems and those systems contain protected information, it could have the have the result of turning into or rising to the level of a data breach, that being a legal term of art that we'll explore further. Um, another frequent type or category of incidents that we often see involve the unintended disclosure of protected information. Um, so, you know, common fact patterns involving mistaken or unintended disclosure of information are often quite simple. It can be something as simple as someone sending out an email. Let's say it's with an Excel spreadsheet attachment. Uh, perhaps in that email or the attachment contains protected information. It's easy to send emails to to the to the wrong place. So oftentimes we'll see matters where, you know, there's mistakenly sent email correspondence with protected information to a party that is not that is not authorized to to see or acquire that information, that type of a fact pattern could potentially result. In a data breach depending on the the applicable law and the specific facts of the case. Another frequent type of incident involving unintended disclosure of information would be a accidental elevation of of account privileges. So organizations you work with often many user accounts, it often internally employee user accounts at various levels of of privileges to see information based on the status of the user. If a if a user is elevated to a spot accidentally where they where they have privileges that they that they should not have and see information protected information that they should not be viewing, that could potentially result in a data breach. Again, data breach being a legal term of art that we will explore further. Um, physical records. This is, you know, kind of an old fashioned type of incident, but it still comes up very often. You have a situation or, you know, you could have a situation where files, you know, physical paper files are either misplaced, you could leave them at a train or a bus stop. Uh, you know, that that can that can happen and that that results in an exposure of information. Assuming that those those files contain protected information, you could have a physical break in to to an organization's facilities. And by way of that, a potential unauthorized viewing or acquisition of paper files that contain protected information. Um, you know, those, those two types of incidents involving paper records are, are commonly seen some and we'll get into this a little bit further some states some state data breach notification statutes contemplate paper records, whereas others don't. Uh, so it's again, um, going to, going to depend on the applicable law, whether or not a situation involving paper records rises to the level of a data breach or not. Um, and then finally, you know, broadly speaking, a, a common type of, of potential data breach, uh, could involve the misconduct of an employee, intentional misconduct, theft of, of protected information that's maintained by an organization or misconduct involving the, the data systems that are maintained by an organization, perhaps locking certain key stakeholders or members of an organization out of a data system or acquiring information from it intentionally, that that has certainly a potential to rise to the level of a data breach. Again, depending on the the applicable law at play and the specific facts of the case. So. Broadly speaking, again, a data breach is going to be when you have a cyber security incident is not necessarily going to rise to the level of a data breach. It's going to depend on the specific facts of the case and an analysis of the applicable law. So it's just important to keep in mind that when you're analyzing a cyber security incident or a potential cybersecurity incident, it's important not to conclude at the outset that it's a data breach unless unless the facts and the applicable law show that that it is it is an analysis that needs to take place, whether or not whether whether or not we actually rise to the level of a data breach when we're when we're thinking about a cybersecurity incident. So we'll explore this further. Um, and the steps of going about that are, are. First going to start with an analysis of whether or not as a threshold question, protected information is involved. If you have a situation, let's say, involving non-protected information, perhaps an organization writes down or records, you know, the favorite flavor of ice cream of all their employees and that and all that information gets exposed. There's no way that that could potentially rise to the level of a data breach because that information, even though it's exposed and even if it's exposed to a criminal or a bad actor, it cannot rise to the level of a data breach because that information itself isn't protected. So when we're talking about an incident that involves. Exposure of information. The basic threshold question is, are we is the information that's at risk even protected in the first place? If if not, the analysis would stop there. And then moving on through the analysis. And we'll we'll we'll dive into each of these in turn. But, you know, if we if we determine, yes, it's protected information, the second question would be, okay, uh. What happened to it? You know, knowing that it is it is information that's protected under state or federal statute or both. We have to consider what exactly happened to it. Was it exposed to a bad actor? Was it acquired by a bad actor? Some kind of combination of both. Something else that's going to have a bearing on whether or not the the incident rises or not to the level of of a data breach? Putting aside what happened in the past to the protected information, we have to also consider what could potentially or what is likely to happen in the future to that information. Um, this is we go through this analysis because it could have a bearing on the conclusion of whether or not the incident rises to the level of a data breach. And it can also have a bearing on whether or not, even if it does rise to the level of a legally defined data breach, whether or not the organization that experienced the breach has obligations to notify impacted individuals. So we so we go through a a analysis of what what could potentially happen to the to the information based on the circumstances of the matter. And finally, as we're as we're analyzing whether or not there's a data breach, whether or not an organization has notification obligations, want to make sure that there aren't any. Applicable statutory exceptions to the conclusion that there's a data breach or the conclusion that there's notification obligations as a result of a data breach. We'll get we'll get into those in a minute. A common one is encryption of of of information. If the if the protected information is encrypted, that could be a situation where there's a safe harbor from having to notify affected individuals due to the fact that that that the information is encrypted and therefore rendered inaccessible to to the unauthorized party that receives it. So we'll get into that in just a minute. Um, finally, if if it is clear and if it is concluded that there is a data breach and it at that at that stage, it could result in and often does result in various obligations, including potential notification obligations to affected individuals. So we'll start with the analysis of what actually is protected information. This is going to vary. Greatly depending on the industry that the organization operates in and as such, the potential applicable law. As a default most organizations are going to be. Covered by the state data breach notification statute, which commonly protects what's what's known as personally identifiable information. Some states will call it personal information. Other states may refer to it in other ways, but commonly spoken of in the in the data privacy community is personally identifiable information. We'll get we'll explore what that means a little bit further in just a second. Um. Health care providers in other highly regulated industries have additional, you know, in addition to state data breach notification statutes have additional potential federal statutes that have privacy provisions in them, such as HIPAA, for example, that that could or may or may not be triggered by a cybersecurity or data privacy incident. Um, in addition to, you know, in addition to health care providers, uh, financial services providers also, you know, find themselves among the, among various industries that have special considerations to, to, to make, uh, in contemplation of a of a data security incident. Um, Spencer mentioned earlier in the presentation, uh, some cyber security incidents may or may not implicate the glba. Um, and finally, government contractors as well as an example, are another highly regulated, uh, you know, could be another highly regulated entity with special considerations if they're working with controlled, unclassified information. So the, the main thing to, to keep in mind here is that. Protected information. What what information is protected is is going to vary based on the nature of the organization, what type of services they're providing, what type of industry they're in, and different industries and different legal schemes. Refer to protected information in different ways. You have PII, you know, on the on on the state statutory side protected health information as defined under HIPAA nonpublic personal information under the Glba controlled classified information, which would be regulated by Dfars. So it is it is going to depend on on the industry for the purposes of of this presentation, we'll focus on PII, personally identifiable information which is protected under state statute. All 50 states having a state data breach notification statute that defines PII or personal information in a certain way and having certain obligations in the result of exposure of that information. So. Getting a little bit further into what protected information, actually. Or rather, what what actually looks like it is going to be it's going to be a situation where you have to look to the law of the of the state of residence, of the individual whose information was exposed. And also, it's going to be a situation where it depends on the. The actual state statute and the statutory definition of personal information. It will vary state by state. That being said, there are a lot of commonalities across across the 50 states. For example, someone's name in combination with a Social Security number is going to rise to the level of being considered. Personal information in all in all, 50 states. Whereas, for example, an individual's name and date of birth that may or may not rise to the level of what is what is considered personal information because it varies state to state. So if you have a situation where. You need to analyze whether or not the information, you know, that that's exposed as a result of an incident is or is not protected information. Under the state statute, you have to look to the state statute, the state data breach notification statute of the individual whose information was impacted to determine whether or not that is PII as it pertains to that impacted individual. Um, it will vary state to state. So. After we've concluded that that protected information is in fact involved in an incident. Again, we have to consider what actually happened to it. When we're analyzing whether or not the incident rises to the level of a full blown data breach as it's defined under the applicable law. Um. Just like. The definition of personal information. The the definition of a breach is going to vary. State to state again with commonalities. Various states and regions in the country mirroring each other with respect to how how a breach is defined. So for the purposes of this of this slide here, we have two states that that have commonalities between them, but also important differences. So Nebraska, for example, defining breach as an unauthorized acquisition of personal information versus Connecticut defining a breach as. A situation that could even involve just mere access to that information. So, um, that is an important difference because you could have a, you could be working with a client that has a cybersecurity incident that involves. Acquisition or access of information, but not the other. So, for example, we talked about the various types of. Main types of cybersecurity incidents, one of them being a business email compromise event and let's say a unauthorized actor. Threat actor is in one or more email accounts maintained by an organization, and we hire a forensic investigator to get involved and to and to review the applicable logs. What did the what did the cyber attacker do while they were in those accounts? And if if that investigation showed, for example, that the threat actor review viewed certain emails or certain attachments without necessarily acquiring. Those emails or attachments that contain protected information. You could have a situation potentially where that incident rises to the level of a data breach in a state like Connecticut that that considers mere access alone to that information to trigger a data breach versus Nebraska, where a full blown acquisition of that of that information is necessary to trigger a data breach. So it is extremely important to assess what exactly happened to the protected information and apply those facts to the law of the state, that of the to the law of the state of residence of the of the potentially impacted individuals to understand whether or not those facts, that incident rise to the level of the of the statutorily defined breach. And again also important to understand that the word breach is used frequently, but the term of art is going to depend state to state, Connecticut defining it as breach of security, whereas Nebraska defining defines it as a as a breach of security of the system. So the word breach in and of itself will depend, uh, will vary state, state to state. Um. So after we've we've concluded that there is definitely protected information involved in an incident and after we've assessed. What, uh. What happened in the incident? What happened to the protected information? And it is seeming likely that that the incident, uh, could could rise to the level of a data breach. It's important also to analyze what the what what could potentially happen looking forward in the future to that information. Why is that important? Well. In some instances. Again, the word that the term breach is defined differently in each state, but sometimes built straight into the definition of a breach is a is a risk of harm analysis. Take Pennsylvania, for example, where in order to have a a data breach, that incident would by definition need to cause or to have the entity reasonably believe that it will cause loss or injury to a resident of of the of the Commonwealth. Um, other states like New York don't necessarily have the risk of harm. A risk of harm analysis built straight into the definition of a breach, but rather have it further down in the statute more as a safe harbor. Uh, to to to notifying affected individuals. In other words. Um, perhaps in New York you have you have a situation where where an incident rises to the level of a data breach. However, um, notification to affected individuals could potentially be determined as not necessary, uh, on account of the, the risk analysis that's built into New York's data breach notification statute. And that risk analysis for New York would, would involve um, an analysis of whether of, of who the information was disclosed to. So in an event where it's disclosed to an employee of the organization and the disclosure does not necessarily uh or is not believed that it will result in, in the misuse of the information or financial harm to the to the affected individuals or emotional harm in certain instances. Then there is a potential that that that incident may not require having to notify affected individuals. An example of a matter that that would warrant a potential risk of harm analysis might be a situation where you have a inadvertent disclosure. Again, that being one of the common types of incidents. Oftentimes organizations are, you know, folks will will send an email to to the wrong recipient. It's a very easy mistake to make. And. You have to consider. Let's say, you know, the organization sends an email, it exposes information related to residents of Pennsylvania. And we determined that that information is protected under Pennsylvania's data breach notification statute. Say it's Social Security numbers, for example. Um. We're going to want to assess the the likelihood of, of harm there, um, to determine whether or not it's it's a it's a, you know, a breach in Pennsylvania. Um, so what would we what would we look to if, if, if we had that type of a situation? Well. Uh, so again, an email goes out to the wrong recipient. It contains, uh, PII with respect to Pennsylvania residents. Well, we would consider the individuals or individual to whom the email was mistakenly sent. Is it was it to a an employee of the organization who would otherwise have the duties to protect that information? Was it to, uh, a random member of the public? Was it to a cyber criminal that that would that will have that would, you know, factor into the analysis here. Did the. Mistaken recipient. Delete the information upon receipt. Did they say that the that they've done anything with the information? Can they attest to that? Can they can they put that in an affidavit potentially? Those are the types of questions that that we would consider. Uh. When assessing whether or not they're whether or not we reasonably believe that that the that the that the exposure of that information could cause a loss or injury to to the Pennsylvania resident. So very, very fact and case specific and also very much depending on. Whether or not the state data breach notification statute has a risk of harm analysis in the statute at all. And if it does, is it in the definition of a breach or is it somewhere else in the statute like New York, for example, where it serves as a as a safe harbor from from notification? So again, very, very case specific there. So again, to recap the analysis here, we've considered whether or not protected information is involved in the first place. If it's not involved, if information is not protected, but it's exposed like exempt, for example, you know, going back to the one we used earlier. Favorite flavor of ice cream and employees, that that cannot be that cannot rise to the level of data breach. But if we know that it truly is protected information, it's considered PII or or, or or it falls under one of those definitions, then we'll assess again what happened to it. Did what happened to it rise to the level of potentially of a data breach? Let's consider what the likelihood of harm is if we still can't. Conclude that there that that it's. You know, not going to result in warranting or that it that it could result in warranting notification. We would want to before ending the analysis, we'd want to make sure that there aren't statutory exceptions that apply that could potentially serve as a safe harbor from notification or from any other, I should say, any other potential obligations that could arise when when we conclude that there is a breach. So what? What could those look like? Uh, I referenced it earlier in the presentation. Encrypted versus unencrypted data. Again, if you have a if you have a. Incident that results in the exposure of encrypted information. We want to make sure to check that the applicable state statute to ensure that there is or is not a safe harbor from from note, from needing to notify affected individuals or any other obligations on account of the fact that the information is encrypted. The reason those the legislative intent behind that being that there is. Understood to be very low risk of harm in an incident where information that's encrypted is exposed due to the fact that a recipient of that information is not really going to be able to do anything with it unless they have the the the key, so to speak, to unlock it. So that is a you know, the encryption of information is something that is that is contemplated under the state data breach notification statutes and can potentially, in some cases serve as as a safe harbor. Again, make sure to check whether or not the. Information. The protected information is stored in a computerized fashion. Is it is it is it data that's maintained on on computer systems or is it written down? Some states contemplating paper records where others don't. So the medium on which the information is stored is is critical to understand in the analysis of whether or not there's a potential data breach at play. And then finally, a situation that involves good faith acquisition by an employee. Again, if an employee encounters information maintained by their employer that they, uh, you know, shouldn't are not authorized to see, but but do so in a mistaken fashion. Let's say it's elevated privileges or let's say they, they receive an email that they shouldn't have received. Um, oftentimes and we have Nebraska as an example, but often times state statutes will consider that. To be a safe harbor even from from notification or it might not even rise to the level of a breach itself if certain factors can be elicited, such as the the, you know, a factor in which it's it's clear that the the employee encountered the information in good faith or accidentally and that there's no circumstances to for us to believe that that information that's you know acquired by in an unauthorized fashion or viewed in an unauthorized fashion would be subject to further exposure the way that you could elicit that potentially. It obviously depends on the case. In some instances, this is where an affidavit might come into play, uh, from from the from the unintended recipient who may be able to, to, to state in an affidavit or a statement that they received the information in an unauthorized fashion or by mistake, and they didn't intend to receive it. They haven't misused it. They've deleted it, etcetera. Again, going to depend on the specific facts of the case. But those are the those are the types of, of of common factors that would, uh, that that would go into play when determining whether or not there's an exception, uh, on, on the basis of a good faith acquisition of the protected information by an employee of the organization. Um, so Spencer, I will turn it over to you now, uh, for, for a discussion of the various. Factors in the various potential obligations that that could come to play. At the spot where we've determined that there is, in fact, a data breach. And there's and there's no, you know, statutory exceptions to it. Perfect. Perfect. So at this point when we've determined about the investigation verification, now we're in the notification phase and there's basically four elements to really be thinking about with the notification phase. There's the who, what, how and when. The who to start is very simple, right? Beyond the regulatory aspect, the who is the individuals impacted? So did you have Eric Benson Social Security number? Did you have Spencer Pollack's driver's license? So at that point you have to notify Eric and Spencer if we've determined that there is a data breach. So obviously the individuals impacted. You also have a data owner requirement where if you imagine if I'm sharing information, if Spencer's Widget Shop shares information with Eric's widget shop about my customer Spencer's customers, Eric becomes a data maintainer, not a data owner. I am the data owner because my customers have given me that information. So determining a data breach now the timelines are going to be different with data owners, but you do have an obligation as a data maintainer to tell the data owner. So if Eric experiences a data breach, he then needs to turn around and tell Spencer about the data breach because it's my client. And so at that point I would be making a decision about notification. Now there's two states that basically compel Eric as a data maintainer to do notifications himself, even without telling the data owner. Those are Florida and Connecticut. The vast other majority of the states and federal laws will say that Eric needs to tell the data owner and put it on the data owner. So you have the individuals, you have the data owners, but then you also have the regulators. So every state is going to vary with this. And it also is going to depend on what laws we're talking about. But in states such as Alabama, Arizona, Arkansas, California, Colorado, Connecticut, Delaware, D.C., Indiana, Florida. Illinois. Illinois. Iowa. Louisiana. Massachusetts. Maryland. Maine. Montana. Nebraska. North Carolina. North Dakota. New Hampshire. New Mexico. New York. Oregon. Rhode Island. South Dakota. Texas. Virginia. Vermont and Washington. The notice should be going to the Attorney General's office if the law is collected, and I'll explain that in a second with that part in states. In Massachusetts, though, you also have to notify the director of consumer affairs and business regulation. In New York, you have to notify the state Consumer Protection Board, the Department of State and the Division of Police, in addition to the attorney general in Florida. Only the Department of Legal Affairs have to be notified. In New Jersey, the Division of State Police in the Department of Law and Public Safety must be notified. In Hawaii, the Office of Consumer Protection must be notified. In South Carolina, the Consumer Protection Division of the Department of Consumer Affairs must receive notice. And in Puerto Rico, the security the secretary of the Department of Consumer Affairs must be notified. So as you see, there's a lot of different variations. The majority of the states that have the regular the. Requirement to notify the primary regulator in the state is generally the attorney general. But as you can see, you want to be very specific about what you're looking at law by law to make sure you're notifying the correct person. And it also is going to depend about how many people are potentially impacted. For example, in Maryland, you only need one person impacted to trigger the requirement to notify the attorney general. However, in Texas, you need 250 people. In California, you need 500 people. So it varies once again, state by state. Some have that very, very low threshold of one person. Some have a higher threshold. And as Iowa and California have 500 some basis say, you don't have to notify any regulator such as Georgia. So it's going to be a state by state analysis. But then you also need to look at the federal law. If you have federal laws impacting you for the Who. So with HIPAA health care organizations, you could potentially be notifying OCR, the Office of Civil Rights, which is with the enforcement arm of HHS. Banking industries. You also have to do potentially the FDIC. Financial institutions could also have the SEC, FINRa. Government agencies could have DOD, Department of State, Department of Energy, depending on their contracts, insurance industries. You could have the Department of Insurance commissioner, the commissioner of insurance departments in various states that have insurance data security laws. So it's really going to depend on the law that's impacting you and doing a deep dive into that for the Who part, the what part gets a little bit more cut and dry, The what part is basically the content that we're going to be putting into this notice that's going to go out in general, you need to be basically explaining what happened when the date of the breach occurred, what information was impacted, provide information to people about how to protect themselves and potentially offer credit monitoring and identity theft protection services. And also what you're doing as a business to basically shore up your defenses and what you're going to do moving forward. Some states do require if a Social Security number was breached to include at least one year of credit monitoring, identity theft protection. Some states, though, such as Massachusetts and Connecticut, do require 18 months. So the states that require it, if socials are involved, Social Security numbers are California, Massachusetts and Connecticut. In general, though, it's always it's never a bad idea to include that, even for the states that don't require that because it's a really good mitigation tool. Other states have specific content that have to go into the letter, such as contact information for an attorney general, contact information for the FTC. Ways to do a security freeze explanation if a security freeze is free. How to get a police report. How to file a police report. And then also, as I said, the information that was impacted. And so we really highlight the companies to include the information that was impacted as required under the law. So you don't have to put. A phone number if that was impacted, unless that's required. Right. We really want to stick to the personally identifiable information that was impacted. Some states require that if a username and password were breached, that you need to be telling them the individual that it was their username and password and advise them to change their password. So once again, it's a state by state analysis, but you do almost have a universal notification that once again goes back to the description of the incident. Information impacted the potential risk, the investigation of remediation, ways to protect yourself, government contact information, and then how somebody can contact the company. The how gets a little bit more interesting. So in general, all the states allow you to do it by mail us mail. If you've got a most recent contact information. Some states allow you to do it by phone. Some states allow you to do it by email. If you don't have enough contact information or potentially in some states, if you meet a threshold based on cost of notification or number of people impacted, then you can do substitute notice. Substitute notice is where you once again, it depends on the state, but in general, you post the notice on your website and then you do media notice. So you send the notice to various media outlets where these people will potentially live. So if you don't have Eric's, if you don't have Spencer's address, but you know, I live in Maryland, you would send media releases to Maryland statewide media outlets in Maryland. Now, in terms of thresholds, some states allow if you have if it's going to cost $100,000 or $250,000 or if it's 100,000 people or more, potentially 500,000 people or more to basically do substitute notice over having to endure the cost of collecting all that information and then mailing out all of those notices because they the states have recognized that the cost does become rather burdensome on these larger breaches. Where it gets really sticky, though, is when so what we call as the calculation clock is to determine when you need to start thinking about when the clock starts ticking. Now, every state is unfortunately going to be different. And that's our common theme here. Every state is different. There's not unless you're in health care or medical, there's no one overarching law. So it's all state by state. So in 12 states, the calculation of clock starts when? So in 12 states. Alaska. Colorado. Hawaii, Illinois, Indiana, Iowa, Michigan, Missouri, New Mexico, North Carolina, South Dakota and Vermont, as well as DC. It's triggered when the entity discovers or is notified of the breach. This 23 other states that basically explain that when the clock starts when a resident information when they know that one of their residents information has been breached or when it's reasonably believed that it was breached. So we take the position that the clock starts after the investigation is completed and we've got a list of people that are impacted, because logically, that would make sense in terms of we would know if Spencer Pollack was involved after we have a list that identifies Spencer Pollack being in Maryland, then it would say at that time the clock would start. And now in terms of the timing, at that point, it varies. Some states have specific timing requirements. So two states, the tightest timing requirement for state law is 30 days, and that's in Colorado and Florida, 30 days from the date of determination of the breach. Ten states. Alabama, Arizona, Maryland. New Mexico, Ohio, Oregon, Rhode Island, Tennessee, Washington, Vermont and Wisconsin require notice no later than 45 days after determining that there's been a breach or without undue delay, consistent with measures necessary to determine the scope of the breach. Delaware, Louisiana, South Dakota and Texas require notice no later than 60 days after the breach. The majority of these laws say, without unreasonable delay, as reasonable as possible. They do give companies a time to determine the nature and the scope of the breach and to get secure, which makes sense because we don't want people focusing solely on notifications when they're vulnerable still. So we need them to be buttoned up and secured. In terms of more of the federal laws under HIPAA, you've got 60 days from the date of determination of breach. But OCR always wants you to do it as soon as possible at that point. In some states, it's a lot tighter in terms of regulatory, in terms of regulators. So if you're regulated under the Nydfs, you've got 72 hours from the date of the incident when it is materially impacting your business or when you've learned that you've got to notify other regulators. So 72 hours is a very tight timeframe. That's the same under a lot of insurance data security laws where they give you about 72 hours to notify the commissioner after you hit a certain threshold of individuals impacted within their state. And if the law applies to you there. Government contracting has very tight timeframes between 24 and 72 hours. You're contractual obligations are also going to dictate the timing of these notifications. So really diving into that to understand it. But once again, it really comes back to this is a very niche area of law. It's very fact specific and you can't just apply one broad stroke across it. You need to be looking state by state law by law on every single time that you have something come up, because also the laws changed very quickly. If we told you the laws in all the states today, in six months, 30% are going to be different. And then you're also going to see new laws that are going to come in that impact it. So you need to be very careful when you're looking at the laws to make sure you're applying the right laws and not just relying on something that was there a year ago. So the next step, after you've concluded your breach, you've sent your notifications, you've finished your regulatory aspects. Now the dust has settled. What do you do? Now you're in the remediation period. And so what I like to say is it's almost lather, rinse, repeat. So you're going to go back to the start. So back to the start is before an incident would have occurred, when, you know, you we wish you would have met us and we would have been able to talk to you about this. But you really want to look at the administrative, physical and technical safeguards. Physical obviously is important, but that's a lot easier to handle internally. The administrative side is the legal compliance. The technical is the cyber security, the more technical aspects for the administrative side. What we really want to focus on are your policies, procedures and protocols that you have in place that are going to demonstrate reasonableness to regulators, employees, clients, the public about how you're protecting information. So what sort of policies am I talking about? Think about basically a written information security policy. That's an umbrella policy that's going to dictate all of the different subset policies when it comes to cybersecurity and privacy. You want a really good privacy policy because that's going to show the public what you're doing with their information, how you're collecting it, how you're using it, how you're sharing it, how you're how they're able to control their information, to how they're able to opt out and access it. You want an incident response plan. So what we know from the statistics is that an average breach globally costs $4.2 million. But a company that has a plan has a team and practices that saves on average 2.6, $6 million. So these are not just numbers I'm pulling out of there. These are from the studies that IBM and the Ponemon Institute did. So it shows that companies that are actually do prepare for these incidents are much better positioned because unfortunately, when it happens, if you haven't prepared, you don't have time to prepare at that point. But the ones that have prepared understand how they're going to weather these, understand how they're going to handle if their systems are down, if they need to get communications out, what their level of exposure is for notifications. So really developing that plan, working with an internal or external legal and cybersecurity experts in tandem, you want to be thinking about your data retention policies. Eric and I will tell you horror stories about companies that have been retaining terabytes upon terabytes, upon terabytes, which is a huge number, very large number of data when they didn't need to. Dating back 20 or 30 years when they had no regulatory obligation. So if you get hit with a data breach and your company has been keeping records for 20 or 30 years, that got exposed and they were acquired, and then Eric and I have determined it was a breach, Well, you're liable for all those people. A lot of our clients are confused when we say that to them. I'm saying, Well, we haven't worked with these people in 20 years. Well, you still have their information, so the law still holds you responsible for it. So having a really good data retention policy to understand what you need to keep and what you don't need to keep, and then moving into data classification policies when data is coming in, how are you classifying it? How are you saving it? Right? Are you mix and matching sensitive information with public information? You really shouldn't be doing that. Really? We want it segregated. The next part would be the vendor due diligence. So nobody knows who Fazio is. But Fazio is a small Hvac company in Pennsylvania. 2014, they got hit with a malware attack which led the hackers to administrative credentials to a payment portal. The payment portal was targets payment portal. So that led to the 2014 target breach. Nobody knows about Fazio, though. Everybody knows about Target. So the big part there is the third party due diligence. Fazio was a third party vendor of Target. And obviously Fazio at that point was using free online anti-malware software, which was not a sufficient product, especially with access into target. So the main point of that story is that one, nobody remembers the fazio's. They always remember the targets. They're going to remember you. They're not going to remember the vendors. So you want to go through that legal process of doing the due diligence with those vendors, making sure that they have the administrative, physical and technical safeguards in place, the same things that you're doing to protect that data because you're going to be held liable, as we discussed earlier, there's the difference between the data maintainer and the data owner. In that instance with Target and Fazio, Fazio would be a data maintainer. So the data maintainer technically is not liable. It always is going to flow back to the data owner, depending also though, on the negligence aspects and the contractual obligations. So you always want to make sure that your vendors are doing what they should be doing and that you're doing the due diligence to demonstrate reasonableness in terms of what you're looking at with them. And then the easiest part to do with this is to train. Right. We want to be training our employees. We want to be doing phishing tests with them. There's great software out there that's not expensive. To really help your employees understand the threats. Do monthly poster campaigns. Email campaigns about cybersecurity threats, have monthly meetings with your employees to discuss the current threat landscape and things they should be looking out for. Really embed this into your culture because employees are the biggest weak link when it comes to data breaches. You know, you can have the best technical infrastructure in place, but if your employees are not trained and they make one wrong mistake, then a data breach starts. And then finally, you really want to be thinking about the parties that you're going to be working with both internally and externally. And so by that, I mean you want to make sure that you have the right team in place. Right. So it's talking to organizations about incorporating the entire C suite to get the everybody on board and then determining externally who you're going to work with if a breach happens. You really want to know your breach, counsel. You really want to know your forensic firm. And you also, as we went back through the incident response plan, want to understand the process, right? So you have the forensic investigation. You have attorneys liaisoning with the FBI. You have a determination of a breach. But then from there, how do you get all those letters out? How do you determine within that data set who's impacted? Well, then you need to understand about the data mining process that companies are brought in to cull through all that data to get us that list to determine who we need to notify. And then what If you have a million people they need to notify? Are you going to be printing a stuffing and mailing letters? No. So then we have to know the companies that we're going to work with for that. So it's a firm understanding of the whole process to really make sure that you've remediated the situation. Because as Eric and I tell clients, it's not you get judged on your first breach, but you get really judged on your second one. So it's what you do in between those two to show the public, to show employees, to show the government the steps you've taken to truly remediate and to truly get better, to best prevent and mitigate the harms of a data breach. Because unfortunately, there's no way to fully stop a data breach. And I think we are at our time. We really appreciate you coming by and taking the hour to listen to Eric and I. And obviously our contact information is up here. If you have any questions, feel free to reach out. And thank you again.