A legacy system cannot meet a PCI DSS v4.0.1 requirement as written: when do you use a compensating control, and when the customized approach?
answer
- constraint versus design choice
- above and beyond other requirements
- Appendix C's six worksheet rows
- 12.3.2 risk analysis per control
- no SAQ, no objective, no mix
basics
~20 sUnder PCI DSS v4.0.1, a compensating control answers a documented constraint within the defined approach, via Appendix C's worksheet. The customized approach is a chosen design meeting a requirement's objective, backed by Requirement 12.3.2's targeted risk analysis and ROC validation.
solid answer
~50 sA **compensating control** belongs to the defined approach and is for an entity that cannot meet a requirement *as stated* because of a legitimate, documented technical or business constraint. Appendix B says it must meet the intent and rigor of the original requirement, provide a similar level of defense, be **above and beyond** other PCI DSS requirements, address the added risk, and cover the requirement now and in future - never a task missed in the past. It is documented on the Appendix C worksheet and validated by the assessor every year. The **customized approach** is a deliberate alternative design that meets a requirement's *Customized Approach Objective*; the entity keeps a controls matrix, performs a **Requirement 12.3.2** targeted risk analysis per control, approved by senior management and repeated at least every 12 months, and the assessor derives its own tests. It is unavailable for requirements with no objective, for SAQ entities, and compensating controls cannot be layered on it.
go deeper
Recall that compensating controls answer a documented constraint and the customized approach meets a stated objective differently, and that they are separate mechanisms.
Explain the Appendix B criteria, especially above and beyond, and what the Appendix C worksheet and a 12.3.2 targeted risk analysis each document.
Run the exception: pick the mechanism for a real legacy gap, build the evidence, keep it effective between assessments and plan the exit.
Judge whether the organization's risk function is mature enough to carry the customized approach's documentation and testing load across many requirements.
## Two escape hatches with different purposes **PCI DSS v4.0.1** offers two ways to satisfy a requirement other than implementing its defined text. They answer different situations and they cannot be combined. | | Compensating control | Customized approach | |---|---|---| | Belongs to | The **defined approach** | The **customized approach** | | Trigger | A legitimate, documented technical or business **constraint** prevents meeting the requirement as stated | A **choice** to meet the requirement's objective another way | | Target | The intent and rigor of the original requirement | The requirement's stated **Customized Approach Objective** | | Documentation | Appendix C **Compensating Controls Worksheet** | Controls matrix plus a **targeted risk analysis** under Requirement 12.3.2 | | Testing | Assessor reviews and validates sufficiency every year | Entity tests effectiveness; assessor **derives** testing procedures | | Validation route | ROC or SAQ | ROC only, by a QSA or ISA | | Intended for | Any entity with a real constraint | "Risk-mature entities" with robust risk management | ## Compensating controls - Appendix B and C Appendix B sets the criteria. A compensating control must: 1. Meet the intent and rigor of the original requirement. 2. Provide a similar level of defense, sufficiently offsetting the risk the requirement defends against. 3. Be **"above and beyond"** other PCI DSS requirements - simply complying with other requirements is not a compensating control. 4. Pass the above-and-beyond test: requirements already required for the item under review cannot count; requirements required elsewhere but not for this item may; existing requirements may be combined with new controls. 5. Address the additional risk created by not meeting the requirement. 6. Address the requirement currently and in the future - it **cannot** fix a requirement missed in the past, such as a task that was due two quarters ago. The standard's own example: a vulnerability exploitable through a network interface, with no security update available from the vendor, compensated by internal network segmentation, limiting access to the vulnerable interface to required devices, and IDS/IPS monitoring of all traffic to it. The **Appendix C worksheet** records six things: the constraints, the definition of the compensating controls, the objective of the original control and the objective the new control meets, the identified additional risk, how the controls were validated and tested, and how they are maintained. The assessor must evaluate every compensating control at each annual assessment, and the results go into the ROC or SAQ. ## The customized approach - Appendix D and Requirement 12.3.2 The customized approach lets an entity meet a requirement's **Customized Approach Objective** "in a way that does not strictly follow the defined requirement". The controls are expected to meet or exceed the security the defined requirement provides. The entity must: - document each customized control in a **controls matrix**; - perform a **targeted risk analysis** for each one under **Requirement 12.3.2**, which requires the Appendix D evidence, **approval by senior management**, and repeating the analysis at least once every 12 months; - test each control's effectiveness and keep monitoring it; - hand the matrix, risk analysis and evidence to the assessor. The assessor then **derives** testing procedures, because there are none predefined, and a QSA involved in designing a customized control may not assess it. Limits: - **Not every requirement is eligible.** Some carry no Customized Approach Objective - for example, Requirement 3.3.1 on not storing SAD after authorization is marked "not eligible for the customized approach". - **SAQ entities are not eligible**; they would need a QSA or ISA assessment documented on the ROC Template. - **Compensating controls are not an option** with the customized approach. - The brands and acquirers may regulate its use, including whether an ISA may perform it. ## Choosing for the legacy system - **The system will be replaced within the year** and the gap is a constraint: a compensating control, with a maintenance plan and the worksheet, is the natural fit. - **The organization has a better control by design** - for example, a different way of meeting an authentication objective - and a mature risk function: the customized approach, accepting the higher documentation and testing effort. - **The gap is in the past** (a quarterly activity skipped): neither helps; the requirement is simply not in place until the activity is performed and the schedule re-established. Do not confuse Requirement 12.3.2 with **Requirement 12.3.1**, the targeted risk analysis used to set the *frequency* of activities where the standard allows it, such as payment-page tamper detection under 11.6.1. Enterprise-wide risk assessment methods are a separate subject.
- Under PCI DSS v4.0.1, can an entity cite strong password rules to compensate for sending admin passwords unencrypted?No. Appendix B uses this exact case: other password requirements such as lockout and complexity are already required for the item under review and do not mitigate interception of cleartext passwords, so they cannot be compensating controls.
- Under PCI DSS v4.0.1, may one requirement be met with the defined approach in one environment and the customized approach in another?Yes. The standard allows both approaches within one environment, including the same requirement met by the defined approach for one system component and the customized approach for another, so an assessment can mix defined and derived testing procedures.
saying these in an interview costs you the question
- A compensating control can cover a quarterly task the entity skipped earlier in the year.
- Meeting other PCI DSS requirements more strictly counts as a compensating control.
- The customized approach is available for every PCI DSS requirement.
- A merchant validating with an SAQ can use the customized approach if it documents a risk analysis.
- A customized control that underperforms can be topped up with a compensating control.