Limitations on the Collection and Use of Social Security Numbers by Local Government Utilities

About the author

Kara Millonzi

View Other Posts

Share on Google+
Share on Reddit
Share on Tumblr

Back in 2008, the local government water utility adopted an Identity Theft Prevention (ITP) program to comply with the federal Red Flags Rule. Still awaiting final word from the Federal Trade Commission on whether or not the Red Flags Rule applies to local government utilities, Utility Jones has decided (with the consent of the utility’s governing board) to continue to implement the ITP program. Among other things, the program requires that utility employees verify the identity of any person that seeks to open a utility account by viewing two forms of identification—including at least one government-issued picture identification card. The program also requires that utility employees collect a prospective customer’s Social Security number (SSN). The utility uses the SSNs to conduct credit checks. The credit checks serve two purposes. The first is to provide an additional means to verify the identity of the person seeking to open the account. The second is to determine whether or not to require a deposit. (The utility only requires a deposit if a prospective customer’s credit score from one of the three consumer credit reporting agencies is below a certain threshold level.) The utility records the SSNs and also uses them to aid in collecting delinquent accounts. Specifically, it submits the SSNs of delinquent customers, along with other pertinent information, to the State’s set-off debt collection program to recover past due utility bills.

A new customer, Cautious Clay, attempts to establish a new account for water service. Conscientious employee that he is, Utility Jones follows the ITP program’s procedures to the letter and verbally requests that Ms. Clay produce the two forms of identification and her SSN. Ms. Clay agrees to show Utility Jones the appropriate identification, but she balks at having to give her SSN. Utility Jones informs Ms. Clay that she cannot open a utility account without providing her SSN. Ms. Clay, calmly yet firmly, informs Utility Jones that it is a violation of her federal rights to be made to produce her SSN. She claims that the utility’s ITP program is illegal and requests that she be allowed to open the account without disclosing the number. What should Utility Jones do?

Utility Jones should urge his governing board to modify its ITP program requirements immediately, at least as they relate to the collection of SSNs.

There are several provisions of state and federal law that govern the collection and use of SSNs by local governments, public authorities, and other public agencies. Collectively they impose restrictions on when and how a government entity may request a SSN, and for what purposes the number may be used. (It is important to note at the outset, that the federal Red Flags Rule neither mandates, nor expressly authorizes, the collection of SSNs in connection with a local government utility’s ITP program. A utility is free to incorporate the collection of SSNs in its ITP program, but it must do so in accordance with the requirements set forth below.)

Can a local government utility request a SSN?

G.S. 132-1.10(b)(1) prohibits a local government or public authority from collecting a SSN from an individual “unless authorized by law to do so” or “unless the collection of the social security number is otherwise imperative for the performance of that agency’s duties and responsibilities as prescribed by law.” If a specific federal or state law does not authorize the collection of the SSNs, the government entity must clearly document (likely in writing) that collection of this information is “imperative” for the performance of its duties and responsibilities.

Local government utilities typically wish to collect SSNs for two purposes. The first is to perform credit checks on potential customers and the second is to aid in debt collection.

There is clear state law authority to collect SSNs for the latter purpose, at least with respect to using the numbers to participate in the State’s set-off debt collection program. Specifically, G.S. 105A-3(c) provides that “[a]ll claimant agencies shall whenever possible obtain the full name, social security number, address, and any other identifying information . . . from any person for whom the agencies provide any service or transact any business and who the claimant agencies can foresee may become a debtor . . . .”

There does not appear to be any state or federal statute that expressly authorizes the collection of SSNs to perform credit checks on prospective utility customers. The federal Fair Credit Reporting Act (15 U.S.C. § 1681 et seq.) authorizes a consumer reporting agency to disclose a consumer credit report to any government entity that has a legitimate business need for the information “in connection with a business transaction that is initiated by the consumer.” 15 U.S.C. § 1681b. The statute does not reference the collection of SSNs in connection with the disclosure. As a practical matter, however, in order to obtain a consumer credit report from the consumer credit companies, a local government utility typically must furnish a prospective customer’s SSN. In order to collect the SSN for the purpose of performing a credit check, a local government utility must rely on the second criteria specified in G.S. 132-1.10(b)(1)—that the collection is “imperative” for the performance of the utility’s duties and responsibilities. Although the statute appears to set a high bar, it is at least arguable that conducting credit checks is necessary for the effective operations of a local government utility. (To date, there is no case law addressing this issue.) If a utility relies on this statutory provision to collect SSNs, at a minimum it must document in writing both the need to conduct the credit check on potential customers and the need to collect the SSNs in order to conduct the credit check.

Note that a utility likely is not authorized to collect a SSN solely for the purpose of using it as a unique identifier for each customer. There is no state or federal law that authorizes the collection of SSNs for this purpose, and it likely is not “imperative” to a utility’s operations. Although it may take extra effort and expense, a utility is capable of creating a unique identifier for each customer without using SSNs.

Can a local government utility require a SSN?

So, at least under certain circumstances, a local government utility may request that a utility customer or potential utility customer furnish his SSN. May, however, the utility require that the customer provide the number in order to receive utility services?

The answer is no. Under almost identical provisions of the Federal Privacy Act, 5 U.S.C. § 522a (note), and the State Privacy Act, G.S. 143-64.60, a government entity may not “deny to any individual any right, benefit, or privilege provided by law because of such individual’s refusal to disclose his social security account number.” Although no court has addressed the issue directly, it is likely that local government utility services constitute benefits or privileges provided by law. There are two exceptions to this general prohibition. The first is if the disclosure is expressly required or permitted by federal statute, and the second is if the disclosure is made to a government entity that maintains a system of records that was in existence before January 1, 1975, and that required disclosure by statute or regulation adopted before that date. Neither of these exceptions likely applies to the collection of SSNs by North Carolina local government utilities. What that means is that although a local government utility may request that a customer or potential customer disclose his SSN (for the purposes described above), the utility may not deny service to that customer if he refuses. (Note that there is some disagreement over whether the Federal Privacy Act provisions apply to local governments. Compare Schmitt v. City of Detroit, 395 F.3d 327 (6th Cir. 2005) with Ingerman v. Delaware River Port Authority, 630 F.Supp.2d 426 (D.N.J. 2009). This dispute is irrelevant in North Carolina because it is clear that the State Privacy Act applies to local governments.)

Questions often arise about the scope of this limitation. May a utility, for example, refuse service to a prospective customer if the utility is unable to obtain a credit report for that person for lack of a SSN? The answer to this question is not entirely clear. Arguably the utility is denying service because of the failure to obtain the credit report not because of the refusal to provide the SSN. But a court very well might hold that the utility is effectively denying service in this circumstance because of the customer’s refusal to disclose the number.

What if instead of denying service, the utility makes it more expensive to procure the service if a customer refuses to divulge her social security number? May a utility automatically charge a deposit fee or a higher deposit fee to a customer who does not provide her SSN? Again, the answer to this question is not entirely clear, but making access to utility services more costly to a customer who refuses to provide a SSN does not deny the customer access to the utility service per se. If the deposit fee is set too high, though, such a policy might be open to a claim by an individual that she effectively is denied services because of inability to pay the deposit fee.

How must a local government utility request a SSN?

There are certain procedural requirements that a local government utility must follow when requesting that a customer disclose a SSN. It must inform the customer that disclosure is voluntary. It also must indicate by what authority it is authorized to solicit the number and list all the potential uses that may be made of the number. See G.S. 143-64.60; 5 U.S.C. § 522a (note); see also G.S. 132-1.10(b)(3) (requiring that a statement of purpose or purposes for which the social security number is being collected and used by provided, upon request, at or before the time of collection). The utility must provide enough information about the potential consequences of divulging the SSN to allow an individual to make a reasoned choice as to disclosure. And, the utility may not use the SSN for any other purposes other than those specifically stated at the time the number was solicited. See, e.g., G.S. 132-1.10(b)(4). A utility should post this disclosure information in the utility office, display it on its webpage and/or print it on the form that requests the SSN.

What if a local government utility obtains a customer’s SSN from another source, such as from a private information broker? The procedural requirements (and the limitations on collecting SSNs described above) do not apply when a local government utility purchases SSNs or obtains them from another source. They only apply when a utility solicits the number directly from the customer.


So, what modifications should Utility Jones suggest his governing board make to its ITP program? First, the utility should make sure that it is soliciting SSNs from customers only for permissible purposes. The utility clearly may collect a customer’s SSN in order to submit any future delinquent accounts to the State’s set-off debt collection program. And, at least arguably, the utility may collect the number in order to conduct a credit check to determine the appropriate deposit amount. The utility may not refuse service to a potential customer who refuses to disclose his SSN, but it likely may impose a deposit fee or a higher deposit fee as a consequence of failing to provide this information.

[Note that if a local government utility collects (or purchases) a SSN, there are a number of statutory provisions that govern its retention and limit its dissemination. See, e.g., 5 U.S.C. § 522a (note); 42 U.S.C. § 405(c)(2)(C); G.S. 143-64.60; G.S. 132-1.10(b) and (c). These will be the subject of a future post…]

Leave a Comment

NOTE - You can use these HTML tags and attributes:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

Time limit is exhausted. Please reload the CAPTCHA.