|
Consider the following GDPR tips, regarding personal data disposal: •GDPR Article 17 (right to erasure / to be forgotten), emphasize on the possibility for individuals to have their personal data erased and no longer used by a Data Controller. |
Individuals may choose to opt out at any time, so that personal data is erased and no longer managed for the purpose stated by the Data Controller.
However and because personal data may reside both inside cases of processes and related to records in the WFUser entity, you should never delete records per se (for instance, deleting records may end up producing data integrity issues, regarding references in other records).
It is strongly recommended to obfuscate data instead, as described below.
Data obfuscation
Data obfuscation is a form of masking data so that is is scrambled and rendered unintelligible on purpose.
This is a helpful measure that results in encrypting sensitive data and mitigate unwanted access to it.
For the purpose of obfuscating data, Bizagi offers diverse options, among which there is an option for admins in the Work Portal, and new functions in the rules API.
All of them you will need to consider according to your processes and individuals' requests.
Refer to how to obfuscate the different data and scenarios as described below.
1. Obfuscating personal data of end users
There is an option in the Work Portal which allows an authorized administrator to manually obfuscate information of a given end user.
This is applicable to end users that work on processes (that is, those recorded in the WFUser entity).
The procedure obfuscates all of Bizagi's default user properties. Thus, customized user properties are not obfuscated.
To use the procedure, an administrator uses User management menu and searches for a given user:
Then, by clicking the "Anonymize" icon, the administrator proceeds to confirm if he/she wishes to obfuscate the personal data related to this specific user:
Consider that once you confirm, such data will be rendered unintelligible without the possibility of undoing it.
Even though the end user's picture will be set to null, you will need to raise a ticket to delete the physical picture file in the cloud storage.
For additional guidelines on this, refer to the below section on Obfuscating files and attachments.
2. Obfuscating personal data for other individuals
Recall that "other individuals" in this context will mean any other Data Subject involved in your processes, who don't actually work on the processes of your organization but who are part of records inputted in the system (in master entities).
Examples are: a contractor's or vendor's contacts, general users/customers or health care patients, etc.
To obfuscate records having sensitive data, you need to set information to null.
You may design a separate process for this purpose as well.
Through the new process you will need a search control to browse and look for sensitive data at those master entities and attributes you have designed for such purpose.
This includes any data you may have in Persona entities as well.
When finding a record, and for open cases, you may rely on Xpath so that rules can set their value to null.
Alternatively and for closed cases, you will need to rely on the CHelper.setAttrib() function to set their value to null (including any file attribute which stores case attachments).
This covers partially the requirement and you will also need to consider if such data are bound to additional physical files and attachments in your ECM system (e.g., pictures, screenshots, personal documents, reports, etc).
For additional guidelines on this, refer to the below section on Obfuscating files and attachments.
Separately, you will need to consider in that same Bizagi process, that you obfuscate data which is stored in Bizagi system logs.
These logs contain information about changes performed in those attributes you identity as holders of sensitive data.
This is done to obfuscate displayed logs having initial values and modified values for sensitive data.
To do this, you may rely on the following two functions of the CHelper class of the Bizagi rules API as described below.
FUNCTION (signature) |
INPUT PARAMETERS |
OUTPUT PARAMETERS |
OBJECTIVE |
|---|---|---|---|
string CHelper.GetEntityLog (string entityName, string attribName, int surrogateKey) |
It is mandatory to send: •entityName: A string specifying the name of the master entity whose log you will fetch. •attribName: A string specifying the name of the attribute of the given master entity, whose log you will fetch. •surrogateKey: An integer specifying the internal ID that identifies uniquely a record of that given master entity. |
Returns a string with a JSON-formatted log having any number of records, where each record details: [{"entityName":"Customer", "attribName":"Email", "value":"john.doe@agilityCorp.com", "date":"06/12/2018 17:03:36"}]
In case that a log is not found (e.g., for a surrogateKey value having no matches), then an empty JSON file is returned. |
This function aims to help you query the entity log you need before actually obfuscating its data.
You may also use it after "anonymizing" the log if you wish to validate that it effectively obfuscated data. |
void CHelper.AnonymizeEntityLog (string entityName, string attribName, int surrogateKey) |
It is mandatory to send: •entityName: A string specifying the name of the master entity whose log you will anonymize. •attribName: A string specifying the name of the attribute of the given master entity, whose log you will anonymize. •surrogateKey: An integer specifying the internal ID that identifies uniquely a record of that given master entity. |
Does not return information (void). In case of an error during its execution, an exception is thrown.
|
This function obfuscates data in the applicable entity log. To be used with caution, given that its use cannot be undone. |
For both functions above, it is suggested that in your separate process, you obtain the .Id for the record you locate through a search control.
This way, the .Id of that record would be used as the surrogateKey you need as an input parameter.
Consider that both functions expect explicitly the name of one attribute. For their use with more attributes, it would be needed to use the functions multiple times.
|
Other exceptions thrown by the above functions will occur if: •The entity is not a master entity or it does not exist (e.g., it is spelled incorrectly). •The specified attribute does not belong to that specified entity. |
3. Obfuscating files and attachments
Files and attachments are mostly applicable to "other individuals" as treated above.
However deleting physical files from the cloud storage needs to requested raising a support ticket.
To delete physical files first consider if you are storing them the Bizagi cloud storage (default treatment) or in an ECM system.
Otherwise, manage your ECM system to delete files and attachments there.
In addition to the above, recall that you need a process as well to set the file attribute information to null, so that personal data is left unbounded/unattached to records in the system.
Conclusion
The disposal of personal data must be well-defined within your organization’s security policies, including any local laws, norms or regulations that apply to it.
It is necessary for you to determine that time frame under which personal data that has already completed its cycle in the system would be deleted.
A recommended measure to help enforce the above is to design a process in Bizagi that conducts such deletion of personal data present in involved attributes and entities of your processes data model, so that such process can be either triggered upon request for a given individual, or so that it can be ran periodically whenever you strictly need to comply to such measures.
When designing the process as hinted above, you may rely on the use of the CHelper.AnonymizeEntityLog() function from the Bizagi rules API.
Though, you may also need complementary manual procedures in Bizagi, such as those considering deletion of physical files and attachments, other admin options, and other procedures which apply to your specific business, processes, and policies within your organization; such as considering disposal of information in physical material if applicable.
|
Regarding Automation Service, consider that data belongs entirely to the customer. Therefore and upon an eventual contract termination, Bizagi, as a service provider, along with its IaaS business associates (Microsoft Azure) implements procedures that enforce secure data disposal. Such procedures involve policies and controls such as: •Physical media does not leave the data centers at any time and it is destroyed on-site by following rigorous procedures involving a hard delete. •Stored data is striped across multiple physical disks using a log-structured system. •Logical controls are in place to make sure that data is not exposed when disk sectors are subsequently re-written. •Data is not downloaded at any moment into laptops or other devices, nor by Azure personnel nor by Bizagi personnel. •Customers may request to extend up for a period of 60 days after effective day of termination, that customer data is kept. •De-identification procedures take place whenever the customer authorizes the use of a backup of its environment for technical support, so that no real data is involved in such troubleshooting scenarios. •Policies and procedures in Bizagi are in place to enforce that personnel who are authorized to connect to cloud environments, have: no customer data in laptops, encrypted disk technology (i.e., BitLocker), access revoked and data safely erased from laptops upon off-boarding, among others. |
Last Updated 12/12/2024 12:05:18 PM