PCI DSS

Introduction

The Payment Card Industry Data Security Standard (PCI DSS) is a collection of security standards designed to protect cardholder data. PCI DSS applies to all organizations that process, store, or transmit credit card information.

PCI DSS is managed by the Payment Card Industry Security Standards Council (PCI SSC), a group of major credit card companies.

Request a Quote

Penetration-Testing-PCI-DSS

Accorian For Your PCI DSS Compliance

Accorian can assist you with

SCOPING ASSESSMENT
Key step in your PCI journey and it helps you determine your applicable scope with/without inheritance of controls and card flow.

READINESS/GAP ASSESSMENT
Aiding you to understand your current readiness against PCI DSS.

vSECURITY TEAM
Simplifying the requirements of PCI DSS, remediation advisory, evidence collection, program management and augment your team to aid in remediation.

POLICY & PROCEDURE DEVELOPMENT
Aiding you in developing/updating your security framework.

PRE-AUDIT
A readiness audit to ascertain if you meet the PCI requirements.

ASSISTED SAQ FILLING
Aiding you in filling your SAQ.

PCI AUDIT & ROC
Final audit with reporting conducted by a QSA.

PCI ASV SCANNING
As a PCI ASV (Approved Scanning Vendor), we can aid in conducting this mandatory quarterly network scan.

Who Does PCI DSS Apply To?

PCI Compliance

PCI DSS affects all companies that accept or process credit cards and have access to cardholder data (CHD) or sensitive authentication data (SAD) that constitutes account information. It also applies to all service provider companies that accept or process credit cards (directly or indirectly) due to the trickle-down of their Third-Party Risk Management Strategy. Thus, becoming a benchmarking security standard for most organizations. This is regardless of size, number of transactions, or if the information is collected directly or indirectly.

What Data Does PCI DSS Impact?

PCI DSS Impact

PCI DSS Requirements

Organizations must adhere to 12 basic PCI DSS compliance requirements to handle credit card information securely. Failure to comply with these requirements increases the risk of a data breach or other fraudulent behavior at the company:

12 PCI DSS Requirements

What Are The Requirements To Be PCI Compliant?

The requirements are based on the volume of transactions per year. The PCI DSS guide breaks down companies into 4 merchant levels.

The 4 Levels of PCI Compliance

4 Levels of PCI

Merchant Level 1:

Level 1 merchants must undergo an audit by PCI QSA (Qualified Security Assessor) with the need for a more significant number of requirements compared to the other levels. This would generate a PCI RoC (Report on Compliance). This audit report includes findings based on the review of the organization’s current security policies, procedures, and controls being in place for protecting cardholder and account data. The audit also requires an on-site assessment and review of all compensatory controls.

This audit needs to be conducted annually or every time there is a change in the environment.

The number of requirements, implementation, time, cost & rigor required to meet the PCI Level 1 and RoC requirements is high. As this will be assessed by a PCI QSA, you can display the PCI Compliant logo on attaining a passing RoC.

Merchant Levels 2,3,4:

Companies need to submit their SAQ (Self-Assessment Questionnaire) for all these 3 merchant levels. There are 9 types of SAQs, with the number of requirements ranging from 24 to 370.

There are cases in which the non-level 1 merchant has to undergo the PCI RoC audit due to their criticality in the supply chain. This is decided by the acquirer or, sometimes, requested by end clients.

Choosing The Right PCI DSS SAQ

Selecting the right SAQ (Self-Assessment Questionnaire) is key to meeting the PCI DSS requirements applicable to your organization.

PCI DSS

All level 2-4 merchants must complete their SAQ and answer all questions to signify passing or, be able to state specific requirements as “not applicable”. If even a single question is missed by the merchant, he will be considered non-compliant and will be required to address and mitigate the risk immediately.

All SAQs have an expected testing column that provides merchants guidance with descriptions of the testing activity that needs to be performed to indicate compliance with PCI DSS.

Upon completion of the SAQ, an attestation of compliance (AoC) needs to be completed by merchants and is signed by the CISO/officer of the company.

Resources

Article

PCIDSS 4.0 from PCIDSS 3.2.1- Part 1

PCI-DSS stands for Payment Card Industry Data Security Standard. This standard first came into the picture in 2004, and it was formed by Visa, MasterCard, Discover Financial Services, JCB International, and American Express. It is governed by PCI SSC, i.e., Payment Card Industry Security Standards Council. Applicability- PCI-DSS applies to companies/organization which accepts, store, process and/or transmits cardholder data. When will the new version PCIDSS v4.0 take effect? Until March 31, 2024, PCI assessments will choose the version (v3.2.1 or v4.0) for conducting the assessment. After this date, v3.2.1 will be retired, and v4.0 will become the singular standard. PCI-DSS v4.0 New Requirements The new version contains a substantial number of new requirements—64 in total. When using v4.0, only 13 out of 64 are mandatory. Until March 2025 additional 51 remain “best practices”; after the retirement of v3.2.1, it will be mandatory to complete a PCI DSS assessment. Changes in the Security Objective of PCI-DSS v4.0? PCI-DSS v3.2.1 PCI-DSS v4.0 Build and Maintain Secure Network and Systems Build and Maintain Secure Network and Systems Protect Card Holder Data Protect Account Data Maintain a Vulnerability Management Program Maintain a Vulnerability Management Program Implement Strong Access Control Measures Implement Strong Access Control Measures Regularly Monitor and Test Networks Regularly Monitor and Test Networks Maintain an Information Security Policy Maintain an Information Security Policy Change in the Names of 12 PCI-DSS v4.0 Requirements PCI-DSS v3.2.1 PCI-DSS v4.0 Install and maintain a firewall configuration to protect cardholder data Install and maintain Network Security Control Do not use vendor-supplied defaults for system passwords and other security parameters Apply secure configuration to all system components Protect stored cardholder data Protect stored account data Encrypt transmission of cardholder data across open, public networks Protect cardholder data with strong cryptography during transmission over open public networks Use and regularly update anti-virus software or programs Protect all systems and network from malicious software Develop and maintain secure systems and applications Develop and maintain secure systems and software Restrict access to cardholder data by business need to know Restrict access to system components and cardholder data by business need to know Assign a unique ID to each person with computer access Identify users and authenticate access to system component Restrict physical access to cardholder data Restrict physical access to cardholder data Track and monitor all access to network resources and cardholder data Log and monitor all access to system component and cardholder data Regularly test security systems and processes Test security systems and networks regularly Maintain a policy that addresses information security for all personnel Support information security with organizational policies and programs Type of Changes Change Type Description Evolving Requirements This change is to make sure that the standard is up to date with emerging threats, technologies and changes in the Payment industry. Clarification or Guidance Updated wording, explanation, definition, and guidance to increase understanding. Structure or Format Reorganization of content. Two Approaches New flexibility has been provided for organizations to satisfy the PCI DSS security objectives. The two distinct techniques for PCI DSS evaluations that will be permitted under version 4.0 demonstrate this flexibility: Defined Approach- The organization is expected to comply with the stated requirements, and assessors will conduct testing procedures as mentioned within the standard.To fill gaps, compensating controls are implemented. This has been consistent since the release of PCI-DSS v3.0. Customized Approach- There is no written testing procedure to be followed by assessors, and the testing procedure will be developed by the assessor to validate the solution the entity has implemented. This approach is focused on “risk mature...

View More

Article

Adobe's Common Controls Framework of Industry-acclaimed security standards

Today’s world is an ever-changing scenario with changes to the technology sector happening more frequently than ever due to emerging technologies. The case is quite similar in the field of Cyber Security. There are a few industry-acclaimed cybersecurity standards for governing the processes and execution of these standards. These standards are usually built upon a framework of control objectives that need to be implemented by the organizations to comply with these standards. Compliance is measured in terms of control objectives meeting the compliance criteria and also other regulatory and statutory criteria. Since most of these Cybersecurity standards speak of similar control objectives or lay emphasis on similar control areas, it is advisable to have the ‘Adobe’s Common Control Framework’, which means that if we are able to comply with a single requirement from a particular framework, in theory, we should be able to use the adherence of that requirement for ALL the similar frameworks. There are several approaches to achieving this Adobe's Common Controls Framework both in theory and in practice and will be discussed in detail later on in this article. The most relevant security and privacy frameworks are ISO 27001, NIST, PCIDSS, GDPR, SOC Type 2. There is a significant overlap of controls contained in these standards as all of these standards primarily deal with one requirement which is the protection of data. Protection of information from unauthorized disclosure, compromise, and theft forms the backbone or the building blocks of an Adobe's Common Control Framework. This leverages the fact that similar controls or that the essence of the controls is the same across standards and can be used to gauge the adherence or compliance of an organization to the standard. In actual execution, while gauging the compliance of an organization, the Adobe's Common Controls Framework is not only holistic but can reduce the effort and cost otherwise required by the organization to comply with individual standards. There are two methods of developing the Adobe's Common Control Framework for an organization and there are very subtle differences between the two methods. They are Controls harmonization and Controls Mapping. Controls Harmonization: Harmonization is the creation of a brand-new control language set from several source languages of standards taking into consideration content & context. In theory, the intent and meaning of the words and sentences remain intact, but the language and actual words of the individual standards have been changed with a new harmonized meaning defined. To achieve the usage of a single language as an industry, globally, it would have significant benefits and it would be the most efficient way to operate not only as security professionals but also as humans. Adobe’s Common Control Framework is an example of this type of construct. The benefits of having a single operating language can truly be amazing in terms of effort reduction and cost reduction. Control Mapping: Today, most brilliant and forward-thinking security professionals are using the control mapping method. The main idea behind this method is to keep the original language intact as much as possible while mapping and matching the intent and meaning of each sentence and word. This is the most practical and realistic approach because this is how humans fundamentally interact with each other globally. One can see this working in real life where two different languages are being spoken by individuals and kept mainly intact, but an interpreter or linguist is translating between the two — the map is developed in the mind of the linguist. Some real-life examples of mapping for cybersecurity frameworks can be seen in HITRUST Framework, Cloud Security Alliance Framework, and even the U.S. Government formally...

View More

What Our
customers are
saying about us

Read Testimonials

The Accorian Advantage

Accorian’s cybersecurity and compliance teams bring a wealth of experience to help navigate organizations through their information security journey. Our hands-on, white-glove approach combined with a goal-oriented, proven methodology brings both fiscal value and expertise to each of our clients. The facts speak for themselves.

    Ready to Start?

    We are Qualified

    we are qualified
    we are qualified
    we are qualified

      Ready to Start?

      Download Case study

      Download SOC2 Guide

      Human Resources Director

      Posted On: 09 May, 2022

      Drop your CVs to joinourteam@accorian.com

        Interested Position
        First Name
        Last Name
        Email
        Total Experience
        Mobile Number
        Upload Resume
        Cancel