Open Mobile Menu



Hello PCI fans! 2018 is right around the corner, and that means there are some key deadlines approaching that could impact your organization’s PCI compliance status. If you are reading this after January 31, 2018 and just realized you should really get started on this give us a call!

I’ve put together the following summary of the shiny new PCI DSS requirements and their upcoming dates in order to help you quickly assess your readiness to meet these changes.  If you are classified as a Merchant you’re getting off somewhat easy; most of the new requirements are only applicable to Service Providers. That said, there are a few significant changes that will impact all organizations subject to the PCI DSS.

Most of these are noted in the DSS as “best practices” until a certain date, at which time they become a required control; you may already be meeting the requirements (if so, good work!), but it doesn’t hurt to double check. One more note: Everyone should now be using SAQ and AOC v3.2 Rev1.1. Their use is required as of October 1, 2017, and they are available in the Document Library at

Requirement Date
Applicable To:
DSS Control
AppSec Consulting’s Recommendation

January 31, 2018


Service Providers

6.4.6 Upon completion of a significant change, all relevant PCI DSS requirements must be implemented on all new or changed systems and networks, and documentation updated as applicable.

First of all, you need to ensure that your organization has clearly defined criteria for what constitutes a “significant change”. The DSS leaves this determination up to the entity, but there is a clue in 11.3.2, which requires:


11.3.2 Perform internal penetration testing at least annually and after any significant infrastructure or application upgrade or modification (such as an operating system upgrade, a sub-network added to the environment, or a web server added to the environment).


We highly recommend that you define these criteria as part of your Risk Assessment process; these can also be determined on an ongoing basis by setting up a Change Advisory Board, who can review and classify changes based on the risk presented to cardholder data and systems. In addition, it is very helpful to include a “PCI RISK” category or indicator in your change management or ticketing system; being able to identify these “significant changes” easily will allow you to audit yourself against this requirement (and demonstrate your compliance to an external QSA Assessor if you are performing a Report on Compliance).


January 31, 2018


Service Providers

8.3 Secure all individual non-console administrative access and all remote access to the CDE using multi-factor authentication

The new requirement for multifactor authentication (MFA) is causing some headaches - let’s look at the guidance written into the note in the DSS:


Note: Multi-factor authentication requires that a minimum of two of the three authentication methods (see Requirement 8.2 for descriptions of authentication methods) be used for authentication. Using one factor twice (for example, using two separate passwords) is not considered multi-factor authentication.


Basically, any administrator access from the Internet to the CDE (MFA was already required), or from your internal network to the CDE (new requirement), must use multifactor authentication. This is not a password to your jump host, and then another password to the CDE firewall. Access must be controlled through use of two distinct factors:

  • Something you have (token, Smartcard, or Smartphone OTP for example)
  • Something you know (e.g. password/passphrase)
  • Something you are (biometric authentication such as voice, fingerprint, iris scan, or that weird mole that you should probably have checked out)

For ease of MFA administration (and to help you meet 1.x DSS requirements for limiting the systems/services allowed to communicate with the CDE from untrusted networks), we strongly recommend enforcing access to the CDE through the use of a jump host/bastion host, and deploying the MFA solution at centralized points.


I could write a whole guidance document on this subject; luckily, I don’t have to because the PCI Security Standards Council already did:


This is required reading for determining your compliance with this requirement; there are a some subtle “gotchas” that are addressed in this document that will help you determine whether or not you are going about this correctly (or make you pull out your hair – I’m talking about you “Independence of Authentication Mechanisms” section…).


As always, note that this document is supplemental guidance. The SSC specifically wants you to know that, “The intent of this document is to provide supplemental information. Information provided here does not replace or supersede requirements in any PCI SSC Standard.”


January 31, 2018

Service Providers

3.5.1 Additional requirement for service providers only: Maintain a documented description of the cryptographic architecture that includes:

     Details of all algorithms, protocols, and keys used for the protection of cardholder data, including key strength and expiry date

     Description of the key usage for each key.

     Inventory of any HSMs and other SCDs used for key management

This one is pretty straightforward, but make sure you update your documented Cryptographic Standards and key inventories to cover all your bases here. A matrix with a column covering each of these bullets will make compliance with this requirement much easier. I’ll get you started. Your inventory/matrix should include:


     Key Name

     Key Use

     Key Description

     Key Protocol

     Key Strength

     Key Expiration Date (and ideally date of last key rotation)

     HSM/SCD Name (I would create the same list above for keys stored on the HSMs/SCDs)


January 31, 2018

Service Providers

10.8.1 Additional requirement for service providers only: Respond to failures of any critical security controls in a timely manner. Processes for responding to failures in security controls must include:

     Restoring security functions

     Identifying and documenting the duration (date and time start to end) of the security failure

     Identifying and documenting cause(s) of failure, including root cause, and documenting remediation required to address root cause

     Identifying and addressing any security issues that arose during the failure

     Performing a risk assessment to determine whether further actions are required as a result of the security failure

     Implementing controls to prevent cause of failure from reoccurring

     Resuming monitoring of security controls

Oh boy... This one will take some thought, and may require some pretty significant changes to your processes and documentation. First of all, the SSC definition of “critical security control systems” (CSCS) applies to:






     Physical access controls

     Logical access controls

     Audit logging mechanisms

     Segmentation controls (if used)


This list is “including but not limited to,” so you need to rely on your asset inventory and risk assessment to determine if these are all of your “critical security control systems.” These are a good starting point.


For each CSCS, you need to address each of the bulleted items in 10.8.1. A standardized document should be created (this can be based on your 12.10.6 “Incident Response Plan/Lessons Learned” documentation, but the new requirements go well beyond this). After a failure in any CSCS is identified, a formal Incident Response process must be activated.  Step 1 of your process will be to immediately restore the security controls (this may require you to shut down systems and suspend access/processing to affected systems until a forensic determination can be made about root cause and impact). After you are certain that the failure and associated risks are understood and contained, the fun part starts. You need to have a formal system or document where you can track:


     The date/time/duration of the failure

     A description of the issue and cause of the failure, including root cause

     Remediation steps taken

     Identification and documentation of data and systems potentially affected by the failure

     How you performed an ad hoc risk assessment focused on the failure (this might be a good time to do a full risk assessment to determine if the failure is part of a larger issue). This risk assessment needs to include a description of further actions needed, controls in place to address the failure, and residual risk if the failure was not completely addressed

     Evidence that the cause of the failure was properly addressed (e.g. references to change control records or remediation artifacts)

     Evidence that controls to monitor the CSCS are functioning properly, and generating alerts to key personnel


It is critical that the staff responsible for responding to CSCS failures and security incidents are fully aware of this process. You will almost certainly need to update your Incident Response Plan and supporting processes, Business Continuity and Disaster Recovery plans, risk assessment process and Risk Management Policy to incorporate all facets of this requirement. 


January 31, 2018

Service Providers Additional requirement for service providers only: If segmentation is used, confirm PCI DSS scope by performing penetration testing on segmentation controls at least every six months and after any changes to segmentation controls/methods.

This one is pretty self-explanatory. This requirement does not require a full application layer penetration test, but you must validate the effectiveness of segmentation controls at least bi-annually and after changes to segmentation controls.  A ton has already been written on what PCI DSS segmentation means, here is a quick reminder from the SSC’s supplemental segmentation guidance document (again, this does not replace/supersede DSS requirements):


Segmentation can consist of logical controls, physical controls, or a combination of both. Examples of commonly used segmentation methods for purposes of reducing PCI DSS scope include firewalls and router configurations to prevent traffic passing between out-of-scope networks and the CDE, network configurations that prevent communications between different systems and/or subnets, and physical access controls.


(Source: Hit up the link for a deep dive into what constitutes proper segmentation of CDE systems from untrusted networks.)


Please note, penetration/segmentation testing can be done by a qualified internal resource (or experts like the team at AppSec Consulting). If you do this internally make sure you document the qualifications of the internal resource and the testing results to support an assessment.  Consider baking segmentation testing into your change control process for all significant network changes.


January 31, 2018

Service Providers

12.4.1 Additional requirement for service providers only:  Executive management shall establish responsibility for the protection of cardholder data and a PCI DSS compliance program to include:

     Overall accountability for maintaining PCI DSS compliance 

     Defining a charter for a PCI DSS compliance program and communication to executive management

This new requirement states that your leadership team has to formally assign responsibility and oversight for the protection of cardholder data. As part of this, your organization will need to establish a policy or charter outlining your cardholder data protection strategy, that is approved by the C-Suite and/or Board.  This is not a one-and-done thing; the DSS requires the establishment of a compliance program. This means that someone will be responsible for identifying emerging threats to cardholder data and systems, reviewing the latest SSC and payment card brands’ guidance, and communicating this to the executive team on an ongoing basis.


When establishing your policy or charter, consider documenting the following areas:


     Project Name




     Owners and Stakeholders


     Resources and Requirements

     Communication and Escalation Plans

     Processes for Escalation of Risks and Status Reporting

     Process for ongoing review and maintenance of the charter and PCI Compliance Program


A summary and evaluation of your organization’s PCI DSS compliance posture should be included in ongoing management/board presentations. This is also a great opportunity to summarize the results of your risk assessment findings related to protection of cardholder data and systems so you can present them to the leadership team (and while not a PCI requirement, putting together cool presentations will also improve your PowerPoint skills).


January 31, 2018

Service Providers

12.11 Additional requirement for service providers only: Perform reviews at least quarterly to confirm personnel are following security policies and operational procedures. Reviews must cover the following processes:

       Daily log reviews

       Firewall rule-set reviews

       Applying configuration standards to new systems

       Responding to security alerts

       Change management processes


This one isn’t too tough to meet if you have operationalized your daily processes. To meet this requirement, you will likely have to ensure that there is a paper trail (such as signoff forms or change control records) for each of these tasks. Responsibility for complying with this requirement can be assigned to teams or individuals. Include requirements for archiving evidence as part of the SOPs for these respective processes.


Remember, most of these tasks need to be done on an ongoing basis. Do not interpret this requirement as meaning that you only have to do these tasks quarterly; the requirement is to check to see that reviews are being done, and that best-practices and formal processes are being followed in a manner that can be considered “business as usual”.

January 31, 2018

Service Providers

12.11.1 Additional requirement for service providers only:  Maintain documentation of quarterly review process to include:

     Documenting results of the reviews

     Review and sign off of results by personnel assigned responsibility for the PCI DSS compliance program

This control is directly related to the previous entry. Ensure those with PCI DSS compliance responsibilities (identified in requirement 12.4.1) review and formally sign off on the quarterly review activities.

June 30, 2018


Service Providers

A2.2 Review the documented Risk Mitigation and Migration Plan to verify it includes: 

     Description of usage, including what data is being transmitted, types and number of systems that use and/or support SSL/early TLS, type of environment;

     Risk-assessment results and risk-reduction controls in place;

     Description of processes to monitor for new vulnerabilities associated with SSL/early TLS;

     Description of change control processes that are implemented to ensure SSL/early TLS is not implemented into new environments;

     Overview of migration project plan including target migration completion date no later than June 30, 2018


A2.3 Additional Requirement for Service Providers Only: All service providers must provide a secure service offering by June 30, 2016.


     Note: Prior to June 30, 2016, the service provider must either have a secure protocol option included in their service offering, or have a documented Risk Mitigation and Migration Plan (per A.2.2) that includes a target date for provision of a secure protocol option no later than June 30, 2016. After this date, all service providers must offer a secure protocol option for their service.

The SSC is giving you until June 30, 2018 to take your insecure protocols to that nice farm in the country (this applies to SSL and TLS 1.0). By this point, you should have identified the usage of these protocols, and planned to remove or replace them before the deadline.


TLS 1.1 and TLS 1.2 are both acceptable, but TLS 1.2 is recommended as the higher version cleans up some security issues in TLS 1.1 (specifically, TLS 1.2 supports authenticated encryption and forces support for stronger AES encryption modes).


Pretty much every scanning tool out there will tell you what versions you are running, and free tools like the Qualys SSL Labs’ SSL Server Test tool ( will tell you what versions your web page supports.


As you have no doubt figured out, most of these requirements are intended to operationalize DSS controls or provide additional levels of oversight to validate that controls are operating effectively. The goal is to “encourage” organizations to meet their compliance requirements year-round, not just at the time of an assessment (or when something terrible happens).  Contact us if you need any assistance with the interpretation or implementation of these controls, or have other security, compliance, privacy, or testing questions. We’re here to help!

Tony Fulda

Tony Fulda has over fifteen years of information technology, information system security and technology training experience, performing technical and enterprise risk assessments and consulting for clients in the higher education, hospitality, healthcare, service provider, and retail industries. As AppSec Consulting’s Managing Director of Strategic Advisory Services, Tony is responsible for driving the strategic direction of the assessment team and ensuring that AppSec Consulting’s clients receive exceptional service and maximum return on investment.

Tony has assisted hundreds of clients achieve their security and compliance goals through scope reduction, process improvement, and strategic technology integration.  He has led or participated in a multitude of remediation projects and has performed US-based and International Level 1 Report on Compliance audits for some of the largest organizations in the world.

read more articles by Tony Fulda