HIPAA Blog

[ Thursday, October 22, 2015 ]

 

Must a BAA require the Business Associate to report unsuccessful Security Incidents?  Yes.

I bring this up because it's a recurring issue for me.  When negotiating BAAs, the BA often says, "We don't need to report unsuccessful Security Incidents; 'Pings' happen all the time and never cause any problem because they never get anywhere.  Asking us to report every ping is burden we can't possible take on."  You know what?  I agree.  HOWEVER, the rules don't.  Look at 45 CFR § 164.314(a)2)(i)(C): “The [business associate agreement ] must provide that the business associate will . . . report to the covered entity any security incident of which it becomes aware, including breaches . . . . “ (Emphasis mine.)  Security incident is defined in 45 CFR § 164.304 as follows: “Security Incident means the attempted or successful unauthorized access, use, disclosure, modification, or destruction or information or interference with system operations in an information system.”  (Emphasis mine.)  A “ping” is clearly an attempted unauthorized access, which means it is a “security incident;” and the BAA provisions say that the BAA must provide that the BA will report all “security incidents.”  The language clearly states that the BAA (or subcontractor BAA, which must meet the same requirements) must require the business associate (or subcontractor) to report “pings.”  In fact, stating that you need NOT report pings is directly contrary with the clear language of the regulations.

This is, obviously, a ridiculous requirement: pings are way too numerous and innocuous to make their reporting anything but a nuisance.  However, reporting them is explicitly called for in the HIPAA regulations.  Since reporting pings is required, I now include it in my BAAs, but minimize the reporting to the barest minimum to still comply with the regulations: a minimal number of reports (no more often than quarterly), with minimal information (a summary statement that “our network system regularly experiences 'pings,' port scans, and similar exploratory contacts, none of which result in a successful access to our system” would be sufficient), and only when requested (which likely will be never).   This complies with the requirements of the regulations but does not unnecessarily burden anyone.

You can also look at the OCR Frequently Asked Questions page.  Go here and search "Security Incident Procedures," and you'll get the answer to this question:

What does the Security Rule require a covered entity to do to comply with the Security Incidents Procedures standard?

The answer mainly deals with what a covered entity must do to respond or react to pings, but the final sentence is telling: "However, § 164.314(a)(2)(i)(C) and (b)(2)(iv) require contracts between a covered entity and a business associate, and plan documents of a group health plan, respectively, to include provisions that require business associates and plan sponsors to report to the covered entity any security incidents of which they become aware." There's that word "any" again. . . .

Jeff [11:26 AM]

Comments:
We get a lot of pushback on this issue. How do you respond to the "but everybody's doing it" argument? I haven't found anything from OCR addressing this specifically.
 
(I'm specifically referring to the trend to include language in the BAA saying "this section constitutes ongoing notice of such unsuccessful attempts and also satisfies any notices necessary by Business Associate to the Covered Entity of the ongoing existence and occurrence of attempted but unsuccessful Security Incidents for which no additional notice to the Covered Entity shall be required.")
 
I'm not sure what the problem is (i.e., which way people are pushing back). The regs say you have to report every Security Incident, which would include unsuccessful ones. Reporting every ping is unrealistic and impossible. Seems like an intractible problem. If someone says, "I'm only reporting successful SIs," they're not compliant with HIPAA. If they say, "you must report every unsuccessful SI," they're imposing an impossible task.

The best way to bridge the gap is to keep the requirement to report all, but either (i) consider the contract itself as an implied report of the unsuccessful SIs that are likely to occur, or (ii) require the report of unsuccessful SIs to only be needed upon request (and to allow a generalized description suffice as the report).
 
Practically speaking, the two options you suggest are comparable. Covered entities aren't going to request these reports anyway. I'm just having trouble wrapping my head around a BAA constituting a report of future events, especially when the regs require reports of security incidents “of which [the business associate] becomes aware,” implying an ongoing prospective obligation.
 
Post a Comment
http://www.blogger.com/template-edit.g?blogID=3380636 Blogger: HIPAA Blog - Edit your Template