On 1 February 2018, a set of new Payment Card Industry Data Security Standard (PCI DSS) requirements officially went into effect. All of them still apply today in PCI DSS v4.0.1, the current version of the standard, most under new numbers, and two of them now apply to merchants as well as service providers.
This matters because the PCI DSS applies to all organisations that store, process or transmit cardholder data. In some cases, only service providers are impacted. In other cases, it’s both merchants and service providers.
The PCI Security Standards Council doesn’t impose penalties itself, but the card brands can apply financial or operational consequences to businesses that aren’t compliant, so you’ll want to ensure that your organisation is fully on board.
Here are the requirements that took effect in 2018, what they are called in PCI DSS v4.0.1, and the actions you need to take to be compliant.
Requirement 6.4.6 (now 6.5.2)
Upon completion of a significant change, all applicable PCI DSS requirements are confirmed to be in place on all new or changed systems and networks, and documentation is updated as applicable.
This simply means that your organisation must update your change management policy so that every significant change triggers a check that the relevant PCI DSS requirements are in place. As new security threats inevitably arise, you must alter your cybersecurity policies accordingly to mitigate your risks.
Some examples of changes include:
- Installing new system components
- Modifying a firewall
- Upgrading product and/or operating systems
- Adding new sub-networks
- Adding new web servers
Requirement 8.3.1 (now 8.4.1)
MFA is implemented for all non-console access into the cardholder data environment (CDE) for personnel with administrative access.
Multi-factor authentication is a technique that only allows access after submitting two or more pieces of information, thus enabling you to keep a tighter grip on who can access your company’s data.
This is important given how often attackers simply log in with stolen details. ASD reported that 42% of industry, government and critical infrastructure sector incidents reported to it in 2024–25 involved compromised accounts or credentials.
Requiring more than one authentication factor makes a stolen password far less useful to an attacker. Since 31 March 2025, Requirement 8.4.2 goes further than the 2018 rule: MFA is now required for all non-console access into the CDE, not only administrative access. Requirement 8.4.3 also requires MFA for all remote access from outside your network that could access or impact the CDE.
Note that PCI DSS v4.0.1 says MFA for access into the CDE can be implemented at the network level or the system/application level. However, it doesn’t have to be both.
Requirement 3.5.1 (now 3.6.1.1)
Maintain a documented description of the cryptographic architecture.
The term “cryptographic architecture” refers to the framework used to encrypt data and prevent it from being intercepted. This can include algorithm details, encryption protocols and the keys used to protect customer payment card data.
What service providers must do is create a document that includes details on all of these elements. In PCI DSS v4.0.1, that description must also cover key strength and expiry dates, how each key is used, and an inventory of hardware security modules (HSMs) and other key management devices. Since 31 March 2025, it must also show that the same cryptographic keys aren’t used in production and test environments.
The aim is to make sure service providers know exactly how stored cardholder data is protected, so weak or poorly managed cryptography doesn’t leave sensitive cardholder information vulnerable.
Note that this requirement is only applicable for service providers storing cardholder data.
Requirement 10.8 (now 10.7.1 and 10.7.2)
Implement a process for the timely detection and reporting of failures of critical security control systems.
In 2018 this applied to service providers only. Since 31 March 2025, Requirement 10.7.2 applies to every entity, and its list of critical security control systems now includes:
- Network security controls (such as firewalls)
- Intrusion detection systems (IDS) and/or intrusion prevention systems (IPS)
- Change-detection mechanisms (such as file integrity monitoring)
- Anti-malware solutions
- Physical and logical access controls
- Audit logging and audit log review mechanisms
- Segmentation controls and automated security testing tools (if used)
It’s the responsibility of every organisation in scope to develop or update an incident response policy so that A) they can swiftly detect issues and B) have a process in place to promptly resolve them. The quicker they react, the better the chances are of containing a threat and protecting cardholder data.
Requirement 10.8.1 (now 10.7.3)
Respond to failures of any critical security controls in a timely manner.
This requirement mandates that you must have processes in place that are capable of responding to failures in critical security controls, including:
- Promptly restoring security functions
- Identifying and documenting the time in which the security failure occurred (when it began and when it ended)
- Finding the root cause of the issue and documenting the remedial action that was taken to address it
- Identifying the specific security issues that occurred along the way
- Performing a risk assessment so that you know if further actions are necessary
- Taking steps to ensure that the issue doesn’t happen again
- Resuming security control monitoring
The bottom line here is that your organisation’s incident response policy must be updated to include the procedures that will be taken should a critical security control fail. This way everyone within your organisation will know how to react and what their job is. Like Requirement 10.7.2, this has applied to merchants as well as service providers since 31 March 2025.
Requirement 11.3.4.1 (now 11.4.6)
If segmentation is used, confirm PCI DSS scope by performing penetration testing on segmentation controls at least once every six months and after any changes to segmentation controls/methods.
Penetration testing is an essential part of being proactive with cybersecurity and allows for the testing of web applications, mobile applications, your network and more. The point of it is to catch flaws and vulnerabilities and fix them before they can be exploited by cyber criminals.
While it’s a good idea to perform periodic pen testing anyway, this requirement mandates that service providers do it at least once every six months and after any changes to segmentation controls or methods. In other words, there is a specific frequency in which pen testing must be done.
Requirement 12.4.1
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 and defining a charter for a PCI DSS compliance program and communication to executive management.
In layman’s terms, responsibility for compliance falls in the hands of executive management. PCI DSS v4.0.1 keeps the same number and notes that executive management may include C-level positions, the board of directors, or equivalent. It’s also clear that a service provider isn’t to treat compliance as a one-off type of deal but as a process that’s woven into the very fabric of their operations.
A compliance charter should be provided to serve as written evidence to show that protecting cardholder information is something that service providers take very seriously and that they’ll continuously work toward improving cybersecurity.
Requirement 12.11 (now 12.4.2)
Perform reviews at least once every three months to confirm personnel are performing their tasks in accordance with security policies and operational procedures.
The PCI DSS clarifies that these reviews must cover five specific tasks:
- Daily log reviews (e.g. network activity)
- Configuration reviews for network security controls (such as firewall rule sets)
- Applying configuration standards to new systems
- Responding to security alerts
- Change management processes
This one is pretty straightforward and is designed to ensure that service providers are doing their part to reduce the risk of a data breach. In PCI DSS v4.0.1, the reviews must be performed by personnel other than those responsible for the task. Performing reviews at least once every three months is important for ensuring continuity and that team members remain diligent in their efforts.
Requirement 12.11.1 (now 12.4.2.1)
Maintain documentation of the quarterly review process to include: documenting results of the reviews and review and sign-off of results by personnel assigned responsibility for the PCI DSS compliance program.
This piggybacks off of the previous requirement and simply states that service providers need to document their quarterly reviews and have the people responsible for the PCI DSS compliance program review and sign off on the results. PCI DSS v4.0.1 also requires the documentation to record the remediation actions taken for any tasks that weren’t performed.
What changed again in PCI DSS v4.0
PCI DSS kept evolving after 2018. Version 4.0 introduced 64 new requirements: 13 applied immediately and 51 were best practices until 31 March 2025, when they became mandatory. PCI DSS v4.0.1, published in June 2024, is a limited revision with no new or deleted requirements, and PCI DSS v4.0 was retired on 31 December 2024.
If your last PCI DSS gap assessment was done against an older version, it’s worth checking your controls against the requirements that became mandatory on 31 March 2025.
Keeping Your Company Compliant
As you can see, these PCI requirements are extremely in-depth and exhaustive. So it’s easy to see how some organisations could struggle with meeting these requirements and maintaining compliance.
It can be quite arduous.
And though full-scale initiatives have been taken by companies all around the world, many still fail to hit the mark. Verizon’s 2015 PCI Compliance Report, for example, found that four out of five companies failed their interim PCI DSS compliance assessment.
Needless to say this isn’t good and is just asking for trouble. Failing to meet compliance standards can hurt your organisation in two ways.
First, you may face financial or operational consequences from the card brands or your acquiring bank. Second, your odds of encountering a data breach increase significantly. If you’re not taking the preventative steps necessary to thwart an attack, you run a far higher risk of falling prey.
In Australia, ASD’s Annual Cyber Threat Report 2025–26 puts the average self-reported cost of cybercrime per report for businesses at $93,500, so the financial backlash can be crippling.
One practical way to meet PCI requirements and maintain compliance is to use PCI DSS compliance consulting services. This is where you get help from a third-party provider who understands the ins and outs of the process and works with you to secure cardholder data from a potential data breach.
They will help you fill in the initial gaps as well as provide you with ongoing services to keep up with future requirements.
If the whole concept of PCI DSS sounds confusing and overwhelming, this is definitely an option to consider.
A New Reality for Businesses
Like it or not, data breaches are something that most organisations now contend with. Those in high-risk industries like healthcare and financial services are especially vulnerable.
These PCI requirements are a way to regulate how organisations collect and store cardholder data to better protect consumers and minimise the chances of data breaches taking place. Placing the focus on the service providers helps improve overall detection and enforces response controls with the goal of reducing risk to cardholder data on behalf of their customers.
Although these requirements are by no means convenient, it’s something you need to get used to. As the threat of data breaches continues to grow and the sophistication level of cyber criminals increases, PCI requirements will evolve as well, just as they did with PCI DSS v4.0.
So whether you’re a small business with only a handful of employees or a global corporation with thousands, you need to do everything possible to achieve and maintain compliance. It’s that simple.
Is your business looking to get PCI DSS compliant? StickmanCyber’s PCI DSS compliance service deploys a 5-step methodology to help you build trust with your customers and support secure transactions with PCI DSS compliance. Book a free consultation today.
Frequently asked questions
What is the current version of PCI DSS?
PCI DSS v4.0.1 is the current version. The PCI Security Standards Council published it in June 2024 as a limited revision of v4.0, with no new or deleted requirements. PCI DSS v4.0 was retired on 31 December 2024, so assessments are now carried out against v4.0.1.
Do service-provider-only requirements apply to merchants?
No. Requirements labelled “additional requirement for service providers only” apply only when the entity being assessed is a service provider. However, some requirements have changed scope over time. For example, detecting and responding to failures of critical security control systems (Requirements 10.7.2 and 10.7.3) has applied to merchants as well as service providers since 31 March 2025.
What is the customised approach in PCI DSS?
The customised approach, introduced in PCI DSS v4.0, is an alternative to the traditional defined approach. Instead of implementing a requirement exactly as written, an organisation designs its own controls to meet the requirement’s stated objective. The PCI Security Standards Council says it is intended for risk-mature organisations and is not a workaround for requirements that haven’t been met.
What is a targeted risk analysis in PCI DSS?
A targeted risk analysis (TRA) is a documented risk assessment for a specific PCI DSS control. Since v4.0, organisations use a TRA to decide how often to perform controls where the standard allows flexibility (Requirement 12.3.1), and to support any requirement met using the customised approach. It lets the frequency or design of a control reflect the organisation’s own risk profile.
Who enforces PCI DSS compliance in Australia?
The PCI Security Standards Council sets the standard but doesn’t manage compliance programs or impose penalties. The card brands run their own compliance programs, and in practice your acquiring bank or payment provider tells you how to validate compliance. PCI DSS is an industry standard rather than an Australian law, but a card data breach may also need to be assessed under the Privacy Act’s Notifiable Data Breaches scheme if your business is covered by the Act.
