|
Automation of Disclosure Request Processing Per recommendation 9.4, only the following categories are considered to meet the criteria for automated processing of data disclosure: · Requests from Law Enforcement in local or otherwise applicable jurisdictions with either 1) a confirmed GDPR 6(1)e lawful basis or 2) processing is to be carried out under a GDPR, Article 2 exemption; · The investigation of an infringement of the data protection legislation allegedly committed by ICANN/Contracted Parties affecting the registrant; · Request for city field only, to evaluate whether to pursue a claim or for statistical purposes; · No personal data on registration record that has been previously disclosed by the Contracted Party.
Question 2: We note the first bullet specifically references the GDPR. Our understanding is the above categories were included in the legal guidance provided to the EPDP Team, and the legal guidance specifically referenced the GDPR. Our assumption is the EPDP Team considered this guidance in developing this recommendation but did not intend to exclude privacy laws outside the GDPR. In other words, though this first use case only references the specific scenario in which a law enforcement requestor has a legal basis for processing under GDPR 6(1)e (or whose processing is explicitly exempted from GDPR’s restrictions on data processing), other law enforcement authorities who are outside the EU might also qualify for automated disclosure if they have a comparable legitimate interest in processing such data under their own local law. Can you please confirm if this assumption is correct (or if, conversely, the intention was only for EU law enforcement requests to have the potential for automation under this use case)? |
|
The assumption is correct. Even EPDP was created to develop ICANN policy to accommodate the GDPR requirements, the EPDP Team took broader approach and attempted to formulate recommendations that would correspond not only to the GDPR, but also to all existing and possible future privacy regulations in different parts of the world. Reference to specific provisions of GDPR in 9.4.1 is evident as it was existing regulation at the time of the formulation of the recommendation. |
|
The areas identified in the SSAD that interact with ICANN Contractual Compliance, like requestor/data subject procedural complaints and Contracted Party SLA issues, appear to integrate well within the existing processes that ICANN Contractual Compliance employs. For instance, the complaints from requestors and data subjects could come through external facing complaint forms that would be developed, and if needed, automated processes may be developed for processing issues such as those related to SLA violations. From there, the complaints can be processed per ICANN Contractual Compliance’s standard approach and processes.
Question 1: Does the proposed approach regarding development of potential complaint forms or automated notifications (where possible) fulfill the intentions of the recommendations? |
|
Indeed, it was intention – to use the existing ICANN compliance mechanism in case the requestors or registries/registrars could file a compliance complaint in situations prescribed by the policy recommendations. It was never planned, though, that data subjects would be able to use ICANN's compliance mechanism. |
Dear Janis,
As discussed during today’s call, here is the additional context behind the question 1:
The areas identified in the SSAD that interact with ICANN Contractual Compliance, like requestor/data subject procedural complaints and Contracted Party SLA issues, appear to integrate well within the existing processes that ICANN Contractual Compliance employs. For instance, the complaints from requestors and data subjects could come through external facing complaint forms that would be developed, and if needed, automated processes may be developed for processing issues such as those related to SLA violations. From there, the complaints can be processed per ICANN Contractual Compliance’s standard approach and processes.
Question 1: Does the proposed approach regarding development of potential complaint forms or automated notifications (where possible) fulfill the intentions of the recommendations?
Please let me know if we may provide any further clarifications.
Regards,
Yuko
From: Yuko Green <yuko.green@icann.org>
Date: Monday, October 18, 2021 at 1:59 PM
To: Janis Karklins <karklinsj@gmail.com>
Cc: "odp-ssad@icann.org" <odp-ssad@icann.org>
Subject: Request for verification/feedback on SSAD recommendations
Dear Janis,
As we continue to develop Org’s assessment for the SSAD ODP, we came to additional questions/assumptions that we would like GNSO Council’s confirmation and/or clarifications.
Contractual Compliance
In the SSAD, there are two areas that implicate ICANN Contractual Compliance intervention:
- Alert mechanisms/complaints regarding Contracted Party behavior (Recs 5.3, 5.4)
The recommendation states the “alert mechanism is not an appeal mechanism – to contest disclosure or non-disclosure affected parties are expected to use available dispute resolution mechanisms such as courts or Data Protection Authorities…”
As a result, Compliance’s role is limited to investigating complaints related to procedural failures by the contracted party.
- Contracted Party SLA requirements (Rec 10)
Similar to existing processes, complaints or investigations related to contracted party requirements for SSAD may be received and processed through public-facing complaint forms that feed into the Naming Services portal (NSp) and result in individual cases.
If needed, develop automation of complaints related to violations as those may be triggered from internal reporting.
Question 1: Does the proposed approach regarding development of potential complaint forms or automated notifications (where possible) fulfill the intentions of the recommendations?
Automation of Disclosure Request Processing
Per recommendation 9.4, only the following categories are considered to meet the criteria for automated processing of data disclosure:
- Requests from Law Enforcement in local or otherwise applicable jurisdictions with either 1) a confirmed GDPR 6(1)e lawful basis or 2) processing is to be carried out under a GDPR, Article 2 exemption;
- The investigation of an infringement of the data protection legislation allegedly committed by ICANN/Contracted Parties affecting the registrant;
- Request for city field only, to evaluate whether to pursue a claim or for statistical purposes;
- No personal data on registration record that has been previously disclosed by the Contracted Party.
Question 2: We note the first bullet specifically references the GDPR. Our understanding is the above categories were included in the legal guidance provided to the EPDP Team, and the legal guidance specifically referenced the GDPR. Our assumption is the EPDP Team considered this guidance in developing this recommendation but did not intend to exclude privacy laws outside the GDPR. In other words, though this first use case only references the specific scenario in which a law enforcement requestor has a legal basis for processing under GDPR 6(1)e (or whose processing is explicitly exempted from GDPR’s restrictions on data processing), other law enforcement authorities who are outside the EU might also qualify for automated disclosure if they have a comparable legitimate interest in processing such data under their own local law. Can you please confirm if this assumption is correct (or if, conversely, the intention was only for EU law enforcement requests to have the potential for automation under this use case)?
We would very much appreciate your help in relaying these questions to the GNSO Council. If you have any questions, please do not hesitate to contact us.
Regards,
Yuko Yokoyama
Program Director
Strategic Initiatives, Global Domains & Strategy
Internet Corporation for Assigned Names and Numbers (ICANN)