FTC Red Flags Rules: How to create an identity theft prevention plan

As of this week, the FTC has begun enforcing the Red Flags Rules, which mandate that certain businesses create and maintain a written identity theft prevention plan. But what does an identity theft prevention plan look like, and which businesses are required to write one? This is where things can get tricky. In this tip, we'll discuss which companies must comply with the Red Flags Rules and how to craft an identity theft prevention plan that will ensure compliance.

Who is required to comply?
Businesses defined as "financial institutions" or "creditors" -- a broad group that includes banks of all sizes, most brokerage firms, credit card companies, mortgage lenders and even non-traditional lenders like utilities, car dealerships and healthcare providers -- need to be compliant with the Red Flags Rules.

For those organizations, a written plan is needed only by those who have "covered accounts," which fall into two areas. The first is pretty straightforward: accounts that are consumer-oriented and used for regular, ongoing transactions. This includes credit cards, mortgages, utilities and cell phone accounts. The second area of accounts is a little vague; defined as: "one for which there is a foreseeable risk of identity theft." So if you have non-consumer accounts, you'll have to do some research -- and a risk analysis -- to determine which accounts fall into this category. Examples suggested by the FTC include small-business accounts and sole proprietor accounts.

However, those "financial institutions" without covered accounts need to periodically review their records to make sure they haven't added any accounts that would be defined as covered accounts. So even if your company isn't bound to comply today, it may be forced to do so in the future as the business evolves.

Crafting an identity theft prevention plan
...

1. Identification: The plan needs to provide a process to identify patterns, activities or transactions (i.e. red flags, hence the name) that appear to be leading to identity theft.
2. Detection: The plan needs to specifically call out processes and procedures that will be used to detect the previously defined red flags.
3. Response: The plan needs to include a process of responding to red flags as they are detected.
4. Revision: The plan should specify the process the organization will use to periodically update sections 1-3 as the threat landscape changes.

If you have outsourced or are planning to outsource covered data or processes, then the plan must cover how your organization will ensure that the company you are outsourcing to will be compliant. In other words, outsourcing does not remove responsibility for protecting the data, so it is imperative to seriously investigate the security abilities of any existing or potential outsourcers.

The FTC has mandated that each company's board of directors (or a senior-level employee if there is no board) approve the initial plan, as well as that all appropriate employees (i.e. those that handle sensitive data) be trained properly about the legislation and how to handle data properly and safely.

The FTC has also provided some guidance for how to determine what Red Flags are, and, in doing so, has identified five main categories that an organization's Red Flags might fall under. They are:

• Alerts, notifications, or warnings from a consumer reporting agency.
• Suspicious documents.
• Suspicious personally identifying information (PII).
• Suspicious activity relating to a covered account.
• Notices from customers, victims of identity theft, law enforcement authorities, or other entities about possible identity theft in connection with covered accounts.

The category "suspicious activities" covers a range of options that will depend heavily on your business, but could be as simple as a change in buying patterns in a specific location, frequency of purchases or oddly high or low purchase values. Keep in mind that what is relevant for your organization might only fit into some or perhaps none of these categories, and that the categories are merely guidelines to help your organization define its compliance processes.

Finally, the really big question is: What happens if my organization is not compliant? There's no audit process for Red Flags, so the only way a company is going to be found non-compliant is if it is investigated by the FTC. However, don't let the relatively low odds of such an investigation stop you from complying. Should the FTC investigate and determine your organization is non-compliant, it will work with the Department of Justice to sue. Currently there is a maximum fine of $3,500 per covered account violation; there can also be violations which are not covered-account specific, and in some cases there can even be multiple violations within a single covered account. This can add up to a whole lot of cash once you start counting how many covered accounts your company may have control over. Additionally, the courts can mandate further compliance efforts if your company is found non-compliant, such as supplementary reports, document retention and mandatory audits, all of which will incur additional soft costs. To sum up, the FTC won't be actively auditing organizations, but it will be investigating on the basis of reported issues, and the costs of being found non-compliant can be staggering.

The FTC has stated that it will pursue investigations vigorously, and that it will not go easy on those organizations that are found to be non-compliant. Therefore, compliance with this rule should be a relatively high priority issue for affected organizations. The nice thing is that more mature organizations likely have most, if not all, of this in place already, so compliance will be more of a documentation exercise than an implementation exercise. Less mature organizations would be wise to roll up the FTC efforts into their other compliance programs, since this would be well suited to a SOX or GLBA program as well.

About the author:
As CSO-in-Residence, David Mortman is responsible for Echelon One's research and analysis program. Formerly the Chief Information Security Officer for Siebel Systems, Inc., David and his team were responsible for Siebel's worldwide IT security infrastructure, both internal and external. He also worked closely with Siebel's product groups and the company's physical security team and led up Siebel's product security and privacy efforts. A CISSP, Mr. Mortman sits on a variety of advisory boards including Qualys and Applied Identity and Reflective, amongst others. He holds a BS in Chemistry from the University of Chicago.