Clone and retest

Cloning a finding

The same weakness often appears on more than one asset, or a similar finding recurs across engagements. Cloning a finding copies its content so you can adjust it for the new context rather than retyping it. What is copied is the finding's own content; state that belongs to the original (its published revision, its pending-changes flag, its retest history) stays with the original, because a clone is a new finding, not a second pointer to the old one.

Recording a retest

A retest is how you record that you went back and checked whether a finding was fixed. You add a retest to the finding with its outcome and its own evidence. You do not set the finding's verification status by hand: it is derived from the retests, in date order. An effective retest moves an open finding to fixed, a partial one to partially fixed, and an ineffective retest on a fixed or partial finding reopens it (see Findings).

Why retest state is derived, not typed

Deriving the verification status from the retests, rather than letting someone set it, means the status can never contradict the record. If the finding says fixed, there is an effective retest behind it, with its date and its evidence. This is what lets a retest report and a final report state the verification state truthfully, and what feeds the "overdue retest" attention items on the Panel: a released finding still open past its remediation due date is something that needs you.