PCI DSS vs SOC 2: Which Do You Need?

With so many different security frameworks and standards that apply to different industries and businesses, it can be difficult to even know where to begin. Which ones do you need to use, at what levels, and when?

Two frameworks in particular are closely related and important for many businesses, and thus are the cause of a lot of confusion. We wanted to address that confusion today. Those two are PCI DSS and SOC 2.

What is PCI DSS?

PCI DSS is the Payment Card Industry Data Security Standard, which is a set of interlocking standards managed by the Payment Card Industry Security Standards Council. The council is composed of members from the five major credit card networks, with the aim of setting and standardizing the security and trust that surrounds the use of payment cards like credit cards.

While PCI DSS is a standard, it’s not a certification. Your business can’t be “PCI certified” as such; instead, you simply need to be PCI Compliant. This compliance is an ongoing process of security awareness, self-attestation, auditing, and review.

All of this is crucial for our modern digital world. When credit card information is flying across the internet billions of times per day, that data absolutely must be secure. Fraud, data breaches, data theft; PCI DSS is meant to protect against all of it, as much as possible.

Compliance with PCI DSS involves a lot of technical and operational security measures for any system and any employee who touches, processes, handles, or could access payment card information. It’s also a moving target; the security standards evolve with the threat environment, with your business growth, and more.

Unlike many other security frameworks, PCI DSS only secures cardholder data. It applies to account numbers, expiration dates, cardholder names, service codes, PIN codes, card validation codes, and similar information.

Other sensitive information your business might handle is not protected under PCI DSS. It may be protected under other kinds of security (SOC 2, for example), or frameworks that may apply to you (ISO 27001 is a common one), but PCI DSS doesn’t care. It’s solely focused on payment card information.

What Goes into PCI DSS Compliance?

As mentioned, PCI DSS centers around a lot of technical and operational security controls focused on protecting cardholder information.

These include:

• Network security controls, to monitor network traffic, watch for suspicious activity, and prevent access from sources that aren’t authorized.
• Secure configuration requirements, to make sure no defaults sneak through and leave your systems vulnerable.
• Stored data protection, to ensure any cardholder data stored on your systems is adequately protected through encryption and other methods.
• Transit data protection, to ensure that any cardholder data passing through your systems is encrypted from start to finish and is protected against MITM attacks.
• Malware protection, to ensure that your systems, in general, are free from potential malicious intrusion.
• Secure development practices, to make sure any custom-developed code or systems your business uses are designed with security from the ground up.
• Access restriction, to make sure only people with the need and requirement to access data are allowed to do so, and no one else has the capability to even touch the systems involved.
• User access and authentication, to validate that your users are authenticated and validated to prevent unauthorized access or account sharing.
• Physical access control, to make sure any physical servers or systems that store cardholder data are protected.
• Access logging and monitoring, to keep a record of all access and activity and watch for signs of intrusion or unauthorized access.
• Testing and validation, to verify that all of the technical controls are functional and in place.
• Policy mandates, to make sure everything you do is backed up and enforced by company policy.

A lot goes into PCI DSS, but that’s not surprising. This list may seem long, but it’s still not as much as more general frameworks like ISO 27001 or government frameworks like FedRAMP. The scope is very narrow, focusing as it does solely on cardholder information, so a well-planned business might only have a small handful of tasks to complete to maintain compliance.

Who Needs PCI DSS?

If you’re a business, PCI DSS applies to you. However, how much it applies to you will vary.

PCI DSS protects cardholder information, so if you interact with cardholder information in any way, you have to comply with PCI DSS. Businesses that sell anything have to accept payments for those sales, so unless you’re a cash-only business or refuse to accept payment cards at all, you’ll need to comply.

Other entities in the financial system also have to comply. Card issuers, financial institutions, merchants of all sorts, acquirers, processors, fintechs; anywhere the information touches, no matter how briefly, must be secured.

PCI DSS is not law, per se. There is no country-level law that requires you to use PCI DSS. Rather, it’s a requirement baked into your agreements when you sign up for merchant accounts or use processors like Stripe or Square.

There’s also no minimum threshold. If you’re a business but you only do one transaction per year, you still have to comply. If you only handle transactions in person, as long as you accept cards, you have to comply. If you only deal with mail orders, as long as cards are involved, you have to comply.

The scale of your compliance needs depends on how much volume you handle.

Level 4 is for businesses that process fewer than 20,000 transactions per year. This has the lowest set of standards and review requirements, and means you generally can use self-attestation and internal auditing to comply. Level 3 is for businesses between 20,000 and 1,000,000 transactions, level 2 is for 1M to 6M, and level 1 is for any business handling over 6M transactions per year. At the higher levels, external audits and more frequent validation are required.

What is SOC 2?

SOC 2 stands for System and Organization Controls 2. It’s a framework that serves as an outline of organization controls across five core areas. It was developed by the American Institute of Certified Public Accountants, or AICPA.

Like PCI DSS, SOC 2 is not a certification. It’s a set of standards and an auditing process, which provides an attestation report, which can then be used to establish trust with other organizations that require it.

How is that different than a certification? Well, it’s not called a certification. Functionally, it’s similar.

SOC 2 is a broader framework than something like PCI DSS. It’s not just focused on protecting something as narrow as cardholder data; instead, it protects all customer data. Businesses that handle or interact with customer data will need to consider SOC 2 and what it might mean for them.

What Goes into SOC 2 Compliance?

SOC 2 centers around five key domains. Each domain encompasses a spectrum of security controls and implementations, as well as organizational and procedural controls, to protect sensitive information. In a way, it’s quite comprehensive, similar to something like ISO 27001. However, it’s much smaller than the likes of ISO 27001 or FedRAMP, which have backing documents like NIST SP 800-53 to establish hundreds of tangible controls.

Instead, SOC 2’s five domains are largely goal-oriented and encompass a lot of variable controls. Many of those controls are optional and depend on the type of business, the type of systems, and the type of compliance you’re aiming for. One business might pass an audit with around 80 controls; another might need 150.

This is because there aren’t specific, defined controls within SOC 2 the way there are with other frameworks. This is actually a pretty big point of frustration for many businesses; without a tangible checklist to run through, it’s a lot more work to figure out what you need to do.

The five key domains of SOC 2 are how the various controls are organized, on a philosophical level.

First is Security. This is the only non-optional part of SOC 2, and covers the full breadth of data security. Complying with this section means doing things like implementing strong multi-factor authentication, taking steps to prevent man-in-the-middle attacks, using robust user access controls, and more.

Second is Privacy. Privacy is the goal of keeping customer data secure because of its personal nature. It centers heavily around company policies, the use of consent forms and notifications, limitations on collecting and retaining customer information, and restrictions on how that data can be used.

Third is Confidentiality. Keeping sensitive customer data confidential is also important, and this defines when information is sensitive but private, and when it’s fully confidential. After all, some information needs to be shared to be used, while other information should not be shared at all. Identifying which kinds of information you handle, and how to handle them appropriately, is a key part of this domain.

Fourth is Processing Integrity. This is a more technical analysis of your systems. Anything that you use to store, process, retrieve, harvest, transform, or interact with customer information needs to be reviewed. Are your systems working as they should? Is data accurate? Is it used appropriately?

Fifth is Availability. This is a control centered around minimizing downtime within your systems, predicting system capacity, handling environmental threats, and making sure data is backed up so it doesn’t need to be re-harvested.

The biggest challenge with SOC 2 is its flexibility. Since there are philosophical domains and security goals, but not specific and tangible security controls, SOC 2 is heavily reliant on external auditing from professional and independent auditors. These auditors go through and review your systems along the five domains, evaluating according to their judgment how well you comply.

Effectively, you decide you want to earn SOC 2 attestation, you analyze your own systems, you develop your own controls and Trust Services Criteria, and then you implement them. The auditor then analyzes all of this and determines if you’re on the money and in compliance, and issues you your report.

A report result will be one of four results:

• Disclaimer of Opinion. This means the auditor doesn’t have enough information to say, and is inconclusive.
• Adverse. This means you failed your audit and will need to improve and try again.
• Qualified. This means you pass your audit, but with an asterisk and some areas of improvement necessary.
• Unqualified. This means you pass your audit with flying colors.

SOC 2 reports are meant to be mostly confidential. They’re designed for internal use and for sharing with certain key stakeholders and partners, because the information in them goes into great detail and can even be a risk if exposed.

There are other forms of SOC as well. SOC 1 is for narrowly-scoped financial information. SOC 3 is similar to SOC 2 but without specifics, and is meant more for the public. There are also specific SOC forms for Cybersecurity and Supply Chain, specifically.

Who Needs SOC 2?

PCI DSS is effectively required based on contracts when you want to accept credit card payments or handle payment card information. What about SOC 2?

SOC 2 is optional. It’s a strong attestation of security, and many business partners or high-end clients/customers for your business may want to require it as part of a contract, but outside of that, it’s not something you need to do.

There are good reasons to invest in SOC 2; it’s security, it builds credibility, and it can win you contracts that would otherwise be out of reach. Plus, if you already adhere to a standardized framework like ISO 27001, most of the work is already done.

No matter what framework you want to use, whether it’s PCI DSS, SOC 2, FedRAMP, CMMC, HIPAA, ISO 27001, or something else entirely, we’re here to help. The Ignyte Assurance Platform is our solution to the mess of documentation, requirements, tracking, and siloed software that presents such a challenge in security compliance. Use it to track your progress, store documentation and artifacts, and maintain a full awareness of your security posture.

To see how it works, simply reach out and book a consultation with a demo tailored to your needs. We’ll be happy to answer any questions you may have.