Privacy laws require transparency on the part of organizations that collect personal information about data subjects. Organizations are required to respond to a variety of requests, inquiries, and complaints. Responding to some requests may take time, so organizations should develop procedures or playbooks so that personnel know how to respond properly and in a timely manner.

Organizations need to develop privacy and security incident response plans to help them better recognize and respond quickly to incidents. Privacy incident response can often leverage an existing security incident response plan, since the procedures for both should be similar. It’s important to define roles and responsibilities in privacy incident response so that all parties know what is expected of them. Organizations that gather metrics on their incident responses will be able to identify areas for improvement.

Data Subject Requests and Privacy Rights

Modern data privacy laws require transparency not only concerning the collection and use of personal data, but also in providing one or more means for data subjects to make inquiries and requests regarding the use of their personal information. Such requests include enabling data subjects to contact organizations to inquire about the use of their personal data, to enact corrections to their personal information, to lodge complaints, to request that their information be transferred to another similar organization, and to request that their identity be removed from an organization’s records. The procedures for making such subject data requests are typically spelled out in an organization’s privacy policy—in fact, laws such as the General Data Protection Regulation (GDPR) in the European Union require that privacy policies describe this. Occasionally, procedures may be located elsewhere, such as in a user guide or in system documentation.

Data Subject Requests

The inquiries and requests that persons may lodge with organizations are known as data subject requests (DSRs). Organizations generally provide multiple means for making such requests, including

•   Postal mail

•   Telephone

•   FAX

•   E-mail

•   Web form

•   In person

Privacy laws require organizations to disclose specific methods for making such inquiries. In turn, organizations need to develop repeatable business processes and train personnel to manage and respond to these incoming inquiries. Personnel who handle the requests will need access to systems and applications containing personal information to respond accurately.

Organizations typically maintain a log of inquiries, including the subject’s name (or other identifying information), so that management can better understand the frequency of requests and the workload incurred. Privacy personnel will recognize that these logs themselves may also contain protected personal information.

Smaller organizations may provide only an inquiry form, an e-mail address, a telephone number, or a surface mail address where such inquiries may be sent. These organizations must respond to DSRs within specific timeframes (which are sometimes spelled out in regulations). Larger organizations automate inquiries in some cases. For instance, a data subject with an existing account on an organization’s systems can log in and click a link to learn how and where personal information is used. Often, such tools provide the means for data subjects to make changes to some of their information.

The types of inquiries that data subjects may send are described in the remainder of this section.

Inquiries for Data Usage

Data subjects may send a DSR regarding the presence and usage of their personal information in an organization’s records. Such a request may be general or quite specific. For instance, a data subject may ask whether his personal information is present in the organization’s systems, or he may ask about specific personal information, such as a home address or telephone number. Depending upon the language of applicable laws and an organization’s complexity, an organization receiving a DSR may need to search through multiple business records or systems to create a complete response to the data subject.

Requests for Updates and Corrections

In some circumstances, a data subject may ask for changes in her personal information used by an organization. For instance, a data subject may change residences and need to update a postal mail or shipping address. Or she may make changes in a payment method, family status, or service provider such as insurance. Finally, sometimes personal information is mistyped and spelling and other corrections are needed.

A request for an update or a correction can rise to the level of redress. In this case, the organization has made a decision detrimental to the data subject, who is requesting that the situation be corrected to make the data subject whole. For example, suppose an organization, believing it is selling an item to an ethnic minority, has priced the item higher than it would be for others. A customer seeking redress would request a correction to her data as well as a change in the organization’s practice.

Organizations are required to provide one or more means through which data subjects can request these corrections. Data subjects often can make these changes through self-service programs, but sometimes they must request that organization personnel make the changes on their behalf.

Privacy policies often provide one or more methods to be used by data subjects to make these requests. Whether the means are automated or manual, organizations typically log these events as routine systems and activity measurements. Like other mature business processes, this logging will sometimes compel management to make changes or improvements to systems and processes. For example, if the organization is receiving numerous requests that personnel must deal with manually, it may provide more self-service tools for data subjects to make some of those changes themselves.

Requests to Opt Out of Automated Profiling and Decision-Making Processes

In some jurisdictions, data subjects have the right to object to automatic subject profiling and automated decision-making processes. In Articles 13 and 21 of the GDPR, for instance, data subjects may request that they be removed from automated decision-making and profiling processes, regardless of the purpose of such automation. If, for example, an information broker that sells mailing lists to other organizations creates data subject profiles based on demographic information, data subjects can opt out of such activities.

Requests for Transfer

A data subject may request that an organization transfer his personal information to another (presumably similar) organization. Article 20 of the GDPR states, “The data subject shall have the right to receive the personal data concerning him or her, which he or she has provided to a controller, in a structured, commonly used and machine-readable format and have the right to transmit those data to another controller without hindrance from the controller to which the personal data have been provided.…” An example of such a request includes the transfer of medical records from one physician to another. Some organizations perform these transfers as a courtesy, but they are not required by law to perform them.

Requests for Removal

In Article 17, the GDPR made famous the notion of “the right to be forgotten,” meaning the outright removal of a person’s data from an organization’s records. The California Consumer Privacy Act (CCPA) contains a similar provision in Section 1798.105. This is not a new concept. A data subject may want to opt out of an activity that an organization is conducting that involves the person’s data. As with other subject data requests, privacy policy will provide specific means for such requests to be made and dealt with.

Organizations accepting opt-out or data removal requests must understand the nature of such data and any laws requiring the retention of records. For example, suppose a former employee requests that her employment records be removed, but employment law requires that employment records be retained for many years after the end of a person’s employment. Similarly, a request made to remove a subject’s data from a bank or credit union may conflict with laws requiring the retention of banking transaction records. On the other hand, marketing organizations that facilitate mail or telephone marketing campaigns may have few or no retention requirements and would be compelled to remove a subject’s data on request. The same can be said of social networking organizations that have few statutory requirements for retaining subject data. Finally, privacy laws cite specific exclusions to data removal requests: GDPR, for instance, does not require courts or prison systems to expunge a person’s criminal history.

Complaints

To improve customer service, organizations may include a means for permitting data subjects to lodge complaints regarding the use of their personal information. A data subject may be venting in the complaint, or the complaint may be an implicit request for a change in the person’s relationship with the organization, including an opt-out or outright removal.

Personnel in the organization will need to consider complaints carefully, including whether a complaint describes an activity that could violate the organization’s privacy policy. For this reason alone, organizations should pay close attention to data subject complaints, as they may be the only way organizations can become aware of privacy or security incidents.

Working with Authorities

Many privacy laws provide for the creation of government authorities that act in a supervisory capacity as a part of the enforcement of these laws. For instance, Articles 51 through 54 of the GDPR define supervisory authorities and their responsibilities. California Privacy Rights Act (CPRA), passed in 2020 by ballot measure, provides for the creation of the California Privacy Protection Agency to enforce the CCPA and additional privacy provisions in the CPRA itself. (Although this book does focus on organizations that will, from time to time, work with supervisory authorities, details on work performed by supervisory authorities are beyond its scope.)

The most important ingredient to successful relationships and encounters with external parties, including auditors, regulators, and supervisory authorities, is the completeness and integrity of business information, including the following:

•   Up-to-date process information

•   Data-flow diagrams (or detailed descriptions of data flows)

•   Effective processes

•   Complete and accurate business records

Nothing frustrates these external parties more than an organization that is disorganized and out of control. When such organizations do produce information, it will be regarded with skepticism, as external parties will wonder if the data was conjured up at the last minute or “cooked” (altered in an attempt to avoid accountability). Such disorganization could even be regarded as a lack of cooperation with a supervisory authority. For instance, GDPR Article 31 reads, “The controller and the processor and, where applicable, their representatives, shall cooperate, on request, with the supervisory authority in the performance of its tasks.”

Supervisory authorities also do not take kindly the responses of organizations that appear disingenuous. Transparency and cooperation is a far better approach—one that can even result in a level of trust between the parties. That said, organizations with something to hide may continue to be uncooperative until the regulator discontinues the inquiry or the organization is backed into a corner and its dishonesty is no longer concealed. The International Association of Privacy Professionals (IAPP) Code of Ethics does not support such behavior.

Privacy and cybersecurity laws often require organizations that store or process personal information to have privacy and security breach procedures. Further, organizations should identify, in advance of any incident or breach, all applicable laws, regulations, and other obligations, and all instances where notification to regulators, supervisory authorities, and affected parties are required should a breach occur. Then, at the onset of an incident or a breach, the organization simply carries out its procedures, which are known and practiced in advance.

Privacy Incident Response

A privacy incident is an event in which one or more data subjects’ personal information has been inappropriately used or disclosed in a manner contrary to applicable laws or regulations. A privacy incident is also an event representing a violation of an organization’s privacy and/or security policy. For instance, if an organization’s privacy policy states that it is not permitted to copy personal information to an external data storage device, the occurrence of such an event would be considered a privacy incident.

Incident Response Regulations

As they develop their incident response procedures, organizations need to understand applicable regulatory requirements and incorporate them into their plans. Most privacy regulations require that organizations inform affected parties of security and privacy breaches, often when specific conditions occur. For instance, the older California privacy law known as SB 1386 required organizations to notify affected parties of breaches and unauthorized access to their personal information (which was defined in detail); however, if the personal information was in an encrypted state when compromised, no notification was required.

In addition to aligning privacy incident response to applicable regulations, organizations should also be familiar with customer expectations, which may differ from regulations. Acts of goodwill can act as a salve on emotionally or financially harmed customers and the organization’s reputation.

Phases of Incident Response

An effective response to a privacy incident is organized, documented, and rehearsed. The phases of a formal incident response plan are explained in this section.

For incident response to be effective, organizations must anticipate that incidents will occur and, accordingly, develop incident response plans, test those plans, and train personnel so that incident response will be effective and timely.

Briefly, the phases of incident response, in order, are

•   Planning

•   Detection

•   Initiation

•   Status updates

•   Analysis

•   Containment

•   Eradication

•   Recovery

•   Remediation

•   Closure

•   Post-incident review

•   Retention of evidence

•   Incident reporting

These phases are discussed in detail in the remainder of this section.

Planning

This step involves the development of written response procedures that are followed when an incident occurs. These procedures are created once the organization’s practices, processes, and technologies are well understood. This helps to ensure that incident response procedures align with the organization’s privacy and security policy, applicable regulations, business operations, the technologies in use, and practices in place regarding architecture, development, management, and operations.

Detection

Detection represents the time when an organization is initially aware that a privacy incident is taking place or has taken place. Because of the variety of events that characterize a privacy incident, an organization can become aware of an incident in several ways, including

•   Application or network slowdown or malfunction

•   Alert from the intrusion detection/prevention system (IDS/IPS), data loss prevention (DLP) system, web filter, cloud access security broker (CASB), and/or other detective and preventive security systems

•   Inquiry or compliant in a data subject request (DSR)

•   Alert from a security incident and event management system (SIEM)

•   Alert from physical security monitoring, including video surveillance and building entrance controls

•   Alerts from an external service provider such as a software as a service (SaaS), platform as a service (PaaS), or infrastructure as a service (IaaS) vendor

•   Alerts from media outlets and their investigators and reports

•   Advisories from open-source intelligence (OSINT) sources

•   Notification from an employee or business partner

•   Anonymous tip

•   Notification from a whistleblower

•   Notification from a credit card brand, bank, or other financial institution

•   Notification from a regulator

•   Notification from law enforcement

Initiation

In this phase, a response to the incident begins. Typically, this will include a declaration of an incident, followed by notifications sent to response team members so that response operations should commence. Notifications are also typically sent to business executives so that they may also be informed.

Many organizations’ incident response plans classify incidents by severity or impact, with varying forms and levels of internal communications associated with each classification. At times, the severity level may be changed as more is learned in later stages of incident response.

Status Updates

From the onset, the incident response team should have established methodologies, formats, frequencies, and recipients of regular status updates to keep management and others informed as the incident investigation unfolds, progresses, and leads to containment, eradication, recovery, remediation, and closure. Generally, higher severity incidents warrant more frequent status reporting and to higher levels of management. The format of reporting must consider the audience so that the content of status reports is suitable for every audience. Often, this requires multiple layers of status reporting, each targeting respective audiences.

Status updates should be marked or labeled at a sufficiently high classification level to apply the greatest possible protection.

Analysis

In this phase, response team members analyze available data to understand the cause, scope, and impact of the incident. This may involve the use of forensic analysis tools to understand activities on individual systems. Because many organizations lack computer forensics tools and expertise, outside experts are often summoned to perform forensics to understand the full nature and scope of an incident.

Containment

Incident responders perform or direct actions that halt the progress or advancement of an incident in this phase. The steps required to contain an incident will vary according to the means used by the attacker. Sometimes, outside experts are called upon to assist with containment efforts.

Eradication

In this phase of incident response, responders take steps to remove the source of the incident. This could involve removing malware, blocking incoming attack messages, or changing users’ access privileges on one or more systems.

Recovery

When the incident has been evaluated and eradicated, systems or components may need to be restored/recovered to their pre-incident state. This may include restoring data or configurations or replacing damaged or stolen equipment.

Remediation

This phase involves any necessary changes that will reduce or eliminate the possibility of a similar incident occurring in the future. This may take the form of process or technology changes.

Closure

Closure occurs when eradication, recovery, and remediation are completed. Incident response operations are officially closed.

Post-Incident Review

Shortly after the incident closes, incident responders and other personnel will meet to discuss the incident: its cause, its impact, and the organization’s response. The discussion will range from lessons learned to possible improvements in technologies and processes to develop better defense and response.

Retention of Evidence

Incident responders and other personnel will direct the retention of evidence and other materials used or collected during the incident. This may include information that may be used in legal proceedings, including prosecution, civil lawsuits, and internal investigations. A chain of custody may be required to ensure evidence integrity.

Incident Reporting

Privacy and security leaders should collect metrics on privacy and security incidents large and small, and then report these, together with numerous other metrics, to executive management as an overall part of its governance. Some of the metrics that should be kept and reported include the following:

•   Number of incidents at each severity level

•   Time required to detect and respond to incidents (this should be measured in minutes, not hours or days)

•   Improvements made as a result of post-incident reviews

•   Reviews and updates of incident response plans

•   Incident responder training

•   Improvements in incident detection

Privacy Incident Response Plan Development

Effective incident response plans take time to develop. A privacy manager developing an incident response plan must first thoroughly understand business processes, privacy policy, data flows, and underlying information systems, and then discover resource requirements, dependencies, and failure points. A privacy manager may first develop a high-level incident response plan, which is usually followed by developing several incident response playbooks, the step-by-step instructions to follow when specific incidents occur.

Resources

Before developing privacy incident response procedures, a privacy manager must identify required and available resources for incident detection and response. Perhaps the most important resource is the organization’s security incident response plan. A correctly designed security incident response plan will recognize and respond to incidents, including information misuse, theft, and destruction. Two elements are needed to develop a privacy incident response plan:

•   Callouts to privacy incident responders, so that they may orchestrate notifications to regulators and affected parties as required by applicable laws and regulations

•   Detection and response to incidents of misuse of personal information that are not themselves security incidents

Besides these, other resources that privacy managers need to identify include

•   Privacy incident response personnel, beyond those workers identified as security incident responders, who will be responsible for examining information systems to understand the nature of a “misuse of personal information” incident

•   Forensics capabilities, including chain of custody procedures, which will ensure that evidence retention is robust if a privacy incident may involve notifications to outside parties

•   Attorney–client privilege, to ensure that incident response communications and records are protected

•   Contact information and methods for regulators and supervisory authorities

•   Prewritten notifications to regulators, supervisory authorities, affected parties, and the public

Roles and Responsibilities

Responding to a privacy or security incident can be complicated; this makes it important for everyone to understand their roles and those of others. Roles and responsibilities should be documented in an organization’s privacy and security incident response plans. Here is a typical arrangement:

•   Incident commander Coordinate hour-by-hour activities and resources, and identify specific personnel and resources required to work through incident stages. In a longer incident with response occurring over extended hours, this will need to be a “shift” position so that responders do not suffer exhaustion.

•   Incident responder Perform the hands-on steps of incident response to identify its cause, contain and eradicate it, and make any adjustments necessary to prevent a recurrence of the incident or a similar one. One or more trained experts in various processes and technologies who are familiar with each incident’s processes or technologies can serve as incident responders. They can be employees of the organization or outside experts in incident response or computer and network forensics.

•   Scribe Record (generally, note-taking versus actual voice recordings) discussions, decisions, resources used, and outside parties (such as vendors) contacted.

•   Legal counsel Interpret and determine the applicability of laws and regulations (during plan development) and make decisions on notifications of external parties. External legal counsel can be retained as required for subject matter expertise and management of attorney–client privilege if used.

•   Privacy officer Lead and guide privacy team, possibly including incident responders, and ensure that privacy is upheld during incident response. This could be considered a co-management role alongside the incident commander (the privacy officer could also be the incident commander) and may also be the party to communicate with regulators as directed by applicable laws.

•   Cybersecurity officer Lead and guide the security team, possibly including incident responders. Ensure that security is intact during incident response. This could be considered a co-management role alongside the incident commander (the security officer could also be considered for the incident commander role).

•   CIO Provide IT staff resources, possibly including incident responders. Lead the continued operation of IT systems during the incident, including potential disaster recovery operations.

•   Business unit leaders Manage business unit and department business operations, including those affected by the incident. Carry out business continuity plans as applicable if primary processing systems are unavailable or untrusted.

•   Crisis communications Coordinate internal communications as required (generally needed only in larger organizations).

•   Public relations or public information officer (PIO) Compose press releases (during plan development), finalize and release tailored press releases, and notify external parties (often through a specialized service).

•   Business continuity and disaster recovery The nature of a major privacy or security incident may necessitate the initiation of business continuity and/or disaster recovery plans if primary information systems are unavailable or untrusted.

Incident Response Playbooks

More mature organizations will have developed numerous (as many as a dozen or more) playbooks, detailed procedures to be followed when specific types of security incidents occur. Typical playbook scenarios include ransomware, denial of service, a lost or stolen laptop or mobile device, destructive malware, compromise of a user account, and more.

Privacy incident response plans need playbooks as well, since many privacy incidents are not data protection security incidents per se, but instead represent the misuse of personal information. Thus, privacy managers developing privacy incident response plans need to develop additional response playbooks so that privacy incident responders can quickly work through investigation, containment, and recovery steps. A privacy incident is not the time to learn how a specific system works, where its logs reside (and how to read and interpret them), and how to run reports to understand the steps that resulted in the incident. Better organizations develop these playbooks in advance, so that incident responders can quickly determine what happened, why it happened, and who was involved.

Response Plan Tabletop Testing

When privacy incident response plans (and playbooks) have been developed, they need to be tested in one or more tabletop exercises. These facilitated discussions are led by an experienced incident responder who walks personnel through a typical privacy incident scenario step by step. At the same time, participants read their privacy incident response plans and discuss the steps they’d be taking if a real incident were taking place.

External Review

Many organizations realize that outside experts should review response plans and other procedures developed internally. Such reviews can draw upon the knowledge and experience of external parties, who can provide objective reviews of privacy and security response plans. Compared to the cost of incident response and subsequent developments, the cost of engaging an expert consultant is nominal.

Privacy Continuous Improvement

The philosophy of continuous improvement is a mainstay of quality-oriented organizations. Rather than assume that all of an organization’s processes, procedures, controls, and other operations are operating at an optimum level, a more realistic approach is the idea that there is always room for meaningful improvement.

Continuous improvement is primarily concerned with the fact of process and control improvement rather than the appearance of improvement. Still, an organization should consider all of its privacy and security programs’ operations as “works in progress,” meaning that management and staff recognize that their processes and controls have not achieved a level of perfection, and likely never will.

An organization can improve processes and controls in the following ways:

•   Accuracy Organization strives to improve its controls and processes so that fewer exceptions and errors occur.

•   Efficiency Organization will seek opportunities to make controls and processes more efficient, so that they will take less effort or require fewer resources while still maintaining quality objectives.

•   Timeliness Organization will seek ways to make controls and processes more responsive so that routine and nonroutine tasks take less time to complete.

•   Risk Organization will look for ways to reduce risks in controls and processes to ensure fewer opportunities for incidents.

Continuous improvement is so important that it is officially a requirement in ISO/IEC 27001:2013. Requirement 10.2 of the standard reads, “The organization shall continually improve the suitability, adequacy and effectiveness of the information security management system.” Similarly, ISO/IEC 27701 (Security techniques – Extension to ISO/IEC 27001 and ISO/IEC 27002 for privacy information management – Requirements and guidelines) requirement 5.8 extends this to include the privacy information management system.

Chapter Review

Modern data privacy laws require transparency concerning not only the collection and use of personal data, but also concerning the ability to provide one or more means for data subjects to make inquiries and requests regarding the use of their personal information. Such requests include offering a process by which data subjects can contact organizations to inquire about the use of their personal data, to enact corrections to their personal information, to lodge complaints, to request that their information be transferred to another similar organization, and to request that their identity be removed from an organization’s records.

Data subject requests (DSRs) are the inquiries and requests that persons may lodge with organizations. Reasons for DSRs include requests to change information, to understand how personal data is being used, to opt out of one or more functions, or to request their data be removed altogether.

A request for an update or correction can rise to the level of redress. In this case, an organization has made a decision detrimental to the data subject, who requests that the organization correct the situation to make the data subject whole.

An organization is obligated to process a “right to be forgotten” request under the GDPR as long as laws forbid the removal of such information.

Many privacy laws provide for the creation of government authorities that act in a supervisory capacity to enforce these laws. For instance, Articles 51 through 54 of the GDPR define supervisory authorities and their responsibilities. The CPRA, passed in 2020 by ballot measure, provides for the creation of the California Privacy Protection Agency to enforce the CCPA and additional privacy provisions in the CPRA itself.

A privacy incident is an event in which one or more data subjects’ personal information has been inappropriately used or disclosed in a manner contrary to applicable laws or regulations.

The phases of incident response are planning, detection, initiation, status updates, analysis, containment, eradication, recovery, remediation, closure, post-incident review, retention of evidence, and incident reporting. Evidence needs to be retained for a specified period.

Because privacy and security incident response techniques are so similar, it may be prudent to combine them into a single process.

Roles and responsibilities should be documented in an organization’s privacy and security incident response plans.

Quick Review

•   Depending upon the language of applicable laws and the complexity of the organization, an organization receiving a DSR may need to search through multiple business records or systems to create a complete response to the data subject.

•   In some jurisdictions, data subjects have the right to object to automatic subject profiling and automated decision-making processes.

•   Most privacy regulations require that organizations inform affected parties of security and privacy breaches, often when specific conditions occur.

•   Although each organization’s privacy incident response plan will vary, an incident is typically confirmed either in the initiation or analysis phase. At that time, organizations may be required to notify regulators, supervisory authorities, or affected parties.

•   Higher severity incidents warrant more frequent status reporting and to higher levels of management. The format of reporting must consider the audience, so that the content of status reports is suitable for every audience. Often, this requires multiple layers of status reporting, each targeting respective audiences.

•   Some organizations direct all communications and status updates to inside or outside legal counsel, so that status updates are protected by attorney–client privilege.

•   Forensic experts should be chosen carefully, as artifacts of their work could be included in subsequent legal proceedings.

•   Because many privacy incidents are also security incidents, the development of a privacy incident response plan should be performed in close cooperation with the security manager to avoid duplication of effort and utilize existing response plan resources and practices.

•   More mature organizations will have developed numerous (as many as a dozen or more) playbooks, which are detailed procedures to be followed when specific types of security incidents take place. Typical playbook scenarios include ransomware, denial of service, lost or stolen laptop or mobile device, destructive malware, compromise of a user account, and more.

Questions

1. A tabletop exercise is:

A. A risk analysis to predict an incident

B. A recap of a recent incident

C. A simulation of an actual incident

D. A test of forensic capabilities

2. An organization has received a data subject’s request to remove all personal information on file. How should the organization respond?

A. Pseudonymize the data subject’s personal information.

B. Anonymize the data subject’s personal information.

C. Remove or anonymize the data subject’s personal information.

D. Remove or anonymize the data subject’s personal information as permitted by other applicable laws.

3. An organization wants to exempt records for any future security or privacy incidents from discovery requests. What should be included in security and privacy incident response plans to accomplish this?

A. Change the data retention policy.

B. Turn off dynamic DLP for the directories where incident records are stored.

C. Retain outside legal counsel.

D. Implement attorney–client privilege.

4. Program responsibilities for the activities of managing data subject requests lie with:

A. Customer support

B. The chief marketing officer

C. The chief information security officer

D. The chief privacy officer

5. In a privacy breach response plan, who should be making decisions on whether (and when) to notify authorities and affected parties?

A. Privacy officer

B. Public relations

C. Legal counsel

D. Crisis communications

6. The role of privacy incident commander is:

A. Develop the privacy incident response plan

B. Coordinate privacy incident proceedings

C. Decide when authorities should be notified

D. Determine incident response roles and responsibilities

7. The purpose of a post-incident review is:

A. Identify improvement opportunities

B. Identify mistakes made during an incident

C. Determine how long it took to respond

D. Review forensic techniques used

8. How long should evidence and records related to a specific privacy incident be retained?

A. One year

B. According to the data retention schedule

C. Seven years

D. According to the data destruction schedule

9. While gathering and examining various privacy-related business records, the privacy officer has determined that the organization has no privacy or security incident log. What conclusion can the privacy officer make from this?

A. The organization does not have privacy or security incident detection capabilities.

B. The organization has not yet experienced a privacy or security incident.

C. The organization is recording privacy or security incidents in its risk register.

D. The organization has effective privacy policies.

10. An organization requests that each data subject submit an image of his or her driver’s license as a means of authentication when submitting data subject requests. Should subsequent data subject requests cite the driver’s license as collected information?

A. Yes, because authentication data is always subject to data access requests.

B. No, because the driver’s license was collected outside of the collection period.

C. No, because information submitted as a part of authentication is exempt.

D. Yes, because the data subject’s driver’s license was collected by the organization.

11. An incident response team is in the process of responding to an incident. The incident responders have removed the malware and blocked command-and-control traffic. At this stage, the source of the incident has been:

A. Contained

B. Eradicated

C. Remediated

D. Recovered

12. What is generally the best approach when working with authorities?

A. Delay for as long as legally permissible.

B. Slowly and progressively provide requested information.

C. Cooperate and act with transparency.

D. Delay for as long as possible.

13. Which of the following methods should an organization provide as means for customers to make inquiries and complaints about privacy matters?

A. Telephone

B. E-mail address

C. Postal mail

D. All of these

14. What is the best method for ensuring that privacy incident responders are familiar with incident response procedures?

A. Include incident responders in tabletop testing.

B. Direct incident responders to develop incident response plans.

C. Direct incident responders to respond to the next incident.

D. Direct incident responders to review incident response plans.

15. The best definition of a data subject request is:

A. A request to be removed from all business records

B. A request to be added to sales and marketing communication

C. A request to be removed from sales and marketing communication

D. An inquiry or request concerning the use of a subject’s personal information

Answers

1. C. A tabletop exercise is a simulation of a real incident, whether a privacy incident, a security incident, an outage, or a disaster. Tabletop exercises for privacy and security incident response should take place at least once per year.

2. D. The organization may proceed with the data subject’s data removal request, provided that there are no other laws requiring the retention of this information. For example, banks are typically not permitted to remove financial records for current or former customers.

3. D. With guidance from the organization’s legal counsel, invoking attorney–client privilege and following certain procedures regarding communications can help to protect incident response records from being discovered in future legal proceedings.

4. D. The chief privacy officer has primary responsibility for the organization’s receipt of, processing of, and response to data subject requests. Other departments may have operational responsibilities in the management of these requests, but the ultimate accountability lies with the CPO.

5. C. Legal counsel should decide when and how regulatory authorities, affected parties, and others should be notified in the event of a privacy or security breach.

6. B. A privacy incident commander’s role is to coordinate and direct incident response proceedings using the plan that has been documented.

7. A. The purpose of a post-incident review is to identify what went well and what improvements can be made—both in terms of incident response procedures as well as with the systems or processes affected.

8. B. An organization’s data retention schedule (which should align with applicable laws) should determine how long evidence and records from an incident should be retained.

9. A. An organization that does not have a privacy or security incident log probably lacks the capability to detect and respond to an incident. It is not reasonable to assume that the organization has experienced no incidents, because minor incidents occur with regularity. Claiming that the organization has effective controls is unreasonable, because it is understood that incidents occur even when effective controls are in place (because not all types of incidents can reasonably be prevented).

10. D. Personal information, including the image of a driver’s license or other government-issued identification, that is collected by an organization for any reason must be disclosed to a data subject who inquires about what information an organization has collected.

11. B. Eradication is the point at which the agent causing an incident (in this case, malware) has been removed from one or more systems.

12. C. Cooperation, collaboration, and transparency are generally better approaches when working with regulators, particularly during an inquiry or investigation. Stalling or delaying proceedings may draw suspicion even when none is otherwise warranted.

13. D. All of the methods described—telephone, e-mail, and postal mail—are valid means for customers to make inquiries and lodge complaints regarding their privacy.

14. A. The best method for incident responders to become familiar with incident response plans is for them to participate in tabletop exercises.

15. D. A data subject request (DSR) can be any form of an inquiry, request, or complaint regarding an organization’s use of the data subject’s personal information.