US20160021133A1

US20160021133A1 - Systems and methods for managing data incidents

Info

Publication number: US20160021133A1
Application number: US14/868,311
Authority: US
Inventors: Mahmood Sher-Jan; Susan M. Rook; Greg L. Kotka; Andrew Migliore; Travis Cannon; Billie Cleek
Original assignee: Id Experts; Identity Theft Guard Solutions LLC
Current assignee: Radar LLC
Priority date: 2012-02-14
Filing date: 2015-09-28
Publication date: 2016-01-21
Also published as: US9781147B2

Abstract

Systems and methods for managing a data incident are provided herein. Exemplary methods may include providing an external entity interface that receives external entity information including a contract between a first party and at least one additional party, notification obligations that specify when the first party or the at least one additional party notifies entities that a data incident has occurred, and properties that trigger an assessment of the notification obligations. When an incident occurs, an assessment is completed and the results thereof are displayed on a risk assessment guidance interface.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

The present application is a continuation-in-part that claims the benefit and priority of U.S. Non-Provisional patent application Ser. No. 14/588,159 filed on Dec. 31, 2014, which is a continuation-in-part that claims the benefit and priority of U.S. Non-Provisional patent application Ser. No. 14/311,253 filed on Jun. 21, 2014, which is a continuation that claims the benefit and priority of U.S. Non-Provisional patent application Ser. No. 13/691,661 filed on Nov. 30, 2012, now issued as U.S. Pat. No. 8,763,133 on Jun. 24, 2014, which is a continuation that claims the benefit and priority of U.S. Non-Provisional patent application Ser. No. 13/396,558 filed on Feb. 14, 2012, now issued as U.S. Pat. No. 8,707,445 on Apr. 22, 2014, all of which are hereby incorporated by reference herein in their entirety including all references cited therein.

FIELD OF THE TECHNOLOGY

Embodiments of the disclosure relate to information privacy. More specifically, but not by way of limitation, the present technology relates to the management of data incidents. The management of a data incident may comprise conducting an analysis of a data incident data relative to federal and state privacy rules and generating a risk assessment and incident response plan for the data incident. Additionally, the present technology may generate notification schedules and gather/transmit notification information for data incidents having a risk assessment that is indicative of a high level of risk.

BACKGROUND OF THE DISCLOSURE

Data incidents involve the exposure of sensitive information such as personally identifiable information and protected health information to third parties. Data incidents may comprise data breaches, privacy breaches, privacy or security incidents, and other similar events that result in the exposure of sensitive information to third parties. Some of these exposures may be subject to numerous state and federal statutes that delineate requirements that are to be imposed upon the party that was entrusted to protect the data. Personally identifiable information (hereinafter “PII”) and protected health information (PHI) which, regards healthcare related information for individuals that are maintained by a covered entity (e.g., an entity that has been entrusted with the PHI such as a hospital, clinic, health plan, and so forth), may include, but is not limited to, healthcare, financial, political, criminal justice, biological, location, and/or ethnicity information. For purposes of brevity, although each of these types of PII and PHI may have distinct nomenclature, all the aforementioned types information will be referred to herein as PII/PHI.

SUMMARY OF THE DISCLOSURE

According to some embodiments, the present technology may be directed to methods managing a data incident. The methods may comprise: (a) receiving, via a risk assessment server, in response to an occurrence of the data incident, data incident data that comprises information corresponding to the data incident, the data incident further comprising intentional or unintentional release of personally identifiable information to an untrusted environment; (b) automatically generating, via the risk assessment server, a risk assessment from a comparison of the data incident data to privacy rules, the privacy rules comprising: (i) at least one federal rule; (ii) at least one state rule, each of the rules defining requirements associated with data incident notification laws; and (iii) at least one contractual obligation defining contractual requirements of a breaching party due to the data incident, the breaching party being a party to the at least one contractual obligation; (c) providing, via the risk assessment server, the risk assessment to a display device that selectively couples with the risk assessment server; and (d) generating a notification schedule when the comparison indicates that the data incident violates at least one of the at least one federal rule, the at least one state rule, the at least one contractual obligation, or combinations thereof.
According to other embodiments, the present technology is directed to a risk assessment server for managing a data incident. In some instances, risk assessment server may comprise: (a) a memory for storing executable instructions; (b) a processor for executing the instructions; (c) an input module stored in memory and executable by the processor to receive in response to an occurrence of the data incident, data incident data, the data incident data comprising information corresponding to the data incident, the data incident further comprising intentional or unintentional release of personally identifiable information to an untrusted environment; (d) a risk assessment generator stored in memory and executable by the processor to generate a risk assessment from a comparison of the data incident data to privacy rules, the privacy rules comprising: (i) at least one federal rule; (ii) at least one state rule, each of the rules defining requirements associated with data incident notification laws; and (iii) at least one contractual obligation defining contractual requirements of a breaching party due to the data incident, the breaching party being a party to the at least one contractual obligation; (e) a user interface module stored in memory and executable by the processor to provide the risk assessment to a display device that selectively couples with the risk assessment server; and (f) a notification module generating a notification schedule when the comparison indicates that the data incident violates at least one federal rule, the at least one state rule, the at least one contractual obligation, or combinations thereof.
According to some embodiments, the present technology is directed to a method for managing a data incident, comprising: (a) receiving, via a risk assessment server, in response to an occurrence of the data incident, data incident data that comprises information corresponding to the data incident, the data incident further comprising intentional or unintentional release of personally identifiable information to an untrusted environment; (b) automatically generating, via the risk assessment server, a risk assessment from a comparison of the data incident data to privacy rules, the privacy rules comprising: (i) at least one federal rule; (ii) at least one state rule, each of the rules defining requirements associated with data incident notification laws; and (iii) at least one contractual obligation defining contractual requirements of a breaching party due to the data incident, the breaching party being a party to the at least one contractual obligation; (c) providing, via the risk assessment server, the risk assessment to a display device that selectively couples with the risk assessment server; (d) receiving one or more selections of one or more states; (e) selecting one or more state statutes based upon the one or more selections; (f) generating at least one state rule based upon a selected state statute; and (g) generating a notification schedule when the comparison indicates that the data incident violates at least one of the at least one federal rule, the at least one state rule, the at least one contractual obligation, or combinations thereof.
According to some embodiments, the present technology is directed to a risk assessment server for managing a data incident, the server comprising: (a) a memory for storing executable instructions; (b) a processor for executing the instructions; (c) an input module stored in memory and executable by the processor to receive in response to an occurrence of the data incident, data incident data, the data incident data comprising information corresponding to the data incident, the data incident further comprising intentional or unintentional release of personally identifiable information to an untrusted environment; (d) a risk assessment generator stored in memory and executable by the processor to generate a risk assessment from a comparison of the data incident data to privacy rules, the privacy rules comprising: (i) at least one federal rule; (ii) at least one state rule, each of the rules defining requirements associated with data incident notification laws; and (iii) at least one contractual obligation defining contractual requirements of a breaching party due to the data incident, the breaching party being a party to the at least one contractual obligation; (e) a user interface module stored in memory and executable by the processor to provide the risk assessment to a display device that selectively couples with the risk assessment server; and (f) a rule generator stored in memory and executable by the processor to: (1) generate the at least one federal rule from a federal statute that governs privacy breaches relative to protected health information (PHI); or (2) generate the at least one state rule from a state statute that governs privacy breaches relative to at least one of personally identifiable information (PII), PHI, or combinations thereof; and further comprising a notification module generating a notification schedule when the comparison indicates that the data incident violates at least one of the at least one federal rule, the at least one state rule, the at least one contractual obligation, or combinations thereof.
According to some embodiments, the present technology is directed to a method for managing a data incident, comprising: (a) receiving, via a risk assessment server, in response to an occurrence of the data incident, data incident data that comprises information corresponding to the data incident, the data incident further comprising intentional or unintentional release of personally identifiable information to an untrusted environment; (b) determining at least one contractual obligation existing between two or more parties, the at least one contractual obligation defining contractual requirements of a breaching party due to the data incident, the breaching party being one of the two or more; (c) automatically generating, via the risk assessment server, a risk assessment for the breaching party using a comparison of the data incident data to privacy rules, the privacy rules comprising at least one of: (i) at least one federal rule; (ii) at least one state rule, each of the rules defining requirements associated with data incident notification laws; and (iii) the at least one contractual obligation; (d) providing, via the risk assessment server, the risk assessment to a display device that selectively couples with the risk assessment server; and (e) generating a notification schedule when the comparison indicates that the data incident violates at least one of the at least one federal rule, the at least one state rule, the at least one contractual obligation, or combinations thereof.
According to some embodiments, the present technology is directed to a method performed by a risk assessment server that comprises a processor and memory for storing instructions, the processor executing the instructions to perform the method, the method comprising: (a) creating an incident record for a data incident, the data record includes information regarding the data incident; (b) selecting one or more roles for each party involved in the data incident, wherein any party can be assigned two or more roles for the data incident based on a contractual relationship with the party and another party; (c) automatically generating a risk assessment from a comparison of the data incident to the privacy rules; and (d) generating a notification schedule for each party to the data incident that is based on the role or roles for the party when a comparison of the privacy rules to the data incident indicates that the data incident violates at least one of the at least one federal rule, the at least one state rule, the at least one contractual obligation, or combinations thereof.
In one embodiment, a method includes: (a) providing an external entity interface that receives: (i) external entity information comprising: (1) a contract between a first party and at least one additional party; (2) notification obligations that specify when the first party or the at least one additional party notifies entities that a data incident has occurred; and (3) properties that trigger an assessment of the notification obligations; (b) receiving, via a risk assessment server, in response to an occurrence of the data incident, data incident data that comprises information corresponding to the data incident, the data incident further comprising intentional or unintentional release of personally identifiable information to an untrusted environment by the first party or the at least one additional party; (c) comparing the data incident data to the properties that trigger an assessment; (d) wherein if the properties indicate that an assessment is required, generating, via the risk assessment server, a risk assessment from a comparison of the data incident data to privacy rules, the privacy rules comprising: (I) at least one federal rule; (II) at least one state rule, each of the rules defining requirements associated with data incident notification laws; and (III) the contract; (e) providing, via the risk assessment server, the risk assessment to a display device that selectively couples with the risk assessment server; and (f) generating a risk assessment guidance interface when the comparison indicates that the data incident violates at least one of the at least one federal rule, the at least one state rule, the contract, or combinations thereof.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, where like reference numerals refer to identical or functionally similar elements throughout the separate views, together with the detailed description below, are incorporated in and form part of the specification, and serve to further illustrate embodiments of concepts that include the claimed disclosure, and explain various principles and advantages of those embodiments.

The methods and systems disclosed herein have been represented where appropriate by conventional symbols in the drawings, showing only those specific details that are pertinent to understanding the embodiments of the present disclosure so as not to obscure the disclosure with details that will be readily apparent to those of ordinary skill in the art having the benefit of the description herein.

FIG. 1 illustrates an exemplary system for practicing aspects of the present technology;

FIG. 2 illustrates an exemplary conversion application for managing data incidents;

FIG. 3 illustrates an exemplary GUI in the form of a data incident details page;

FIG. 4 illustrates an exemplary GUI in the form of a data incident dashboard;

FIG. 5 illustrates an exemplary GUI in the form of a state specific risk assessment selection and notification page;

FIG. 6 illustrates an exemplary GUI in the form of a data sensitivity level evaluation and selected federal and state specific risk assessments page;

FIG. 7 illustrates an exemplary GUI in the form of a federal risk assessment page;

FIG. 8 illustrates an exemplary GUI in the form of a state specific risk assessment page;

FIG. 9 illustrates an exemplary GUI in the form of a statute summary page;

FIG. 10 illustrates an exemplary GUI in the form of an aggregated notification schedules page;

FIGS. 11-13 illustrate exemplary GUIS that are utilized to collect, store, and transmit pertinent documents or data;

FIG. 14 is a flowchart of an exemplary method for managing a data incident; and

FIG. 15 illustrates an exemplary computing device that may be used to implement embodiments according to the present technology.

FIG. 16 is a flowchart of a method for managing a data incident, the method including at least one contractual obligation.

FIG. 17 is a flowchart of a method for managing a data incident involving parties with different roles.

FIG. 18 is a table of various party roles (properties), party types/relationships, and internal/external notifications.

FIG. 19 is a flowchart of a method for external entity workflow for a data incident.

FIG. 20 is a graphical user interface in the form of an external entity incident input screen where a party, contract, notification, and additional details are input into the risk assessment server.

FIG. 21 is a graphical user interface that provides a list of external entities.

FIG. 22 is a graphical user interface that displays a summary of an incident, as well as detailed information for one or more external entities impacted by a data incident.

FIG. 23 is a graphical user interface that provides detailed information regarding a data incident.

FIG. 24 is a graphical user interface that provides yet additional details regarding the data incident in addition to those provided in FIG. 23.

FIGS. 25-35 collectively illustrate various example features that can be implemented within the risk assessment server. The features are listed in tabular format.

DETAILED DESCRIPTION

In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the disclosure. It will be apparent, however, to one skilled in the art, that the disclosure may be practiced without these specific details. In other instances, structures and devices are shown at block diagram form only in order to avoid obscuring the disclosure.
Generally speaking, the present technology may be directed to managing data incidents. It will be understood that the terms “data incident” may be understood to encompass privacy incidents, security incidents, privacy breaches, data breaches, data leaks, information breaches, data spills, or other similarly related events related to the intentional or unintentional release of protected information to an untrusted environment. This protected information may be referred to as personally identifiable information (hereinafter “PII/PHI”) or protected health information (e.g., an entity that has been entrusted with the PHI such as a hospital, clinic, health plan, and so forth).
PII/PHI may encompass a wide variety of information types, but non-limiting examples of PII comprise an individual's full name, a date of birth, a birthplace, genetic information, biometric information (face, finger, handwriting, etc.), national identification number (e.g., social security), vehicle registration information, driver's license numbers, credit card numbers, digital identities, and Internet Protocol addresses.
Other types of information may, in some instances, be categorized as PII/PHI, such as an individual's first or last name (separately), age, residence information (city, state, county, etc.), gender, ethnicity, employment (salary, employer, job description, etc.), and criminal records—just to name a few. It is noteworthy to mention that the types of information that are regarded as PII are subject to change and therefore may include more or fewer types of information that those listed above. Additionally, what constitutes PII/PHI may be specifically defined by a local, state, federal, or international data privacy laws.
While entities that are subject to these privacy laws may be referred to in a variety of ways, for consistency and clarity an entity (either individual or corporate) that is entrusted with PII/PHI will hereinafter be referred to as an “entrusted entity.”
It will be understood that the privacy laws contemplated herein may comprise details regarding not only how an entrusted entity determines if a data incident violates the law, but also when the provision of notification to one or more privacy agencies and/or the customers of the entrusted entity is warranted.
According to some embodiments, the present technology is directed to generating risk assessments for data incidents. These risk assessments provides specific information to the entrusted entity regarding the severity of the data incident relative to a state or federal rule. Additionally, the risk assessment provides information regarding the data sensitivity for the data incident. That is, the risk assessment may determine if the type of data that was exposed is highly sensitive information. As mentioned before, some PII/PHI may be considered more sensitive than others. For example, a social security number may be more sensitive than a gender description, although the relative sensitivity for different categories of PII/PHI are typically delineated in the privacy rules and may require delineation in the context of each data incident.
The present technology may determine the severity and/or data sensitivity for a data incident by collecting data incident data from an entrusted entity. This data incident data may be compared against one or more selected privacy rules to determine the severity and/or data sensitivity for the data incident. In some instances, the present technology may model the data incident data to the one or more privacy rules.
According to some embodiments, the privacy rules described herein may comprise the content of a state and/or federal statute. In other embodiments, the privacy rules may comprise abstracted or mathematically expressed rules that have been generated from the text of the state and/or federal statute. Applying a privacy rule to the data incident data may yield values for the severity and/or the data sensitivity of the data incident.
In some embodiments, the risk assessment may provide indication to the entrusted entity that an obligation has occurred. More specifically, if the severity of the data incident and/or the data sensitivity of the data incident when compared to the privacy rules indicates that the data incident has violated at least one of the privacy rules, the risk assessment may include an indication that an obligation has been created. An obligation may require the entrusted entity to notify subjected individuals that their PII/PHI has been potentially exposed. The obligation may also require that notification be provided to a regulating authority such as the department of Health and Human Services (HHS), Office for Civil Rights (OCR), Federal Trade Commission, a state agency, or any agency that regulates data incident notification.
The present technology allows entrusted entities to model data incident data to privacy rules which include at least one state rule and at least one federal rule. In some instances, entrusted entities may model data incidents to the rules of several states to generate risk assessments of each of the states. This is particularly helpful when entrusted entities service customers in many states. Moreover, each of these states may have differing notification requirements, along with different metrics for determining when a data incident requires notification.
In some embodiments, the risk assessment may include a risk level that is associated with a color. More specifically, a hue of the color is associated with the severity of the data incident as determined by the comparison or modeling if the data incident data.
According to the present disclosure, the present technology may generate a notification schedule for an entrusted entity along with mechanisms that aid the entrusted entity in gathering pertinent information that is to be provided to the customer and/or one or more regulator agencies.
These and other advantages of the present technology will be described in greater detail with reference to the collective FIGS. 1-15.
FIG. 1 illustrates an exemplary system 100 for practicing aspects of the present technology. The system 100 may include a risk assessment system, hereinafter “system 105” that may be implemented in a cloud-based computing environment, or as a web server that is particularly purposed to manage data incidents.
In general, a cloud-based computing environment is a resource that typically combines the computational power of a large grouping of processors and/or that combines the storage capacity of a large grouping of computer memories or storage devices. For example, systems that provide a cloud resource may be utilized exclusively by their owners; or such systems may be accessible to outside users who deploy applications within the computing infrastructure to obtain the benefit of large computational or storage resources.
The cloud may be formed, for example, by a network of web servers, with each web server (or at least a plurality thereof) providing processor and/or storage resources. These servers may manage workloads provided by multiple users (e.g., cloud resource customers or other users). Typically, each user places workload demands upon the cloud that vary in real-time, sometimes dramatically. The nature and extent of these variations typically depend on the type of business associated with the user.
In other embodiments, the system 105 may include a distributed group of computing devices such as web servers that do not share computing resources or workload. Additionally, the system 105 may include a single computing device, such as a web server, that has been provisioned with one or more programs that are utilized to manage data incidents.
End users may access and interact with the system 105 via the client device 110 through a web-based interface, as will be discussed in greater detail infra. Alternatively, end users may access and interact with the system 105 via a downloadable program that executes on the client device 110. The system 105 may selectively and communicatively couple with a client device 110 via a network connection 115. The network connection 115 may include any one of a number of private and public communications mediums such as the Internet.
Additionally, the system 105 may collect and transmit pertinent information to regulatory agencies, such as regulatory agency 120, as will be discussed in greater detail infra. In some instances, notification may also be provided to affected individuals 125.
The system 105 may be generally described as a mechanism for managing data incidents. The system 105 may manage a data incident by collecting data incident data for the data incident and then modeling the data incident data to privacy rules. As mentioned previously, the privacy rules may include at least one state rule and at least one federal rule. The modeling of the data incident data may be utilized to generate a risk assessment for the data incident. The risk assessment may be utilized by an entrusted entity to determine how best to respond to the data incident. The system 105 is provided with a risk assessment application 200 that will be described in greater detail with reference to FIG. 2.
FIG. 2 illustrates a risk assessment application, hereinafter referred to as application 200. In accordance with the present disclosure, the application 200 may generally include a user interface module 205, an input module 210, a risk assessment generator 215, a notification module 220, and a reporting module 225. It is noteworthy that the application 200 may include additional modules, engines, or components, and still fall within the scope of the present technology. Moreover, the functionalities of two or more modules, engines, generators, or other components may be combined into a single component.
As used herein, the terms “module,” “generator,” and “engine” may also refer to any of an application-specific integrated circuit (“ASIC”), an electronic circuit, a processor (shared, dedicated, or group) that executes one or more software or firmware programs, a combinational logic circuit, and/or other suitable components that provide the described functionality. In other embodiments, individual modules of the application 200 may include separately configured web servers. Also, the application 200 may be provisioned with a cloud.
Generally described, the application 200 allows entrusted entities to input data incident data, have one or more risk assessments generated, and receive the one or more risk assessments, along with notifications schedules, as required.
An entrusted entity may interact with the application 200 via a graphical user interface that is provisioned as a web-based interface. The web-based interface may be generated by the user interface module 205. It will be understood that the user interface module 205 may generate a plurality of different graphical user interfaces that allow individuals associated with the entrusted entity (e.g., privacy officer, compliance officer, security officer, attorney, employee, agent, etc.) to utilize interact with the application 200. Examples of graphical user interfaces that are generated by the user interface module 205 are provided in FIGS. 3-13, which will be described in greater detail infra.
Upon the occurrence of a data incident, the input module 210 may be executed to receive data incident data from the entrusted entity. It is noteworthy that the user interface module 205 may generate different types of graphical user interfaces that are tailored to obtain specific types of data incident data from the entrusted entity.
Initially, it may be desirous for the entrusted entity to establish a profile that may be utilized to determine if the entity that is using the application 200 is, in fact, an entrusted entity. It is noteworthy that to mention that the determination of what entities are entrusted entities depends upon the privacy rule. For example, an entity may be considered to be an entrusted entity under a particular federal statute, but may not be labeled an entrusted entity under one or more state statutes. Likewise, different states may have discrepant methods for determining who constitutes an entrusted entity.
Therefore, it may be advantageous to determine information about the entity such as what types of information they collect and where they conduct business. The input module 210 may be executed to solicit pertinent information from the entity that may be utilized to determine if the entity is an entrusted entity. Again, the entity may specify a plurality of states in which they conduct business, or the states of residence/domicile for customers with which they conduct business.
If it is determined that the entity is an entrusted entity, the input module may further solicit data incident data for one or more data incidents. Pertinent data incident data may include the type of data that was compromised, the date of compromise, the amount of data that was compromised, were there security measures in place (e.g., encryption, redaction, etc.), was the incident intentional or unintentional, was the incident malicious or non-malicious, how the data was compromised (e.g., theft of laptop, database security failure, lost storage media, hacked application, hacked computing device (e.g., web server, email server, content repository, etc.), and other types of information that assist in determining a risk level for the data incident as well as any notification obligations.
In some instances, rather than soliciting generalized data incident data from the entrusted entity, the input module 210 may select questions that solicit data that is particularly relevant to the privacy rules to which the entrusted entity is subject. For example, if a privacy rule specifies that a threshold amount of records must be exposed in order to create an obligation, the end user may be asked if their amount of exposed records meets or exceeds that threshold amount. This type of tailored questioning narrows the analysis that is performed of the data incident data and improves the efficiency of the risk assessment process.
Once the data privacy data has been received, the input module 210 may generate a summary of the data privacy data (or at least a portion of the data) that is provided to the entrusted entity via a graphical user interface generated by the user interface module 205.
The input module 210 may be configured to solicit confirmation from the entrusted entity that the data privacy data in the summary is correct. If the data is incorrect, the entrusted entity may go back and correct the errant data.
As mentioned briefly above, the input module 210 may solicit and receive one or more selections of one or more states from the entrusted entity. Using the selections, the input module 210 may select one or more state statutes based upon the one or more selections. Also, the input module 210 may generate at least one state rule for each selected state statute. Additionally, one or more federal rules may be selected and generated as well.
The input module 210 may generate a state or federal privacy rule by evaluating the state/federal statute and creating a plurality of qualifications from the statutes. Qualifications for a statute may include, for example, thresholds or formulas that are used to determine if the data incident data of a data incident violates the statute. Stated otherwise, these qualifications may be used as a mathematical model of a statute. Data incident data may be evaluated in light of the model. The resultant modeling may be used to generate a risk assessment for the data incident.
The risk assessment generator 215 may be executed to generate one or more risk assessments for the data incident. The risk assessment generator 215 may model the data incident data to the selected or determined privacy rules to determine if an obligation has been triggered under a privacy rule.
Again, risk assessments may be generated by modeling the data incident data to at least one state rule and at least one federal rule. The risk assessment may combine risk levels for each rule into a single risk assessment, or individual risk assessments may be generated for each rule.
Modeling of the data incident data to a privacy rule (either state or federal) by the risk assessment generator 215 may result in the generation of a severity value and a data sensitivity value for the data incident. The severity value may represent the extent to which PII/PHI has been compromised, while the data sensitivity value may represent the relative sensitivity of the PII/PHI that was compromised. These two factors may independently or dependently serve as the basis for determining if a notification obligation exists. For example, if the severity value meets or exceeds a threshold amount, a notification obligation may exist. If the data sensitivity value meets or exceeds a threshold amount, a notification obligation may exist. In some instance, a notification obligation may only exist if the sensitivity value and the data sensitivity value both exceed threshold amounts. Again, the threshold amounts are specified by the particular privacy rule that is being applied to the data incident data.
The risk assessment generator 215 may also determine and apply exceptions that exist in a state or federal statute during the generation of a risk assessment. These exceptions may be noted and included in the risk assessment.
The risk assessment generator 215 may create a visual indicator such as a risk level or heat map that assists the entrusted entity in determining if a data incident is relatively severe or is relatively benign. This visual indicator may be included in the risk assessment. For example, a risk assessment may include a risk level that includes a visual indicator such as a colored object. In some embodiments, a hue of the object is associated with the severity of the data incident where red may indicate a severe risk and green may indicate a benign risk, with orange or yellow hues falling somewhere therebetween. Examples of heat maps and risk levels indicators are illustrated in FIG. 7.
Included in the risk assessment, in some instances, is a summary of sections of the state or federal privacy statute. For example, with regard to a state specific assessment, the risk assessment generator 215 may generate an outline of key information about the state statute that was utilized to generate the state specific risk assessment. This outline may be displayed to the entrusted entity via a user interface.
If the risk assessment generator 215 determines that the data incident violates one or more statutes (e.g., high severity value, PII/PHI is very sensitive, etc.), the notification module 220 may be executed to generate a notification schedule. The notification schedule may be generated based upon a data associated with the data incident. That is, the statute may specify when notification is to occur, relative to the date that PII was exposed.
Additionally, the notification schedule informs the entrusted entity as to what types of information are to be provided, along with the regulatory bodies to which the information should be provided. Again, the notification schedule may be generated from the statute itself. For example, a statute may specify that the data incident data (or a portion of the data incident data) collected by the input module 210 should be provided to a particular state agency within a predetermined period of time. Again, if a plurality of states have been designated or selected, the notification schedule may include notification dates for each state agency.
To assist the entrusted entity in meeting their notification obligations, the reporting module 225 may be executed to gather pertinent documents or other information from the entrusted entity and transmit these documents to the required reporting authorities. The reporting module 225 may prompt the entrusted entity to attach documents via a user interface. Once attached, these documents/data may be stored in a secured repository for submission to regulatory agency. In other instances, the entrusted entity may transmit required information directly to the regulatory agency.
Additionally, the reporting module 225 may provide required notifications to affected individuals, such as the individuals associated with the PII/PHI that was compromised.
FIGS. 3-13 illustrate various exemplary graphical user interfaces (GUI) that are generated by the user interface module 205. Each of the exemplary user interfaces will be described below.
FIG. 3 illustrates an exemplary GUI in the form of a data incident summary page. The summary page 300 includes a plurality of received answers to questions that were provided to the entrusted entity. Responses that were received indicate that the data incident involved the loss of a cellular telephone, an incident date of Jan. 2, 2012, an incident discover date of Jan. 16, 2012, and other pertinent data incident data.
FIG. 4 illustrates an exemplary GUI in the form of a data incident dashboard page 400. The page 400 includes listing of pending and completed risk assessments for a plurality of data incidents. Each entry may include a risk indicator having a particular color to help the entrusted entity in quickly determining data incidents that are high risk. A risk indicator may be associated with a particular privacy rule. For example, a risk indicator for an Employee Snooping data incident indicates that a moderately high risk is associated with the data incident relative to HITECH rules (e.g., rules associated with the compromise of PHI). This moderately high risk is indicated by a yellow dot placed within a row of a “HITECH Status” column. Additionally, a severe risk is associated with a state privacy rule. This severe risk is indicated by a red dot placed within a row of a “State Impact” column.
FIG. 5 illustrates an exemplary GUI in the form of a state specific selection and notification page 500. The notification page is shown as comprising an image that informs the trusted entity that six states have been affected by the data incident. To view a risk assessment for each state, the trusted entity may click on any of the stated listed in the leftmost frame.
FIG. 6 illustrates an exemplary GUI in the form of a data sensitivity level evaluation page 600. The page includes a plurality of data sensitivity indicators the sensitivity for different types of PII/PHI that were compromised by the data incident. For example, medical record numbers are shown in red as being highly sensitive. Moreover, medical record numbers may pose financial, reputational, and medical harm, which are just some of the dimensions of potential harm caused by compromise of PII/PHI. In contrast, the data incident also compromised individual's date of birth. As determined by entrusted entity, that type of PII/PHI is not considered highly sensitive and thus, has been depicted in green.
FIG. 7 illustrates an exemplary GUI in the form of a risk assessment page 700. The risk assessment page 700 includes a heat map 705 and corresponding risk level indicator 715, which is placed within the heat map 705. The heat map 710 includes a grid where vertical placement indicates data sensitivity level and horizontal placement indicates severity level. As is shown, as the sensitivity and severity levels increase, so do the odds that the data incident may trigger an obligation to notify affected parties. In this instance, the risk level is high because the sensitivity level is high and the severity level is extreme.
Positioned below the heat map 705 is a notification schedule that includes not only the obligations for the entrusted entity, but also the expected notification dates. Again, this schedule may be based upon requirements included in the violated statute.
FIG. 8 illustrates an exemplary GUI in the form of a state specific risk assessment page 800. The page 800 includes a risk assessment for the State of California. The state impact is shown as high and a summary of the types of PII/PHI that were exposed are summarized below the state impact indicator. Similarly to the risk assessment page 700 of FIG. 7, a notification schedule is included on the state specific risk assessment page 800. It is noteworthy that a state specific risk assessment page may be generated for each affected state (such as the affected states listed on the state specific selection and notification page 500 of FIG. 5.
FIG. 9 illustrates an exemplary GUI in the form of a statute summary page 900. The statute summary page 900 includes a copy (or a portion) of the privacy statutes (California Civil Code 1798.29 & 1798.82; California Health and Safety Code 1280.15) that were utilized to generate the state specific risk assessment that was provided on in FIG. 8. Note that the summary also includes whether the state statutes include harm test and exceptions which are flagged by the risk assessment generator 215 according to the specific privacy statutes.
FIG. 10 illustrates an exemplary GUI in the form of an aggregated notification page 1000. The page 1000 includes a notification schedule for each affected privacy statues (e.g., federal and state(s)) relative to one or more data incidents. A list of notification events is provided and the end user may utilize the check boxes to select which states (or federal) risk assessment notification schedules are displayed.
FIGS. 11-13 illustrate exemplary GUIS that are utilized to collect, store, and transmit pertinent documents or data. FIG. 11 illustrates an attachments page 1100 that shows a plurality of documents that have been uploaded to the system such as media notification, attorney general notification, privacy policy, and corrective action plan. Positioned adjacent to the list of documents is a checklist that includes all the pertinent documentation that is to be provided to regulatory authorities, the media, and/or affected individuals. As the required data are uploaded, each required data category is noted with a green check mark. Missing elements can be easily determined and uploaded.
It is noteworthy to mention that the on-time reporting of required incident data may be paramount in determining compliance and good faith on the part of an entrusted entity. Consequently, failure to meet required notification deadlines may result in fines and other regulatory punishment.
FIG. 12 illustrates an upload page 1200 that may be utilized by an entrusted entity to upload and categorize required compliance information (e.g., documents shown in FIG. 11). Files may be tagged with metadata linking them to the related federal and states risk assessments before they are stored in a content repository or transmitted to an appropriate party.
FIG. 13 illustrates an exemplary time stamped notation and actions page 1300 that displays notes entered into the system by a particular end user. Actions may include a note that a particular employee is to be retrained and certified. Any type of related action such as a remedial action, uploading of a file, or other notification and/or compliance related action may be noted and associated with a particular risk assessment.
FIG. 14 illustrates a flowchart of an exemplary method for managing a data incident. The method may include a step 1405 of receiving data incident data. The data incident data may include information that pertains or corresponds to the data incident. Also, the method may include a step 1410 of automatically generating a risk assessment from a comparison of data incident data to privacy rules. The privacy rules may comprise at least one federal rule and at least one state rule, where each of the rules defining requirements associated with data incident notification laws. Additionally, the comparison may include modeling the data incident data against privacy rules. Also, the method may include a step 1415 of providing the risk assessment to a display device that selectively couples with a risk assessment server. It is noteworthy to mention that the risk assessment may include a visual representation of the risk associated with a data incident relative to the privacy rules.
Additionally, for data incidents that violate a privacy rule (either state or federal) the method may include a step 1420 of generating a notification schedule for the data incident, along with an optional step 1425 of transmitting notification information to a regulatory agency and/or affected individuals (e.g. those who's PII/PHI has been compromised).
FIG. 15 illustrates an exemplary computing device 1500 that may be used to implement an embodiment of the present technology. The computing device 1500 of FIG. 15 (or portions thereof) may be implemented in the context of system 105 (FIG. 1). The computing device 1500 of FIG. 15 includes one or more processors 1510 and main memory 1520. Main memory 1520 stores, in part, instructions and data for execution by processor 1510. Main memory 1520 may store the executable code when in operation. The system 1500 of FIG. 15 further includes a mass storage device 1530, portable storage medium drive(s) 1540, output devices 1550, user input devices 1560, a graphics display 1570, and peripheral devices 1580.
The components shown in FIG. 15 are depicted as being connected via a single bus 1590. The components may be connected through one or more data transport means. Processor unit 1510 and main memory 1520 may be connected via a local microprocessor bus, and the mass storage device 1530, peripheral device(s) 1580, portable storage device 1540, and display system 1570 may be connected via one or more input/output (I/O) buses.
Mass storage device 1530, which may be implemented with a magnetic disk drive or an optical disk drive, is a non-volatile storage device for storing data and instructions for use by processor unit 1510. Mass storage device 1530 may store the system software for implementing embodiments of the present invention for purposes of loading that software into main memory 1520.
Portable storage device 1540 operates in conjunction with a portable non-volatile storage medium, such as a floppy disk, compact disk, digital video disc, or USB storage device, to input and output data and code to and from the computing device 1500 of FIG. 15. The system software for implementing embodiments of the present invention may be stored on such a portable medium and input to the computer device 1500 via the portable storage device 1540.
Input devices 1560 provide a portion of a user interface. Input devices 1560 may include an alphanumeric keypad, such as a keyboard, for inputting alpha-numeric and other information, or a pointing device, such as a mouse, a trackball, stylus, or cursor direction keys. Additionally, the computing device 1500 as shown in FIG. 15 includes output devices 1550. Suitable output devices include speakers, printers, network interfaces, and monitors.
Display system 1570 may include a liquid crystal display (LCD) or other suitable display device. Display system 1570 receives textual and graphical information, and processes the information for output to the display device.
Peripherals 1580 may include any type of computer support device to add additional functionality to the computer system. Peripheral device(s) 1580 may include a modem or a router.
The components provided in the computing device 1500 of FIG. 15 are those typically found in computer systems that may be suitable for use with embodiments of the present invention and are intended to represent a broad category of such computer components that are well known in the art. Thus, the computing device 1500 of FIG. 15 may be a personal computer, hand held computing device, telephone, mobile computing device, workstation, server, minicomputer, mainframe computer, or any other computing device. The computer may also include different bus configurations, networked platforms, multi-processor platforms, etc. Various operating systems may be used including Unix, Linux, Windows, Macintosh OS, Palm OS, Android, iPhone OS and other suitable operating systems. The computing device 1500 may also utilize web browser applications that display the web-based graphical user interfaces described herein. Exemplary web browser applications may include, but are not limited to, Internet Explorer, Firefox, Safari, Chrome, and other web browser applications that would be known to one of ordinary skill in the art with the present disclosure before them. Moreover, when the computing device 1500 is a mobile computing device, the computing device 1500 may likewise include mobile web browser applications.
It is noteworthy that any hardware platform suitable for performing the processing described herein is suitable for use with the technology. Computer-readable storage media refer to any medium or media that participate in providing instructions to a central processing unit (CPU), a processor, a microcontroller, or the like. Such media may take forms including, but not limited to, non-volatile and volatile media such as optical or magnetic disks and dynamic memory, respectively. Common forms of computer-readable storage media include a floppy disk, a flexible disk, a hard disk, magnetic tape, any other magnetic storage medium, a CD-ROM disk, digital video disk (DVD), any other optical storage medium, RAM, PROM, EPROM, a FLASHEPROM, any other memory chip or cartridge.
The embodiments described above consider the effect(s) of state and/or federal laws on a data incident, and specifically what types of obligations arise in view of these laws. The embodiments also consider the generating a notification schedule in light of the obligations imposed upon a breaching party.
The present technology can also be extended to consider not only local, state, federal, international laws, as well as combinations thereof, but also the impact of contractual obligations on a breaching party.
In some embodiments, the present technology can evaluate and apply three separate and types of obligations. The first type of obligations arise from the application of state law to a data incident. The application of the first type of obligations results in the imposition of a first set of obligations for a breaching party. The second type of obligations arise from the application of federal law to a data incident. The application of the second type of obligations results in the imposition of a second set of obligations for a breaching party.
The third type of obligations arise from the application of contractual obligations to a data incident. The application of the third type of obligations results in the imposition of a third set of obligations to a breaching party.
According to some embodiments, each of the first set, second set, and third set of obligations are different from one another. That is, each set of obligations will impose a unique obligation or set of obligations on the breaching party, which are different from the other sets of obligations. For example, a third set of obligations imposed by a contractual obligation comprises a requirement of a rapid email notification to all business customers within 24 hours of a data incident. While state and federal laws will have their own obligations, the state and federal laws will not have this obligation.
While a breaching party is generally defined as a party that has obligations imposed on it due to a data incident, in the context of a contractual obligation, a breaching party is one of at least two or more parties to a contractual obligation. This breaching party is the subject of a data incident. For example, a contract exists between a data owner and a data custodian, who are both parties to a contractual obligation. The contractual obligation specify certain obligations relating that are in addition to, or in excess of, the state or federal rules that dictate obligations in light of a data incident/breach.
In general, the present technology can be used to create response plans involving data incidents where parties to the data incident have hybrid roles. For example, the parties could include a covered entity and a business associated of the covered entity. The present technology provides workflow management that allows an entity to manage its state and federal regulatory obligations as well as its contractual obligations stemming from a data incident involving data that is owned by the entity, as well as data that is being processed or maintained by a second entity on behalf of the entity's clients.
Whereas state and federal obligations are imposed on any party that is involved in a data incident via statute or law, a contractual obligation relating to data privacy involves obligations that are imposed by contract onto one or more of the parties to the contract.
A data owner, a data maintainer, a data steward, and a data custodian are to be understood in terms of their relationship or role relative to a set of data that is the subject of a data incident. A data owner is a party that has complete legal rights over a set of data. The data owner also has rights in use, acquisition, distribution, destruction of this data—just to name a few. A data custodian controls authorization for access data, interpreting data security policies, data versioning control, and so forth. A data steward is responsible for data elements, controlling both data content and metadata, as well as usage consistency, data conflict resolution, and so forth. The data custodian and data steward work together to preserve data security of the set of data. The roles of a data custodian and a data steward will be construed in accordance with data governance rules applied between the parties to the contractual obligation.
It will be understood that multiple parties involved in a data incident can have obligations imposed upon them. Thus, in some instances only one party in a data incident is obligated with notification requirements. In other embodiments, multiple parties can be imposed with obligations due to a data incident.
In the context of HIPPA, in one embodiment a first party is a covered entity and a second party is a business associate of the covered entity. If a data incident occurs, regardless of the fault of any given party, both the covered entity and the business associate are subject to notification obligations. Due to the respective roles, the obligations for each party can be different. The state and federal laws can have obligations that are imposed on each party and these obligations can be different from one another.
Also, the covered entity and the business associate can have an executed contractual agreement that defines contractual obligations for the parties. For example, a covered entity can employ a business associate to carry out its administrative functions related to the provision of healthcare services. To allow for this sharing of duties, HIPPA rules require that a written agreement be in place between the covered entity and the business associate. This agreement clearly defines the duties of the parties that are to be performed under the contract as well as obligations imposed on both the parties as required under HIPPA/HITECH laws.
For context, the definitions of both a covered entity and a business associate are defined in 45 CFR 160.103, which is cited herein and incorporated by reference.
While the above example references parties such as a covered entity and a business associate with respect to HIPPA/HITECH obligations, the present technology can apply any contractual provision that imposes obligations on a party to the contract in the event of a data incident.
In one embodiment, a covered entity could include a hospital group that services patients. A business associate of the hospital group could include a billing and accounting service that has access to patient information. The accounting service provides a business function to the hospital and encounters potential or actual PII or PHI. A service agreement is established between the hospital group and the accounting service and this agreement includes several provisions that deal with how PII and PHI are to be maintained by the accounting service. The service agreement also includes notification obligations that specify how the accounting service should handle notifications to the covered entity or patients in response to a data incident.
In another embodiment, a doctor's group which operates out of the hospital would be considered a covered entity with respect to its patients. The hospital group would be a business associate of the doctor's group that uses the hospital facilities.
The obligations found in a service agreement can be manually into the risk assessment server by one or more parties. In another embodiment, the service agreement can be uploaded to the risk assessment server and the risk assessment server can extract relevant obligations from the service agreement relating to data incident obligations. Additionally, an identification of a role for each party to the agreement can be made. In this, the risk assessment sever can efficiently identify notification obligations for a party to the service agreement and create notification schedule that includes the relevant contractual notification obligations, as well as other state and federal notification obligations imposed by statute.
Using the examples above, it will be appreciated that an entity can be both a covered entity and a business associate, but these roles depend on the natural of the relationship with the entity and other entities, defined by a contractual relationship.
The suggestions or recommendations generated by the risk assessment server are dictated, in some embodiments, by the role assumed by a party to a contractual agreement. Because a party can be both a data owner (covered entity) and a data maintainer (business associate), relative to the same data incident.
For example, generating a notification schedule can include generating a first notification schedule for a party when the party is acting as a data owner and generating a second notification schedule for the party when the party is acting as a data maintainer. To be sure, the creation of the first and second notification schedules occurs in response to the same data incident.
The extraction of obligations can include the risk assessment server analyzing the service agreement for keywords or phrases indicative of notification obligations.
FIG. 16 is a flowchart of an example method that is executed in accordance with the present technology. The risk assessment server described above can be configured to execute the method illustrated in FIG. 16.
In some embodiments, the method includes identifying 1605 the occurrence of a data incident. Once a data incident has been identified, the method includes receiving 1610 data incident data that comprises information corresponding to the data incident. The data incident data can comprise, for example, the identities of the parties involved in the data breach/incident.
As mentioned above, the data incident is defined by the intentional or unintentional release of personally identifiable information to an untrusted environment.
Next, the method includes automatically generating 1615 a risk assessment from a comparison of the data incident data to privacy rules. In one embodiment, the method includes determining 1620 if at least one federal rule should be applied. Also, the method includes determining 1625 if at least one state rule should be applied.
To be sure, each of the state and federal rules define requirements associated with data incident notification laws.
In some embodiments, the method includes determining 1630 if at least one contractual obligation defining contractual requirements of a breaching party due to the data incident. As mentioned previously, the breaching party is a party to the at least one contractual obligation, such as a covered entity and a business associate.
The method also comprises providing 1640 the risk assessment to a display device that selectively couples with the risk assessment server, as well as generating 1645 a notification schedule when the comparison indicates that the data incident violates at least one of the at least one federal rule, the at least one state rule, the at least one contractual obligation, or combinations thereof.
The method described above can be executed in any order. Steps can be added, omitted, and/or modified as required so long as the steps selected for the method are consistent with the teachings provided herein. For example, the method can include a step of determining a role for each entity in a contractual agreement. This process can occur before the data incident occurs or can be performed after the data incident occurs, but prior to creation of the notification schedules.
FIG. 17 is a flowchart of a method for managing a data incident.
As with the method of FIG. 16, the risk assessment server is utilized to perform the method. Generally, the method of FIG. 17 involves the identification of a data incident and the selection of a role for a party that is based on a contractual agreement between that party and one or more parties. The role, in part, dictates the obligations imposed on that party either by state or federal law, as well as any obligations for that party set forth in the agreement. For context, some state and federal laws impose duties or obligations on a party depending upon whether they are a data owner or a data maintainer. By way of example, HIPPA laws impose duties on both covered entities and business associates. These obligations are different for each role. As mentioned above, a party can be both a covered entity and a business associate within the context of a single data breach.
The method includes a step of creating 1705 an incident record for a data incident. This data record includes information regarding the data incident.
Next, the method includes selecting 1710 one or more roles for each party involved in the data incident. Again, a single party can be assigned two or more roles for a single incident.
Once the incident has been identified and one or more roles assigned to each party to the data incident, the method includes automatically generating 1715 a risk assessment from a comparison of the data incident to the privacy rules.
The method also includes generating 1720 a notification schedule for each party to the data incident that is based on the role or roles for the party when a comparison of the privacy rules to the data incident indicates that the data incident violates at least one of the at least one federal rule, the at least one state rule, the at least one contractual obligation, or combinations thereof.
In some embodiments, the present technology can leverage an external entity workflow to manage complex relationships and obligations between contracting parties. Thus, in addition to having regulatory obligation imposed by regulatory agencies who apply state and federal privacy rules, parties can also have specific notice obligations that stem from contractual obligations between parties.
Specific definitions and descriptions for various parties are provided for clarity of description. On type of party is a covered entity (CE), which comprises an entity that is covered by federal or state privacy laws, some of which require notification obligations to impacted parties. According to the HHS (health and human services) definition, a CE can be a Healthcare Provider such as a doctor or healthcare clinic, a Health Plan (e.g., health insurance company, HMO, Medicare/Medicaid), or a Healthcare Clearing House. According to the FTC (federal trade commission), a CE is a financial institution.
Another type of party is a Business Associate/Service Provider. According to the HHS definition, a business associate (BA) is a person or entity that creates, receives, maintains, or transmits protected health information to perform certain functions or activities on behalf of a covered entity. The equivalent entity in the financial world is referred to as a Service Provider (SP).
Parties can enter into a Business Associate Agreement (BAA), where the BAA is the contract between a CE and an external entity that covers obligations such as notifications, indemnification, and so forth.
In some instances, these BAAs (as well as other contracts) can include indemnification clauses. If there is a data breach or HIPAA violation, these events can incur costs such as attorney fees, notification costs, credit monitoring, or fines. An indemnification clause determines who pays the costs. If you are the indemnified party, an indemnification clause is a promise by the other party to cover your losses if they do something that causes you harm. “Indemnify” and “hold harmless” mean the same thing—to make whole after causing a loss. See article on HIPAA.com.
A subcontractor is a person or entity to which a business associate delegates a function, activity or service in a capacity other than as a member of the workforce of such business associate.
An upstream/downstream position describes where an entity exists in the chain of HIPAA or FTC compliance. For example, a BA is downstream of a CE, a subcontractor is downstream of a BA, and a CE is upstream from a BA and a subcontractor—just to name a few.
An external entity is an organization with which a first party has a relationship as defined by a contract. The relationship can be as a client, business associate, service provider, or subcontractor.
In some instances, parties can implement a fully insured or self-funded health plan. Employers that offer health insurance benefits finance those benefits in one of two ways: (1) they purchase health insurance from an insurance company (fully insured plans), or they self-fund the health benefits directly for employees (self-funded or employee sponsored plans) and contract with insurance companies to serve as third-party administrators of the insurance plan. Employers with self-funded plans are usually considered to be CE's and must comply with the HIPAA privacy and security rules. This is because the employer has access to its employees' medical information, either directly or through a third-party administrator (TPA). Usually, the TPA is a health insurance company.
In general, the external workflow processes described herein can support covered entities as defined by HIPPA and their obligations under HIPPA Final Rule, and financial institutions as defined by the FTC and their obligations under GLBA. The external entities workflow extends the functionality of the risk assessment server (described in greater detail infra) to include external entities (BA or SP) that have obligations to clients, individuals, and agencies. The risk assessment server can be configured to handle contractual obligations similarly to regulatory jurisdictions.
The risk assessment server can implement various UIs to request, capture, process, and identify notification obligations for contracting parties. In some embodiments, the risk assessment server can create external entities, define contacts and notifications, and define notification rules.
The risk assessment server can configure specific properties to “unlock” the external entities workflow. For example, the risk assessment server can set properties that trigger notice obligations. When the properties of a data incident match these triggers, a party is informed that their notice obligations have been triggered. This informational process can specify entities requiring notification, the content of the required notification, and so forth.
In some embodiments, the risk assessment server can specify one or more affected external entities, and at least one regulatory jurisdiction involved in the data incident.
An assessment of the incident can occur and can be conducted in accordance with any of the embodiments described above.
According to some embodiments, the risk assessment server can optionally generate and/or display various UIs that allow a party to view the regulatory assessment results and evaluate whether any jurisdictions are notifiable breaches.
In some embodiments, an example workflow can comprise a covered entity creating a data incident record within the risk assessment server. The CE can initiate a workflow on its own behalf in this embodiment. The CE defines a source, which is itself as well as its role as a CE. The CE can select employees who were involved in the data incident. In another embodiment the CE can create a workflow for an incident on behalf of a BA. In these embodiments, the CE can specify that the source is external in nature (a BA) and that the reporting party is a CE. The risk assessment server then specifies the name of the BA who caused the incident and may also specify an incident date. The CE can utilize the risk assessment server to determine its notice obligations, if any and begin the notification and remediation process. The CE can utilize the risk assessment server to monitor the implicated BA's compliance to its contractual notice obligations.
In another example data incident, a BA causes a breach that has impacted one or more CEs and the BA can be obligated due to contractual obligations with CEs. In this example, the BA can create the incident report and define any relevant properties such as role, employees, and so forth.
A BA can also specify a data incident on behalf of a subcontractor. Again, the subcontractor is a downstream entity of a BA. When the subcontractor reports the incident to the BA, the BA can define incident properties such as source, role, employee(s), BA, and informed date (e.g., the date on which the BA was informed by the subcontractor that a data incident had occurred).
In some embodiments, a notifying party can be defined as a hybrid entity that has both regulatory and external entity obligations. In these instances, the party can be obligated due to a state law, a federal law, and/or a contractual obligation.
FIG. 18 illustrates a table that includes a list of entity designations, roles, and permutations of internal and external notification obligations based on party type and an associated role.
FIG. 19 is a flowchart of an example method of an external workflow process. As with the methods above, the risk assessment server is utilized to perform the method. In some embodiments, the method comprises the risk assessment server providing 1905 an external entity interface that receives external entity information. In some embodiments, the external entity information can comprise a contract between a first party and at least one additional party. For example, one of the parties can upload a copy of a contract between the first party and at least one additional party. This contract specifies contract clauses that can include notification obligations, such as the indemnification agreement/clauses defined above. The contractual obligations can take various forms as would be appreciated by one of ordinary skill in the art.
In some embodiments, a party can define notification obligations that specify when the first party or the at least one additional party notifies entities that a data incident has occurred, as well as properties that trigger an assessment of the notification obligations.
The properties can include many permutations of various quantities/qualities/parties. These properties can include source (either internal or external), party role, breaching party relationship, incident date, and incident details.
In some embodiments, some properties that can affect the assessment, or can be deleted or deactivated such as a Relationship Contractual Notify Rule, a Regulatory Notify Rule, Timeline, Contacts, Notifications, and Active/Resolved. Changes can be saved in the UI at any time. The changes will propagate to existing incidents as described (and configured) in the Message column. The server may not allow locked incidents to be updated because of a desire to maintain the integrity of the assessment history.
Deleting a contact or notification or deactivating an external entity removes the relevant configuration from the server. If changes are applied to incidents that are assessed but unlocked, the assessment data is cleared and users must reassess the incident. A new contact can be created at any time without risk.
Properties that are displayed in the incident but don't affect the assessment include, but are not limited to Entity Name, Entity Type, Contact Name, Notification Name, Notification Method, and Notification Summary.
In some embodiments, the method can comprise receiving 1910, via a risk assessment server, in response to an occurrence of the data incident. The data incident data comprises information corresponding to the data incident, the data incident further comprising intentional or unintentional release of personally identifiable information to an untrusted environment by the first party or the at least one additional party.
Next, the method includes comparing 1915 the data incident data to the properties that trigger an assessment. To be sure, if the properties indicate that an assessment is required the method further comprises generating 1920, via the risk assessment server, a risk assessment from a comparison of the data incident data to privacy rules.
In some embodiments, the privacy rules comprise one or more of the following: (a) at least one federal rule; (b) at least one state rule, each of the rules defining requirements associated with data incident notification laws; and (c) the contract.
According to some embodiments, the method includes the providing 1925, via the risk assessment server, the risk assessment to a display device that selectively couples with the risk assessment server.
Additionally, the method includes generating 1930 a risk assessment guidance interface when the comparison indicates that the data incident violates at least one of the at least one federal rule, the at least one state rule, the contract, or combinations thereof.
FIG. 20 is an example risk assessment guidance interface 2000. The interface 2000 comprises a basic information section 2002 that defines various entity or party data. The interface 2000 also comprises a contract upload mechanism 2004 that allows one or more parties to upload a contract that defines the notification obligations between the parties.
In some embodiments, the interface 2000 can also comprise a notifications section 2006 that allows a party to specify notification obligations.
In some instances, default notification obligations can be implemented if no specific notification obligations are defined.
To be sure, the properties that trigger the notification obligations can be determined from the party information collected in section 2002, as well as the contractual information uploaded in section 2004.
FIG. 21 illustrates another example risk assessment guidance interface 2100 that allows a party to manage its external entity relationships. For example a business associate ABC Corp is listed. Each of the entities defined using the assessment interface 2000 of FIG. 20 will be listed in the interface 2100.
FIG. 22 is a screenshot of a detailed incident assessment user interface 2200. Specifically, this UI 2200 includes a contract based assessment of obligations. A summary section 2202 is provided which indicates violation type, which in this instance includes HIPAA HITECH (federal rule). The summary section can also identify impacted external entities and status of analysis for each of the external entities.
A breach assessment section 2204 provides the specific details of an identified data incident, for two specific entities/parties. The first entity is a diagnostic imaging company and the second entity is a fortune 500 manufacturing company. To be sure, these entities are the parties to which a BA or other downstream external entities are obligated to notify that a privacy incident has occurred. Each of these entities will have a detailed summary about whether they have been or will be notified and status indicator for the current notification analysis.
FIG. 23 includes a detailed incident interface 2300 that provides a robust set of details for an identified incident. An incident detail section 2302 includes attributes of the incident gathered from the incident details provided by a reporting party. A risk factor section 2304 is also included that provides more specific details regarding the severity of the data incident.
FIG. 24 is another summary interface 2400 that includes various sections that provide additional details regarding a data incident. The interface comprises a regulated data section 2402, a data sensitivity section 2406, a jurisdictions section 2408, and an external entities section 2410. These various sections can include visual indicators that inform a user as to the types of data involved in the data incident, as well as a sensitivity level of the data involved in the incident, as well as any jurisdictions involved (e.g., if state or federal rules are implicated), and a list of any external entities that are involved in or impacted by the data incident.
FIGS. 25-26 illustrate a table of external entity administration console features. FIGS. 27-33 illustrate a table of external entity workflow features for the risk assessment server. Some of the illustrated features require customer licensing. FIGS. 34-35 collectively illustrate a table of additional functionalities that can be implemented by the risk assessment server. These features illustrated in FIGS. 25-35 are not intended to be limiting in any way but are example features and logic that can be implemented by the risk assessment server.
While various embodiments have been described above, it should be understood that they have been presented by way of example only, and not limitation. The descriptions are not intended to limit the scope of the technology to the particular forms set forth herein. Thus, the breadth and scope of a preferred embodiment should not be limited by any of the above-described exemplary embodiments. It should be understood that the above description is illustrative and not restrictive. To the contrary, the present descriptions are intended to cover such alternatives, modifications, and equivalents as may be included within the spirit and scope of the technology as defined by the appended claims and otherwise appreciated by one of ordinary skill in the art. The scope of the technology should, therefore, be determined not with reference to the above description, but instead should be determined with reference to the appended claims along with their full scope of equivalents.

Claims

What is claimed is:

1. A method for managing a data incident, comprising:

providing an external entity interface that receives:

external entity information comprising:

a contract between a first party and at least one additional party;

notification obligations that specify when the first party or

the at least one additional party notifies entities that a data incident has occurred; and

properties that trigger an assessment of the notification obligations;

receiving, via a risk assessment server, in response to an occurrence of the data incident, data incident data that comprises information corresponding to the data incident, the data incident further comprising intentional or unintentional release of personally identifiable information to an untrusted environment by the first party or the at least one additional party;

comparing the data incident data to the properties that trigger an assessment;

wherein if the properties indicate that an assessment is required, generating, via the risk assessment server, a risk assessment from a comparison of the data incident data to privacy rules, the privacy rules comprising:

at least one federal rule;

at least one state rule, each of the rules defining requirements associated with data incident notification laws; and

the contract;

providing, via the risk assessment server, the risk assessment to a display device that selectively couples with the risk assessment server; and

generating a risk assessment guidance interface when the comparison indicates that the data incident violates at least one of the at least one federal rule, the at least one state rule, the contract, or combinations thereof.

2. The method according to claim 1, wherein receiving data incident data comprises:

providing one or more questions to the display device that elicit information corresponding to the data incident;

receiving responses to the one or more questions;

providing the responses to the display device; and

receiving confirmation of at least a portion of the responses.

3. The method according to claim 1, further comprising:

receiving one or more selections of one or more states;

selecting one or more state statutes based upon the one or more selections; and

generating at least one state rule based upon a selected state statute.

4. The method according to claim 1, wherein the at least one federal rule comprises a federal statute that governs privacy breaches relative to at least one of protected health information (PHI), personally identifiable information (PII), or combinations thereof.

5. The method according to claim 1, wherein the at least one state rule comprises a state statute that governs privacy breaches relative to at least one of protected health information (PHI), personally identifiable information (PII), or combinations thereof.

6. The method according to claim 1, wherein the risk assessment comprises a risk level that indicates a severity of the data incident relative to at least one of the at least one federal rule, the at least one state rule, or combinations thereof.

7. The method according to claim 6, wherein the risk level is associated with a color, wherein a hue of the color is associated with the severity of the data incident as determined by the comparison.

8. The method according to claim 1, wherein the risk assessment defines one or more exceptions that apply to at least a portion of the data incident data based upon the comparison.

9. The method according to claim 1, wherein the risk assessment comprises at least a portion of the at least one state rule.

10. The method according to claim 1, further comprising providing an alert to the display device when the comparison indicates that the data incident violates at least one of the at least one federal rule, the at least one state rule, or combinations thereof.

11. The method according to claim 1, wherein the notification schedule comprises notification dates that are based upon a violated statute, along with notification requirements that describe information that is to be provided to a regulatory agency.

12. The method according to claim 11, further comprising receiving the information that is to be provided to a regulatory agency and storing the same in a content repository associated with the risk assessment server.

13. The method according to claim 1, wherein the comparison includes modeling of the data incident data to the privacy rules to determine a severity and a data sensitivity of the data incident.

14. The method according to claim 1, wherein the comparison comprises:

modeling the data incident data to determine severity and data sensitivity of the data incident by evaluating the data incident data relative to the at least one state rule; and

generating a state specific risk assessment from the modeling.

15. The method according to claim 1, wherein the data incident data specifies a role for the first party or the at least one additional party as a business associate or service provider, an identification of one or more employees involved in the data incident, a data incident notification date, and combinations thereof.

16. The method according to claim 1, wherein the data incident data specifies an identification of a subcontractor rather than one or more employees.

17. The method according to claim 1, wherein the first party or the at least one additional party is both a covered entity and a business associate of another covered entity.

18. The method according to claim 1, wherein the external entity interface comprises a contract upload interface and a notification designation interface.

19. The method according to claim 1, wherein the risk assessment guidance interface comprises an impact summary that indicates which state or federal rule was violated and one or more external entities implicated in the data incident.

20. The method according to claim 1, wherein the risk assessment guidance interface comprises an external entity assessment profile that comprises a chronological list of data incident events and a disposition for each of the data incident events.

21. The method according to claim 1, further comprising generating a data incident detail interface that comprises risk factors from the data incident data, regulated data table, a data sensitivity index, jurisdiction identification, and the identity of any external entities, or any combinations thereof.

22. The method according to claim 21, wherein the regulated data table comprises cells that each comprise a visual indicator of low, medium, or high risk for each type of sensitive information included in the data incident.

23. The method according to claim 22, wherein the jurisdiction identification comprises an identification of the at least one federal rule or the at least one state rule.

24. The method according to claim 1, further comprising generating a data incident detail interface that comprises selected details for the data incident in visual format.