PCI DSS compensating controls: when they are allowed and how to document them

When can a PCI DSS compensating control stand in for a requirement?

Imagine an assessor asking why a requirement you cannot meet as written is not a finding. A compensating control is allowed only when a documented, legitimate constraint prevents you from meeting a requirement and the control you put in its place meets the intent of that requirement. The Qualified Security Assessor (QSA) judges whether the control is sufficient during the assessment. The PCI Security Standards Council does not approve specific configurations or controls in advance, so the answer is never a yes from the standard alone. The answer depends on three things: the constraint, the risk and the evidence. A constraint must be real and specific, such as a legacy platform that cannot run a required function or a vendor product with no supported update path, not a budget preference or a project delay. The risk must be stated in terms of what the requirement protects, and the control must reduce that risk in a measurable way. Evidence must show the control operates, not just that it was designed. For SAQs, every response of In Place with CCW requires the Compensating Controls Worksheet in Appendix B, so confirm with your acquirer or the brand which questionnaire applies before you start.

How to document a compensating control worksheet

A compensating control is only as credible as its paper trail. Each element of the worksheet answers a question an assessor will ask, from which requirement is affected to how the control is kept working over time. Every In Place with CCW response in an SAQ needs the worksheet in Appendix B, and a ROC carries equivalent detail in the assessor's documentation.

Requirement and constraint

Name the exact PCI DSS requirement the control stands in for, then state the legitimate technical or business constraint that prevents meeting it as written. A constraint such as an unsupported platform or a system that cannot be changed without breaking payment processing must be specific and evidenced. Vague statements like "cost is too high" do not establish that the requirement cannot be met. Ask your assessor early whether the constraint is one they will accept.

Objective and identified risk

Restate the intent of the requirement in your own words, then describe the specific risk that remains unaddressed because the control is not met as written. Assessors judge sufficiency against the intent, so the objective should be stated in terms of what the requirement protects. A risk statement tied to a named system and data flow is far easier to validate than a generic description of threats.

Definition of the control

Describe the compensating control precisely enough that a second person could configure, operate and test it. Name the technologies, settings, owners and the systems in scope. For example, an illustrative control might combine network isolation with application allow-listing on a specific host group. Vague descriptions such as "enhanced monitoring" will not survive review.

How the control addresses the risk

Map each part of the control to the risk you identified, showing which element reduces likelihood and which limits impact. Explain why the combined controls provide a level of protection comparable to the requirement. The assessor needs to see a reasoned argument, since the PCI SSC does not pre-approve configurations and the QSA decides whether the intent is met.

Validation and testing evidence

Record how the control was tested, by whom, when, and what result was obtained. Attach configuration exports, test scripts, alert samples and sign-off records that the assessor can sample during the review. Evidence should show the control working in the live environment, not only that it was designed. Confirm with your QSA which evidence format they expect.

Ongoing maintenance and review

Document the recurring activities that keep the control effective: the periodic risk assessment, the change triggers that force a review, and the owner responsible for each. Compensating controls for systems that must be migrated also need an active plan with dates and milestones. Missing a periodic review undermines the control, so assign a calendar and a named owner before the assessment begins.

Who decides whether a compensating control is sufficient

The PCI Security Standards Council does not approve specific compensating controls or configurations. Sufficiency is decided during each assessment. The Qualified Security Assessor (QSA) examines the control in the environment and decides whether it meets the intent of the requirement it replaces. QSAs are trained by the Council on that intent, which is why two organizations with similar designs can reach different outcomes depending on how the control is built, operated and evidenced. An organization should not expect a pre-clearance letter from the Council for a design, and should be cautious about any third party that offers one.

The organization owns the control. Its management decides whether to use a compensating control, defines what it does, assigns the people who run it, and funds its operation and its annual and change-driven risk assessments. An implementation partner can help design the control, draft the worksheet, and collect the supporting evidence, but that work prepares the file rather than validating it. Ask any partner to state in writing which parts of the work it performs and which parts remain with your team and your assessor.

Validation belongs only to the independent assessor. On a Report on Compliance, the QSA tests the compensating control and records the conclusion in the ROC. On a Self-Assessment Questionnaire, the In Place with CCW answer and its Appendix B worksheet are reviewed as part of the Attestation of Compliance process, and the entity signing the AOC is accountable for the accuracy of what it declares. Before committing budget to a design, confirm with your acquirer or the payment brand that requires validation which assessor and which document will be used, and agree the test evidence the assessor will need on day one.

Where compensating controls cannot be used

A compensating control only substitutes for a requirement when a legitimate constraint blocks the defined approach and the control meets the requirement's intent. The boundaries below mark where that substitution fails, so teams know which gaps need corrective action rather than a worksheet.

Missed periodic activities cannot be backdated

If a quarterly scan or an annual review was skipped before the assessment, a compensating control cannot be written retrospectively to cover the gap. The assessor can find the requirement in place only after the entity performs corrective action and the activity runs successfully. Teams should check their recurring task calendar and logs well before the assessment window opens, because the gap will be visible in the evidence for the period under review.

Unwanted requirements are not optional

A compensating control is not a route around a requirement the organization finds inconvenient, expensive or out of step with its roadmap. The constraint must be a documented, legitimate technical or business limitation that prevents meeting the defined approach. Preference, cost alone or a missing budget line does not qualify, and assessors will ask why the requirement cannot be met as written.

The worksheet cannot prove intent

A completed worksheet does not establish sufficiency by itself. The QSA decides whether the control meets the intent of the requirement, and the PCI SSC does not pre-approve specific configurations. A control that only reduces some risk, or that cannot be shown to operate continuously, will be rejected even when the paperwork is complete.

Unsupported systems need a migration plan

Isolation, allow-listing and monitoring can address the risk of an unsupported operating system only temporarily. The entity must keep an active plan to migrate to a supported system, and the control does not remove the need for that plan. A compensating control with no migration date, or one that has been left in place for years, will not satisfy an assessor.

Controls must stay in force

A compensating control is validated for the assessment period and must operate throughout it, not only on the day the assessor visits. Any change that weakens the control, including a new system, a changed data flow or a new recording platform, requires the control to be reassessed. Teams should confirm that change management triggers a fresh review of every active worksheet.

Unsupported systems and call recordings as worked examples

Consider an illustrative case: a payment reporting server runs an operating system whose vendor has stopped issuing security patches, and the application it hosts cannot be moved until a vendor release is certified. PCI DSS expects patches for system components, so the gap cannot simply be declared closed. PCI SSC FAQ 1130 accepts that compensating controls such as isolation, application allow-listing and active monitoring may address the risk temporarily, provided the entity keeps an active plan to migrate to a supported system.

Isolation: Place the server in its own network segment with deny-by-default rules that allow only the specific flows the application needs, documented in the network diagram.
Application allow-listing: Permit only approved binaries and scripts to execute, so that unpatched code paths are harder to reach.
Active monitoring: Log and alert on configuration drift, new listening services and unexpected outbound connections, with the alerts reviewed by a named team.
Migration plan: Keep a dated, owned plan with budget approval, test milestones and a cutover target, updated as the schedule changes.
Worksheet entries: Record the constraint, the risk it creates, each control's objective, how it was tested and the evidence an assessor can sample.

Before the assessment, confirm with your QSA which controls they will test and what evidence of the migration plan they expect to see.

How the compensating control moves from design to annual validation

The sequence turns an unmet requirement into a documented, tested control that a QSA can validate during the assessment and that stays valid through later change and annual reviews. Each step produces a record that the next step depends on.

Identify the legitimate technical or business constraint
The entity names the specific reason it cannot meet the requirement as written, such as a system that cannot be upgraded or a data store that cannot be securely purged. The constraint is usually raised by the system owner and confirmed by security and the business. The output is a short constraint statement that names the requirement, the affected system and why the defined approach is not possible. Consider this done when someone outside the project team can read it and understand why the requirement cannot be met directly.
Document the risk the requirement addresses
Security writes down the risk the requirement exists to reduce, in terms of the cardholder data and systems affected, the threats that matter and the impact if the risk occurs. The risk statement should map to the intent of the requirement, not only to the requirement's wording. The output is a risk record linked to the constraint and to the entity's risk assessment. It is complete when a QSA could trace the requirement's objective to the specific exposure the control must address.
Design the control to meet the requirement's intent
The team selects controls that reduce the documented risk in a different way, such as isolation, restricted access, additional monitoring, encryption or enhanced logging. Each control is described with its configuration, owner, operating procedure and the way it is monitored. The output is a control design that shows how each element addresses the risk. The design is ready when every risk statement has at least one control tied to it and the owners have accepted their duties.
Test the control before relying on it
The entity tests the control in the environment where it runs, checking that it works as designed and that gaps are visible. Testing often combines configuration review, sample evidence and an attempt to bypass the control. The output is dated test results with the tester's name, the findings and any corrective actions. Do not move to documentation until the tests pass or the design has been changed and retested.
Complete the compensating controls worksheet
The entity completes the Compensating Controls Worksheet, which records the constraint, the objective of the requirement, the identified risk, the controls, the testing performed and the evidence for each. Where the entity uses a Self-Assessment Questionnaire, each In Place with CCW response depends on this worksheet in Appendix B. The output is a signed worksheet and a matching evidence folder. It is complete when a reviewer can follow each statement to an artifact.
Have the QSA validate sufficiency during the assessment
The QSA examines the worksheet, the design, the tests and the operating evidence during the assessment and decides whether the control meets the intent of the requirement. The PCI SSC does not approve specific compensating controls in advance, so this judgment belongs to the assessor. The output is the assessor's finding in the Report on Compliance, or the assessor's acceptance in an SAQ review. Ask the assessor early whether the proposed design meets the intent, since a rejected control has to be redesigned and retested.
Maintain the control through risk assessments
The entity repeats the risk assessment at least annually and whenever the environment changes, confirming that the constraint still exists, the risk is still covered and the control still operates. It also keeps the protection of the data, restricted access and monitoring in place between assessments. The output is an updated worksheet, dated risk assessment results and retained operating evidence for the next validation. If the constraint disappears, for example after a system is replaced, the control is retired and the requirement is met directly.

Mistakes that get compensating controls rejected

Most rejected compensating controls fail for the same reasons: the justification rests on cost, the control misses the risk it claims to address, the supporting risk assessment lapses, or the control is left in place as a permanent substitute. Each card below names one failure and the check that prevents it before the assessor arrives.

Citing cost as the constraint

A compensating control must rest on a legitimate technical or documented business constraint, and cost alone is not one. Assessors expect the constraint to be specific, such as a legacy platform that cannot run the required software, and they expect evidence that the entity tried the defined approach first. Before drafting the worksheet, write down the technical reason the requirement cannot be met as written. If the only reason is budget, the control is likely to be rejected, and the honest path is remediation.

Control does not address the stated risk

A compensating control must meet the intent of the requirement it replaces, which means it has to reduce the same risk. A control that adds monitoring but does not restrict the access the requirement targets will not satisfy an assessor. Map each element of the worksheet to the specific risk it addresses, then ask whether an attacker who exploits the gap would still be stopped or detected. The QSA makes this judgment during the assessment, so the worksheet should show the reasoning, not only the control names.

Missing the annual risk assessment

A compensating control that stands in for an unmet requirement depends on recurring risk assessment, both annually and whenever the environment changes. Without current assessments, the entity cannot show that the control still reduces the risk, and the justification goes stale. Schedule the review on the same calendar as the assessment, record the date, the participants and any changes to the environment, and keep the results with the worksheet. Assessors look for this record during validation.

Treating an interim control as permanent

A compensating control for an end-of-life or unsupported system is a temporary measure, not a lasting exemption. The entity must keep an active plan to migrate to a supported system, and the assessor will look for evidence that the plan is moving, with owners, dates and budget decisions. A control that has remained in place for years with no migration activity signals that the control is being used to avoid remediation. Track the migration plan alongside the worksheet and update both at each review.

Reusing a worksheet without testing it

Entities often copy a worksheet from a previous assessment or a peer organization without confirming that it fits their own environment. Controls such as isolation, allow-listing or monitoring only work when they are configured and operating in the current systems, and a generic description will not persuade an assessor. Confirm each control is in place, record how it was tested, and identify the owner who operates it. Worksheets that describe the actual environment are far easier to defend.

Questions buyers ask about compensating controls

Is a compensating control cheaper than meeting the requirement?

Not usually, and it should not be chosen for cost alone. A compensating control is an alternative that must meet the intent of the requirement at the same level of protection, so it often needs its own design, monitoring, periodic risk assessment and evidence. The cost drivers are the engineering to build the alternative, the tooling and staff time to run it, and the assessor time to test it each year. Those costs recur. Ask any partner to separate one-time build work from the annual effort to keep the control running, and to show which parts your own team will carry. Compare the total of both paths over several assessment cycles, not the first quarter.

Who writes the compensating controls worksheet?

The entity writes it. Your organization documents the constraint, the objective of the requirement, the controls you put in place, how each one addresses the risk, and the evidence that shows they operate. An implementation partner can help draft the content and prepare the supporting evidence, but the worksheet describes your environment and must be owned by your staff. On a SAQ, the worksheet sits in Appendix B. On a ROC, the QSA documents the control in the report. Either way, the assessor then tests it, and the people who run the systems should be able to explain it without reading the document.

Does the PCI SSC pre-approve compensating controls?

No. The PCI SSC does not approve specific configurations or compensating controls in advance. QSAs, who are trained by the SSC on the intent of requirements, decide during the assessment whether a control meets that intent for your environment. This means the same design can pass in one environment and fail in another, depending on the systems, data flows and risk. Before you build anything, agree the proposed approach with your QSA or acquirer in writing so that you do not invest in a design the assessor will reject. Acquirer acceptance is a separate question that depends on your payment brand and acquirer.

Can a self-assessment questionnaire include a compensating control?

Yes, but only in a specific way. Every SAQ response of In Place with CCW requires a Compensating Controls Worksheet in Appendix B of the SAQ. The response must still describe the control clearly, and the entity must be able to show the controls operating. Some organizations are surprised that a SAQ cannot document a customized approach, so a compensating control on an SAQ is not a substitute for a customized design. Check the SAQ eligibility rules for your payment channel before relying on this route, because an SAQ that is not eligible for your environment will not be accepted regardless of the worksheet.

How long can a compensating control stand in for a requirement?

A compensating control is meant to be temporary or a sound long-term design only where the constraint is real and persists, and it must be reassessed. The assessment is annual, and the control must keep meeting the intent of the requirement at each assessment. Risk assessments are repeated annually and when changes occur, so a control that worked when first approved may need redesign after a system change. Unsupported systems illustrate the temporary side: the entity keeps an active plan to migrate. Missed periodic activities cannot be covered this way, so a control is never a way to skip a recurring task.

What must we provide to the QSA to support a compensating control?

Provide evidence that the control exists, operates and is reviewed. Typical items include the written justification for the constraint, the risk analysis and its date, the control design and configuration, change records, access lists, monitoring and alert logs, and records of periodic review. For the call recording example that PCI SSC FAQ 1210 describes, the set includes annual and change-driven risk assessments, protection of the data, restricted access and query logs, and the documented justification. Ask the QSA for a list of expected evidence before the assessment starts, and assign an owner to each item so the evidence is ready when the assessor samples it.

Can DeployOpen prepare the compensating controls evidence for our assessment?

DeployOpen can plan, implement and document self-hosted open-source platforms inside your own infrastructure, and prepare the systems, controls and evidence that a compensating control relies on, such as monitoring configuration, access records and review logs. Work is fixed-scope, with scope and deliverables agreed in writing before work starts. DeployOpen does not issue reports, attestations or certifications and does not decide whether a control is sufficient. That judgment belongs to your QSA, and your organization owns the control and the worksheet. Ask us to confirm the exact deliverables in the written scope.

What to confirm with your QSA before relying on a control

Before you build a compensating control into your plan, confirm three things with your QSA: which requirement the control is meant to satisfy, what evidence the QSA expects to see, and whether the control fits your validation route. The PCI SSC does not approve specific compensating controls. The QSA decides during the assessment whether a control meets the intent of the requirement, so an informal sign-off from a vendor, a consultant or an internal reviewer carries no weight in the final report. Ask the QSA to name the requirement in writing, then describe the control against that requirement's intent rather than against your preferred wording.

Next, ask what the QSA will test and how often. Ask which artifacts will demonstrate the control working across the assessment period, such as risk assessment records, access reviews, configuration exports, monitoring logs or the documented justification for the control. Also confirm whether the control belongs on a Compensating Controls Worksheet in Appendix B of a self-assessment questionnaire, or whether it requires a Report on Compliance. A control that is acceptable on one route can be out of place on another, so settle the route before you design the control.

The organization owns the control, its operation and its risk decision. DeployOpen can prepare the systems, configurations and evidence that a QSA will review, and can help document the control and its supporting processes. DeployOpen does not issue reports, attestations or certifications, and the QSA's conclusion is the only validation that counts. Write these answers into your engagement records, so that your internal owner, your implementation partner and your assessor all work from the same understanding of the control.

How DeployOpen prepares compensating control evidence

DeployOpen works on PCI DSS compensating controls as an implementation partner, not as the assessor. We help clients scope the system where a compensating control is proposed, build and document the control inside their own infrastructure, and assemble the evidence a QSA will test. The organization owns the decision and the control, and only the QSA decides whether it meets the intent of the requirement.

How we scope

Written scope agreed before work starts, naming the requirement, the constraint and the systems affected.
Confirmation of whether the constraint is genuinely technical or documented, so the control is not used for a requirement that can be met as written.
Identification of the data flows, systems and people that the proposed control must protect and cover.

How we build

Design of the compensating control inside the client's cloud accounts, data centers or air-gapped networks, using self-hosted open-source platforms where suitable.
Configuration of access restriction, logging and monitoring so that each claim in the worksheet can be shown with system output.
Preparation of the risk analysis and periodic review tasks that the control depends on, including reviews after material changes.

How we hand over

A completed compensating controls worksheet draft, with each element mapped to the evidence that supports it.
A collection of configuration exports, logs, review records and test results arranged for the QSA to sample.
Documentation of ownership, review cadence and the migration or retirement plan, handed to the client's team to maintain.

How we support

Support for the client's team during the QSA's questions, providing evidence and explaining how the control operates.
Ongoing support, upgrades and continuous testing available as a retainer after the initial engagement.
Confirmation with the client's QSA early on which evidence they expect, since the assessor makes the final judgment on sufficiency.