PCI DSS Targeted Risk Analysis: A Template an SMB Can Actually Fill
PCI DSS Targeted Risk Analysis: A Template an SMB Can Actually Fill
PCI DSS v4.0.1 lets an entity choose the frequency for certain activities — but only if a targeted risk analysis justifies the choice. The TRA is not optional paperwork; it is the document the assessor checks to confirm your cadence matches your risk. Skip it and the frequency is non-compliant, whatever you actually do.
PCI DSS v4.0 introduced the targeted risk analysis (TRA), defined in requirement 12.3.1. Wherever a requirement says an activity is performed “at the frequency defined in the entity’s targeted risk analysis,” the entity must produce a TRA that documents the analysis behind the chosen frequency. The PCI SSC Information Supplement (Targeted Risk Analysis Guidance, November 2023) is explicit on what the TRA must contain and how the assessor reviews it.
This article gives the elements the standard requires, a fill-in template an SMB can use, and a worked example for requirement 11.6.1 (payment-page tamper-detection frequency, referenced in the 6.4.3 / 11.6.1 explainer).
When a TRA is required
A TRA for activity frequency is required only where a PCI DSS requirement explicitly says so — “performed in accordance with all elements specified in Requirement 12.3.1.” The PCI SSC guidance lists the requirements that trigger one, with suggested frequencies:
| Requirement | Activity | Suggested frequency |
|---|---|---|
| 5.2.3.1 | Periodic evaluation of system components identified as not at risk for malware | At least every 6 months |
| 5.3.2.1 | Periodic malware scans (if used to meet 5.3.2) | At least daily |
| 7.2.5.1 | Review of application & system account access | At least every 6 months |
| 8.6.3 | Periodic change of application/system account passwords | At least every 3 months |
| 9.5.1.2.1 | Periodic POI device inspections | At least monthly |
| 10.4.2.1 | Periodic log reviews for all other system components | At least weekly |
| 11.3.1.1 | Addressing other (non-high/critical) vulnerabilities | Medium ≤3 months, Low ≤6 months |
| 11.6.1 | Payment-page change/tamper-detection mechanism | At least weekly |
| 12.10.4.1 | Periodic training for incident response personnel | At least annually + at start of employment |
Even if you follow the suggested frequency, a TRA is still required to document and support the choice.
Two rules that catch SMBs
*A TRA cannot be used to perform an activity less frequently than the requirement states.* If a requirement says “at least weekly,” your TRA cannot justify monthly. To go below a stated minimum, you must use the customized approach (requirement 12.3.2, a different TRA) or a documented compensating control.
*A TRA is not needed to perform an activity more frequently.* If the requirement says weekly and you run the check daily, no TRA is required — just do it.
The TRA sits between these: it justifies a frequency at or above the requirement’s floor, calibrated to your risk.
The elements a TRA must contain (requirement 12.3.1)
Per the PCI SSC guidance, a frequency TRA identifies, for each applicable requirement:
1. The specific assets the requirement protects (e.g. log files, credentials, a payment page). 2. The threat(s) or outcomes the requirement protects against (e.g. malware, an undetected intruder, credential misuse, a skimmer). 3. The factors that contribute to likelihood and/or impact — anything that increases an asset’s vulnerability to the threat (exposure to untrusted networks, environment complexity, high staff turnover) and the criticality of the components or the volume/sensitivity of the data. 4. The chosen frequency, with justification for how it addresses the identified risk. 5. The review cadence — the TRA is reviewed at least every 12 months and on changes that could impact risk, and updated as needed.
The assessor’s role is to confirm all elements are documented and that the entity justified how the frequency addresses its risk. A frequency with no documented reasoning fails.
The template
Use one row per applicable requirement. PCI SSC provides a sample template (PCI DSS v4.x Sample Template: Targeted Risk Analysis for Activity Frequency); using it is not required, but all its elements must be present.
| Field | What goes in it |
|---|---|
| Requirement | The PCI DSS requirement number (e.g. 11.6.1) |
| Activity | The activity whose frequency is being set |
| Asset(s) protected | The specific asset(s) |
| Threat(s) / outcome(s) | What the activity detects or prevents |
| Likelihood factors | Exposure, complexity, turnover, etc. |
| Impact factors | Criticality of components, data sensitivity/volume |
| Chosen frequency | The cadence, at or above the requirement’s floor |
| Justification | One paragraph tying the frequency to the factors above |
| Review date | At least annually; trigger on significant change |
| Owner | Who maintains this TRA entry |
A worked example: 11.6.1 payment-page tamper detection
An SMB runs its own e-commerce payment page (SAQ A-EP) and uses synthetic monitoring plus CSP violation reporting for 11.6.1. The TRA entry:
| Field | Entry |
|---|---|
| Requirement | 11.6.1 |
| Activity | Change- and tamper-detection on payment-page HTTP headers and script contents as received by the consumer browser |
| Asset(s) protected | The payment page as rendered in the customer’s browser; the cardholder data the form collects |
| Threat(s) / outcome(s) | Magecart-style skimming; unauthorized script injection or alteration; CSP weakening |
| Likelihood factors | Payment page loads third-party scripts (tag manager, analytics) — multiple injection vectors; e-commerce site is internet-facing 24/7; one developer commits to the page |
| Impact factors | A successful skimmer exfiltrates PANs for the duration it runs; direct PCI DSS violation and card-brand consequences if undetected |
| Chosen frequency | Daily (synthetic monitoring runs once per day; CSP violations reported in near-real time and reviewed daily) |
| Justification | The page is internet-facing with multiple third-party script vectors, so detection lag directly scales exposure. Daily synthetic monitoring catches a tampered script within ~24 hours, limiting the breach window; CSP violation reporting provides near-real-time alerting for the most common injection pattern. Daily is above the weekly floor and matches the 24/7 exposure. |
| Review date | Annually, and on any change to the payment-page script inventory or a new third-party script |
| Owner | IT Lead |
This entry is a few paragraphs. It names the assets, the threats, the factors that drive the frequency up, and ties the chosen cadence to the risk. An assessor reading it can see why daily and not weekly — which is the entire point.
Three mistakes to avoid
- **Copy-paste TRAs.** Identical entries across unrelated requirements signal the analysis was not done. Each requirement has different assets and threats; the factors must reflect that.
- **Frequency below the floor.** A TRA cannot lower a stated minimum. If you need a lower cadence, that is the customized approach or a compensating control, not this TRA.
- **One-and-done.** The guidance requires annual review and update on significant change. A TRA dated three years ago is non-compliant regardless of its content.
How this fits the series
The TRA is the document behind every “at the frequency defined in the entity’s targeted risk analysis” line in PCI DSS — including the 11.6.1 frequency referenced in the 6.4.3 / 11.6.1 explainer and the log-review cadence implied by your scope reduction decisions. It is one of the artifacts your SAQ filing depends on. If you also run ISO 27001, the TRA is narrower than your ISO 27001 risk assessment — it is a payment-specific, frequency-focused slice.
What to do next
List which TRA-triggering requirements apply to you from the table above (most SMBs have 3–5). Fill one row per requirement using the template, starting with the one whose frequency you are least sure about. Tie each frequency to the factors, set a review date, and sign it. That is a compliant 12.3.1 TRA — a few hours, not a consulting engagement.
Want a review of your TRAs before your assessment? Book a 30-min **PCI scope reduction + readiness review** — we check each TRA entry against the 12.3.1 elements, flag the frequencies that will not survive assessor scrutiny, and hand you the corrections. Bilingual EN/FR, no obligation.
Get Your Free Security Readiness Assessment
Map your controls, identify compliance gaps, and secure your systems before the audit.