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:
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.
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:
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)