Does Your Organization Have A Privacy Incident Response Plan?

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

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 b.dana@dana-enterprises.com.

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]
# of
Date Organization Description
Records
1/21/06 California Army National Stolen briefcase with personal information of National Guardsmen including a “Hundreds”
Guard “seniority roster,” social security numbers and dates of birth.
6/8/06 Univ. of Michigan Credit Paper documents containing personal information of credit union members were 5,000
Union (Ann Arbor, MI) stolen from a storage room.
6/13/06 U.S. Dept of Energy, Current and former workers at the Hanford Nuclear Reservation were notified 4,000
Hanford Nuclear that their personal information may have been compromised, after police found
Reservation (Richland, WA) a 1996 list with workers’ names and other information in a home during an
unrelated investigation.
2/20/07 Back and Joint Institute of 20 boxes containing social security numbers, photocopies of driver’s license “Hundreds”
Texas (San Antonio, TX) numbers, addresses, phone numbers and private medical history of chiropractic
patients were found in a dumpster.

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

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

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


Does Your Organization Have A Privacy Incident Response Plan?

More Related Content

What's hot

Similar to Does Your Organization Have A Privacy Incident Response Plan?

Does Your Organization Have A Privacy Incident Response Plan?