Deception is moving at machine speed. Learn to keep pace.
Portal LoginSupportBlogContact
Search
Portal LoginSupportBlogContact
Search
Get a Demo
Start for Free
HomeCybersecurity 101
PCI DSS

PCI DSS Cyber Security: Requirements and Best Practices

Written by: Lizzie Danielson

Published:10/3/2025
Last Updated: 9/21/2026

Glowing white shield with checkmark inside neon circular rings on a dark server-room stage
ChatGPT logoChatGPTOpens in new tabClaude logoClaudeOpens in new tabPerplexity logoPerplexityOpens in new tabGoogle Gemini logoGoogle AIOpens in new tab
On This Page

PCI DSS, or the Payment Card Industry Data Security Standard, establishes security requirements for protecting payment card data. For managed service providers (MSPs) and internal IT teams, understanding how those requirements map to practical security controls can support a stronger, more consistent security program.

Key takeaways

  • PCI DSS establishes security requirements for organizations and service providers within its scope.
  • Scope depends on the systems, people, processes, and services connected to payment card data.
  • Requirement 10 addresses logging and monitoring, while Requirement 11 addresses security testing.
  • A managed SIEM can support logging, monitoring, investigation, and reporting activities, but it does not independently establish PCI DSS compliance.
  • Transaction thresholds and validation requirements vary by payment brand, acquirer, merchant, and service-provider classification.
  • PCI DSS compliance requires ongoing control management, documentation, monitoring, testing, and validation.

What does PCI DSS mean for cybersecurity?

PCI DSS is a security standard created by the PCI Security Standards Council. It addresses how organizations protect cardholder data when it is stored, processed, or transmitted.

The standard covers:

  • Network security
  • Protection of stored and transmitted cardholder data
  • Vulnerability management
  • Access control
  • Logging and monitoring
  • Security testing
  • Information security policies

PCI DSS establishes requirements for organizations and service providers within its scope. Specific controls and validation obligations depend on the organization’s cardholder data environment, role, and applicable payment-brand or acquirer requirements.

Why PCI DSS matters for MSPs and their clients

PCI DSS compliance is more than a documentation exercise. Organizations that fail to meet applicable requirements may face consequences from payment brands or acquiring banks, including fees, additional validation requirements, or restrictions on payment processing.

A security incident can also lead to investigation, remediation, legal, notification, and recovery costs. MSPs should understand how their services affect each client’s cardholder data environment and compliance responsibilities.

MSPs may also be in scope when they store, process, transmit, or otherwise affect the security of cardholder data. The exact obligations should be confirmed with the applicable acquiring bank, payment brand, or Qualified Security Assessor (QSA).

Who needs to consider PCI DSS compliance?

Organizations that store, process, or transmit cardholder data may be subject to PCI DSS requirements. This can include:

  • Retailers
  • Ecommerce businesses
  • Restaurants
  • Healthcare organizations that accept card payments
  • Businesses using point-of-sale systems
  • Service providers that affect the security of cardholder data

PCI DSS scope is determined by the systems, people, processes, and services connected to payment card data—not simply by an organization’s industry or size.

The 12 PCI DSS requirements

PCI DSS requirements are organized around protecting payment card data and securing the systems that support payment processing.

1. Install and maintain network security controls

Organizations must use appropriate network security controls to protect systems and environments that store, process, or transmit cardholder data.

This includes defining network boundaries, managing traffic, and reviewing security-control configurations.

2. Apply secure configurations to system components

Systems should be set secure configurations rather than vendor-supplied defaults. Organizations should manage configuration standards, remove unnecessary services, and protect administrative credentials.

3. Protect stored account data

Organizations must apply appropriate protections to stored account data. Depending on the environment, this may include limiting data retention, restricting access, masking data, and using cryptographic protections.

4. Protect cardholder data during transmission

Cardholder data transmitted across open, public networks must be protected with strong cryptography and secure protocols.

Organizations should also verify that insecure protocols and unnecessary transmission paths are not used.

5. Protect systems and networks from malicious software

Organizations must protect systems against malware where applicable. This includes deploying anti-malware technologies, maintaining them, and monitoring for relevant threats.

6. Develop and maintain secure systems and software

Organizations must address vulnerabilities throughout the system and software lifecycle. This includes applying security updates, managing vulnerabilities, and incorporating secure development practices where applicable.

7. Restrict access by business need to know

Access should be limited according to business needs. Users should receive only the privileges required for their roles.

8. Identify users and authenticate access

Organizations should assign unique identities to users and apply appropriate authentication controls. These may include strong passwords, multi-factor authentication (MFA), and controls for service and application accounts.

9. Restrict physical access to cardholder data

Physical access to systems and media containing cardholder data should be controlled and monitored. Organizations should address facilities, devices, media, and visitor access.

10. Log and monitor access to systems and cardholder data

Organizations should collect and protect relevant audit logs, monitor access and security events, review logs at the required frequency, and retain records according to applicable requirements.

A managed SIEM can support these activities, but PCI DSS does not require an organization to use a product specifically labeled SIEM.

11. Test security systems and processes regularly

Requirement 11 addresses testing security systems and processes. Depending on the applicable requirements and environment, this may include vulnerability scanning, penetration testing, wireless testing, intrusion-detection testing, and other security-validation activities.

12. Support information security with organizational policies

Organizations should maintain information security policies and supporting programs. These policies help define responsibilities, procedures, risk-management activities, security awareness training, and incident-response processes.

PCI DSS validation levels and transaction volume

Payment brands and acquiring banks commonly classify merchants according to transaction volume. However, thresholds and validation requirements can vary based on:

  • Payment brand
  • Acquiring bank
  • Merchant classification
  • Service-provider classification
  • Transaction type
  • Cardholder data environment
  • Applicable validation program

Some organizations may complete a Self-Assessment Questionnaire (SAQ), while others may require an assessment performed by a QSA. External vulnerability scans, reports, attestations, or other validation activities may also apply.

The applicable validation path should be confirmed with the organization’s acquiring bank, payment brand, or QSA. Transaction-volume categories should not be treated as universal rules.

How to become and remain PCI DSS compliant

PCI DSS compliance is not a one-time assessment or validation event. Organizations should establish an ongoing process that includes the following steps:

  1. Define the cardholder data environment

    Identify the systems, applications, people, processes, and service providers that store, process, transmit, or otherwise affect the security of cardholder data.

  2. Determine applicable requirements

    Review the organization’s scope, payment-brand rules, acquirer requirements, and applicable PCI DSS validation path.

  3. Assess current controls

    Compare existing safeguards, policies, procedures, and technical controls with the applicable PCI DSS requirements.

  4. Remediate identified gaps

    Address vulnerabilities, access-control issues, configuration weaknesses, logging gaps, policy deficiencies, and other findings.

  5. Complete required validation activities

    Depending on the environment, this may include an SAQ, QSA assessment, Approved Scanning Vendor (ASV) scan, penetration test, attestation, or other documentation.

  6. Maintain controls throughout the year

    Continue monitoring, reviewing logs, testing security controls, managing changes, addressing vulnerabilities, and preserving required evidence.

What happens if an organization ignores PCI DSS requirements?

Potential consequences vary by the organization’s payment-brand and acquiring-bank relationships. They may include:

  • Additional fees or assessments
  • Increased validation requirements
  • Required remediation
  • Forensic investigation after an incident
  • Costs associated with notification and recovery
  • Restrictions on payment processing
  • Legal, contractual, or reputational consequences

The consequences depend on the specifics of the situation, the organization’s agreements, the applicable payment-brand rules, and whether a security incident occurred.

PCI DSS and its ties to cybersecurity practice

PCI DSS is not just paperwork. It’s a practical framework for risk management and aligns closely with cybersecurity best practices across other compliance programs (like HIPAA or GDPR). By following PCI DSS, you’re building a solid security foundation for protecting critical data, not just cardholder data.

Adopting PCI DSS requirements improves your organization’s ability to identify, block, and recover from cyber threats. Plus, staying compliant can actually help with insurance requirements, cyber audits, and trust with your customers.

How Huntress Managed SIEM can support PCI DSS efforts

PCI DSS Requirement 10 addresses logging and monitoring access to systems and cardholder data. Huntress Managed SIEM can support this part of a broader PCI DSS program by collecting relevant log data, applying Smart Filtering, retaining searchable security events, and providing SOC-led monitoring, investigation, and reporting.

Standard retention is 12 months, with extended-retention options available for organizations with longer requirements.

Managed SIEM does not independently make an organization PCI DSS compliant. Organizations remain responsible for:

  • Defining their cardholder data environment
  • Implementing required controls
  • Determining which logs and events must be collected
  • Maintaining documentation and evidence
  • Completing required testing and validation
  • Confirming requirements with their acquiring bank, payment brand, or QSA
ChatGPT logoChatGPTOpens in new tabClaude logoClaudeOpens in new tabPerplexity logoPerplexityOpens in new tabGoogle Gemini logoGoogle AIOpens in new tab
On This Page

Frequently asked questions about PCI DSS

PCI DSS compliance means meeting the applicable Payment Card Industry Data Security Standard requirements for an organization’s cardholder data environment and completing the required validation process.

Payment brands and acquiring banks administer PCI DSS programs and determine applicable validation and reporting requirements. A Qualified Security Assessor (QSA) may perform an assessment when required.

Organizations that store, process, or transmit cardholder data may be subject to PCI DSS requirements. Service providers may also be in scope when their services affect the security of cardholder data.

No. PCI DSS requires appropriate logging, monitoring, retention, review, and related security controls. A SIEM is one technology that can help support those activities.

PCI DSS requirements address several practices that can strengthen security, including access control, vulnerability management, secure configuration, encryption, logging, monitoring, and security testing. These practices can reduce risk, but PCI DSS compliance does not guarantee that an organization will prevent every cyberattack.

No. Huntress Managed SIEM can support applicable logging and monitoring activities, but organizations remain responsible for their complete PCI DSS program, including scope definition, control implementation, testing, documentation, and validation.

Additional Resources

Protect What Matters

Secure endpoints, email, and employees with the power of our 24/7 SOC. Try Huntress for free and deploy in minutes to start fighting threats.
Try Huntress for Free