Abstract: In various embodiments, a system may be configured to substantially automatically determine whether to take one or more actions in response to one or more identified risk triggers (e.g., data breaches, regulation change, etc.). The system may, for example: (1) compare the potential risk trigger to one or more previous risks triggers experienced by the particular entity at a previous time; (2) identify a similar previous risk trigger (e.g., one or more previous risk triggers related to a similar change in regulation, breach of data, type of issue identified, etc.); (3) determine the relevance of the current risk trigger based at least in part on a determined relevance of the previous risk trigger; and (4) determine whether to take one or more actions to the current risk trigger based at least in part on one or more determined actions to take in response to the previous, similar risk trigger.

Abstract: In particular embodiments, a data subject request processing system may be configured to utilize one or more local storage nodes in order to process a data subject access request on behalf of a data subject. In particular embodiments, the one or more local storage nodes may be local to the data subject making the request (e.g., in the same country as the data subject, in the same jurisdiction, in the same geographic area, etc.). The system may, for example, be configured to: (1) receive a data subject access request from a data subject (e.g., via a web form); (2) identify a suitable local storage node based at least in part on the request and/or the data subject; (3) route the data subject access request to the identified local storage node; and (4) process the data subject access request at the identified local storage node.

Abstract: Responding to a data subject access request includes receiving the request and validating an identity of the requestor. In response to validating the identity of the requestor, a computer processor determines whether the data subject access request is subject to fulfillment constraints. If so, then the computer processor notifies the requestor that the data subject access request is subject to one or more limitations and the computer processor takes action based on those limitations. Fulfillment constraint data is updated and maintained in a database or server.

Abstract: A particular organization may undertake a plurality of different privacy campaigns, processing activities, etc. that involve the collection and storage of personal data. The system may be configured to collect customer satisfaction data, for example: (1) as part of a data subject access request submission form; (2) when providing one or more results of a data subject access request to the data subject; or (3) at any other suitable time. The customer satisfaction data may be collected in the form of a suitable survey, free-form response questionnaire, etc. (e.g., thumbs up vs. thumbs down, etc.). Additionally, by integrating a feedback survey with the data subject access request process, the system may increase a number of consumers that provide responses to the feedback survey. In particular embodiments, the system is configured to require the requestor to respond to the feedback survey prior to submitting the data subject access request.

Abstract: Computer systems and methods for: (1) analyzing electronic correspondence associated with a data subject (e.g., the emails within one or more email in-boxes associated with the data subject); (2) based on the analysis, identifying at least one entity that that the data subject does not actively do business with (e.g., as evidenced by the fact that the data subject no longer opens emails from the entity, and/or has set up a rule to automatically delete emails received from the entity); and (3) in response to identifying the entity as an entity that the data subject no longer does business with, at least substantially automatically populating and/or submitting a data subject access request to the entity (e.g., to delete all personal information being processed by the entity).

Abstract: In particular embodiments, in response a data subject submitting a request to delete their personal data from an organization's systems, the system may: (1) automatically determine where the data subject's personal data is stored; (2) in response to determining the location of the data (which may be on multiple computing systems), automatically facilitate the deletion of the data subject's personal data from the various systems; and (3) determine a cause of the request to identify one or more processing activities or other sources that result in a high number of such requests.

Abstract: In particular embodiments, in response a data subject submitting a request to delete their personal data from an organization's systems, the system may: (1) automatically determine where the data subject's personal data is stored; and (2) in response to determining the location of the data (which may be on multiple computing systems), automatically facilitate the deletion of the data subject's personal data from the various systems (e.g., by automatically assigning a plurality of tasks to delete data across multiple business systems to effectively delete the data subject's personal data from the systems).

Abstract: In particular embodiments, in response a data subject submitting a request to delete their personal data from an organization's systems, the system may: (1) automatically determine where the data subject's personal data is stored; and (2) in response to determining the location of the data (which may be on multiple computing systems), automatically facilitate the deletion of the data subject's personal data from the various systems (e.g., by automatically assigning a plurality of tasks to delete data across multiple business systems to effectively delete the data subject's personal data from the systems).

Abstract: In particular embodiments, a Data Access Webform Crawling System is configured to: (1) identify a webform used to collect one or more pieces of personal data; (2) robotically complete the identified webform; (3) analyze the completed webform to determine one or more processing activities that utilize the one or more pieces of personal data collected by the webform; (4) identify a first data asset in the data model that is associated with the one or more processing activities; (5) modify a data inventory for the first data asset in the data model to include data associated with the webform; and (6) modify the data model to include the modified data inventory for the first data asset.

Abstract: In particular embodiments, a Cross-Border Visualization Generation System is configured to analyze one or more data systems (e.g. data assets), identify data transfers between/among those systems, determine whether any particular regulations apply to the identified data transfers, and generate a visual representation of physical locations of the one or more data systems and the one or more data transfers between them. The system may, for example, color-code one or more lines or indicators showing a transfer of data between a first and second data system The one or more indicators may convey, for example: (1) whether the data transfer is secure; (2) a type or level of security that is applied to the transfers; (3) one or more regulations that apply to the transfer, and/or (4) any other suitable information related to the transfer of particular data between the first and second data system.

Abstract: In particular embodiments, a data subject request processing system may be configured to utilize one or more local storage nodes in order to process a data subject access request on behalf of a data subject. In particular embodiments, the one or more local storage nodes may be local to the data subject making the request (e.g., in the same country as the data subject, in the same jurisdiction, in the same geographic area, etc.). The system may, for example, be configured to: (1) receive a data subject access request from a data subject (e.g., via a web form); (2) identify a suitable local storage node based at least in part on the request and/or the data subject; (3) route the data subject access request to the identified local storage node; and (4) process the data subject access request at the identified local storage node.

Abstract: In particular embodiments, a data processing data inventory generation system is configured to: (1) generate a data model (e.g., a data inventory) for one or more data assets utilized by a particular organization; (2) generate a respective data inventory for each of the one or more data assets; and (3) map one or more relationships between one or more aspects of the data inventory, the one or more data assets, etc. within the data model. In particular embodiments, a data asset (e.g., data system, software application, etc.) may include, for example, any entity that collects, processes, contains, and/or transfers personal data (e.g., such as a software application, “internet of things” computerized device, database, website, data-center, server, etc.). For example, a first data asset may include any software or device (e.g., server or servers) utilized by a particular entity for such data collection, processing, transfer, storage, etc.

Abstract: In particular embodiments, a data processing data inventory generation system is configured to: (1) generate a data model (e.g., a data inventory) for one or more data assets utilized by a particular organization; (2) generate a respective data inventory for each of the one or more data assets; and (3) map one or more relationships between one or more aspects of the data inventory, the one or more data assets, etc. within the data model. In particular embodiments, a data asset (e.g., data system, software application, etc.) may include, for example, any entity that collects, processes, contains, and/or transfers personal data (e.g., such as a software application, “internet of things” computerized device, database, website, data-center, server, etc.). For example, a first data asset may include any software or device (e.g., server or servers) utilized by a particular entity for such data collection, processing, transfer, storage, etc.

Abstract: In particular embodiments, a data processing data inventory generation system is configured to: (1) generate a data model (e.g., a data inventory) for one or more data assets utilized by a particular organization; (2) generate a respective data inventory for each of the one or more data assets; and (3) map one or more relationships between one or more aspects of the data inventory, the one or more data assets, etc. within the data model. In particular embodiments, a data asset (e.g., data system, software application, etc.) may include any entity that collects, processes, contains, and/or transfers personal data (e.g., a software application, database, website, server, etc.). A data asset may include any software or device (e.g., server or servers) utilized by a particular entity for such data collection, processing, transfer, storage, etc. The system may then utilize the generated model to fufill a data subject access request.

Abstract: In various embodiments, fulfilling a data subject access request may be particularly costly. In some embodiments, a company may store data regarding a particular data subject in multiple different locations for a plurality of different reasons as part of a plurality of different processing and other business activities. For example, a particular data subject may be both a customer and an employee of a particular company or organization. Accordingly, in some embodiments, fulfilling a data subject access request for a particular data subject may involve a plurality of different information technology (IT) professionals in a plurality of different departments of a particular company or organization. As such, it may be useful to determine a cost of a particular data subject access request (e.g., particularly because, in some cases, a data subject is entitled to a response to their data subject access request as a matter of right at no charge).

Abstract: A privacy management system that is configured to process one or more data subject access requests and further configured to: (1) enable a data protection officer to submit an audit request; (2) perform an audit based on one or more parameters provided as part of the request (e.g., one or more parameters such as how long an average request takes to fulfill, one or more parameters related to logging and/or tracking data subject access requests and/or complaints from one or more particular customer advocacy groups, individuals, NGOs, etc.); and (3) provide one or more audit results to the officer (e.g., by displaying the results on a suitable display screen).

Abstract: In various embodiments, a data subject request fulfillment system may be adapted to prioritize the processing of data subject access requests based on metadata of the data subject access request. For example, the system may be adapted for: (1) in response to receiving a data subject access request, obtaining metadata regarding the data subject; (2) using the metadata to determine whether a priority of the data subject access request should be adjusted based on the obtained metadata; and (3) in response to determining that the priority of the data subject access request should be adjusted based on the obtained metadata, adjusting the priority of the data subject access request.

Abstract: In particular embodiments, a computer-implemented data processing method for responding to a data subject access request comprises: (A) receiving a data subject access request from a requestor comprising one or more request parameters; (B) validating an identity of the requestor by prompting the requestor to identify information associated with the requestor; (C) in response to validating the identity of the requestor, processing the request by identifying one or more pieces of personal data associated with the requestor, the one or more pieces of personal data being stored in one or more data repositories associated with a particular organization; and (D) taking one or more actions based at least in part on the data subject access request, the one or more actions including one or more actions related to the one or more pieces of personal data.

Abstract: In various embodiments, before a data subject request can be processed, the data subject's identity may need to be verified. In various embodiments, the system provides a mechanism to automatically detect the type of authentication required for a particular data subject based on the type of Data Subject Access Request being made and automatically issues a request to the data subject to verify their identity against that form of identification. For example, a subject rights request might only require two types of authentication, but a deletion request may require four types of data to verify authentication. The system may automatically detect which is type of authentication is required based on the DSAR and send an appropriate request to the data subject to verify their identity.

Abstract: A privacy management system that is adapted for, in the course of processing a particular data subject access request, automatically determining a type of the data subject access request, such as: (1) a request to delete personal data of the requestor that is being stored by a particular organization; (2) a request to provide, to the requestor, personal data of the requestor that is being stored by the particular organization; (3) a request to update personal data of the requestor that is being stored by the particular organization; and (4) a request to opt out of having the particular organization use the requestor's personal information in one or more particular ways. After making this determination, the system may determine, based on the determined type of data subject access request, a particular workflow to follow in authenticating the data subject before fulfilling the data subject access request.