A PCI DSS assessment covers a period, usually the twelve months before the report. It does not ask whether a control is in place today. It asks whether it operated throughout. That is why the organisations that find assessments calm are not the ones with the best technology. They are the ones with a calendar.
The calendar, by frequency
These are the periodic activities PCI DSS version 4 asks for, grouped by how often. Frequencies marked “service providers” apply to them in addition to the general rule. Where the standard says “at the frequency defined in your targeted risk analysis”, you set the frequency, and the risk analysis is itself an annual record.
Daily. Review security logs and alerts for the systems that matter most, and keep a record that the review happened and what came out of it.
Weekly or per risk analysis. Review the remaining logs at the frequency your risk analysis defines. Inspect payment terminals at the frequency your risk analysis defines, against an inventory.
Monthly. Install critical security patches within a month of release; the record is the patch report with dates.
Quarterly. Internal vulnerability scans, with rescans until the high-risk items are resolved. External scans by an approved scanning vendor, with a passing report. For service providers: a documented review that personnel are following the security policies and procedures.
Every six months. Review the firewall and router rules, and record what was removed. Review all user accounts and access, including third parties, and record what changed. For service providers: test segmentation controls, and confirm the scope.
Every twelve months. Confirm and document the scope. Penetration testing, external and internal, plus a re-test of what was found. Targeted risk analyses for each requirement that depends on one. Security awareness training for everyone, with records. Test the incident response plan. Review the hardware and software in use for continued support. Monitor each third-party service provider’s compliance and keep the evidence. Review the information security policy. Review and update the inventory of system components, the data-flow diagrams and the network diagrams.
After significant change. Penetration tests and segmentation tests, and a rescan. “Significant” is defined by you, in writing, in advance, so that nobody argues about it afterwards.
Turning the list into a state
Each line gets an owner by name, a due date, and a description of the record it produces. Not “quarterly scan: IT” but “internal scan, first week of each quarter, Marie, output: the scan report with the rescan attached, filed here”. When the assessment comes, the assessor asks for four of something, and four are there, each with a date and a name.
The first year is the hard one, because the records do not yet exist. The organisations that start the calendar six months before their first assessment arrive with six months of records and a clear explanation for the rest. The ones that start six weeks before arrive with six weeks and a problem.
What people get wrong
They treat readiness as a project with an end. The assessment ends. The calendar does not.
They set frequencies by habit rather than by the risk analysis the standard asks for, and then cannot explain the frequency when asked.
They do the activity and skip the record. A review that leaves no trace did not happen, for assessment purposes, and often for real purposes either.
They forget “after significant change”. A platform rebuilt in March on a test from last September has an untested network.
A review that leaves no trace did not happen, for assessment purposes, and often for real purposes either.