Archive for the 'AOC' Category

21
May
19

An Inadvertent Service Provider

A discussion came up on the last PCI Dream Team session regarding situations at universities that have bookstores and cafeterias operated by third parties on their networks and those vendors processing payment card transactions.  QSAs encounter this situation not only at universities and colleges, but also with hospitals, health clinics and large corporations.

The Situation

As organizations focus on customer and employee perks, QSAs encounter third parties operating business outlets within a variety of organizations.  These businesses include coffee shops, convenience stores, dry cleaners, bookstores, restaurants, cafeterias, parking ramps, travel agencies, pharmacies, health clubs and a whole host of other businesses.  Of course, all of these third parties accept payment cards for their services and need a way to process those cards.  Organizations offering these perks have existing wired and wireless infrastructure that get leveraged to connect these third parties to the internet and their payment processors.  Thus, bringing that network and everything attached to that network into scope for PCI compliance.

As a result, this situation creates a PCI compliance problem because the organization is now a service provider as well as a merchant.  The organization thought by outsourcing these businesses it was reducing PCI scope not increasing scope.  But scope increases because since they are now considered a service provider, they must provide each of these third parties with a Service Provider Attestation Of Compliance (AOC) for that network connectivity.

But it can and does get worse.  I have encountered situations where the outsourcing organization provides help desk, firewalls and other support services for these third parties, further complicating their PCI compliance responsibilities.

What Do You Do? Option 1 – Get Out Of Scope

There are some ways to get out of scope, but these can be complex and/or expensive.

The first way to get out of scope is to force all of your third parties to get their own network connectivity from their own internet service provider (ISP).  The problem with this is that an ISP will likely have to run wire into your facilities to make those connections.  That can be disruptive as well as expensive and complicated due to locations within existing buildings.  And what if each business wants their own ISP because of a contract relationship?  That will mean multiple ISPs tearing up your facilities.  Not necessarily the best situation.

The most extreme solution to get out of scope is for the outsourcing organization to implement carrier equipment and become a “carrier” to these third parties.  I have had a few clients go down this road, but it is not cheap and can also be more trouble than it is worth.  However, for a university or large hospital/clinic complex with lots of third parties, this solution can actually be a cheaper route to implement and operate.

But the beauty of these solutions is that your organization is totally out of scope so there are no service provider PCI assessment requirements.

What Do You Do? Option 2 – Reduce Scope

There are also a couple of ways to reduce scope.  But reducing scope requires at a minimum the creation of a Service Provider SAQ D and AOC.

The quickest and easiest way to reduce scope is that the outsourcing organization can implement end-to-end encryption between the third party’s connection and the internet.  However, this adds the requirements in section 4 to the assessment as well as keeps the endpoints in scope for PCI compliance.

Another option to reduce scope is to require these third parties to implement encryption from their operation to anyone outside of the outsourcing organization.  While this seems simple, it usually never is simple.  Never mind the fact that if that encryption is ever stopped (most times without your knowledge), the outsourcing organization’s network is back in scope.  Typically, when this gets brought up as a solution, a lot of the third parties balk or say they do not know how to encrypt their connections.  Never mind the fact of the complexity of proving that the outsourcing organization does not have encryption keys and that every third party connection is encrypted becomes problematic.  It ends up more trouble than it is worth.

The only good news about reduced scope is that you only need to fill out a Service Provider SAQ D and AOC because you have no idea the transaction volumes being processed by any of these third parties.  That said though, it is additional paperwork that needs to be filled out annually and given to all your third parties.

Heaven help you though if you offer firewall, help desk and other support services in addition to connectivity.  Those just complicate your compliance and reporting efforts.  All I can say is, if you can stop offering those services, stop.  If you cannot stop those services, then be prepared to document and report on the PCI compliance of each of those services.  That can be done in a single assessment, but the AOC must cover each of those services provided individually in a separate section 2g.

Never mind the fact that if some of those services offered give your organization insight into the number of transactions processed by your third parties such as you provide payment processing under one or more of your merchant identifiers, you may end up having to conduct a Service Provider Report On Compliance (ROC) because the transaction volume exceeds one of the card brands’ annual service provider transaction volumes.

There you have it on third parties and their payments on your network.

21
Nov
18

Requirement 12.8.2

I got a comment a while back about contracts and PCI compliance.  The two requirements that are relevant in this discuss are 12.8.2 and 12.9.  Requirement 12.8.2 is for all organizations (merchants and service providers) that are being assessed under the PCI DSS.  Requirement 12.9 is only for service providers.

As usual, the clarifications surrounding these requirements were all provided verbally over the years at various PCI Community Meeting presentations and Q&A sessions.  But the overall gist of these requirements can be readily determined.  It just takes a little bit of effort and looking at more than just the PCI DSS.

Requirement 12.8.2 states:

“Maintain a written agreement that includes an acknowledgement that the service providers are responsible for the security of cardholder data the service providers possess or otherwise store, process or transmit on behalf of the customer, or to the extent that they could impact the security of the customer’s cardholder data environment.

Note: The exact wording of an acknowledgement will depend on the agreement between the two parties, the details of the service being provided, and the responsibilities assigned to each party. The acknowledgement does not have to include the exact wording provided in this requirement.”

The Guidance provided for 12.8.2 states:

“The acknowledgement of the service providers evidences their commitment to maintaining proper security of cardholder data that it obtains from its clients. The extent to which the service provider is responsible for the security of cardholder data will depend on the particular service and the agreement between the provider and assessed entity.

In conjunction with Requirement 12.9, this requirement is intended to promote a consistent level of understanding between parties about their applicable PCI DSS responsibilities. For example, the agreement may include the applicable PCI DSS requirements to be maintained as part of the provided service.”

If things are still not clear enough, it helps to look at the ROC Reporting Template to get clarification.  The tests being conducted for a given requirement usually clear up any confusion regarding what is being expected.  There is only one test for 12.8.2 and it states:

“Describe how written agreements for each service provider were observed to include an acknowledgement by service providers that they will maintain all applicable PCI DSS requirements to the extent the service provider handles, has access to, or otherwise stores, processes, or transmits the customer’s cardholder data or sensitive authentication data, or manages the customer’s cardholder data environment on behalf of a customer.”

The first thing to notice in all of these discussions is that nothing in the PCI DSS states that any organization is required to work with a PCI compliant third party.  None of the requirements in 12.8 specify that an Attestation Of Compliance (AOC) be provided.  A lot of QSAs will argue that requirement 12.8.4 requires it, but if you read the test:

“Describe how it was observed that the entity maintains a program to monitor its service providers’ PCI DSS compliance status at least annually.”

There is nothing in that test that explicitly mandates that an AOC is required to monitor third parties.  Granted an AOC is the easiest way to monitor service provider compliance, but there is nothing explicitly calling it out in this test.

So where does this “requirement” originate?  It comes from the merchant agreements with the card brands, specifically Visa and MasterCard.  They require that their merchants only work with third parties that are PCI compliant and can prove that compliance with a Service Provider AOC.  This is why it is important to read and understand the brands’ merchant agreements and their own security programs.  There are a number of key “requirements” that come from those documents that are just as important as what is in the PCI DSS.  So, read them as well as all of the PCI documents.

Getting back to the PCI DSS, what the Council wants QSAs and ISAs to look for in contracts, master service agreements, addendums and any other legal documents that describe the parties’ legal relationship is some sort of acknowledgement between all parties that they will abide by the PCI DSS and ensure that sensitive authentication data (SAD) and cardholder data (CHD) is kept secure.

Where a lot of QSAs/ISAs go wrong is demanding that the words “PCI DSS”, “PCI standards” or other explicit acknowledgement of “PCI” something to appear somewhere in those documents.  The Council has stated a number of times that explicitly using “PCI DSS”, “PCI standards” or “PCI” anything is not required.  It would be great if such documents did, but a lot of legal documents do not because they either predate the PCI DSS or lawyers argue it is not necessary.  That is what led to the Note in both requirements.  The key is the last sentence which explicitly states:

“The acknowledgement does not have to include the exact wording provided in this requirement.”

It is this sentence that the Council always points to and states that this is why explicit statements of PCI or any other direct reference to PCI is not necessary nor required.  My advice is, when in doubt, ask your client’s legal counsel for their legal interpretation of the legal agreements and whether they fell it covers the PCI responsibilities of the parties involved.

That will lead you to the fact that a lot of legal agreements reference the PCI DSS and PCI standards indirectly through language that obligates the parties to follow and comply with “regulatory or other legal requirements”.  The reason this language works is because “other legal requirements” will drag in the card brand legal agreements for taking and processing card payments.  Every card brand has legal agreements for merchants and service providers that explicitly call out that the customer of the brand will maintain PCI compliance for all relevant PCI standards.

Where this discussion becomes problematic is with service providers that do not directly process, store or transmit SAD/CHD such as managed service providers and the like that can affect the security of payments.  That is because they are not directly under the card brands’ legal agreements, so their contracts while using the same “regulatory or other legal requirements” will not necessarily be referencing PCI compliance because they are indirectly involved.  It is in these cases that I rely on getting a PCI AOC from the service provider which then provides the additional assurance that the service provider understands that they need to be PCI compliant.

It is when I cannot obtain an AOC from a service provider that I then explain to my client that this service provider’s environment needs to be assessed as part of their assessment.  Either that or my client needs to find a new PCI compliant service provider.

What a QSA/ISA needs to be looking for in a service provider’s AOC is a couple of things (actually, there are a lot of things, but these are the most important).

First, you need to ensure that the services provided to your client have all been covered by the service provider’s assessment.  Section 2a of the AOC documents the services covered and not covered.  The most common problem found with section 2a is that one or more services used by an organization were not assessed.  If services were not assessed, then you need to notify the service provider and develop a plan of how to handle this situation.

The next thing to review is the locations that were part of the assessment.  It still amazes me the number of AOCs I review where a client’s data center or processing center was not part of the assessment.  It gets worse when you bring this to the attention of the service provider and they get put out or worse, they argue with you over the fact that they must review every facility where a service is conducted.  I am sorry, the PCI SCC and the card brands are the ones that make the rules, I am just the poor assessor that must enforce and live by them.

Finally, you need to review section 2g for all of the services assessed (if they were assessed from section 2a).  Section 2g are a matrix of the 12 PCI DSS sections that explains who is responsible for the various PCI DSS requirements.  From this matrix an organization is to construct their PCI program to fit the controls that they need to implement to be PCI compliant for this service.

There should be a section 2g for every individual service assessed, but in instances where PCI coverage is the same for different services (e.g., SaaS application hosting), you can combine services in section 2g.  However, this is where problems usually are found.  My favorite example of such a problem is the day I found data center co-location and call center services listed in the same matrix.  I am sorry, but those services have very little similarity particularly in PCI controls.  When you encounter this situation, it is usually indicative of a QSAC that does not understand how to deal with service providers and is cutting corners to get the ROC and AOC out the door.  In addition, it also likely indicates a service provider that is just “checking a box” for PCI compliance to placate customers.  But worse is when that service provider is listed on the Visa or MasterCard service provider lists (it is rare, but I have seen it) which then indicates that the brands are also not doing their due diligence in their review of the AOC.

Hopefully, you now better understand requirement 12.8.2.  In a future post I will discuss requirement 12.9.

09
Nov
18

Service Provider To A Service Provider

Another good question from our recent PCI Dream Team session.

“Are service providers to a service provider be required to provide report on compliance (ROC) to the service provider in a private cloud scenario?”

It depends.

The reason it depends is because the answer will depend on whether or not the service provider in question directly processes, stores or transmits sensitive authentication data (SAD) or cardholder data (CHD).  While our session this time was on ‘The Cloud’, the cloud has nothing to do with the answer, so the answer will be the same regardless.

If you are unsure if you are a service provider, read this post.  If you are trying to construct a story that gets your out of scope as a service provider, read this post.

Reporting Requirements

Before we can talk about what a service provider needs to provide to a merchant or another service provider, we need to ensure that everyone understands the PCI reporting requirements.

For any service provider that directly processes, stores or transmits SAD or CHD, if the volume of Visa/MasterCard/Discover transactions is greater than or equal to 300,000, then the service provider must go through a PCI assessment that produces a Service Provider ROC and Attestation Of Compliance (AOC).

For service providers that directly process, store or transmit less than 300K transactions or does not directly process, store or transmit, then that service provider can self-assess using the Service Provider SAQ D and related AOC.

Another key point regarding reporting that needs to be made is that there are differences between the Merchant AOC and the Service Provider AOC.  It is very important that service providers use the Service Provider AOC and not the Merchant AOC.

I still get too many Merchant AOCs from service providers.  Most often this is because these service providers are also merchants and they mistakenly believe their merchant PCI assessment serves as their service provider PCI assessment.  Not so!  These service providers need two assessments.  One that covers their merchant payment processes (usually a very small assessment) and one that covers their service provider processes which is usually the larger of the two.

The first key AOC difference is that the Service Provider AOC has a section 2a that discusses what services were assessed in the assessment and what services were not assessed.  This is important to customers of service providers because it allows them to ensure that all of their services have been assessed in this AOC.  If they have not, then the customer knows to ask the service provider for additional AOCs that cover those services.

The other key AOC difference is section 2g which documents the requirements tested during the assessment for each service assessed from section 2a.  The PCI SSC requires that individual 2g sections be used if the services assessed have different requirements matrices.

Finally, section 2c is also very important to customers as it explains what locations were included in the assessment.  I cannot tell you the number of AOCs I have reviewed from large service providers only to find that the location used to service my client was not part of the service provider’s assessment.  As a result, the AOC has no use to my client in their assessment.

Who Needs What?

Under the PCI rules, a service provider is required to provide their Service Provider AOC to all merchants and other service providers to which they provide services.  Yet time and again as a QSA, I end up in fights with service providers who refuse to provide their AOC to my clients.

This requirement of providing an AOC is all about proper vendor management and ensuring there are no gaps in meeting controls responsibilities.  The Service Provider’s AOC has a matrix in section 2g for each service assessed that explains what requirements the service provider is responsible, what requirements are the customer’s responsibility and those requirements where there is shared responsibility.  Without that matrix, a customer has no way to understand their responsibilities in maintain PCI compliance between themselves and their service providers.

Please notice that nowhere have a I mentioned sending anyone the ROC, only the AOC.  As you will recall, the question involved the sending of the ROC to another service provider.  That is not to say that you cannot send your ROC, it is just not required by the PCI SSC.

As a QSA, I have encountered a few situations where section 2g is not clear enough and have asked a service provider for their ROC to ensure that my client properly sets up their controls to mesh with the service provider’s controls.  If the service provider was unwilling to provide their ROC or even the section needed, I hold a lot of conference calls to clarify the situation.

With that said, if you want your organization listed on either the Visa or MasterCard Global Service Provider lists, you will have to submit your ROC and AOC to those card brands (as well as some money) to get on those lists.  If you are a service provider and can use the Service Provider SAQ D and you want to get listed on either brand’s service provider list, you will have to go through the ROC assessment process.  Visa and MasterCard will only accept a ROC for listing on their sites.

Hopefully you now understand what is required and what is not.

08
Jul
18

Can I Use SSAE 18 SOC 2 Reports? Part 2

In the last post I discussed what the SOC reports are and what, in general, to look for in a SOC 2/3 report.  Now I want to take you through the more detailed analysis of the SOC reporting so that you can understand why it might not give you the result you desire and how to address that fact.

How Do I Analyze The SOC Report?

Based on the testing in the ‘Information Provided by Independent Service Auditor’ section, you are going to need to map that testing into the PCI ROC tests, if they even fit.  I typically use the Prioritized Approach spreadsheet to do this as it provides a way of documenting the requirements covered and a quick dashboard regarding what is covered.

As you reviewed the domains listed under the SOC 3 report, I am sure you thought; “What is not to like?  It looks like most of what I need for PCI is covered.”  But you would be wrong.  You will find after you map the controls from any SOC 2 report that covers all the TSP domains into the Prioritized Approach that the report will likely only cover around 20% to 25% of the PCI DSS requirements.  That is because the level of detail in the SOC tests are just not as detailed as they are in the PCI DSS.  As a result, SOC 2 reporting does not provide the kind of reliance you need to respond to all of the relevant PCI DSS requirements.

For example, while SOC will likely test that password controls are in place, you will be unable to ascertain if the organization enforces seven character or greater password lengths, password complexity, nor if they require passwords to be changed every 90 days or less.  Let alone if the special requirements for vendor password management are enforced.  It is these missing details that create the coverage problems with using the SOC reporting results.

The same can be said for change management.  When tested, the SOC report will likely call out a lot about change management, but not at the level of detail required in the PCI DSS for requirements under 6.4.  You will also find that coverage in requirements 1 and 2 regarding network and server configurations will be lacking in specificity to meet the PCI DSS testing.

Now as a QSA, you have a decision to make.  Can you accept only 20% to 25% of coverage of PCI DSS requirements as being PCI compliant?  I know I cannot.  I need much more to work with before I can get comfortable that a SOC report provides the necessary coverage for PCI compliance.

Now What?

You and your client have expended all this effort and are no closer to the result desired than when this process started.

So, what to do next?

Work with your service providers that provide you SOC reports to include testing that adds the PCI DSS details that are missing.  There will likely be a bit of push back from these service providers because adding testing to their SOC reports will cause the cost of their SOC reports to increase, sometimes significantly.  So be prepared for it.

What you need to do is to have their auditors add the necessary testing details to the description of controls and then have them test that they are in place.  Examples include:

  • Password length, complexity, change frequency and the procedures followed to perform a password reset.
  • Details surrounding privileged and general user management including provisioning, management approvals, users are implemented with least privilege and users are disabled or removed when terminated.
  • Changes tested for segregation of duties between developers and operations, segregation of test, QA and production environments, production data not used for testing, developers do not have unrestricted access to production, test data and accounts removed before applications are promoted to production, changes document impact, they are appropriately authorized, they have been tested, they have been vulnerability assessed and they document backout procedures.
  • If encryption is used to protect data, document the algorithms used, are key custodian agreements in place, are split key processes in place if performing manual key management, indicate if a hardware security module (HSM) is used and are keys changed when their crypto-periods expire or they are believed to be compromised.
  • Document the configuration standards that are followed by device classes such as firewalls, switches, servers and test that they have been implemented.
  • Document that anti-virus is implemented on systems commonly affected by viruses and malware, what the anti-virus solution is that is implemented, the anti-virus solution cannot be disabled and that the anti-virus solution is actively running on all systems it is installed.
  • Document that vulnerability scanning is performed, how often scanning is performed and that vulnerabilities are remediated.
  • Document that penetration testing is performed, how often penetration testing is performed and that findings are remediated.
  • Document that log data is collected from all devices, it is reviewed at least daily and that it contains a date/time stamp, device name, type of log entry and other relevant information.

There are a lot of other areas that could be added to the SOC report, but these are, in my opinion, the bare minimum that need to be added to make the SOC report more relevant for PCI.  I am trying to balance the amount of additional information needed versus the cost of providing it in the SOC report.

By adding all of this will it cover all of the gaps between SOC and PCI?  No.  But it should give your QSA significantly more comfort that the controls in place to meet PCI than what is currently being provided by CPAs.

24
Mar
18

When A Client Refuses To Provide Evidence

As a QSA there are occasions when a client tells you that you cannot be allowed to have copies of evidence.  The most common occurrence is with firewall and intrusion detection/prevention configurations.  But there are odd instances as well for things like software development lifecycle documentation and information security policies where it makes no sense.

As a “recovering” penetration tester, I get some of these requests.  I once got into a financial institution because their network engineer wanted advice on their firewall configuration and posted the configuration on a forum for people to provide advice.  So, people are right to be concerned.  That said, qualified security assessor companies (QSAC) are required to provide a secured storage area for storing client evidence, so it’s not like evidence is stored just anywhere.

To be clear, a QSA is required to obtain evidence that supports their assessment of the PCI DSS requirements.  The reason is for the PCI SSC’s assessor quality management (AQM) process.  The Council has the right to review not only the redacted Report On Compliance (ROC) and Attestation Of Compliance (AOC), but also the evidence that supports the ROC.  This has always been the case under the AQM process, but it has only been recently that the Council has started exercising that right and reviewing samples of evidence.

Regardless of all of these precautions and requirements, there are still those times when a client refuses to provide copies of the evidence.  What is a QSA to do?

The Council has provided QSAs with an option when this situation happens, it sounds simple, but is not always as simple as it appears.

When a client refuses the QSA to leave with the necessary evidence, the QSA must then require the client to securely store the evidence reviewed for a maximum of three years and agree to make that evidence available if the Council pulls their ROC for review under the QSAC’s AQM.

The key to this solution is that they client must store exactly what the QSA reviewed for a period of three years.  In the case of a firewall configuration, the client needs to create a human readable file (i.e., text, PDF, screen shots, etc.) and then store that file securely either on their network, a CD/DVD or even a USB thumb drive.  A lot of clients create an encrypted archive for storing this information which is a very good idea.  I have heard of a few situations where the client misplaced the archive resulting in a finding against the QSAC for not being able to provide the evidence to the PCI SSC for review.

This evidence solution is likely outside of the original contract with the QSA.  As a result, the QSA will have to make an addendum to their original agreement to cover this situation.  Expect a bit of legal work to come up with getting such an agreement and getting the client to agree with it.

But suppose the client refuses the conditions of the addendum.  What then?

This is where the client’s acquiring bank comes into the picture.  A client’s acquiring bank is required to arbitrate such disputes between QSAs and their client.  Whatever the acquiring bank decides, the QSA needs to make sure that they get the decision in writing (e.g., email, letter, etc.) and put that decision in with the rest of their evidence.  A QSA should also write up a brief memo to provide the background of the situation so that anyone going back and reviewing the evidence understands what happened and therefore has some context as to why the bank issued their decision.

There you have it.  Another situation addressed.

26
Aug
17

PCI Compliance And Financial Institutions

I remember being at one of the early PCI Community Meetings and someone from the PCI SSC promised that the PCI DSS would be periodically updated to reflect changing business conditions as well as changing threats.  Here we are more than a decade later, and we have version 3.2 of the DSS, but it has been changed more for changes in threats and very little for business.

Their rationale was that they wanted to minimize the number of compensating control worksheets (CCW) that would be needed for the majority of organizations.  This was in response to v1 of the PCI DSS that required that data encryption keys change annually.  Most large merchants who were participating organizations (PO) complained that it was taking six months to a year or more to encrypt their transaction databases and files.  Requiring annual key changes would leave those databases and files at risk because they would always be in a state of perpetual decryption/encryption.  As a result, almost everyone had a CCW for that requirement.  So, the Council changed the requirement to require the changing of encryption keys when they were believed to be compromised or if one or more persons who know the keys leave the company or change roles.

The reason I bring this up is that I have been dealing with financial institutions and their PCI compliance issues for the last few years.  If there is anything more frustrating, it is trying to apply a standard written for merchants to organizations that are not merchants.  It seems like every time I turn around; a requirement needs a CCW, particularly when concerning requirement 3.4.

I am sure the Council will point to requirement 3.2 as their token change that took into account issuers.  But that does nothing for the other requirements that financial institutions struggle.  The biggest reason a lot of the PCI requirements are a struggle is that financial institutions are in the business of; surprise, surprise; processing, storing and transmitting cardholder data.  That IS their business.  3.2 was a great change for issuers, but a lot of the rest of the PCI DSS is a huge pain for a financial institution without a lot of CCWs and the blessings of the requisite card brand(s).

Let us look at a few requirements where CCWs are needed when assessing an FI.

3.4 Render PAN unreadable anywhere it is stored (including on portable digital media, backup media, and in logs) – this can be very problematic for financial institutions.  The reason is that while they can encrypt or tokenize the data, they also need to decrypt/detokenize it as well.  In a lot of cases, they need to do those operations quickly and very often.  It is not that the FIs do not want to protect the information, it is just that they have some unique issues in meeting PCI requirements.

The best example of this situation is debit cards.  Debit cards must be tied to a demand deposit account (DDA) such as a checking or savings account.  That means somewhere there must be a mapping of the debit card into the core application system.  But to process transactions from the card networks when customers use their cards, the PAN must be decrypted/de-tokenized so that the payment can be approved or declined.  This decryption/de-tokenization process needs to meet a timing standard, so adding to the processing time is usually not an option.  As a result, it is not unusual to find that the PAN to DDA mapping file is not encrypted or tokenized.

6.4.3 Production data (live PANs) are not used for testing or development – when part of your business is all about processing, storing and transmitting sensitive authentication data (SAD) and/or cardholder data (CHD), using a few card brand test accounts like a merchant would use for testing is not going to work.  Particularly when you are testing with one of the card brands to certify your application.  In those instances, the FI and brands are going to demand the use of a large and varied set of PANs to ensure that systems are functioning properly.  The only way to do that is with live data from production.

3.2.1 Do not store the full contents of any track (from the magnetic stripe located on the back of a card, equivalent data contained on a chip, or elsewhere) after authorization

3.2.2 Do not store the card verification code or value (three-digit or four-digit number printed on the front or back of a payment card used to verify card-not-present transactions) after authorization

3.2.3 Do not store the personal identification number (PIN) or the encrypted PIN block after authorization.  – requirement 3.2 addresses that issuers that have a business reason to retain sensitive authentication data (SAD) can retain it.  However, 3.2.1, 3.2.2 and 3.2.3 say that all of this data cannot be stored right after authorization. These requirements then go on to say the QSA must inspect incoming transaction data, log data, databases, etc.  Well, guess what?  The incoming transaction data always has SAD in it of some form because the FI has to authorize the transaction.  As I said earlier, databases can have it because of the speed required to authorize.  This is the FIs’ business, yet the standard does not recognize this fact.

The bottom line is that the PCI DSS does not reflect the realities of financial institutions.  As a result, FIs require numerous CCWs to meet the PCI DSS requirements.  As I stated at the beginning, the Council promised that they would address such issues to make CCWs the exception not the rule.  Well, here we are, and in the FI world CCWs are commonplace.  And as we move forward, it will be FIs that will be the focus of the standard, not merchants.  Merchants will very soon be out of the payment card data business altogether with the exception of their POI.  So, it only makes sense to adapt the PCI DSS to securing FIs.

We have separate PCI DSS and AOC documents for service providers.  Maybe we need separate such documents in addition to revised requirements for financial institutions?

Seems like a good discussion topic to bring up at the upcoming Community Meeting.

24
Mar
17

Service Provider AOCs and Section 2g

It is becoming obvious that there are a lot of QSAs out there did not get the message when v3 of the PCI DSS came out and the new AOC for service providers was introduced.  This has been a big topic at the last few community meetings as well and recently became a big topic with a number of my clients as I continue to see service provider AOCs that are not correct.  I have even mentioned this problem already in a post about service providers, but the problem continues.

As a result, I have decided this is a great time to discuss the problem and get everyone to ensure it is fixed so that we stop the arguments over something that is clearly documented in the service provider AOC form and needs to be done correctly.  Because there is no excuse for messing this up.

Section 2a

Before we get to the actual problem, we need to talk about section 2a in the service provider AOC as it drives the problem.

PCI AOC SP Section 2a

In section 2a of the service provider AOC, a QSA is call out in the ‘Name of service(s) assessed’ and to check every box in the ‘Type of Service(s) assessed’ for every service named as part of the service provider’s PCI assessment.

QSAs seem to be doing very well in checking the appropriate boxes for ‘Type of Service(s) assessed’ on the AOCs that I encounter.  However for the ‘Name of service(s) not assessed’, QSAs seem to not necessarily doing quite as well.  The reason will become obvious when I discuss section 2g.

One important note though.  When checking the ‘Others’ box (or any of the ‘Other’ boxes), please make sure to list ALL the other services that were assessed and NEVER, EVER use “etc” in that explanation.  All the services in the ‘Others’ category MUST BE listed individually and specifically.  Again, this will become obvious as to why when we get to section 2g.

And before we move on, I get questions about cloud services, i.e., SaaS, PaaS and IaaS.  Those are services and should be listed as such in the ‘Name of service(s) assessed’.

Section 2g

PCI AOC SP Section 2g

Notice that shaded ‘Note’ that is in bold and italics that states:

“One table to be completed for each service covered by this AOC. Additional copies of this section are available on the PCI SSC website.”

What this note means is you need to have the same number of section 2g’s as you have named services in section 2a.  And this is where a lot of QSAs and their QA reviewers are going wrong with their service provider AOCs

For example, if you have named five services in 2a, there had better be five pages of 2g filled out.  One for each of those five named services.  By the same token, if you are relying on check boxes under the ‘Type of Service(s) assessed’ section to define the services covered, then you should call those out separately in 2g.

The bottom line though is that, however a QSA breaks things out, there must be multiple 2g sections for each individual service provided.

In some very rare instances there can be some services that might have the same coverages/responsibilities for the requirements in the matrix and those may be combined into one table.  The Council has even said as much in clarifying this form.  However the Council has also been very clear that when combining those services into one 2g section, those services MUST have EXACTLY the same responsibilities and that is where a lot of QSAs get into trouble.  So the recommendation I would make is just do one 2g for every service and stop trying to combine things.

Now the QSAs that I have had discussions (arguments) with over their flawed service provider AOCs always bring up the fact that the AOC Word document is locked and they cannot make changes.  I always point them back to that ‘Note’ in 2g which states:

“Additional copies of this section are available on the PCI SSC website.”

According to the guidance provided by the Council at the Community Meetings, QSAs are to append those additional 2g sections to the end of the AOC.

That said, some of us in the QSA community have unlocked the Word document (NOT approved by the Council) and just copy section 2g and insert it inline in the AOC for the number of services we need sections for and fill them out.

One final note about section 2g.  Please follow the instructions to the letter when filling out the table/matrix for the service.  I cannot tell you the number of those that I encounter where ‘Partial’ or ‘None’ are checked and then there is nothing documented in the ‘Justification’ column.  The instructions are very clear in how you are supposed to fill the ‘Justification’ column out so there is no excuse for leaving it blank.

And for the merchants that have to deal with these service provider AOCs.  It is up to you to police these documents.  If you receive an AOC and it is not properly filled out, it is up to you to point out your concerns to the service provider.  If the service provider does not address your concerns, you have a couple of options at your disposal.

  • Contact the PCI SSC with your concerns at qsa@pcisecuritystandards.org. Document your concern(s) in your email as well as including the AOC in question.
  • If the service provider is listed on either the Visa or MasterCard service provider lists on their respective Web site, you should notify them as well. This is because both of those card brands should have caught this error before listing the service provider on their Web site.  For Visa, go to http://www.visa.com/splisting/learnmore.html and use the appropriate email address for your region under the PCI DSS Validated Service Providers row.  For MasterCard, use the pcireports@mastercard.com email address and as with the Council document your concern(s) in an email as well as including the AOC in question.

By contacting the Council, you will provide the Council feedback that a QSAC is not conducting their assessments for service providers appropriately and that the Council may need to conduct an assessor quality management (AQM) process for that QSAC.

Notifying the card brands will do two things.  It will point out a potential flaw in their service provider listing process that needs to be addressed.  But it could also potentially put the service provider in a different status on the card brands’ lists.

15
Dec
16

The Council Speaks On A Number Of Topics

The Council had a Webinar session for QSAs and ISAs on Thursday, December 15. It was a great session, but at only an hour, there were a lot of questions that went unanswered.  The following were the more notable discussion topics.

Not Tested

The Council got the message and they are working on new wording for the AOCs as well as some guidance for “Not Tested” and how it can be used and not impact PCI compliance.  They expect to have something issued in the first quarter of 2017.

Network Segmentation and Scoping

This was a very hot topic and drew a lot of questions and some useful answers as well as generating a slew of new questions.

We got a definition of “purpose-built controls”.  There really is not any change here in what the Council has told QSAs and ISAs in the past regarding segmentation.  The bottom line is that “purpose-built controls” are those controls that segment one network from another network.  That can be firewall rules, access control lists (ACL) or any other controls that control or limit the communications from one network to another network.  I posed a question regarding encryption such as TLS and IPSec as still being a valid segmentation control, but it did not get answered.  I am assuming that it still is a valid control given the Council’s statement that nothing has changed, but until we have explicit confirmation, that still is an assumption, not a fact.

The Council answered a number of questions regarding whether or not in-scope devices can be on the same network segment as out of scope devices can co-exist.  As usual, we go the “it depends” discussion.  The bottom line is that it depends on the threat presented by the out of scope devices to those in-scope.  If an organization has lax security controls over all of their networks and devices, then I would be hesitant to allow out of scope devices to be on the same network segment as in-scope devices.

One of the most amazing discussions on this topic was an answer given regarding whether or not a device that has only an outbound connection from the cardholder data environment (CDE) can be considered out of scope.  Under the Open PCI Scoping Toolkit, this would be categorized as a 2C system.  The Council started out with their stock answer of “it depends” and then clarified that answer.  The answer given was that while the system would be in scope because it is connected to the CDE, what requirements it would need to comply with would depend on the risk presented by the system to the CDE.  This seemed to give organizations an opportunity to argue a minimization of requirements.  I am sure this will result in a lot of arguments between QSAs, ISAs and their assessees in the future.

As a funny aside, the Council mentioned the “three hop rule” and then feigned ignorance as to where it came from.  As I pointed out in my post, it was from the 2014 Community Meeting in Orlando.

Not-Listed Encryption Solutions

This guidance is a train wreck and just seems to keep getting worse.  The Council gave a lot of answers to questions, but it just seemed like they were digging an ever deeper hole, not filling it in.

The biggest news is that the Non-Listed Encrypted Solution Assessment (NESA) document should be available for review in the first quarter of 2017.

The next biggest news was the Council reconfirming that this is only guidance/recommendations and not some new process that is mandatory.  They even made sure to tell everyone attending that QSAs are NOT to hold up an organization’s ROC/SAQ over not having a NESA for their E2EE solution.  So if an E2EE solution does not have a NESA, then the fallback based on a lack of guidance from the Council is to preform whatever procedures that the merchant’s acquiring bank recommends.

The purpose of this Information Supplement the Council stated was to provide QSAs, merchants, service providers and banks with the Council’s acceptable way to deal with assessing E2EE solutions.  While on its face this statement and rationale makes sense, it does not make sense from the standpoint that the organizations driving the E2EE solutions are the banks and processors that have partnered with the E2EE solution providers.  Given that the banks and processors are the same organizations driving PCI compliance of the merchants that consume those E2EE solutions it seems rather odd that they would be questioning what is acceptable for PCI compliance of their approved E2EE solutions.

At the end of the day, it just seems that this NESA process is a solution looking for a problem and that the only problem the process really solves is getting more E2EE solutions to just finish the NESA and validate as a P2PE solution.

Until the banks and processors get behind the NESA process, I see this effort as dead on arrival.

So it sounds like it will be a busy first quarter for the Council.

The Council stated that the slide deck for this session will be posted to the Portal sometime after the first of the year.

02
Dec
16

Not Tested Clarification

In the November 2016 Assessor Newsletter from the PCI SSC, there is a clarification on what ‘Not Tested’ actually means and implies.  I am sure this will really get some service providers whipped up as it will create some issues with work they perform on behalf of their customers.

The following is taken directly from that newsletter.

“Recently, AQM has received some questions about the impact of using “Not Tested” as a response within a completed ROC. This article is intended to address a few points briefly, with published documentation to follow.

  1. Due to an oversight, the option for “Not Tested” was not included in the summary findings table within the summary overview when that table was introduced with the ROC Reporting Template for use with PCI DSS v3.2. We will publish an errata for the ROC Reporting Template shortly.
  2. Some have asked whether one can have a compliant AOC in instances where “Not Tested” was used. While PCI SSC is not able to comment on matters of compliance, we would direct you to read the verbiage at Part 3 PCI DSS Validation of the Attestation of Compliance below:aoc-part-3

How to achieve “all questions answered affirmatively” is the question. PCI SSC does not consider “Not Tested” to be an affirmative statement. The difference between “Not Tested” and “Not Applicable” is that no testing at all is performed for “Not Tested” whereas for “Not Applicable” some testing is performed to confirm a given control is truly not applicable. As such, between “Not Tested” and “Not Applicable,” only “Not Applicable” can be considered an affirmative response.

The intent in introducing “Not Tested” was to achieve a better level of transparency as to the level of compliance and this clarification supports that intent. If you have questions or suggestions, please reach out to the QSA Program Manager.”

It is that second to the last paragraph that will likely send most people off of the deep end.  Their comment that the “PCI SSC does not consider “Not Tested” to be an affirmative statement” really got me going.  What exactly then was the point of using ‘Not Tested’ if you did not consider it an affirmative statement?  Which by the way, when using affirmative as an adjective, means “asserting the truth, validity, or fact of something.”  Last I checked, ‘Not Tested’ would be considered a truth or fact.

There are a number of options for the Council to take here.

  1. Change the wording in the ‘Compliant’ box in Part 3 to reflect that an entity is compliant with all of the requirements tested.
  2. Give us a box in Part 3 that says ‘Compliant with Exceptions’ or something of that ilk which would allow those entities not testing certain requirements to still be judged compliant with what was tested.
  3. Tell QSAs that an AOC cannot be filled out for assessments that mark any requirements as ‘Not Tested’ because an AOC is not relevant.

I remember at a number of past Community Meetings various Council representatives repeatedly and emphatically told those of us from the Accounting community that PCI assessments were not SAS 70 (now SSAE 16) engagements when we would invoke SAS 70 like rules for sampling, testing and the like.  Well, I hate to say it, but the Council is sure turning them into one with all of these pronouncements.

UPDATE: On the Council’s Webinar on Thursday, December 15, it was announced that the Council will be making changes to the AOC and will issue new guidance on this topic sometime in the first Quarter of 2017.  So stay tuned for an update.

UPDATE: From the January 2017 Assessor Newsletter.

Update on use of “Not Tested” with PCI DSS

In the November 2016 Assessor Newsletter, PCI SSC addressed the use of “Not Tested” in PCI DSS and the resulting impact on the Attestation on Compliance (AoC). The article included no change in intent, but rather acknowledgment of existing confusion. PCI SSC recognizes the challenges that the clarification on “NotTested” highlighted and is working internally on providing further documentation to support assessors in addressing such cases.

PCI SSC cannot comment on matters of compliance, as those decisions – as always – are business decisions that should be made by the assessor with the payment card brands and/or acquirers. The article ‘Clarification – “Not Tested” use in PCI DSS’ was never intended to change this, and assessors should continue to work with these entities as they have since the “Not Tested” designation was introduced.

Please note that FAQ 1331 “Can SAQ eligibility criteria be used for determining applicability of PCI DSS requirements for onsite assessments?” has been updated this month to better support the intended use of the “Not Tested” and “Not Applicable” findings.”

The bottom line is that “Not Tested” cannot be a response to any requirement and then expect to have a compliant ROC/SAQ and resulting AOC.

18
Jul
16

Third Party Service Provider PCI Compliance

This has recently become a very hot topic as more and more businesses get serious about controlling their supply chains not only for PCI but for information security in general.  It has only taken three years after the Target breach for organizations to really understand that their computer systems and networks are all part of a larger technology ecosystem and that their security depends on the security of everyone else they are connected.  This post provides guidance for service providers and merchants alike.

The first question that can come up is what is the difference between a third party and a service provider?  Technically there is no difference.  “Third party” is a term that comes from the financial audit industry which is where I first encountered it a long time ago.  Third parties are those outside organizations that provide services under contract to another organization.  Examples can include services such as office cleaning, facility management, mailroom management, lock box services, secure document destruction, human resources and a whole host of other business services.

In today’s complex corporate structures, functions such as information technology or human resources as well as whole business units can be separate legal entities and provide business services to other parts of the corporation.  While not truly outside organizations, for regulatory assessments they may also be treated as third party organizations.  I have a number of large clients that take this approach because it simplifies their audit/assessment and compliance reporting processes.  However if a merchant or service provider is going to take such an approach, it should be discussed with their acquiring bank and/or the card brands to obtain their formal approval before assessing and reporting under that approach.

What Organizations Are Service Providers?

The next question that comes up is what organizations qualify as a third party service provider under PCI?  The PCI SSC defines a service provider in the PCI DSS Glossary as:

“Business entity that is not a payment brand, directly involved in the processing, storage, or transmission of cardholder data on behalf of another entity. This also includes companies that provide services that control or could impact the security of cardholder data. Examples include managed service providers that provide managed firewalls, IDS and other services as well as hosting providers and other entities. If an entity provides a service that involves only the provision of public network access—such as a telecommunications company providing just the communication link—the entity would not be considered a service provider for that service (although they may be considered a service provider for other services).”

Under that definition any third party organization that directly processes, stores or transmits sensitive authentication data (SAD) or cardholder data (CHD) are service providers.  Examples of these organizations are transaction gateways, transaction processors and some loyalty program providers.  One notable exception is acquiring banks.  Acquiring banks are only third parties if they provide services in addition to being an acquiring bank such as card terminal management and transaction processing.

Where things get messy is third party service providers that do not directly come into contact with SAD or CHD but could come into contact with it.  While I have written two posts on this topic, there still seem to be a lot of managed service providers in denial over whether they need to be PCI compliant.  The bottom line is that if you are a service provider and you could impact the security of SAD/CHD, you must comply with the PCI standard (see PCI SSC FAQ 1092).

But that is where complaints and arguments from such peripheral service providers focus.  Most have no idea if their customers need PCI compliance unless they ask or get asked by a customer.  As a result, they tend to argue that because they do not know they do not need to comply.  Unfortunately, ignorance and/or lack of knowledge are not a valid reason to not be PCI compliant.  That is why it is incumbent for all service providers to ask every customer and prospective customer if they require PCI, HIPAA, GLBA or any other regulatory compliance so that the service provider can ensure that they can properly comply with those requirements.

Service Provider Levels Explained

Service providers, like merchants, are categorized into levels by the card brands.  The most commonly referenced service provider levels are those defined by Visa, MasterCard and Discover.

  • Level 1 service providers conduct 300,000+ transactions annually on behalf of their customers, and
  • Level 2 service providers conduct less than 300,000 transactions annually for their customers.

JCB and American Express have their own service provider level definitions, but there are very, very few service providers that only process exclusively for those brands.  If you are one of those rare service providers, I would tell you to visit the appropriate brand’s Web site and review their service provider level definitions.

Level 1 service providers must conduct a PCI assessment that results in a service provider Report On Compliance (ROC) and related Attestation Of Compliance (AOC).  That assessment can be conducted by a QSA or an ISA just as with merchant PCI ROCs.  Level 2 service providers can use either the service provider SAQ D or create a service provider ROC.

These levels also add confusion to those service providers that do not process or transmit any transactions.  As they rightfully point out, their transaction volume is zero.  I then point out to them that zero is less than 300,000, so they are considered a Level 2 service provider.  Problem and confusion solved.

The most important thing to understand about service provider levels are that if your organization is a service provider level 1 for any card brand, your organization is a level 1 for all card brands.

The next important thing to note about these assessment processes is that they must use the service provider specific SAQ D, ROC and AOC forms.  I cannot tell you the number of times I have gotten a service provider’s AOC and/or SAQ/ROC and it is not the service provider specific version.  More on this topic later.

The Global Registries

Once we get these third parties to admit they are in scope for PCI compliance, the next issue that typically comes up is in regards to the card brand global registries for service providers.  Both Visa and MasterCard have public registries of service providers on their respective Web sites.  These are strictly marketing schemes run by the respective brands and it is not mandatory that service providers be listed on either of these lists.  Since they are marketing schemes, they have no real meaning regarding any merchant organization’s PCI compliance and are not a substitute for getting an AOC from a service provider.  What they do provide is a quick way for merchants to find PCI compliant service providers providing services they wish to outsource.  As a result, a lot of service providers like to be listed on these Web sites just so that merchants will consider them.

To be listed on either of these Web sites, the service provider must have a PCI QSA (an ISA cannot be used) conduct an assessment and then the QSA must file the resulting compliant ROC and AOC with the appropriate card brand.  In the case of service providers that process or transmit SAD/CHD, they will have a relationship with a bank that must sponsor the service provider with the brands to get listed on the Web site.  For service providers that do not have a relationship with a bank because they do not process or transmit SAD/CHD, those service providers must contact the appropriate card brand who will then sponsor them.  Once approved by the brand, the service provider then pays a fee to be listed.  To stay listed on the brands Web site, the service provider must annually revalidate their compliance using a QSA, have the QSA file their compliant ROC/AOC with the brand and pay a renewal fee.

To add confusion for service providers, Visa also maintains a separate, private inventory of service providers.  This list is for Visa and their acquiring banks to reference and is not available to the public.  Visa is trying to ensure that all service providers are tracked for their annual PCI compliance even if they do not register for their public Global Registry.  So if you are a service provider and are filing a service provider SAQ D/ROC or you do not register for the public Global Registry, you will be asked to fill out information for this private Visa service provider inventory.

Service Provider AOC Issues

The most common AOC problem we encounter with service providers is that they only assess some of their services provided, not all of their services.  For third party run data centers the most common requirements assessed are requirements 9 (physical security) and 12 (policies) but no other requirements are assessed even if that same firm provides managed services such as network security, network monitoring, virtualization, server management and network management.  I will address this situation later on in the post when discussing service providers that do not have a PCI assessment.

The next most common problem is that the AOC provided to the merchant is not a service provider AOC.  The biggest problem this mistake creates is that there is no way to know what services provided to the merchant were assessed for PCI compliance.  Then you have a very embarrassing conversation for all involved as you inform the service provider that their PCI compliance is reported on the wrong form(s).  Worse is the fact that most times this results in a whole new assessment being conducted because service provider requirements were not assessed and too much time (i.e., more than 90 days) has passed since the assessment was completed.

With the introduction of v3 of the PCI DSS, the service provider AOC has had a number of changes to facilitate merchants’ evaluation of the service provider’s PCI compliance.  The first change was to list not only what services were assessed in section 2a, but what services were not assessed.  Then for each service that was assessed, the QSA/ISA is required to individually document in separate sections of 2g of the AOC which of the 12 requirements were tested for each service.

Which brings us to the third most common problem.  The AOC does not document each service individually in section 2g.  As I stated earlier, this was a change with v3, but many QSAs/ISAs did follow the instructions in the section.  In addition, the Council has not helped this situation as the AOC document is locked so adding additional sections for 2g are not possible using the Council’s form.  The Council’s advice is to copy that section and then paste additional sections as necessary to the end of the AOC.

Another situation that we occasionally run into is service providers that have gone through the PCI assessment process but refuse to provide their customers with a copy of their AOC.  Reasons for not providing the AOC vary (from the stupid to the absolutely idiotic), but it happens more often than I would like to admit.  The PCI SSC has repeatedly reinforced at their Community Meetings and in FAQs that if a service provider has been independently assessed, they must provide their service provider AOC to their customers.  If you encounter such a situation, I would recommend contacting the appropriate card brands and complaining to them about the service provider particularly if that service provider is listed on the card brands’ public Global Registry.  In most cases, such complaints will result in the brand suspending the service provider’s listing until they comply.

The last problem we encounter with AOCs is their timing and availability.  In a perfect world, every service provider would have an AOC less than a year old available for every customer.  But in the real world, a merchant conducting their assessment encounters service providers that either: (a) are also in the process of conducting their assessment, (b) had their assessment delayed and will not be able to provide an AOC by the time the merchant’s assessment is completed, or (c) does not have an AOC.

The first two conditions are timing issues and should not be a problem unless the service provider has not been compliant in the past.  As the Council has repeatedly pointed out, no organization’s PCI compliance is affected by the PCI compliance of any other organization.  In addition, the Council has also said that the PCI assessment process are not conducted to the standard of an AICPA SSAE 16 assessment which needs reliance on third party assessments.  As a result, you need to work with your QSA/ISA, bank and service providers to agree to an approach to handling these first two conditions.  My recommendation is as long as there is close to a year between assessments (give or take 30 to 60 days), I would accept whatever current AOC is available from the service provider.  For situations where there is going to be significant differences in time, I would consult with your acquiring bank or the card brands.

It is the third condition that creates the most heartburn for a merchant and the service provider.  In this situation, a merchant has no choice but to include that service provider as part of the scope of their PCI assessment (see PCI SSC FAQs 1065 and 1290).  Most of the time, this is covered under the service provider’s contract under a section regarding regulatory and legal compliance audits and assessments.  The service provider agrees to allow the merchant’s staff or authorized representatives to conduct any audits/assessments whenever required.  In very rare situations, I have encountered older contracts that do not have such audit/assessment provisions and it becomes a painful issue to get the service provider to comply with the assessment process.

However, this third condition creates a larger scope and will result in increased costs for a merchant’s PCI assessment.  Sometimes that increase can be extremely significant if the service provider is doing a substantial amount of the work that needs to be evaluated such as hosting and managing a merchant’s IT environment.  While QSAs try to minimize the occurrence of this sort of situation when scoping engagements, they still encounter it as the merchant is confused and does not understand the implication of their decision to use a non-PCI compliant service provider and their responsibilities under the PCI DSS and their Merchant Agreement.  As a result, the QSA does not get accurate answers to their scoping questions and does not find out about the service provider’s involvement until they are performing the assessment.

Non-PCI Compliant Service Providers

Before discussing this, I first need to dispel a myth.  Nowhere does the PCI DSS require a merchant to use only PCI compliant service providers (see PCI SSC FAQ 1312).  That is a requirement specified by certain card brands in their Merchant Agreements (most notably Visa and MasterCard).  Therefore not using PCI compliant service providers does not and should not result in a PCI compliance issue provided they are assessed as part of the merchant’s assessment as stated earlier.

Getting back to the topic at hand.  As an example, you have a service provider AOC and it says that section 8 is not compliant (with the latest changes in v3.2 for service providers, this is a situation that is becoming more and more common.)  As a merchant, what do you do?

This is where requirements 12.8 and 12.9 come into play as part of an organization’s vendor management process.  As part of your organization’s vendor management process you should have the following processes, at a minimum, in place.

  • Have a complete inventory of service providers including the date of their last AOC, expected receipt date of their next AOC, and whether the current AOC was PCI compliant. If not PCI compliant, it should note for each service provider those areas of non-compliance and the dates each area will be compliant.
  • For any non-PCI compliant service providers, periodic meetings need to be held with the non-compliant service provider to obtain updates on their remediation efforts. Depending on the duration and complexity of the project(s), these meetings may be conducted quarterly, monthly or even weekly.  However notes need to be kept for all of these calls and information updated as to the project(s) status.  These updates should not be suspended until the service provider is judged PCI compliant.
  • Any adverse changes in remediation efforts status should result in a review of the service provider and possibly result in seeking a new PCI compliant service provider.
  • To be judged compliant, the service provider must have a QSA/ISA submit proof (for example, a letter outlining evaluation procedures followed with a revised AOC) that they have evaluated the remediation efforts and that those efforts are complete and the PCI requirements in question have been judged PCI compliant.

The most important take away in this whole discussion regarding non-PCI compliant service providers is that it does not affect the PCI compliance of the organization using the service provider.  That said, anyone following such procedures outlines above should be prepared to provide their acquiring bank and/or card brands with proof of all of these monitoring activities.

As with all topics related to PCI compliance, this one is no different and there will be nuances to all of these discussions.  But hopefully you now understand all of the basics regarding third party service providers.




Announcements

If you are posting a comment, be patient, as the comments will not be published until they are approved.

If your organization has a PCI opportunity, is in need of assistance with a PCI issue or if you would like the PCI Guru to speak at your meeting, you can contact the PCI Guru at pciguru AT gmail DOT com.

I do allow vendors to post potential solutions in response to issues that I bring up in posts. However, the PCI Guru does not endorse any specific products, so "Caveat Emptor" - let the buyer beware. Also, if I feel that the response is too "sales-ee", I reserve the right to edit or not even authorize the response.

Calendar

June 2021
M T W T F S S
 123456
78910111213
14151617181920
21222324252627
282930  

Enter your email address to subscribe to the PCI Guru blog and receive notifications of new posts by email.

Join 2,386 other followers