Frequently Asked Questions

Audit Program Frequently Asked Questions

Audit Methodology Questions

Audit Documentation Questions

Audit Program Service Provider Questions

New Registry Agreement Audit Questions

Domain Name System (DNS) Infrastructure Abuse Registry Audit Questions

Audit Methodology Questions

1. How long will the audit take?

   The audit timeline is approximately five months: one month to collect the data (Request for Information or RFI), three months to audit the data collected, and one month to report the results. ICANN is committed to keeping the impact to the contracted party minimal, if all data is provided upon request during the RFI process (otherwise, follow up questions or requests to the contracted party may be needed).

2. What algorithm ICANN used for randomly selecting Registrars/Registries during the three-year audit program?

   ICANN will use StatPlus, a random # generator based on the sample size input and the population. StatPlus is a similar algorithm calculation program as Data Analysis/Random Sampling in Excel: Computerized random sampling method where a user inputs the sampling conditions (i.e. the sample size desired, total population) and other conditions, like the confidence level, defaults to the original standard parameters within the application.

3. What is ICANN's current approach for selecting Registrars and Registries for audit?

   ICANN uses the following factors in its process to select parties for audit:

   • Contracted parties that have not been previously audited
   • Contracted parties that were audited over 2 years ago
   • Contracted parties with highest numbers of 3rd Notices per number of domains under management calculated over the past 12 months
   • Contracted parties that had received a Notice of Breach in last 12 months
   • Contracted parties with highest numbers of failed data escrow deposits
   • Contracted parties with low responsiveness to ICANN's requests/inquiries
   • Contracted parties with issues that were remediated and are re-occurring again
   • Contracted parties for which there appear to be ICANN community concerns, as reflected in media reports, blogs, or inquiries/reports from community members or other contracted parties
   • Contracted parties that had changes to the delivery of services (for ex. Changes in service providers, data escrow agents, etc.)

4. What does ICANN plan to report to the community?

   ICANN will issue two standard reports: (a) an audit report listing the Registrars/Registries randomly sampled by year, as well as the provisions audited; and (b) a deficiencies report listing all deficiencies found through the audit, by statistics only and not by the Registrar/Registry. A summary, by provision, of the pass versus fail rate will be an example of a statistic to be published.

   Reports will be defined during the planning phase and a list will be made available on the Contractual Compliance webpage (Under "Audit Program"). All statistics will be published, including the Registrar/Registry name, and provision audited. Individual audit reports will be sent to each Registrar/Registry either during or at the close of the audit phase.

5. How will ICANN audit a Registrar/Registry group that has multiple agreements?

   Each agreement will be audited separately. Contracted parties may submit the same data/records in response to the RFI for multiple entities if the data/records apply to those entities.

6. How will the Registrars and Registries receive the Pre-Audit Notification and RFI notification?

   Both Pre-Audit and RFI notification will be sent only to contracted parties selected for audit via email.

7. How will ICANN collect the data and ensure its security?

   All data and records will be collected in a secure, encrypted repository with strict access controls by designated and specific user access permissions.

8. How long will ICANN hold data collected from the Registrars/Registries?

   ICANN is committed to retaining data collected through the audit for the minimum period under ICANN data retention policy.

   If no issues are identified within the Registrar/Registry response, the audit data will be destroyed after six months.

   For the Registrar/Registry for which contractual compliance issues are identified, data regarding such instances of non-compliance will be retained until resolution, plus six months. (For example, if the data provided through the audit demonstrates that a Registrar does not have a certificate of general liability insurance, but is in compliance on the other items audited, ICANN will only retain data related to the insurance issue for the longer period of time.)

9. What specific registrar agreement and registry agreement terms is ICANN auditing?

   All contractual obligations, including ICANN consensus policies, are potentially subject to an audit. The scope will be communicated within the Pre-Audit Notification Letter as well as in the RFI. When identifying the specific obligations to be included in an audit, and to minimize resource impact, ICANN will take into account factors such as community needs, risk assessment, time, resources and costs.

10. How is ICANN validating responses?

    ICANN performs both manual and automated validation efforts based on the data received. All data is to be validated against pre-defined steps as part of the overall audit plan. ICANN compares the responses and follow up where questions exist. Please see the audit plan posted here: https://www.icann.org/resources/pages/audits-2012-02-25-en

11. What happens if issues are identified?

    ICANN follows the Contractual Compliance Informal Resolution process [PDF, 1.15 KB], also referred to as the 1-2-3 process which consists of 15 business days for Notice 1, five business days for Notice 2, and five business days for Notice 3. There are various issues that could be identified during this process: failure to respond, responding with inaccurate or incomplete data, or a situation where the Registrar or Registry identifies an issue internally during the audit and notifies ICANN. All issues will be followed up directly with the contracted party, prior to publishing any statistics. If the responses result in a resolution of the issue identified, then that will not be noted as an issue in the posted audit results. Otherwise, outstanding issues remaining after the audit closed will be reported to Registrar or Registry in the final deficiencies report. The outstanding issues will be published online in the Notice of Breach when it reaches the Formal Resolution Process also known as the enforcement stage.

12. Why not audit just the "bad" players? Why audit everyone?

    Audits are a valuable component of any organization's contractual compliance function because they offer the opportunity to generally: (a) gain insight into performance weaknesses; (b) develop predictability expectations for contracting parties; (c) assist ICANN in developing effective and efficient mechanisms to ensure contractual compliance, including through consistent and equitable remediation efforts; and (d) allow ICANN to enhance community transparency through fact based and measurable reporting. Once the baseline has been established, ICANN will consider a more focused approach based on contracted party audit results.

13. What's the basis for including all contracted parties, when the 'Right to Audit' clause isn't present in 2001 RAA and Registry Agreements?

    One of ICANN's responsibilities is to conduct audits of its agreements in order to ensure that all contracted parties are in compliance with those agreements.

14. Gathering the data requested to respond to some questions may take longer than 15 days, will extension requests be freely granted?

    Extension requests will be reviewed and assessed on a case-by-case basis. With the advanced planning and publishing of the overall audit plan, contracted parties are encouraged to review the plan and prepare for the audit.

    Registry Operators will have 15 business days to reply to the RFI. If there is no reply from the registry operator (or incomplete data is provided), ICANN will follow up with a second and third notice, as needed (five business days to reply to each). Failure to respond to the third notice (or still providing incomplete data) will result on a notice of breach to the Registry Operator. Only the notice of breach is published on ICANN's web site. ICANN will collaborate in each phase to clarify what information is missing or incomplete.

15. If a deficiency is discovered and a remediation plan is agreed upon, can we avoid being breached?

    Yes. If a deficiency is discovered, a remediation plan is agreed upon, and the contracted party delivers in accordance with the remediation plan timeline, ICANN will not breach that contracted party for those issues that have been remediated. If the contracted party fails to comply with the remediation plan, ICANN will follow the compliance approach and process in the informal resolution (1-2-3 step) phase prior to enforcement.

16. ICANN states that 'Registrars or Registries may be subject to more than one audit in a three-year cycle based on special circumstances or considerations.' What circumstances or considerations would cause multiple audits?

    Special circumstances or considerations may include excessive compliance issues identified during the audit, excessive complaints, or other unforeseen reasons requiring additional reviews. If such circumstances exist, the contracted party will be notified in advance of receiving a second RFI.

17. One of my registrars/registries went through an audit last year. Another one of my registrars/registries has been selected for audit this year. Is there any way we can be waived from this year's audit?

    As set forth in ICANN's audit guidelines regarding "opt out" from the inception of the three-year audit plan (Beijing ICANN46), a registrar or "family of registrars" (i.e., a group of companies that has the exact same operations and processes in place and are under common ownership and/or have a parent/subsidiary relationship organizational structure) may "opt out" of an audit only if the following criteria are met:

    (1) There are no significant deficiencies or multiple deficiencies noted from the prior year audit,
    (2) There are no significant organization or process changes over the course of the year and the registrar/registry can attest to the accuracy of the control environment, and
    (3) There are no significant ICANN Policies/Contracts that have been implemented prior to the audit cycle.

    Please send an email to ICANN Contractual Compliance at complianceaudit@icann.org if you believe that your registrar/registry qualifies to "opt out" of audit for the current audit cycle.

    Back to Top

    Audit Documentation Questions

18. With regards to RFI's request for evidence that registrants accepted terms & conditions in our Registration Agreements, some of our Registration Agreements are subject to Non-Disclosure Agreements. How can we seek to provision for the data you require without breaching client confidentiality?

    The RAA allows the contracted parties to designate information provided to ICANN as confidential information to be maintained in confidence. Registrars need to inform ICANN if delivering the information being requested violates any law and need to indicate the applicable country, name of the law, number (as applicable), with an explanation of why delivery of the information to ICANN under an obligation of confidentiality would violate the local law.

    In response to request above in the RFI, ICANN does not need to see confidential information such as prices, customer info, and service description; when and where appropriate, please mask or redact the confidential information in the registration agreement that is subject to confidentiality. The Registrar needs to demonstrate that the registrant accepted the Terms & Conditions for registration. Another approach to this question that other registrars have taken is to provide a log that shows timestamp of acceptance.

19. Often, registrars have payment proof not only for the domain, but also for other services. Does the audit request payment proof of all services or only the domains?

    For audit purposes, ICANN needs payment proof for the domains. You do not need to send proof of payments for other services.

20. Does the invoice itself act as proof of payment for domain? Or should we provide financial statements of the payment provider?

    The invoice itself is not an evidence of payment received; however, an invoice marked as "Paid" would be considered as proof of payment. Other evidences of proof can be bank statements, PayPal statements, or similar statements that show payment was received.

21. Would invoices that indicate "total amount charged" or "transaction complete" act as proof of payment?

    As long as the invoice shows that the payment was for the domain, it would be considered as the proof of payment. On the other hand, if the invoice shows only the amount paid and no relation to any domain name, it would not be considered as proof of payment unless additional proof is provided.

22. Does the audit request proof of the last payment or of any prior periods?

    As stated in RFI, the audit only requests the most recent payment.

23. With regards to RFI's request for evidence of payments for selected domains, we invoice our clients in a consolidated manner rather than transact via web site/credit card per domain. For "proof of payment", is it sufficient to provide invoice number and date in which the payment for these domains is included?

    A proof of payment as described above providing invoice number, date and time of the transaction, domain name and an indication that it is a payment transaction is sufficient.

24. Some of the domains were registered five years ago and are not paid for the last five years. What should registrars do if they cannot find the payment records of those domains? To the extension of this question, how many years are registrars supposed to keep the payment records?

    The RFI requires evidence of the most recent payment received for the registration of each domain name included in the sample. If the registrar cannot provide the appropriate records, the registrar will be notified of the deficiency and will begin a remediation plan.

    The 2009 RAA requires registrars to maintain records and information for the life of the domain name and three years after the deletion or the transfer away of the registration.

25. Domains registered during LandRush followed a different procedure. What should registrars do with those domains if they do not have registration logs?

    Domains registered during LandRush do not apply to the current RFI, because it is out of the scope of the 2009 Registrar Accreditation Agreement. This matter falls under the new registry agreements; at this time, provisions of 2013 RAA are not being audited.

26. What exactly is the RFI Excel spreadsheet for?

    The RFI Excel spreadsheet acts as a summary sheet of the information registrars and registries provided. For example, registrars and registries can enter words such as "Done;" "Uploaded" or leave it blank to indicate the request documents are submitted. When something is not applicable, registrars and registries can provide details such as "N/A, no transfers are made in last 45 days;" "N/A, we don't keep these records due to …." or "N/A, we can't find any documentation." With such spreadsheet, the auditor can clearly navigate the audit process.

27. Are we required to fill out the RFI Excel spreadsheet in addition to uploading information in the folders?

    Yes.

28. What is in the RFI?

    The RFI includes questions and some examples of the documentation that auditors are looking for.

29. There are domains that are in ASCII format, but I would like the Unicode format.

    Registrars may use the following web site to convert the ASCII domain name to Unicode format: http://mct.verisign-grs.com/.

30. Cells that are designated for phone/fax numbers in the Request For Information document are supposed to be filled with phone & fax numbers but the format of those is set and locked to something else. Thus each time I am entering a phone number it is converted to a random number. For example I am trying to enter the number +552.2812517 into cell F11 (which is our primary contact phone number) but Excel is automatically turning it into 55.228.125.17.

    Please do not enter + sign in the beginning; Excel will treat it as formula.

31. Are there any limits on the file formats that may be uploaded to the web site? Is it restricted to only .TXT, .DOC, and .PDF?

    There are no restrictions on file format; you can upload files in any non-proprietary formats.

32. If the documentation to be uploaded includes email communication, will ICANN request logs proving the mail was received at the senders' host?

    ICANN would expect to receive full TCP headers for the email messages that your registrar sends to the registered name holders.

33. For "Request for Domain Deletion & Auto-Renewal Policy," do registrars upload the policy, or simply show a link to the live webpage on the Excel spreadsheet instead?

    Either way is acceptable. Registrars may upload the policy, or simply show a link to the live webpage on the Excel spreadsheet.

34. What exactly is the auditor looking for under the request of public contact?

    Auditor is looking for accurate and complete public contact data in RADAR.

35. There is a question on the RFI Excel spreadsheet that requires information whether the selected sample domains were transferred out or in within specified timeframe. If the selected sample domain does not have any transfer activities within the indicated period, would "N/A" be an appropriate answer?

    For domains that have not been transferred out or in within the indicated period, "N/A" is an appropriate answer. If there has been a transfer, the appropriate answer would be either "Gaining/Transferred In" or "Losing/Transferred Out."

36. With regards to question in the RFI that is asking for FOAs/AuthCodes, does this only refer to the domains that have transferred, as it was indicated in the answer to prior question?

    Yes, this question applies only to domains that are marked "Gaining/Transferred In" or "Losing/Transferred Out" in response to prior question.

37. Some companies own several registrars, brands and trademarks. In some cases, the company's registrar may register domain names to its brands for commercial purposes by using registrar's name as the registrant. The end result is that the registrars have registered domain names to themselves. Under such circumstances, would "N/A" be an appropriate answer to the request of "Registration Agreements"?

    Registrars can also be registrants for domain names registered through use of their own accreditation provided that the domain names are used for the provision of registrar services. If registrar enters "N/A" in the spreadsheet, the registrar will need to provide explanation of how the domain name is used for: (1) contracting with domain name holders; (2) collecting registration data about registered name holders; and (3) submitting registration data to the registry operators.

38. The audit notice states: "If you are part of a family and multiple registrars within your family were selected, you can respond for one IANA number within your family ONLY if all selected registrars operate the same, technically and operationally." Does it mean we can answer for the domain names identified for one registrar only?

    Yes, it does. However, please provide a list of all Internet Assigned Numbers Authority (IANA) numbers of the family members and indicate which IANA number you are choosing to represent the family. Or, alternatively, you can indicate on each family member's RFI – "member of the family, see IANA xxxx."

39. Are the RFIs for the registrars public? Are the responses to the RFI from registrar audits made public in an anonymized form at all?

    Neither RFI nor responses to RFI provided to ICANN are made public.

40. When an email is sent to ICANN Contractual Compliance do we get an acknowledgment immediately (automated) or if not automated then what is the expected time frame to receive the first acknowledgement of the email?

    There is no automated acknowledgment from the ICANN Contractual Compliance email address when it has received an email. We recommend that you send emails to ICANN Contractual Compliance (complianceaudit@icann.org) with a delivery receipt selected for your email so that you know that we have received it.

    ICANN's Contractual Compliance team strives to acknowledge receipt of emails and when possible, reply in substance, to all inquiries within three to five business days.

41. Are replies to questions and documentation requested in the Request for Information acceptable in English only or other languages are acceptable?

    Replies in Registrar's native language are acceptable; documentation is acceptable in the original language, no translation is required.

42. Request for Information requests Registrar Self-Assessment Certification (CEO Certificate). What is the CEO certificate?

    The Registrar Self-Assessment Certification (CEO Certificate) template can be found at the following link https://www.icann.org/resources/pages/ceo-certification-2014-01-29-en

43. I lost my upload log on information (or it does not work), what should I do?

    Email complianceaudit@icann.org and request new log on credentials.

44. I am having difficulty opening the RFI, what should I do?

    Email complianceaudit@icann.org and specify the difficulty you are having. ICANN will work with you to provide RFI in other formats.

45. Where is the 2013 RAA Registrar Training located?

    Click here: https://www.icann.org/resources/pages/registrar-training-resources-2015-09-23-en – this link provides the content hosted by ICANN (http://learn.icann.org) as well as a link to an alternative YouTube version of the content. Use whichever is more convenient for you, but note that 1) quizzes are not included in the YouTube version; and 2) translated-subtitle versions of the training are only available on learn.icann.org (from the home page, select your language at the top of the screen, then select the 2013 RAA Registrar Training.)

    Back to Top

    Audit Program Service Provider Questions

46. How did ICANN select the Audit Program service provider?

    Preparation and planning for the Audit Program began in April 2012. The methodology, approach and Request for Proposal (RFP) were designed and approved in late May 2012. The RFP was released to five pre-selected firms on 13 June 2012. ICANN identified the five audit firms based on the following criteria: knowledge of ICANN, global presence, size, expertise, and reputation. ICANN followed its normal procurement process: RFP issued, Q&A, Proposal Analysis, Scorecard Ratings Methodology. A cross-functional steering committee was formed to evaluate and rank the firms. The vendor selection is based on the steering committee's evaluation and consultation with the ICANN executive management team.

47. What happens if the auditors being considered are also new gTLD Applicants? Does this pose as a conflict of interest?

    The Audit Program service provider is required to disclose and publish any and all actual or potential organizational, as well as individual staff members', conflicts of interest and propose a mitigation plan for each disclosed circumstance. At a minimum, the service provider is required to deploy an ethical wall between those working on the audit and those that have any involvement in a registry or registrar. This helps ensure confidentiality, as well as mitigate any potential or actual conflicts. If ICANN is made aware of a conflict, ICANN will employ all available resources to mitigate any issues and, at a minimum, will internally review all documentation provided by the contracted party, rather than have anyone with the Audit Program service provider review such documentation.

    Back to Top

    New Registry Agreement Audit Program Questions

48. How will the New gTLD Compliance Audit Program impact the new Registry Agreement Audit Program audit plan?

    The audit plan is impacted in terms of the scope as it related to the number of registry operators that sign the new Registry Agreement with ICANN and the changes to the agreement (exemptions, additional obligations, etc.).

49. Who will the RFI be sent to?

    ICANN will email the RFI to the registry operator's compliance point of contact, with a copy to the primary contact.

50. Will ICANN publish a guide on how to pass the audit?

    ICANN does not provide a guide on how to pass the audit. Please respond and provide the requested information per the required date. ICANN will review and follow-up on a case-by-case scenario.

    Please consult with your legal, technical and operational teams on the steps required to pass the audit.

51. Will ICANN be providing additional details regarding the methodology and further guidelines to enable us to provide you with more detailed feedback?

    ICANN has shared, to the extent possible and appropriate, the audit approach. Additional details related to testing methodology are not provided to auditees. This is a common practice in auditing.

52. Is there a provision for the registry operator to request additional time in order to respond to the RFI?

    ICANN is following its standard approach; parties will have 15 business days to provide the requested information. If information is not provided, further notifications will be issued, providing some extra time, before matter is potentially escalated to a breach of contract.

53. Can we expect a more precise WHOIS specification (other than Specification 4) prior to the audits?

    At this point, the audit is based on the WHOIS Specification 4 as outlined in the registry agreement. The auditors will take into consideration any additional guidance on the subject, as soon as it is finalized.

54. How many TLDs will be audited? Is there a requirement for at least one registry operator from each region?

    The objective of the new Registry Audit Program is to select a representative sample to test the overall compliance with the different contractual obligations. The number of TLDs selected for audit is based on selection criteria which does not include physical location or place of registration of a registry operator. Thus, it is possible that there will be more than one (or none) TLDs selected for an audit for a certain region.

55. Will there be consideration given to registry service providers that support multiple registries?

    The audit covers registries, as they are the contracted parties for ICANN. It is possible that several registries, serviced by the same registry service provider will be selected for audit.

56. Will the RFI require registries to repeat everything that's already in the new gTLD application and/or the Agreement?

    The RFI will take into consideration applicable previously submitted information. If the RFI calls for information that registry operator provided during application, then the registry operator should state that and respond that there have been no changes since the application was submitted.

57. Is the New Registry Audit Program target all gTLDs in existence?

    This program targets gTLDs that have signed the 2 July 2013 base registry agreement, as amended from time to time.

58. There are provisions in the New Registry Agreement that apply once a year in January. If the registry operator signed before 1 January but was delegated in May, does that annual provision apply?

    In this case, the registry operator may respond "not applicable" to questions in the RFI and briefly explain the reason why.

59. Will ICANN provide guidelines on the form of expected responses?

    The RFI will provide general guidelines to the form of expected documentation and responses.

60. Will detailed explanations be required or will it be self-certification?

    The RFI may include some questions where self-certification (or a statement) is sufficient. Other questions may require documentation and/or detailed explanations.

61. Will some of the audit checks be actual transaction tests?

    The audit checks will be performed based on the need to validate compliance; some tests/checks might include actual transaction tests.

62. Will ICANN be conducting site visits as envisioned in the Registry Agreement?

    At this time, site visits are not planned, but are possible.

63. During the claims period for each registry, will ICANN audit whether the domains registered have not been approved by the Trademark Clearinghouse Database (TMDB)?

    Yes, ICANN will audit that during the claims period the registry, prior to domain registration, verified whether or not the domain name have been in TMDB.

64. Section 2.11b of the New Registry Agreement requires the registry operator to reimburse ICANN for audit costs incurred where the registry operator is vertically integrated; can you provide rough cost estimates for budgeting purposes?

    At this time, ICANN will incur the cost of the audit program.

65. Is Centralized Zone Data Service (CZDS) in the audit scope?

    Centralized Zone Data Service will not be audited; it is not one of the audit program focus areas at this time.

66. Will the Registry-Registrar Agreement be required to be presented as part of the audit?

    RRAs are in the audit scope (see audit scope http://www.icann.org/en/resources/compliance/outreach/registry-agmt-audit-12may14-en.pdf [PDF, 714 KB]). ICANN will review some of the provisions in RRAs to confirm the compliance with Code of Conduct (and, possibly, some other provisions of Registry Agreement).

67. Question 6.B in the RFI, refers to "custom policies" regarding reserved names. What are "custom policies" regarding reserved names?

    Article 2.6 of the Registry Agreement (RA) states that "…Registry Operator may at any time establish or modify policies concerning Registry Operator's ability to reserve (i.e., withhold from registration or allocate to Registry Operator, but not register to third parties, delegate, use, activate in the DNS or otherwise make available) or block additional character strings within the TLD at its discretion." The audit refers to this as "Custom policies". If the TLD has created any policies covering reserved names, please disclose such policies. If not, please state "No."

68. Questions 7.a and 7.b requests in RFI requests a registry operator's to upload its Business Continuity Plan (BCP) and most recent results of BCP's annual testing. What are the expectations of ICANN with respect to Business Continuity Plans for TLDs?

    As stated in Specification 6, Article 3.3 of the RA, "Registry Operator shall maintain a business continuity plan." Therefore, it is expected that a Business Continuity Plan should be in place by the TLD delegation date. In addition, Article 3.3 also specifies that the BCP should be tested annually by each TLD.

69. Question 9 of the RFI is about the cross ownership between registry operators and registrars and/or resellers. What if a registry operator is not entitled to obtain accounting books or financial records of the registrar or reseller with whom it is vertically integrated?

    Please provide an explanation as to why the registry operator is not able to obtain the records, and indicate where revenues from its registrar or reseller are captured in the registry operator's financial statements.

70. Question 12 of the RFI requests that the registry operator upload all of its Registry-Registrar Agreements (RRAs) to ICANN's Contractual Compliance site. Is this correct?

    There are multiple ways to comply with this request: (1) by uploading a full copy of all RRAs (signature pages are optional) that your registry operator has in effect, or, (2) by uploading the standard RRA, the pages of any RRAs that are different from the standard template and provide a list of the registrars and resellers for the TLD. ICANN may select registrars and/or resellers from the list and request its full RRA.

    Back to Top

    Domain Name System (DNS) Infrastructure Abuse Registry Audit Questions

71. What are the legal bases, such as clauses in the Registry Agreement, for audit questions inquiring about registry operators' abuse handling processes and procedures?

    For most generic top-level domains (gTLDs), there are clear requirements regarding abuse handling in the Registry Agreement, including Specifications 6 and 11 of the Base Registry Agreement. While the agreements describe the obligations, they do not define how an audit will assess compliance with the obligations. The abuse-related audit questions seek to determine whether the registry operators' processes and controls support the explicit contractual obligations. It should be noted that some legacy gTLD agreements do not have audit obligations nor do they have obligations to address DNS infrastructure abuse. For these registry operators, we seek their collaboration in an effort to learn about the registry's procedures in handling DNS abuse and security threats, if any. The audit results will inform the ICANN Community on the active role contracted parties are taking in combatting DNS infrastructure abuse.

72. During the webinar, ICANN mentioned 'good practices' observed from the March 2018 DNS abuse-related audit responses. Are these good practices contractual requirements?

    Good practices are not contractual requirements. A good practice is a process, a methodology or a practice that has been proven to work well and produce results; therefore, it can be recommended as a model. The essence of identifying and sharing good practices is to learn from others.

    Examples illustrating registry operators' good practices in this area include:

    • Security threat analyses are conducted frequently, and reports are retained
    • Registry operator identifies abusive domains through proactive monitoring (technical analysis)
    • Reports include abusive domains identified in publicly available abuse reports
    • Registry operator sends requests to sponsoring registrars to review domain activity and suspend abusive domain names during the review
    • Registrar responds to registry operator, complying with registry operator request for review
    • As a result of the review, some domains are deleted, suspended or no action taken due to conclusion that domain is not actually abusive
    • Registry operator retains and provides communications regarding actions taken on abusive domains

73. What kind of abuse monitoring is expected from gTLDs without third party registrants (i.e. Registry has only domains under its direct control) and Brand gTLDs?

    ICANN is aware of registries without third party registrants and of the uniqueness of Brand gTLDs (gTLDs with an approved Specification 13 in its current registry agreement). Although these registries presumably have control over the use of its second level domains, the potential for abuse continues to exist and Specification 11 of the registry agreement remains applicable. In cases where abuse monitoring is not already being conducted, ICANN is requesting an explanation and additional information regarding any future monitoring plans.

74. Can we receive an exact timeline for this audit?

    Slide five of the November 2018 registry audit webinar presentation has been updated with the audit timeline. The audit program follows the ICANN Contractual Compliance Approach and Process. Upon receipt of the Request for Information (RFI), registry operators have 15 business days to respond. If there is no response, ICANN will follow up with an additional 5 business day deadline and provide a final 5 business day deadline before escalating to enforcement. If additional time is requested, ICANN will review the request on a case-by-case basis, based on the amount of information that was provided prior to such request and the reason for the request.

75. Were the expenditures for this audit in the budget for the current year?

    Yes, ICANN planned for this audit in its budget.

76. Is it possible to receive a link to the online Request for Information (RFI) that applies to all gTLDs that are managed by a single registry operator (instead of one link per gTLD)?

    At this time, we are not able to provide this functionality. Links to online-based RFIs are gTLD-specific. If a registry operator wishes to respond to the RFI questions and provide requested documentation (that uniquely addresses each gTLD) via a single RFI response, please communicate this request to ICANN for review and approval.

77. How does ICANN suggest registry operators justify the transfer of any personal data in its Request for Information (RFI) response, considering some of the data will be coming from the EU and may be subject to GDPR?

    ICANN Contractual Compliance is not requesting personal data as part of the audit. Please note, the audit Request for Information (RFI) has the following warning -- "For any documentation provided, please comply with local laws, if applicable, and redact any data deemed private (e.g. personally Identifiable Information)."

78. How will ICANN determine whether a registry operator provided an incomplete security threat analysis and report?

    ICANN will review the registry operator security threat report and compare the data to publicly available abuse reports, as provided by sources listed below. If ICANN determines that a report is incomplete based on this comparison, we will provide a sample of abusive domains from the publicly available reports that are not in the registry operator's reports. We will also provide evidence of each domain's abuse type, where applicable and available.

    For example, in the March 2018 gTLD Audit round, some registry operator security threat analysis reports appeared to be incomplete when compared to publicly available reports because there were gTLDs with domains missing from their security threat analysis reports that had been publicly identified as abusive. ICANN reported these examples as initial findings (rather than noncompliance) to the registry operators. The registry operators were cooperative and accepted the findings based on the information provided. As a result, they made some updates/changes to their monitoring system and/or process, and their reports significantly improved to include all or most of the publicly available information.

    The reputation service providers that ICANN org relied on include MalwarePatrol, PhishTank, Spamhaus and SURBL. We are continuing to rely upon the sources which are also used by Domain Abuse Activity Reporting (DAAR) program.

79. The audit Request For Information (RFI) asks for examples of abuse reports received by the registry operator – what type of reports do you expect to receive from registry operators?

    This question asks for abuse reports that were filed with or reported to the registry operator that suggest or allege abuse, regardless of report type. The type of reports will vary - for example, an email communication or a filed report via the registry abuse contact, a correspondence or any other form of reporting the registry receives. If the registry operator dismisses or does not retain information about certain types of reports/comments related to abuse, it should be indicated in the RFI response with an explanation regarding why so that ICANN can understand the approach.

80. Can registry operators ignore questions they feel are not applicable?

    ICANN will review responses in accordance with the specific contractual obligations. If there is a deficiency noted with a contractual obligation, ICANN will follow the process to ensure the deficiency is addressed. Where there is no contractual obligation, ICANN will inform the registry operator of the findings of the audit.

Back to Top