OFFICIAL Afternoon all sorry for the response overlapping the meeting, please find responses to the questions in red below which we will cover in todays meeting. Regards Chris The RrSG has reviewed the LEA1 use case provided by the GAC team, and has the following feedback. ● In section (b), the RrSG is pleased to see the request limited to “Non-public registration data,” and affirms that this SSAD must not be used to disclose other data that may be held by the Controller, it should be limited only to previously-public registration data. ● In section (c), there is the expectation that not only redacted data is provided in the SSAD, but also data which are publicly available. The SSAD should be restricted to providing only non-public registration data which was previously public, and should not include currently-public data. We feel this gives an increased accuracy in processing the data, could you give a reason why this data should not be given by the disclosing party. ● For section (c), the RrSG notes that the footnote “For each request, the requestor will need to confirm which data elements are necessary.” is a part of the template, and may not be understood to be a mandatory part of the use case and any disclosure request. It should be clarified that the requestor must request only the minimum relevant data, and the Controller should disclose only the minimum relevant data. Agree change. ● Section (d) indicates the “Lawful basis of entity disclosing non-public registration data to the requestor” as 6 (1) f (legitimate interest). This is acceptable as the basis on which the disclosing entity provides the data, however we do note that the requestor needs to also indicate the legal basis for the request itself, which is likely to be 6 (1) e (public interest) Legal basis for the requestor is under section e ● In section (e), jurisdiction should also be part of the supporting info that is provided with the disclosure request, and there are related questions that the plenary team should consider. E.g., does an LEA have the authority to request non-public data from a non-local controller and does the non-local controller have a legal obligation/dispensation to provide such data to a foreign LEA. If the requestor is using 6.1f then no compulsion from the LEA is being used. Having the authority to request data would be dealt with under by accreditation /authentication but must be confirmed before release safeguard suggestion below would hopefully cover this? ● For section (f), we propose an additional safeguard: The requestor must be endowed with the appropriate legal authority to make such a request of a non-local controller. Agree change ● In section (g), the disclosing entity should have an additional safeguard: they must be enabled to verify the legal authority of the LEA to make the request. Via a accreditation /authentication method? ● Also in section (g), the RrSG notes the addition of this text: “The data subject should be able to challenge-with proper substantiation-the balancing test with rights to object and to erasure.” The right to erasure would seem to apply not to data disclosed through the SSAD but instead to the data held by the Controller; how would the right to erasure be operationalized here? Applicable to the disclosuring body so an erasure in this case would be removal of the Domain name and all related records assuming they are the rr/ry else another body would be the deletion of any records held (assuming any are held). ● The section (h) description has been updated to specify an automated system; this is not necessarily what the SSAD will require. It may be that an SSAD functions best when the expectation is manual review rather than automated processing; the decision has not yet been made and should not be presumed. Think this and other sections are what if this was agreed ● Also in (h), the RrSG is pleased to note that the disclosure is limited to the current registration data set, and will not include historical records. We would suggest also that this be limited to specific domains, bulk requests should not be considered. By bulk do you mean unrelated or do you mean multiple domains? ● In section (i) the RrSG again objects to the addition of “automatic” to the section description. This and other sections are provided along the lines of what if this was agreed ● Section (j) is strangely worded and the RrSG could not parse the intent of the section; we would appreciate clarification from the GAC team.
From earlier input we would suggest adding jurisdiction and legal basis to this
● In section (m) the required timeframe for a substantive response is 2 business days. This is not a sufficient period of time to review and address requests. Recommendation 18 of the EPDP Phase 1 Report gives 2 business days for acknowledging receipt of a request; we should not now modify this to require substantial response in that same 2 day period. If there will be any SLA in place, there should also be an exception to allow for manual processing of complex or questionable requests. As this is just for LEA use cases we believe this is a viable time frame for the expected volume within this subset. ● The RrSG does not agree with section (n), that automation of the substantive response is possible/desirable. Requests must be reviewed so that the balancing test can be performed, which is difficult to automate. It may be that a hybrid-style system is useful, in which an automated system does a first pass and then a human reviews the results and completes the disclosure. Worth further discussion The NCA email domain has changed to @nca.gov.uk. To ensure your email gets through please do not use @nca.x.gsi.gov.uk ************************ This information is supplied in confidence by NCA, and is exempt from disclosure under the Freedom of Information Act 2000. It may also be subject to exemption under other UK legislation. Onward disclosure may be unlawful, for example, under data protection legislation. Requests for disclosure to the public must be referred to the NCA FOI single point of contact, by email on PICUEnquiries@nca.gov.uk. All E-Mail sent and received by NCA is scanned and subject to assessment. Messages sent or received by NCA staff are not private and may be the subject of lawful business monitoring. E-Mail may be passed at any time and without notice to an appropriate branch within NCA, on authority from the Director General or their Deputy for analysis. This E-Mail and any files transmitted with it are intended solely for the individual or entity to whom they are addressed. If you have received this message in error, please contact the sender as soon as possible.