Posts

Understanding the Audit Types for Debt Collectors and Collection Agencies

A closer look at how SOC 1, SOC 2, PCI and FISMA applies to Debt Collection and what it means for your Collection Agency.

If you’re performing collections, you’re no stranger to regulatory compliance and the proactive supervision of government agencies such as the Federal Trade Commission (FTC), Consumer Financial Protection Bureau (CFPB), and the Office for Civil Rights (OCR). It’s also critical to consider how you’re protecting consumer data and understand what information security audits are available and will best fit your organization based on the type of debt you’re collecting. Engaging an independent third-party to perform one of these many audits is not necessarily a requirement for collecting debt, but is highly recommended to ensure that the controls you have in place to protect sensitive data are appropriate and operating effectively.

What are the most commonly requested audits? Which audit is right for me? How can I prepare? Whether you’re collecting credit card, medical, student loan, or commercial debt, familiarizing yourself with the Alphabet Soup of information security audits – SOC 1, SOC 2, HITRUST, PCI, and FISMA – is the best way to begin making sense of the commonly requested frameworks and understand which one is right for you.

  • Credit Card Debt
  • SSAE 18/SOC 1
  • SOC 2/HITRUST
  • PCI
  • FISMA
  • Credit Card Debt
  • X
  • X
  • X
  • FISMA
  • Healthcare Debt
  • X
  • X
  • PCI
  • FISMA
  • Student Loan Debt
  • X
  • X
  • PCI
  • X
  • Commercial Debt
  • X
  • X
  • PCI
  • FISMA

SOC 1

An SSAE 18 (formerly SSAE 16), or SOC 1, or Statement on Standards for Attestation Engagements No. 18, is the most commonly used framework for U.S. service providers. SSAE 18 reports were primarily designed to report on the controls of a service organization that are relevant to their client’s financial reporting. SSAE 18 engagements are performed solely by CPA’s and intended to aid service organizations in eliminating potential errors to protecting client data and attest to the effectiveness of the controls. There are two types of SSAE 18 (SOC 1) reports, a Type I and a Type II. Similar in the presentation of each control objective, a Type I attests to the controls as of a specific date in time, whereas a Type II attests to the controls through a specified period of time, offering a description of the tests performed for each control and the results of the tests.

If you’re working directly with a bank, have a client specifically requesting an SSAE 18, or are simply looking for a good place to start, I recommend pursuing an SSAE 18 audit. This could apply if you’re collecting on credit card, medical, student loan, or commercial debt. The SSAE 18, as many audit types do, utilizes a risk-based approach allowing you to identify your areas of risk and determine whether you’re appropriately addressing each risk. The SSAE 18 audit process helps you to design and implement internal control, thus demonstrating commitment to integrity and ethical values through policy and procedure.

SOC 2

I recommend selecting a SOC 2 audit if your client demands it, prospective clients are requesting, or if you’re specifically collecting on healthcare accounts. A SOC 2 audit, unlike a SOC 1, is prepared in accordance with AT 101, Attest Engagements. Similar to a SOC 1, SOC 2 engagements are performed by a licensed CPA. A SOC 2 reports on non-financial controls, focusing on what are known as the Trust Services Principles; Security, Availability, Processing Integrity, Confidentiality, and Privacy. Is the system protected against unauthorized access (logical and physical)? Is the system available for operation and use as agreed? Is the system processing complete, accurate, timely, and authorized? Is the information designated as confidential protected as agreed? Is personal information that is collected, used, retained, disclosed, and destroyed in conformity with the entity’s privacy notice commitments? This is what is addressed during a SOC 2 audit engagement.

A recommended practice for those working closely with the healthcare industry is undergoing a SOC 2 HITRUST audit. Pairing a SOC 2 with a HITRUST CSF (common security framework) component can help take the guesswork out of HIPAA compliance assessments. The HITRUST framework is a healthcare industry-created compliance protocol designed to address compliance and risk expectations of HIPAA’s Security Rule, variations in business practices, and third-party assurance expectations. Since the SOC 2 is designed to address the aforementioned Trust Services Principles, which are all concepts intrinsic within HIPAA’s Security Rule requirements and the HITRUST framework, it is an incredibly effective report that will provide internal and external value to your organization.

PCI

The Payment Card Industry Data Security Standard (PCI DSS) was jointly developed by the payment card brands to encourage and enhance cardholder data security and to facilitate the broad adoption of consistent data security measures globally. PCI DSS v3.2 is the current version, and applies to any merchant who stores, processes, or transmits cardholder data, and any service provider who stores, processes, or transmits data on behalf of a merchant. As a debt collection agency, you can be either a merchant or a service provider. You’re considered a merchant if you’re accepting credit cards as payment, and a service provider if you’re loading account numbers into your system to collect on. PCI DSS is a robust information security standard with approximately 394 controls, 12 Requirements, organized under six Control Objectives.

If you’re collecting on credit card debt, or accepting or processing payment cards, you must comply with PCI. You may become “PCI Compliant” by completing a Self-Assessment Questionnaire (SAQ). There are nine basic versions (with variations), and can either be signed by a Qualified Security Assessor (QSA) or can be a self-attestation. You may also become “PCI Certified”, and upon completion will receive an official Report on Compliance (RoC) from a QSA.

FISMA

The Federal Information Security Management Act (FISMA) is a U.S. federal law, enacted in 2002, to protect government information and assets from unauthorized access, use, disclosure, disruption, modification, or destruction of information and information systems to protect the three pillars of information security; Confidentiality, Integrity, and Availability. FISMA is the law; NIST Special Publication 800-53 is the comprehensive standard that contains the individual security controls required to comply with FISMA. Certification is achieved when an Authorization to Operate (ATO) is signed by a federal agency’s senior management official.

If you’re collecting on student loan debt, working with the federal government, a federal contractor, or a sub-service provider of a federal contractor, you are required to meet the National Institute of Standards and Technology (NIST) 800-53 standards.

There’s not a cookie cutter approach to determining which information security audit is right for you. The important things to consider are best practice recommendations, who these audit frameworks apply to, and the type of debt you’re collecting. Whether you choose to undergo an information security audit or not, the best place to start is making sense of the alphabet soup.

Making Sense of the Regulatory Alphabet Soup

SSAE 16, SOC 2, HIPAA, PCI DSS, FISMA, ISO 27001. We’ve all heard of the Alphabet Soup, but what do they all really mean?

Which one is right for me? Which one should I pursue? Why would I get this audit over that audit? As auditors, these are the questions we are most frequently asked.

To help answer these questions and truly familiarize you with the different audit frameworks, we’ve broken down the Who’s, What’s, and Why’s for the most commonly reported on frameworks.

SSAE 16/SOC 1

Who asks for an SSAE 16? If you work with publicly traded companies, financial institutions, or state or local government, you will frequently be required to have an SSAE 16 audit performed by a third party. It is the most commonly used form of attestation for service providers in the US. So what is an SSAE 16? It’s an audit and report on internal controls (whether related to information security, financial, operational, or compliance controls) at a service provider that are relevant to their client’s data. The SSAE 16 audit takes a risk-based approach, with specified objectives that are created to address client risk, and controls, or activities, to accomplish each objective. A third-party auditor would be looking at your environment to make sure your objectives are appropriate, your controls are effectively designed, and that you are doing what you say you are doing. An SSAE 16 audit is as good as its scope.

SOC 2

Typically, the same clients who are asking you for an SSAE 16 will be the ones asking you for a SOC 2. Whereas SOC 1 was designed to validate internal controls at a service provider that relate to client financial reporting and validate information security, SOC 2 was a framework specifically designed for companies delivering technology related services. The SOC 2 framework is finally gaining popularity. SOC 2 was specifically designed to report on one of five principles: Security, Availability, Confidentiality, Processing Integrity, and Privacy. The established criteria for each principle address the following questions: How are your policies and procedures relative to the standard documented? How do you communicate those to all interested parties? How do you monitor that those controls are being effectively performed?

HIPAA

If you are working for a healthcare provider or a Business Associate who services a healthcare provider, you are going to be asked for validation of your compliance with HIPAA laws. Any entity who handles Protected Health Information (PHI) will be responsible for compliance with HIPAA. Legislation requires appropriate Physical, Administrative, and Technical Safeguards to protect PHI. Much like the SSAE 16, HIPAA compliance is risk-based. You must begin by performing a Risk Assessment to determine what the appropriate physical, administrative, and technical safeguards are, implement those, and then perform regular monitoring to ensure the safeguards are still appropriate. There is no “hard list” of requirements for HIPAA, and there is no certification. A third-party audit would provide validation of your controls and their appropriateness and effectiveness.

PCI

The PCI Data Security Standard applies primarily to the payment card industry. If you store, transmit, or process cardholder data, you will be required to comply with PCI DSS. Additionally, if you have a client who is required to comply with PCI DSS, they are required to validate your compliance with the standard as well. PCI DSS is a very robust information security standard, and is also sometimes used as a best practice, even without handling credit card data. A PCI audit is an information security audit focused on the protection of credit card data. All PCI audits are performed by a PCI Qualified Security Assessor (QSA). There are over 200 controls and 1,000 audit tests that make up the framework and process. There are six control objectives with 12 subject areas. When a third-party auditor performs a PCI audit, it results in a PCI Report on Compliance (ROC).

FISMA

FISMA Compliance is required of anyone working with the federal government, a federal contractor, or a sub-service provider of a federal contractor. FISMA is the law. NIST Special Publication 800-53 is the actual standard that lists the individual security controls required to comply with FISMA. A FISMA audit is a thorough assessment of your information security practices as it relates to NIST SP 800-53 requirements. It involves a detailed risk assessment, and a selection of comprehensive controls determined by whether you are a low, moderate, or high category. Out of the frameworks we’ve covered so far, FISMA is the most extensive.

ISO 27001-27002

If your customers are doing business globally, chances are you’ll be asked for an ISO 27001 audit. It is a very mature, holistic, information security standard that is widely recognized and highly revered on an international level. 27001 is the entire standard, and 27002 refers to just the controls. An ISO 27001 audit is a complete audit of your Information Security Management System (ISMS). This includes management system, risk management, internal audit, management review, continual improvement, and information security controls.

Determining which audit framework is the best for your organization depends on a number of things; who your clients are, who your clients’ clients are, and what kind of information you process. For more information on a specific framework, or if you are interested in speaking with an Information Security Specialist for a consultation, contact us today.

2014: The Year of Updating Frameworks

As the world continues to be pressured with information security challenges, over the last 12 months, major compliance frameworks have recently been updated or are currently updating. In today’s current climate, incidents and breaches are occurring more frequently, and at a much larger scale. With this in mind, many entities have realized these threats and are beginning to closely analyze the gaps in the current frameworks (HIPAA, ISO 27001:2013, FISMA/NIST 800-53, PCI DSS v3.0). Our number one business goal is to protect any critical assets, so it’s important to understand all of these changes and the impact they have on your organization. The most notable updates have been to the HIPAA, ISO 27001, FISMA, and PCI DSS frameworks.

Why should these updates be important to you? Let’s face it – it’s the new reality. Almost every industry is having the “compliance discussion”. Security threats aren’t just for big companies anymore, and the fines and loss of business can be an unfortunate impact of not being compliant.

HIPAA

Let’s begin with the healthcare industry. The HIPAA law strives to address the protection of patient information. We want to keep information private. That is what we are most after. The Security Rule enables privacy by establishing the approach of how to protect information so privacy can be obtained. Last September, the Omnibus Rule became effective to strengthen the Business Associate requirement. All covered entities are now required to ensure that their Business Associates are HIPAA compliant, and these BA’s can now be held directly responsible by the Department of Health and Human Services for their compliance. Where do you begin in assessing your vendors? Conduct a risk assessment of all vendors and determine which are the most at risk and monitor accordingly.

ISO 27001

ISO 27001 can be considered the grandfather of all information security frameworks. Most new publications reference ISO 27001 as a starting point, as this framework is internationally recognized and applicable. The ISO 27001:2013 update provides specific requirements for establishing, implementing, maintaining, and continually improving an information security management system. Your information security management process must be a system that is continually operating and improving based on changing risks. The core change is not revolution, but rather evolution. The standard has been reorganized and more harmonized and has made risk assessment focus a key change to the standard. Requirements for management commitment and preventative action have also be revised, with a greater emphasis on setting the objectives, monitoring performance, and metrics.

FISMA

The FISMA Act is a set of guidelines for selecting and specifying security controls for information systems that process, store, or transmit Federal information. The Act references that NIST publishes Special Publications as important updates that should be referred to. NIST 800-53 is specifically pointed towards as a reference for how to select controls and what it is that you need to implement for your systems. NIST 800-53 expects the important element of risk assessment to determine which controls apply, to what degree they should be applied, and what areas specifically should be considered.

PCI DSS

The payment card industry is probably what we’ve been hearing the most about. With all of the current breaches targeting retailers and service providers, the council has sought out to address the causes of these breaches and strengthen the industry. The Payment Card Industry Data Security Standard (PCI DSS) was developed to encourage and enhance cardholder data security and facilitate the broad adoption of consistent data security measures globally. PCI DSS v3.0 is an update to the security standard, and is available for implementation this year. Compliance with v2.0 is still an option only through January 2015. There were three major updates to the PCI DSS. There is a new Penetration Testing requirement that states an implemented penetration testing plan should be in place to verify that controls are operational and effective. Service Provider responsibilities have also been updated. Since security is a shared responsibility, service providers are now required to include written vendor acknowledgement for each DSS requirement for which they’re responsible. The last major change in PCI DSS v3.0 is in regards to password requirements and the enhanced awareness to ensure password security.

It’s important to ask yourself, which of these frameworks apply to me? Which apply to my vendors? Performing a Risk Assessment can help you determine what is important to you and your organization, allowing you to assess from there. Security is no longer passive. Technology is evolving quickly, along with techniques used by hackers. As the compliance frameworks continue to update, it’s important to understand that security must now be active and always evolving.