Does Your Organization Have A Privacy Incident Response Plan?

Article: Does Your Organization Have A Privacy Incident Response Plan? May 2007 Newsletter Printer Friendly Version

Author: William L. Dana, CISSP, CISM, CBCP, CIPP With 14 years of experience, Mr. Dana’s career has provided a diverse experience not only in the designing, installation, integration, and maintenance of network systems but also in areas of information security and information privacy assurance. He has over 8 years of experience in information security and over 6 years of experience as a Privacy Engineer supporting Federal Agencies and Commercial clients. Bill is currently working with ISACA’s National Capital Area Chapter in DC to help establish the Information Privacy / Privacy Governance Committee for the Chapter. Bill can be reached for comments or interests in the Privacy Committee at [email protected].

In today’s world of the “Information Age” where virtually every organization is not only “online” but is interconnected or has some form of electronic data sharing activities with at least one other organization, it is not a case of “IF” an organization will have a privacy breach —it is a question of “WHEN” it will occur. While this may sound pessimistic or even fatalist, it is not only a safe assumption to make but should be the foundation an organization uses to prepare its privacy incident response plan or program. Looking back over the last two years, the shift from “IF” to “WHEN” can be supported by facts like:

Within the United States, between January 10, 2005 and March 20, 2007 there have been 520 privacy breaches reported that have involved over one-hundred-and-four (104) million records.[1]

At least 30 states have enacted Privacy Breach Notification Laws [2] as a result of significant privacy breaches. Notification requirements vary between states (organizations with an international presence will also be faced with notification requirements for the countries where they have a presence) in regard to issues such as identifying what is considered to be a breach that requires notification and the time frame for notifying.

While there are no Federal notification requirements [3] depending on the business sector your organization is in, Federal Statues such as, Safeguard Rule of the Gramm-Leach-Bliley Act [4], The Health Insurance Portability and Accountability Act’s (HIPAA) Security and Privacy Rule [5], or The Fair and Accurate Credit Transactions Act‘s (FACTA) record disposal rule [6] may be factors impacting how an organization responds to and handles a privacy breach.

Although the majority of breaches currently reported are technology related, privacy breaches still occur with hardcopy documents (see Table 1, Recent Privacy Breaches Involving Paper Documents). A breach involving hardcopy documents can be just as serious as one involving technology.

A privacy breach can be an “internal incident” where information is exposed to unauthorized personnel within an organization (e.g. salary information for an employee is disclosed to other employees), or it can be an “external incident” where information is disclosed to or obtained by parties outside the organization (e.g., stolen computers, hackers, incorrect mailings, etc.).

Table 1 – Recent Privacy Breaches Involving Paper Documents [7]

Why Should My Organization Have a Privacy Incident Response Plan? Without question, a privacy breach is a very costly event for an organization. It is currently estimated that an organization can expect to spend about $182.00 [8] per compromised record to respond to and mitigate a privacy breach (up from an estimated cost of $132 per record in 2005). In addition to the cost aspect, a privacy breach can result in your organization getting the attention of news media, industry regulatory agencies, and attorney generals, not to mention your organization’s customers. How your organization responds to and handles a privacy breach can have a dramatic impact both financially and with regard to public opinion. Think of the Privacy Incident Response Plan (PIRP) in the terms of a contingency plan that provides a framework for how

Date Organization Description # of Records

1/21/06 California Army National Guard

Stolen briefcase with personal information of National Guardsmen including a “seniority roster,” social security numbers and dates of birth.

“Hundreds”

6/8/06 Univ. of Michigan Credit Union (Ann Arbor, MI)

Paper documents containing personal information of credit union members were stolen from a storage room.

5,000

6/13/06 U.S. Dept of Energy, Hanford Nuclear Reservation (Richland, WA)

Current and former workers at the Hanford Nuclear Reservation were notified that their personal information may have been compromised, after police found a 1996 list with workers’ names and other information in a home during an unrelated investigation.

4,000

2/20/07 Back and Joint Institute of Texas (San Antonio, TX)

20 boxes containing social security numbers, photocopies of driver’s license numbers, addresses, phone numbers and private medical history of chiropractic patients were found in a dumpster.

“Hundreds”

Page 1 of 6Article: Does Your Organization Have A Privacy Incident Response Plan? (Print Version)

6/7/2007http://isaca-washdc.org/content/newsletters/articles/article-may2007-print.htm

an organization will respond, identifies key team members, and allows your organization to respond in a coordinated manner to minimize damage and prevent a bad situation from getting worse. Once your organization has a PIRP in place, it will have a platform for mock incidents to be conducted to train personnel, evaluate the plan for gaps, and be better prepared to respond in a coordinated manner and to handle multiple notification requirements.

My Organization Already Has a Computer Security Incident Response Program. Is That Not Enough? Odds are no—having just a computer security incident response program (CSIRP) will provide only a small part of what will be needed to respond to and handle a privacy incident. Most CSIRPs are designed to monitor, detect, and respond to network based incidents. However, most CSIRPs are not prepared to conduct in-depth data analysis to assess the types and scope of information that maybe involved in data breaches. Some other areas that your organization’s CSIRP may not address but which are necessary to consider when handling a privacy incident are:

Responding to and handling paper-based data breaches; Supporting all the phases in the life cycle of a privacy incident beyond the traditional incident response life cycle illustrated in Figure 1;

Determining scope, risk, and impact of the breach based on analysis of the information involved with the breach; Coordination of various internal and external notification requirements with regulators, law enforcement, customers, senior management, and/or stockholders;

Handling potential incident notifications that come from outside of the organization (e.g., phone call from local media);

Assuming that an outside agent contacting the organization about a suspected breach is a “Good Samaritan” rather than considering that the outside agent could be a “malicious actor” with hostile intentions.

What Are The Phases of a Privacy Incident Life Cycle a That Should be Covered by a Privacy Incident Response Plan? Part of what makes the privacy incident life cycle unique is that like most privacy programs and policies, it draws on the principles of “Fair Information Standards”[10] and is therefore much more transparent and involves a lot more communication than does a typical CISRP, or even a Continuity of Operations Plan / Contingency Plan / Disaster Recovery Plan (COOP / CP / DRP). The other unique aspect of this life cycle is that it is very probable that any organization will be operating in multiple phases simultaneously. Currently there is no definitive life cycle model that can be pointed to (as there is with a CSIRP or Contingency Planning). Most privacy incident life cycle models should have phases similar to the following ones: Detection Analysis, Containment, Notification, Recovery, and Monitoring / Preparing. To provide a reference point for discussion of the privacy incident life cycle, the following Privacy Incident Response Life Cycle Model [11] in Figure 2, has been created to provide an illustration of what a Privacy Incident Response Plan should address.



The Incident Detection and Identification phase (or the Detect/Analysis Phase in a CISRP) involves both reactive and proactive processes that gather, monitor, or receive potential incident information from internal and external sources as well as from monitoring for indications with tools like intrusion detection systems. Your organization’s CISRP may very well be the primary group responsible for this activity. However, there will be new monitoring points that a Computer Incident Security Response Team (CISRT) or Coordination Center may need to include: digital rights management [13] systems, content management systems, breach prevention systems, privacy/ethics hotlines, and of course the news media. Once the incident is identified, some initial triage is done to classify/categorize, prioritize, and validate the initial information, begin documentation of the incident, and the eventually hand off the information to the Incident Analysis and Screening Phase. With the declaration of a privacy incident a Privacy Incident Response Team (PIRT) specific for the incident would be assembled and assume coordination and oversight of the incident response.

The Privacy Incident Analysis and Screening phase, while it may involve the CISRT, should be overseen by the assembled Privacy Incident Response Team, which would be made up of key members called for in the PIRP. Part of the PIRT would include a small workgroup which would include personnel that are knowledgeable about the business process, systems, and data involved in the breach. It would be this small workgroup’s task to conduct the detailed analysis based on the information available to develop an information data model that would identify to the greatest extent possible what records/information have been compromised. With the identification of an incident as a privacy incident, it becomes imperative and critical that an organization not just know the basic facts (when it happened, if the breach is still occurring, how it occurred, where it occurred, etc.) but also start identifying information about the actual data involved:

Who is the Source/Owner of the data within the Organization and what IT systems are involved? Initial estimate of how much data may be involved (e.g., an entire database, a set of tables from a database, 10,000 records, etc.).

The time period and/or age of the data affected by the incident (e.g., between current and 3 months ago, between 3 to 5 years ago, etc.).

Who currently knows about the incident (e.g., already in the newspapers, internal within organization, or just the response teams and the person that notified the organization of the incident)?

Who was involved with events leading up to the time when the incident occurred? What protection was in place prior to the event and what protection may still be in place (e.g., data encryption, digital rights)?

Will data forensic services be needed? Are formal and controlled “Chain of Custody” protocols required for evidence collection and protection?

While the Incident Analysis and Screening Phases initial objective is to define the boundaries and ranges of data involved, typically the group conducting the detailed analysis will continue to refine the information data model through out the remaining phases of the life cycle until either (a) the data is recovered and can be verified that it was not compromised or (b) a mitigation strategy has been fully implemented (e.g. accounts closed, credit monitoring services, etc.).

Containment During Phase 3, which could potentially occur simultaneously with Phase 1 and/or Phase 2 depending on the incident, the PIRT begins to contain the incident (and prevent additional information from being disclosed if the incident is still on going) and assess the impacts of the breach. Containment for a privacy incident could require:

Securing Data Processing Operations to prevent further disclosure of information. Containment of what employees know about the incident to only what they need to know, especially during the early stages of the response; containing rumors as much as possible.

Limiting who represents or speaks for the organization about the incident with the media, law enforcement, regulators, affected individuals, and to the employees within the organization.

Containing or withholding details about the incident from the media due to investigation by law enforcement or to prevent the perpetrator from learning exactly what is contained in the data, as they may not be aware of what



they have.

Containment could also involve having to invoke a “blackout period” for trading stock by the organization’s employees.

Breach Assessment The Breach Assessment step of Phase 3 is where the impact to the organization begins to be determined based on the information data model that was constructed and refined by the Incident Analysis and Screening process. A Breach Assessment for a privacy incident should draw on elements from the organization’s risk management plans (corporate as well as IT) and potentially could rely on some of the same processes used during the damage assessment phase from the organization’s COOP / CP / DRP. The breach assessment should include:

Estimated risk and probability that the breach will result in identity theft of the impacted individuals. Identification of what jurisdictions are involved (e.g. in what states are the impacted individuals located, are foreign countries involved, etc.).

Identification of the external stakeholders requiring notification about the incident. What type of notification is required and when is it required by law or regulation? Should all impacted parties receive the same notification information as would be required by the most stringent law or will impacted parties receive different notification information based on the laws for where they reside?

Recommendations related to voluntary notification and involvement of law enforcement. Should external consultants be obtained (e.g., legal counsel, public relations firm, investigative or forensic services)?

Just as a COOP / CP / DRP has some standard basic scenarios for response defined (i.e., hurricane, flooding, etc.), a PIRP should have some standard response plans that can be used by the organization as a starting point for both handling the incident at its discovery and then modifying the standard response in order to address the requirements of a particular incident. As an example, some of the standard response plans that an organization might need to develop are for:

An incident that involves employee records only; An incident that involves the loss of Business Proprietary records; An incident that involves the compromise of customer and consumer data; Use of a third party to manage response or notification aspects of an incident.

Similar to Phase 2, an organization may have a specific team that handles the breach assessment activities for the PIRT for a number of reasons, one being that it is very possible that the breach assessment may have to occur simultaneously with either Phase 1 or Phase 2; it would then need to be revised and updated as detailed information became available. Having some standard response plans to start from could mean the difference that keeps a bad day from getting worse, such as when the incident is discovered at the same time the media arrives to interview the management team. Having these plans in place to address not only initial handling procedures but also a generic response can allow an organization to begin mitigation efforts and notification efforts faster than if they were to start from scratch.

In the context of this article, “response” and “notification” are considered two separate functions. “Response” refers to activities the organization engages in to prepare for the notification process and necessary remediation activities required; and “notification” is defined as formally notifying the impacted individuals of the compromise and of the mitigation efforts to prevent identity theft. Response Where the prior phases were oriented more towards data collection and analysis of the incident, in Phase 4 the organization finalizes and implements the proposed “response plan” as part of the output from the Breach Analysis step of Phase 3. During Phase 4 a number of things may be occurring concurrently throughout the organization.

Call Center Staff is being trained and provided a script for when calls come in to be able to respond. Procurement Office may be arranging for provisions for impacted individuals to receive credit monitoring services and/or credit reports.

Accounts Receivable staff may be closing and voiding affected accounts and establishing new accounts for the impacted individuals;

IT Staff may be upgrading systems with patches or installing additional monitoring and auditing functions for



impacted systems.

Notification The notification step of this phase involves the arduous task of complying with various local, state, federal, or international laws to individually notify each affected person that his or her personal information has been compromised (and should not be confused with other messages that may have been sent out to affected parties in other stages). This notification typically will provide detailed information about the breach (as appropriate based on any law enforcement investigation in process), steps taken to prevent it from happening, how the individual whose data was involved may be impacted, identification of any steps the individual may have to take to protect him or herself, what the organization is doing for the individual, and who to contact with questions or for more information. As part of this step, the organization would notify any regulatory agencies about the incident, if they had not already done so. The organization may also need to send notifications about the incident to its vendors, clients, and creditors. The activities initiated in the notification step will be moderate to long term tasks that will need to be tracked until they are closed out. There is also the potential that follow-up notifications to some of the individuals will be required.

With any incident, but possibly more so with a privacy incident, the Post-Incident Review could be critical for the organization in the days to come after the incident has been “closed out.” One of the goals of the Post-Incident Review should be the development of a final report that documents the entire incident and includes a detailed timeline of events, a formal documentation of decisions made, and a log of all incident related data. [14] Every incident response system, regardless of what it is designed to respond to, is a constantly changing and adapting system to identify, respond to, and maybe even prevent new threats. One of the final steps that should always be taken before closing out an incident, no matter how good or bad the outcome was, is to conduct a Post-Incident Review. Seldom will there be an incident from which an organization or a response team will not be able to learn something. More often than not, necessary changes to procedures are identified.

As your organization monitors compliance with privacy requirements and periodically evaluates the effectiveness of your response plan, don’t forget to also monitor what is going on with other organizations. There is always the potential to learn something from an incident involving another organization. With the publicity recent privacy incidents have been getting, there is a wealth of actual incidents against which you can evaluate your plan (or as the starting point for developing one) by conducting a tabletop exercise and simulating the incident as if it had occurred at your organization.

Things to Remember When Developing a Privacy Incident Response Plan First and most importantly, do not forget about the paper documents within the organization. While the information and technology systems may be the primary source for a potential privacy breach your plan still has to take into account and be ready to handle the loss or theft of paper records. An incident involving paper documents may also prove the hardest to respond to and handle if the organization does not have an effective records management system. Secondly, your Privacy Incident Response Plan is not a stand-alone document and should ultimately be interdependent on a number of other plans and/or programs your organization has put in place as part of its corporate governance [15] such as the:

Risk Management Plan (both Organizational and Information Technology); Continuity of Operations / Contingency Plan / Disaster Recovery / Business Resumption Plans; Communications Plan / Crisis Communications Plan; Information Systems Inventories / Business Process Models / Data Models; Computer Security Incident Response Plan / Physical Security Incident Response Plan.

Your Privacy Incident Response Plan will need to involve a cross-functional team that should have senior level participation. Some of the representation that the team will need to have from within the organization is: Legal Counsel, Corporate Communications / Public Relations, Human Resources, Chief Information Officer, Chief Privacy Officer, Chief Risk Officer, as well as representation from the business or data owner for the information involved in the breach. Another key point to handling a privacy incident and developing a privacy incident response plan is the need for timely, accurate, and appropriate communications both within your organization between departments and employees, and external to your organization with customers, media representatives, regulators, and law enforcement officials. However, in order to have timely, accurate, and appropriate communications your organization will need to have solid information about what happened, how it occurred, what information was affected, how the incident was detected, and what mitigating controls were in place.



Finally, once your organization has a privacy incident response plan in place with employees trained, remember to test the plan periodically. One way to conducting periodic tests of the plan (preferably twice a year if possible) is to use mock privacy incidents based on actual incidents that are pulled from current events. Unlike Contingency Plan or Disaster Recovery Tests, a test of the privacy incident response plan does not have to involve shutting down production systems to carry it out; rather, it can be done as a “table top” event. One of the benefits from having a privacy incident response plan is that it will provide a framework to handle an incident and reduce the initial “panic reactions” and “knee-jerk decisions” when the organization discovers it has had a privacy incident. If the personnel responsible for responding to and coordinating a privacy incident are not trained or familiar with the plan, nor are your organization’s employees educated about their responsibilities when a privacy incident has been discovered, having the plan will be of little value. Holding a mock privacy incident allows your organization to test your plan, but more importantly it trains your employees for the real event.

Endnotes [1] Information related to reported incidents was compiled from the Privacy Rights Clearinghouse, Chronology of Data Breaches. http://www.privacyrights.org/ar/ChronDataBreaches.htm [2] Consumers Union, Notice of Security Breach State Laws, Last updated June 27, 2006. http://www.consumersunion.org/campaigns/Breach_laws_May05.pdf [3] For Federal Agencies OMB Memo 06-19 issued on July 12, 2006 has put forth guidance related to the timeframe a federal agency is suppose to notify US-CERT within when a privacy incident has been identified. [4] Information about The Gramm-Leach-Bliley Act Safeguards Rule can be found at: http://www.ftc.gov/privacy/privacyinitiatives/safeguards.html [5] Information related to HIPAA’s security rule can be found at: http://www.cms.hhs.gov/SecurityStandard/Downloads/securityfinalrule.pdf. Information about HIPAA’s privacy rule can be found at: http://www.hhs.gov/ocr/hipaa/privrulepd.pdf [6] Information about FACTA’s record disposal rule can be found at: http://www.ftc.gov/os/2004/11/041118disposalfrn.pdf [7] Information was compiled from the Privacy Rights Clearinghouse, Chronology of Data Breaches. http://www.privacyrights.org/ar/ChronDataBreaches.htm [8] Ponemon Institute’s “2006 Cost of Data Breach Study”, released October 23, 2006. [9] This Illustration was reproduced from page 3-1 of NIST Special Publication 800-61, “Computer Security Incident Handling Guide”, January 2004. [10] The principles of Fair Information Standards (Openness, Notice, Use, Correction, Accuracy and Security) was put forth in the 1973 Department of Health, Education, and Welfare “Report of the Secretary’s Advisory Committee on Automated Personal Data Systems”. [11] The Life Cycle Model pictured in Figure 2 was created by the author for discussion and explanation purposes for this article, and only represents the author’s view and opinion of what a privacy incident response life cycle model should look like. The use of this model in this article should not be viewed or considered as a “standard” or a “requirement” in any way. [12] This Privacy Incident Response Life Cycle Model is based on the Vee Development Model. The Vee model was originally developed by NASA, in the late 1980s, for software development and then adapted for system development by Kevin Forsberg and Hal Mooz in 1990. The Vee Development Model is the third generation of models that integrate the original Waterfall and the Spiral models. Today, the Vee Development Model is part of systems engineering standards including EIA 632 and ISO 15288. [13] Digital Rights Management (DRM) is an umbrella term referring to technologies used by content or information owners to control access to or usage of electronic documents or files. DRM can also place restrictions on a document or file that establish a period of time it can be used, restrict it so only certain machines can open/access the document or file, or restrict the ability to copy, forward, or edit a file. [14] Your organization should have a policies concerning the handling and retention of this data as potential evidence in future or pending actions resulting from the incident. [15] Depending on the type of your organization there may be other plans or programs that will also be involved. © Copyright 2007 - National Capital Area Chapter

