What CX Leaders Need to Know About Security and Compliance

No items found.

Think about the last time you identified yourself over the phone to an agent—you probably handed over your name, address and birthday without a second thought. After all, a customer service interaction is one of the rare times where a customer (usually) feels safe enough to willingly hand over their personal identifiable information (PII) to another person. To get to this point, companies have invested countless hours and resources to build a high level of trust with their customers. 

With so much on the line, it’s essential that CX teams  put the right tools in place to ensure that their agents remain compliant with security protocols while safeguarding against a potential data breach. In this guide, we talk about the importance of security and compliance to CX teams, and how you can work with your Information Security (InfoSec) teams to ensure your vendors have the right security attestations and certifications.


Why is Security and Compliance Important to CX teams?

In short: data security is important to CX teams because customers don’t want to buy from brands with security issues.

The data speaks for itself; a 2018 study published by international security firm Gemalto (now a part of Thales) found that 70% of customers would stop doing business with a brand that had suffered from a data or privacy breach. Another study, conducted on behalf of IBM Security, found that cybersecurity and privacy was the second most important factor (after quality) in B2C purchasing decisions. 

For individual interactions, agents who aren’t familiar with security and compliance protocols, and fail to verify a customer’s identity or safeguard their personal information, are bound to receive more complaints, and lower CSAT ratings.

For brands who have invested so much in building up customer loyalty, it’s alarming to know that it could all be easily undone by a few moments of carelessness on the part of an agent or vendor.

What does this mean for CX teams?

CX teams need to ensure that their suite of tools have the right security attestations in place, and that their teams are given the right training and mechanisms to detect and prevent agent behavior that might result in a breach.

For their customers, security attestations (like SOC 2, HIPAA, or ISO27001) show customers a brand’s emphasis on data security, and helps customers choose the right organization to entrust their wealth, health, and personal information with.

And for CX leaders, these attestations are usually a prerequisite mandated by the company’s Chief Information Security Officer (CISO) or CTO. An organization’s security and compliance efforts are only as secure as their weakest link, so CISOs typically require vendors to match the same attestations as the company itself has attained. 

When in the market for tools like helpdesk software, chatbots, or quality assurance software, CX leaders should be able to quickly exclude vendors who do not meet the company’s (or the industry’s) security requirements. 


What Compliance and Security Attestations Should Your CX Tools Have?

There are two main categories of attestations: Information Security (InfoSec) risk management frameworks (like SOC 2 and ISO27001), and industry-specific attestations (like HIPAA and PCI).

When purchasing CX tools, you should require your vendors to have attestations in at least one InfoSec risk management framework (SOC 2 or ISO27001, depending on your location), and, depending on your industry, these tools should also meet the industry-specific attestations that your CISO/InfoSec team has mandated.

Information Security Risk Management Frameworks:

SOC 2

SOC 2 compliance is a part of the American Institute of CPAs’ Service Organization Control reporting platform, and is widely recognized and accepted by CISOs as the standard for organizations that work with 3rd party vendors

Building on the idea that your security protocols are only as strong as your weakest link, SOC 2 attestation covers a wide range of criteria, including risk management, HR operations, engineering, local and physical access controls, incident management, and change management. Such widespread coverage eliminates any weak links in the organization’s security strategy. 

But not all SOC 2 certifications are equal. 

SOC 2 encompasses five different trust services criteria. These are: Security, Confidentiality, Privacy, Availability and Processing Integrity. SOC 2 certification requires teams to be compliant with at least the “Security” criteria—and that’s where most CX tools stop. MaestroQA has gone beyond the requirements of a basic SOC 2 certification to add “Confidentiality” and “Privacy” criteria to our own SOC 2 certification to ensure your customers’ data is protected and kept secure.

CX leaders should also be aware of the two different types of SOC 2 attestation, aptly named SOC 2 Type 1, and SOC 2 Type 2. Type 1 is a point-in-time audit, meaning that the controls are being tested only at a single point in time. Type 2 requires testing over a defined period, usually 6-12 months, and ensures that the organization has met and maintained the standards over the entire test period and the controls are operating effectively over the period.

Naturally, SOC 2 Type 2 is much more secure and difficult to achieve than Type 1, and should be every CX leader’s first requirement when selecting a pool of vendors for consideration.

ISO27001

ISO27001 is comparable to the standards set forth by SOC 2, but enjoys more international recognition. While SOC 2 audits were designed specifically for service organizations, ISO27001 is applicable to any organization of any size or industry. 

There’s one last difference: there are fixed, international standards for ISO27001, while organizations applying for SOC 2 certification are allowed to define their own controls relevant to pre-defined criteria, which a certified auditor must then approve and attest that they’ve met.

Both ISO27001 and SOC 2 Type 2 attestations provide similar levels of comfort (InfoSec speak for security) to CX teams—rope your CISO, InfoSec or Procurement teams into the buying process when selecting CX tools to ensure the vendors are compliant with either attestation.

Industry-specific attestations:

Common examples of industry-specific attestations are HIPAA (protecting patient health information or PHI), and PCI (protecting payment card information).

The good news: if you haven’t heard of any of these, or aren’t already aware of any industry-specific attestations that your CX team requires, your industry probably doesn’t require any. On the other hand, if the alphabet soup above made sense to you, you should be requiring all of your CX tools to have the same level of compliance or attestation. 

The principle here is simple: if the tool is going to be processing, handling, or storing protected customer information, that tool needs to have the appropriate level of compliance as required by your industry. There are 5 simple steps you should follow to evaluate the security attestations of vendors.


5 Steps to Take To Evaluate the Security Attestations of CX Vendors

1. Involve your CISO/InfoSec Team Early in the Buying Process

Checking in with your CISO or InfoSec team about the necessary compliance attestations can help you whittle your vendor options down. That way, you don’t waste time assessing vendors who would not have made the cut anyway. 

These days, ISO27001 or a SOC 2 Type 2 attestation are the minimum requirements for any CX team, while other teams might require a HIPAA or PCI attestation depending on industry. Vendors who don’t meet the requirements or have no plans to complete these attestations in the near future can be easily excluded from your search.


2. Ask Prospective Vendors to Complete a Security Questionnaire

Consider what information your organization will be sharing with your vendor (e.g. customer personal information, QA scorecards, or customer support tickets). Work with your InfoSec team to produce a security questionnaire for prospective vendors to pass.

SecurityScorecard has a vendor risk management template that should help you and your team to get started. Questionnaires like these are extremely common in the SaaS sales cycle, and potential vendors should have no trouble completing (and passing!) a security questionnaire during the sales process.


3. Understand the Differences in the Attestation Levels for SOC 2 Compliance

In North America, most CX vendors have a basic SOC 2 Type 1 attestation—which only requires them to pass the audit at a single point in time. A SOC 2 Type 2 attestation is much harder to attain, and requires vendors to pass long term audits over the span of 6-12 months, and to then maintain their compliance annually. Having a SOC 2 Type 2 attestation is an indicator of a vendor that has invested the time and resources to ensure that their systems protect the privacy and security of their (and your) customers.


4. Look Out for “Exceptions” in Audit Reports

Remember the “Security” criteria that forms the basis of every SOC 2 audit? There are 9 other “common criteria” that fall under the umbrella of “Security”—and not every vendor passes each one. It’s like passing your driving test with just a point to spare—everyone you offer a ride to would probably feel safer if you took (and passed) the test again.

Be sure to ask about exceptions in your security questionnaire, and ask your InfoSec team if missing any of these “common criteria” could be a factor for disqualification.


5. Look Out For The Auditor’s Opinion in SOC 2 Reports

Every SOC report comes with an opinion attached—and the information within can be very telling.

A disclaimer opinion typically means that the auditor could not issue an opinion because they were limited by the service organization (or the vendor, from your perspective) in the information that they provided or the procedures performed.

An adverse opinion is the most severe an auditor can issue, and indicates that the auditors, and thus, the users of the SOC report should not, and can not place any reliance on the service organization’s/vendor’s system.

A qualified opinion is a caveat that the auditor issues to indicate that the controls were either not designed (for SOC 2 Type 1) or operating effectively (for SOC 2 Type 2). A qualified report indicates that the issues identified within the report were significant enough to deem one or more controls ineffective. Your InfoSec team would be able to determine if the ineffective control is enough to disqualify a vendor.

An unqualified opinion is the best case scenario, and indicates that the controls tested were designed (for SOC 2 Type 1) and operating effectively (for SOC 2 Type 2). An unqualified report doesn’t necessarily mean no issues or exceptions (see the previous section on qualified opinions) were identified. Rather, it means that any issues the auditors uncovered were remediated/mitigated by the vendor/service organization, and the overall impact on the report was deemed effective despite these issues.


Have More Questions About CX Security and Compliance? We’re Here to Help

Want to learn more about cybersecurity and compliance on CX teams? 


Request a demo of the industry’s most secure quality assurance platform. Learn more about the controls and criteria we’ve put in place to protect your customers' privacy, and how using best-in-class quality assurance software can help build the right compliance behaviors in your CX team.

Related articles
Navigating AI Implementation Strategy in Customer Experience: Risks and Strategies
April 15, 2024
Read More
Elevating Call Center Performance with Six Sigma and MaestroQA
April 19, 2024
Read More
Elevating Business Excellence Through Non-Customer-Facing QA: A Strategic Imperative
March 28, 2024
Read More
Navigating AI Implementation Strategy in Customer Experience: Risks and Strategies
April 15, 2024
Read More
Elevating Call Center Performance with Six Sigma and MaestroQA
April 19, 2024
Read More
Elevating Business Excellence Through Non-Customer-Facing QA: A Strategic Imperative
March 28, 2024
Read More
Elevating Trust and Safety through QA: How TaskRabbit Sets the Standard
April 4, 2024
Read More