Should you use the PCI DSS customized approach or the defined approach?
You are probably here because a QSA has questioned how a control is met, a customer questionnaire asks for evidence that does not match your documented procedure, or you are planning to redesign a control and want to know whether the standard lets you do it differently. PCI DSS v4.x lets each requirement be met through the defined approach, which follows the requirement as written, or, for entities with robust security and risk management, the customized approach, which meets the stated objective of the requirement in a different way. The customized approach is an option, not a shortcut, and it is only available where your risk management is mature enough to support it.
The right choice depends on three things: the specific control, your organization's risk maturity, and whether the assessment will end in a Report on Compliance (ROC) or a Self-Assessment Questionnaire (SAQ). Each customized requirement needs its own targeted risk analysis, and SAQs cannot document the customized approach at all, so an entity that wants to use it will generally need a ROC. Before committing, confirm with your QSA that the control's objective is clear, that your team can produce the risk analysis and the evidence, and that the change is worth the added documentation. The organization owns this decision and the controls behind it. The QSA judges whether the customized approach meets the objective, and the PCI SSC does not approve individual designs in advance.
Which option fits a given requirement?
This table compares the defined approach, the customized approach and a compensating control across who uses each one, the evidence it needs, the targeted risk analysis it requires, whether an SAQ can document it and what the QSA reviews. Read each column as one path for a single requirement, and note that the customized approach always requires a ROC.
| Question | Defined approach | Customized approach | Compensating control |
|---|---|---|---|
| Who uses it | Any entity meeting the requirement as written | Entities with robust security and risk management that can meet the stated objective another way | Entities that cannot meet a requirement for a documented, legitimate technical or business constraint |
| Evidence needed | Evidence that the requirement as written is met | Documented design, how the objective is met, and evidence it stays met over time | Completed compensating control worksheet and evidence it covers the requirement's intent |
| Targeted risk analysis | Required only for requirements that let the entity set activity frequency (12.3.1) | Required for each customized requirement (12.3.2) | Not a TRA. The worksheet documents the constraint, risk and controls instead |
| Can an SAQ document it? | Yes, where the SAQ applies | No. SAQs cannot document customized approach objectives | Yes, through the compensating control worksheet where the SAQ applies |
| Validation document | ROC or SAQ, depending on eligibility | ROC is required | ROC or SAQ, depending on eligibility |
| What the QSA reviews | Whether the requirement as written is met in scope | Whether the objective is met, the risk analysis is sound and the approach is sustained | Whether the control meets the intent of the requirement, decided by the QSA |
Who the customized approach is meant for
The customized approach is meant for entities with robust security and risk management, where the organization can show that it understands its own risks well enough to design a different way of meeting a requirement's stated objective. It is not a cheaper or easier route to compliance. An entity that chooses it takes on more analysis, more documentation and more explanation to the assessor than the defined approach asks for. Before deciding, ask whether your security program already identifies assets, threats and risk owners, reviews those risks on a schedule, and changes controls when the risk picture changes. If those practices exist only in a policy document, the customized approach will expose the gap rather than close it.
A customized design has to show more than a working control. It has to explain which objective the requirement sets out, how the entity's implementation meets that objective, why the approach is sound for the environment it runs in, and how the entity will know it is still working. Each customized requirement also needs its own targeted risk analysis, so the design, the analysis and the monitoring must agree with one another. A small team without a documented risk program usually stays with the defined approach, because it would have to build that program first and would then carry a heavier evidence burden in the assessment. Confirm your team's capacity to maintain these records before committing to any customized requirement.
The PCI SSC blog describes the customized approach as a way for mature organizations to meet intent in a different manner, and it is the QSA who judges whether a particular design does so. The Council does not approve individual designs in advance. Expect the assessor to test the objective, the risk reasoning and the ongoing review, and to reach a conclusion that you cannot predict from the standard alone. Agree the proposed design with your QSA early, in writing, before it is built into systems or processes that would be costly to change.
What the targeted risk analysis for a customized requirement must show
A targeted risk analysis is the documented reasoning that justifies a customized implementation or a flexible frequency. Assessors read it to confirm that the entity understood the threat, chose a control that meets the stated objective, and keeps that reasoning current. The cards below cover the parts that analysis must contain and the two distinct cases it serves.
Assets and threats in scope
The analysis starts by naming the assets the requirement protects, such as cardholder data stores, payment application servers or administrator credentials, and the threats that could compromise them. Vague statements like "malware risk" do not give an assessor enough to test. Check that each asset maps to a system in your inventory and that each threat is specific to how your environment is built and operated.
Likelihood and impact factors
Each threat needs a documented view of how likely it is to occur and what it would cost if it did. The analysis should state which factors drive those judgments, such as exposure of a system to the internet, the volume of account data at risk, or past incidents. Record the basis for each rating so an assessor can follow the reasoning rather than accept a bare score.
Frequency justification for 12.3.1
Requirement 12.3.1 applies to any requirement that lets you choose how often an activity runs. Here the analysis must identify the assets and threats, weigh likelihood or impact, and justify the chosen frequency. It has been mandatory since 31 March 2025, and a frequency set without this documented reasoning will not satisfy an assessor even when the chosen interval looks reasonable.
Objective-based analysis for 12.3.2
Each requirement met through the customized approach needs its own targeted risk analysis, separate from any frequency analysis. It should describe the stated objective of the requirement, the control you built instead, and why that control meets the objective. Ask whether a QSA could test the control against the objective without needing the original requirement wording to interpret it.
Link to the customized control
The analysis must show how the customized control meets the stated objective in practice. Name the mechanisms, owners, and the evidence each produces, and state any residual risk that remains. Confirm with your QSA which evidence they expect for each customized control before you build it, because the control design and the documented reasoning need to match.
Review every 12 months
A targeted risk analysis is not a one-time document. The analysis must be reviewed at least every 12 months, and earlier when the environment, threat landscape or system architecture changes materially. Assign an owner, keep dated versions, and record what changed at each review so the assessor can see the analysis tracks the environment it describes.
Why an SAQ cannot document a customized requirement
An entity that expects to validate with a Self-Assessment Questionnaire should know early that SAQs cannot be used to document the customized approach. The SAQ templates have no place to record a customized approach objective, so any requirement met that way does not appear in the questionnaire at all. For an entity whose only route was an SAQ, this is a scoping problem before it is a documentation problem. If the environment depends on a customized implementation, the SAQ may simply not be the right vehicle, and the entity needs to confirm which template its acquirer or payment brand accepts for that year.
The likely route is the Report on Compliance template, which a Qualified Security Assessor completes. The PCI SSC notes that entities validating with the customized approach may be able to use the ROC template instead, but that is a possibility to confirm, not a guarantee. The QSA decides whether the entity's circumstances and the customized implementations fit the ROC. Ask the QSA to confirm eligibility in writing before the assessment begins, and ask it to show how each customized requirement's targeted risk analysis will be tested. Plan the time for this step, because discovering the mismatch during fieldwork can move the validation date.
For the Attestation of Compliance, the practical result is that the AOC must match the template actually used. A ROC-based AOC will reflect the customized approach, while an SAQ-based AOC will not. Customers, processors and acquirers that ask for evidence should receive the AOC that corresponds to the completed report, and they may ask why an SAQ does not list every requirement in the environment. Confirm with your acquirer or payment brand which template and AOC form they will accept, and confirm the current versions of both with the PCI SSC before you commit to a timeline.
How to prepare a customized requirement for QSA review
This sequence turns a customized approach from an idea into a documented, tested control that a QSA can assess without surprises. Each step produces a record the entity owns, and the final brief sets up the QSA to test the design against the stated objective.
Confirm the requirement and its stated objective
Start by reading the specific requirement and its objective as written in the current PCI DSS v4.0.1 text, and confirm that the customized approach is available for it. Security or compliance staff own this step. The output is a short scoping note naming the requirement ID, the objective it must meet, and the systems in the cardholder data environment it covers. You know it is done when the team agrees on the objective in writing, because every later step is tested against it.
Decide the approach with the business owner
Hold a decision meeting with the business owner of the affected system to choose between the defined approach and the customized approach. Compare the operational effect, the ownership of the control and whether the organization has the security and risk management maturity the customized approach assumes. The output is a signed decision record stating the chosen approach, the rationale and the accountable owner. Record a decision to stay with the defined approach just as carefully, since it avoids later rework.
Write the targeted risk analysis
Prepare a documented targeted risk analysis for the customized requirement. It should identify the assets involved, the threats the requirement addresses, the likelihood and impact factors, and why the customized control meets the objective. Security leadership approves it and the record is dated and version controlled. The output is a signed targeted risk analysis that the entity must review at least every 12 months. You know it is done when a reviewer outside the project can follow the reasoning from threat to control without asking questions.
Design and implement the control
Engineering and operations teams design the control so it meets the stated objective, then implement it in the production environment. Document the design in a control description covering how the control works, which components it depends on, who operates it, what triggers it and how failures are detected and escalated. The output is an approved control description plus change records showing the control was deployed. Confirm that the implemented configuration matches the description before moving on.
Collect evidence across the assessment period
Run the control in production and collect evidence continuously throughout the assessment period, not only at the end. Typical evidence includes configuration exports, logs, tickets, review records and test results, each tied to the control description and the targeted risk analysis. The compliance lead owns the evidence set and checks periodically that records are complete, dated and retrievable. The output is an indexed evidence set that shows the control operated as described, which the QSA will sample during testing.
Brief the QSA on the design before testing
Before formal testing begins, brief the QSA on the control design, the targeted risk analysis and the objective the control is meant to meet. Walk through the evidence index and explain where each objective-related artifact lives. Ask the QSA to confirm the testing approach in writing so there is no disagreement at the end. The output is a meeting record and the QSA's agreed test plan. Whether the QSA accepts the customized design remains the QSA's independent judgment, and the organization should not expect the briefing alone to settle it.
Who does what: your team, an implementation partner and the QSA
Your organization owns every control and every risk decision, including the customized approach. Control owners are the people accountable for each requirement in the cardholder data environment, usually across security, IT operations, engineering and payments. They decide whether a customized approach is justified, approve the targeted risk analysis and accept any residual risk in writing. Those decisions cannot be delegated to a partner or to the QSA.
- Targeted risk analysis: Owners identify the assets, threats and likelihood or impact factors for each customized requirement and approve the resulting frequency or method.
- Control design: Owners define how the customized control meets the stated objective and assign operating responsibility.
- Evidence preparation: Owners confirm that the evidence shows the control operating over the assessment period, not only that it was designed.
- Final ROC review: Owners check factual accuracy in the ROC and confirm that the described controls match their environment.
- Risk acceptance: Owners sign off on the risk decision and schedule the review of each targeted risk analysis at least every 12 months.
Confirm with your QSA which evidence formats and sign-off records they expect before you start the work.
An implementation partner prepares systems, documentation and evidence so that your control owners can make informed decisions and the QSA can test them. The partner does not decide whether a requirement is met, does not sign the risk decision and does not issue any report or attestation. Where the partner also performs testing or configuration, confirm that its work is kept separate from the assessment itself.
- Targeted risk analysis support: The partner drafts the asset inventory, threat inputs and frequency calculations for owners to review and approve.
- Control design support: The partner builds or configures the technical controls, such as logging, file integrity monitoring or access reviews, that the customized approach relies on.
- Evidence preparation: The partner collects configuration exports, logs, review records and test results in a form the QSA can sample.
- ROC support: The partner maps evidence to the requirements and answers factual questions, but it does not write conclusions about whether a requirement is met.
- Handover: The partner documents the operating procedures so that your team can run the controls after the engagement ends.
Ask any partner to state in writing which tasks it will perform and which it will not, and confirm that its scope is fixed before work starts.
A Qualified Security Assessor is the only party that decides whether a requirement is met and documents that decision in the ROC. The QSA tests the customized approach against the stated objective, reviews the targeted risk analysis and samples evidence over the assessment period. The QSA is independent of the implementation work and cannot have designed the controls it tests.
- Targeted risk analysis review: The QSA examines whether the analysis covers the required elements and whether the frequency or method is justified.
- Control testing: The QSA tests whether the customized control meets the objective, using the same evidence standards as the defined approach.
- Evidence sampling: The QSA selects samples across the assessment period and may request additional evidence.
- ROC completion: The QSA writes the ROC, and the Date of Report is set when the QSA company and the assessed entity agree on the final version.
- Attestation of Compliance: The AOC is completed on the official template and signed according to that template, and it cannot precede the ROC.
Confirm the QSA company's independence policy and ask how it will handle any work the implementation partner has already done.
How the customized approach differs from a compensating control
A customized approach and a compensating control are both alternatives to meeting a requirement exactly as written, but they answer different situations. A customized approach is a designed way to meet the stated objective of a requirement, chosen by an entity that has a robust security and risk management program and wants to do the job differently from the defined method. A compensating control is a temporary alternative for a documented constraint, usually a legacy system, a technical limit or a business reason, that prevents the entity from meeting the requirement as written at all. The first is a design choice. The second is a workaround for a gap that the entity is working to close.
The PCI SSC does not approve specific configurations or controls in advance. QSAs, who are trained by the SSC on the intent of each requirement, judge during the assessment whether a compensating control meets that intent, and they make the same kind of judgment on whether a customized design achieves the objective. The two routes are documented differently. A customized approach needs its own targeted risk analysis for each requirement, and its objective and testing approach appear in the ROC, since SAQs cannot record it. A compensating control is recorded on the compensating control worksheet with the constraint, the risk it creates, the controls that offset it and how they were validated.
Before you invest in either route, ask your QSA in writing which one applies to each requirement that is not met as written. A customized design that the QSA would treat as a compensating control carries different documentation and different expectations, and the wrong label can send the assessment back for rework. Also confirm whether the QSA expects the targeted risk analysis to cover the customized requirement itself, and whether any compensating control you rely on has a review date tied to the system's replacement plan.
What usually causes customized approach projects to stall
Most customized approach delays trace back to a small set of planning gaps made early and discovered late. The cards below cover the decisions and documents that assessors look at most closely, so each one can be checked before the ROC work begins.
Design before the objective is written
Teams often build the replacement control first and then try to describe what it achieves. Under the customized approach the stated objective is the test, so a design without a written objective has nothing to measure against. Before any engineering starts, write the objective of the requirement in your own words, name the assets it protects, and confirm that the proposed control meets that objective. Check that the objective and the design can be reviewed side by side by someone who was not in the design meetings.
Risk analysis that lists controls only
A targeted risk analysis that names the controls in place but not the threats they address does not justify anything. Assessors expect the analysis to identify the assets, the threats against them, and the likelihood or impact factors that support the chosen design. Review your draft and ask whether each threat maps to a control and each control maps to a threat. If a control has no threat behind it, the analysis is incomplete and should be reworked before the QSA sees it.
No review every 12 months
A targeted risk analysis is a living record, not a one-time document. Where the analysis supports a frequency decision, it must be reviewed at least every 12 months, and the review must be dated and evidenced. Teams that complete the analysis for the first assessment and then forget it tend to discover the gap during the next assessment. Put the review on the same calendar as your other recurring security tasks, assign an owner, and keep the signed or approved version of each review.
Using an SAQ for a customized requirement
Self-Assessment Questionnaires do not provide a place to document customized approach objectives, so an entity that uses the customized approach cannot record it there. Teams that start with an SAQ often discover the mismatch only when they prepare the submission. Decide the validation route before design work begins. If the customized approach is in use, confirm with your acquirer or payment brand whether a ROC is required, and plan the QSA engagement accordingly.
Evidence that shows the tool, not the outcome
Screenshots of a product dashboard or a list of installed agents show that a tool exists, but they rarely show that the stated objective is being met. Assessors look for evidence that the result holds over time, such as logs, test results, exception records and reviews that demonstrate the objective in operation. For each customized requirement, define the outcome evidence before deployment, and confirm that the monitoring output can be exported and sampled. Ask the QSA early which records they expect to sample.
Late QSA briefing
Many customized approach designs reach the QSA only after the controls are live, and the assessor then finds gaps in the objective, the analysis or the evidence. Brief the QSA before implementation so they can comment on the proposed objective, the risk analysis and the test approach while changes are still cheap. The QSA remains the party who decides whether the design meets the requirement, and an early briefing does not change that independence. Ask for the briefing to be recorded in your project plan, along with any questions raised.
Questions buyers ask about customized and defined approaches
Is the customized approach cheaper than meeting requirements as written?
Not automatically. The customized approach does not remove work, it moves it: you must design the control, document the objective, run a targeted risk analysis for each customized requirement and give the QSA evidence that the alternative meets the objective. Cost depends on how many requirements you customize, how mature your risk management already is, and how much assessor time the validation takes. Ask any implementation partner or QSA to price the customized design work and the ROC validation as separate line items before deciding.
Can we document a customized approach in a self-assessment questionnaire?
No. SAQs cannot be used to document the customized approach, so customized approach objectives do not appear in them. Entities that want to validate with the customized approach may be able to use the ROC template instead, which a QSA completes. Confirm with your acquirer or the payment brand whether a ROC is required for your merchant or service provider level before you commit to this route.
How long does a targeted risk analysis take to write?
No researched duration is available, so treat any timeline as something to confirm with your own team and assessor. The effort depends on the number of customized requirements, the quality of your asset inventory and threat data, and how many reviewers must sign off. Each requirement needs its own targeted risk analysis that identifies assets, threats and the likelihood or impact factors behind the decision, and the analysis must be reviewed at least every 12 months. Plan for that recurring review in your calendar, not only the first write-up.
What must our team provide before a QSA can validate a customized control?
Your team owns the control design and the evidence that it works. Expect to provide the documented objective of the requirement, a description of the customized control, the targeted risk analysis for each customized requirement, and operating evidence such as logs, configurations, test results and records of review. The QSA then tests whether the control meets the stated objective in practice. Ask the QSA early which artifacts they will sample and in what period, so your team can produce them without rework.
Can a consultant design the customized control for us?
A consultant can help design and document a customized control, but the organization owns the control and its risk decision. The consultant prepares systems, controls and evidence; the QSA independently assesses the result. Keep the design work and the assessment with separate parties, because a firm that designed a control has a conflict if it also validates that control. Put the deliverables, the owner of each risk decision and the handover of evidence in writing before work starts.
How does the QSA decide whether our customized control is acceptable?
The QSA judges whether the control meets the stated objective of the requirement, using the targeted risk analysis and the operating evidence you provide. The PCI SSC does not pre-approve specific configurations, and QSAs decide during the assessment, using the intent of the requirement as their reference. Expect questions on how you identified risk, why the chosen frequency or method is adequate, and whether the control keeps working over time. Share draft analysis early so the QSA can flag gaps before the Date of Report.
Is the customized approach the same as a compensating control?
No. The customized approach is a route to meet a requirement's objective in a different way, and it requires a targeted risk analysis and ROC validation. A compensating control is used when a requirement cannot be met as written because of a legitimate technical or business constraint, and it is documented on a compensating control worksheet. Both can appear in a ROC, but they follow different rules, so confirm with your QSA which one fits each gap.
Do we need to confirm acquirer rules before choosing the customized approach?
Yes. The PCI SSC does not enforce compliance; the individual payment brands decide which entities must validate and how, and they run any enforcement programs. Ask your acquirer or payment brand whether they accept the customized approach for your merchant or service provider level, and whether they require a ROC rather than an SAQ. Get that answer in writing, because it determines the validation path and the evidence you must retain.
How DeployOpen works on this
DeployOpen plans, implements, documents and supports self-hosted open-source platforms inside your own infrastructure, so that systems and evidence for a customized requirement are ready for your QSA. DeployOpen prepares the controls and evidence; the organization owns its controls and the QSA issues the ROC and decides validation.
How we scope
- Engagements are fixed-scope, with the requirements, systems and deliverables agreed in writing before work starts.
- We list which requirements your team wants to meet through the customized approach and which stay on the defined approach.
- We confirm with your QSA and acquirer which validation template and evidence they expect before design begins.
How we build
- We help draft the targeted risk analysis for each customized requirement, covering assets, threats and likelihood or impact factors.
- We configure self-hosted open-source platforms in your cloud accounts or data centers to meet the stated objective of each requirement.
- We test each customized control in your environment and record the results in a form your assessor can reproduce.
How we hand over
- You receive documented designs, configuration baselines, targeted risk analyses and test results for each customized requirement.
- We deliver a handover that maps each customized objective to its system, owner, evidence source and review date.
- Your team owns the controls after handover, and the QSA decides whether the customized approach is validated in the ROC.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers for customized controls that need regular review.
- Targeted risk analyses must be reviewed at least every 12 months, and we can prepare updates alongside your review cycle.
- Ask your QSA which evidence they need for the next assessment, and we will confirm the work and fees in a written quote.
