Abstract: In particular embodiments, a consent conversion optimization system is configured to test two or more test consent interfaces against one another to determine which of the two or more consent interfaces results in a higher conversion percentage (e.g., to determine which of the two or more interfaces lead to a higher number of end users and/or data subjects providing a requested level of consent for the creation, storage and use or cookies by a particular website). The system may, for example, analyze end user interaction with each particular test consent interface to determine which of the two or more user interfaces: (1) result in a higher incidence of a desired level of provided consent; (2) are easier to use by the end users and/or data subjects (e.g., take less time to complete, require a fewer number of clicks, etc.); (3) etc.

Abstract: In various embodiments, a Consent Refresh, Re-Prompt, and Recapture System is configured to interface with a Consent Receipt Management System in order to, for example: (1) monitor previously provided consent by one or more data subjects that may be subject to future expiration; (2) monitor a data subject's activity to anticipate the data subject attempting an activity that may require a level of consent (e.g., for the processing of particular data subject data) that is higher than the system has received; and/or (3) identify other changes in circumstances or triggering events for a data subject that may warrant a refresh or recapture (e.g., or attempted capture) of a particular required consent (e.g., required to enable an entity to properly or legally execute a transaction with a data subject). The system may then be configured to automatically refresh, re-prompt for, and/or recapture consent as necessary.

Abstract: A data processing central consent repository system may be configured to, for example: (1) identify a form used to collect one or more pieces of personal data, (2) determine a data asset of a plurality of data assets of the organization where input data of the form is transmitted, (3) add the data asset to the third-party data repository with an electronic link to the form, (4) in response to a user submitting the form, create a unique subject identifier to submit to the third-party data repository and, along with the form data provided by the user in the form, to the data asset, (5) submit the unique subject identifier and the form data provided by the user to the third-party data repository and the data asset, and (6) digitally store the unique subject identifier and the form data in the third-party data repository and the data asset.

Abstract: In particular embodiments, a Data Transfer Risk Identification System may be configured to analyze one or more data systems (e.g., data assets), identify data transfers between/among those systems, apply data transfer rules to each data transfer record, perform a data transfer assessment on each data transfer record based on the data transfer rules to be applied to each data transfer record, and calculate a risk score for the data transfer based at least in part on the one or more data transfer risks associated with the data transfer record.

Abstract: Data processing systems and methods, according to various embodiments, are adapted for automatically assessing the level of security and/or privacy risk associated with doing business with a particular vendor or other entity. In various embodiments, the systems may automatically obtain and use any suitable information to assess such risk levels including, for example: (1) any security and/or privacy certifications held by the vendor; (2) the terms of one or more contracts between a particular entity and the vendor; (3) the results of one or more privacy impact assessments for the vendor; and/or (4) any other suitable data.

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: Data processing systems and methods according to various embodiments are adapted for automatically detecting and documenting privacy-related aspects of computer software. Particular embodiments are adapted for: (1) automatically scanning source code to determine whether the source code include instructions for collecting personal data; and (2) facilitating the documentation of the portions of the code that collect the personal data. For example, the system may automatically prompt a user for comments regarding the code. The comments may be used, for example, to populate: (A) a privacy impact assessment; (B) system documentation; and/or (C) a privacy-related data map. The system may comprise, for example, a privacy comment plugin for use in conjunction with a code repository.

Abstract: A data processing system, according to various embodiments, may receive a data subject access request that includes a request to delete personal data of a particular data subject, modify personal data of the data subject, and/or provide personal data of the data subject. At least partially in response to receiving the data subject access request, the system may determine whether the data subject access request was initiated by an automated source. At least partially in response to determining that the data subject access request was initiated by an automated source, the system may automatically take at least one action to have the data subject access request reinitiated by a human source. At least partially in response to determining that the data subject access request was initiated by a human, the system may automatically facilitate the fulfillment of the data subject access request.

Abstract: In various embodiments, a system may be configured to analyze data for a particular consent capture point to identify a change in consent capture rate from the capture point. The system may, for example, be configured to automatically detect that the system has stopped receiving consent records from a particular capture point. In such embodiments, the system may be configured to generate an alert, and transmit the alert to any suitable individual (e.g., privacy team member, IT department member, etc.) regarding the capture point. The system may, for example, enable an entity to identify one or more capture points that may have become non-functional (e.g., as a result of one or more changes to the capture point).

Abstract: A consent receipt management system may, for example, be configured to track data on behalf of an entity that collects and/or processes persona data related to: (1) who consented to the processing or collection of personal data; (2) when the consent was given (e.g., a date and time); (3) what information was provided to the consenter at the time of consent (e.g., a privacy policy, what personal data would be collected following the provision of the consent, for what purpose that personal data would be collected, etc.); (4) how consent was received (e.g., one or more copies of a data capture form, webform, etc. via which consent was provided by the consenter); (5) when consent was withdrawn (e.g., a date and time of consent withdrawal if the consenter withdraws consent); and/or (6) any other suitable data related to receipt or withdrawal of consent.

Abstract: In particular embodiments, an Orphaned Data Action System is configured to analyze one or more data systems (e.g., data assets), identify one or more pieces of personal data that are one or more pieces of personal data that are not associated with one or more privacy campaigns of the particular organization, and notify one or more individuals of the particular organization of the one or more pieces of personal data that are one or more pieces of personal data that are not associated with one or more privacy campaigns of the particular organization.

Abstract: A centralized data repository system, in various embodiments, is configured to provide a central data-storage repository (e.g., one or more servers, databases, etc.) for the centralized storage of personally identifiable information (PII) and/or personal data for one or more particular data subjects. In particular embodiments, the centralized data repository may enable the system to populate one or more data models (e.g., using one or more suitable techniques described above) substantially on-the-fly (e.g., as the system collects, processes, stores, etc. personal data regarding a particular data subject). In this way, in particular embodiments, the system is configured to maintain a substantially up-to-date data model for a plurality of data subjects (e.g., each particular data subject for whom the system collects, processes, stores, etc. personal data).

Abstract: In particular embodiments, a Personal Data Deletion System is configured to: (1) at least partially automatically identify and delete personal data that an entity is required to erase under one or more of the conditions discussed above; and (2) perform one or more data tests after the deletion to confirm that the system has, in fact, deleted any personal data associated with the data subject. The system may, for example, be configured to test to ensure the data has been deleted by: (1) submitting a unique token of data through a form to a system; (2) in response to passage of an expected data retention time, test the system by calling into the system after the passage of the data retention time to search for the unique token.

Abstract: Data processing systems and methods, according to various embodiments, are adapted for efficiently processing data to allow for the streamlined assessment of risk ratings for one or more vendors. In various embodiments, the systems/methods may use one or more particular vendor attributes (e.g., as determined from scanning one or more webpages associated with the particular vendor) and the contents of one or more completed privacy templates for the vendor to determine a vendor risk rating for the particular vendor. As a particular example, the system may scan a website associated with the vendor to automatically determine one or more security certifications associated with the vendor and use that information, along with information from a completed privacy template for the vendor, to calculate a vendor risk rating that indicates the risk of doing business with the vendor.

Abstract: Data processing systems and methods, according to various embodiments are adapted for efficiently processing data to allow for the streamlined assessment of the risk level associated with particular privacy campaigns. The systems may provide a centralized repository of templates of privacy-related question/answer pairings for various vendors, products (e.g., software products), and services. Different entities may electronically access the templates (which may be periodically updated and centrally audited) and customize the templates for evaluating the risk associated with the entities' respective business endeavors that involve the relevant vendors, products, or services.

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: A consent receipt management and data processing system may be configured to provide a centralized repository of consent receipt preferences for a plurality of data subjects. In various embodiments, the system is configured to provide an interface to the plurality of data subjects for modifying consent preferences and capture consent preference changes. The system may provide the ability to track the consent status of pending and confirmed consents. In other embodiments, the system may provide a centralized repository of consent receipts that a third-party system may reference when taking one or more actions related to a processing activity.

Abstract: Computer-readable mediums, according to various embodiments, store computer-executable instructions for: (1) scanning computer code to determine what types of personal information the computer code collects or analyzes; (2) prompting a first one or more individuals for information regarding this aspect of the computer code (e.g., why the computer code is collecting the personal information); (3) communicating this information to a second set of one or more individuals; (4) receiving, from the second set of individuals, a recommended revision to the computer code that would facilitate the compliance of the computer code with one or more privacy standards; (5) facilitating the implementation of the revision; and (6) after the revision has been completed, generating an updated privacy assessment for the computer code that reflects the fact that the one or more revisions have been completed; and (7) generating a report listing the one or more revisions that have been completed.

Abstract: In various embodiments, a data map generation system is configured to: (1) enable a user to specify one or more criteria; (2) identify one or more data flows based at least in part on the one or more specified criteria; (3) generate a data map based at least in part on the identified one or more data flows; and (4) display the data map to any suitable individual (e.g., the user). In particular embodiments, the system is configured to display all data flows associated with a particular organization that are stored within the system. In other embodiments, the system is configured to display all data flows that are associated with a particular privacy campaign undertaken by the organization.