accounting academy weekly ledger accounting academy weekly ledger

Get to Know a Fintech Expert — PCI and SOCs

Ralph Perdomo

The world of electronic payments is cloaked with many layers of security and compliance. Which is for the best; after all, those layers are in place to ensure payments are transmitted safely and securely.

Unfortunately, those same layers that protect your payments also make it difficult to make sense of what’s what when it comes to compliance.

Take for instance the alphabet soup of compliance: PCI DSS and SOC (Payment Card Industry Data Security Standard and System and Organization Controls, respectively). Only the most ardent payables professional would know the nuances of each and how they can relate. How PCI is a security standard for handling branded credit cards while SOC is used as guidance on auditing methodologies and not the actual control—a sort of yin to PCI’s yang.

interview with compliance director of nvoicepay on PCI DSS and SOC standards

To better understand the importance and benefits of adhering to these compliance and security standards requires the knowledge of a security expert.

For this, I interviewed Jeremiah Bennett, Director of Compliance at Nvoicepay. Bennett is directly responsible for making sure each and every one of our customers' invoice payments is sent securely—and he’s proud to report he’s done so for over six years.

 

Ralph:
Jeremiah, thank you for taking the time to speak with me today. I’m excited to learn more about the compliance and security surrounding electronic payments. I’d like to get started by defining some industry terms. What is PCI?

Jeremiah:
PCI was developed by the major credit card brands or payment card brandsmore generally—to mitigate fraud. It was a response to them realizing and resolving vulnerabilities.

For example, some vendors were charging incorrectly or maliciously. Or some people would take a card they knew to be issued to someone else and take it to some vendor and process the card to obtain goods or services even though they didn't actually pay for them. The charges would then be disputed by the customer or the card company themselves. The merchants or vendors would be stuck footing the bill.

Ralph:
Please correct me if I’m wrong, then—PCI as a standard secures credit card transactions and accounts, is that correct?

Jeremiah:
Yes. What PCI is doing is just putting together a set of standards to try to help prevent the breach of sensitive data. The sensitive data with PCI, specifically, is cardholder information, but you can swap out cardholder information for anything—bank account information or what have you.

Ralph:
Does that mean the PCI use case can be applied when dealing with other types of sensitive information?

Jeremiah:
Yes. Any kind of sensitive data that could potentially be breached by an unauthorized entity.

Ralph:
And that’s what Nvoicepay has done? It’s applied the PCI framework to all transactions—not just credit card ones?

Jeremiah:
Correct. You see, PCI as an abstraction is very scalable. And since we're storing vendor bank account information and performing transactions—really very similar to credit card payments—taking the PCI and wrapping it around other data is a sound approach to protecting sensitive information.

Ralph:
And how does SOCs reporting figure into the whole thing?

Jeremiah:
So, SOC 1 deals more around financial controls. It’s more around how you're dealing with money, like do you have proper controls in place. SOC 2 is more focused on security. There are a couple other, what they call, trust principles that are involved with SOC 2 as well but the security is the big one.

Ralph:
What’s on a SOC report, exactly? Is that something you can talk about?

Jeremiah:
A SOC report is written to say, ‘hey, we are a service provider and as a service provider, here's a description of the services that we provide.’ So within the details of the report, there’s an outline of the services provided.

In it, we’d say things like how we handle your instructions given a particular risk and how we would mitigate things to prevent a risk from ever being exploited.

Next we go through an assessment by process, saying: ‘Here's a set of evidence showing that we are conforming to these controls.’ We publish and an auditor reconciles the evidence, publishing their report saying something like: ‘it's our opinion that the service provider was fulfilling these control statements and was not fulfilling these control statements.’

Ralph:
Ok, so let me try to interpret this—at a 35,000 foot level, the SOC report outlines how we handle financial instructions, how we secure it, and how we handle threats? Is it succinct to say that a SOC report outlines expectations and capabilities?

Jeremiah:
Yes. And the SOC report further establishes what the burden is for the customers using the service. So, to say, ‘hey, here are the controls that we have in place in order to protect your system. But we expect while you use our system that you're doing these things as well.’

Ralph:
We're only as strong as our weakest link—

Jeremiah:
Right. So, don't share user accounts, make sure you're using strong encryption, things like that.

Ralph:
Does a SOC report go both ways? As in there’s a burden on the customer as much as the service provider?

Jeremiah:
Yeah, but it’s a little more nuanced than that. With SOC, we outline requirements based upon our system description. And not every company shares the same set of requirements. In fact, I doubt any two companies show the same set of requirements. There are different principles that they all have in common, but the actual specific control statements are going to vary.

Ralph:
It sounds like SOC carries a level of trust—our customers trust us to protect their financial data and we trust them to adhere to policy. But how does this trust and security and compliance work with our cloud provider?

Jeremiah:
Just like our customers exercise diligence in assuring that we, as a service provider, are meeting their needs, so too, do we do the same with our cloud providers. We ask for their SOC report so we can evaluate and determine that their controls are sufficient and that there aren't any exceptions in meeting those.

There is this trust, then, which allows us to further leverage controls.

Ralph:
Without disclosing too much of what we do, what are some of those leverage controls or tools used? Are you allowed to speak on that without compromising security?

Jeremiah:
Those various tools help to fulfill different security requirements that are common to a lot of different standards. So, whether it's adding a firewall in place, or having intrusion protection in place, or file integrity monitoring in place, our cloud provider allows us to leverage those tools and allows us to extend that capability down to our customer.

By leveraging those controls, we’re able to assure our customers’ needs are met with the highest level of security. Which all comes back down to inclusion items on the SOC report.

Ralph:
Jeremiah, what, then, have you come to learn about compliance and payments? What’s your take on it?

Jeremiah:
I've come to appreciate the job more because I realize that without the compliance, really, a lot of business wouldn't happen. We have a lot of customers that say, ‘we're not just gonna take you for your word that you're good. You need to demonstrate and show to us that we can trust you.’ And that’s what these compliance standards help—that’s the proof that we’ll do right by them.

 

Visibility. Control. Convenience. Here's how you can have it all with payment automation. [Read more]