IRS e-file Security and Privacy Standards FAQs


Q.  Are these standards mainly for On-Line (as defined by IRS) providers?

A.  The requirement to register your Web site’s Uniform Resource Locator (URL), went into effect July 2007 and applies to all Authorized IRS e-file Providers. The other six (6) apply only to e-file Providers that actually participate in Online Filing of individual income tax returns.

Q.  The new standards are advisory (i.e., not mandatory) for the 2009 filing season. Will they become mandatory for the 2010 filing season?

A.  As of this date, no final determination has been made as to whether or not the new standards will become mandatory for the 2010 filing season.

Q.  The Extended Validation SSL certificate (EVSSL) would offer little additional security relative to the standard SSL certificate of equal encryption “strength.” In addition, EVSSL could limit the number of browsers e-file providers could support.

A.  We do not require EVSSL because of its encryption “strength” or because of the highly visible and informative way EVSSL-compatible browsers display EVSSL certificates. We require EVSSL because EVSSL is the only type of SSL certificate whose issuance is subject to a uniform and strict set of standards for authentication of the certificate applicant’s identity.

Q.  In the text of the requirement, you reference “… in accordance with PCI DSS.”  Can you please describe where the weekly requirement is listed?  When I reviewed 11.2 of the PCI DSS, it identified a quarterly requirement for scanning.

A.  PCIDSS 11.2 requires that the scans be performed “at least quarterly.” “At least quarterly” does not necessarily mean “quarterly.” Daily, weekly, and monthly all meet the definition of “at least quarterly.”

Q.  Defining “system components” as “any network component, server, or application that is included in or connected to the taxpayer data environment” and extending that to say “the taxpayer data environment is that part of the network that possesses taxpayer data or sensitive authentication data” isn’t clear to us.

A.  Our definitions of “system components” and “taxpayer data environment” are word-for-word out of PCI Data Security Standards except that we replaced “cardholder” with “taxpayer.”

Q.  Our monitoring tools are likely to detect the type of attack that CAPTCHA could prevent.  Rather than implement CAPTCHA, we would like to improve the tools we have.

A.  The requirement is for an effective challenge-response protocol to protect Web sites against malicious bots. CAPTCHA is mentioned only as an example.

Q.  Clarity is needed on the application of CAPTCHA.  Would it be acceptable to only implement this technology on account creation?  Or would the IRS require this technology to be used every time a taxpayer saves their data and e-files their return?
A.  The requirement is for an effective challenge-response protocol to protect websites against malicious bots. CAPTCHA is mentioned only as an example. The selected protocol must be implemented in such a way as to detect and prevent attempts at automated bulk submission of fraudulent tax returns.

Q.  Because there are many types of security incidents, many types of responses are required.  Taking a Web site offline would not be an appropriate response to a loss of taxpayer information in printed form, for example.

A.  There is no requirement for the Web site to be taken offline. If the Web site is the proximate cause of the incident, however, the Provider shall cease collecting taxpayer information via the compromised Web site until the underlying causes of the incident are successfully resolved. Clearly, the Web site cannot be the proximate cause of loss of taxpayer information in printed form.