| | 2.8 Compliance
05. How to Comply with GPR | | |
|---|
| 28.05 How to Comply with GPR: | | 1. Many analysis and audit requirements become a legal obligation, but application improvements can be transparent for people using bespoke application services. | | 2. A mandated obligation is Protection-by-Design where evidence is created to demonstrate to ICO and others that data protection has been deployed. | | 3. A recommended protection measure is Pseudonymisation where critical data is moved from a data record and secured in external files. | | 4. The example below provides an overview of how one field may be protected, however similar procedures are applied to all fields. |
| 2. Example: | | 1. Every customer record includes a contact persons name that by law must be protected and evidence must be created to demonstrate protection-by-design. | | 2. In this example, the customer record is assigned a placeholder as "k11" and the contact persons name placehold is "c23". | | 3. The mission is to replace the readable contact persons name in each customer record with a token that is meaningless to a criminal. Evidence is that if the customer data was stolen, no contact persons name would be disclosed and no criminal could reverse engineer the data to create the contact persons names. |
| 3. Step 1: | | 1. Select the primary key and contact persons name from each customer record and store the result in a CSV file. SELECT c01,c23 FROM k11. | | 2. Restructure the CSV into a pseudonymised file called "k1123" as token and value pairs. Encrypt the contact persons name into a string using many different encryption methods. Encode the token so it can be derived, but is not the same as what is stored in the customer record. |
| 4. Step 2: | | 1. Update the contact persons name field in each customer record as the records primary key. UPDATE k11 SET c23=c01. | | 2. Amend the table declaration of the contact persons name field from VARCHAR (32) to INT as 4 bytes. |
| 5. Step 3: | | 1. Upgrade each 4GL business rule to replace the contact persons name declaration of "32,TEXT" to "6,"PSE6". The effect is that a new "PSE6" display method is used to display the contact persons name. | | 2. Upgrade Eliza to load and decrypt the "k1123" file into an array. Like any LIST display method, the PSE6 display method will show the name based on the value of the token. |
| 6. Step 4: | | 1. Upgrade the update 4GL business rule to support the PSU6 storage method. The "k1123" file is loaded, the new name appended with a new token and the file is written. The customer record, contact persons name field is updated with the new token. |
| 7. Reality: | | 1. Reality is much more complicated as the old and new must co-exist in multiple data centers at the same time. | | 2. Historical and archived data must also be processed in a similar way without generating any token conflicts. | | 3. Duplicate names can be consolidated with the same token used to represent the same name in different customer records. |
| 8. Level-Two: | | 1. To protect the names of people in a much more effective way, each name can be fragmented into two (or more) parts. Each part is then pseudonymised with unique files and different encryption methods. The result is stored as a pair of tokens in the customer record that must be decrypted together to display the contact persons name. |
| Document Control: | | 1. Document Title: How to Comply with GPR. | | 2. Reference: 162805. | | 3. Keywords: How to Comply with GPR. | | 4. Description: How to Comply with GPR. This document does not provide legal or financial advice. | | 5. Privacy: Public information service to who it may concern. | | 6. Issued: 11 Feb 2017. | | 7. Edition: 1.1. |
|
|