| 11 Portfolio 29 Data Protection Application | |
---|
Public Privacy Notice Application |
| | Public Contact Us Application |
|
Private Digital Wallet Application |
| | Private Data Dictionary Application |
|
11.29 Data Protection Application Service | 1. "DPAS" means the Data Protection Application Service that provides the additional facilities necessary to comply with GDPR. | 2. DPAS-PNA is the public Privacy Notice Application (PNA) with extensions to inform the data subject (and ICO) of their rights and the purpose that personal data is used. | 3. DPAS-CUA is the public Contact Us Application (CUA) for data subjects to send messages to the controller and processor and DPO and other roles. | 4. DPAS-DWA is a private Digital Wallet Application (DWA) for data subjects to sign-in and process their PII. | 5. DPAS-DDA is a private Data Dictionary Application (DDA) providing am inventory data gathering and catalogue facility for the ASP DPO to document all relevant data that may be shared with the ICO. | 6. PII is known as personal data that is "processed", rather than "stored" because PII is encrypted and so it is plausible to state that PII is never stored, only an encrypted version is stored that may or may not be PII. | 7. Data protection is a revenue opportunity for the few that do it legally; rather than a business cost for those that try to overlook legal obligations. |
Glossary | "GDPR" means General Data Protection Regulation with reference to articles as UK law. | "BAS" means the Bespoke Application Service belonging to the Owner as the "controller" and operated by the Application Service Provider (ASP) as the "processor". | "DPAS" means the Data Protection Application Service used provide the services demanded to comply with GDPR. | "Data Subject" means a person, including staff, customer contacts, supplier contacts and business associated information held in the Bespoke Application Service, personal emails, local computer files and paper documents. | "PII" means Personally Identifiable Information as any personal data owned by data subject. | "DPO" means Data Protection Officer who reports to the ASP Board and whos essential services are part of the Bespoke Application Service. | "DPIA" means Data Protection Impact Assessment that is shared with the ICO to demonstrate compliance with GDPR. |
2. Privacy Notice Application (PNA) | 1. The business requirement is for the DPO to create and maintain a public Privacy Notice Application with GDPR extensions to keep each data subject informed of their rights. | 2. The DPAS-PNA application service publishes the privacy notice and legitimate purposes of the contrller processing PII. | 3. DPAS-PNA public information is shared with the Owner, Data Subjects and ICO in read-only mode. | 4. The business requirement is for a data subject to be shown principles about their PII such as:- | (1) Article 5(1a) PII shall be lawfully, fairly and transparently processed. | (2) Article 5(1b) PII is used for a specific legitimate purpose and no other purpose. | (3) Article 5(1c) PII shall be adequate, relevent and limited to what is necessary in relationship with the purpose. | (4) Article 5(1d) PII shall be accurate and kept up to date. | (5) Article 5(1e) PII shall be kept only as long as necessary with regard to the purpose. | (6) Article 5(1f) PII shall be protected against theft, loss, destruction, damage, using appropriate technical and organisational measures. | 5. The business requirement is for a data subject to be shown information about their PII such as:- | (1) Article 13(1a) The identity and contact details of the controller - see DPAS-CUA messaging service. | (2) Article 13(1b) The contact details of the DPO - see DPAS-CUA messaging service. | (3) Article 13(1c) The purposes amd legal basis for the processing for which the PII are intended. | (4) Article 13(1d) The legitimate interests pursued by the controller. | (5) Article 13(1e) The categories of recipients who have access to the PII. | (6) Article 13(1f) A statement that no PII shall be transfered to any other country. | (7) Article 13(2a) The criteria used to determine the period for which the PII will be stored. | (8) Article 13(2b) The existence of DPAS-DWA where the data subject has the right to access. | (8) Article 13(2c) A statement that the data subject has the right to withdraw consent at any time. | (8) Article 13(2d) A statement that the data subject has the right to lodge a complaint with the controller or/and ICO. | (8) Article 13(2e) A statement of the consequences of withdrawing consent to process the PII. | (8) Article 13(2f) A statement where profiling and automated decision making is involved and the envisaged consequences of not using these processes. | 6. The business requirement is for some of the DPAS-DDA Data Dictionary Application information to be published as an extension to the privacy notice. | Please click here to popup more information about Privacy Notice |
3. Contact Us Application (CUA) | 1. The business requirement is for a public application service to provide an improved "contact us" facility where data subjects may communicate with the Request Fulfilment Management team using support requests. Types of messages may include the right to withdraw consent to use the data subjects PII or to lodge a complaint. | 2. DPAS-CUA support request information is shared with the Owner, Approved People, Data Subjects and ICO as required. | 3. To ensure that data subjects have the right to access all information about them, so messages from obsolete sources must be included as:- | (1) Postal messages must be scanned and uploaded as a support request that can then be shared with the data subject. The paper message must then be shredded to ensure it cannot be lost or stolen, it does not need to be made available to the data subject upon request and it does not need to be erased upon request. No paper document is permitted to survive for more than 20 hours before it is shredded and burned. | (2) Phone messages must be transcribed as a support request that can then be shared with the data subject. The phone message must then be erased to ensure it cannot be lost or stolen, it does not need to be made available to the data subject upon request and it does not need to be erased upon request. All phone messages must be assumed to be a phishing attack until the caller provides evidence to the contrary. Private, confidential and sensitive information must never be disclosed on the phone. No phone message recording is permitted to survive for more than 20 hours before it is erased. | (3) Email messages must be transcribed and/or uploaded as a support request that can then be shared with the data subject. The email message must then be erased to ensure it cannot be lost or stolen, it does not need to be made available to the data subject upon request and it does not need to be erased upon request. All email messages must be assumed to be a phishing attack unless the sender provides evidence to the contrary. Private, confidential and sensitive information must never be disclosed in an email message. No email message is permitted to survive for more than 20 hours before it is erased. | 4. DPAS-CUA acts as a 24*7 receptionist who never stops. | Please click here to popup more information about Contact Us Notice |
4. Digital Wallet Application (DWA) | 1. The business requirement is for a data subject to sign-in to access and process their Personally Identifiable Information. After a person has been uniquely identified, they may sign-in with their name, email address and access code to process their PII as:- | (1) Article 15 Right of Access. | (2) Article 16 Right to Rectification. | (3) Article 17 Right to Erasure (right to be forgotten). | (4) Article 18 Right to Restrict processing. | (5) Article 20 Right to data Portability. | (6) Article 21 Right to Object. | (7) Article 22 Right to Stop Profiling. | 2. DWA may be the most significant improvement in privacy and methods of working caused by GDPR laws. | Please click here to popup more information about Subject Access Request Service |
4b. Block Chain | 1. Some data such as a statement of invoices and payments is shared by more than one party - both the customer and the supplier could be said to be the controller. GDPR may not apply to normal business transactions as financial statments of invoices and payments. | 2. Most PII may evolve to have shared ownership where the PII is represented by encrypted data stores held by more than one party. | 3. Many of the GDPR obligations evaporate when shared ownership of replicated encrypted data is deployed and stored by all parties. | 4. What is PII today will become all business data in a few years, so the GDPR obligations must be deployed in the more cost effective way to cope with continually evolving privacy measures. | 5. Digital Wallet: people can put their PII in their digital wallet and share that PII with other parties as needed. People can withdraw their share options at any time. |
5. Data Dictionary Application (DDA) | 1. The business requirement is for the DPO to create and maintain the Data Protection Impact Assessment (DPIA) strategic documentation that drives the whole GDPR experience. | 2. The DPAS-DDA Data Dictionary Application is a private inventory, catalogue and data gathering service is used to continually manage the DPIA strategic information. | 3. DPAS-DDA strategic information shall be shared with the Owner and ICO in read-only mode as needed. | 4. The business requirement is for the controller (or the controllers representative as the processor) to maintain a record of processing activities under its responsibility to include:- | (1) Article 30(1a): The name and contact details of the controller and the data protection officer - on online message application service. | (2) Article 30(1b): The purpose of the processing. | (3) Article 30(1c): A description of the categories of data subjects and categories of personal data. | (4) Article 30(1d): The categories of recipients to whom the personal data is disclosed including the country. | (5) Article 30(1e): The time duration before personal data is erased or the criteria to determine the time duration. | (6) Article 30(1f): A general description of the security measures deployed in compliance with Article 32. | 5. The business requirement is for the processor to maintain a record of all categories of processing activities under carries out to include:- | (1) Article 30(2a): The name and contact details of the processor and the data protection officer - on online message application service. | (2) Article 30(2b): The categories of processing carries out. | (3) Article 30(2c): The processor shall not transfer any personal data to any other country or any other processor. | (6) Article 30(2d): A general description of the security measures deployed in compliance with Article 32. | 6. The business requirement is for the DPO is create and maintain a data breach notification procedure to include:- | (1) Article 33(3a): Describe the nature of the personal data breach, including the categories and number of data subjects concerned and the categories and number of personal records concerned. | (2) Article 33(3b): Communicate the name and contact details of the Data Protection Officer where more information can be obtained. | (3) Article 33(3c): Describe the documented risk consequences for the personal data breach. | (4) Article 34(3a): Appropriate technical and organisation measures were implemented such as encryption that cause the personal data to be unintelligible. | (5) Article 34(3b): The controller has taken measures to ensure that high risks are no longer likely to materialise. | (6) Article 34(3c): It would involve a disproportionate effort. | 7. The business requirement is for the DPIA to include:- | (1) Article 35(7a): A systematic description of the processing operations and purposes of the processing including the legitimate intests of the controller. | (2) Article 35(7b): An assessment of the necessary and proportionality of te processing operations in relation to the purposes. | (3) Article 35(7c): An assessment of the risks to the rights of data subjects. | (4) Article 35(7d): The measures deployed to address the risks including safeguards, security measures and mechanisms to ensure the protection of personal data. This is used as a demonstration of adequate security measures when evaluated by the ICO. | 8. The business requirement is for the processor to comply with approved codes of conduct and have those codes of conduct monitored by a trade association. | (1) ISO 27001 Information Security Management (ISM) Standard is a foundation to all security measures. | (2) Cloud Security Alliance (CSA) is an appropriate trade association with a very comprehensive code of conduct and self-assessment compliance. | Please click here to popup more information about Data Protection Impact Assessment (DPIA) |
Bespoke Application Service | 1. The business requirement is for the bespoke Application Service specified by its Owner as the controller to be improved to fully comply with GDPR. | 2. All PII (without exception) evolves to become Pseudonymised and Replicated Encrypted Data (PARED). to ensure that it cannot be stolen or lost. | 3. PARED will ensure that PII cannot be stolen or lost and will eliminate the threat of a notifiable data breach. | 4. For each person identified in any record:- | (1) A flag must be stored to state that the person is an "Adult" - all legal issues relating to children and yound persons are eliminated. It is not a business requirement to store the persons date of birth as that data could only be used to discriminate against a person based on their age. | (2) A field must be stored to select the person "preferred contact method" as email, phone, post or none. When the persons preferred contact method is "none", then any processing of that persons PII is disabled. The persons preferred contact method will be "none", when the PII is subject to the data subjects right (1) to restrict processing, (2) to object, (3) to stop profiling or (4) consent has been withdrawn. | (3) A field is hidden with the data subjects unique access code that they can use with their name and email address to sign into DPAS-DWA. The access code is derived so it is not stored and cannot be lost or stolen. The access code can be communicated to the data subject with an automated email so the sender does not need to see the access code. | (4) Pseudonymisation is used so PII such as a persons name is encrypted and stored in a different data store with a derived token stored in the customer record. A distinct search service is provided to enable data to be discovered by a persons name or any other encrypted PII field. |
Access Code | 1. Every data subject can be assigned an access code acts like a password - a data subject can sign-in with their (1) name, (2) email address, (3) phone number and (4) access code. | 2. The data subjects access code could be stored or could be derived by business rules acting on a set of PII fields - the access code remains active while the PII remains stable and is disabled when any key PII is changed. | 3. The access code from be automatically emailed to the data subject with a button on the form so the user does not see the access code. | 4. Where the access code is forgotten, the user can click the button to cause an automated email to be sent to the data subject showing the access code. | 5. Where the access code is stolen and a new access code needs to be issued, then a PII field value is changed to cause the assigned access code to be changed. | 6. The life cycle of an access code is until a key PII field value is changed. If the persons phone number is changed, they are assigned a new access code. |
Categories of Recipients | 1. A recipient of PII is a controller approved person, a processor second level support person or the data subject themselves. First level support (the 24*7 receptionist) only have access to DPAS-CUA messaging service and the self-service support service. System administrators and operations teams only have access to encrypted data that is meaningless and unintelligible. | 2. The controller approved people may be categorised by branch location and/or department. The controller approved people shall be categorised as (1) Executive with read-only access to most information, (2) Manager with access to management information and supervisory rights to manage their own staff PII; and (3) Agents who use the bespoke application service. | 3. The processor approved people are the Second Level Support team who are bound by confidentiality service agreement to keep the PII private. Second Level Support people have sign-in rights that are compareable to those of a controller approved person with a Management role, but for any selected branch or department. | 4. The First Level Support team and Second level Support team are parts of the Request Fulfilment Managers department. First Level Support people deal with phone, email and postal requests with access to a wealth of public information that may be communicated, but they do not have access to any private information, except the Contact Us Application (CUA). Second Level Support people have access to business information including PII in the same way as any approved person has access to the Bespoke Application Service. No other person or role has access to any business information. Even the database administrator cannot access any business information because its all encrypted and uinintelligible. |
Categories of Data | 1. Business data is categorised as "Private" and can only be accessed by approved people after they have signed in. | 2. Personal data (PII) is categorised as "Personal" and may be access by approved people after they have signed in. | 3. Sensitive personal data such as health, religion, culture, ethnicity and gender is NOT used and NOT stored. | 4. Personal data may include:- | (1) Persons Name that is typically the first and family names. | (2) Persons preferred contact method such as: Email, Phone, Mobile, Post or None. | (3) Person is an Adult (must be YES). | (4) Persons assigned DPAS access code (derived). | (5) Persons email address. | (6) Persons phone number. | (7) Persons mobile number. | (8) Persons postal address: building, house number, street, district, town, county, country, postcode. | (9) Persons vehicle registration. | (10) Persons driving licence number (date of birth), expiry date, number of points (on date checked). | (11) Persons contact or policy number, expiry date. | 5. In the context of business data, job title is not considered to be PII because it may be dependent on department, branch and company at a point in time. A persons preferred language is not considered to be PII. A persons time zone and normal business hours are not considered to be PII. A persons postal address may be a post office box number, a company registration address or a postal service address that may or may not imply the location of the person or where they live. | 6. When a data subject signs in to view their PII, it may be reasonable and desirable for the person to be granted the right to correct; their job title, branch name, managers name, department name and related business data. It may be unreasonable for a person to change their role, but they may be able to correct their normal business hours and normal business days. | 7. In the context of personal data, address street, district, town. county and country are not PII, but may be replaced with pseudonymised tokens in the normal way. A benefit would be that these field values would only be stored once, however some search and filtering overheads will be created. |
Adult | 1. The ONLY category of person that may be stored must be an adult. Special processing of consent by a guardian is mandated where the personal data is about a person who is not an adult. To minimise the cost of doing business, special legal processing for people who are not an adult has been eliminated. | 2. All staff who are contracted to confidentiality with a service agreement, must be an adult who are legally able to commit to such an agreement. | 3. All customer, supplier and business associate contact people who consent to the processing of their personal data must be an adult who is legally able to consent to such processing. | 4. It would be contrary to GDPR article 5(1c) as excessive to store a persons date-of-birth just to verify that the person is an adult. The only purpose to store a persons date-of-birth is to discriminate against them based on their age - that would be illegal and the person could claim damages for ageism. |
Document Control | 1. Title: Data Protection Application Service. | 2. Description: Data Protection Application Service. | 3. Key Words: GDPR, Data Protection Application Service. | 4. Privacy: Public shared for the benefit of humanity. | 5. Reference: 161129. | 6. Edition: 1.2. | 7. Issued: 22 Aug 2017. |
|
|