Select Monthly Archives
- March 2019
- February 2019
- January 2019
- December 2018
- November 2018
- August 2018
- July 2018
- May 2018
- March 2018
- February 2018
- December 2017
- November 2017
- September 2017
- August 2017
- June 2017
- May 2017
- March 2017
- February 2017
- January 2017
- December 2016
- November 2016
- October 2016
- September 2016
- August 2016
- July 2016
- March 2016
- October 2015
- September 2015
- July 2015
- May 2015
- March 2015
- February 2015
- January 2015
- December 2014
- September 2014
- August 2014
- July 2014
- June 2014
- December 2013
- September 2012
Filed In: PCI DSS
Written By: Chip Ross February 19, 2019
This is Part 1 in a 4-part series exploring how to ensure readiness for a Payment Card Industry (PCI) assessment, and how to avoid issues that can cause delays and additional costs.
Is There Commitment from Executive Management?
One of the most important ways to ensure that your assessment goes smoothly is to obtain commitment from top-level management that PCI compliance is a priority. An email from the CIO or CISO can go a long way in communicating to the front-line personnel that will be engaged in the assessment that their timely cooperation is necessary for the success of the engagement.
Do I Understand My Classification and Level?
It’s very important to understand exactly where the organization lies regarding PCI validation requirements. Too often, entities do not know their classification and level, and unknown situations present themselves during the audit, which causes delays, and additional expense. The first thing to know is whether you are a Merchant, a Service Provider, or both.
Am I a Merchant or a Service Provider?
From a PCI perspective, any entity that interacts with cardholder data (CHD) is either a Merchant, or a Service Provider. At a high level, a Merchant is an entity that accepts CHD as payment for goods or services, and a Service Provider is an entity that stores, processes or transmits CHD on behalf of another entity, or provides some service which can affect the security of another entity’s CHD. How is it determined whether an entity is a Merchant, or a Service Provider? First, follow the Merchant IDs.
A Merchant obtains a merchant ID (MID) from an acquiring bank, or sometimes a payment processor acting as an acquiring bank, which is used to ensure the Merchant receives the funds, and that the cardholder’s account is billed, for the goods or services purchased. A more generic term for these banks or payment processors is ‘acquirer’, which we will use for the remainder of this article. If an entity ONLY stores, processes or transmits CHD using MIDs that they own, they are a Merchant.
If an entity stores, processes or transmits CHD that isn’t directly attached to their MIDs, they are a Service Provider. It’s important to note that it’s possible for an entity to be both a Merchant and a Service Provider.
As mentioned above, the other way an entity can be a Service Provider is by affecting the security of another entity’s CHD. Examples of this include hosting, managed services, and payment processing.
Why is this important? There are numerous additional PCI requirements that can require significant additional time, resources, and expense for Service Providers. It’s critical for an entity to understand whether any of these requirements need to be assessed, and to be prepared for the effort. It also lets an entity understand who needs to know they are PCI compliant.
There is also a case where an entity called a ‘payment aggregator’ sort of ‘loans’ their MID for a Merchant to use. This situation is not considered here, but is addressed in another blog article: https://www.appsecconsulting.com/blog/payment-aggregation
Who Needs to Know I am Compliant?
As previously discussed, a Merchant obtains their MID from an acquirer. When an acquirer signs an agreement with the card brands allowing them to process charges, part of that contract states that they will ensure that their Merchants are PCI compliant. If it is determined by the brands that an acquirer’s Merchants are not compliant, they can be fined by the card brands.
This means, in most cases, the acquirer is actually the one that is asking a Merchant to validate their PCI compliance status. In fact, in every Merchant’s contract with an acquirer, there is language that states they must be PCI compliant, must validate their PCI compliance. Additionally, the acquirer is allowed to pass on the fines levied by the card brands to non-compliant Merchants.
It’s a little bit different for Service Providers. It’s usually the Service Provider’s clients that are asking them to show that they are PCI compliant. In most cases, the Service Provider doesn’t have a contract with either an acquirer or the card brands. However, if the Service Provider stores, processes or transmits CHD, they are also required to be PCI compliant. The waters are murkier for Service Providers that don’t actually handle CHD. Even if there is no contract with the brands, if a Service Provider is responsible for a security breach involving CHD, they could face significant financial and legal consequences.
We’ve seen many cases where an entity thought they were only a Merchant, but discovered during the assessment that they were also a Service Provider. To avoid this, a detailed examination and understanding of the MIDs involved is required. Examine all agreements with all acquirers, and compile a list of all MIDs. Finance or Accounting personnel can be a helpful resource in compiling that list.
How Many Transactions Am I Handling?
As you can see, it is critical that an entity understands which MIDs it owns, which acquirers issued them, and whether they are handing CHD that is under another entity’s MID. In addition to whether an entity is a Merchant or Service Provider, the number of annual transactions handled by an entity is used to determine what they must do to validate compliance.
The card brands categorize both Merchants and Service Providers by Levels. For both Merchants and Service Providers, an entity with a large number of transactions must validate compliance via an on-site Report on Compliance (ROC). Entities with a smaller number of transactions may validate PCI compliance using a variety of different Self-Assessment Questionnaires (SAQ). More information regarding those levels and available SAQs is available in the blog article: https://www.appsecconsulting.com/blog/pci-101-transaction-volumes-and-validation-requirements
Reporting templates for both of these types of assessments are available at the Council website.
Having this information in advance of any assessment activity helps ensure that the entity employs the appropriate validation methods. If possible, the annual transaction count should be broken down by card brand (Visa, MasterCard, Discover, American Express, JCB) as each brand has slightly different thresholds for self-assessment. Again, Finance or Accounting personnel can be a helpful resource. Additionally, this information may be able to be obtained directly from the acquirer.
While not as common, we have seen engagements that needed change orders, because the entity was actually a different Level than they thought. The more common occurrence is that the entity is not prepared for the correct SAQ.
How Can AppSec Consulting Help?
Our Qualified Security Assessors (QSAs) leverage AppSec Consulting’s proven PCI assessment methodologies. Their many years of security, IT, development, and PCI auditing experience ensures that whatever your goals, the outcome is exactly what you need and makes strategic sense for your business. Whether you’ve been asked by your bank “to comply with PCI”, or preparing for your first validation with a Report on Compliance (ROC), gearing up for annual re-validation, or would just like to know what the PCI DSS mean to your business, our team of experts are there to help.
More information can be found at www.appsecconsulting.com, or call us at 408-224-1110