PCI DSS vs. SOC 2: Differences, Mappings & Streamlining

What are PCI DSS and SOC 2?

The Payment Card Industry Data Security Standard (PCI DSS) is a certification for credit card data security. Similarly, but with a broader focus, the System and Organization Controls Report (SOC 2) is a certification for overall data protection. Companies may seek one or both.

Key takeaways:

PCI DSS protects credit card data, while SOC 2 secures all types of sensitive customer data.
PCI DSS requires audits or self-assessments based on transaction volume; SOC 2 involves CPA audits with risk-based criteria.
About 60% of PCI DSS and SOC 2 requirements overlap, including access control, encryption, and vendor management.
Companies needing both certifications often process payments and handle other sensitive customer data, like SaaS or cloud providers.
Combining PCI DSS and SOC 2 efforts saves time (up to four months) and reduces costs by 20–30%.

Differences between PCI DSS and SOC 2

The main difference between PCI DSS and SOC 2 is the scope of each compliance framework. PCI focuses on the security of systems that collect, transmit, process, and store credit card data. SOC 2 focuses more broadly on data security for any system that serves customers or clients.

Here’s a more detailed list of differences between PCI DSS and SOC 2:

PCI DSS

Focuses on data security for the use and processing of credit cards.
Uses either self-assessment or an audit by a Qualified Security Assessor (QSA), depending on the number of credit card transactions being processed.
Features specific, checklist-like requirements rather than implementing controls from a risk assessment.
Has four PCI DSS compliance levels based on the number of credit card transactions processed. Each level has different compliance requirements.
Requires a PCI DSS policy, in addition to information security policies.

SOC 2

Focuses on the security of sensitive information, and, where relevant, the data’s confidentiality, availability, processing integrity, and/or privacy.
Uses an audit by a CPA who assesses the controls that the organization has selected to meet the SOC 2 criteria.
Features a risk-based framework, where the organization must demonstrate that its implemented controls meet SOC 2 criteria.
SOC 2 has two different types. SOC 2 Type 1 is a point-in-time audit that assesses whether internal controls are designed appropriately. Type 2 tests the design of the controls and whether the controls have been operating effectively over a period of time, typically 12 months.

Comparing SOC 2 and PCI DSS

How PCI DSS overlaps with SOC 2

PCI DSS and SOC 2 are two of the most widely used cybersecurity frameworks for businesses. The two frameworks share roughly 60% of the requirements, so you can use many of the same controls and evidence.

The overlaps between PCI DSS and SOC 2 include:

Access control
Both frameworks require logical and physical access policies, such as access reviews and termination controls. However, PCI goes a step further and requires a cardholder access policy, controls for access to data protection tools, and a vendor defaults policy, among other items.
Encryption
Both frameworks call out controls related to the encryption of data at rest or in transit.
Risk management
PCI requires a PCI risk analysis in addition to the typical SOC 2 controls around vendor risk management and a security risk assessment.
Incident response
PCI and SOC 2 share similar incident response policies, procedures, and controls.
Audit frequency
Both have annual audits.
Vendor management
Both frameworks share vendor management controls, such as a vendor management policy and periodic review of vendor security controls.
Physical security
Both include a physical access policy and related physical access controls, such as locked doors and controlled access to servers. PCI adds controls over physical access to cardholder data and a physical security policy for cardholder data.
Vulnerability management
Both cover frequent vulnerability scans. However, PCI has stronger vulnerability management requirements, such as an external vulnerability scan performed by an Approved Scanning Vendor (ASV) and specific policies for vulnerability management and system and information integrity.

Mapping the PCI DSS and SOC 2 controls overlap

This table shows the 60 percent of controls that the two frameworks share. Companies can save time and money by approaching the overlaps strategically. This table, with added PCI DSS and SOC 2 control reference numbers, is also available as a download below.

Control Title	Description
Contracts	The organization utilizes contractual agreements that define relevant data security [and privacy] commitments and requirements for its customers and third-party providers.
Data Flow Diagram	The data flow diagram is maintained and highlights the systems that require logical access controls per data classification level. The data flow diagram is updated annually or as business needs require.
Separation of Duties: IT Operations	Developers do not have access to IT infrastructure tools or the production environment. Exceptions are documented and approved by the head of IT.
Acceptable Use Policy	All staff sign an Acceptable Use Policy, which outlines rules for the acceptable use of information associated with information and information processing, as well as, appropriate procedures for compliance with legislative, regulatory, and contractual requirements related to proprietary software services.
Security Training	Employees and contractors complete security-related training, as relevant to their duties, upon hire and on an annual basis. The annual security training includes information on how to report security incidents and concerns. The training includes topics specific to different roles depending on participants' access to sensitive data.
Network Diagram	System boundaries are defined in the network diagram. The network diagram is reviewed annually or as business needs require.
Asset Inventory	An inventory of information assets, including hardware and software, is maintained and updated at least annually. All assets have an assigned asset owner. All assets are classified based on the data classification convention.
Risk Assessment Methodology	A risk assessment is conducted annually or in the event of significant changes to the organization and/or information systems. The risk assessment will identify, assess, mitigate, report and monitor security, fraud, legal & regulatory, and vendor risks. Risks are scored by likelihood and impact, and high risks are actioned upon according to the risk assessment policy.
Data Classification Policy	A defined information classification scheme has been established to label and handle data. This policy is reviewed, updated, and approved annually. Classifications consider the legal requirements, value, criticality, and sensitivity to unauthorized disclosure or modification of the information. Data is classified into three levels: public, confidential, and sensitive.
Vulnerability Scan	Vulnerability scans are performed quarterly to help identify security risks. Results are assessed and, where required, remediated.
Intrusion Detection	Threat detection tools are utilized to monitor and log possible or actual network breaches and other anomalous security events. Alerting occurs on threats and results are actioned as appropriate.
Logical Access	Logical Access Policy and Procedures are in place which define the authorization, modification, removal of access, secure authentication requirements, and the principle of least privilege. The policy is reviewed annually.
User Authentication	Unique usernames and passwords are required to authenticate all users. Users must use non-privileged accounts or roles when accessing non-security functions, and any shared accounts must be approved by the head of IT.
Termination of Access	A user's logical [and physical] access to IT systems is revoked within [# hours or business days] of termination or transfer and all assets are returned to the organization when employment ends or their contract terminates. Exceptions are documented in an offboarding checklist and/or offboarding ticket.
Data Retention/Deletion	Procedures are in place to remove data from production based on retention schedules, contract requirements, and deletion rules that are applied to specific forms of data; disposals are tracked; a data disposal process is in place. These procedures are reviewed, updated, and approved as needed.
Password Requirements	Authentication for the network, operating systems, databases, applications, cloud, and VPNs adheres to the company password setting requirements. These requirements are documented within the Logical Access [or Password] Policy.
Disk Encryption	Disk encryption is enforced, by centrally managed data loss prevention rules, on all employee devices.
Security Program Monitoring	Management actively monitors the status of its information security program and reports results to upper management quarterly.
Antivirus	Antivirus is installed on all workstations and servers to help protect against viruses and malicious software on the systems.
Change Management Policy	A Change Management Policy and Procedures are in place to request, document, test, and approve changes. The head of IT is responsible for ensuring that changes to IT services are made in a manner appropriate to their impact on operations. All technology acquisition, development, and maintenance processes are governed by change management procedures. The policy is reviewed at least annually and re-distributed to staff, as needed.
Separation of Environments	Production, testing, and development environments are logically and physically separated.
Encryption at Rest	All data at rest is encrypted using industry standard algorithms.
Encryption in Transit	Any sensitive data that is transmitted over public networks, and data in transit is encrypted.
Encrypted Server Access	Production system access is encrypted to ensure communications with servers are secured. Devices accessing or connecting to the system are authenticated prior to access being granted.
Change Management: Infrastructure	Infrastructure changes are tested, reviewed, and approved by authorized personnel prior to implementation.
Change Management: Application/Software	All application changes for internally developed software are developed, tested, and approved prior to implementation.
Firewall Rules	Firewall rule sets are configured and in place to help prevent unauthorized access threats from outside the application and infrastructure environment.
Risk Assessment Action Plans	Risks identified through the risk assessment process are addressed by management and appropriate mitigation strategies or risk acceptance are assigned and tracked for completion. Risk assessment results are shared with the leadership team and the board annually, and risk treatment activities are documented accordingly.
Data Management Policy	A defined Data Management Policy provides guidance on information categories, usage, storage, and transmission of data. This policy is reviewed, updated, and approved annually.
Visitor Sign-In	A visitor log is maintained for visitors accessing the physical locations in scope.
Server Room	Physical access to the onsite server room is restricted to authorized individuals [such as the DevOps team or specific job titles] who have the key; access is approved by the head of IT.
User Access Review	Management performs at least an annual review of user access to systems based on job duties. Inactive users are removed and removal is documented. The review is formally documented including system generated user listings and sign off by management.
Vendor Due Diligence	Due diligence activities are performed over new vendors and service providers prior to contract execution. Due diligence activities include an assessment of information security practices based on the assessed level of vendor risk.
Automatic Patching	Servers are configured to automatically install critical security patches.
Patch Management	A formal process is followed in order to identify, review, install, and monitor patches for servers, workstations, and network devices. Server patching scans occur and patches are applied as needed. Management is notified of any down time to apply updates. Acceptance testing is documented for new information systems, upgrades, and new versions.
Incident Response: Employee Responsibility	A documented incident response plan is in place to guide employees in identifying, reporting, and acting on breaches and incidents.
Incident Response: Process	The incident response process includes documentation of containment steps performed, impact assessment, data capture for analysis, mitigations, stakeholder notification, steps to restore service. The organization performs a root cause analysis (RCA) for incidents and information disclosures that could impact security, confidentiality, or privacy. The plan is protected from unauthorized disclosure.
Administrator Access	Internal administrator access to the application, database, network, VPN, and operating system is restricted to authorized users.
Employee Shared Drive	A centralized drive is in place for employees to access all corporate policies and procedures as well as job descriptions.
Locked Doors	Physical doors are locked according to policy.
Physical Access Policy	A Physical Access Policy is in place to guide employees through physical access protocols. The policy is reviewed at least annually and re-distributed to staff, as needed.
Provisioning	Logical/physical user access requests are documented and require approval prior to access being provisioned.
Badge Access System	A badge access system is in place to safeguard access to sensitive areas, access to physical servers onsite, and to log all user activity.
Risk Assessment Policy	The Risk Management policy and procedures are in place and include how to identify risks, to evaluate risks, and how to address and mitigate those risks. The policy is reviewed at least annually and re-distributed to staff, as needed.
Data Center Physical Access	Physical access to the onsite server room/data center is restricted to authorized individuals. All changes to access are documented. New access requests and changes to access are appropriately approved.
Vendor Review	Critical IT vendors and service providers are reviewed annually or more frequently based on risk level. The review includes updating vendor risk profiles, assessing performance against contracts, and re-assessing the vendors’ security controls.
Information Security Policy	The Information Security Policy is maintained, reviewed, and updated annually by management.
Incident Response: Testing	The security incident response plan is tested on at least an annual basis.
Background Check	Background/reference checks are required prior to hire.
Camera System	A camera system that covers all entry/exit points to high security areas (including emergency exits), windows, loading docks, fire escapes, and restricted areas (e.g., vault, server/machine room, etc.) is maintained.

Mapping the PCI DSS and SOC 2 evidence overlap

PCI DSS evidence items are often more specific to a certain system, but they share many requirements with SOC 2. This table shows the overlap of typical evidence collected for both frameworks.

Evidence Title	Evidence Description
Acceptable Use Policy	Provide the Acceptable Use Policy. If you have already uploaded signed versions of the policy, you may deactivate this evidence item.
Access Removal Procedures/Checklist	Provide the procedures or completed checklist used by IT to remove system access when employees are terminated.
Access Request - Current Employee	Provide the documented approval for the most recent current employee's request to access new IT tool(s). This could be a ticket from the ticketing system. It should show the tool(s) that access is being granted to, as well as who approved the access, and the date of approval.
Access Request - New Hire	Provide the documented approval for the most recent new hire's request to access IT tools. This could be a ticket or onboarding checklist. It should show the tools that access is being granted to, as well as who approved the access and the date of approval. In some organizations, basic access is automatically granted upon hire and captured on the onboarding checklist.
Access Termination Ticket	Provide a completed access termination ticket for the most recently terminated staff member.
Administrator Access to Application	Provide a system-generated list of administrative users for applications in scope. If uploading a manually created screenshot as evidence, it should include the date/time stamp to be valid.
Administrator Access to Database	Provide a system-generated list of the administrative users to all databases in scope. If uploading a manually created screenshot as evidence, it should include the date/time stamp to be valid.
Administrator Access to Network/Cloud	Provide a system-generated list of the administrative users to in-scope networks or cloud environments. If uploading a manually created screenshot as evidence, it should include the date/time stamp to be valid.
Administrator Access to Operating System	Provide a system-generated list of administrative users to the operating systems in scope. The list should include the user name, user ID, and account creation date, if possible. If uploading a manually created screenshot as evidence, it should include the date/time stamp to be valid.
Annual Employee Training	Provide the list or report showing who completed the annual IT security training during the audit period.
Antivirus Configuration - Server	Provide the antivirus configuration for each in-scope server. The screenshot should show that the anti-virus software is up to date. If uploading a manually created screenshot as evidence, it should include the date/time stamp to be valid. Alternatively, provide MDM tool settings and/or a current dashboard showing all devices enabled.
Antivirus Configuration - Workstation	Provide antivirus configuration set to run on workstations. If uploading a manually created screenshot as evidence, it should include the date/time stamp to be valid. Alternatively, provide MDM tool settings and/or a current dashboard showing all devices enabled.
Application User List	Provide a system-generated list (or series of screenshots) of all internal users with access to in-scope applications. Include the account creation date as well as the date that the account was removed, disabled or modified. If uploading a manually created screenshot as evidence, it should include the date/time stamp to be valid.
Application/Software Change List	Provide a system generated list of software/applications code/configuration changes deployed to production for the audit period. The list must include a merge request identifier or other unique number or identifier, the date of merge, and the name or title of the change (or a brief descriptor). The list must indicate the date/time the report was created.
Application/Software Change List Parameters	Provide the parameters used to generate the list of software/applications code/configuration changes deployed to production for the audit period. If uploading a manually created screenshot as evidence, it should include the date/time stamp to be valid.
Application/Software Change Testing	Provide a recent application change ticket that demonstrates developer and development activity as well as the tester and testing activity, review, and approval was completed prior to implementation.
Backup Policy	Provide the Data Backup and Restoration Policy. Ensure that the policy includes timing for backup failure remediation. This policy may be included as a subsection within the Information Security Policy or a stand-alone document.
Backup Restoration Procedures	Provide the documented backup restoration procedures. This may be documented within the Data Backup and Restoration Policy.
Business Continuity Plan	Provide the documented Business Continuity Plan. The plan should include how business operations will continue when a disaster has occurred. The plan should also include consideration of information communication technologies and the maintenance of information security.
Change Management - Developers	Provide a system-generated list of developers. If uploading a manually created screenshot as evidence, it should include the date/time stamp to be valid.
Change Management - Production Access	Provide a system-generated list of internal users who can push changes to production. If uploading a manually created screenshot as evidence, it should include the date/time stamp to be valid.
Change Management Policy	Provide the Change Management Policy. This should include types of changes, departments involved, version control and ticketing tools used, the process of development, testing, approvals, migration to production, segregation of duties, and separation of environments.
Code Repository Access List	Provide a system-generated list of all users with access to the source code repository. This may be included in the user access review documentation. If uploading a manually created screenshot as evidence, it should include the date/time stamp to be valid. Ensure that the access is appropriate for the users noted.
Contractor List	Provide a system generated list(s) of all contractors employed by the organization for the audit period. This list should include the contractor's name, company name, reporting Manager, department, start date, and termination date (if applicable).
Contractor List Parameters	Provide the attributes selected or the query used to generate the list of all contractors employed during the audit period. If uploading a manually created screenshot as evidence, it should include the date/time stamp to be valid.
Critical Vendor SOC 2 Review	Provide the documented review of the most recent SOC 2 reports for all critical subservice organizations. If using the Strike Graph template, critical vendor SOC 2 review is included within the Vendor Risk Register, if you are including your review in that sheet you may deactivate this evidence item. The subservice organization's CUECs must be addressed. The review should be performed at least annually.
Current Data Flow Diagram	Provide the data flow diagram which shows the way information flows through the organization’s process or system. Redact all IPs. Ensure that the diagram has a 'last updated' date included within the document and the date is within the last 12 months or within the audit period. For privacy frameworks also show the flow of PII. For PCI, show the flow of cardholder data.
Current Network Diagram	Provide the network diagram that indicates the routes of which data travels (i.e. internal and external nodes). Redact all IPs. Ensure that the diagram has a 'last updated' date included within the document and the date is within the last 12 months or within the audit period. For PCI, the network diagram should indicate the firewall, DMZ, customer, and internal network zones.
Customer Contract	Provide the most recent signed contract, Master Service Agreement, Statement of Work, or similar document with a new customer. Ensure that the document includes security (and, where appropriate, privacy) components.
Customer List	Provide a system generated list of all active customers that includes the dates of their acquisition. Include a screenshot of the parameters used to generate the export. The list should include the customer's name and the date the customer contract became live. The screenshot should include the date/time stamp to be valid.
Data Classification Policy	Provide the Data Classification Policy. This should include the data within your organization and how data is classified. For NIST, this should also include media marking.
Data Disposal List	Provide a system generated list of all data disposals for the audit period. This will typically come from the ticketing system. The list should include the data element and the date of its disposal.
Data Disposal Ticket	Provide an example of the most recent data disposal event.
Data Management Policy	Provide the policy or procedures governing information categories, usage, storage, and transmission of data. This policy should also include a discussion of record disposal practices. This policy should be reviewed, updated, and approved annually.
Database Encryption	Provide the settings showing that sensitive data at rest is encrypted on the database or evidence that external database providers employ database encryption (via their SOC 2 or contractual documentation). If uploading a manually created screenshot as evidence, it should include the date/time stamp to be valid.
Database User List	Provide a system-generated list (or series of screenshots) of users with access to the internal database. Include the account creation date as well as the date that the account was removed, disabled or modified. If uploading a manually created screenshot as evidence, it should include the date/time stamp to be valid.
Device Disk Encryption	Provide the setting showing that disk encryption is required and pushed to all internal devices. If uploading a manually created screenshot as evidence, it should include the date/time stamp to be valid. Alternatively, provide MDM tool settings and/or a current dashboard showing all devices enabled.
Employee Intranet	Provide a screenshot showing that in-scope policies are made available to employees via the intranet (or similar). The screenshot should include the date/time stamp to be valid.
Employee List	Provide a system generated list(s) of all employees for the audit period. Include current employees and employees terminated during the audit period. This list should include name, job title, hire date, termination date, and if possible, the department, manager name, and location or office site. Current contractors can be added to this list if they come from the same system.
Employee List Parameters	Provide the attributes selected or the query used to generate the list of all current employees for the audit period. The selection parameters should include no terminated employees. If uploading a manually created screenshot as evidence, it should include the date/time stamp to be valid.
Employee Reporting	Provide evidence that employees are made aware of their responsibilities in reporting incidents or potential security breaches to the Head of IT. Examples include a screenshot from an intranet page or a slide in an all-hands security training deck or presentation. If uploading a manually created screenshot as evidence, it should include the date/time stamp to be valid.
Employee Screening	Provide support that a background check or other screening was conducted for a recent new hire prior to employment. This can be an invoice from the background check service or the specific background check results with PII obscured.
Encryption in Transit	Provide configuration evidencing encryption-in-transit for connections between services (SFTP, VPN).
Firewall Rules	Provide the firewall rule configurations for the cloud service network. This can be via a dashboard, the rule settings, or the DMZ, if applicable. If uploading a manually created screenshot as evidence, it should include the date/time stamp to be valid.
Incident List Parameters	Provide the parameters used to generate the list of security incidents for the period. If uploading a manually created screenshot as evidence, it should include the date/time stamp to be valid.
Incident Response Plan	Provide the Security Incident Response Plan. It should outline how incidents are defined, documented, tracked, monitored, resolved, and the departments that are involved in the identification, investigation, containment, eradication, and recovery.
Incident Response Tabletop Test	Provide evidence that the incident response plan was tested during the audit period. This could be in the form of a memo documenting the tabletop test that includes relevant members of the incident response team. If there has been a security incident within the audit period, you may use that incident as your test.
Information Security Policy	Provide the Information Security Policy and supporting evidence (e.g., revision history, email communications, version redline edits, the timestamp on the actual policy) to show that the Information Security Policy has been reviewed and approved by the policy owner within the audit period.
Infrastructure Change List	Provide a system generated list of infrastructure changes deployed to production during the audit period. The list should include the deployment date, the name of the service changed or implemented, and a ticket number or other reference.
Infrastructure Change List Parameters	Provide the parameters used to generate the list of infrastructure changes deployed to production for the audit period. If uploading a manually created screenshot as evidence, it should include the date/time stamp to be valid.
Infrastructure Change Testing	Provide the most recent ticket for an infrastructure change that demonstrates that the change was tested, reviewed, and approved.
Intrusion Detection Configuration	Provide the intrusion detection/ intrusion prevention system (IDS/IPS) configurations. This should include the alerting rules. If uploading a manually created screenshot as evidence, it should include the date/time stamp to be valid.
Logical Access Policy and Procedures	Provide the document that details the Logical Access Policy and Procedures. The document should include the concepts of role-based access and least privilege. For some organizations, this document may also include logical access procedures.
Management Review - Risk Assessment	Provide documentation demonstrating management's review of the risk assessment.
Network/Cloud User List	Provide a system-generated list (or series of screenshots) of all users with access to the internal network or cloud environment. Include the account creation date as well as the date that the account was removed, disabled or modified. If uploading a manually created screenshot as evidence, it should include the date/time stamp to be valid.
New Employee Access	Provide evidence showing that access to the network and internally managed software was provisioned based on job role, approved, and implemented promptly and accurately. This can be shown by a recent ticket, a checklist or other means.
New Hire Training	Provide evidence of the completed IT security training for the most recent new hire. This can be a certificate, sign-off, or a report from the system showing that required new hire training has been completed in a timely manner.
Operating System User List	Provide a system-generated list (or series of screenshots) of all internal operating systems users. Include the account creation date as well as the date that the account was removed, disabled or modified. If uploading a manually created screenshot as evidence, it should include the date/time stamp to be valid.
Organizational Chart	Provide the most recent organizational chart. Ensure that it includes the date it was last updated.
Password Settings - Application	Provide the application layer password settings. Ensure that the settings match your password policy. If uploading a manually created screenshot as evidence, it should include the date/time stamp to be valid. The configurations should mirror the password policies within relevant security policies.
Password Settings - Database	Provide the database layer password settings. If uploading a manually created screenshot as evidence, it should include the date/time stamp to be valid. The configurations should mirror the password policies within relevant security policies.
Password Settings - Network/Cloud	Provide the network or cloud layer password settings. If uploading a manually created screenshot as evidence, it should include the date/time stamp to be valid. The configurations should mirror the requirements found in the Password Policy or relevant security policies.
Password Settings - Operating System	Provide the operating system layer password settings. If uploading a manually created screenshot as evidence, it should include the date/time stamp to be valid. The configurations should mirror the password policies within relevant security policies.
Patch Management Policy	Provide the Patch Management Policy or procedures that include the automatic and manual procedures for patch updates. The policy should also include a process on verifying the source of a patch to ensure authenticity.
Patch Scan	Provide the tool configuration to scan the network for unpatched network devices and machines. If uploading a manually created screenshot as evidence, it should include the date/time stamp to be valid.
Periodic Logical Access Review	Provide all completed internal user access reviews for the audit period. The reviews should include a system-generated list of users to all in-scope systems, the level of access they have, evidence that access was reviewed, and proof that any requests for removal were carried out. This is commonly tracked using tickets or a spreadsheet with tabs outlining access for each in-scope service.
Record Retention Schedule	Provide the record or document retention schedule. This may be included within the Data Retention Policy or may be a separate document.
Risk Assessment	Provide evidence of a completed risk assessment being performed during the audit period that includes assessment of fraud, vendor, IT, environmental and physical (only if your company manages its own physical data center and servers), and business operational risks. The assessment should also include risk score, risk owner, and mitigation plans. The Strike Graph Risk Assessment results can be downloaded and attached.
Risk Management Policy and Procedures	Provide the document governing the risk management process. This should include frequency of the risk assessment, identification of risks, scoring/rating risks, and impact of risks. If using Strike Graph's risk assessment, this will be the Risk Management Policy document.
List of Security Incidents	Provide a system generated list of all security or privacy incidents during the audit period. The list should include the date the incident was reported and a title or brief description of the incident. Ensure that the incidents were addressed in accordance with the Incident Response Plan.
Security Incident Resolution	Provide a completed security incident response ticket or report. It must include the following: analysis of the impact of a security event, incident containment, incident resolution, classification of the severity of the incident, and root cause analysis of the incident. Any technical analysis or log review should also be included. This process is typically documented in a memo, ticket, or incident template form.
Separation of Environments	Provide (a) screenshot(s) showing the production, development and testing environments are logically separated from one another. If uploading a manually created screenshot as evidence, it should include the date/time stamp to be valid.
Server Encryption	Provide the operating system/server or virtual machine (VM) encryption configuration for a sample server in scope. If uploading a manually created screenshot as evidence, it should include the date/time stamp to be valid.
Server Scan and Patch	Provide evidence of the most recent patch update following industry standards/updated patch available from vendors. If uploading a manually created screenshot as evidence, it should include the date/time stamp to be valid.
Signed Acceptable Use Policy	Provide the signed acceptable use policy for the most recently onboarded new hire. If the acknowledgment is separate from the policy content, also provide the full Acceptable Use Policy document.
Termination List	Provide a system generated list of all terminated employees during the audit period. The list should include the name, date terminated, and department. If you are providing an export from another tool (ie an Excel sheet or CSV file) then also include a screenshot showing how the export was generated.
Training Materials	Provide the security (and privacy, if in scope) awareness training materials used for annual all-hands training. This could be from an educational system or from a presentation.
Vendor Due Diligence	Provide a recently completed due diligence review or report for a new vendor or critical service provider. Due diligence activities are those that occur before a new vendor is onboarded. NOTE: This new vendor review is included within the Strike Graph Vendor Risk Register template. If you are using the Strike Graph Vendor Risk Register sheet, you can log your new vendor due diligence activities using the tab on the sheet and deactivate this evidence item.
Vendor List	Provide a list of all new, active vendors or organizations that the organization pays for services that were added during the audit period. The list should include the vendor's name, date onboarded, date offboarded (if relevant), and a brief description of the service provided (if available).
Vendor Management Policy and Procedures	Provide the Vendor Management Policy and the steps or processes that are undertaken to review the vendor's security practices.
Vendor Risk Register	Provide the register showing relevant IT vendors and any critical non-IT vendors along with their associated risk level (and date of the last review).
Vulnerability Management Policy	Provide the documented process that addresses roles and responsibilities associated with vulnerability management, vulnerability risk rating system and SLAs, and vulnerability remediation steps. Include information on how vulnerabilities can be reported by third parties, suppliers, or vendors.
Vulnerability Remediation	Provide evidence of remediation activity for critical or high vulnerability scan findings.
Vulnerability Scan Results	Provide the results of all quarterly vulnerability scans over the service IP domains and endpoints. If vulnerability scanning takes place on a more frequent basis, update the control frequency. If scans take place monthly, provide every monthly scan during the audit period.

SOC 2 to PCI DSS Mapping Download

The spreadsheet below shows the SOC 2 and PCI DSS control and evidence overlaps, including the SOC 2 and PCI control reference numbers.

How to choose between PCI DSS and SOC 2

Choosing between PCI DSS and SOC 2 depends on the type of data you’re handling. Also, some businesses may benefit from both certifications. PCI DSS certifies for cardholder or credit card data, while SOC 2 certifies for any sensitive data. Some clients may require businesses to have one or both.

The choice between PCI DSS and SOC 2, or doing both, depends on these factors:

Type of data handled and audit scope: PCI deals with cardholder or credit card data. SOC 2 protects sensitive data involving a service being provided. The SOC 2 audit covers systems that the data passes through or rests on.
Compliance requirements: Contracts and vendor management typically drive the need for SOC 2 compliance. An organization typically needs to fulfill a requirement to be compliant with a generally accepted framework, and SOC 2 is the most popular in the United States. Other options are typically ISO 27001, COBIT, and NIST CSF. Non-compliance can result in missed revenue. The major credit card companies drive PCI compliance, and non-compliance results in costly fines.
Business model: Businesses that process a high volume of credit card transactions must be PCI compliant. Businesses that provide a service to other businesses that store, process, or collect customer data should be SOC 2 compliant.

Micah Spieler, Chief Product Officer at Strike Graph

“PCI DSS is truly just for companies handling credit card transactions,” says Micah Spieler, Chief Product Officer at Strike Graph. “Unless you’re directly handling credit card data, there’s no compelling reason to add PCI to your compliance program.”

To learn more about this choice, see our articles on who needs PCI DSS and who needs SOC 2.

When should a company get both PCI DSS and SOC 2 certifications?

A company should get both PCI and SOC 2 when it collects credit card payments and provides a data-related service to clients, customers, or vendors.

Here are other situations when a company may need both PCI DSS and SOC 2 certifications:

Handles both credit card transactions and other sensitive customer data, such as a SaaS platform with integrated payment processing
Provides services to both consumers and enterprise clients, requiring compliance with multiple security frameworks
Operates in industries with stringent regulatory requirements (e.g., healthcare, finance) and handles both payment and non-payment data
Offers cloud or managed services where customers expect SOC 2 compliance and also processes credit card payments, necessitating PCI DSS
Seeks to build trust and credibility by demonstrating strong security controls across various types of sensitive data
Expands services from payment processing to include broader data handling for clients, necessitating both certifications
Works with third-party vendors that require compliance with both PCI DSS and SOC 2

“If you are ambitious, you can tackle PCI and SOC 2 at the same time,” Spieler says. “They share many of the same control and evidence requirements, so they fit well together. However, if you have a small team with less availability, or don’t have a pressing deadline, it’s easier to start with SOC 2 — that will give you a good baseline to then layer PCI on top of."

How to add PCI DSS if you have SOC 2 certification

If you already have SOC 2, adding PCI will require going into more detail. First, define the scope of your PCI environment. Perform a gap analysis to identify SOC 2 controls to enhance or PCI gaps to address. The final steps are implementation and an audit, if required.

Implement or update any existing controls and collect the required evidence items. If an audit is required, based on PCI DSS compliance levels (Levels 1-4), hire a Qualified Security Assessor (QSA) to perform the audit.

How to add SOC 2 if you have PCI DSS certification

If you already have a PCI certification, adding SOC 2 is not a big lift. You can leverage many of PCI’s detailed requirements for SOC 2. Adding SOC 2 involves determining what to cover, assessing risk, and conducting a gap analysis.

Michelle Strickler, CRISC and Senior Cybersecurity Compliance Manager at Workstreet

“The first step to a SOC 2 is to define scope,” says Michelle Strickler, CRISC and Senior Cybersecurity Compliance Manager at Workstreet. “Is the organization going to tackle only the common criteria (aka security), or will it be adding any of the other criteria to the SOC 2 report, such as availability, confidentiality, processing integrity, or privacy? Part of defining the scope is to identify the exact product or service to be covered by the SOC 2 report.”

Strickler adds, “Once you define the scope and understand the requirements, you can undertake a risk assessment and gap analysis. This process will identify which controls and evidence items you can reuse for SOC 2. After implementing all controls and collecting the evidence, hire a CPA to perform the audit and issue the SOC 2 report.”

How to do SOC 2 and PCI DSS at the same time

Defining the scope for each audit is key to tackling PCI and SOC 2 simultaneously. For example, controls may be the same, but evidence for PCI could be limited to a specific network or database. Compliance software, like Strike Graph, can help you minimize duplicative efforts.

There is roughly a 60% overlap in controls for both frameworks, but the evidence items may be more specific for PCI. This is where a configurable tool for GRC (governance, risk, and compliance) can help.

For more on this topic, listen to Strike Graph CEO Justin Beals and ComplySAM CEO Sam Oberholtzer discuss the benefits of tackling PCI DSS and SOC 2 together.

Summary

Justin: So our first question - this is going to be a lot of fun. I'm the questioner. You are the expert today. What is PCI DSS? We could just start there with a big overview.

Sam: Of course. Don't want to bore everyone too much, but at least it's exciting for the folks who may not know that they actually need to be compliant with this. So just starting off, PCI DSS stands for Payment Card Industry Data Security Standard, and this is a type of audit that an independent body or a qualified assessor will actually come in and assess against the standard. And so really there's a council called Security Standards Council, that is actually the ones that enforce the standard, but really the big payment credit card companies, Visa, MasterCard, American Express, Discover, and JCB are actually the ones that have to enforce it.

Justin: Oh, I see. So if essentially let's say that I have a tech startup or, I have an online platform. We want to process credit cards. You're not going to be able to store, submit, get Visa to pay you back, run a transaction without compliance against this standard. Is that right?

Sam: So actually you technically are still going to be allowed to process card holders’ data. However, it's up to those five big crack card companies to actually perform audits and investigations. So we'll definitely dive into the fines later, but I thought that was super interesting, that the council is not actually required to do so, but the banks themselves are allowed to and should do that.

Justin: Absolutely. Yeah. So tell me a little bit, a lot of our customers are looking for SOC 2 reports. That's the general security compliance standard that I think a lot of people in North America have gravitated towards. What's the difference between PCI DSS and SOC 2, and if I did SOC 2, how far away might I be from PCI DSS?

Sam: Yeah, absolutely. So PCI pretty much includes all of SOC 2. Of course, I will say I do have to do a disclaimer, even though when I was on the audit side, the systems overlapped. So PCI would take all of SOC 2, and then additional systems that collected the payment and credit card information. So that's why I say typically PCI will include SOC 2, because SOC 2, as we may know, really derives around the systems and the services that the company provides.

Justin: Got you.

Sam: While PCI is really highlighting the payment systems. Payment processing systems, card holder data systems. However you may call it. And a lot of the time it is including the SOC 2 systems. And so-

Justin: Go ahead, Sam.

Sam: And I was going to say, and so typically there's about a 60% overlap. And so PCI just has an additional 40% depending on the services of the company.

Justin: Okay. That's super helpful. What we love about this, and something we of course have built into the intelligence in our platform, is that activities that you might be doing for SOC 2 that are applicable to the standard like PCI DSS, are essentially mapped to both standards. And so you're able to take advantage of work on one for work on the other. That's super helpful. …

Justin: I think the one that I always worry about is if you are going to be running these types of financial transactions, there's just so little room for error. And I think that while it's great to minimize, look, we all want to minimize the amount of compliance we have to go through. That is a given. At the same time it always makes me nervous when you're working in situations where every transaction has to be perfect. And so I do think if I were doing this, I might look through the SOC 2 portion of the standard for processing integrity.

Justin: And also probably wrap that into what I'm thinking and broadly to say like, "Do I have some controls around processing integrity, and error checking around processing integrity, so that I'm sure that these transactions are processed in the correct way." And then you get into financial controls too.

Sam: Exactly.

Time savings by doing PCI DSS and SOC 2 at the same time

Pursuing PCI DSS and SOC 2 compliance separately can take four to 12+ months. By aligning efforts, organizations can leverage overlapping controls and documentation, potentially completing both within three to eight months before handing off to auditors. This approach can save one to four months compared to pursuing each compliance separately.

How long does it take to achieve PCI DSS compliance separately?
The duration varies based on the merchant's compliance level. For Level 1 merchants processing over 6 million transactions annually, compliance can take six to 12 months due to rigorous requirements, including an annual on-site audit. For Levels 2 to 4, the process typically takes two to six months and involves self-assessment.
How long does it take to achieve SOC 2 compliance separately?
The timeline depends on the type of report. A Type 1 report assesses controls at a specific point in time, usually taking two to three months to prepare and complete. A Type 2 report evaluates controls over a period (typically three to 12 months), requiring an initial preparation phase of two to six months, followed by the audit period.
How long does it take to achieve both PCI DSS and SOC 2 compliance?
By aligning efforts, organizations can leverage overlapping controls and documentation, potentially completing both within three to eight months before handing off to auditors.

Cost savings by doing PCI DSS and SOC 2 at the same time

Combining PCI DSS and SOC 2 reduces redundant efforts, saving 20-30% by overlapping audits, controls, and documentation. Savings depend on the PCI DSS level (1-4) and SOC 2 report type (Type 1 or Type 2) and trust criteria categories included.

How much does it cost to do PCI DSS?
Achieving PCI DSS compliance costs vary based on organization size and transaction volume. Small businesses may spend $5,000 to $20,000, while larger enterprises could incur $50,000 to $200,000. Expenses include assessments, network security, data encryption, employee training, vulnerability scans, penetration testing, and compliance fees.
How much does it cost to do SOC 2?
Achieving SOC 2 compliance costs vary based on organization size, complexity, and audit scope. For small to midsize companies, a SOC 2 Type 1 audit typically ranges from $7,500 to $15,000, while a Type 2 audit averages between $12,000 and $20,000. Larger organizations may incur higher expenses, potentially exceeding $100,000.
How much does it cost to do both PCI DSS and SOC 2?
Combining PCI DSS and SOC 2 compliance efforts can lead to cost efficiencies by addressing overlapping requirements simultaneously. While individual costs vary, pursuing both standards together may reduce overall expenses by 20-30% compared to separate implementations. For instance, if separate compliance efforts cost $100,000 each, a combined approach might total $140,000 to $160,000, depending on organizational factors.

How Strike Graph streamlines PCI DSS and SOC 2

If you want to learn how the controls and evidence for PCI DSS and SOC 2 map specifically for your organization, set up a time to chat with a Strike Graph compliance expert. Bundling PCI and SOC 2 using Strike Graph can save organizations between $10,000 and $40,000+ and an average of two to three months.

Contact Strike Graph today to get on the path to streamlined compliance.

PCI DSS and SOC 2 FAQs

Can an organization achieve both PCI DSS and SOC 2 certifications simultaneously?
While it is possible to prepare for PCI compliance and SOC 2 simultaneously, many organizations have them audited them back-to-back or with a bit of space between the audits due to auditor scheduling. A QSA may have a different skill set than the IT Auditor working under a CPA, and staffing the audit team is the main driver.
Which industries typically need both PCI DSS and SOC 2 certifications?
Online retailers and SaaS providers that process many credit card transactions will need both PCI DSS and SOC 2 certifications.
How often must an organization be audited for PCI DSS and SOC 2 compliance?
Organizations are audited at least annually for PCI DSS and SOC 2. However, some organizations, such as the major cloud providers, may find that their customers prefer a semi-annual SOC 2 attestation.
What are the consequences of non-compliance with both PCI DSS and SOC 2 standards?
Noncompliance with PCI results in monthly fines and could restrict the organization’s ability to continue processing credit cards. That could result in the loss of contracts and reduce customer trust and revenue.
Are there tools or systems that help organizations comply with both PCI DSS and SOC 2?
The PCI Council offers useful templates and guides to assist organizations in compliance. For SOC 2, “tools” are in the form of costly compliance consultants, policy templates found through internet searches or AI prompts, and a variety of GRC tools and services.

DOWNLOAD YOUR FREE EBOOK:

5 things every startup founder should know about SOC 2

The Platform

Features

Solutions

For industries

Frameworks

Strike Graph

FEATURED

Thought leadership

categories

Ebook

SEARCH

Ready to see Strike Graph in action?

We look forward to helping you with your compliance needs!

We look forward to helping you with your compliance needs!

PCI DSS vs. SOC 2: Differences, Overlaps and Streamlining Certifications

written by Kenneth Webb , CISSP, GWAPT, CSSLP, CISA, CIS LA Strike Graph

In this article:

What are PCI DSS and SOC 2?

Differences between PCI DSS and SOC 2

Comparing SOC 2 and PCI DSS

How PCI DSS overlaps with SOC 2

Mapping the PCI DSS and SOC 2 controls overlap

Mapping the PCI DSS and SOC 2 evidence overlap

SOC 2 to PCI DSS Mapping Download

How to choose between PCI DSS and SOC 2

When should a company get both PCI DSS and SOC 2 certifications?

How to add PCI DSS if you have SOC 2 certification

How to add SOC 2 if you have PCI DSS certification

How to do SOC 2 and PCI DSS at the same time

Time savings by doing PCI DSS and SOC 2 at the same time

Cost savings by doing PCI DSS and SOC 2 at the same time

How Strike Graph streamlines PCI DSS and SOC 2

PCI DSS and SOC 2 FAQs

Download your free ebook now for practical tips on achieving SOC 2 compliance.

Get a product demo to talk with our experts and see Strike Graph in action

Related Stories

Keep up to date with Strike Graph.

Frameworks

Learn more

Ready to see Strike Graph in action?

We look forward to helping you with your compliance needs!

We look forward to helping you with your compliance needs!

written by Kenneth Webb
, CISSP, GWAPT, CSSLP, CISA, CIS LA
Strike Graph