Category: PCI-DSS (Page 1 of 19)

Let’s Talk v4: Overview

So, on March 31st 2022, PCI-DSS v4.0 dropped on us.

The original timeline for v4.0 has already passed a long time back. Back in 2019, there had been talks that v4 would drop in late 2020. Then due to the global pandemic of unknown origins, it was moved to 2021 and now finally, they decide to release it in 2022. We all know PCI SSC loves deadlines. They love the whooshing noise deadlines make as they go by.

First of all, let’s start with another quote from the wisest sage of all generations:

Don’t Panic.

Douglas Adams

Because if we take a look at the timeline below, there’s a pretty long runway to adopt v4.0.

The above basically means this:

a) Entities undergoing PCI right now, whether it’s first time or renewals, if you are going to be certified in 2022, your current cycle and next renewal in 2023 can stay with v3.2.1.

b) Entities thinking to go through PCI-DSS, and will likely be certified in 2023, you can stay with v3.2.1 for this cycle, and then for the next renewal up in 2024, you will need to move to v4.0

Long story short, entities have 1.5 years to stay on PCIv3.2.1 and go v4.0 on your 2024 cycle. That doesn’t mean that you don’t do anything from now till then of course. Depending on your processes, there may be some changes. However, it’s not too crazy and it’s more incremental than anything else, including areas where we are already practicing , but was not noted in v3.2.1 (example being anti-phishing controls, which have been a staple for most of our FSI clients).

So we’re going to have a few breakdown of areas we think is fairly relevant to note in v4.0; a deeper dive into requirements that are added or changed, and more importantly how we think a company can move forward in preparation.

Of course that being said, the v4.0 is only 3 weeks old. A toddler in terms of its predecessors. Let’s put it into perspective. PCIv1 (and its sub versions 1.1 and 1.2) lasted almost 6 years from 2004 – 2010.

PCIv2 lasted half that time from 2010 – 2013.

PCIv3 and its sub-versions (3.1, 3.2, 3.2.1) lasted from 2013 to 2022. That’s 9 years old. So in retrospect, we are literally in the 0.6% timeline for v4 if it were to follow the v3 age. Meaning, there could be a lot of changes yet to come, or clarifications or explanations etc.

Over the life of v3, we’ve seen many supplementary documents (for scoping, logging, penetration testing, risk management etc) churned out in support to clarify v3 items. While not part of the standard itself, these supplementary documents and hundreds of FAQs are generally quoted or referenced by us to support our arguments for and against some of the decisions that QSAs put to our clients. These are extremely useful especially when QSAs put in some pretty daft interpretations of the requirements (see our previous post on CDD).

There has been some extremely subtle changes aside from the major ones and we want to note these items in page 4 of v4:

PCI DSS is intended for all entities that store, process, or transmit cardholder data (CHD) and/or sensitive authentication data (SAD) or could impact the security of the cardholder data environment (CDE).

Some PCI DSS requirements may also apply to entities with environments that do not store, process, or transmit account data – for example, entities that outsource payment operations or management of their CDE.

In accordance with those organizations that manage compliance programs (such as payment brands and acquirers); entities should contact the organizations of interest for more details.

pci v4.0 warning to those entities that scream i am out of scope because i don’t store, transmit or process stuff!

There’s a lot of things we dislike about v4.0. But there’s a lot of things we LIKE about it as well. So it’s like that family trip that you are taking with your entire extended family. There’s that cousin that you completely dislike that you wish you don’t need to make small conversations with – you know, the one that constantly name drops and questions whether you have achieve as much as he has in life. And tries to coach you to be a better person and live a better life, and have more than your currently unfulfilling, loveless marriage and a deadend, purposeless job as a PCI-DSS consultant. Yeah, you know it. But at the same time, you like these trips because it’s time with your family as well, and time to goof off with your kids, walk on the beach with your spouse and basically fantasize throwing your cousin into a pit full of vipers. v4.0 is like that trip.

The main takeaways from the above quote would be

a) No more free passes to those entities who claim they are out of scope simply because they don’t store, process or transmit card data. If you have impact on the security of the CDE, then you are in.

b) First time we are seeing the word “Organizations of Interest”. While this is nothing much, it’s like watching a movie in the cinema that’s based on a comic book and you see an obscure easter egg referencing to that comic and you get goosebumps because you know, you’re a nerd. And you like this kind of subtle references that no one else knows about. Basically OIs are the upstream customers, banks, FSI, organisations that are requesting your PCI-DSS compliance. It’s easier now to make this reference as it is now an official term in v4.0. Yay.

c) Organizations that ‘impact security’ is in. Previously the problem is that we had outsourced SOC/NOC, or outsourced providers that do not handle card data (e.g managed providers for firewalls etc) and even cloud services that handle the MFA or authentication generation, claiming that there is no card data, therefore they don’t need PCI. That’s fair enough, but we still need to assess that service as part of an on-demand assessment to ensure that that service is properly secured or at least has basic security functionality over it. While a majority of providers are fine with this, we have had antagonistic providers shouting to high heaven that we are idiots because of the very fact that they do not store, process or transmit card data; they should be completely disregarded from the PCI assessment. Um. No. You’re not and V4.0 is smacking you in the face for this.

Another item on v4.0 is the sheer amount of information they provide right at the beginning of the standard. They are talking about the scoping methods, segmentation, encryption and applicability on third party providers, use of third party providers and how to be compliant with them, BAU best practices, sampling methods, definition of timeframes, definition of words like significant changes, approaches to implementation of PCI-DSS, testing methods, assessment process, RoC writing and if you look carefully, there is also a recipe in there for Jamie Oliver’s Yorkshire Pudding.

In the previous v3.2.1, the requirements started on page 20. In v4.0 the requirements start on page 43. The total number of pages in v4.0 is 360, up 158% from the previous 139 pages. So, simply put, you are going from reading Enid Blyton’s Famous Five Goes to Finniston Farm to Leo Tolstoy’s War and Peace.

The requirements themselves remain as 12, so in essence, despite all the fluff at the beginning, the actual requirements are still intact. There’s quite a fair bit of items to look at, and here we provide a brief overview of it:

a) Customized implementation

So, we have this outcomes-based implementation of PCIv4. This is based on the purpose or the ‘spirit’ of the requirements and may not necessarily use the standards-defined controls to achieve it. So, for instance, the requirement to do quarterly internal scans – the objective is to identify vulnerabilities in a regular interval and to ensure that the organisation addresses this vulnerability. Instead of having an option for on-demand scanning, the organisation may opt to sign up for a continuous analysis and automated scanning that are available in cloud such as Google or AliCloud. So while the controls are different, it addresses the same objective.

It is noted that custom implementation should only be done by organisations with a mature risk management practice in place, as this requires more work for the organisation and the QSA to define tests of these controls.

On how this is implemented or samples of it, I am sure we will be seeing more examples as the standard starts maturing. Remember, v4.0 is still a baby, not even out of the maternity ward yet.

b) Multi-factor and Passwords

Multi factor is now needed for any access into the CDE. So, we call in Multi-Multi Factor – whereby, an MFA is required for remote users to get into the network, and from the non-cde network, to get into the CDE, it requires additional MFA. It would seem fairly straightforward, but companies now have to consider to implement a jump server in the CDE to act as a control aggregator to go to multiple systems in the CDE – or they could just deploy another MFA solution on the network .

Passwords are to be changed to 12 alphanumeric up from 7. There’s still a runway on this as it is only considered standard in 31 March 2025. A lot of things can happen from now till then and a lot of technology can change. We could be facing global climate crisis and end of the world, or world war 3 nuclear warfare, or an asteroid could hit earth, or the Rapture happens, you know, future stuff. But in case none of those things come to past, then yeah, make sure you move your passwords to 12 alphanumeric.

c) Group Accounts

8.2.2 gives a needed reprieve on this kerfuffle of having group accounts. In v3.2.1, this is disallowed, but v4.0 , it is allowed, based on the rule of common sense. Some systems do have group accounts for a purpose, or is unable to provide certain functionality to individual accounts. So while there is now more justifications etc needed, it’s no longer a hard no for group accounts.

d) Targeted risk analysis

Targeted risk analysis can now be done to determine the frequency of certain actions – such as password changes, POI device inspections, non-CDE log reviews, low vulnerabilities remediation, FIM review, frequency of training etc. Now while we want to believe that the PCI-SSC idea on having this is for organizations to change frequencies of controls to be MORE stringent (example to have the password changed every 30 days instead of 90 days), the reality is that most of us would stretch this requirement to make life a lot easier for us. I mean, what’s the point of having flexibility if you can’t make it as flexible (i.e as little work to be done) as possible, right?

e) Card data discovery (CDD)

Card Data Discovery Scans – CDD. There is finally some clarifications on Card Data scans to be done every 12 months and to clarify what we have already covered in our previous post in educating the QSA on how to interpret the particular CDD requirement. So yeah, kudos PCI-SSC for supporting us!

d) Misc – Anti Phishing and Full Disk Encryption

As mentioned previously, we now have references to Anti-Phishing requirements, which should have been there long before, to be honest.

We have clarifications which will have significant impact to some of our clients – the use (or abuse) of the full disk encryption requirement. V4.0 has basically blocked that way out for some of our customers utilising Bitlocker with TPM to get past Requirement 3. This is , to us, a fairly significant item of v4.0 which we will be dedicating a post later on it.

Well, so that’s it for the overview for now. We hope to get more articles out to do deeper dives into v4.0 but like I said, it’s still early days and there would be more clarifications ahead. Hopefully it will be more positive, and the experience of v4.0 will be less like that family outing with the cousin that should be thrown into a pit of vipers.

Contact us at for any queries you have on PCI and we will get back to you immediately.

PCI-DSS Card Data Discovery Scans


For PCI-DSS, there are some fairly obvious requirements that are set in stone in order for you to pass PCI-DSS. ASV scans quarterly. Internal vulnerability scans – quarterly. Annual penetration testing. Half yearly reviews of firewall config and policies. Annual training awareness. These are biblical principles of the gospel of PCI.

And then again, there are other areas where interpretation is a little more of a touch and go; up in the air; subjective to the wind; sort of the things where there are as much disagreements and controversies as whether Han shot first or Greedo was just an absolute tool who misses from two feet.

And while most arguments often stems from our clients and us as we try to explain some concepts to them, there comes once in a while a subject where we find ourselves against the explanation of QSAs. Now, not all QSAs are created equal. When I say QSAs here, I refer to the individual QSA, not the organisation QSA. As in the human being who are QSAs for the QSA-C (QSA Company). We’ve worked with some who are technically well versed; we’ve worked with some who are strong in documentation and theory, we’ve worked with some who can communicate well but not so technical, and those who are opposite. But every once in a while, we come across QSAs who think they know everything (they don’t), and they stubbornly stick to a point of argument even when we have exhausted all avenues to show them their point is flawed. The more we argue, the more adamant they take their stance even if their justifications seem to be plucked directly out of their …. posterior appendages.

One of the items you will often see coming up in PCI-DSS is this thing called the Credit Card Discovery Scanner (CDD). What is this? In PCI-DSS standard pg 10:

To confirm the accuracy of the defined CDE, perform the following:
The assessed entity identifies and documents the existence of all cardholder data in their environment, to verify that no cardholder data exists outside of the currently defined CDE.

PCI DSS v3.2.1

The CDD process is basically just a process using a tool usually to identify whether card information is stored in the clear within the organisation. These are usually regular expressions based applications; where it can categorise the type of card based on BIN or the initial numbers. These tools are often quite useful as well to find other forms of information like personal information etc, as long as you can identify filters and regular expressions for them. Some tools out there are from Groundlabs, Managed Engine, ControlCase etc. We also have free CDD tools like Pan Buster, Credit Card Scanner etc. The free tools are a little bit more difficult to use in our opinion and there seems to be less support for database scans and more false positives overall, so you may spend a longer time cleaning up the results.

Whether commercial or free tools, what PCI has been fairly silent about is whether these are mandated in the standard to be done. Unlike ASV scans or penetration testing, the standard doesn’t specifically state the need to run these tools for a normal PCI-DSS standard. When I say ‘normal’; I refer to a set of additional requirements under Appendix A3: Designated Entities Supplemental Validation (DESV) . These are specially assigned entities that has large volume of card data or has suffered significant breaches. This is designated by payment brands or acquirers, and it’s not something a QSA or even the audited entity decides on.

So looking into the card data scan requirements; we only have the Pg 10 scoping requirement and in the DESV portion , A.3.2.5 – “Implement a data-discovery methodology to confirm PCI DSS scope and to locate all sources and locations of clear-text PAN at least quarterly and upon significant changes to the cardholder environment or processes”

In most cases, CDD scans are done on an annual basis for normal PCI-DSS (non DESV), or at times half-yearly as required by the QSA.

So along came another QSA who stoutly declares that all companies are required to do a quarterly CDD scan regardless of size for all systems in scope. When politely reminded that he seems to be mixing up the DESV quarterly scan requirements; he says no. He is highlighting requirement 3.1: “A quarterly process for identifying and securely deleting stored cardholder data that exceeds defined retention.”

When pressed to explain why this is a CDD scan, he states its obvious, that everyone needs to run the CDD scanner every quarter to address this requirement.

OK. We disagree. Completely. This is one of the instance, where QSA super-imposes requirements on each other just because it sounds the same.

Let’s break it down by looking at the PURPOSE of the CDD scan. And the best way is to go back to the standard and pick up the part where the standard states a ‘data-discovery’ method in DESV A3.2.5.

Implement a data-discovery methodology to confirm PCI DSS scope and to locate all sources and locations of clear-text PAN

A3.2.5 PCI-DSS V3.2.1

It’s clear that the CDD purpose is to locate where CLEAR-TEXT PAN is found in the CDE (and non-CDE) environment. Why is this important? Because in the CDE, there should never be any clear-text PAN found in storage. All PANs must be protected by either of the Four Horsemen of the Apocalypse: Encryption, Truncation, Hashing or Tokenization. A failed CDD means there are card PAN found in clear text within the CDE.

So with that in mind, lets go back to requirement 3.1. This is nothing to do with identifying clear PAN. It talks about identifying AND deleting EXPIRED card data (based on retention policies). That’s it. If the PAN is encrypted or tokenized but its stored beyond its retention period; requirement 3.1 tells you to delete it. It talks about retention period and storage beyond it. Which part of it talks about doing a card data scan to identify clear text card information?

In the description, it further states: A quarterly process for identifying and securely deleting stored cardholder data that exceeds defined retention requirements.

So QSA, please RTFM; requirement 3.1 isn’t talking about the need to run CDD quarterly to identify clear-text PAN storage; it is to run something (script) or manual; to identify PAN storage that is already expired. It is to discover duration of storage; not security of storage. Running a shell script may be good enough to get the timestamp of files; or checking the timestamp on the database entries to ensure that all card data is removed or anonymized after a period of say, 7 years.

If you need assistance in PCI-DSS or any other compliance standards like the ISMS or ITSM, drop us a note at We can help clarify some of these annoying requirements that even QSAs (as experienced as they are) are plucking out of their rear appendages.

PCI-DSS 2022 and Version 4


So we are now in 2022. PCI-DSS v4.0 is due to be out and one of the things we have been doing for the first two weeks of the year is to get over our holiday hangovers. That’s right. In our country (Malaysia), the slowest months are December, January and February. It’s like starting a car in the dead of winter. These 3 months are like the Amen Corner in Augusta for businesses. December hits like a ton of bricks due to the Christmas season; and then just when things start moving in January, it grinds to a halt for Chinese New Year, where the entire nation just flat out refuses to work. When we are back in the second week of Chinese New Year, we are once more in first gear climbing up the hill again of 2022.

So we did things a bit differently. We started the first two weeks with a series of training for clients and potential clients, to go through PCI-DSS v4.0 and create an awareness of what is there to expect.

The above is taken from the PCI website and immediately we see some interesting things here. Number one: PCI-DSS v3.2.1 only retires in 2024. This is interesting, because usually the transition period isn’t so long. It’s long now because – I don’t know, there may be an ongoing pandemic and such. So here we are Q1 2022, and our customers are asking when do we transition to v4.0?

Well, the answer would be: as soon as you can. But in theory, you can probably stick to v3.2.1 validation for 2022 and realistically move to v4.0 in 2023. In fact, for some of our clients whose PCI maintenance period follows the calendar year, they can even force 3.2.1 into their 2023 validation year.

As for the actual content in PCI v4, it’s still a well kept secret like the plot of Spiderman: No Way Home; but we have been reading a bit and also have joined last year’s PCI-DSS community meeting and learnt some interesting tid-bits of it.

No 1: Compensating Controls

The-get-out-of-jail-free card. Customers have been dangling this Compensating Controls card in front of our faces ever since the Mesopotamian times. When they can’t address a control – use compensating controls! When they cannot implement something due to budget – compensating controls! When they can’t make changes to an application because it was designed by a group of kindergarten kids and it would break the moment you touch it – Compensating Controls! When you don’t know what to say to your wife after a long night out at the pub with the mates and come back smelling like a keg of kerosene – Compensating Controls!

The problem with compensating controls is that they are a pain in the neck to implement and to document. And to justify. The compensating control worksheet, the justification documentation, the implementation of the control itself to be ‘above and beyond’ the scope of PCI-DSS etc. Everyone things this is a silver bullet only to find it the deepest rabbit hole you can ever fall into.

So, PCI v4 does away with compensating controls. Great.

And they introduce Customized Implementation.

A lot of people are saying this is a game changer.

Honestly? Until more information comes out, we only have this to go with:

Customized implementation considers the intent of the objective and allows entities to design their own security controls to meet it. Once an organization determines the security control for a given objective, it must provide full documentation to enable their Qualified Security Auditor (QSA) to make a final decision on the effectiveness of a control.


Design their own security controls? Well, ok, isn’t this the same as compensating controls? I am thinking this just expands the interpretation to something a bit broader in which case the control may not even be a technical control. So instead of stating , ok, we can’t meet certain password controls due to the legacy application issue, and compensating controls were previously excessive logging and monitoring; isolation of network, whitelisting of IPs and access; using WAF and DLP and Virtual patching etc etc; are we stating now, a possible customized approach would be: instead of all these technical controls; we now have a customized security approach. Which includes isolation of network, whitelisting of IPs and access; using WAF and DLP and Virtual patching etc etc.

Until we see some examples of this, it may just be well that most companies will go along with the ‘normal’ approach; or adopt a wait and see approach and eke out the last remaining drop of v3.2.1. into 2024.

No 2: UP in the Clouds

Another item that has been long overdue? Cloud. It’s about time things get addressed and not just cloud, but how services and containers work as well. We have had auditors coming to our clients insisting on them doing testing, VA/PT on services from AWS, not recognizing there’s not even an IP address to start with. To be fair to the SSC, they do have a few Cloud Guidelines Supplementary documentation, which we actually find very useful especially in our projects on certifying cloud technologies. We can see this being incorporated more formally into v4.0 where the requirements will be designed around Cloud environment more organically than what we see right now (sort of force-fitting many of the traditional concepts like Network IDS, Patching etc into the cloud environment).

No 3: Not another MF-A!

I have a bad feeling about this.

MFA has been a constant pain for us. Firstly, where MFA is being implemented – not just on perimeter but now on every access to the CDE. At least it’s now still on admin accounts. We hear they plan to introduce for ALL users. We also hear the collective screams of the tormented from the nine hells of Dante. Secondly, a lot of customers are still depending on MFA via SMS. If PCI goes along the NIST route, we could see this being deprecated soon. Also, clarifications as well on whether client side certificate are acceptable as a ‘something you have’ factor would be most welcomed. We see different QSAs interpreting this so differently you’d think we’ve asked them to interpret some ancient Thuggee text. Multi-factor challenges are already there for us over the past years, with Bank Negara’s RMIT focus on ‘strong MFA’ for large financial institutions. A clear guidance also should be there on how to evaluate multi-factor that is dependent on a cloud provider; and whether common implementation like Google Authentication etc can still be considered as good enough for V4.0

No 4: Encrypting everything

We also hear now that the “Pocket Protector Trope” security may be implemented. Remember those movies we watch, where the hero gets shot in the chest and you think he dies but he reveals that the bullet is stopped by his pocket watch; his badge; a bible; or some other dang sentimental thing that was given to him like 40 scenes ago?

So in PCI, usually when data is traversing the internet or network, it states the transmission needs to be encrypted. It doesn’t technically state anything about encrypting the data package itself while in transmission. The data encryption almost exclusive occurs during data at rest. So in this case, they are doubling the protection: They are adding that pocket watch to catch the bullet; so if the transmission gets compromised, the data is still secured. The bullet doesn’t hit the hero!

No 5: Recovery and Continuity

Not so much as something coming, but more of what we’d like to see. One of the biggest criticism we see customers bemoaning at PCI (other than the cost and budget and the complexity and..ok, everything else) – is that PCI has little focus on business continuity and disaster recovery. It’s almost as if PCI is standing there saying, “OK, you have outage for a few days? Great, make sure your credit card information is safe.” It’s not really business focused, it’s more credit card confidentiality focus. What we would like to see is a little more focus on this area. Over the past 2 years, we have seen customers getting all sorts of attacks from cyberspace. Malware, ransomware, hacking, fraud, defacement — it’s like the world goes into a pandemic and everyone’s bored to bits at home and everyone is taking up hacking as a part time gig. Malware for instance – how prepared is a PCI compliant company against ransomware attack? Have they done their backups? Have they tested their systems to recover?

So, if you have any queries on PCIv4 for us, drop us an email at and we will definitely get back to you. Have a great and safe year ahead for 2022!

PCI-DSS and Card Storage


We had an interesting discussion a few weeks back about storage in PCI-DSS. We disagreed with an acquirer’s position in how PCI-DSS views storage and therefore opened a whole can of … interesting debate.

The problem the acquirer had with our position was simple. We have a client who is currently doing a data migration import from another service provider to their document management system. Amongst the terabytes of data were possible scanned copies of credit card information, either in forms or actual card photo-copies themselves. Now, we are talking about terabytes.

Our position was fairly straightforward. Do you need these card data? We asked. No, said our client. We don’t need the card data as we do recon and backoffice operations on other form of identification. Can these information be removed or redacted? Bemused, they said, possibly, but the problem is that there are going to be millions of records to be dealt with.

Well, is there a way we can sanitize the data before it enters into your environment?

Yes, possibly, we need to ask the acquirer to ask their current provider to do it for us.

The provider you are taking business away from?


Good luck…

And sure enough, the acquirer responded and asked us, “Shouldn’t PCI-DSS allow the storage of these card information, and how your client is able to deal with it? Why do you insist on us redacting and removing the card information? What then is the purpose of PCI-DSS??”

Now, on the surface, that argument does make sense. After all PCI-DSS applies to entities who store, transmit and process credit card information right? Why then wouldn’t we want our client to store credit card information if they are going through PCI-DSS?

Unfortunately, this is a case of getting the solution (PCI-DSS) mixed up with the problem(storing card data). In other words, in a more current analogy, just because I got vaccinated doesn’t mean I would purposely go out and try to get infected so that the vaccine has something to do. The purpose of PCI isn’t for you to store credit card. It’s for you to manage the storage of credit card IF you store it. Storing credit card isn’t a PCI-DSS objective, its an issue that PCI-DSS tries to solve.

So back to this little kerfuffle; if they pass us terabytes of information with card data, our client will need to figure a way to protect this data. Likely encryption of any information that card data is present, which includes key management etc. If they can redact it and remove it before it enters into our client’s environment, then we avoid it. We are basically following the concept of PCI-DSS :

Requirement 3 addresses protection of stored cardholder data. Merchants who do not store any cardholder data automatically provide stronger protection by having eliminated a key target for data thieves. Remember if you don’t need it, don’t store it!

PCI-DSS Prioritized approach

If we don’t need it, don’t store it. In this case, we don’t need it, so we are trying to escape storing it. However, if this cannot be done (which likely it won’t be), then we just need to put controls in there. We’re trying to get our clients to do less and we are also trying to remove card footprints in other areas, thus reducing the risks to the card brands, and likely save the world from impending disaster and destruction.

However, we do have another issue.

Because there is potentially CVV storage (photocopy of cards front and back) and scanned into softcopies, we have a bit of a problem. CVV cannot be stored in any format or in any media post authorisation. So therefore, if this is being dumped into our client’s environment, it’s imperative someone removes this information. To us, its a lot easier to remove it at source; but unfortunately that means there is an effort to be spent on it, which no one is willing to do.

How the CVV got stored in the first place is a question that we don’t have an answer to. However, we do know that if CVV is present, we cannot just encrypt it and be done with it. We will need to remove these information one by one. There are a few solutions out there that can do auto redaction and be applied to a massive amount of files, provided that the files are in a sort of standard fashion. That could be a solution on this, but again, it’s beyond what we are discussing for this article.

The point is, having PCI-DSS doesn’t automatically mean we MUST store card data. It simply means IF we store card data we are applying PCI-DSS controls to that storage of card data.

Let us know if you need more information about PCI-DSS or any IT standard compliance like ISO27001 or CSA/SOC, we are ready to assist, just contact us here. Stay safe everyone!

Hardening Checklist

Requirement 2.2 has been often deliberated by customers undergoing PCI-DSS. To recap, the requirement states:

Develop configuration standards for all system components. Assure that these standards address all known security vulnerabilities and are consistent with industry-accepted system hardening standards.
Sources of industry-accepted system hardening standards may include, but are not limited to:
• Center for Internet Security (CIS)
• International Organization for Standardization (ISO)
• SysAdmin Audit Network Security (SANS) Institute
• National Institute of Standards Technology (NIST).

Requirement 2.2

So often, customers go ahead and download the CIS hardening documents at and copy lock stock and barrel into their policies and send it in. Now all this may be well and good, but now you have around 1,200 page tome with guidelines like 14 character alphanumeric password, as opposed to what PCI requires (7 Alphanumeric). This is where our customers get stuck, and some even send in a 1000 page hardening document to us to review, only for us to find that they have not implemented even 1% of what is noted in their hardening document.

After that, the hardening documents get re-jigged again until it meets a reasonable, practical standard that is implementable, usually in the form of a checklist. For a very quick hardening checklist, this is the initial one we often end up using, just to get our clients up to baseline speed, whether it’s PCI or not:

Hardening ItemServersNetwork DevicesDatabases
Assign individual server for each critical role (App, Web, DB, AD, AV, Patching etc)YNAY
Disable/Rename/Remove default user accountsYYY
Assign role based access to usersYYY
Disable insesure or unnecessary servicesYYNA
Use Secure Versions of Remote Access Services (SSH, RDP over SSL)YYY
Install well known Anti Virus with latest signaturesYNANA
Install latest OS / Firmware / Software security patchesYYY
Disable inactive users automatically after 90 daysYYY
Ensure Following Password Policies –
1. Use Complex Password with 7 characters or more
2. Remember minimum last 4 Passwords
3. Require passsword change within 90 days
4. Require password change upon password reset and first logon
Ensure following account policies –
1. Account lockout threshold – Max 6 attempts
2. Account lockdout duration – 30 mins or until admin unlocks
3. Idle Session Timeout – 15 Mins or less
Ensure passwords are stored securely with encryptionYYY
Enable Audit logging to Capture at minimum following events –
1. Successful Login
2. Failed Login
3. Administrative Actions
4. User Creation
5. User Deletion
6. User Updates
7. Escalation of Privileges
8. Access to Audit Trails
9. Initialization or stopping auditing
Configure NTP and time syncronizationYYY
Implement File Integrity Monitoring`YYY

Now obviously this doesn’t cover all the requirements of PCI (testing, scans, retention etc) but this should give us a fair idea of how ready our systems are for an audit or assessment.

If you have any queries on PCI or ISMS or any other security related standard, drop us a message at

« Older posts

© 2022 PKF AvantEdge

Up ↑