Category: ISO27001 (Page 1 of 2)

Credit Card transaction flow

It has been a VERY long while since we last updated. Q1 has been a very challenging period for not just us, but for our clients, and I am sure, many businesses around the world as well. It’s just a lot of things (not necessarily good) happening, and we can only wish all our customers and readers to be safe and to take care of oneself during these challenging times.

Instead of going into too technical a subject, it may be a good idea to just start off this decade with a quick recap on some basics of credit card flows. This allows us to understand certain things dealing with PCI-DSS and gives us some background on more technical subjects later. This article takes us back to the basic.

How does a credit card transaction flow look like?

a) A cardholder (you and me) uses a credit card to purchase something – either online (card not present) or physically (card present).

b) The merchant either uses a POS, or virtual terminal or e-commerce, but at the end the authorisation request is transmitted to the ‘acquirer’.

c) The acquirer in this case the the merchant’s bank (or payment gateway, if not a bank). Not yours (issuer). So when you receive a credit card receipt, take a look at the receipt and it should state the acquirer. The acquirer acquires (signs up) merchants to accept card payments and ensure the merchant gets reimbursed for the credit card payments they accept.

d) The acquirer sends on the request to the processor. A processor does the authorisation and settlement service for all credit card transactions for each of the cards accepted by the merchant. These generally requires a front and back end processor.

e) The processor passes the transaction to the issuer, who approves/declines the transaction for whatever reason. Your issuer is the one issuing your card and generally has badge over the card (e.g your bank).

f) Whatever the response from issuer, the processor then sends it back to the acquirer, and the acquirer then sends it back to the merchant, through the terminal or however the request came in.

g) The merchant now has the approval (or decline) code, and the transaction is completed by providing the cardholder with the receipt.

h) Now the merchant and the acquirer goes through the clearing and settlement phase and the acquirer credits the merchant’s account.

i) The acquirer submits the transaction for settlement via the processor, and the processor requests the issuer to reimburse the acquirer for the transaction.

j) Finally, the issuer post the transaction to the cardholder account and the cardholder needs to settle the account (or not) on their statement.

That, in a nutshell is how a basic credit card flow works. Of course, there are inner workings in there, such as usage of settlement banks, consolidation of different acquirers, daily clearing data file reconciliation etc. But the above overall should give you a good working knowledge of what happens when you dip or wave your card in the next transaction you make.

For more information on PCI-DSS or ISO compliance, please drop us an email at! We will get back to your immediately. Stay safe!

PCI DSS and the Problem of Scoping


I recall in an actual case a few years back when I received a call from a company requesting us to do a certification for PCI for them. So I met them and drew out their PCI plan starting with a gap assessment, remediation and certification audit.

They said they have already done their own gap assessments internally by their ISMS guys. And they will be doing all their remediation on their own and they just needed me to quote for certification audit because “PCI is forcing us to be certified by a third party, which we believe we can do it better than you can”.

There was nothing much to talk to them about, but I did mention that if we find major NC (non compliances, in ISMS speak), we would then use that ‘certification audit’ as our own gap assessment and that we might be required to come back again to verify.

The company truly believed that PCI was a subset of ISMS and they handled it as such.

So we came in for the certification and found out that their entire scope was completely messed up. For instance, there was another out of scope network and systems connecting into their CDE for monitoring. Because card data wasn’t passing through, they marked it as out of scope. Unfortunately, PCI doesn’t see it that way. This would be considered an Non CDE In Scope, and systems within this network will need to be secured as well, and hardened as per PCI. The logic is that if these systems are compromised, there is a path into the CDE that can be exploited.

They made a huge fuss on this, claiming that they are willing to absorb the risk and that their management signs off on the risk assessment.

ISMS is a best practice/guideline at best – it’s a great marker for security, but PCI is a standard. If you can’t meet it, then you don’t meet it. Of course, there are ways around this particular issue, but they insisted we passed them simply because their management accepted the risk.

Here’s another idea: PCI-DSS generally doesn’t really care about your business. It’s not about you. It’s about card data. Visa/Mastercard and the Jedi PCI council are not concerned about your business – they are concerned about the confidentiality and integrity of card data. That’s why you will not find any BCM or DRP requirement in PCI. RTO and RPO? Pfft. They don’t care. Your business can go down for 10 weeks but as long as card data is safe, it’s good.

And that’s why, scoping is HUGELY important. Many people might think that a gap assessment is a waste of time. It is, if it’s done incorrectly. I recently witnessed a ‘gap assessment’ report that was a complete mess. It just detailed the PCI twelve requirements and in each requirement gave an overview of the company’s controls and what they should be doing: ripped off almost verbatim from the actual standard itself. That can be downloaded for free.

A gap assessment needs to bring you from one place to another and needs to provide these:

a) A clear understanding of your scope, including a writeup on your network, and processes that have been assessed. It should also be clear what is out of scope. This initial scope usually is not set in stone as remediation would sometimes change what is in scope and what is not in scope. But at least you have something concrete to start with.

b) If possible, an asset register. For PCI. If this is not possible (for many reasons, e.g they have not purchase some assets required for a control), then the asset inventory needs to be prioritised a quickly as possible to see what is scoped and not. Asset should be clear on: Public ips, internal devices, servers, network devices, people involved, desktops, databases etc.

c) Network in scope and out of scope. This is key as companies are required to identify segments scoped out, and do segmentation testing. Also, CDE is clearly marked, NON-CDE IN SCOPE (we call it NCIS) must also be identified. Systems in NCIS could be monitoring system, SIEM, AD etc. Any system that connects to the CDE, but does not store, transmit or process credit card data are considered NCIS. NCIS must be scoped for testing, quarterly scans, hardening and such.

d) Clear roadmap for remediation and recommendations to proceed, specific to the organisation. These ‘gaps’ should all have a corresponding solution(s).

If the gap assessment doesn’t give you any of these, then it’s pretty useless. If it doesn’t move you forward or provide you with the information to move forward, it’s not a gap assessment. It’s an expensive training session.

So back to the first example of a customer. It wasn’t possible for us to certify them no matter how they argued, because simply they were not compliant (there were also many issues that they did not comply, for instance storage of card data in text files and sending via emails).

As a lesson – don’t neglect the proper scoping. It’s hard work, but as I always say: Start wrongly, do wrongly, finish wrongly. And that’s 6 – 8 months down the drain, with thousands of ringgit gone in investing, and job on the line. The second example is pertinent also. There is always a chance to OVERSCOPE as there is to UNDERscope.

An overscoping example would be to purchase all sort of snazzy security systems worth thousands of ringgit only to find that these were not needed, or that current controls were sufficient. It’s nice to have – but most of our customers, no matter how big they are, always have a trigger on the budget and cost optimisation is the topmost in their priority.

If you want us to help you in your PCI-DSS scoping, drop us a note at and we can get you started with the initial understanding straight away!

The Myths of the Top 10 Myths of PCI-DSS


A while back, the PCI council published a good article called the Ten Common Myths of PCI-DSS, to basically debunk a few conclusions people (or so they think) might have on PCI-DSS.

After wading deep into this standard for the past 6 years, I am taking a look again at these myths and I am like, Wait a minute, this isn’t exactly correct.

Myth 1 – One vendor and product will make us compliant

This myth is hard to beat. It’s obvious that one vendor and one product doesn’t make anybody compliant since PCI-DSS is so much more than a product or an implementation. It’s the practice of security within an organisation itself. But wait. Not all PCI projects are created equal, and here’s where we call ‘scope reduction’ comes into play. It is possible that a product can significantly reduce scope so much so that it’s almost easy to become compliant. For instance, tokenization. This is a solution created to remove the need of dealing and storing actual card data in a merchant environment. Instead a token is used and is mapped in the token vault provided by a service provider. Hence, the merchant does not have the key or means to decrypt. Of course, they still handle the first time card data is transmitted through, but it removes the need of the merchant to completely fill the dreaded SAQ D-MER as they no longer need to store card data. Or P2PE for instance. When it started, the solution was to provide a point to point encryption so that merchants need not have the means to manage the keys or decrypt the data. Of course, P2PE bombed and they had to revise the standard to make it more realistic.

Myth 2 – Outsourcing card processing makes us compliant

Again – if you outsource card processing, it might not immediately make you compliant but it sure as heck make it a lot easier to be compliant! With the new revisions of SAQ, we have the nicely flavoured SAQ-A and SAQ A-EP for ecommerce merchants to deal with, to avoid the death knell of SAQ D-MER. There are like 9 flavours of SAQ (self assessment questionaire if you are wondering), and merchants might differ in their journey of PCI depending on their business. Outsourcing to a PCI compliant card processor or payment gateway is a great way to reduce your scope. So while this myth is correct, outsourcing is still a great strategy if payment processing is not your core business.

Myth 3 – PCI compliance is an IT project

Everyone will nod their head in the board room and steering com and agree to this one sagely. But from experience, I will tell you, whether it’s business or IT project – IT guys will be significantly involved in it. If you think you can breeze through this sucker the way you championed through ISO27001, you are in for a little surprise. A large part of the 12 requirements deal with technical requirements, from firewall configuration to antivirus to logical access controls. Logging and key management are significant challenges we find, and an entire requirement 6 deals with patch management and secure coding practices. So, if you are not familiar with terms like OWASP, KEK, DEK, WSUS, TACACS/ACS/LDAP, XSS, CSRF,CVE and all these, it’s time to get cracking. Having done both ISO27001 and PCI, we can say the ISO is more of a best practice/guideline on security while PCI is a standard. It’s either you do or do not. There is no try.

Myth 4 – PCI will make us secure

I know what this myth is trying to say, but technically, if you are practicing PCI, you are a heck lot more secure than someone that’s not. Besides, being ‘secure’ isn’t a final state to be – it’s not possible, but rather it should be a constant practice of a hundred different activities to contribute to ‘being secure’. It’s like when people talk about ‘enlightenment’ or ‘world peace’ – it’s not actually achievable – and even if it is – it’s not sustainable. So yes, PCI will make you secure , relative to the company that has their server under a marketing director’s desk and the password “PASSWORD”.

Myth 5 – PCI is unreasonable; it requires too much

Obviously, PCI Council wants you to think this (again, they are saying these are myths, so whatever you read, PCI Council is asking you to think opposite). They are saying, PCI is reasonable, it doesn’t require much.

I disagree.

It requires a lot.

I mean, OK, if you say SAQ A or A-EP, fine, agreed, it’s a breeze.  But if you are talking about SAQ D or a full cert?

Unless you have unlimited resources, money, time or already practicing some Level 5 Maturity of security, then you need to really look into managing PCI. Most of our clients aren’t in that state, so when you talk to them about the amount of work needed? Oh boy.

Let’s say they have 40 devices in scope. Multiple applications, running on multiple servers. Several layers of firewalls. Firewall rules need to be clean. Sounds easier than it is. The amount of legacy rules we see in some clients would make you think that firewall has been around since the internet was invented. Server upgrades due to EOL. Network changes because the database is accessing the internet directly. Applications not patched. Devices not updated. Logging not centralised. No correlation of logs or event management. No incident management. No central management of passwords and users. Applications developed eons ago and developers have since left the company with the only document being a note saying, “Goodbye and thanks for all the fish!”. You get the drift.

Myth 5 and Myth 10 (PCI is too hard) is the same. When you put the word “TOO” in there, its brings in relativity. What is “TOO” to some companies? When you have a single administrator running the whole thing and he is dividing his time between this and a thousand other things, “TOO” might be the key phrase there. So, I won’t say it’s not possible for a full certification – it obviously is, since we have certified a number – but what we don’t want is our clients walking into PCI with expectations of breezing through and then get slammed like a deer in headlights. It will take effort. It will take resources. It will take money and it will take time. Yeah, time. Around 3 – 4 months if you are lucky for a full certifications. I often get a stunned look of disbelief and a general retort that goes like: “<insert invectives here>, I thought it would only take 2 – 4 weeks, man.”

Look – PCI is really useful and it’s not the intention to discourage people from going for it – but it would be great to be better informed so that expectations can be synced to reality. In the next article, we will cover the remaining myths of PCI.

Sunway ITSSC is ISO27001 certified

Sunway Logo

Congratulations Sunway for being ISMS certified!

The certification link is here.

When we were approached in 2011 to first broach the subject on making Sunway ITSSC ISO27001 (ISMS) certified, it was a daunting task ahead. They had many groups, with a potentially large and challenging scope. Through teamwork and persistence, PKF and Sunway started work in 2012, and in less than a year, they were certified in 2013. Without the amazing tenacity of their employees, it would not have happened, and it was certainly a joy and privilege to be able to be the ISMS consultants during the implementation and gap assessment stage of the project. This is a testimony that with grit and hardwork, along with an unwavering focus on the objectives, nothing is impossible.

PKF offers a catalogue of services for your ISMS needs. We have done gap assessments, implementation advisory, risk management services and even served as independent internal auditors to fulfill the ISMS requirements. Contact us at for more information on how we can help you achieve your ISMS goals.

It was indeed an amazing experience working with such a motivated team from Sunway. Of course, the celebratory dinner and karaoke session was pretty fun too!


PKF IT Opportunities

One of the main reasons we moved the IT advisory function out of internal audit was the fact that IT encompassed so much more than just doing an audit.

I believed in the exponential growth of IT based on the simple belief: IT is integral to efficient and effective businesses. Businesses that do not leverage on IT will go nowhere. So it only makes sense that IT will get more complex and more critical as each year goes by.

Back in 2010, PKF Malaysia realised this pattern. By staying stagnant and doing what the other firms were doing: Internal Auditors doing IT audits, we were going to simply die off. The first thing we realised was that, while Internal Auditors were OK doing IT audits, these were two different animals. We didn’t want to do checklist audits. We didn’t want someone  doing IT audit who didn’t even know what the heck was an AAA server or how to do a simple VLAN config on a Cisco router. We didn’t want someone who would go up to the Audit Committee, put someone else’s career at stake by giving ridiculous recommendations and reports, based on ‘previous experience’ and ‘industry best practices’, when they don’t even know head or tail on what Active Directory is used for, or what’s the basics of DNS poisoning or IP spoofing. We needed serious technical people who have been on both customer and consulting end, and we needed to separate from the Internal Audit group….simply because we want an audit to be done differently.

We moved quickly into ISO27001 (ISMS) and PCI-DSS, we went through ISO27005 for risk assessment, we did COBIT 4.1 training and enablement and got everyone at least CISA certified. Most of us, like me, have multiple certs, for instance in IT forensics, IT ethical hacking, IT management, Project management and so forth.

We moved quickly to become MSC status to be a serious player in 2011, and we started strategic collaborations for different purposes. We joined workgroups with government and private agencies, opening channels to MOSTI, MIMOS, Bank Negara and so on, to conduct knowledge sharing sessions. For free. I am a great believer that contribution back to the industry should be done as part of our professional duty, and not as an engagement service.

So here we are, at the precipice of change. PKF itself has undergone some tremendous changes over 2012 and 2013. This week, we had our PKF Asia Pac Conference, where different countries got together, to explore different areas and opportunities. We’re excited, as we see the work we’ve done in the past 3 years to build our knowledge and reputation, possibly coming to fruition. I am also a big believer that PKF requires an IT function regionally. There should be a Center of Excellence, not just to do IT audit but to do Technical Services like penetration testing and forensics, or troubleshooting and service management; and also project management.

This is where we are. We still have a long way to go, but with the extension of our services into the other firms in PKF, we’re set to stay for a long while.

Here is the link to the presentation we did to the other PKF Firms last week.

PKF Avant Edge – Partner Presentation

« Older posts

© 2021 PKF AvantEdge

Up ↑