PCI CFA common mistakes
PCI CFA · Understand the traps and how to avoid them.
Treating the cardholder data environment as only the systems that physically store card numbers, and excluding connected systems that can reach them, such as the jump host, the backup server, the SIEM collector, or the virtualization management plane, from the documented CDE boundary.
Candidates memorize the definition of the CDE as 'systems that store, process, or transmit cardholder data' and stop there, forgetting that PCI DSS scoping also pulls in systems that can impact the security of the CDE. They also tend to trust the client's own network diagram instead of testing reachability, so the diagram becomes the scope rather than the evidence.
What to do instead
Before drawing the boundary, build a reachability map from actual configuration and traffic data: firewall and router rules, routing tables, VLAN assignments, hypervisor management networks, and authentication logs showing which hosts log in to which. Classify every host as CDE, connected-to, or out of scope with a written justification, then test the boundary by confirming that no path exists from out-of-scope systems into the CDE except through documented, segmented controls. Where segmentation is claimed, verify it with configuration review and, where possible, traffic evidence rather than accepting the assertion.
Citing PCI DSS requirements by memory with the wrong version or wrong requirement number, or stating a control is required when it was retired or renumbered in the current version, and building the finding around that incorrect citation.
The standard has been restructured across versions, requirements have been merged and split, and several controls moved between requirements or became future-dated. Candidates study from summaries and older material, and under time pressure they write the first requirement number that comes to mind instead of verifying it.
What to do instead
Anchor every finding to a requirement number and sub-requirement from the exact version of the standard in force at the time of the assessment, and state the version in the report. Keep the current requirement text open while writing. If you cannot confirm the exact citation, describe the control failure precisely and mark the citation for verification rather than guessing a number. In the report, separate the observed condition from the requirement it violates so a citation error does not invalidate the finding.
Starting the forensic investigation by imaging or rebooting systems before capturing volatile evidence, or allowing the client to 'clean up' the environment before evidence is preserved, so memory-resident malware, active sessions, and running processes are lost.
Candidates focus on disk images because they are familiar and easy to hand off, and they want to stop the breach quickly. Volatile data feels transient and less concrete, so it gets deferred until after containment, by which time it is gone. Clients also pressure investigators to let operations resume.
What to do instead
Apply a fixed order of volatility: capture memory, running processes, network connections, logged-in sessions, routing and ARP tables, and volatile logs before touching disks, and document each acquisition with tool, version, hash, and time. Establish a written preservation request to the client before any remediation begins, and record any unavoidable loss of evidence with the reason. If the client has already rebooted or wiped systems, document that as a finding that limits conclusions rather than silently working around it.
Relying on file timestamps and file system metadata as the timeline of attacker activity without accounting for time zone, clock skew, or timestamp manipulation, and presenting a single clean timeline as fact.
Timestamps look objective and are easy to sort, so candidates build the narrative directly from directory listings. They forget that MAC times can be altered by the attacker, that different sources log in different time zones, and that system clocks drift or are deliberately changed.
What to do instead
Normalize every source to a single documented time standard, record the offset applied to each source, and cross-check file timestamps against independent sources such as authentication logs, network flow records, and application logs. Treat file system timestamps as one data source among several and flag where they conflict with other evidence. Where timestomping is suspected, look for anomalies such as timestamps predating the operating system install or inconsistent precision, and state the uncertainty explicitly in the report.
Concluding that no compromise occurred because the available logs show nothing, without first establishing whether the relevant logging was enabled, retained, and complete for the period in question.
Absence of evidence in a log is treated as evidence of absence. Candidates check whether logs exist rather than whether the logging configuration could have captured the activity at all, so a disabled audit policy, a short retention window, or a gap in forwarding is read as a clean bill of health.
What to do instead
Before drawing any negative conclusion, document the logging architecture: which sources were enabled, what audit policy was in force, retention periods, forwarding paths, and known gaps. State the visibility window explicitly and phrase conclusions as 'no evidence of compromise was identified within the period for which adequate logs were available.' Where logging was insufficient, report that as a finding in its own right rather than as an absence of compromise.
Attributing an intrusion to a named threat actor or a specific malware family based on a shared tool, a common web shell, or a single indicator, without corroborating infrastructure, code, or tradecraft links.
Candidates want a satisfying narrative and know the well-known families, so a familiar file name or a public indicator match becomes an attribution. Shared use of commodity tools like credential dumpers or common web shells is extremely weak evidence because many unrelated actors use them.
What to do instead
Separate what the evidence supports from what it suggests. Report observed facts, then assessed conclusions with an explicit confidence level, and list the specific evidence supporting each. Only attribute to a named actor when multiple independent links align, such as infrastructure overlap, code reuse, distinctive tooling configuration, and consistent targeting, and say plainly when attribution is not possible from the available evidence.
Reading individual log lines and reporting them one by one, instead of correlating across sources to reconstruct the sequence of activity from initial access through to data exfiltration.
Log analysis is often taught tool by tool, so candidates review the web server log, then the authentication log, then the endpoint log in isolation. Correlation requires holding several sources in mind at once and is the step most often skipped under time pressure.
What to do instead
Build a timeline keyed on a normalized timestamp and a small set of pivot values such as source IP, account name, hostname, and file hash, then walk the timeline forward and backward from each suspicious event. For every candidate event, ask what should appear in other sources if this is real, and check whether it does. Present the result as a sequenced narrative with source citations for each step, not as a list of anomalies.
Writing findings that describe a control as 'weak' or 'not in accordance with best practice' without stating the observed condition, the evidence, the affected systems, and the specific requirement or standard breached.
Candidates confuse an assessment report with a security opinion. Vague language feels safer because it cannot be proven wrong, and it is faster to write than a precise finding with evidence attached.
What to do instead
Use a fixed finding structure: condition observed, evidence and source, systems and data affected, requirement or standard reference, risk and business impact, and recommended remediation. Write each condition so a reader who was not present can verify it. Replace qualitative adjectives with measurable statements, such as the number of systems affected, the date range of the exposure, and the specific configuration value observed.
Containing an incident by deleting malware, rebuilding systems, or resetting credentials before the scope of compromise has been established, then reporting conclusions that cannot be supported because the evidence was destroyed.
Containment feels urgent and rebuilding is the fastest way to stop the bleeding. Candidates treat eradication as containment and act before they know which accounts, systems, and data were touched, so the rebuild removes exactly the evidence needed to determine scope.
What to do instead
Separate containment from eradication in the plan and sequence them deliberately: preserve evidence, contain the spread, establish scope, then eradicate and recover. Where the client insists on immediate rebuilds, capture the required evidence first and record what was lost and when. Track every containment action with a timestamp and the person who authorized it, and reflect those actions in the final report so the reader understands what evidence no longer exists.
Assuming the merchant's or service provider's self-reported scope and breach description are accurate, and building the investigation around the stated number of affected systems and the stated entry point without independently validating them.
The client is the source of the engagement and often has a strong interest in a narrow scope. Candidates accept the brief because challenging it feels confrontational and because validating scope takes time that feels better spent on analysis.
What to do instead
Treat the client's account as a hypothesis to be tested. Independently enumerate internet-facing systems, payment applications, and data flows, and compare the result with the stated scope, documenting every discrepancy. Report scope discrepancies as findings even when they do not change the conclusion, and state clearly in the report which facts were independently verified and which rest on client representation.