Definition

The Customised Approach, introduced in PCI DSS v4.0 (Requirement 12.3.2), allows merchants and service providers to implement security controls in ways that differ from the defined requirements, provided the Customised Control Objective is met and documented via a rigorous Controls Matrix and independent testing. It is distinct from Compensating Controls (Appendix B), which carry a legacy constraint justification. The approach is most relevant to large, complex environments where defined requirements create disproportionate architectural cost.

Why it matters

The pressure on PCI DSS v4.0 programmes is shifting in specific, observable ways:

• Visa and Mastercard acquirers in the UAE increasingly reject boilerplate compensating controls post-v4.0 transition; a Customised Approach with QSA-validated Controls Matrix satisfies Requirement 12.3.2 more cleanly.
• Compensating controls require annual re-justification and a documented 'legitimate technological or documented business constraint' under Appendix B; for SaaS-hosted CDEs the constraint argument is eroding as cloud-native options mature.
• OCR-style scrutiny from regional PCI boards (e.g., Central Bank UAE) targets Requirement 12.1.2 programme governance; a Customised Approach signals a mature security posture to examiners and enterprise buyers.
• Average QSA billable hours for a compensating control package in the GCC run AED 45,000–90,000 per cycle; a one-time Customised Approach Controls Matrix can amortise that cost across three RoC cycles.

Evidence sources to capture

What an auditor or reviewer will sample for — wire each source into your evidence repository before the next review cycle:

• Customised Controls Matrix (CCM) document — control objective statement, risk rationale, testing procedures, and QSA sign-off date
• Targeted Risk Analysis (TRA) report per Requirement 12.3.2 — threat scenarios, likelihood ratings, residual risk acceptance by CISO
• QSA testing workpapers — sample sizes, test dates, pass/fail results for each Customised Control Objective
• Change-management tickets (ServiceNow or Jira) — change ID, CCM version reference, approver, effective date
• Annual programme review minutes — board or steering-committee sign-off per Requirement 12.1.1

Recommended next actions

A 90-day plan, sequenced so each step produces evidence the next step depends on:

• Day 0–30: QSA Lead inventories all existing compensating controls and scores each against Appendix B constraint viability vs. Customised Approach cost-benefit; output a ranked shortlist.
• Day 31–60: ISMS Manager and QSA co-author Customised Controls Matrix for top-three candidates, including threat modelling under Requirement 12.3.2 and TRA linkage.
• Day 61–90: Internal audit validates CCM evidence packs; QSA performs preliminary testing and issues draft testing procedures for inclusion in RoC.
• Day 90+: Head of Compliance presents finalised CCM to acquiring bank relationship manager and updates SoA / P2PE programme documentation accordingly.
• Ongoing: Review CCM at each annual RoC cycle or when CDE architecture changes materially; re-run TRA if threat landscape shifts per Requirement 12.3.1.

Example metrics

Instrument these and report them monthly to the executive sponsor; sustained adverse trends become board-level conversations:

• Compensating controls retired via Customised Approach migration — target ≥70% of existing compensating controls within 18 months
• QSA testing pass rate on Customised Control Objectives — target 100% on first submission; <2 findings requiring remediation
• Annual RoC cost delta (compensating vs. customised) — target AED 30,000–60,000 net saving per RoC cycle after CCM build cost
• CCM review cycle — completed within 30 days of any CDE architecture change event
• TRA documentation age — no TRA older than 12 months in active use per Requirement 12.3.2

The executive frame

For an executive sponsor, the decision behind this piece reduces to three questions: what changes in the next two quarters, what is the cost of not acting, and what is the minimum credible response?

Held against your acquiring bank and card schemes (Visa, Mastercard, Amex), the answer is rarely "do nothing" — but it is also rarely "rebuild the programme". The honest answer for most PCI DSS v4.0 buyers is a sharply scoped uplift focused on the two indicators that move the most: CDE asset count vs prior quarter and % of in-scope systems with daily log review evidence.

• What changes. The supervisory bar has moved on operating evidence, not on the control text itself.
• Cost of inaction. Findings carried into the next cycle compound; remediation in a regulator-driven timeframe costs 3–5× what proactive remediation costs.
• Minimum credible response. A 90-day uplift focused on the two indicators above, with a board-level commitment to the next review point.

Pitfalls we keep seeing

Across MAST Consulting Group's PCI DSS v4.0 portfolio, the same recurring failure modes show up cycle after cycle. None are exotic; all are expensive when they reach the audit report.

• Pattern: logging that records the event but not the actor. What good looks like: the same control evidenced inside the workflow it governs, not separately for the audit.
• Pattern: CDE diagrams that don't match what segmentation testing finds. What good looks like: the same control evidenced inside the workflow it governs, not separately for the audit.
• Pattern: ASV scans with carried-over false positives that were never re-validated. What good looks like: the same control evidenced inside the workflow it governs, not separately for the audit.
• Pattern: missing TRAs for requirements that allow them (e.g., 11.3.1.1, 5.3.2.1). What good looks like: the same control evidenced inside the workflow it governs, not separately for the audit.

Tooling we actually reach for

MAST Consulting Group is deliberately tool-agnostic, but in practice the same shortlist keeps appearing on PCI DSS v4.0 engagements because the integrations are cheap and the evidence is defensible:

• network segmentation testing tools — used not because it is fashionable, but because the audit trail it generates is one the reviewer accepts on the first ask.
• FIM (Tripwire, OSSEC, Wazuh) — used not because it is fashionable, but because the audit trail it generates is one the reviewer accepts on the first ask.
• SIEM (Splunk, Sentinel, Chronicle) — used not because it is fashionable, but because the audit trail it generates is one the reviewer accepts on the first ask.

How MAST Consulting Group can help

MAST Consulting Group runs PCI DSS v4.0 programmes for banks, insurers, healthcare networks, payments providers, telcos and government entities across the UAE, KSA, India and the wider GCC. We bring Lead Practitioners, sector specialists, and a working library of policies, risk methodologies and evidence templates that have passed audit at firms recognisable to your board.

If anything in this briefing is relevant to a programme you are scoping or rescuing, the fastest next step is a 30-minute working session with the practice lead. We will look at your specific situation, share what we have seen work for PCI DSS v4.0 programmes at similar scale, and tell you honestly if the work is something you should bring to us or run in-house.