About Us | Contact Us
View Cart

Incident Response Laws

By Dan Hadaway | Wednesday, October 8, 2014 - Leave a Comment

47 States have Customer Notification Laws


“Which laws do we need to comply with?”

Another one of those Dan’s New Leaf Posts, meant to inspire thought about IT Governance . . . .

ServIcons_ITAudit_01

We’re often asked a question like:

“Does Indiana (or Ohio or Illinois or . . . ) have a law regarding data breach response and, in particular, are we to notify somebody at the state?”

Yes,  Indiana and 46 other states have such a law.

You can usually find the law for your state by Googling “<your state> data breach statute.”

However, for those governed by HIPAA GLBA SOX and all the other “bad-news laws,” in most of those states, if you already comply with a federal regulation that covers customer notification, you might be able to avoid the paperwork hoops that state law often requires you to jump through.  For example, a financial institution that complies with the disclosure requirements prescribed by the Federal Interagency Guidance on Response Programs for Unauthorized Access to Customer Information and Customer Notice is not required to make a disclosure under the Indiana Code 24-4.9, which governs incident response for entities in Indiana.  Banks and credit unions:  We interpret this to mean that if your Incident Response Policy requires you to comply with the Interagency Guidance, then you do not have to comply with the Indiana Law. And that’s a good thing, because the Interagency Guidance is often more clear and flexible than the state laws.  (Note, these are our our opinions as Certified Information System Auditors and not attorneys or lawyers.)

When Should the Customer Notice be Provided?
The interpretive guidance states that a financial institution should provide a notice to its customers whenever it becomes aware of an incident of unauthorized access to customer information and, at the conclusion of a reasonable investigation, determines that misuse of the information has occurred or it is reasonably possible that misuse will occur.

Customer Notification (also called “Customer Notice.”)
The guidance is clear that notification to the customer must be given in a clear and conspicuous manner. The notice should include the following items:

  • Description of the incident;
  • Type of information subject to unauthorized access;
  • Measures taken by the institution to protect customers from further unauthorized access;
  • Telephone number customers can call for information and assistance; and
  • Remind customers to remain vigilant over next twelve to twenty four months, and report suspected identity theft incidents to the institution.

The guidance encourages financial institutions to notify the nationwide consumer reporting agencies prior to sending notices to a large number of customers that include contact information for the reporting agencies.

Delivery of Customer Notice

Customer notice should be delivered in a manner designed to ensure that a customer can reasonably be expected to receive it. For example, the institution may choose to contact all customers affected by telephone or by mail, or by electronic mail for those customers for whom it has a valid e-mail address and who have agreed to receive communications electronically.

When do we really need to start considering this?

Your Incident Response Plan should articulate a triage process performed by the Information Security Officer (or whomever the task is assigned to.)   The plan should give the ISO authority to classify incidents into “notification incidents” versus “other incidents.”  (Many organizations have a gradation of “other” incidents.)  But the point is, if it is a notification incident, the ISO “pulls the fire alarm” and an Emergency Incident Response Team Meeting is called.

The classification should be based on what type of information was breached.  (Some organizations will include additional factors such as whether the recipient of the information is known and friendly or unknown or unfriendly.)

The guidance itself establishes that customers must be notified whenever “Sensitive Customer Information” is breached.  According to the guidance, ” sensitive customer information means a 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. It also includes any combination of components of customer information that would allow someone to log on to or access the customer’s account, such as user name and password or password and account number. ”

In a real incident, which law you should comply with will ultimately need to be approved by a lawyer.  This is why you should have legal counsel available for emergency incident response team meetings, and this is why you shouldn’t fret too much about it, other than to know the code applicable in your state (and in Indiana it’s Indiana Code 24-4.9), whether that code has exemptions for organizations complying with federal regulations, and then what the exact steps are to achieve the above articulated objectives of the customer notification phase of an incident response.


Original article by Dan Hadaway CRISC CISA CISM. Founder and Managing Partner, infotex

“Dan’s New Leaf” is a “fun blog to inspire thought in the area of IT Governance.”

 


same_strip_012513


 

Latest News
    Another awareness poster for YOUR customers (and users).  Now that we have our own employees aware, maybe it’s time to start posting content for our customers! Download the large versions here: Awareness Poster (Portrait) Awareness Poster (Landscape)   You are welcome to print out and distribute this around your office. Interested in one of ours […]
    Questions about China’s new disclosure laws only highlight the uncertainty about disclosure in general… An article review. China recently made waves in the security world by announcing a new set of data security laws, one of which has added new fuel to a long running debate: how and when should security vulnerabilities be disclosed…and to […]
    Four Conditions … …For Why a Network Can be Anything But a Network! Another one of those Dan’s New Leaf Posts, meant to inspire thought about IT Governance . . . . I have to admit that infotex is being called into engineering meetings with larger organizations these days that are NOT community based banks.  We […]
    Another awareness poster for YOUR customers (and users).  Now that we have our own employees aware, maybe it’s time to start posting content for our customers! Download the large versions here: Awareness Poster (Portrait) Awareness Poster (Landscape)   You are welcome to print out and distribute this around your office. Interested in one of ours […]
    If Zero days need Zero clicks, are there any secure devices in the mix? Tanvee Dhir explores the Pegasus spyware. Another technical post, meant to inspire thought about IT Governance . . . . Introduction Over the past couple of weeks, we have seen multiple stories regarding a powerful piece of spyware called Pegasus sold […]
    Our Lead Non-Technical Auditor takes a look at the new AIO Guidance… Architecture, Infrastructure, and Operations (AIO) is the latest booklet released by the Federal Financial Institutions Examination Council (FFIEC) in their line of  IT Examination Handbooks. It is an update to their 2004 Operations booklet and, as the name implies, expands into the areas […]
    Another awareness poster for YOUR customers (and users).  Now that we have our own employees aware, maybe it’s time to start posting content for our customers! Download the large versions here: Awareness Poster (Portrait) Awareness Poster (Landscape)   You are welcome to print out and distribute this around your office. Interested in one of ours […]
    Many organizations still fail to consider the unique risks posed by cloud computing… An article review. Last month thousands of Western Digital MyCloud device owners learned about the risks of cloud-based solutions the hard way: their data had been wiped remotely due to a flaw in the internet-facing component of their external hard drives. While […]
    infotex does not use Kaseya… We are protecting our Clients! Another blog post meant to inspire thought about IT Governance . . . . To all infotex managed security service Clients: As you may be aware there was a large ransomware attack recently that leveraged a remote management tool called Kaseya that is used by many […]
    While we’re not a news service, we often use current events to comment on trends and our services. This blog is intended to get people thinking about topics and trends in Technology Risk Management, through our article reviews, as well as through original blog articles about current events and our MSSP services (such as our […]