Skip to content
  • There are no suggestions because the search field is empty.

Common PCI DSS Compensating Control Examples

This article provides examples of common compensating controls

 

Common PCI DSS Compensating Control Examples

Overview

Compensating controls are sometimes necessary in environments where meeting a PCI DSS requirement exactly as written is not technically feasible.

In these cases, organisations may implement alternative controls that:

  • Meet the intent of the requirement

  • Provide equivalent or stronger protection

  • Are documented in a Compensating Control Worksheet (CCW)

  • Are approved by an assessor (where applicable)

Below are common scenarios seen in modern SaaS organisations.

Example 1: Legacy system cannot support MFA

Requirement intent

Administrative access must be strongly authenticated (MFA).

Common SaaS constraint

A legacy billing or payment-related system does not support MFA directly.

Compensating control approach

Implement layered controls such as:

  • Access only via a hardened jump server with MFA enforced

  • Strict IP allowlisting (no open internet access)

  • Network segmentation isolating the legacy system

  • Enhanced logging and alerting for all privileged activity

  • Short session timeouts and frequent access review

Why this works

Even though MFA cannot be enabled on the system itself, access is still protected by equivalent controls.

Example 2: Cardholder environment cannot be fully segmented as designed

Requirement intent

Limit scope and exposure by isolating the CDE.

Common constraint

Cloud-native architectures may have shared services that complicate segmentation.

Compensating controls

  • Strong identity-based access controls at the cloud layer

  • Separate accounts/subscriptions for payment workloads

  • Micro-segmentation using security groups and policies

  • Continuous monitoring of traffic flows

  • Regular segmentation testing evidence

Key point

Segmentation must be demonstrable, even if implemented differently from traditional networks.

Example 3: Inability to meet a specific log retention mechanism

Requirement intent

Security logs must be retained and available for review.

Constraint

A SaaS platform may not support native long-term retention on certain managed services.

Compensating controls

  • Export logs to a central SIEM or immutable storage

  • Enable write-once storage controls

  • Implement automated alerts on critical events

  • Maintain documented review procedures

Outcome

Log integrity and availability are maintained even if retention is outsourced.

Example 4: Vulnerability scanning tool limitations in cloud environments

Requirement intent

Systems must be regularly scanned for vulnerabilities.

Constraint

Traditional scanning tools may not cover ephemeral workloads (containers, serverless).

Compensating controls

  • Use container image scanning in CI/CD pipelines

  • Continuous dependency monitoring (SCA tools)

  • Cloud-native vulnerability management services

  • Defined remediation SLAs and tracking

Why it is acceptable

Security outcomes are achieved through modern tooling rather than legacy scanners.

Example 5: Encryption requirement met through tokenisation

Requirement intent

Stored cardholder data must be unreadable.

SaaS/FinTech reality

Most organisations avoid storing PAN entirely.

Compensating control approach

  • Use tokenisation from the payment provider

  • Ensure no PAN storage in internal databases

  • Implement controls preventing card data capture in logs

  • Regular checks that only tokens are stored

Important note

Tokenisation is often a better control than encryption when properly implemented.

Example 6: Secure development controls for small engineering teams

Requirement intent

Software must be developed securely.

Constraint

Early-stage SaaS companies may not have formal SDLC processes yet.

Compensating controls

  • Mandatory peer code review via pull requests

  • Automated security testing in CI/CD

  • Separation between dev and production environments

  • Controlled release approval workflows

Outcome

Security assurance is maintained without heavyweight bureaucracy.

Example 7: Physical security controls in remote-first organisations

Requirement intent

Prevent unauthorised physical access to systems in scope.

Constraint

SaaS companies may have no central office or use managed co-working spaces.

Compensating controls

  • No on-premise cardholder systems at all

  • Cloud-only payment environments

  • Strong endpoint controls for staff devices

  • Identity-based access restrictions and logging

Key point

Reducing physical scope entirely is often the strongest approach.

Example 8: Third-party managed services reduce direct control

Requirement intent

Service providers must be managed securely.

Constraint

Organisations rely heavily on cloud providers, PSPs, and MSPs.

Compensating controls

  • Document shared responsibility clearly

  • Maintain supplier due diligence records

  • Require PCI compliance attestations from providers

  • Restrict and monitor third-party access

  • Annual reassessment of supplier risk

Why it matters

Outsourcing does not outsource accountability.

Example 9: Patch timelines cannot always meet strict schedules

Requirement intent

Critical vulnerabilities must be remediated promptly.

Constraint

Regulated FinTech environments may require extended testing before patching production.

Compensating controls

  • Temporary risk mitigations (WAF rules, network restrictions)

  • Enhanced monitoring until patch deployment

  • Formal risk acceptance with approval

  • Accelerated patching for the highest-risk systems

Outcome

Risk is controlled even when patching is delayed for valid reasons.

Example 10: Requirement met through stronger alternative controls

Requirement intent

Reduce exposure to cardholder data.

SaaS best practice

Instead of compensating for missing controls, many SaaS firms reduce scope entirely by:

  • Fully outsourcing payments

  • Using hosted checkout pages

  • Eliminating PAN handling internally

This often results in SAQ A rather than SAQ D — the strongest form of “compensating” is removing card data from your environment.

Best practice guidance

Compensating controls should always be:

  • Rare and well-justified

  • Approved internally and documented formally

  • Reviewed regularly

  • Supported by strong, audit-ready evidence

Assessors are far more likely to accept compensating controls that are:

✅ layered
✅ measurable
✅ continuously monitored
✅ clearly risk-reducing

Key takeaway

SaaS organisations often rely on modern architectures that don’t map perfectly to traditional PCI controls. Compensating controls allow flexibility, but only when they clearly deliver equivalent security outcomes and are properly documented.