With PCI DSS 4.0, nine of the requirements were rewritten to allow the assessed entity to define how frequently the control should be completed. While that flexibility sounded great to some folks, others weren’t exactly thrilled—because guess what? It means more paperwork. Every. Single. Year. These nine requirements now require a Targeted Risk Analysis (TRA) to justify the timing you choose. Let’s walk through each one and decide what might be best for your company.
Requirement 5.2.3.1 – addresses systems that do not have anti-malware installed because they are supposedly not at risk. But let’s be honest here… when is the last time you saw a system that was not susceptible to malware? If they have a CVE (Common Vulnerability and Exposures entry) on cve.org, its susceptible. I haven’t met an operating system yet that doesn’t have one. Still, if you truly do you have a system that is not at risk, the Council recommends a manual inspection at least every 6 months.
Requirement 5.3.2.1 – covers how often you scan for malware IF you’re not scanning in real time. Again, I haven’t seen anyone not scanning in real-time in a very long time. However, if you do not scan in real-time, your TRA needs to spell out how often you scan and how you came to that determination. Just a heads-up: scanning less than daily is likely to raise some eyebrows with your QSA.
Requirement 6.3.3 – defines how quickly to apply patches that are not ranked as critical. Side note: this isn’t listed in the TRA Guidance, but your QSA will be expecting to see it. Requirement 6.3.1 already says you need to rank patches according to risk. The TRA will address how quickly those various risk rankings must be applied. This varies greatly from organization to organization, but the ultimate goal is to have all patches applied within 90 days regardless of their ranking.
Requirement 7.2.5.1 – deals with user access reviews for all application and system accounts. These accounts are notorious for having a generic password that is known by everyone, never changed, and having excessive privileges. The Council suggests these accounts be reviewed at least once every six months.
Requirement 8.6.3 – addresses the password changes for application and system accounts. These accounts are typically only used by systems (scripts, services, etc.) to login. Personally, I’d rather use a long, complex password and only change it once a year – or when someone with access leaves. The Council says every 3 months, but if you can justify your approach in the TRA, that’s your call. Just be careful saying things like, “We can’t change it – stuff breaks.” That’s a red flag for your QSA.
Finding this helpful? Join our newsletter.
Requirement 9.5.1.2.1 – addresses how often you should inspect card readers (POI point of interaction devices). With chip cards, the risk of skimming is much lower – but in the US, we’re still dipping a lot, and that’s where attackers strike. Monthly checks are the baseline, but I prefer doing this as part of the open/close checklist. The TRA lets you set the schedule – just be smart about it.
Requirement 10.4.2.1 – addresses the frequency of log reviews of systems that are not monitored in real time according to requirement 10.4.1. Again, I’ve never seen this one come up – most systems today are being monitored in real-time. But if not, the Council recommends viewing logs at least once every seven days. Your TRA should say how and why you do it differently, if you do.
Requirement 11.3.1.1 – How fast do you fix vulnerabilities that aren’t critical or high? My take? Mediums should be fixed in 2 months, lows in 3. The Council says 3 months for mediums, 6 months for lows. Informational findings should just be monitored. Your TRA is your chance to explain your logic and make sure it holds up during your assessment.
Requirement 11.6.1 – addresses how often payment pages are checked for changes. The DSS says weekly or as defined by the targeted risk analysis. Personally, I’d hope you’re not going longer than a week. The faster you find an issue, the faster you fix it. Simple as that.
Requirement 12.10.4.1 – addresses the training of incident response personnel. The incident response team should have training at least once a year. Hopefully they haven’t had to deal with a real incident—but training keeps them sharp. Also don’t forget to train new members right away—incidents don’t wait until everyone’s up to speed.
Targeted Risk Analysis Guidance
This short article attempts to outline targeted risk analyses. Luckily, the PCI Council has your back with detailed guidance.
Each TRA should include:
- a description of the assets you’re protecting
- what threats the requirement helps to prevent
- why the threat matters to you (likelihood, impact)
- the logic behind your chosen frequency – plus any research or justification
- date of last review (yup, you’ve got to review/update it annually)
- Policies and procedures to make sure you are doing this consistently.
Remember, PCI no longer requires a company-wide risk assessment – but these individual TRAs are mandatory for the nine requirements listed above. That said, a company-wide risk assessment is still a smart move. It’s just not officially required for PCI compliance anymore.
Until next time – keep calm and risk responsibly.
