Blog

  • New HIPAA Regulations for 2025

    New HIPAA Regulations for 2025

    Stay Compliant with HIPAA Regulations in 2025
    Since the 1990s, healthcare organizations and their business associates have followed HIPAA regulations to safeguard protected health information (PHI). While the core rules have remained largely unchanged, significant updates to the HIPAA Privacy Rule are scheduled for 2025, potentially adding complexity to compliance efforts.

    (more…)

  • Third-Party Risk Management: How SOC 2 Helps Ensure Vendor Security

    Third-Party Risk Management: How SOC 2 Helps Ensure Vendor Security

    In today’s interconnected business environment, companies increasingly rely on third-party vendors to enhance their operations, streamline services, and improve efficiencies. However, this dependency comes with significant risks. Third-party risk management (TPRM) has become crucial as organizations seek to protect sensitive data and maintain regulatory compliance. One of the most effective frameworks for managing third-party risk is the Service Organization Control 2 (SOC 2) report. In this blog post, we’ll explore how SOC 2 helps ensure vendor security and bolster third-party risk management.

    (more…)

  • PCI DSS v4.0.1: Key Updates You Need to Know

    PCI DSS v4.0.1: Key Updates You Need to Know

    The Payment Card Industry Data Security Standard (PCI DSS) continues to evolve to keep pace with cybersecurity risks and compliance demands. PCI DSS v4.0.1 introduces key updates and refinements designed to make adoption smoother and compliance more practical for organizations handling payment card data.

    Building on the major changes introduced with PCI DSS 4.0 in 2023, such as enhanced flexibility, stronger risk management focus, and clearer security requirements, this latest version addresses feedback and clarifies implementation details. In this blog, we’ll break down the most important PCI DSS v4.0.1 updates and explain what your business needs to know to stay compliant.

    (more…)

  • Mitigating Third-Party JavaScript Tag Risks

    Mitigating Third-Party JavaScript Tag Risks

    RSI Security recently partnered with JScrambler to host the webinar Securing Hospitality: Mitigating Third-Party Tag Risks in a Dynamic Digital Landscape. Our Director of Information Security and Compliance, Mohan Shamachar, hosted and was joined by JScrambler’s Product Marketing Manager, Katia Kupidonova, and Director of Sales Engineering, Jeffrey Cleveland.

    (more…)

  • Breaking Down the PCI Compliance Process

    Breaking Down the PCI Compliance Process

    What is the PCI compliance process?
    The PCI compliance process applies to any organization that receives, processes, or transmits payment card data. It’s designed to protect cardholder information from breaches and reduce fraud by enforcing security controls across people, processes, and technology. Below you’ll find a clear, step-by-step guide to the key PCI DSS requirements and how organizations typically move from assessment to full compliance.

    How Can You Achieve PCI Compliance?

    Although the PCI compliance process broadly applies to all organizations that process card payment data, every organization must define organization-specific approaches to meeting PCI compliance goals. 

    The typical PCI compliance steps include:

    • Understanding basics of PCI DSS
    • Defining PCI DSS scope
    • Completing PCI DSS self-assessment
    • Remediation of PCI DSS vulnerabilities
    • Reporting PCI DSS compliance 

    Achieving PCI compliance is essential for minimizing risks to sensitive card payment data. Working with a PCI compliance specialist can help you navigate the PCI compliance process.

    Step 1: Understanding Basics of the PCI Compliance Process 

    The basics of the PCI compliance process include:

    • The goal of PCI DSS compliance
    • Types of PCI sensitive data
    • PCI Levels

    Understanding key aspects of this process helps simplify PCI compliance steps.

    What is the PCI DSS Framework?

    The PCI Data Security Standards (DSS) guides sensitive data security protections for organizations that process card payments. Broken into six goals and 12 Requirements (see below), the PCI DSS framework outlines best practices for organizations to achieve PCI compliance and secure global card payment transactions.

    The PCI Security Standards Council (SSC)—formed by Founding Members Visa, Mastercard, American Express, Discover, and JCB International—oversees the overall implementation of the PCI compliance process.

    [su_button url=”https://www.rsisecurity.com/request-demo/” target=”blank” style=”flat” size=”11″]Request a Free Consultation[/su_button]

    What is PCI Sensitive Data?

    The PCI DSS stipulates protections for sensitive card payment data, which include:

    • Cardholder data (CHD), broken into:
      • Primary account number (PAN)
      • Cardholder name
      • Service code
      • Expiration date
    • Sensitive authentication data (SAD), broken into:
      • Full magnetic stripe data
      • Card verification code (e.g., CAV2, CVC2, CVV2, CID)
      • Personal identification number (PIN)

    Protecting CHD and SAD is of the utmost importance in the PCI compliance process. Note that aside from the specific subgroup of payment card issuers, SAD storage is explicitly not permitted by merchants in any capacity once it is used to verify cardholder identities.

    computer

    What are the PCI Levels for Merchants?

    A merchant’s PCI Level is dependent on the volume and level of its transactions. PCI Level also determines the PCI compliance process for assessing and reporting compliance (see below). 

    According to Visa’s PCI DSS compliance guide, the four PCI levels (based on merchant transactions processed across all payment channels or global merchants) are:

    • Level 1 – Over 6 million Visa transactions 
    • Level 2 – 1 to 6 million Visa transactions 
    • Level 3 – 20,000 to 1 million Visa transactions
    • Level 4 – Less than 20,000 Visa transactions 

    The breakdown of Levels slightly varies per payment card company but generally follows the same transaction volumes for each of the four. Determining your organization’s PCI Level helps define PCI DSS scope and compliance reporting, simplifying the overall PCI compliance process.

    What are the PCI Levels for Service Providers?

    The PCI Levels for service providers also depend on the volume of transactions for services. Per Mastercard’s compliance guide, the service-provider PCI levels (based on third-party processing and related services) include:

    • Level 1 – 300,000 or more Mastercard transactions annually 
    • Level 2 – 300,000 or fewer Mastercard transactions annually 

    Similar to the guidelines for merchants, the PCI SSC requires service providers to report compliance. Therefore, determining PCI Levels for service providers is essential to the overall PCI compliance process.

    Step 2: Defining DSS Scope for the PCI Compliance Process  

    PCI DSS scope is simply the collection of environments, networks, and processing capabilities that store or interact with CHD in any manner. The DSS Requirements must be adhered to regarding these IT resources and their activities to ensure compliance. To reduce PCI compliance scope, organizations can implement segmentations that contain CHD and similar sensitive data to better secure and manage it.

    PCI DSS implementations and annual reporting necessitates defining your organization’s compliance scope as one of the first PCI compliance steps.

    Personnel and Elements Involved in PCI Sensitive Data Processing

    The PCI compliance process mandates the institution of specific security policies and controls to address all aspects of adherence for the various personnel, entities, and IT resources involved in card payment processing, which oversee:

    • Individuals assigned to various responsibilities and processing points, including:
      • Personnel operating point-of-service terminals
      • Cybersecurity teams
      • Teams managing physical and cloud storage
    •  Environments containing CHD, including:
      • Networks for CHD transmission 
      • Wireless access points
      • Applications used for payment processing, web-hosted or otherwise
      • Systems (e.g., databases for CHD storage)
    • External organizations involved in CHD processing and similar activities, including:
      • Third-party service providers (e.g., cloud storage, encryption)
      • Equipment vendors (e.g., point-of-service terminals, physical servers)
      • Business partners (e.g., partnerships requiring remote access to CHD environments)

    The effectiveness of a PCI compliance process relies on addressing compliance at all stages of card payment processing, especially those with the highest sensitive data exposure risks. 

    Determining which entities, personnel, and IT resources are involved in your organization’s card processing operations helps simplify the PCI compliance steps, especially with the help of a PCI compliance partner.

    What are the PCI DSS Requirements?

    The bulk of guidance required for the PCI compliance process is found in the 12 Requirements of the PCI DSS v3.2.1. Further broken into sub-requirements, the PCI DSS Requirements address all aspects of PCI compliance and are a springboard for protecting CHD and SAD from threat risks. 

    The 12 Requirements of the PCI DSS (categorized by goals) include:

    • Building network and system security
      • R1: Configure firewalls to secure cardholder data
      • R2: Avoid the use of vendor-supplied defaults for security parameters
    • Protecting cardholder data
      • R3: Secure stored cardholder data
      • R4: Encrypt cardholder transmission over open, public networks
    • Managing vulnerabilities
      • R5: Secure systems against malware
      • R6: Protect systems and applications
    • Strengthening access control
      • R7: Implement business need-to-know restrictions for access to cardholder data
      • R8: Limit access to system components via user identification and authentication
      • R9: Control physical access to cardholder data
    • Monitoring and testing networks
      • R10: Monitor access to networks and cardholder data
      • R11: Test security processes and systems
    • Implementing an information security policy
      • R12: Establish an organization-wide information security policy

    Implementing the guidelines stipulated by the PCI DSS Requirements is essential to the PCI compliance process and helps protect CHD and SAD from breach risks.

    third-party-office-man2

    Step 3: Completing a PCI Self-Assessment

    The main goal of completing a self-assessment in the PCI compliance process is to analyze the overall security of CHD processing. A PCI self-assessment also helps identify vulnerability risks and sets the stage for relevant and appropriate remediation efforts.

    PCI DSS Vulnerability Assessment 

    Within the PCI compliance process, vulnerability assessment helps identify cybersecurity gaps in the technologies and processes involved in CHD processing. 

    Common vulnerabilities that pose risks to the security of CHD include:

    • Poorly configured firewalls – Firewalls are critical to preventing the flow of external malicious traffic into secured CHD environments. Flaws in firewall configurations include:
      • Unrestricted connections between the cardholder data environment (CDE) and external unsecured networks
      • Lack of perimeter firewalls to deny access to unauthorized traffic into CDE
      • Limited personal firewall functionality on personal use devices
    • Use of vendor-supplied default passwordsUse of passwords or security parameters provided by vendors during system installation presents security risks. Related access control vulnerabilities include:
      • Lack of industry-accepted hardening standards to address system vulnerabilities
      • Poor management of cryptography protocols for vendor-supplied security parameters
    • Storage of CHD and SADPer PCI DSS Requirement 3, CHD should only be stored under specified conditions and strictly for legal, regulatory, or business reasons. Practices that risk the security of CHD and SAD include: 
      • CHD storage beyond defined retention durations
      • SAD storage in any capacity once cardholder authorization processes are complete (aside from payment card issuers)
    • Unencrypted CHD transmission – Transmission of CHD across open, public networks risks unauthorized exposure. Specific vulnerabilities include:
      • CHD transmission over public networks (e.g., Internet, 802.11 wireless, Bluetooth)
      • Sending unencrypted PANs via end-user technologies (e.g., email, SMS)

    Identifying vulnerabilities that present risks to payment card data security informs vulnerability assessment efforts and ensures optimal PCI compliance.

    Completing a Self-Assessment Questionnaire (SAQ)

    The PCI compliance process requires all PCI-eligible organizations (except those required to submit a Report on Compliance (ROC)) to complete a Self-Assessment Questionnaire (SAQ). 

    SAQs primarily require completing a series of “yes” or “no” questions to assess compliance to each PCI DSS Requirement and consists of two components:

    • Questions to determine PCI DSS compliance
    • Attestation of Compliance (AOC) to confirm compliance self-assessment
      • Per Visa, organizations categorized as Levels 2 and 3 must submit AOCs, whereas Level 4 organizations are only obligated to complete an SAQ.

    Merchants must fill out the appropriate SAQ, depending on the environment used to process CHD. SAQ classification depends on:

    • Provision of third-party card payment services
    • Storage of CHD
    • Presence of card during transactions
    • Type of transaction processed (e.g., e-commerce, mail order telephone order (MOTO))
    • Physical or virtual terminals used for CHD collection

    After completing the SAQ, the next step in the PCI compliance process is verification of the self-assessment by a Qualified Security Assessor (QSA) (see below). 

    However, any vulnerabilities or risks to CHD identified during the self-assessment must be remediated before completing the PCI DSS certification process.

    Step 4: Remediation of PCI Vulnerabilities

    Vulnerability assessment, whether internally (via SAQ completion) or externally (via QSA assessment), can reveal gaps in your organization’s PCI data security. Additionally, the DSS Requirements stipulate that merchants must have an Approved Scanning Vendor (ASV) perform quarterly vulnerability scans. Therefore, vulnerability remediation is critical to the PCI compliance process and helps close security gaps. 

    Your organization can employ commonly used vulnerability remediation techniques to best address PCI security gaps.

    Penetration testing 

    Also known as ethical hacking, penetration testing is one of the best practices for identifying remediable vulnerabilities in PCI data security. Pen-testing helps identify existing and unknown vulnerabilities within an organization’s systems by simulating threat attacks. 

    As part of the PCI compliance process, the PCI DSS requires organizations to implement penetration testing methodologies that address:

    • Coverage of the entire CDE perimeter, including critical systems, applications, and networks
    • Network testing of:
      • Operating system components
      • Network function components 
      • Internal and external networks
    • Application testing to cover commonly exploited vulnerabilities (e.g., web application vulnerabilities)
    • Assessment of threats and vulnerabilities experienced in the last 12 months, ensuring:
      • Pen-testing at least once each year and after changes to the CDE
      • Remediation of vulnerabilities and retesting systems post-remediation
      • Testing of segmentation controls where applicable to protect CDE from external traffic
    • Retention of data from penetration testing 

    Penetration testing helps identify vulnerabilities immediately, preventing materialization into breach risks. Working with a qualified Approved Scanning Vendor (ASV) will help your organization determine best practices for penetration testing in the PCI compliance process.

    Threat Detection and Mitigation

    Threat detection and mitigation supports vulnerability remediation efforts should an attack manage to find and exploit one. Specific tools for threat detection and subsequent mitigation in the PCI compliance process include:

    • Intrusion detection/preventionOngoing monitoring of security threats to the CDE helps inform intrusion detection and prevention. Specifically, intrusion detection and prevention systems must address:
      • Vulnerabilities in firewalls at CDE access points
      • Processes for notifying relevant security personnel of suspected compromises
      • Updated security components for all intrusion detection and prevention engines (including signatures and baselines)
    • Incident response protocols – Timely response and mitigation of threat incidents are critical to protecting CHD and SAD. Incident response protocols must address:
      • Change detection mechanisms that trigger security alerts for any changes to critical files, applications, or systems
      • Comparison of critical files to identify unauthorized modifications
      • Fast and efficient response processes to minimize compromise risks, should a data breach occur

    Robust threat detection and mitigation tools can help your organization address vulnerabilities to PCI data security and simplify the PCI compliance process

    Step 5: Submitting PCI Compliance Reports

    Compliance reporting is the final step of the PCI DSS certification process. PCI DSS reporting must be performed annually to maintain compliance.

    Reporting by PCI Level

    Depending on an organization’s PCI level (see above), certification of compliance requires submission of the completed reporting documentation (i.e., some combination of an SAQ, Attestation of Compliance (AOC), and Report on Compliance (ROC)). A QSA must fill out both AOCs and ROCs; while QSA involvement is not mandatory for SAQ completion, it significantly streamlines reporting efforts.

    The PCI DSS certification process for merchants, based on Visa’s compliance guidance, is as follows:

    • Level 1Required to file a ROC and AOC each year, but not an SAQ.
    • Level 2Required to file an SAQ along with an AOC each year
    • Level 3Required to file an SAQ along with an AOC each year
    • Level 4Required to file just an SAQ each year

    Determining your organization’s PCI Level will ensure completion of the appropriate PCI DSS certification process, especially with the help of an experienced QSA.

    Role of a QSA in PCI DSS Certification

    Working with a leading QSA is critical to a smooth PCI DSS certification process. Essential points to consider for discussions with a QSA include:

    • Specific organization goals and needs 
    • Critical assets involved in processing card payments (e.g., data, systems, applications)
    • Process of completing relevant documentation (e.g., ROC, AOC)
    • Vulnerability assessment and remediation
    • PCI DSS certification process

    With the help of a QSA, your organization will protect CHD from data breaches, which have significant legal, financial, reputational consequences. 

    RSI Security is an experienced QSA and ASV that will guide you throughout the PCI compliance process and help minimize PCI data breach risks. 

    Optimize Compliance Processes, Gain PCI DSS Certification

    The PCI compliance process helps protect CHD and SAD from data breaches and demonstrates your commitment to PCI data security. Virtually all organizations that collect, process, transmit, or store CHD must maintain and demonstrate compliance with the DSS.

    Download Our PCI Compliance Checklist


  • Ethical AI: How NIST AI RMF Supports Ethical Decision-Making

    Ethical AI: How NIST AI RMF Supports Ethical Decision-Making

    Artificial intelligence (AI) has revolutionized various industries, offering unprecedented opportunities for innovation and efficiency. However, the rapid advancements of AI have led to new responsibilities. Ensuring that AI systems make ethical decisions is paramount to their successful and sustainable deployment. This is where the National Institute of Standards and Technology’s (NIST) AI Risk Management Framework (AI RMF) comes into play. The NIST AI RMF is a set of guidelines designed to help organizations manage the risks associated with AI systems, ensuring they are developed and deployed ethically, responsibly, and in a way that promotes trust. Keep reading to explore how the NIST AI RMF helps foster ethical AI practices.

    (more…)

  • How SOC 2 Compliance Benefits SaaS Providers: Enhancing Security, Trust, and Growth

    How SOC 2 Compliance Benefits SaaS Providers: Enhancing Security, Trust, and Growth

    Software-as-a-Service (SaaS) businesses handle sensitive information for their clients, thus ensuring robust security measures is critical. One way SaaS companies can demonstrate their commitment to security is through SOC 2 compliance. SOC 2 (System and Organization Controls 2) is a framework that outlines how organizations should manage customer data based on five “trust service criteria”: security, availability, processing integrity, confidentiality, and privacy. Let’s explore how SOC 2 compliance specifically benefits SaaS providers.

    (more…)

  • What Are The Different Types of IT Security?

    What Are The Different Types of IT Security?

    Since the beginning of the 21st century, the concept of Information Technology (IT) has shifted significantly. To the average person, IT no longer means possessing the capability to simply search the web using keywords, neither does it focus only on clunky desktop computers. With technology’s evolution, IT has expanded to include numerous subsets — from programming to engineering to security to analytics and beyond.

    The “information” aspect includes far more than obtaining sensitive data or protecting it. Systems now possess the capabilities for complex queries, extrapolating data, predicting future events, and even advising officials. This access and wealth of knowledge inevitably led to the expansion of the IT security field. Are you familiar with the basics of cybersecurity? Read on to learn about the different types of IT security and how you can protect your business.

    (more…)

  • The Five Trust Services Criteria of SOC 2: What They Mean for Your Business

    The Five Trust Services Criteria of SOC 2: What They Mean for Your Business

    The System and Organization Controls (SOC) 2 report, developed by the American Institute of CPAs (AICPA), has become a crucial standard for evaluating and demonstrating an organization’s commitment to security, availability, processing integrity, confidentiality, and privacy. These five principles, known as the Five Trust Services Criteria, are the cornerstone of SOC 2 compliance and offer a framework for companies to build and maintain trust with their stakeholders. Keep reading to discover what the Five Trust Services Criteria are and what they mean for your business.

    (more…)

  • Comparing NIST AI RMF with Other AI Risk Management Frameworks

    Comparing NIST AI RMF with Other AI Risk Management Frameworks

    Artificial Intelligence (AI) is transforming industries by enabling more efficient processes, better decision-making, and innovative solutions to complex problems. However, the rapid adoption of AI technologies brings significant risks, including biases, security vulnerabilities, and ethical concerns. To address these challenges, various organizations have developed AI Risk Management Frameworks (RMFs) to help ensure the responsible and secure deployment of AI systems. Among these frameworks, the NIST AI RMF stands out. In this post, we will compare the NIST AI RMF with other prominent AI risk management frameworks to understand their similarities, differences, and unique contributions to AI governance.

    (more…)