PCI DSS Maturity Stages: How Secure is Your Organisation?
Maturity frameworks are a great way to understand your organisation’s security posture against cyber threats and industry standards.
That’s why major cyber security frameworks, such as the NIST Cybersecurity Framework and the Essential Eight, use official maturity tiers and levels, respectively, to guide organisations through the various stages of compliance.
PCI DSS does not define formal maturity tiers. You’re either compliant or you’re not. What does change is what a PCI DSS-complaint environment actually protects you from. PCI DSS does have different guidance, commensurate with risk levels, that determine which of the 300+ PCI DSS requirements your organisation must meet. These determining factors include:
- How you accept card payments.
- What data enters your environment (and whether you process, transmit or store it).
- How many transactions you process per year.
However, in practice, organisations develop payment security capability over time. But the black-and-white nature of PCI DSS means a lot of organisations sign off as being compliant, yet aren’t as secure as that status should suggest.
Intent is what drives organisations up the maturity scale. You can technically prove compliance with lower-maturity controls. However, when faced with a sophisticated cyber threat, those controls may not safeguard your cardholder data.
This is often how organisations come to engage Stratica. We ensure PCI DSS controls are designed to secure cardholder data, not just maintain PCI DSS compliance. There’s a difference, and it’s often the difference that attackers exploit.
As Australia’s only dual PFI/QSA firm, we’ve seen both sides of payment security. And it’s our understanding of what goes wrong in a card data breach that allows us to provide security advice that ensures our clients implement PCI DSS in a way that provides genuine security uplift. We’ve taken many organisations from non-compliance to full compliance, often within 90 days. We’ve also taken organisations who were previously marked compliant by their previous assesser, but suffered a breach, to a stronger security posture. Stratica’s PCI Security Maturity Framework helps organisations understand where they sit on that journey.
The Stratica PCI DSS Maturity Framework
Each organisation that’s required to demonstrate PCI DSS compliance sits somewhere on this spectrum.
Stratica PCI DSS Security Maturity Framework: Stages Summary
| Stage | Name | Programme State | Key Characteristics |
|---|---|---|---|
| S1 | Reactive Compliance | Audit-driven | Compliance happens once a year, at audit time, then gets forgotten. |
| S2 | Repeatable Compliance | Process-establishing | There’s a plan and an owner, but reliability doesn’t equal quality and key-person risk is high. |
| S3 | Defined Payment Security | Programme-structured | Payment security becomes a formal, documented programme owned by the organisation, not by individuals. |
| S4 | Managed and Measured | Continuously monitored | The PCI DSS programme runs continuously all year, with automation, tooling and real leadership visibility. |
| S5 | Optimised and Risk-Adaptive | Continuously improving | Compliance is the baseline; the programme goes beyond just meeting PCI DSS requirements. It’s risk-adaptive by design and stays ahead of the threat landscape. |
Stage 1: Reactive Compliance
Most organisations start here. At this maturity level, it’s about ticking the boxes. So, PCI DSS is something that gets dealt with once a year when the assessment comes around, and not actively managed in between. Security controls exist but, they’re applied inconsistently. Compliance evidence gets pulled together at the last minute. And after compliance is assured, it’s forgotten about until the next assessment rolls around. Ownership of the programme is murky at best. Necessary uplifts such as patching happens when someone gets to it. The organisation might pass the assessment and be PCI DSS compliant on paper, but the underlying control environment is fragile and largely untested between cycles.
Stage 2: Repeatable Compliance
This is the level where things start to become organised, but the programme is still running primarily as an annual compliance exercise. There’s a workplan, a named owner, and core PCI DSS obligations are known and tracked across daily, weekly, monthly, quarterly, six-monthly and annual cadences. Activities happen on schedule rather than in a last-minute scramble. For example, quarterly ASV scans are running and passing against Requirement 11.3. The issue is that reliability does not yet mean quality. When priorities change, remediation slips and monitoring is patchy. The programme also leans heavily on a small number of people. Lose one of them and organisations can quickly find themselves sliding back a level.
Stage 3: Defined Payment Security Programme
This is the most important step for most organisations. It’s when payment security becomes something the organisation actually owns as a formal programme. Responsibilities are assigned, processes are documented, and scope and segmentation are actively managed rather than assumed. Third-party and service provider relationships are governed through shared responsibility matrices, giving both parties clarity on who owns what across the control environment. For e-commerce environments, script governance is formalised and tamper detection, particularly on the card payment page, is in place – and it’s automated and actually monitored. At this level, PCI DSS compliance is systemised, running on processes rather than the ad-hoc, fragmented knowledge of individuals that leads to inconsistent application.
Stage 4: Managed and Measured Payment Security
At this stage, the PCI DSS compliance programme is genuinely running all year rather than gearing up for assessment season. Controls are monitored continuously, remediation is tracked through tooling rather than spreadsheets, and the organisation can produce evidence of control operation at any point without scrambling. Leadership gets real visibility into the programme’s health through consistent reporting. The defining shift from L3 is automation: processes that existed on paper now have instrumentation, measurement and active management behind them.
Stage 5: Optimised and Risk-Adaptive Payment Security
Organisations at this stage have moved well beyond compliance as a goal. The programme continuously improves and adapts based on actual risk, with control frequencies adjusted through documented risk analysis and threat intelligence feeding directly into detection and response rather than sitting in a separate function. Performance is benchmarked against peers, improvement cycles are documented and outcomes are tracked. At this stage, simply achieving PCI DSS compliance is the baseline. It’s the foundation for a continuously improving payment security programme that, by design, stays well ahead of the cyber threat landscape.
PCI DSS compliance is achievable at all stages. What these maturity stages determine is how easy the programme is for your organisation to maintain, and how well your security controls perform when targeted by cyber criminals. That second point’s important: as cyber criminals leverage AI tools to bring the time to exploitation to zero, your organisation is more vulnerable than ever. And no organisation is too small or insignificant to be a target.
The 9 Capability Pillars of PCI DSS Maturity
Your PCI DSS maturity stage is determined by your adherence to 9 PCI DSS capability pillars, which are found in the twelve highlighted PCI DSS Requirements sections. These are the core elements of an effective PCI DSS security posture.
The PCI DSS capability pillars are:
1 Governance and Programme Management Who owns the programme, how it’s structured, and how it’s reported to leadership.
2 PCI Scope and Segmentation How well the cardholder data environment is defined, contained and isolated from the rest of the business.
3 Secure Configuration and Change Whether systems in scope are hardened to a defined standard and changes are managed without introducing risk.
4 Vulnerability and Patch Management How consistently vulnerabilities are identified, prioritised and remediated against defined SLAs.
5 Logging, Monitoring and Detection Whether the right events are captured, reviewed and actioned in a way that gives genuine visibility into the environment.
6 Incident Response Readiness How prepared the organisation is to contain and recover from a payment security incident when it happens.
7 Third-Party and Service Provider Oversight How well the organisation manages the PCI DSS obligations of its vendors and service providers.
8 Cloud and Shared Responsibility Whether responsibilities across cloud environments are explicitly documented and continuously verified.
9 E-Commerce and Payment Page Security How well the organisation controls and monitors its payment pages, including the third-party scripts that represent one of the highest-risk surfaces in a modern payment environment.
Ready to find out where you stand?
Most organisations don’t know their current maturity stage until they review their actual compliance efforts. Understanding where you sit on this spectrum, and what it means for your actual security posture, is the first step toward building a payment security programme that works beyond assessment day.
If you’d like to assess your current maturity, identify the gaps that carry the most risk, and build a practical roadmap for uplift, get in touch.
Stratica’s PCI DSS Security Assessment maps your organisation across all nine capability pillars and gives you a clear picture of where to focus first.
**Contact us to for a PCI DSS Security Assessment.**