Archives for August 2014

Todd Langusch
TECH LOCK

This is the first of a three-post series from Todd Langusch at TECH LOCK.

Those who operate in the ARM industry must nowadays operate under the watchful eye of various government agencies, from the Federal Trade Commission (FTC) to the Department of Health & Human Services (HHS) to the Consumer Financial Protection Bureau (CFPB), just to name a few. In addition, several States have signed into law new legislation with new requirements for collections and the protection of consumer data. Lastly, there are several industry standards that clients (banks, creditors, debt buyers, etc.) request of companies – some of the more common ones are the ISO 27000 series, PCI DSS, SSAE 16, SOC 2, and HITRUST.

Our highly-regulated industry is replete with acronyms and regulations. Over the past year, many organizations have been setting up a Compliance Management System (“CMS”) to meet client requirements and to prevent costly lawsuits and fines. A CMS has certainly been a key initiative for collection agencies, but contrary to what some vendors may say a CMS is not an out-of-the-box solution; it is, instead, a comprehensive system made up of discrete parts that must be tailored to an organization’s processes. The intention behind a CMS is to ensure that agencies are operating within the letter and spirit of the law, and that consumers’ rights are protected throughout all of their interactions with the collection agency.

Collection agencies and debt buyers are subject to many regulations and requirements, and frequently obtain an independent third party audit report to provide evidence of their CMS or parts of it. One part that is frequently audited is the protection of consumer information (data security). Given all of the acronyms, requirements, and types of audits out there which one should a company choose? The first question a business owner or leader should ask is, “Why am I being audited in the first place? Is it to fulfill a client requirement, is it to sleep better at night knowing there are proper controls in place, or is it to ensure my company is compliant with all applicable laws, regulations and client contractual requirements?”

I would like to share with you my opinion based off of my years sitting in your seat as well as from an auditor perspective.  After reviewing over 800 companies in the ARM Industry as an auditor and as CIO of a large debt buyer evaluating our service providers (agencies, law firms, and other vendors) I have seen quite a bit of misunderstanding of audit types, wasted monies, and high risk. Let’s start with the biggest misunderstanding of them all first, SSAE 16:

1) SSAE 16 or SOC 1

Below are three key items I wish to pass along with a reference link back to the frequently asked questions the American Institute of Certified Public Accountants (AICPA) released.

1. Your organization cannot get “certified” SSAE 16. No such certification exists and nor did one exist for SAS 70.  Organizations frequently marketed they were SAS 70 certified and even now SSAE 16 certified. Please refer to FAQ #7 that starts on the bottom of page 4 located here which clears up this misconception.
2. The SSAE 16 is not specifically built to examine an organization’s controls relevant to the security, availability, or processing integrity of a system or the confidentiality, or privacy of the information processed by the system. In short, if an organization is looking to meet a client data security requirement this is not the report to use! The first two pages of the FAQs walk through this and also specifically call this is in Q&A #11 located here.
3. As CIO of a large debt buyer, I would frequently see SAS 70 or SSAE 16 marketed to my organization from potential service providers and I would often see press releases or communications sent over regarding these audit reports, which was a clear sign to me that organization really did not know that these audit reports are meant to be restricted to management of the service organization, user entities that are customers of the service organization, and user auditors. These reports are not meant to be used for sales or marketing! This is also clearly communicated in FAQ #6 located here. 

In the end, it will take additional time for this misconception to filter itself out. Recently, I saw a few RFPs that required “SAS 70 certification,” and SAS 70 that has been retired since June 15, 2011. I understand organizations obtain SSAE 16 because it may show up in an RFP or they may be asked by the client, but organizations should open up a dialog with their clients to truly understand what it is they are really asking for. If it is the confidentially, integrity and availability of data then they really should obtain a different audit like a SOC 2 or PCI DSS. If their client only wants a report on internal control over financial reporting, then an SSAE 16 audit is appropriate.

Todd Langusch is the President & Chief Executive Officer of TECH LOCK, Inc. Todd has more than 25 years of privacy, data security and information technology experience, and has held more than 26 different information technology certifications. Join Todd at ARM-U, October 14-15 in Washington, DC, as he discusses the important ways in which operations and compliance overlap within a collection agency’s compliance management system (CMS). It’s just one of many panels you won’t want to miss!