PKF AvantEdge

Tag: iata (Page 2 of 2)

PCI-DSS IATA: Dissecting the New FAQs

July 13, 2017 / / 0 Comments

A few significant things occurred this week for the IATA PCI-DSS Program, summarised below:

a) We finally have a very clear way forward thanks to some clarifications direct from IATA, and in some parts due to our dogged persistence to get some answers

b) The new FAQs were published end of June and an updated version was done yesterday (11 July) and is now online at http://www.iata.org/services/finance/Documents/pci-dss-faqs.pdf

Firstly, the significant news.

IATA confirmed that Level 3 and Level 4 Merchants do not need a QSA to signoff their AoC/SAQ – which, to many agents, means they can do SAQ on their own, or using their own IT resources, or external consultants (not necessarily QSA, but if you prefer a QSA, by all means, go for it)

IATA also confirmed that they are considering exemptions for agencies that do not have any credit card transactions in their business channels.

These two clarifications address some long running questions agencies had for PCI-DSS. Do they need external consultants, do they need a QSA, do they need any compliance even if they don’t have credit card, etc etc.

Regarding point b) above, there was a quick iteration on the FAQs to clarify a few items. So here are some of the changes between the newest FAQ on 11 July and the one on the 29 June, and we can go through it.

The first 4 FAQ questions remain more or less the same although we do have a nitpick on 1, which is

FAQ#1 Who do I approach for PCI DSS compliance?
We suggest that you contact your acquirer.

Technically, this is correct, however, it’s not exactly complete. Because their (travel agents) acquirer wouldn’t have visibility over the agencies’ channel of credit card via GDS and BSP (or soon to be NGI – the new gen ISS). Acquirers have no idea of this because when the agents uses GDS credit card facility, they are doing in BEHALF of airlines! So even if they were to correspond with the payment brands directly as per FAQ#3, the brands wouldn’t know, nor care about the agency. Because in the GDS-BSP channel, the agency is not the merchant – it is the airline. (lightbulb).

Therefore, it must be the airlines who must be PCI compliant in that channel – however, because they make use of agents, the agents end up having to be compliant as well. But the airlines don’t deal directly with agents for this channel – they have an aggregator in between the agencies and airlines. And yes, this aggregator, this glue that holds everything together is the ecosystem of GDS-BSP/NGI. So if the agency connects to BSP, IATA is the ‘service provider’ offering this service – therefore, it is IATA that needs to clarify the requirements. Which they are doing – so technically FAQ 1 should read

FAQ#1 Who do I approach for PCI DSS compliance?
Yo, it’s us, man! That’s why you’re reading this on an IATA page!

In our clarification request, we didn’t point this out to IATA because our email at that point was already too long. It’s like we were writing the Titanic of emails, and we had to cut some scenes to fit into a readable email size.

Next, FAQ #6 is also important. Only for our own selfish self satisfaction.

FAQ #6 Are compliance certificates recognized for PCI DSS validation?
The answer to this question is no. Any sort of documentation which is not under the authority and validation of PCI DSS, will not be accepted for indicating the company’s compliance with PCI DSS.

And this is what we have been telling clients for YEARS. There is literally no such thing as a certification of compliance as far as PCI is concerned. Yet, everyone wants to see your ‘certificate’ and even go as far as to reject the AoC and RoC and SAQ documents. There is NO SUCH THING as a PCI-DSS compliance certificate. If someone prints a certificate out for you, it cannot bear any logo from the PCI-DSS council because it is not part of PCI. It’s a nice piece of paper to put up in your lobby but that’s it. When we work with our principal QSA, they also have this “certificate”, but we always make it clear that this is only issued as an aesthetic by the QSA and not considered acceptable to the PCI-DSS program formally. You MUST have the AoC and RoC/SAQ combination of documents at least – and also whatever ASV scans etc you might have. So, we would suggest not to go about calling yourself PCI-certified agency – just say you are compliant to PCI is enough. It sounds less sexy but those are more accurate terms to use.

FAQ#7 was corrected to refer to Question 14, instead of Question 13 as previous FAQ stated. Innocent error, of course, no harm done. It doesn’t mean that the writer of the FAQ can’t count.

FAQ#8 was also corrected whereby the previous FAQ stated (emphasis ours)

“The latter has to be completed as a declaration of the results of the service provider’s assessment with the Payment Card Industry Data Security Standard Requirements and Security Assessment Procedures (PCI DSS).”

and now correctly states

The latter has to be completed as a declaration of the results of the merchant (or travel agencies)’s assessment with the Payment Card Industry Data Security Standard Requirements and Security Assessment Procedures (PCI DSS).

Because technically, travel agents are merchants not service provider, so it might be just a copy and paste error.

FAQ#11 Can a QSA that is not listed in a specific country but listed in another country conduct a certification process in the non-listed country?

Originally it stated

“Yes. By definition, Qualified Security Assessor (QSA) companies are independent security organizations that have been qualified by the PCI Security Standards Council to validate an entity’s adherence to PCI DSS.”

This might not be exactly accurate as there are certain regional restrictions based on fees. So, the change became

“Overall speaking, yes. Nevertheless it should be noted that under the QSA program guide, section 6.3.1, there are qualified regions in which QSA can or cannot perform in as noted “QSA Companies are authorized to perform PCI DSS Assessments and QSA-related duties only in the geographic region(s) or country(s) for which they have paid the regional or country fees, and as indicated on the QSA List.”

Once again, that’s more accurate. And there are more words. And it has a quote from an official document from PCI, so it sounds very important.

FAQ#14 has the big change in the new FAQ version compared to the one in June, whereby under level 2 merchant column we have this “note” to clarify that level 2 merchants under Mastercard requires either an onsite ISA or onsite QSA to validate their SAQ. This is what we call “Validated SAQ”, and this is what Mastercard was telling us earlier, that this must be done by the QSA onsite (if they do not have an ISA – which is “internal security assessor”, which is as rare as an albino beluga whale).

FAQ#18 is the one applying to agencies without any credit card transactions. Now you do need to be careful. IATA does state that PCI applies to agencies processing credit card with the IATA GDS-BSP channel or any other channel (including your acquiring bank direct channel). This means if you have an EDC or POS device, or do internet transactions, you STILL need to undergo PCI-DSS. Who you send your AoC/SAQ to is another story, because IATA wouldn’t know much about your POS/EDC channel since you are not their merchant. Technically you send it to whoever you have a merchant account with – your acquirer. But again, your acquirer isn’t even asking for it! So. We suggest that you still do it, and keep it in case someone asks for it. We hear some cynical snorts in the background but we are going to ignore it. Be nice.

FAQ#23 – they decided to completely change this one. The previous answer seemed slightly confusing and in contradiction to FAQ#6 and FAQ#14. Previous FAQ in end June stated:

It should be noted that the third party should be authorized by the PCI DSS Council as a Qualified Security Assessor (QSA) to accept the PCI DSS compliance certificate. The scope shall cover the BSP card sale transactions.

a) Again, as FAQ#6 already confirmed – there is no such thing as a compliance certificate, so technically all compliance certificates issued by whoever, whether QSA, ISA, consultant or the Queen of England should not be accepted as formal documentation of PCI. One more time we hear this certificate of compliance being bandied around like its some sort of Ark of the Covenant, we are going to collectively walk out of our office and lie down on the main road in silent protest.

b) It’s sounds slightly confusing because it seems that this statement is saying a QSA is needed to be involved for all merchant level compliance as well which is contradicting FAQ#14.

To give them credit, their explanation to this was:

“We have had instances in which the agent was providing us with some sort of certificate issued by a third party, under the assumption that the certificate was issued by a QSA therefore we wanted to make clear that in the case an agent were to go this way they should be checking out the authorized QSA list available in PCI DSS council site.”

Yes, completely agreed. But not the certificate part. D@mn it, that’s it! We are headed out tomorrow and lying down on the street in protest!! Watch the news!

Anyways, now the current FAQ#23 reads a different:

Because most large merchants have complex IT environments, many hire a QSA to glean their specialized value for on-site security assessments required by PCI DSS. The QSA also makes it easier to develop and get approval for a compensating control. However, for Level 3 and Level 4, PCI DSS provides the option of doing an internal assessment with an officer sign-off if your acquirer and/or merchant bank agrees. Mid-sized and smaller merchants may use the Self-Assessment Questionnaire found on the PCI SSC Web site to assess themselves.

If this sounds familiar, it’s because it is. It’s lifted from Myth 6 in the famous PCI document at https://www.pcisecuritystandards.org/pdfs/pciscc_ten_common_myths.pdf

It’s certainly reads better, although, it doesn’t really answer the FAQ#23’s questions, but hey who cares? It makes sense!

So anyway, from this we learnt a few things

a) IATA is really keen to be on the ball on this PCI-DSS compliance and has put in effort in getting the right information out to the agencies – kudos to them and really impressed with their management’s response to queries.

b) The industry as a whole is still grappling a lot on PCI-DSS and needs to move forward with the right information and decision.

c) As QSAs, consultants, auditors, advisors or IT experts, we all need to work together to get our clients up to speed with the right information so they can make decisions and we can assist them.

PCI-DSS is never easy. Even those doing SAQ A-EP are having headaches, what more agents going through SAQ D-MER and all its 340++ questions. IATA seems to understand that and has PCI on their agenda.  We are willing to work with anyone on this – we have our clients who are travel agencies, but we also want to help other agencies get up to speed with PCI, what is required, and how to get compliant from the different validation requirements per PCI’s standpoint.

So to summarise this long winded post, from the horses’ mouth themselves:

a) There is no need for QSA involvement in Level 3 and level 4 merchant self assessment questionnaire (SAQ). Merchant officer signoff on section 3b is enough. However (and this is our opinion) if you can get assistance from QSA, ISA, consultants, IT experts, auditors,the Queen of England or even your own internal IT person familiar with PCI, go for it. You’ll need all the help you can get.

b) For those without credit card transactions in ALL channels (not just IATA), consider the exemption in FAQ#18. But please contact IATA on this as you should truly understand what might be the consequences in the future.

OK, that’s it for now. Drop us a note at pcidss@pkfmalaysia.com. We are preparing a complimentary talk on PCI-DSS specific to this travel agency industry soon, so stay tuned!

IATA PCI-DSS: What Exactly is Required?

May 30, 2017 / / 2 Comments

pci-compliance

Continuing our series on Merchant program for PCI-DSS. Why this is (or will be) so important is that in around 12 – 15 months, if you are a merchant, very likely you will be getting a call from your acquirer.

About 2 months back, Mastercard announced that all acquirers must have in place a risk assessment program for Level 4 merchants by March 31, 2019. This basically means that there is a great concern that 99% of Level 4 merchants out there are blissfully unaware of this PCI-DSS nonsense they need to comply. It is the acquirer’s duty, but the pain starts all the way at the merchants.

One industry feeling the pinch here is the travel industry. But don’t worry, travel agents, soon, the other industries like your cousins at the hotels and hospitality will be going through the same process as you are going through now. It’s just who is going through first. And the faster you get through the better.

Travel agents across the world has been mandated by IATA to be PCI compliant. Please read our previous post here.

We have gone through the requirements in that post, but we’ve been hearing a lot of things coming to us from the travel agencies recently, namely:

a) All Travel Agents need to engage a QSA to formally sign off their SAQ.

IATA should be able to give a formal statement on this. QSAs or consultants or PCI experts cannot dictate or mandate the validation requirements. Mostly this is by the processor (IATA) or the acquiring bank. If they can’t make a statement, then it would fall back into the card brand validation requirements. Which it has so far, unless IATA comes forward to clear this up. We can’t seem to find anywhere that IATA has had special requirements other than listed in the card brands requirements.

There might be further explanation needed based on their PDF at http://www.iata.org/services/finance/Documents/pci-dss-compliance-procedure.pdf

The procedure first states

Travel Agents are encouraged to contact their merchant bank (acquirer) or the applicable payment brand(s) to identify the appropriate procedures based on their eligibility.

But then at the bottom it implies that for assessment, it needs to have a QSA perform ‘on-site’ PCI assessment – which is not exactly accurate as it depends on their level. Further on right at the bottom, it states:

Depending on the number of card transactions handled those can be:
– PCI DSS Attestation of Compliance (AOC) which must be completed by a Qualified Security Assessor (QSA).
– Self-assessment questionnaire signed by an authorized officer.
– The results of quarterly vulnerability scans if applicable.

The problem here is that if the AoC is required to be signed by the QSA, so does its corresponding SAQ. These documents have the same signoff (3c for QSA) section. If you read the above you might be tempted to also argue that IATA is saying, depending on the number of card transactions (meaning your level), the requirements can be either:

– PCI DSS Attestation of Compliance (AOC) and ROC or SAQ which must be completed by a Qualified Security Assessor (QSA) – this applies to Level 1 Merchant (they can also use ISA but lets put that aside for now), and also Level 2 if you deal with mastercard.
– Self-assessment questionnaire (SAQ) and AoC signed by an authorized officer. – This applies to level 3 and 4
– The results of quarterly vulnerability scans if applicable.

Now we don’t know if this is what IATA is saying – it’s just the many ways this section can be interpreted so we do hope IATA will have a clarification on this matter. They CAN decide on a more stringent requirement for their agencies (such as ALL levels engaging a QSA to be onsite like a level 1 merchant), but this needs to be clear, so agencies can forge ahead with the proper budget and expectation.

Most travel agents fall under the Level 4 category of merchants, which based on the current requirements of PCI-DSS only requires a merchant officer to sign off the document.

Mastercard’s SDP services recently responded back to us on this with a confirmation as below:

Level 4 merchants are required to ensure they are PCI-DSS compliant by filling in the correct SAQ based on their processing environment and have the evidences prepared , and also to do this each year. There is no requirement from Mastercard to engage a QSA/ISA to signoff their SAQ on part 3c or part 3d of their SAQ/AoC and their executive signoff on part 3b is sufficient. This must be signed by the merchant. Engaging a QSA will be above and beyond their requirement and only done if they require assistance in filling their SAQ. Therefore, using a QSA is entirely optional and based on the discretion of the merchant.

This goes a long way in saying the same thing that has always been said. The logic I would argue here is, if your industry is made up thousands of merchants, how do we build a meaningful program to get all these merchants compliant? If QSAs are supposed to validate all the evidences, how much bottleneck will there be?

This is also inline with the famous PCI-DSS myth document at https://www.pcisecuritystandards.org/pdfs/pciscc_ten_common_myths.pdf. In Myth 6:

Myth 6 – PCI requires us to hire a Qualified Security Assessor
Because most large merchants have complex IT environments, many hire a QSA to glean their specialized value for on-site security assessments required by PCI DSS. The QSA also makes it easier to develop and get approval for a compensating control. However, PCI DSS provides the option of doing an internal assessment with an officer sign-off if your acquirer and/or merchant bank agrees. Mid-sized and smaller merchants may use the Self-Assessment Questionnaire found on the PCI SSC Web site to assess themselves.

Now, I know, there are so-called ‘merchant programs’ out there run by a few QSAs. I’ve spoken to many merchants who deem themselves compliant just because an ASV ran a scan on their external IP address and gave them a ‘certificate’ of compliance (which is not even a recognised document by PCI-SSC!).  If anything, it just makes the merchant falsely complacent and gives PCI a bad name and a bad rep as an on-paper compliance but practically as useful as ice is to eskimoes.

The crux of the matter isn’t whether QSAs need to be involved or not. It would be super if they can get involved, but the matter is cost and time. QSAs programs are not cheap, and also, how much work do they actually do for the client? The counter argument is, if QSAs are not involved, what then? You get a bunch of executives just signing off they have a firewall when in their mind they are thinking, “Man, Which wall am I going to have to set on fire to comply to this stupid request?”. It’s not a knock on their intelligence, but really, a lot of merchants are really good in doing whatever they are doing and they don’t exactly have a CIO to standby to interpret all the requirements of PCI-DSS for them. And PCI, despite its oftentimes banal requirements, is a compliance requiring a lot of technical understanding.

How do we solve this? Awareness.

The SAQs reason for existence serves simply as a baseline document and puts the onus on the merchant to ensure they have the proper security in place. A lot of merchants are not aware of this obligation. The moment they sign off that document, they are saying, I am taking responsibility over this document. I verify and validate this as true. If it’s not…well. If it comes to any breaches or anything, then the merchant takes responsibility.

If they are fully aware of their responsibility, then getting help is likely required. But now, there is no need for a formal QSA to get involved. If you can, then do so as QSAs do theoretically should have more experience in PCI – but consultants, or advisors can take this role. And there are many reasons why it might turn out better this way which I will explore in my next few articles.

b) All Travel Agents need to engage ASV to do their security scans

Man. This is probably the most misunderstood requirement of all time. All time. 100s of merchants have come to us proudly saying their ASV scan proves their PCI compliance. No, it doesn’t. The ASV scan is just one of many requirements you need to go through. It’s like you dressing for work and wearing only your shoes and nothing else and go to work and say, “Hey, I am all dressed!”. Um. No.

And while ASV is important, we have seen our fair share of trigger happy ASVs being done for travel agencies. Oh, you have a website? ASV! Oh, you have an internet facing IP and router? ASV!

Come on. We recently adviced one client who was having trouble remediating an issue on their website. I asked them, wow, for a small company doing internet transactions, its a big deal. And they went like, “What in the good name of **** are you talking about?” And they explained they just had a corporate website and were asked to do a scan. I went and look, and aside from the site looking like it had been designed by a 15 year old drinking too much mountain dew, it serviced no credit card transactions at all. They don’t even have any systems doing that. They just do EDC terminals that connect directly to the bank and completely isolated. So why the scan?

Because we were told, they said.

And so I drafted an email for them and told them to send it over to their QSA (they are level 4 by the way) and the response came back, “Oh thanks man, they told us there is no need to scan anymore! Yay!”.

The problem remains. How many merchants are scanning their completely static websites and receiving a certificate of compliance and pronouncing they are PCI ‘certified’? Is it the ASV or QSA’s problem? No. PCI clearly states that it is the merchant (or scan customers) who ‘defines the scope of the scan’, so merchants are taking a fair bit of the burden if the ASV is done incorrectly. ASV scans are needed if your site does credit card acceptance (SAQ A-EP). It’s also needed on any external IPs you might have if these are transmitting card information (SAQ B-IP, SAQ C). SAQ A, B and C-VT has no scan requirements listed. A lot of clients could possibly fall under the SAQ B and possibly SAQ C-VT, so ASV scans can be further avoided.

c) All Travel Agents will be fined XYZ amount for non-compliance

Now, this might be true but IATA hasn’t really come out to say anything. Frankly I will be very surprised if there is such a requirement. Basically, IATA is just saying, if you don’t become compliant, don’t connect to us. If you don’t connect to us, then you can’t issue tickets. This is a worse threat than being fined. So they don’t have to be overbearing to impose such a condition AND impose a fine for clients who are non compliant. Because technically, if you are non compliant, you are not connected to IATA. If you are not connected to IATA, what are they fining you for?

smartmurphy

d) PCI-DSS is applicable to all Travel Agents even those without credit card acceptance and transactions

OK. I am not sure whether there will be such agencies or not, meaning there is ZERO card acceptance or processing or storage or transmission in your merchant environment. Now do note, even e-commerce when you outsource your ENTIRE payment processing, the fact that you have the credit card payment option on your website puts you in need of compliance. For merchants that do not have any facility whatsoever (either card present or card-non-present), then technically, PCI-DSS should not apply. I say technically. Because if you are connecting to IATA’s processor (BSP) then even if you make zero or a million transactions, the risk is still there. So yes again IATA as the big boss of BSP has the right to ask for compliance from agencies with zero credit card transactions. In this case, my suggestion is to write to IATA  and see what is the next step. I can’t imagine any merchant business now not catering to credit/debit card payment but, wait. OK, my neighbourhood barber actually told me they only accept cash only, or barter trade my iphone for 2 years supply of haircut. So yeah, why not. But really, if no credit/debit card payment is an option and you regularly settle through agency credit or carrying a pile of cash, you technically can ask IATA what’s the next step.

In summary, we are not saying that there is some sort of conspiracy theory going on where QSAs are trying to pull a fast one on customers and creating F.U.D in the industry. After all, we ourselves have been certifying clients for 7 plus years already. But what we need to understand is that wrong information could be worse than no information. We need to get the right information out there so that merchants can make informed decisions. If they want QSAs, then ok all the better. If they prefer in house or specialised consultants, then OK. If they decide to do the hokey pokey instead of PCI compliance, then hey, that’s an informed decision on their side.

So, let’s get this awareness out. Travel agencies have about 10 months to get compliant. It’s not crunch time yet. This is like the start of the 3rd quarter in basketball. Important, but not Michael Jordan clutch time.

If you need more information on PCI-DSS applicability in your merchant business, drop us an email at pcidss@pkfmalaysia.com. We’ll get in touch with you ASAP.

IATA and PCI-DSS to Travel Agents: Data Channels

April 30, 2017 / / 0 Comments

PCI

IATA has for a few years been championing the need for PCI-DSS to the travel agencies that are registered under them. More recently, they have been pushing compliance for PCI and even made a deadline at June 2017 for all agencies to be PCI compliant. Unsurprisingly like many well intentioned deadlines, it is now pushed further back to March 2018. Our prediction is that by November or December this year, we might see yet another delay in the deadline. But that doesn’t mean there’s any let up in compliance. Therefore, we’ve been reaching out to many of the agencies who were our clients previously and letting them know if they need help on their SAQ, they know where to find it. Us!

Now, just to summarise, being registered with IATA means a big deal to an agency. It simply means you can issue tickets. So how it works is that IATA is like a national ‘switch’. Whereby registered members can receive calls from clients, and based on pricing etc, select the airline and pricing and issue these tickets – either to other clients or in behalf of even other agencies. Firstly, there is credit card involved, of course. Secondly, IATA members can tap into the BSP – the IATA Billing and Settlement Plan. This is like a huge payment switch – whereby it handles all the payments to multiple airlines from the agencies, so that agencies don’t have to deal individually with airlines for settlement of the tickets. Which is good. Secondly – there is the GDS (the global distribution system). There are a few players in the market – Sabre is one of the biggest (used by Malaysian Airlines), others are like Amadeus, Patheo etc. We’ve so far encountered Sabre and Amadeus in our clients and both of these are PCI certified providers.

So, with this basic understanding of how agencies work, how does PCI apply?

First of all, unless IATA makes a statement otherwise, agencies DO NOT NEED a QSA to do a level 1 certification or sign off on SAQ, unless explicitly requested do. Since IATA is the processor for the agencies in this case, it’s their call. But it’s a big call, because level 4 merchants aren’t very large and they might not be able to get QSAs to help sign off their documents. We are working with one of the largest merchants at the moment and even they are not requested by their acquirer to get a sign off on SAQ from a QSA.

99.99% of agencies out there will fall under the Level 3 or Level 4 merchant band and we all know what that entails – SAQ, signed off by their executive – only if required should they get a QSA to participate. But it helps to have someone that knows about PCI or else you would be groping in the dark with the SAQ options.

What we see a lot are merchants automatically selecting SAQ D-MER when it comes to PCI. Again you don’t have to.  Depending on the number of channels you have you might be able to select C-VT, or B, or even A-EP, A. We call these specialised SAQs – remember, if you don’t meet any of these criteria, you drop into the SAQ D bucket.

What many people don’t know is that you can opt for a separate SAQ for each channel, instead of having one SAQ D to cover all. Both are possible, but its just that for SAQ D, you would be marking a fair bit N/A if you are say just doing POS and e-commerce.

Before we venture into the dark arts of SAQ selection, let’s explore probable channels that agencies have.

a) Through the website – this is not that common actually. Now with Expedia, Agoda and all these portals coming up, it’s easier for consumers to get the best price regardless. But for corporate trips etc, some of these websites might still prove useful. Most of these websites will either redirect to another payment gateway or might even link to a GDS. Either way, they generally do not host the site where credit card information is being entered. So in this case, SAQ A might work. If they have card information collected in their environment before sending it over to the payment gateway, then SAQ A-EP. Questions for A = 22, A-EP = 191. So please think it over as to why you want to collect card information on your site.

b) MOTO – or Mail Order Telephone Order. In most cases, there would be a call into the agency requesting booking. Now it’s important then how card data is now transmitted, processed and stored. The agent likely will not have any funky call system like Ameyo or Genesys, and may just rely on our good old PSTN phone line. Once call is received, the agent will request details , including card details and type it directly into a GDS system. In this case, as there is no recording on the line, it’s fine, and as long as the agent is using a hardened desktop/laptop with a virtual terminal into the GDS, you can rely on SAQ C-VT to cover this. Now, what is a virtual terminal? Basically, it’s a virtual POS. You just don’t need to buy the POS devices. All GDS offers this solution, whereby you log into the virtual terminal and just input the card information.

The tricky part here is that not all information is received on phone. Sometimes, clients will say, OK, let me send you a batch of credit card info in a text file via email. Or, hold on, I am shooting you an image via WhatsApp or Skype. Or, wait, let me fax you the form. Oops.

Now what happens is that other channels are being utilised. You have storage of credit card information. You are no longer eligible for C-VT. C-VT = 81 questions. D-Mer = 332 questions. So, if you can stop these practices, I would suggest, go ahead and stop it.

c) Walk-In – most agencies have outlet(s) and you can walk in, and pay off the counter. They will either key in the information as if you had called, into the virtual terminal – OR, they might have an actual POS machine for you so you can dip your card and make a card present transaction. In this case, it depends on how the POS machine is setup. It would be pretty similar then to a normal retailer transaction – like a grocery store or departmental store. We’ve already written this at length here: http://www.pkfavantedge.com/it-audit/the-saq-bs-and-how-they-apply-to-you/.

So there you have it. Remember the following

SAQ A = 22 questions (good!)

SAQ A-EP = 191 questions (not great!)

SAQ B = 41 questions (good!)

SAQ B-IP = 82 questions (not so great!)

SAQ C = 160 (not very good!)

SAQ C-VT = 81 (that’s ok!)

SAQ D- MER(SP) = 332 or 359 questions (bye bye weekends!)

So there you have it. If you are an agency or a retailer and you need any help at all to clarify this PCI-DSS requirement, drop us an email at pcidss@pkfmalaysia.com. We will attend to you immediately!

 

 

Newer posts »

© 2024 PKF AvantEdge

— Up ↑