Logging, Monitoring, and Incident Response
Logging, Monitoring and Incident Response
This domain tests whether detection evidence would survive scrutiny, and whether your incident plan accounts for a provider-side event.
Requirement 10 requires logging of individual access to CHD, administrative actions, access to logs, invalid attempts and authentication or audit-log changes (10.2), with sufficient record content (10.3) and synchronised time (10.3.3). Logs must be retained at least 12 months with the most recent three months immediately available (10.5.1), protected from modification and backed up promptly to a central location (10.5.2, 10.5.3), with file integrity monitoring on logs (10.5.4) and at least daily review (10.4.1). Requirement 12.10 requires an incident response plan, tested at least annually (12.10.5), with defined roles and escalation.
Cloud design: a dedicated log-archive account with write-once storage and restricted roles, an organisation-wide audit trail, flow and threat-detection logs feeding a SIEM, alerting on key policy and trail changes, and detection rules tuned to the actual PAN access paths.
Worked example. An application tier logs locally to disk with 30-day rotation and then deletes them. It fails 10.5.1 (12 months total, three months available), 10.5.3 (prompt central backup) and likely 10.2 if PAN access lines are missing. Any engineer with instance access can also edit the files, which fails 10.5.2. Fix: ship to the log-archive account, apply object lock, restrict deletion to a break-glass role, retain 12 months with three months queryable, and enable integrity monitoring. Reasoning: logs are defensive evidence and are themselves a security-impacting system in scope.
Traps. Confusing total retention with the three-month readily available window; logs stored where the workload's own role can delete them; no logging of access to logs or of key usage; an incident plan silent on provider notification, forensic acquisition and acquirer or card brand timelines.