Keep the evidence tied to the question

A configuration screenshot can establish a setting at a particular time. A log can show that an event was recorded. A technical test can demonstrate a behavior under stated conditions. Each has value, and each has limits. A useful validation cycle combines them to answer a specific control question.

Suppose a network change adds a new management path to a sensitive system. The earlier test still describes the earlier environment. The next decision is whether that change affects the assumptions behind the result, which checks need repeating, and who is responsible for them.

Define a cycle with an accountable owner

Use this operating pattern to connect the work across engineering, security, and assessment teams:

  • State the objective in observable terms. Identify the resource, the identities or networks involved, and the behavior that should be prevented or detected.
  • Establish coverage. Link the objective to current inventory, relevant configuration, exceptions, and telemetry. Record gaps in visibility.
  • Choose a test that answers the question. Agree authorization, safe boundaries, expected observations, and stop conditions.
  • Correct the cause. Assign an owner and capture what changed, including related systems that may share the weakness.
  • Retest and retain the result. Record the environment, date, coverage, remaining limitations, and the next trigger for review.

Reference: NIST SP 800-115 — assessment planning and post-testing activities

Apply it to a segmentation question

Consider an illustrative planning scenario: a business network should have no unauthorized path into the CDE. Start by identifying the source networks, destination systems, expected restrictions, and permitted management flows. A diagram provides context; configuration review and authorized technical checks provide different evidence about implementation.

If a check finds unexpected reachability, record the source and destination, the tested service, the observed result, and the intended policy. Determine whether the issue is a rule error, an overlooked route, or a misunderstanding of the boundary. After correction, repeat the relevant checks and consider whether other boundaries share the same cause.

This is a suggested workflow, not a description of a client incident. Its value is the traceable connection between an objective and the evidence supporting the outcome.

Use a cadence that matches the obligation and the change

Continuous monitoring does not mean continuously running intrusive tests. It can combine routine evidence review, automated observations, change triggers, and scheduled assessments. NIST SP 800-137 describes a monitoring strategy shaped by risk and information needs.

For PCI work, follow the applicable requirement’s actual interval and change trigger. Additional validation may be useful, but calling the program continuous does not replace required tests. Nor should a team describe every recommended practice as a new PCI DSS mandate.

Reference: NIST SP 800-137 — information security continuous monitoring

Write evidence that survives handoff

An engineer should be able to identify the affected system and understand the change. A reviewer should be able to follow the objective, test, finding, and retest without reconstructing the story from unrelated attachments. Retain supporting screenshots and outputs with enough context to make them meaningful.

The QSA evaluates whether evidence is appropriate for the assessment. Good organization helps that review, but it does not turn a limited test into complete assurance. State what the evidence supports and leave the remaining uncertainty visible.

Reference: PCI SSC FAQ 1566 — evaluating evidence