| A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
1 | Identifcatino of Provenance Metadata and Formulating Compliance Queries based on GDPR-Readiness Guide provided by Ireland's Data Protection Commissioner | ||||||||||||||
2 | ID | Category | Title | Comment | GDPR | Type | To Implement? | Data | Data Comment | Model based? | Model Comment | Instance based? | Instance Comment? | Automate? | Comment |
3 | G1 | General | Categories of personal data and data subjects | List the categories of data subjects and personal data collected and retained e.g. current employee data; retired employee data; customer data (sales information); marketing database; CCTV footage. | demonstrative | Y | personal data, data subjects | subclasses that have other subclasses can be considered as categories in this case | Y | this only needs information about the classes, not the instances | N | instances are difficult to aggregate into categories, and would need some abstract information to efficiently do so | Y | run this over the latest model as required | |
4 | G2 | General | Elements of personal data included within each data category | List each type of personal data included within each category of personal data e.g. name, address, banking details, purchasing history, online browsing history, video and images. | demonstrative | Y | personal data | subclasses that do not have other subclasses can be considered by types within categories | Y | this only needs information about the classes, not the instances | N | instances are difficult to aggregate into categories, and would need some abstract information to efficiently do so | Y | run this over the latest model as required | |
5 | G3 | General | Source of the personal data | List the source(s) of the personal data e.g. collected directly from individuals; from third parties (if third party identify the data controller as this information will be necessary to meet obligations under Article 14). | demonstrative | Y | personal data, steps that collect data, entities that provde data | Y | there could be fixed models where data is collected directly from data subjects or some data provider which can be shown through the abstract model | Y | instances can show who the actual data providers are, if they can change with time. Ideally, the change should be reflected in the model | Y | run this over the latest model and over instances | ||
6 | G4 | General | Purposes for which personal data is processed | Within each category of personal data list the purposes for the data is collected and retained e.g. marketing, service enhancement, research, product development, systems integrity, HR matters, advertising. | demonstrative | Y | results of G1, processes acting on data | get all plans that contain steps that act on the data, then aggregate them based on categories | Y | run this over the model only as it enquires about the state of the system and not about a particular instance | N | this CAN be run on instances for data subject specific queries, but this is not what the original query meant | Y | run this over the latest model as required | |
7 | G5 | General | Legal basis for each processing purpose (non-special categories of personal data) | For each purpose that personal data is processed, list the legal basis on which it is based e.g. consent, contract, legal obligation (Article 6). | demonstrative | Y | results of G4, processes acting on data | get legal basis in steps within plans from G4 | Y | legal basis does not change in instances, so query this on models | N | this CAN be run on instances for data subject specific queries, but this is not what the original query meant | Y | run this over the latest model as required | |
8 | G6 | General | Special categories of personal data | If special categories of personal data are collected and retained, set out details of the nature of the data e.g. health, genetic, biometric data. | demonstrative | Y | special category personal data | subclasses under special category of personal data | Y | as with normal categories of data, this query only needs information about category, not specifics | N | instances are difficult to aggregate into categories, and would need some abstract information to efficiently do so | Y | run this over the latest model as required | |
9 | G7 | General | Legal basis for processing special categories of personal data | List the legal basis on which special categories of personal data are collected and retained e.g. explicit consent, legislative basis (Article 9). | demonstrative | Y | results of G6, steps that collect data, steps that store data | get all steps that collect or store special categories of data, then retrieve their legal basis | Y | same as G5, this is information about the abstract model | N | this CAN be run on instances for data subject specific queries, but this is not what the original query meant | Y | run this over the latest model as required | |
10 | G8 | General | Retention period | For each category of personal data, list the period for which the data will be retained e.g. one month? one year? As a general rule data must be retained for no longer than is necessary for the purpose for which it was collected in the first place. | N | results of G1, steps that store data | this is interpretative based on how retention time is calculated; ideally, this will be a part of the consent or policy that feeds into the provenance graph | ||||||||
11 | G9 | General | Action required to be GDPR compliant? | Identify actions that are required to ensure all personal data processing operations are GDPR compliant e.g. this may include deleting data where there is no further purpose for retention. | N | this is very vague and does not depend or does not directly involve provenance; unless a list of processes or plans can be linked to show 'actions' but these would still need to be combined with some form of documentation | |||||||||
12 | P1 | PersonalData | Validity of Consent | Have you reviewed your organisation’s mechanisms for collecting consent to ensure that it is freely given, specific, informed and that it is a clear indication that an individual has chosen to agree to the processing of their data by way of statement or a clear affirmative action? | 7,8,9 | assistive | Y | consent, steps that acquire consent | This cannot be directly evaluated because of conditions such as freely given, specific, etc. which are qualitative. But, the information about how the consent was collected can be presented to make an informed decision. | Y | identify steps that collect consent along with static data content such as privacy policy and T&C that are used along with the form/mechanism used to collect consent. | N | This is assuming that the instances follow the abstract model. So the mechanism that they used to collect consent is the same as that referenced in the abstract model. Therefore, this is already considered to be evaluated under the abstract model. However, this CAN be used to retrieve and evaluate the consent mechanism for a particualr data subject. | Y | run this over the latest model as required |
13 | P2 | PersonalData | Retrospective Consent | If personal data that you currently hold on the basis of consent does not meet the required standard under the GDPR, have you re-sought the individual’s consent to ensure compliance with the GDPR? | 7,8,9 | N | This is a very complex question that needs information about the current data, how it was collected, the consent that operates on it, etc. Therefore, this is not resolved currently. There MAY be provenance information that can be associated with this query, however, for this current level of work, it is out of scope. | ||||||||
14 | P3 | PersonalData | Demonstration of Consent | Are procedures in place to demonstrate that an individual has consented to their data being processed? | 7,8,9 | evaluative | Y | consent | this is a relatively simple query that is based on demonstrating the consent covering the processing, or in more abstract terms, only demonstrate that consent exists | Y | identify steps that collect consent, and steps that archive or store consent. This is useful to demonstrate that the model system stores the consent, and where it was collected from. | Y | query the (latest) consent associated with a data subject | Y | run this query over the latest model or on the data graph, it requires no manual parameters |
15 | P4 | PersonalData | Withdraw consent for processing | Are procedures in place to allow an individual to withdraw their consent to the processing of their personal data? | 7.8.9 | evaluative | Y | steps that withdraw consent | this is demonstration of capability that allows consent to be withdrawn | Y | identify steps that withdraw consent | N | Y | run this query over the latest model | |
16 | P5 | PersonalData | Children's Personal Data | Where online services are provided to a child, are procedures in place to verify age and get consent of a parent/ legal guardian, where required? | 8 | evaluative | Y | steps that acquire consent, steps for age verification | this query can be resolved by showing that steps exist for age verification and acquiring legal/guardian consent | Y | identify steps that check for legal verification of age for children, and get parental/guardian consent. This is a bit out of the way, since the model itself does not contain any logic for age verification or acquisition of consent, but it exists to show how this can be done, or in the case of instances, whether it was done | N | this CAN be run on instances, basically checking whether the age is below legal age, and in that case, whether parental/guardian consent was obtained; but the point of the query is whether such procedures exist | Y | run this query over the latest model |
17 | P6 | PersonalData | Legitimate interest based data processing | If legitimate interest is a legal basis on which personal data is processed, has an appropriate analysis been carried out to ensure that the use of this legal basis is appropriate? That analysis must demonstrate that 1) there is a valid legitimate interest, 2) the data processing is strictly necessary in pursuit of the legitimate interest, and 3) the processing is not prejudicial to or overridden by the rights of the individual. | assistive | Y | steps that process personal data | this is not a singular query, and should be split into several components as follows: firstly, the query that finds all steps using personal data, then, we need to find the legal basis of all such processes, filter it to those using legitimate interest as a legal basis, and present them for analysis. The latter part of the query, where it is to be analysed whether this 'legal basis' is correct, is a qualitative and legal matter that cannot be analysed programmatically. Therefore, this query serves to provide information required in making a manual and informed judgement of this. | Y | since this query analyses the legal justifcation of processing in the broad sense, it should be run on the abstract model of the system rather than on an instance | N | this CAN be run on instances, but in that case, it would be checking the legal basis on only that particular instance related to the data subject under consideration | Y | run this query over the latest model | |
18 | R1 | Rights | Subject Access Requests (SARs) | Is there a documented policy/procedure for handling Subject Access Requests (SARs)? | 15 | assistive | Y | steps that handle SAR | though this does not directly relate to the provenance of consent or personal data, this can be resolved by demonstrating that there are steps for resolution of SAR | Y | since the query relates to the ability to handle requests, this should be done on the abstract model of the system | N | this CAN be queried over instances, in which case, the policy can check whether particular SARs where handled, and if so, then through what procedures | Y | run this query on the latest model |
19 | R2 | Rights | Subject Access Requests (SARs) Response Time | Is your organisation able to respond to SARs within one month? | 15 | assistive | N | steps that handle SAR | this cannot be decided programmatically except when someone explicitly states that time to handle is 1 month, in which case, the query would be checking only for the value. But this query can be used to check whether SARs were handled within the period of one month | N | Y | check SARs if they were handled within the time period of one month. This would require storing timestamps that show when the SAR was made and when it was resolved or addressed by the system. The query would then calculate the interval between the two timestamps and check if it was less than 30 days (one month) | Y | if the query is only checking the interval between timestamps, then it can be automated; in fact, the automated version of the query can be used to flag SARs that have NOT been resolved within one month, or closer to that date so that they can be correctly addressed | |
20 | R3 | Rights | Data Portability | Are procedures in place to provide individuals with their personal data in a structured, commonly used and machine readable format? | 20 | evaluative | Y | steps that address right to data portability | breaking down this query, it first checks whether there are procedures to address the right to data portability, and further to that, investigates whether that procedure can provide data in the required format; while the format itself cannot be assesed as to whether it suits the requirements specified, it can certainly be checked against a known set of acceptable formats | Y | since the query only addresses capability, it should be run on the abstract model of the system | N | this CAN be run over instances, in which case, it would act to check if a particular data format provided to the data subject is within the acceptable list of data formats | Y | run this query on the latest model |
21 | R4 | Rights | Deletion and Rectification | Are there controls and procedures in place to allow personal data to be deleted or rectified (where applicable)? | 16,17 | evaluative | Y | steps that address right to rectification | this query checks the capability of the system in deleting or rectifying data | Y | since the query only addresses capability, it should be run on the abstract model of the system | N | this CAN be run over instances, in which case, it would act to check if a particular data subject was provided the function to delete and rectify data, and whether that was performed correctly. | Y | run this query on the latest model |
22 | R5 | Rights | Right to restriction of processing | Are there controls and procedures in place to halt the processing of personal data where an individual has on valid grounds sought the restriction of processing? | 18 | assistive | N | data subjet request, steps that process personal data | this is a little complex; so breaking it down gives this - an individual has requested that their data not be processed or be processed in a restricted fashionl; so there is the component of a request; the organisation then has to decide whether this request is 'on valid grounds' which is an entirely legal procedure, and which cannot be done programmatically. Once that is decided, and found to be valid, the personal data processing of that particular data subject should be halted or stopeed. The latter part is where the query can be assistive. It can retrieve the steps that use personal data, so they can be flagged for the halting procedure. Whatever other stes are involved in this operation can also be depicted using provenance. | N | identifcation of which steps use personal data can be done on the abstract model | Y | since the request is happening at the instance level, it makes sense to resolve this query at the instance level. In this case, some information may be needed from the abstract model, such as steps that use personal data, but even then they would need to be resolved as to which are actually using the data subject's personal data | N | part of this query can be automated, but as a whole, the query involves many components that need to be explicitly specified and run manually since it involves a decision process |
23 | R6 | Rights | Right to object to processing | Are individuals told about their right to object to certain types of processing such as direct marketing or where the legal basis of the processing is legitimate interests or necessary for a task carried out in the public interest? | 21 | N | the query could retrieve some process that shows this information, but that can be done using a simple URI as well, so there is no 'query' component here | ||||||||
24 | R7 | Rights | Halt processing after right to object | Are there controls and procedures in place to halt the processing of personal data where an individual has objected to the processing? | 21 | evaluative | Y | steps that process personal data | this query checks the capability of the system in halting processing of data; this can be resolved as some series of steps that, upon request, change the system state for particular data sets so that they are not processed again; the query checks for the presence of such steps; this is also how the right to object is handled | Y | the query checks whether the system model has step(s) to address the right to object | N | this CAN be run on instances to check for particular right to object for specific data subject's, but the text of the query does not state this | Y | run this query on the latest model |
25 | R8 | Rights | Profiling and automated processing | If automated decision making, which has a legal or significant similar affect for an individual, is based on consent, has explicit consent been collected? | 22 | assistive | Y | steps that make automated decisions, consent | in this query, any processes that have automated decision making, and are based on consent, are analysed to see if explicit consent has been provided; this can be checked if consent is marked as explicit consent (in this regard), and requires some known form of consent to compare this against; for generic purposes, the query can assist in identifying steps that feature automated decision making and check if consent is being collected (other processes will then check if the consent is explicitly collected for this purpose) | Y | this is used to identify steps that make automated decisions | Y | the specific consent provided by the user is required to associate with the automated legal processing and to analyse whether it explicitly permits this | N | it is possible to run this query on an automated basis if all the data is present; however, the last part of checking validity still needs to be done manually; which means that only a part of the query can be automated |
26 | R9 | Rights | Right to obtain human intervention | Where an automated decision is made which is necessary for entering into, or performance of, a contract, or based on the explicit consent of an individual, are procedures in place to facilitate an individual’s right to obtain human intervention and to contest the decision? | 22 | assistive | Y | steps that make automated decisions, right to contest automated decisions | like the previous query, this involves identifying automated decision making steps, checking if they are associated with consent; and then investigating whether there exist steps that can help the data subject to contest the decision | Y | since the query only checks for presence of procedures, this can be specified or queried on the abstract model of the system | N | this CAN be run on instances to check for particular right to object to automated decision making for specific data subject's, but the text of the query does not state this | Y | run this query on the latest model |
27 | R10 | Rights | Restrictions to data subject rights | Have the circumstances been documented in which an individual’s data protection rights may be lawfully restricted? Note: the Irish Data Protection Bill will set out further details on the implementation of Article 23. | 23 | N | this query relates to a set of documents that clarify the specified question; while provenance information can show the lifecycle of these documents; we do not consider that in scope for this work | ||||||||
28 | A1 | AccuracyRetention | Purpose Limitation | Is personal data only used for the purposes for which it was originally collected? | evaluative | Y | personal data, consent, steps that involve personal data through use, share, store | this simple looking query can be interpreted to be quite broad - what personal data was collected ? what was the consent and permissions it contained? what was the personal data used for - processing, storing, sharing? And then to match them all up. This is dependant on the form of consent used, to retrieve permission for using data. Even without that, the query can be used to assist in retrieving information about what is happening with the personal data, and the consent associated with it. | Y | The query on the abstract model can check what categories/types of data are collected and where they are used. This can be helpful in providing a brief overview of the system. This can then be compared with whatever consent options are being presented to evaluate whether all processing and data operations are indeed referenced in the consent collection or policy. | Y | The query on instances retrieves all processes that involve personal data along with the consent in question and then compare whether each step was permitted based on the consent. | Y | The retrieval of information can be automated, but this involves taking into account the way consent is represented | |
29 | A2 | AccuracyRetention | Data minimisation | Is the personal data collected limited to what is necessary for the purposes for which it is processed? | assistive | Y | personal data, steps that process personal data | the query can assist by retrieving what personal data is collected and what it is being used for; this can then be used to evaluate whether the data is adequate for purposes | Y | The overview of the system can provide this information in brief, and would be common for all data subjects | Y | This query CAN be run on instances, as services can differ between data subjects. However, it is better to run this on the abstract model for proving that the system itself follows data minimisation. | Y | The retrieval of information can be automated | |
30 | A3 | AccuracyRetention | Accuracy | Are procedures in place to ensure personal data is kept up to date and accurate and where a correction is required, the necessary changes are made without delay? | N | the procedures in question may allow the data subject to rectify the data, or it could be the organisation itself who is rectifying data; this is quite complicated to represent. A provenance trace can be maintained to show that some discrepancy was detected, and then it was changed to show compliance. But the query itself cannot be resolved in the context of this work. | |||||||||
31 | A4 | AccuracyRetention | Retention | Are retention policies and procedures in place to ensure data is held for no longer than is necessary for the purposes for which it was collected? | N | the procedures in question delete data once the purposes for which it was collected has been achieved, but this is difficult to evaluate programmatically. A query that can retrieve information about what data is collected and for what purposes can assist in this, but it cannot show whether the data was deleted at the correct time. This could use some information at the instance level, but this can turn very complex. | |||||||||
32 | A5 | AccuracyRetention | Retention Legal Obligations | Is your business subject to other rules that require a minimum retention period (e.g. medical records/tax records)? | N | this query is based on legal documentation and does not involve provenance | |||||||||
33 | A6 | AccuracyRetention | Destroy data securely | Do you have procedures in place to ensure data is destroyed securely, in accordance with your retention policies? | assistive | Y | steps that delete data | the particular of how deletion is achieved can be helpful in the context of this query; therefore the query can be resolved by identifying what personal data is being delete by what steps, which can then be helpful to investigate the methods used for secure deletion | Y | Since the methods of deletion are common for all data subjects, this query can be run on the abstract model of the system | N | Y | The identification of steps that delete data can be done automatically | ||
34 | A7 | AccuracyRetention | Duplication of records | Are procedures in place to ensure that there is no unnecessary or unregulated duplication of records? | N | This query asks for steps that ensure there is no duplication of data. While it is possible to simply point this to a step or process that is said to do this, it is not sufficient to evaluate the query. Therefore, this is not within the context of the current work. | |||||||||
35 | T1 | Transparency | Transparency to customers and employees | Are service users/employees fully informed of how you use their data in a concise, transparent, intelligible and easily accessible form using clear and plain language? | 12,13,14 | N | This query does not directly relate to provenance; but it can reuse other queries if the personal data aspect is changed to only relate to employee data. This can be used to understand how the employee data is being used. | ||||||||
36 | T2 | Transparency | Provide Information listed in Article 13 | Where personal data is collected directly from the individuals, are procedures in place to provide the information listed at Article 13 of the GDPR? | 13 | assistive | Y | steps that collect personal data | This query cannot directly evaluated because asessing whether the information has been provided in a satisfactory manner is a qualitative evaluation. Instead, the query can provide information such as where personal data is collected, identifying the steps that collect this data. This can be used to explore the artefacts and methods used by the step in an effort to find if the required information is being displayed. | Y | Information related to what steps collect the data and what artefacts are associated with them is common for all data subjects. Therefore, this query should be run over the abstract information model of the system. | N | Y | run this query on the latest model | |
37 | T3 | Transparency | Provide Information listed in Article 14 | If personal data is not collected from the subject but from a third party (e.g. acquired as part of a merger) are procedures in place to provide the information listed at Article 14 of the GDPR? | 14 | assistive | Y | steps that collect personal data | Like the previous query, steps that collect personal data are identified, and then filtered based on who is providing the data, which in this case, is third parties. The rest of qualitative information rematins the same. | Y | Filter steps that collect data based on the provider being a third party | N | Y | run this query on the latest model | |
38 | T4 | Transparency | Provide information when engaging | When engaging with individuals, such as when providing a service, sale of a good or CCTV monitoring, are procedures in place to proactively inform individuals of their GDPR rights? | N | This is very context specific, and does not relate to provenance | |||||||||
39 | T5 | Transparency | Provide information on facilitating rights | Is information on how the organisation facilitates individuals exercising their GDPR rights published in an easily accessible and readable format? | N | This is not related to provenance | |||||||||
40 | C1 | ControllerObligations | Supplier Agreements | Have agreements with suppliers and other third parties processing personal data on your behalf been reviewed to ensure all appropriate data protection requirements are included? | 27,28,29 | N | This is not related to provenance | ||||||||
41 | C2 | ControllerObligations | Data Protection Officers | Do you need to appoint a DPO as per Article 37 of the GDPR? | 37,38,39 | N | This is not related to provenance | ||||||||
42 | C3 | ControllerObligations | Reasons for not having a DPO | If it is decided that a DPO is not required, have you documented the reasons why? | 37,38,39 | N | This is not related to provenance | ||||||||
43 | C4 | ControllerObligations | Escalation procedures | Where a DPO is appointed, are escalation and reporting lines in place? Are these procedures documented? | 37,38,39 | N | This is not related to provenance | ||||||||
44 | C5 | ControllerObligations | Have you published the contact details of your DPO to facilitate your customers/ employees in making contact with them? (Note: post 25 May 2018 you will also be required to notify your data protection authority of your DPO’s contact details) | 37,38,39 | N | This is not related to provenance; Though the details of the DPO can be published using FOAF/V-Card for interoperability | |||||||||
45 | C6 | ControllerObligations | Data Protection Impact Assessments (DPIAs) | If your data processing is considered high risk, do you have a process for identifying the need for, and conducting of, DPIAs? Are these procedures documented? | 35 | assistive | Y | steps part of the DPIA process | This query essentially asks what steps are involved in the conducting of a DPIA; The latter part of the query talks about documentation, which can be linked and retrieved, but is not part of the provenance. | Y | Since the query relates to steps, this can be answered by the abstract model of the system | N | N | ||
46 | S1 | DataSecurity | Risks involved in processing data | Have you assessed the risks involved in processing personal data and put measures in place to mitigate against them? | 32 | assistive | Y | steps that process data | This query requires assessment of risks involved in processing of data. This cannot be done programmatically. So the query provides information about what data is being processed, allowing an exploration of the processing operations which can then be used to analyse risks. | Y | Since this is concerned with how the data is used within steps, the abstract model of the system is better suited for exploration. | N | N | ||
47 | S2 | DataSecurity | Documented Security Program | Is there a documented security programme that specifies the technical, administrative and physical safeguards for personal data? | 32 | N | This is not related to provenance | ||||||||
48 | S3 | DataSecurity | Resolving security related issues | Is there a documented process for resolving security related complaints and issues? | 32 | N | This is not related to provenance; Though the processes can be declared as steps/plans | ||||||||
49 | S4 | DataSecurity | Designated individual for security | Is there a designated individual who is responsible for preventing and investigating security breaches? | 32 | N | This is not related to provenance | ||||||||
50 | S5 | DataSecurity | Encryption | Are industry standard encryption technologies employed for transferring, storing, and receiving individuals' sensitive personal information? | 32 | N | steps that share data | This query cannot be directly evaluated without knowledge about the type of encryption used to share data. However, it can assist by providing information about what steps share data, which can then be used to explore the data sharing practices. | |||||||
51 | S6 | DataSecurity | Removing information | Is personal information systematically destroyed, erased, or anonymised when it is no longer legally required to be retained. | 32 | N | This is not related to provenance | ||||||||
52 | S7 | DataSecurity | Restoring access | Can access to personal data be restored in a timely manner in the event of a physical or technical incident? | 32 | N | This is not related to provenance | ||||||||
53 | B1 | DataBreach | Documented incident plans | Does the organisation have a documented privacy and security incident response plan? | 33,34 | evaluative | Y | processes or plan that address security incidents | This is the provenance model for how to respond to a security incident response. This can be expressed through the abstract system model. | Y | The abstract model contains information about what should happen in case of a security incident. The query will retrieve this model. | N | Y | The query can be automated as it is simply retrieving the specific plans/processes that satisfy the criteria | |
54 | B2 | DataBreach | Regular reviews | Are plans and procedures regularly reviewed? | 33,34 | N | This query does not relate to provenance; Though information about each review can be stored as a provenance trace and queried over instances to ensure they are regularly reviewed (by comparing timestamps between reviews) | ||||||||
55 | B3 | DataBreach | Notifying authorities | Are there procedures in place to notify the office of the Data Protection Commissioner of a data breach? | 33,34 | evaluative | Y | processes or plans for notifying DPC | The query provides information about processes or plans that notify the DPC. Since this is only a plan, it is queried over the abstract model of the system. | Y | The query retrieves the specific steps associated with notifying the DPC. | Y | This query can be automated | ||
56 | B4 | DataBreach | Notifying data subjects | Are there procedures in place to notify data subjects of a data breach (where applicable)? | 33,34 | evaluative | Y | processes or plans for notifying data subjects of a data breach | The query provides information about processes or plans that notify the data subjects. Since this is only a plan, it is queried over the abstract model of the system. | The query retrieves the specific steps associated with notifying the data subjects | Y | This query can be automated | |||
57 | B5 | DataBreach | Documentation of data breaches | Are all data breaches fully documented? | 33,34 | N | The query asks to retrieve documentation; Indirectly, this is provenance information, as data breaches occuring need to be stored as provenance traces, but currently this is out of context for the work | ||||||||
58 | B6 | DataBreach | Co-operation procedures for data breach | Are there cooperation procedures in place between data controllers, suppliers and other partners to deal with data breaches? | 33,34 | N | This is a complex operation, and may not be evaluable with current level of provenance information; Therefore, is considered out of scope for this work | ||||||||
59 | I1 | InternationalDataTransfer | Data transfer outside EEA | Is personal data transferred outside the EEA, e.g. to the US or other countries? | 44,45,46,47,48,49,50 | evaluative | Y | steps that share data | The query basically checks if data is being transferred to regions outside the jurisdiction of the EU. This can be done only if the relevant metadata specifies the region of transfer. | Y | This query can be evaluated on the abstract model of the system if it contains the relevant information | Y | It can also be used to resolve dynamic data transfers, though this would need further investigation of the region, such as in case of IP addresses, knowing where it is located | Y | It can be automated |
60 | I2 | InternationalDataTransfer | Special category of Personal Data in Transfer | Does this include any special categories of personal data? | 44,45,46,47,48,49,50 | evaluative | Y | results from I1, category of personal data | This query refines the previous query to identify if it includes special categories of data | Y | As before, this can be evaluated over the abstract model | N | Can be executed over instances, but identifying special categories is difficult | Y | It can be automated |
61 | I3 | InternationalDataTransfer | Purpose of Transfer | What is the purpose(s) of the transfer? | 44,45,46,47,48,49,50 | assistive | Y | steps that share data | The query may not be resolvable if the metadata does not specify the purpose of the transfer. In that case, providing information about the data transfers themselves can be helpful. | Y | Data transfers can be obtained from abstract model | Y | Instances also contain information about data transfers that may need investigations | Y | It can be automated |
62 | I4 | InternationalDataTransfer | Transfer Recipients | Who is the transfer to? | 44,45,46,47,48,49,50 | evaluative | Y | steps that share data | The query retrieves the entity the data is shared with. Since GDPR mandates this information to be present, the query should be able to retrieve it | Y | This can be evaluated over the abstract model | Y | It can also be used to investigate instances of data sharing and who they were shared with | Y | It can be automated |
63 | I5 | InternationalDataTransfer | Transfer Details | Are all transfers listed - including answers to the previous questions (e.g. the nature of the data, the purpose of the processing, from which country the data is exported and which country receives the data and who the recipient of the transfer is?) | 44,45,46,47,48,49,50 | N | This cannot be evaluated programmatically | ||||||||
64 | I6 | InternationalDataTransfer | Legality of international transfers | Is there a legal basis for the transfer, e.g. EU Commission adequacy decision; standard contractual clauses. Are these bases documented? | N | This query can be evaluated if the information exists along with each data transfer. Currently, it is assumed that this is not the case. | |||||||||
65 | I7 | InternationalDataTransfer | Transparency | Are data subjects fully informed about any intended international transfers of their personal data? | N | steps that share data | The query can be interpreted as whether data subjects are informed of any data sharing processes before they actually happen. Therefore, this is a query over the abstract model. | ||||||||