Updated PAN Truncation FAQ

As part of the holiday giving tradition, the PCI SSC has given us an updated FAQ (#1091) on the subject of PAN truncation and it will likely go down as the most confusing FAQ ever.

The FAQ starts out simple enough with the statement:

“A maximum of the first 6 and last 4 digits of the PAN is the starting baseline for entities to retain after truncation, considering the business needs and purposes for which the PAN is used.”

But it is the table that follows that gets messy.

It seems that each of the card brands has their own take on PAN truncation based on PAN length and other factors. Only American Express has stayed the course.

Based on the guidance for UnionPay, Visa, Mastercard, JCB and Discover, the idea of first six/eight and ANY OTHER four is a bit bizarre not to mention risky.

Never mind the obvious warning note at the end of the FAQ that states:

“Access to different truncation formats of the same PAN greatly increases the ability to reconstruct full PAN, and the security value provided by an individual truncated PAN is significantly reduced. If the same PAN is truncated using more than one truncation format (for example, different truncation formats are used on different systems), additional controls should be in place to ensure that the truncated versions cannot be correlated to reconstruct additional digits of the original PAN.”

Personally, I would stick with the good old first six, last four and avoid any of these other formats as you are likely setting yourself up for problems and PCI non-compliance.

Happy holidays to all!

Advertisement

Remote PCI Assessment Guidance Issued

At the end of September 2021, the PCI Council released a Guidelines and Procedures document on conducting Remote Assessments for PCI and card brand assessments.  Most of this document is a rehash of previous Council statements and guidance.  However, there is one new element in this document that all QSAs will need to read and comply with and that is the requirement of documenting a feasibility analysis to justify conducting a remote assessment.

Some of the examples the Council gives as valid reasons that an on-site assessment may not be feasible includes:

• Restrictions on the ability to travel or meet in person due to health and safety concerns or government advisories.  We are all familiar with the COVID-19 pandemic and its impact on travel, particularly international travel.  However, I encountered this a while back due to a volcanic eruption in Iceland that cancelled my trip to Europe.  Since we had no way of knowing how long the eruption would cause travel disruptions and we were on a tight timeline, we conducted video conferences rather than travel.
• Geographic locations that are physically inaccessible or difficult to reach.  I personally ran into this situation one several years ago when a data center in Europe that was supposed to be decommissioned before the next assessment remained operational.  The company I worked for had shut down their EU operations and there was no way to justify 16 hours of flight time for a two-hour data center walk through.  We held meetings with the data center operator via video conference and did a virtual walk through.
• Testing required at a location is limited to documentation and interviews and no observations of processes, systems or physical environment apply.
• The entity operates a virtual environment without physical premises or facilities.  This has become more and more common with entities that operate in The Cloud.  Why rent expensive office space when there is not need for it?  This situation only got more prevalent with the pandemic and will likely only increase in the future.

As the Council states in their guidance,

“For many assessments, a combination of onsite and remote testing may provide a suitable balance, as it allows for increased efficiencies in the assessment process while enabling an appropriate level of assurance to be achieved in the assessment result.  For example, documentation reviews can often be performed remotely without significant loss of assurance, whereas observations of processes and environmental characteristics will generally require an onsite review.”

Regardless of whether the assessment fits into one of the bullets above, the Council wants QSAs to formally document their analyses of why the onsite assessment cannot be performed and the risks that may present to meeting the assessment objectives.  This analysis needs to be completed prior to starting any testing and is supposed to be a joint effort between the assessor and the client.

Topics that the Council recommends be addressed include, but are not limited to:

• Confidentiality, security, and data protection requirements.
• Availability and effectiveness of the remote assessment technologies.
• Effects on entity’s personnel.
• Effects on operation support.
• Assessment scope and completeness.
• Quality and reliability of digital evidence.

The Council further states:

“During the analysis, the entity and assessor should identify any challenges and potential risks associated with the remote testing and determine whether it is feasible for testing to be thoroughly completed to produce a high level of confidence in the assessment results.

The results of the feasibility analysis—including the risks and challenges associated with use of the remote testing methods, and any mitigating controls for overcoming the risks and challenges—should be documented and agreed upon by both the entity and assessor. A copy of the feasibility analysis results should be included with the applicable ROC/ROV. Entities and assessors may be required to produce the analysis upon request by the PCI SSC or applicable compliance-accepting entity.”

The key points from that statement above is that: (1) the feasibility analysis needs to be submitted with the ROC/ROV and, (2) if requested by the PCI SSC or compliance accepting entity (i.e., Brand or bank), the QSA is required to produce the analysis.  As a result, this is a non-optional exercise.

The feasibility analyses must document that:

• The assessment is feasible to be fully completed at this time using onsite methods, remote methods, or a combination of onsite and remote methods.
• The assessment is only feasible to be partially completed at this time.
• The assessment is not feasible currently.

According to the guidance, it is only those assessments that are completely feasible that can be conducted.

The Council includes a very important note regarding the analyses.

“The feasibility analysis determines whether the use of remote testing methods is feasible for a particular assessment.  Determining that a remote testing method is feasible does not guarantee that use of the testing method will produce the level of assurance needed for the assessor to reach a finding; this will depend on how the remote testing method is implemented and used, whether the testing can be completed for all applicable components and areas, and whether sufficient evidence is provided for the assessor to make a determination.  Assessors and entities should continue to monitor and evaluate the effectiveness of the remote testing methods throughout the assessment to confirm whether the testing methods are performing as intended and whether additional testing may be needed.”

This concept of “assurance” appears to all be in the eye of the beholder.  Meaning, if the Council, Brands or Banks determine, in their opinion, that the remote methods are not providing appropriate levels of assurance, the ROC/ROV can be rejected.  Not that a lot of banks are going to reject ROCs/ROVs on this, but I can see the Council’s AQM reviews and Card Brands rejecting ROCs/ROVs on analyses that they deem flawed or incomplete.  The AQM process is the most concerning because a QSAC could end up in remediation due to a failure to appropriately document the remote assessment feasibility.

As with most edicts issued by the Council, they should have produced a form for this feasibility analysis so that everyone understands what is required from these feasibility analyses.  Can the feasibility analysis be documented in section 1.2 of the reporting template or is a separate document required?  I would recommend this for the obvious remote assessments of COVID and everything in The Cloud.  I would recommend a separate document for feasibility analyses that are longer in discussion.

Sadly, I foresee a lot of confusion and heartache in the QSAC community as we move through this new requirement.  That is because I see a lot of assessments that are blocked due to COVID travel restrictions or the assessed entity having no physical offices being rejected for “flawed” feasibility analyses when it should just be allowed with no further documentation or discussion.

It will take time to see how this shakes out.

UPDATE 11/29/2021 – I received a comment on this post (see below) and the confusion is beginning. A service provider has had one of their customers request the documentation regarding what is provided in Appendix A of the remote assessment guidance document as well as the remote assessment feasibility study. Since these are ROC documents, there is no requirement from the Council that requires any organization to turn over their ROC to any third party other than their acquiring bank or the card brands. The AOC is the communication document to third parties. If an organization wishes to turn over Appendix A from the guidance, that is the organization’s decision, but it is NOT mandatory nor it is required by the Council.

Last PCI DSS v4 Request For Comments Period

According to an email I received today, the draft validation documents (I am assuming that means the ROC Reporting Template and AOC) will be released on Monday, June 28, on the PCI Portal for QSAs, ISAs and POs to review and comment.

The comment period will be open for 30 days from that date.

Make sure you get your copy, review the documents and generate comments as this is your chance to have input on the PCI DSS.

April 2021 Assessor Newsletter

A couple of interesting items in this month’s Assessor Newsletter that came out on April 30.

All Assessor Webcast

The first thing is the June 15 All Assessor Webcast that will be held at 1430 UTC and will be an hour and a half long. I reached out to some contacts I have and they are all mum as to what could possibly take an hour and half to discuss. Given that the final RFC of PCI DSS v4 might be out by then, it could be there will be a discussion of that document. Regardless, I would recommend everyone sign up to attend this session.

QSA v4 Training

Another little interesting tidbit was in the QSA Program Changes. I do not recall hearing about this in the past, so that is why I found it interesting.

“QSAs can only perform assessments using versions of the standard for which they have received PCI SSC training:

– This requirement only applies to major releases of the standard, it does not apply to minor revisions.

– Once a QSA completes the PCI DSS v4 Transitional Training, an indicator will be added to the QSA Assessor listing on the Website.”

From what I can gather, what this means is that until a QSA has attended the PCI DSS v4 Transitional Training, a QSA will not be able to conduct a PCI assessment using the v4 template. As a result, I am guessing that attendance at these training sessions will be at a premium as QSAs will want to attend them as soon as possible. Hopefully these will be online sessions so that getting into them early are not as big an issue as would be for in-person training.

QSAC QA Questionnaire

For those QSACs that have been looking for the annual QA Questionnaire, it was released on March 24 and is posted on the PCI Portal under the Resources Center. So make sure you download it and go through it as soon as you can.

FAQ of the Month

The final tidbit is regarding this month’s FAQ #1325 entitled ‘Does PCI SSC provide a “PCI DSS Compliant” logo?’.

“PCI SSC does not issue an official PCI seal, mark or logo that companies can use when they achieve PCI DSS compliance. Please note that the PCI logo is a registered trademark and may not be used without authorization. You may not use the marks PCI Compliant, PCI Certified, PCI DSS Compliant, PCI DSS Certified or PCI with check marks or any other mark or logo that suggests or implies compliance or conformance with our standards. If your company is a member of one of PCI SSC’s programs, i.e. PO, QSA, ASV, ISA, or QIR, please contact your Program Manager who can provide a program logo that can be used for members of that program only. Note that authorized use of an applicable PCI logo by a program member is not an indication of that organization’s PCI compliance status or an endorsement by PCI SSC.

April
Article Number 1325″

This ranks up there with FAQ #1220 on the subject of PCI compliance certificates and the fact that they are worthless. Why these continue to be allowed to go on, I do not understand. I suppose until the Council begins putting QSACs in remediation for these incidents, they will continue.

Just thought these topics were worth sharing in case you missed the latest newsletter.

No 2021 Community Meetings

So much for getting together this year for a PCI Community Meeting anywhere in the world.  The Council sent out an email on Wednesday, April 21, that explains what will replace those events.

“PCI SSC is excited to announce the most important global online event for the payment card industry. New this year, the PCI SSC Global Community Forum will bring together industry experts from all over the world to share the latest in information security, update you on changes to PCI standards and programs as well as provide opportunities to network with peers. The PCI SSC Global Community Forum will take place online from Tuesday, 26 October – Thursday, 28 October.
This global online event held over the course of three days will include all the things you expect from PCI SSC events – important Council updates, regional insights, opportunities for feedback, networking, and fun engagement activities. Given the uncertainty of travel and international border restrictions, the Council has made the decision to offer this online event with dedicated days for each region presented in local time zones and cancel its 2021 in-person Community Meetings in North America, Europe, and Asia-Pacific.
Global Community Forum speaking submissions are still being accepted through Friday, 23 April at 11:59 PM EDT.”

Hopefully we will all get together in person sometime in the future.

Quick Update on PCI DSS v4

In the February 2021 Assessor newsletter, the Council announced the following.

“Because of the broad impact PCI DSS has on the payment community, the Council is seeking additional feedback into the PCI DSS v4.0 validation documents. As a result of expanding stakeholder feedback opportunities to include these supporting documents, the Council is now targeting a Q4 2021 completion date for PCI DSS v4.0. The publication and availability of PCI DSS v4.0 is still being determined. The Council will communicate the targeted publication date in the coming months.”

So we will apparently see one more iteration of v4 before it is released. According to their blog post, the comment period will start around June 2021.

See their blog post for more information.

One other important item from the newsletter for all QSAs, do not forget to register for the next All Assessor Webcast on March 18, 2021.

The 2020 PCI Community Meetings Go Virtual

A lot of us remember when the 2017 NACM in Orlando was cancelled due to Hurricane Irma.

Troy Leach announced on Twitter yesterday that the 2020 NACM would be virtual as would all of the other Community Meetings.

It will not be the same, but at least we will be virtually together.

The Last (Hopefully) Scoping Discussion

Back in May 2017, the Council finally issued their long awaited Information Supplement on Scoping and Network Segmentation.  Based on some questions I have received since then, there are apparently a lot of people that still have not read the official information supplement.

So, I am invoking “RTFM” which means the first order of business is to get everyone to read the information supplement before asking questions.  The second order of business is to forget everything that was discussed in the Open PCI Scoping Toolkit as the Council will tell you it does not apply and never did apply.  Even though they never offered any alternative until the publication of the aforementioned information supplement.  So, throw away all your copies of the Open PCI Scoping Toolkit as it is not usable anymore.

With the Council’s information supplement, there was a change in terminology in how we refer to the various network segments and what is in scope.  As you will see, the Council’s approach has simplified the scoping classifications.  Because of the pervasiveness of the Open PCI Scoping Toolkit, I have included some references to the categories used in the Toolkit to clarify the Council’s terminology.

• Cardholder Data Environment (CDE) Systems – These systems are always in scope for PCI compliance. These are systems that are either: (1) a system that directly processes, stores or transmits cardholder data (CHD) or sensitive authentication data (SAD), OR (2) a system or component that is on the same network segment (i.e., same network subnet or VLAN) as a system component that directly processes, stores or transmits CHD/SAD.  With the Open PCI Scoping Toolkit, these were considered ‘Category 1A/1B’ systems.
• “Connected To” or “Security-Impacting Systems” – These systems are also always in scope for PCI compliance. These systems are basically those that directly connect to systems in the CDE or could influence the security of the systems or data in the CDE.  In the Open PCI Scoping Toolkit, these were the ‘Category 2A/2B/2C/2D’ systems.  Unlike in the Open PCI Scoping Toolkit, the Council chose to simplify things and have only one category versus the “shades of gray” approach.  That said, there are more detailed criteria defined on page 10 of the information supplement that define these systems.  Examples include, but are not limited to, Active Directory (AD) servers, RADIUS servers, TACACS+ servers, Security Information and Event Management (SIEM) solutions, Network Time Protocol (NTP) servers, Domain Name System (DNS) servers and Domain Host Control Protocol (DHCP) servers.  These systems and devices can also be considered as “Shared Services” because they provide service not only to the CDE but also to out of scope systems.
• Out of Scope Systems – There are four criteria for these systems: (1) The system must NOT process, store or transmit CHD/SAD AND  (2) the system cannot be on the same network segment or subnet as the CDE. AND  (3) the system cannot directly connect to any other system or component in the CDE  AND  (4) The system does not meet ANY of the criteria described for “Connected To” systems.  If all of these criteria are met, then the system is out of scope.  In the Open PCI Open Scoping Toolkit these were the ‘Category 3’ systems.

As we have found out at the Community Meetings since the publication of the information supplement, the Council will demand you use their scoping terminology.  If you use the Open PCI Scoping Toolkit scoping categories, you will be asked to restate your questions or comments using their terminology.  So please from here on out use the Council’s terminology whenever discussing scoping categories.

Why Is Scoping A Problem?

Scoping is a problem because organizations think it is the QSA’s problem.  However, the PCI DSS states on page 10:

“At least annually and prior to the annual assessment, the assessed entity should confirm the accuracy of their PCI DSS scope by identifying all locations and flows of cardholder data, and identify all systems that are connected to or, if compromised, could impact the CDE (for example, authentication servers) to ensure they are included in the PCI DSS scope.”

Eight times out of ten, it falls into the QSA’s lap to determine and confirm PCI scope even though it is the assessed entity’s responsibility to define scope and the QSA’s role is to confirm that analysis.  This is why arguments over scope happen.  QSAs get into trouble because they follow the processes defined below and determine that the scope is not correct.  Had the assessed entity done their work, the argument likely would not have happened or at least would not have been as big as it became.

The purpose of this post is to explain what your QSA is doing when they asked for all the documentation and what they are doing that your organization should be doing before the QSA even shows up.  For QSAs, this is what you should be doing to ensure that the scope of your engagement is correct.

Follow The Data

The first thing that people seem to get wrong about scope is fixating on the storage of CHD and ignoring the processing and transmitting of CHD/SAD.  This is a big reason why voice over IP (VoIP) gets missed.  VoIP typically never stores CHD/SAD.  But when customers are making payments over the telephone, CHD/SAD is being discussed and that is what makes the telephone system a CDE and therefore in scope for the PCI assessment.

The key to resolving this is to follow the CHD/SAD through your networks.  When he was a Council trainer, Art (“Coop”) Cooper was famous for constantly telling his classes to, “Follow the data.”  Therefore, the data flow diagrams overlaid on your network diagrams are so especially important in determining PCI scope.  Done properly, these diagrams allow you to understand where the CHD/SAD flows through your organization (i.e., transmission), where it is processed, as well as where it ends up stored.

From that analysis, you can then document where, if anywhere, the CHD/SAD is encrypted and who manages the encryption keys.  If your organization manages the encryption keys, then you will need to prove and document that those intermediate devices between the encryption endpoints cannot decrypt the CHD/SAD in order to keep them out of scope.  If an outside third party manages the keys, then scope is reduced to where the encryption endpoint is in your environment.  For more about encryption and scope, see my Encryption Series of posts listed on the Post Series References page.

Once you have completed this activity, you have defined your CDE, likely many of them.  It is not unusual for organizations to have their VoIP network and solution as one CDE and then another for their eCommerce or brick & mortar retail.  But there could be even more CDEs depending on your environment.

One other caveat on scoping CDE.  Devices that are in the CDE that do not process, store or transmit CHD/SAD are in scope for PCI compliance.  These include devices and systems such as jump servers, switches, routers, Active Directory domain controllers, DHCP servers, DNS servers and firewalls.

And that is the rub in this process.  It is not unusual to have a client determine that their CDE is larger than they originally believed.  This is particularly true in environments that are rapidly changing.  The reason is that changes occur that involve the processing or transmission of CHD/SAD and people forget that those are also in scope because of their fixation on storage of CHD.  So do not be surprised to be surprised when this analysis turns up with in scope devices that were not believed to be in scope.

Connected To Systems

With the CDE(s) defined, we now we need to define all the systems that connect to the CDE(s), hence the “Connected To” designation by the Council.  The reason Connected To systems are in scope is because they can influence the security of the systems and devices inside the CDE.  The term you will hear some people use is that Connect To systems can be ‘infectious” to systems in the CDE.

The first place to start is by reviewing the firewall rules or access control lists (ACL) that segment your CDEs from the rest of your network segments.  You will likely find specific IP addresses for devices such as Active Directory domain controllers, security incident and event manager (SIEM), FTP, DNS, DHCP, RADIUS, TACACS+ and similar services.  It is not unusual to see application and database servers in a complete network subnet.

The second place to investigate are the organization’s most recent penetration testing results for network segmentation.  It still amazes me how even with a detailed examination of the firewall rules and ACLs that there are still devices that end up with connectivity into the CDE because of human error examining the rules and ACLs.  So use the network segmentation testing to double check your review of the firewall rules and ACLs.

Once you have identified all these networks you then need to make sure that you have an accurate inventory of all the systems and devices on these networks.  I typically ask for Nmap scans of the network subnets to make sure the inventory is complete.  I take the Nmap results and compare those to the organization’s configuration management database (CMDB) or whatever they use to track their system/device inventory.

I also make sure that all the devices and systems found in this process are contained in their internal vulnerability scanning.  Again, it is not unusual to find out that devices and systems are not being scanned quarterly for PCI which is why this check is important.

Now We Have PCI Scope

With all of this done, we now know the scope of the environment and what must be assessed.  But, remember, while you are done for the current assessment, this all needs to be performed again next year.

The Joke That Is SAQ A

This week another outbreak of Magecart was detected in at least 19 eCommerce sites.  It is using a new way to obfuscate and gather cardholder data (CHD).  As I read through the latest description, it brought to mind SAQ A.

But before I launch into that diatribe, first a little bit of history so that everyone understands why SAQ A even exists.

In the early wild, wild west days of payment card security on the internet, enterprising solution providers were pandering “outsourced” solutions that would “avoid” compliance with the then Visa Cardholder Information Security Program (CISP) and MasterCard Site Data Protection (SDP) compliance efforts.  What they were selling was a solution that used a variety of Web site techniques to keep the CHD away from the merchant’s Web site.  These solutions sold themselves because they took the merchant out of scope from the very onerous Visa and MasterCard security programs.

Then along came the PCI DSS and the self-assessment questionnaires (SAQ).  As part of that process, the Council and the Brands realized that these so-called out of scope solutions were not really “out of scope”.  The result was SAQ A which covers these outsourced solutions.  For years they had kept their solutions out of the card brands’ compliance programs and now they were included.  SAQ A was good news, bad news moment for the solution providers.  The bad news was that there was no escaping the fact that their customers were now in scope for PCI compliance.  However, the good news was that to placate these solution providers who were lobbying loudly for no scope, the Council and Brands minimized the number of requirements in SAQ A to a very, very bare minimum so that these outsourced solutions would not scare their customer bases off due to PCI compliance.

Just for the record.  SAQ A is the absolute bare minimum number of requirements any merchant can comply with and be considered PCI compliant.  There is nothing less.

And Now The Jokes – Bad As They Are

The first joke is that SAQ A is the absolute prime example of compliance does not equal security, bar none.

Anyone that thinks compliance with SAQ A keeps their customer payments secure is seriously lying to themselves.  Magecart in all of its forms is exhibit number 1 as to why SAQ A is a joke and should be retired.

I have told my clients since SAQ A was published that if they thought compliance with SAQ A would keep them out of trouble to think again.  Yes, SAQ A keeps the processors, banks and brands happy, but it does nothing to manage the risk presented by any web site.  That is because if the code/executable/script on their server that invokes the redirect or iFrame is ever tampered with (as with Magecart), it will not be the processor or bank held legally responsible, it will be the merchant that operates that web site that is legally on the hook.

That is the second joke of SAQ A.  Merchants think they have pushed the payment card processing risk of their eCommerce operation off to a service provider and they have not.  Unknowingly, they still have a lot of skin in the game.  More than they realize or want to realize.

Yet time and again, I encounter merchants following SAQ A that blindly go about life without regularly patching, maintaining or monitoring their web site because “SAQ A says I do not need to do that”.  All of this under the mistaken belief that SAQ A’s requirements create security for that web site which they do not.  Sadly, I have also encountered a number of merchants over the years that have been caught in the SAQ A trap and found out the hard way the monetary and business costs of their beliefs in SAQ A protecting them from bad actors.

SAQ A Is Compliance Not Security

In the last update of the SAQs in 2018, the Council did address a minor shortcoming in SAQ A.  That addition was to require organizations to ensure that their Web server was patched current for critical vulnerabilities.  However, from a risk perspective for an internet-facing system, that did very little to ensure the security of merchant Web sites used for directing payment processing.

Notably, SAQ A does not require at least any of the following:

• Only one major service running, i.e., Web server with eCommerce application.
• External and internal vulnerability scanning.
• External and internal penetration testing.
• Critical file monitoring to identify if the redirect or iFrame invocation method has been tampered with.
• Logging and monitoring of the Web server and Web applications.

Most information security professionals would still likely consider even these aforementioned requirements inadequate.  These are all items I have told my clients I recommend, but even these absolute bare minimum steps for securing a Web server are not required for SAQ A compliance.

As a result, is it any surprise that most information security professionals and most QSAs consider SAQ A worthless for anything other than PCI compliance?  Organizations that truly understand information security also realize that SAQ A is not security and follow SAQ A-EP for ensuring the security of their out of scope Web servers.

The bottom line is that we in the payment security industry need to lobby the PCI SSC, banks and card brands to get rid of SAQ A before even more organizations get hurt.

Surprise! PCI Largely Ignores Disaster Recovery

As a lot of people are finding out when they rolled out work from home (WFH) for COVID-19, it turned out that compliance with the PCI DSS was not in place and in some cases, not even possible.  If the PCI Dream Team session last week is any example, I think a lot of QSAs got calls and emails from their clients asking what the Hell had happened?

What we are all experiencing is a shortcoming of the PCI DSS and a point that has been discussed off and on since it came into existence.  The problem is that the PCI DSS does not worry about business continuity (BCP) or disaster recovery (DR) unless there is cardholder data (CHD) or sensitive authentication data (SAD) involved which typically only occurs when that data exists at hot/warm recovery sites.  If the CHD/SAD is only there when recovery is occurring, then those locations are out of scope.

Unfortunately, the COVID-19 event is not your normal “disaster”.  With the invocation of WFH, production data centers and offices were still fully operational which is typically the concern of BCP/DR.  What changed was that the government enacted stay at home or shelter in place orders and the recovery site became an employee’s home, not your expected recovery location.  Worse, since WFH would not involve CHD/SAD until it was invoked, QSAs had no reason to assess any plans for such recovery because they were not in-scope until activated.

That said, a lot of QSAs (myself included) usually did have a discussion with clients that, while their BCP/DR plans were not in-scope, clients should occasionally assess those plans to make sure that, when invoked, the plan maintained PCI compliance.  Because when the BCP/DR was invoked, whatever was done had to be PCI compliant the moment it was used.

And there is the rub in all of this.  There is no grace period with PCI compliance because of the invocation of BCP/DR.  You are expected to be 100% PCI compliant regardless.

There are a number of lessons learned due to the COVID-19 disaster.

• BCP/DR will need to be updated for pandemic incidents including WFH capabilities. According to the World Health Organization (WHO) and the Centers for Disease Control (CDC), pandemics are not going to go away, so the ability to continue operations remotely is going to have to be part of an organization’s recovery options.
• WFH capabilities will have to be incorporated into normal production capabilities. This effort will need to address PCI compliance as well as HIPAA, CCPA, GDPR and any other relevant security and privacy programs your organization may have to comply with.  I have had a number of organizations enact such capabilities, policies and procedures for various parts of their operations over the years due to changing work requirements of their personnel as WFH offers a number of flexible advantages for retaining employees.
• Implement virtual desktop infrastructure (VDI) to provide office as well as remote working capabilities. This can also potentially allow WFH to use an employee’s BYOD as long as they are not required to be PCI compliant.  Use of VDI allows the use of thin clients and Chromebooks to be used as workstations making security of those workstations a bit easier as well as reducing the cost.
• Implement P2PE or end-to-end encryption (E2EE) solutions for the entry of CHD/SAD into applications. There are a number of USB and Bluetooth options available from the various point of interaction (POI) vendors such as Verifone and Ingenico as well as other third-party application vendors.
• Softphones create a larger scope by bringing the workstation they connect to into full scope for PCI compliance. The number of requirements that need to be assessed can be reduced by using VDI and connecting the softphone to the VDI through the workstation.  Making such a connection though is not “plug and play”, so be prepared to have to work a lot with the VDI vendor to make that connection work.  But do not be surprised if it does not provide a reliable and/or clear connection, so make sure you are prepared to have to place the full workstation into scope to have an acceptable working solution.
• If you are expecting to use The Cloud for your VDI or application, make sure that you conduct appropriate capacity planning so that you are not caught without the ability to expand that solution due to WFH. A lot of organizations have found with the COVID-19 event that their Cloud implementation did not scale as they thought it would.  It turned out that Cloud providers have capacity limitations just like in-house data centers.  While you are not using that capacity all of the time, you need to reserve it for those instances when you need it.  While not free, that excess capacity can be reserved for such events as COVID-19 so that when you need it, it is available.