Continuous Compliance With the PCI DSS

The idea of continuous compliance has been part of PCI DSS since its earliest versions, but it became a much more explicit priority with the release of PCI DSS v3.  That update marked a deliberate move away from treating compliance as a once a year box-ticking exercise.  Instead, it emphasised the need for organisations to maintain security controls on an ongoing basis, reflecting the reality that threats, systems, and environments are constantly changing.  While the PCI DSS is typically positioned as a ‘point-in-time’ assessment, meaning that it considers your organisation and the compliance of its processes at the time of the assessment being conducted, the objective of the Standard is for you to maintain compliant processes throughout the year.

So, in v3, the Standard introduced the concept of ‘implementing PCI DSS into business-as-usual processes’, i.e., integrating compliance into your standard operating procedures, not treating it as an add-on.  This included a number of recommendations for how BAU compliance could be achieved.  PCI DSS v4 has taken this concept a step further by elevating some of those earlier BAU recommendations into explicit, mandatory requirements.

To demonstrate continuous compliance to an assessor, you will need a defined process that meets the relevant PCI DSS requirement, individuals within your organisation who understand and consistently follow the process, and process outputs to evidence that it has been performed as designed in the period between assessments.  

The PCI DSS requirements which your organisation needs to meet will drive the BAU processes you implement.  The key is to integrate PCI DSS compliance into your everyday business practices where possible, instead of building a completely separate process specifically for compliance purposes.

For example, when considering change management, you should not develop a dedicated ‘PCI change management process’, but have a change management process in place that incorporates PCI DSS – and this is appliable to both technical changes and business changes.  If a significant business structural change occurs (e.g., acquisition or merger), as part of your standard change management process this needs to trigger a PCI DSS change review that considers whether your compliance is impacted, if your scope needs to be reassessed, whether there are new requirements you now need to be compliant with, etc.  So, your change management process should contain wording stating that business structural change requires a PCI DSS review.

For organisations undergoing their first PCI DSS assessment, the assessor’s expectations will differ slightly.  Because you will not yet have historical process outputs, the assessor cannot look for evidence of ongoing execution.  Instead, they will focus on whether the necessary processes have been defined, meet PCI DSS requirements, and whether relevant personal understand how to follow them going forward.  

As stated above, the processes that you need to implement will depend on which requirements are applicable to your organisation.  However, common BAU processes include:

• Quarterly firewall reviews
• User access rights reviews
• Vulnerability scans
• Real-time monitoring
• Overall compliance and communication programme.

The final requirement in the list applies only to larger organisations and service providers, reflecting the expectation that these entities maintain more formalised, scalable processes for ongoing compliance.  It dictates that executive management are ultimately responsible and accountable for the protection of cardholder data, and that a defined compliance programme and communication programme (referred to as a PCI DSS charter) need to be established to ensure that executives maintain clear visibility into the organisation’s ongoing compliance status.

Before this requirement was included, the PCI Security Standards Council (SSC) identified that while many organisations were technically compliant, executives were uninvolved in and lacked knowledge of the PCI DSS process.  As such, the SSC introduced this requirement in v3 to enhance leadership buy-in and commitment to compliance among these larger organisations, helping to ensure that PCI DSS was approached as an organisation-wide effort rather than an IT-only project.  In practice, implementing this PCI charter into BAU will typically involve regular communication upwards from team members to executives, confirming that compliance activities are being completed and requirements are consistently being met.

‍

The vast majority of BAU requirements are periodic requirements, which are activities and processes that need to be completed at a particular interval.  For some controls, the Standard defines fixed intervals at which they need to be completed, such as quarterly scans (with the PCI DSS specifying that quarterly means once every 90 days), annual penetration tests, and 6 monthly access reviews.  For certain other controls, the PCI DSS only specifies that they need to be performed ‘periodically’ and does not prescribe specific intervals.  These include:

• Reviewing service account access
• Checking PIN entry devices for tampering
• Ensuring change-detection controls are functioning
• Training incident-response personnel.

Flexible-interval controls require organisations to determine how often the control should be performed, using a risk-based frequency established through a targeted risk analysis (TRA).  The Standard specifies that for every periodic requirement without a predefined frequency, a TRA must be conducted to justify the chosen period.  Each TRA is specific to the individual requirement.  These analyses are distinct from other risk assessments your organisation may conduct in other areas, but they can be incorporated into your standard risk assessment framework.  Because TRAs must be reviewed and re-evaluated annually, and most organisations already run on an annual risk assessment cycle, it is logical and efficient to fold the TRA workflow into your established process.

The PCI SSC provides a useful TRA template that can be utilised by your organisation if required. But, at a high level, TRAs should assess assets, threats, likelihood, impacts, and risk-reduction measures, ultimately determining the level of risk to cardholder data associated with the chosen frequency.  During a PCI DSS assessment, your organisation will need to provide TRA outputs as evidence.  A Qualified Security Assessor (QSA) will want to confirm that your justifications are logical, reasonable and proportionate to the risk, and you will need to be able to demonstrate that you have considered how the chosen frequency affects the potential risk to cardholder data.

For more information on TRAs, read our blog on PCI DSS v4.0: Targeted Risk Analysis.

The key for maintaining compliance with periodic requirements is to avoid missing scheduled activities, regardless of interval.  Once an interval has passed, the activity cannot be retroactively completed.  For example, if your assessment is approaching and you discover that quarterly scans haven’t been performed for the last six months, there is no way to ‘catch up’ and the missed activity will represent a compliance failure.  

A straightforward but highly effective way to ensure periodic activities are completed on time is to identify which individual is responsible for a particular activity, and discussing how you can most effectively integrate the activity into their standard operating procedure.  This will often mean placing the task in the responsible individual’s calendar, scheduled shortly before the activity is due.  

If a periodic compliance activity is missed, it’s important to take corrective action to ensure the issue does not persist.  While assessors may be understanding of a genuine one-off lapse, they will expect to see that you are taking steps to prevent recurrence.  Meanwhile, a pattern of missed requirements will be looked on unfavourably, and could lead to your organisation losing its compliance status.  

As such, you should consider introducing additional measures to ensure processes are completed on time under these circumstances.  This could involve increasing the frequency at which required activities are carried out or introducing extra verification checks, such as having another team member confirm that the activity has been completed.  Alternatively, you could implement automation, perhaps by setting up automated reminders or automate the generating of tickets near the due date, ensuring that the appropriate individuals are prompted to pick up and complete the required tasks.

‍

PCI DSS v4 has taken advantage of the widespread availability of automated tools and systems that can monitor in real time by building these technologies into some of the requirements.  For example, where anti-virus would traditionally run a weekly scan and provide a report, modern anti-virus tools often run continuously, providing real-time monitoring of systems; this has now been included within the Standard as an acceptable anti-virus control.  Other examples include real-time log monitoring and user activity monitoring.  The systems used need to be periodically checked to ensure they are functioning correctly, and the alerts they generate must still be reviewed and acted upon, but the monitoring itself can now be automated for certain requirements.

Implementing real-time monitoring can provide considerable benefit.  Often, the time between organisations being compromised and that compromise being detected is too long; real-time monitoring significantly shortens that window.  It allows you to identify security events and issues at the earliest possible stage, in turn enabling you to act on and resolve events/issues quickly.

Despite the above, some of the monitoring required by the PCI DSS does still need to be performed manually.  The Standard requires that organisations conduct quarterly internal reviews, which involve working through a checklist to verify that manual activities are being completed, such as:

• Vulnerability scanning
• Firewall reviews
• Hardware and software reviews
• User access rights reviews.

You need to ensure that the individual appointed to conduct these reviews is not the same individual performing the processes themselves.  They must be conducted by an independent person so that nothing is overlooked or missed.

‍

Organisations that treat compliance as an embedded, day-to-day discipline are not only able to meet PCI DSS expectations around year-round compliance, but also spend less time responding to avoidable issues, face fewer surprises during assessment, and build stronger, more resilient security practices as a result.  With the right approach, you create an environment where compliance becomes a natural outcome of how the organisation operates, rather than an annual hurdle to clear once a year.  In doing so, your organisation strengthens its long term security posture and keeps compliance firmly on track.