Category: Risk Management (Page 1 of 4)

ASV Scans /= PCI Compliance

There is an old story about a chicken and eagle. I hear this story being told by life coaches or motivational trainers trying to get through to our thick, jaded, technical skull that there is something more to life than coding and technology.

The abbreviated version is this: A farmer was walking and finds an eagle’s egg fallen out of the nest. He picks it up, brings it back to his farm, and puts it into the chicken coop. Soon, it hatches, and joins the other chickens in the farm and learns how to be a chicken, even though its an eagle. So this is where some of the version diverges.

a) The chicken and the eagle starts talking one day and the eagle notices another eagle flying high in the sky and he goes, “Dang, I wish I could be an eagle,” and his chicken-pal looks at him scornfully and says, “You are a chicken. How can you be like the king of all birds, soaring through the sky?” So the eagle keeps thinking he is a chicken and the next day he gets roasted for dinner. And the farmer finds his meat a bit tough and doesn’t taste like chicken at all. The moral here is: Don’t let your limitations inhibit you or you will end up a cooked and eaten. This is probably the original version before the other two came along below:

b) The farmer is visited by a naturalist who observes this ‘chicken’ and immediately knows he is an eagle. So he takes this chicken up to a high cliff, and throws him over, shouting: “Spread your wings and fly! Soar like the eagle you are meant to be!” And the eagle soars through the clouds and sky and become the king of all birds. The moral of the story: All of us are eagles, even if you think you are a chicken. All you need is a life coach or a motivational trainer to throw you off the ledge and you will soar. This is the preferred version for life coaches and motivational speakers. For obvious reason.

c) Same as story b) above, but instead of soaring, the naturalist throws the ‘chicken’ off the ledge, and it falls 100 feet and splatters its brains all over the bottom of the ledge and dies since it doesn’t know how to fly. And gets cooked and roasted for dinner. The moral of the story (and this is by far, our more preferred, realistic and risk-averse version): Don’t do something you may be destined for but not ready for. Or you will end up smashed, cooked and eaten.

All three versions have this theme in common: The eagle isn’t a chicken and the chicken isn’t an eagle. The chicken may have commonalities of an eagle, like wings and a beak, but just because it has those doesn’t make it an eagle.

Yes, I am aware that the anecdote above isn’t a very good illustration of the point I am trying to make, but I couldn’t think of a better one. And in a roundabout way, what I want to illustrate here is that ASV scans do not make you PCI Compliant.

We get this a lot.

A company would come and say they are PCI-compliant. Or we have a client who outsources certain portion of their operations to another company and that company comes back and shows us their ASV compliant scan and says this is all they need to show us. We (The auditors/consultants) are compelled to accept this because the ASV scans demonstrate their PCI Compliance, they say.

Let’s make a point here: ASV questions and subquestions in the SAQ D covers around 14 queries. Out of around 600. That means ASV covers 2.33% of PCI-DSS. There is a massive load of other controls and items covering PCI-DSS Other than those precious ASV quarterly scans. What about your patching? Hardening? Firewall security? HR policies? Logging and monitoring? Logical access? MFA? Hardening of systems? Anti-virus and host firewalls? What about service provider management? What about vendor default passwords? What about storage, encryption, key management? Software development? Application and penetration testing? Internal vulnerability scans? Training?

You can see how impossible it is to accept just the ASV report as an evidence of PCI compliance, much like how we cannot accept the chicken as an eagle, but yet, we are constantly berated upon that we don’t know what we are doing and that their Banks have accepted their ASV scans as a sign of PCI compliance, so we should to. But we can’t. We can’t accept 2.33% as a 100% of something. It’s simply mathematically not possible.

So there you go – banks. Why do banks perpetuate this myth that PCI compliance = ASV scans? Why? It’s 2.33% of PCI-DSS! You can’t accept something as an eagle just because it has wings and a beak! There’s really no argument about it.

Here is what 2.3% feels like:

a) The number of Jazz music of all US Music sales in 2013

b) Increase in slot machine spending in New Zealand in 2018 Q1

c) Auto parts industry against the US GDP in 2013

d) Android 6.0 Marshmallow installation for all Android devices in July 2016

e) Thats lesser than the % of freshwater we have on this planet (2.5% of water on the planet is freshwater)

I am sure there’s a lot of 2.33% out there on this planet, but the point we are making is this: It’s not compliance. It’s a small but important part of compliance but it’s not compliance. So no matter what your banks tell you, we can never accept the ASV scan as a sign of PCI compliance. It can be accepted as one of the evidences of PCI compliance amongst many, but not as an evidence of complete compliance.

Now, stop calling a chicken an eagle. Let us know about your questions for PCI or any compliance at

SAQ A and A-EP, the eternal struggle

Another week, another lockdown struggle, another political instability and another question on the eternal confusion called the SAQ A and A-EP. And this time, it wasn’t so much of us trying to clarify with the customer on this – but us trying to explain to QSAs on it. It just shows how much confusion there is to this thing even after all these years, that even auditors, whose bread and butter is literally on PCI-DSS still struggle to understand it. I don’t blame them – it’s the way that the SAQs are worded, and the confusion that surrounds it that makes it so frustratingly difficult to interpret.

SAQ A by far gets the most mileage. Not because a lot of people are eligible for it, but because at 20+ questions, it’s by default the go-to SAQ for most organisations, whether they are eligible for it or not. I mean, comparing the SAQ D and the A is like scaling Everest vs the little sand hill that your 5 year old kid just built on the beach. Something like that. So everyone (even non-eligible Service Providers) always default to the Open Shortest Path First, which is the SAQ A when they need to choose an SAQ to be “PCI-Compliant”.

However, SAQ A is notoriously difficult to be eligible for and today we are going to look at it. Again. We have often seen everyone anything from storing card information, to hardcopy storage of insurance policies, to doing outsourced call center picketing in front of our office shouting for their SAQ A rights. I mean, let’s start here with SAQ A and A-EP and the difference.

We are not going to focus on the controls in these SAQ, but rather the ‘eligibility’ of it, meaning, on Page 4 of both SAQ under “Before You Begin”. Instead of just repeating all that is typed in there in this article, I will assume those reading this article is keen for a deeper dive into the murky waters of SAQ and not here for a shallow wade – so I am going to assume you have those SAQs right in front of you and I don’t have to delve into the history much, ok?

SAQ A’s story starts off by stating there are TWO types of business who are eligible for it.

a) E-Commerce Merchants

b) MOTO (mail order/telephone order) – card not present

c) Of course, those who do not STORE, PROCESS or TRANSMIT card holder data in ANY electronic format on their system and premise.

Let’s start with MOTO first, because this often confuses people. Straight away those doing MOTO will dance a jig in front of me and gleefully points out that they deserve the SAQ A. All your base are belong to SAQ A, if those nerds like me would understand. Because I usually move them over to SAQ C or C-VT depending on how their call center/MOTO transactions are set up (even B-IP may apply e.g MOTO function on terminal, but mostly MOTO ends up being in SAQ D because they often store card data on file).

Hold on there though. Eligibility of MOTO is tied to the eligibility of c) – i.e you do not store (OK), process (erm, yeah ok, sometimes) or TRANSMIT card holder. Often the transmit and process part is done when you have people on your premise doing MOTO. The moment a phone call comes in – BAM! you are hit. You are done for.

So the ONLY time MOTO is eligible for SAQ A is later described in the SAQ:

Mail order/telephone order (MOTO) or e-commerce merchants that have completely outsourced all operations (where there is no redirection mechanism from the merchant to the third party) and therefore do not have any systems in scope for this SAQ, would consider these requirements to be “not applicable.”


The above is talking about how we can mark Requirement 2,6 and 8 as Non applicable. But notice where it states: COMPLETELY OUTSOURCED ALL OPERATIONS. This means, your company’s MOTO transaction is never done by your own company or on your own premise or by your people or using your technology. You have Completely, irrevocably, irreversibly outsourced the entire function to someone else who is PCI-DSS compliant. Then OK, you cool.

So now we know how to deal with that MOTO part. Oh wait, wait. There is a scenario from one client, where customers actually come over to the counter and try to make payment. However, because they have upgraded everything, instead of dipping or waving that card into a terminal for a POS payment, the counter person whips up a high tech iPad, connects to the companies website, looks at the credit card (while the customer is in front of them) and type out the transaction onto the e-commerce site itself for the transaction. How do we deal with this?

Well. This certainly doesn’t qualify for SAQ A in a strict sense, since this is considered a ‘face-to-face’ channel. However, logically, that transaction is made as an e-commerce, card non present transaction, because the CVV is entered as well and on the merchant end, it qualifies as a e-commerce transaction based on the flow and the fee they are paying. This is an interesting scenario as I would likely look at it as an e-commerce flow, since technically, the customer can do it themselves, but its just that for some reason, maybe they don’t know how, or they can’t figure it out, they go over to the counter to do it. The acquirer certainly doesn’t know about it. But because the information is going through the company’s asset, the company’s line, the company’s network, there would be additional risk they need to consider. In the end, it would be the call of the QSA on how they view this, however, I don’t think this could qualify for an SAQ A channel. It could be technically treated as a SAQ B-IP as we can assume its a terminal, but most auditors, to err on the side of caution may just opt for the full SAQ D on this.

OK, MOTO done.

Now for the e-commerce. I am not going to repeat what I’ve written some years back:

But I am just going to dive right in where the confusion begins. SAQ A-EP is written in a way that confuses people, and requires some sort of Indiana Jones exploration to figure out what in tarnation they are trying to get at.

So, under Before you begin, the second eligibility point (we call this ITEM 2):

Item 2: “All processing of cardholder data, with the exception of the payment page, is entirely outsourced to a PCI DSS validated third-party payment processor;”

This is confusing. They say – “All processing of cardholder data EXCEPT the payment page”. This means, the payment page actually SITS with the merchant, while everything else is outsourced to PCI third party. This means, this SAQ is eligible for merchants with PAYMENT PAGE (where credit card is entered) residing in their premise. So therefore, if the PAYMENT PAGE is also outsourced, immediately, this SAQ is no longer eligible. In a simple logic:

if (paymentpage) then { read next line;} elseif (!paymentpage) { exit();}

That means, SAQ A-EP doesn’t apply anymore to us if we have outsourced the payment page because this condition is not met, and therefore the if statement should exit, or if you are in a loop, it should end. SAQ ENDS.

The problem is auditors are generally non-programmers and even when the condition is no longer eligible, they keep going!!

And it’s really, the next line that is the confusion of all confusion:

Item 3: “Your e-commerce website does not receive cardholder data but controls how consumers, or their cardholder data, are redirected to a PCI DSS validated third-party payment processor;”

I mean, if we had exited the SAQ loop on the second condition, we won’t need to deal with this nonsense. So let’s break it down. YES, my e-commerce website does not receive card holder data, since I outsourced ALL MY PAYMENT page already to third party. But wait, you are saying “CONTROLS’ how consumers or data are ‘redirected’ to a third party? What? Obviously there is an element of control here, so how do we define ‘control’? Isn’t redirecting to an outsource payment page CONTROL?

The next confusion is the next line:

Item 4: “If merchant website is hosted by a third-party provider, the provider is validated to all applicable PCI DSS requirements (e.g., including PCI DSS Appendix A if the provider is a shared hosting provider);”

Hold up – didn’t we already agree that if the merchant entire website is hosted by a third party PCI provider, this would already not be in SAQ A-EP (see the exit rule of item 2). In fact, isn’t completely outsourcing the website the whole point of SAQ A? What sort of black magic is this?

Item 5: “Each element of the payment page(s) delivered to the consumer’s browser originates from either the merchant’s website OR a PCI DSS compliant service provider(s);”

Look at this wording. Look at it. Tell me that this is not contradicting item 2, the ‘with exception of the payment page’ condition. Let me rephrase item 2:

“You can go for SAQ A-EP if you host your payment page and have outsourced your processing to a PCI third party” –therefore implying that if you don’t host payment page and outsource everything, then another SAQ (SAQ A) applies.

Item 5 slaps Item 2 in the face and goes, “No. SAQ A-EP for you if you host the payment page, or the payment page is hosted by your PCI-DSS service provider. So no, Item 2, you wrong. You dead wrong.”

That usage of the word “OR” in that sentence confuses programmers or those with IT background, I think. This is a logical connector where if condition A OR condition B, if any of this is TRUE or both TRUE, we enter into the loop. Compared with the AND connector, where both needs to be true, otherwise we don’t process the loop. So the above statement is stating “ANY CONDITION WHATSOEVER” since it uses “OR”, will need to apply SAQ A-EP.

In fact, if they had clarified if all of these conditions are connected to each other either through the AND or OR operator, it would makes much more sense to us. It’s like the question, “Are you going to do it now OR do it later?” and we answer “Yes!” because we are indeed doing it now or later, and the question didn’t specify which condition as long as we are doing it.

Anyway, back to the story. The note in SAQ A-EP states:

For the purposes of this SAQ, PCI DSS requirements that refer to the “cardholder data environment” are applicable to the merchant website(s). This is because the merchant website directly impacts how the payment card data is transmitted, even though the website itself does not receive cardholder data.


It is very ominous. It states, even if your website does not receive card holder data, you still impact or ‘control’ how the payment card is transmitted.

All is not lost though, because if you flip back to SAQ, under the SAQ A notes:

For this SAQ, PCI DSS Requirements that address the protection of computer systems (for example, Requirements 2, 6, and 8) apply to e-commerce merchants that redirect customers from their website to a third party for payment processing, and specifically to the merchant web server upon which the redirection mechanism is located


I mean, I don’t know how clear it needs to be. It states in SAQ A “FOR THIS SAQ” – apply to merchants that ‘REDIRECT’ customers FROM their website (merchant website) to 3rd party for payment processing and specifically TO the merchant web server where the redirection occurs.

I am going to clarify the phrase that is underlined. the word “TO” is a preposition of the verb “apply to” in the earlier sentence, i.e this applies to merchants, specifically to their web server etc etc. Why its confusing here is because some may read it as a preposition to indicate direction , i.e redirect customers from their website to a 3rd party, specifically TO a merchant web server etc etc, which basically indicates the redirect is going into a loop (from merchant site to third party back to the merchant site) which doesn’t make sense.

I just want to point this out as I may not be the only one confused with this play of words and irresponsible usage of the preposition “TO”. Only me? Ok, fine.

Anyway – long story short, we used the notes in SAQ A to get out of jail for our client, and the QSA seemed to be resigned to that, noting there is a huge huge confusion with how A-EP is written. You do need to know, A-EP was born after A, so definitely, there would be some contradiction since they weren’t written together. SAQ A-EP is like the grumpy uncle that sits in the corner in your Christmas party and snaps at you when you ask him how he’s doing, while SAQ A is like the uncle with all the presents and all the children running around him and laughing with him as he tells a joke. Ah, SAQ A, we like you a lot.

Anyway – a final note on us, while we can state on PCI side, a full outsourcing of e-commerce payment page to third party qualifies for SAQ A, you do need to think – SAQ A-EP makes sense. The page doing the re-direct could be attacked and compromise and the redirect sent to another ‘payment page’ that looks exactly the same as the actual one. So while you are laughing with SAQ A, you need to take into account not to ignore the reasonable requirements that A-EP puts to you – vulnerability scan, firewall rules, penetration testing – i.e these are all best practice baselines that should be practiced regardless of compliance conditions etc. I would recommend a middle ground and take up a risk approach to it – implement these controls based on a good risk assessment and not just ignore the poor, grumpy SAQ A-EP uncle sitting in the corner. Because he may have a point in terms of security, after all.

Let us know about your experience or questions on PCI, SAQs or any other compliance questions at!

Is PCI-DSS the most confusing standard?

After being involved in PCI-DSS for almost a decade as well as other standards and guidelines like ISO27K, 27017, 9001, PDPA, GDPR, CMMI and a partridge in a pear tree, we can almost unanimously say: PCI-DSS is probably the most confusing standard out there. Not so much of the content itself – it’s fairly easy to understand in terms of the technical controls. The confusion begins at the start: Applicability and Scope.

Now scoping for PCI-DSS has been hammered by us in many articles over the years, so for this article, we will look at Applicability.

So what is applicability?

It simply means, who does this standard apply to? This is different from ‘scope’. A scope is basically what is being assessed? Applicability is basically: Do I need to do this thing?? For instance for simplicity:-

a) GDPR = Applies to entities processing EU personally identifiable information. Entities that may have a more global presence or require to deal with customers with a larger market distribution may end up being applicable to the GDPR.

b) PDPA = applies to entities in Malaysia processing personal information, which basically means almost everyone.

c) ISO27001 = guideline that can be used by any entity to cover their core processes. This may also be required by some governments on certain industries, e.g the government requiring CNII (Critical National Information Infrastructure), so simply, if you are CNII, then you should be doing the ISO27K.

d) CSA Star Alliance = standard for our data centers to apply, but it’s not mandatory (as far as we know).

e) TVRA = based on MAS (Monetary Authority of Singapore) requirement for financial institutions, so generally if you are regulated by them, then you need to get this done. It’s actually a subset of their Technology Risk Management Guidelines. It’s pretty much a mirror of Malaysia’s RMiT (Risk Management in Technology) subset of data center resilience section. As an aside it seems slightly comical that these two countries, tied so closely together in terms of history and economy would sit down and decide to name their federal bank’s IT standard so closely to each other. I mean, it’s like:

i) Singapore – Let’s call our technology standard Technology Risk Management!

ii) Malaysia – Hmm, we can’t sound the same otherwise we might look like we aren’t original. Let’s flip it around and call it Risk Management in Technology!

Back to the subject, most standards out there has a reasonably clear idea of who it applies to. Even Bank Negara’s e-money guidelines or their baseline IT security requirements – apply to those regulated by them. HIPAA (not in Malaysia) applies to medical and healthcare entities.

Which leaves us with PCI-DSS.

From the onset, PCI-DSS applicability is actually very clear:

PCI DSS also applies to all other entities that store, process or transmit cardholder data (CHD) and/or sensitive authentication data (SAD).

PCI-DSS Standard

So in general, whenever you are storing, processing or even transmitting any part of the card holder data (PAN) or the sensitive authentication data, e.g track data, CVV etc, then PCI applies to you.

The confusion begins when these exact terms are used by those who are NOT doing any of these 3 (Store, Transmit, Process or STP) –lets call them NON STP– but still gets pulled into scope kicking and screaming like a child on his first day of kindergarten or adults on their first day of work after a holiday in the Bahamas. Examples are data centers, hosting providers, physical security storage companies (storing secure boxes for companies) – in their business model, they don’t deal with credit cards at all. But their customers may. Or may not. They don’t know. So for instance, if an insurance company decides to store their policy files with credit card information physically into a box and ship it to the physical storage company, how does the storage company gets yanked into ‘applicability’ of PCI?

The problem of section 12.8.2:

12.8.2 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

pci dss standard

The last part is where QSAs hook on – ‘impact the security of the customer’s CDE’. Now, just to be clear, 12.8.2 by itself has no indication that PCI is a requirement for these “NON STP” providers. It comes later in 12.8.4 and 12.8.5 where it states

12.8.4 Maintain a program to monitor service providers’ PCI DSS compliance status at least annually.

PCI dss standard

Argument on whether this relates to PCI-DSS compliance as a program or just service providers adhering to the PCI-DSS controls internally is an argument beyond time and space itself and requires a thesis to be written on it. Hence for now, simplicity wise, going by the standards and how many QSAs interpret it, multi factor authenticating providers gets pulled in. Hosting and cloud providers get pulled in. Storage vendors get pulled in. Cloud HSM and security providers gets pulled in. Fraud management gets pulled in. The whole thing about who could impact the security of customer’s environment gives QSAs a field day in including everyone in the party.

So applicability isn’t so straightforward after all. After determining anyone that stores, transmit and process credit/debit card with the PCI council members badges — now we have anyone that influences the security of the first group’s card data environment. This basically pulls almost everyone into applicability.

It doesn’t end there, however.

Because of the way PCI is structured, the PCI council actually washes their hands to determine who should be PCI compliant, and how they should be compliant. They pass that over to the individual card brands (I guess that’s themselves), who passes it to their banks connecting to their network, who in turn passes it on to their payment providers and who in turn passes either to their service providers or to their merchants. This is looked into in FAQ #1473, #1126, #1212 and a whole lot of other references. They always have this statement:

The PCI SSC recommends that entities contact their acquirer and/or the payment brands directly, as applicable, to understand their validation reporting requirements. Please contact the payment brands directly.

Everywhere to ensure everyone knows

When we were kids we used to play a party game whereby two teams have everyone sitting in two long straight lines. At the front of the line, the gamekeeper passes them a message, for instance “There is a blue wolf sitting in the Artic, looking at you with yellow, hungry eyes tonight” or something like that. Each kid will then need to whisper that message to the person behind him until it reaches the last person and that last person will have to go to the front and declare the message aloud, which invariably ends up something like “There comes wind that blew into the attic and sitting at me with fellow grey ice to the right.”  And everyone laughs.

This is how it is in PCI. The message gets passed down and somehow along the way, the message gets so jumbled that we can only shrug and go, “OK…” Some messages we have heard (from customers who claim their banks said):

a) “You need to show us their SAQ and ROC together! The AoC is not enough” – Not really. If you are doing SAQ, there’s no ROC (Report of Compliance). Likewise, if there is a ROC, it’s not SAQ. Both have AoC though.

b) “Physical storage companies that store physical card data like forms needs to do SAQ C-VT” – We’ve seen this, where storage company gave a SAQ C-VT (virtual terminals) to their banks and was accepted. No, you can’t. A physical storage company, being a service provider should look at the SAQ D and then mark of the irrelevant controls (such as firewall etc) as Not Applicable.

c) “You can do SAQ A – as a payment gateway!” – A permutation of b) – whereby a payment provider gave us an SAQ A as proof of their PCI compliance. I think they just scanned through which is the shortest SAQ A and go, OK, let’s go for the easiest. No, SAQ A isn”t applicable to service providers. SAQ D needs to be done and controls that are relevant to be identified.

d) “You can store hashes with truncated data, its more secure!” – This is more of our previous post, where a company we spoke to started arguing on the merits of implementing truncation, encryption, hashing and storing everything together. No, it doesn’t work like that. If Truncated information and simple hashing is stored together, without a random salt, it may be easier to determine the card information through common sense brute force (please don’t talk about rainbow tables).

e) “They need me to be a level 4 certified gateway provider since I do less than 6 million transaction.” – In general service provider levels are only level 1 and level 2, according to visa and mastercard and amex. Secondly, the transaction levels for level 1 Visa and Mastercard are 300,000 volume, significantly lower than 6 million (which is for merchants). Amex has a higher threshold (2.5 million) but in general, we look at Visa/Mastercard since they are the most widely distributed.

f) “They insist on seeing a certificate of compliance – other documents are not allowed” – This has become so common that it’s painful. There is no such thing as certificate of compliance. These are all conjured up in the imagination of QSAs and PCI-DSS never issues certificates. It is technically as useless as showing your birth certificate to your bank. Yet, your bank insist upon it. FAQ #1220 of PCI addresses it below. So while it’s not wrong to issue certificates, but these are not considered “official documents”:

Because certificates and other non-authorized documentation are not officially recognized, entities that receive these documents to indicate their own compliance (for example, from a QSA or ASV) or another entity’s compliance (for example, from a service provider) should request that official PCI SSC documentation be provided. Any organization issuing, providing, or using certificates as an indication of compliance must also be able to provide the official documents. 

FAQ #1220

g) “Since you only transmit and process card data and not store, no need for PCI-DSS” – We get this a lot from banks. Technically if you transmit or process card data , you should be PCI applicable. However, since banks have a big say in your compliance (for instance they may force you to be level 1 compliant even if you have zero transactions), on the flip side, if they say they don’t need it, then well, you don’t need it. You could probably argue with them and say you actually do need it from a technical point of view, but most customers just take the bank for their word and move on. The bank has made their risk assessment, and if they insist we don’t need to be PCI compliant and gives a black and white stating they don’t need – essentially they (the bank) is absorbing all the risk of non-compliance, aren’t they? Remember – PCI-DSS is generally a contractual obligation between parties. If the bank says contractually you are not required for PCI-DSS, then what’s the argument? In this case, we usually advice our clients to still undergo a self assessment to ensure they are aware of the security practices and we then get a nod of wise agreement before they shoo us out of the room, never to be heard from again. If they had a trapdoor button that drops us into the Rancor’s pit, I guess they would have used that.

h) And finally, most recently – “they say the since we only store PAN and without expiry and CVV, they said PCI-DSS isn’t applicable to us” – this is a bit mind boggling since this bank was an international bank and we think they should know better. But that doesn’t mean local banks know less, we’ll take it back. It’s just that international banks, being exposed in so many countries, would probably have the mindshare larger than local banks to know more about these things. But this one was – “You don’t store CVV and expiry date? OK – no problem, just go ahead and store PAN for all we care! Yeay!” Granted, the use of card information without information like CVV, expiry etc may not be as useful, but there are still other ways for PAN to be used – identity theft for one. Or, it can be used in combination with other information they already have. Or they just want to sell it on the dark web. PCI-DSS puts a big premium on PAN storage, so much so saying, if PAN is stored, all other information must be protected. And oh – CVV is considered Sensitive Authentication Data (SAD), and no, it cannot be stored post authorisation for whatever reason.

There are a whole lot more of strange things we have heard over the years from banks and service providers but those are the main examples. Again, I do not think it’s due to them purposely misinterpreting the standard, but like that party game, once the message gets passed down the line so many times, eventually it’s just going to end up like garbage. It’s like how I had to deal with my wife’s instructions to buy stuff from the grocery. It’s sanskrit to me…I mean how many different pasta brands are there and why must we buy such a specific one? Pasta’s pasta, no?

If you need us to help un-garble PCI-DSS for you, drop us a note at and let us get to it!

PCI-DSS Cheatsheet

As we approach the end of the decade, we are approaching 16 years since PCI-DSS was first introduced back in 2004. 16 years. That’s probably a full dog lifetime. I would imagine the guys back in 2004 would have thought: “Let’s just get version 1 out this year. I’m sure our next generation of brilliant minds will figure everything out by 2020.”

So now we are a few ticking days away from 2020 and yet, at the end of the line, I am still answering calls that are increasing as the days go by: What is PCI-DSS and how do we get it?

Most of these callers are generally calling because our names are listed pretty high on the internet when someone types in PCI-DSS Malaysia. Apart from that, a majority of these callers are calling because we were reference by one of our clients. We have faced different variations of callers coming in: Some requests us to provide them with a PCI-DSS ‘license’ in order to operate for their clients. Some requires a ‘certificate’, some are literally clueless as to what it is but their banks have mercilessly dumped this whole requirement to them.

Step 1: Who’s Asking?

First of all, take a deep breath, here is a simple cheatsheet. Whoever is asking you to be PCI-DSS, take note of it. Here are the Usual Suspects:

Bank – Very likely you are connecting to them doing some sort of payment processing like a payment facilitator, a TPA etc. Or you could be a service provider and your client just happens to be a bank, which brings us to

Customer – your customer for some reason is dealing with credit/debit cards, either directly or indirectly, and they require you to do PCI-DSS because you are servicing them or they have outsourced to you, like BPO, Data Center, hosting, call center, or even network transit

Internal – One of your internal managers have read up about PCI-DSS and decided that your company will sound very cool if you are PCI-DSS certified. Now, in this case, you could or could not be PCI. Because PCI is a contractual obligation dealing with credit/debit cards badged with Visa, Amex, Mastercard, JCB, Diners/Discover – if you don’t deal with this or have any clients dealing with it but your company just wants to get any standard out there – my suggestion wold be to go for something like ISMS (ISO27001) as that’s a better guideline rather than a contractual standard like PCI-DSS. If you still insist – well, you could still go through the SAQ but a lot of it will be not applicable to you since you are Non-CDE for everything.

Those 3 are mainly the motivations behind PCI-DSS. Why is it important to determine who is asking, is because of the next step:

Step 2: Determine your Level

Now there are guidelines out there for which level you should be at. If a service provider, then anything over 300,000 volume of card processing will bump you into level 1. For merchant, anything over 6 million for level 1 and anything over 1 million for level 2. I can’t count the times people get mixed up with Service provider levels and merchant levels. Even banks. I have banks telling our payment gateway that they are Level 4 . There is no such thing. It’s either one or 2. For merchants there are level 1,2,3 and 4 but the volumes are different.

Now while the guidance is cool and all, at the end it’s your bank or customer determining your level. If your bank decides to only deal with you if you do a full certification and RoC with a QSA, then even if you are processing ZERO transactions, they have deemed you as level 1. You can then decide to either say OK, fine, or tell them you are taking your business elsewhere. In that case, they may decide not to play hardball. I don’t know. Same as your customer. Your customer may decide you need to be assessed by a QSA, so it’s best you determine this with whoever is asking you.

The secret sauce is this: Most of the time, your bank/customer won’t have a clue what they want. They will just say, Oh, be PCI compliant. In this case, approach them with some tact. Your mission, should you choose to accept it, should be to avoid level 1 certification as much as you can, if your volume is low. It’s not justifiable. Look, if you want to be assessed by a QSA, by all means, but at least, know that you have a choice if your volume is low, and your bank/customer isn’t fussy about it. Just tell them: “OK, I’ll be PCI-DSS compliant, and I will fill up the Self Assessment Questionnaire (SAQ) and our management will sign it off and send it over to you. Is this OK?” If yes, then great, do your own self assessment. You can save up some money.

Step 3: Determine your Controls

This is probably the trickiest part of PCI-DSS. You see, being level 1 or level 2, self assessed or third party assessed, SAQ or RoC does NOT make any difference on what controls you need to have in place. An example: Level 1 compliance may require you to do ASV scans for 3 external IPs and 20 Internal IP Penetration testing. Guess what? Even if you are doing an internal self signed SAQ, you are supposed to do the SAME THING. No difference. No “Oh, since I am level 2, I will do ASV scans for 1 IP and maybe take 5 Internal IP for Pentest instead of 20.” In theory, all controls are the same, the only difference is WHO assesses and attests these controls.

Now, of course, realistically, this is not happening. Like I always illustrate, some companies consider a firewall as a wall on fire and they sign themselves off as PCI-DSS. Hence the whole passing the buck, passing the risk thing about PCI that I won’t go into discussion here. But in theory at least, same controls apply. But how do you determine what applies to your business? Well, based on your business flows of course.

Determine above all whether you are storing credit card information. If you are not, roughly 35% of PCI-DSS is not applicable (I am plucking that % out of no where, so don’t quote me). But a big chunk isn’t applicable. Second, determine whether you even interact with credit card or not. Look into all your channels. It could be complex like a call center, or simple like a network transit. In most case if you can determine that you have no access to credit card PAN or don’t store, and don’t process, the controls that are applicable to you are minimal. You should STILL be PCI compliant, but minimal controls apply.

Step 4: Determine your vendors and outsourcers

We had a client who cancelled an ongoing PCI-DSS with us because they have deemed themselves PCI-DSS compliant because they are using a PCI-DSS software. I cannot count the number of times I have to correct them – NO. Just by using a software which is PA-DSS compliant or even PCI compliance (like Cloud) DOES NOT make you PCI-DSS compliant. Will it help? Sure it will, but can you piggy back on someone else’s compliance? No. You can’t. So either you go through PCI yourself, or stay non-compliant, but don’t say you are compliant when you are only using a software that is compliant. That’s like saying you are certified to fly a plane when you are a passenger of a plane flown by a certified pilot. Or something similar.

Get your vendors on board for PCI if possible. If they refuse you can still use them, but you now have to include their processes under YOUR PCI-DSS program. Why would you want to spend extra days getting your vendor compliant when there are OTHER vendors who already are compliant?

So there you have it:- When someone requests PCI compliant – first, review your options. There is no ONE way for PCI. Go with the least resistance – self signed SAQ if your volume allows it. That saves you a lot of time and money as opposed to getting a QSA to come in.

If you have any queries on PCI-DSS, drop us a note at and we will attend to it right away! Merry Christmas!

The Criticality of Project Management

Project management over the years have gone through somewhat of a bad rap for technology projects, especially. They always seem like a luxury afforded by management, and whenever things go south in a tech project, the first stop for blame is always on the project manager. It’s a tough life. On one hand you need to appease the forces that hold the budget (the business) and on the other, you need to deal with a bunch of geeks who are talking binary stuff and whom you know would rather not have you in the room because you don’t talk tech as much as them.

We used to have a Project Management Office, receiving work from other large projects looking for business analysts, project leaders, program managers etc. It’s not cheap upkeeping these guys, what’s with their PRINCE and PMP certifications and their training and hours. The problem was also when the project ended, then basically we had to go look for other projects to take them on. It’s an expensive affair, unless you have a constant pipeline of internal or external projects to keep them busy. The thing was, we noticed project managers tend to stay as project managers. You couldn’t get them to go into tech audits, or develop software or do compliance work. At least, for the ones we hired.

In the past, Project Managers are fairly agnostic in terms of technical capability. They have a set of domains they are good at (whether they are good at telco projects, compliance projects, migration projects), but overall, the discipline more or less remains constant. Methodologies used by these managers include lean, SCRUM, Agile etc, or simply PMI/PMBOK guidelines, which some of our managers tend to gravitate to. But aside from this basic competency of managers, there is inherently a personality that project managers need to have. Leadership is obvious, decision making capability, the ability to stand strong when being questioned and able to communicate the project properly. The ability to pull people together, from technical to consultants to internal business, and yes, the inherent charisma that one must have to become a successful project manager. He or she needn’t be the most technical in the room, but they must be able to sniff bullshit and weed it out. Time, budget and quality are the basic triangles of forces that need to be met, and good project managers are aware of this.

Due to cost and lack of demand, we shuttered our PMO a few years back, but our guys still practice basic PM work in our compliance project, and in some smaller companies, we actually end up taking the informal role of the project leads. We wouldn’t call ourselves project managers, because not everyone who calls themselves project managers are actually project managers. However, for larger companies, we do defer to the project manager in charge, and in our time we have had some experience with some of the best in the business, and some of the absolute worst. The problem is because being a good PM or absolute garbage is so difficult to assess.

It MAKES A HUGE difference who you put as a project manager. It spells either success or complete doom to your project the moment you assign a good or a garbage project manager.

For a compliance like PCI-DSS, there are some specific traits a manager should have, as PCI is a fairly technical project. And most PCI projects tend to drag on past 4 months or so. Some even a year plus. It does require a fair bit of technical knowledge, persistence and goodwill to successfully manage the project. Here are some of what we observed, and having experience good ones, and the bottom of the barrel type of project managers, we can probably give a fair opinion of what are the points of success (between good manager (GM) and hapless manager (HM)):

a) Technical Capability

This is more of a trait than a skill.

The GM know they don’t need to be experts, but they also know they need to put their backs and time into understanding the whole thing and trying to absorb the technical matters of it. They would attend training sessions and they would ask very good questions. The hapless managers go: OK, everyone knows their spot here. Consultants, I will look to you to answer all PCI related questions. I am here to gather information for all parties, so I want everyone to come for every meeting we are going to have moving forward.

The hapless one basically just comes in, fires off a few questions on project matters, and then sidles down and constantly have a far away look in their eyes when we start talking about the project tasks and updates. Or glued to their phones or laptop, furiously typing out stuff with their brows knotted up. Their strategy is that everyone else will carry their own load so they don’t need to know anything technical because they are too busy with other more important things, like buying food for their cats online. Occasionally, they bark out some orders here and there but you can tell, they know jackshit. After 4 – 5 sessions, they are still clueless and that’s when they start losing grasp of reality, and if the consultants are not available, the whole project is stuck, and then they move into the stage of looking to blame people for their ineptitude. Oh yeah. We have had plenty of these experiences for sure.

b) Communication

This seems a given, and a good manager ensures everyone is on the ball and the scoreboard is known to all. They know how to manage downlines (the people that need to get things done), horizonlines (the peers who are managing other downlines) and uplines (the business or sponsors pressuring the project). This innate ability isn’t bestowed on the hapless one. The hapless manager’s basic modus operandi is to take whatever the team gives, and being questioned by uplines and peers, decide that they don’t know how to explain it and comes back to the team again to ask for more information on how to deal with the questions. There is a complete lack of awareness in these managers that they are unable to overcome. They are unable to argue their points succinctly and always give in when there is pressure. Because of their lack of skill and understanding, they have no clue what positions to take and often waste the entire project timeline by going back and forth hopelessly like grass (or lalang) swaying in the wind.

c) Responsibility

One of the true strengths of character is when things are not going right, the good ones take up the responsibility of the situation and face the issues head on. The hapless ones find a way out, and find a way to blame others. To them, it’s always someone else at fault and never them. This stems from their utter lack of confidence in the project, that the only way they can reverse the situation is by saying, “It’s not my fault.” They usually will turn to consultants, as they are external to the company, and seek to pin the blame on them. It’s tough, but it is what it is. Most companies, given the choice of an external party and an internal person, would side with their own regardless of facts.

d) Time Management

The LLB (Look Like Busy) Trait is a big problem with these hapless managers. Because of their lack of a), b) and c) above, they are running around like headless chickens, being pulled from one meeting to another, unable to resolve any issues properly. So their heads are constantly in their phones or laptops instead of properly leading the project. Firefighting, or looking to assign blame. You can also tell when they are not able to manage meeting times. Many times, we have received calls from project managers requesting either immediate meeting at their office, or to come onsite within the next day and they wail because we tell them we are either overseas or assigned to other audits and we can do a phone. Most don’t understand that (unless we are properly paid and engaged), we are not their outsourced compliance unit so they blame us for non commitment. We are their consultants and there is no service level that requires us to stay in the clients office all the time for their beck and call. Unless, again, if they pay us, but most don’t pay for consultants to sit down and wait for inept project managers to scramble around looking for ad-hoc meetings.

Because they are scrambling and blaming instead of working,these PMs now think they are utterly important because they are so busy, but the fact is because of the ineptitude, they are being forced to seek responsibility, communicate or have technical explanation of the project – all which they are unable to do. So it’s one excruciating, meaningless and useless meeting after another. It’s horrible to exist in that manner for a career, but we’ve seen this many times.

Once you solve a), b) and c), Time Management solves itself.

Bonus points: While this may not be always true, the way project managers approach meetings and projects can actually say a lot. If a PMP or PRINCE PM comes in, there is usually a methodology on the table, tools and actual project management software they utilise for reporting. They are able to standardise our reports to a point where it goes straight to the point and to what they know their uplines need to know. Some hapless PM comes in, not certified in anything, not having knowledge of any tools, software or methodology, but basically armed with an excel sheet they took from another project manager who took from another project manager who used it to make sandwiches. That’s how senseless we see some of these methods and tools sometimes an we just look at everyone across the table and everyone goes like: “What is going on?”

In conclusion, never underestimate the importance of Project Managers, especially in a long drawn project like PCI-DSS. While we have known some excellent ones in our time, we have also worked with yahoos out there that single-handedly managed to trainwreck projects. From this article, it may seem our experience is more on the latter, but the opposite is true – we have the privilege to have worked with some really excellent ones that have also helped us get better, over these years. They are absolutely precious resources in a project, trust me. It’s just that when we do face one or two hapless PMs, it stands out a little bit more because we are so used to working with good ones!

Yes, we have shuttered our PMO as an advisory a few years back, but we also recognise the need for great PMs that might be able to help us out in our projects. If there is any interest, drop us a note at and we will get in touch wth you.

« Older posts

© 2021 PKF AvantEdge

Up ↑