How should organisations evidence continuous testing for SOC 2 and PCI DSS?

What auditors actually expect when you say “continuous testing”

For SOC 2 and PCI DSS, continuous testing is not a promise that testing happened at some point in the quarter. Auditors want evidence that testing is recurring, that results are tracked over time, and that weaknesses are actually driven to closure. In practice, that means keeping artefacts that show the control operated consistently, not just a polished summary at the end of the period.

The strongest evidence set usually includes live scan outputs, dated findings history, ticketed remediation actions, retest results, and approval records for any accepted exceptions. Those artefacts let a reviewer see the full control loop, from discovery to remediation to validation, which is much harder to dispute than a static report exported once for audit.

A useful test is whether an independent reviewer could reconstruct the control’s operating history without asking your team to narrate it. If the answer is no, the evidence is probably too thin, too curated, or too detached from day-to-day operations to satisfy an audit that is looking for current control performance.

How to structure evidence so it shows the control kept working

Organisations should organise evidence around repeatability, timestamps, and traceability. The goal is to show that testing cadence is built into operations, not assembled later for the audit window. That usually means preserving each run’s output, the scope tested, the date of execution, the issues opened, and the follow-up proof that those issues were remediated or formally accepted.

For SOC 2, this aligns well with SOC 2 Trust Services Criteria (AICPA), because the evidence must support ongoing monitoring, logical control operation, and a defensible audit trail. For PCI DSS, it is equally important that the evidence shows testing is part of a sustained security process rather than a one-time compliance exercise, especially where vulnerability management and review cycles are in scope.

That means the record set should be consistent enough to answer three basic questions: what was tested, what failed, and what changed afterward. If those three items are missing, the evidence may prove activity, but not effective continuous control.

When the control involves repeated scanning or validation, the history matters as much as the latest result. A clean current run is useful, but a pattern of repeated findings with no durable closure is usually a stronger signal for auditors than the absence of findings in a single screenshot.

What makes the evidence credible instead of cosmetic

The evidence becomes credible when it is generated as part of normal operations and can be cross-checked across systems. Ticket IDs should map to findings, findings should map to remediation work, and remediation should map to retest or verification evidence. That chain is what turns “we test continuously” into a claim that can actually be substantiated.

For PCI DSS, the control story is strengthened when the evidence shows access restriction, vulnerability tracking, and remediation discipline rather than only periodic attestation. The current PCI DSS v4.0 guidance published by the PCI DSS v4.0 document library reinforces least privilege and account governance expectations, which makes weak, one-off evidence harder to defend if it does not reflect actual operating practice.

In audit terms, a continuous-testing programme is most convincing when it produces a stable paper trail and a stable operational trail. If the two diverge, for example if the dashboard says “green” but the remediation queue is stale, the evidence set is not really continuous, it is selective.

Practitioner Guidance

What to verify: Confirm that every material test run has a timestamp, a defined scope, a finding history, and a retest or closure record. If any of those elements is missing, treat the evidence as incomplete even if the summary looks strong.

Common mistake: Teams often keep the latest scan result and discard the history that proves control continuity. That is usually enough to show a point-in-time check, but not enough to show an operating process.

Decision rule: If a finding affected a system that is still in production, prioritise the remediation record and retest evidence over a narrative explanation of why the issue was low severity. Auditors generally care more about whether the control loop closed than whether the initial defect sounded minor.

Practitioner takeaway: The best evidence for continuous testing is a complete chain of execution, finding, remediation, and revalidation. If you cannot show that chain repeatedly, you do not yet have continuous testing evidence, only periodic testing output.

Related resources from NHI Mgmt Group

• How should organisations prepare IAM evidence for a PCI DSS assessment?
• Why do scanners not count as PCI DSS 4.0 penetration testing evidence?
• Why do organisations need different controls for HIPAA, PCI-DSS, GDPR, and SOC 2 instead of treating compliance as one checklist?
• How should organisations use PCI DSS penetration testing to validate cardholder data controls before a breach occurs?