TL;DR
Requirement 12.3.1 is not a company risk assessment. In PCI DSS v4.0.1 it is one documented analysis for each requirement that tells you to complete one: assets, threats, what changes the likelihood or impact, and why the frequency you picked is enough. Review each one at least once every 12 months. A row in an SAQ applies only where it applies to your environment. PCI DSS Dashboard can hold the analysis. It does not pick the frequency, and it does not decide whether an acquirer accepts the package. What you still send is a signed, dated SAQ + AOC PDF.
The cell says "periodically." Someone typed "annually," attached last year's enterprise risk register, and moved on. The register is twenty pages of business risk. It never names the application account, the threat that account is there to stop, or why twelve months is the right gap before that password changes.
That is the dull failure on Requirement 12.3.1. Not a missing signature. A frequency with no analysis behind it.
Renewal is last year's PDF versus this year's cycle. Scans are a fresh SAQ with no passing ASV report. This is the other file. Where a requirement tells you to set the pace, the pace has to be written in the shape 12.3.1 asks for.
What 12.3.1 actually asks for
In PCI DSS v4.0.1 (June 2024), Requirement 12.3.1 applies to each requirement that specifies completion of a targeted risk analysis. The analysis is documented. It names the assets, the threats, and the factors that change likelihood or impact. It justifies how the frequency or process you defined minimizes that likelihood or impact. You review each analysis at least once every 12 months, and you update it when that review says the result no longer holds.
v4.0.1 clarified where the sentence applies. The Summary of Changes from v4.0 to v4.0.1 (August 2024) says the requirement applies only where a requirement specifies that analysis, and the result has to justify your frequency or process. One company risk assessment stapled to every "periodically" is the older reading.
The guidance column is blunt about the other document people attach. An enterprise-wide risk assessment is recommended and is not required. ISO 27005 and NIST SP 800-30 are examples it gives for that broader assessment. They are not a substitute.
The Council's TRA note (Lauren Holloway, 28 November 2023) separates that frequency analysis from a customized-approach TRA. On v4.0.1 SAQ D for Merchants (October 2024), Requirement 12.3.2 says it is specific to the customized approach and does not apply to entities completing a self-assessment questionnaire. If you are filling an SAQ, 12.3.2 is not the worksheet.
You do not get to retune a clock the standard already set
In the v4.0.1 timeframes section, "periodically" means you set the frequency, you document it, you support it with the 12.3.1 analysis, and you still show that it meets the intent of the requirement. A named timeframe is not yours to loosen.
A common failure pattern: every "periodically" gets treated as a free choice, with the company risk register stapled on the back. User-account reviews in Requirement 7.2.4 are at least once every six months. That is a defined timeframe, not a TRA. External scans under Requirement 11.3.2 are the same kind of fixed cadence. A new SAQ does not replace them.
Requirement 11.3.1.1 is the line people blur into the scan calendar. It is not the quarterly internal scan. It is how you address vulnerabilities that are not ranked high-risk or critical, based on the targeted analysis, with rescans as needed.
Where the standard actually points at 12.3.1
These requirements in v4.0.1 tell you to do the analysis according to 12.3.1. A printed SAQ row still applies only where it applies to your environment.
- 5.2.3.1. How often you re-check systems you called not at risk for malware.
- 5.3.2.1. How often periodic malware scans run, only if that is how you meet 5.3.2. The note limits 5.3.2.1 to entities that run those periodic scans.
- 7.2.5.1. How often you review access on application and system accounts.
- 8.6.3. How often those accounts' passwords change, with complexity that fits the frequency. Compromise is a separate trigger. The TRA does not replace it.
- 9.5.1.2.1. How often, and how, you inspect POI devices.
- 10.4.2.1. How often you review logs for systems not already named in 10.4.1.
- 11.3.1.1. How you address vulnerabilities that are not high-risk or critical. Not the scan interval.
- 11.6.1. Only if you skip "at least weekly." Weekly means you are not using 12.3.1 to set that cadence.
- 12.10.4.1. How often incident-response personnel are trained.
Requirement 6.3.3's guidance recommends a TRA for non-critical patch timing. The requirement line does not point at 12.3.1 the way 8.6.3 does. Recommended is not the same as specified. I am not adding it.
The applicability notes still say best practice until 31 March 2025. That date has passed. Where the requirement applies, the deferral is over.
Your SAQ is a shorter list
SAQ A r1 (January 2025) removed 6.4.3, 11.6.1, and 12.3.1. The change log says 12.3.1 had been added because 11.6.1 specified it. The Council's 30 January 2025 note says the same removal, and that PCI DSS itself still contains the requirements. SAQ A no longer asks you to report 12.3.1. Scripts on that questionnaire are a different post: hosted checkout pages.
SAQ A-EP (October 2024) prints 12.3.1, plus 5.2.3.1, 5.3.2.1, 8.6.3, 10.4.2.1, and 11.6.1. It does not print 7.2.5.1, 9.5.1.2.1, 11.3.1.1, or 12.10.4.1. On 11.6.1, the SAQ limits the row to merchant web servers that host the payment page sent to the customer's browser. A URL redirect is Not Applicable. Not every hostname you publish.
SAQ D for Merchants (October 2024) prints the longer set, including those four and 12.3.1. No POI devices means 9.5.1.2.1 is not your homework.
If your acquirer specifies the validation documentation it requires, follow its instructions. The SAQ still has to fit the payment environment and the eligibility criteria. An acquirer cannot make an entity eligible for an SAQ it does not qualify for. Which SAQ Am I? is the pre-flight. What you still send is the signed, dated SAQ and AOC.
What "done" looks like on one line
One analysis per requirement that specifies one. Not one paragraph with the number swapped.
For 8.6.3, name the account and the secret, the misuse you are worried about, and the factors that make that misuse more likely: where the secret sits, who can read it, whether the account can log in, staff turnover. Then the frequency, why it is enough, and the complexity you paired with it. Date the next look. At least every 12 months.
"Annually, because that is what we do" is not that sentence.
The guidance column also says to look again when something could change the risk, not only on the anniversary. The defined bullets are still the 12-month review and an update when that review says you need one. If the secret moved, last year's justification is about a system you no longer run.
What the platform holds, and what it will not invent
PCI DSS Dashboard includes a pre-populated targeted risk analysis for Requirement 12.3.1. The structure is there. You still name the assets, the threats, and why the frequency is one you can defend. The tool will not invent that decision.
Wizards are live for SAQ A, A-EP, B-IP, and D. Save as you go, sign, download a signed, dated SAQ + AOC PDF. SAQ A and B-IP are €99. SAQ A-EP is €699. Payment gates the download. The analysis is evidence beside that PDF. It does not replace it, and the wizard does not decide whether the acquirer accepts the package.
The frequency still has to be performed. The platform can track scheduled tasks and the evidence for each completion. The task record is not the TRA.
Empty analysis, start there, not with another PDF export. Unsure the row applies, use the contact page.
A portfolio, not one merchant
A book of merchants where every "periodically" is the same word, and no file names an asset, eats a quarter. The signed PDF can go up the parent chain when a merchant finishes. The analysis stays that merchant's. We do not write the justification on the way up.
