An auditor wants proof that last quarter's policy finding is closed — why isn't the closed ticket enough?
answer
- the claim is about the world, not the workflow
- a ticket records an assertion by a human
- show two runs, not one
- an empty result has several causes
- pin the rule version and the scan scope
basics
~10 sA ticket records that someone said they fixed it. Proof is the same rule, re-run over current state, no longer returning that resource — shown alongside the earlier run that did return it.
solid answer
~50 sThe claim under audit is about the world, not about your workflow. A ticket marked done is a record of an assertion by a human; it can be closed by mistake, closed optimistically, or closed because the work was descoped. The evidence that matches the claim is a pair of runs: the earlier run of the rule that raised the finding, and a later run of **the same rule** over current recorded state where the resource is in scope and no longer matches. Then defend the negative, because an empty result is ambiguous. No finding can mean fixed, or that the resource left the scan's scope — deleted, moved to another account, dropped from the inventory export — or that the rule itself was narrowed. So the evidence has to carry the rule version and the scan scope next to the result, otherwise `no findings` is indistinguishable from `not looked at`.
go deeper
Understand that closing a ticket and fixing a resource are different events, and that re-running the rule that raised a finding is how you check the resource rather than the paperwork.
Be ready to describe the evidence concretely: the run that raised the finding, a later run of the same rule over current state, the resource in scope, and no result. Explain why one clean run on its own proves less.
Show that you volunteer the ambiguity of an empty result — fixed, deleted, out of scope, or rule narrowed — and that you remove it by pinning the rule version, stating the scan scope and confirming the resource was in the scanned set.
Own the standard for what your organisation will accept as remediation evidence, so closure claims are reproducible on demand rather than assembled by hand each time somebody asks.
## The mismatch between the claim and the artefact When you report a finding closed you are making a claim about a resource: the condition the rule tests no longer holds. A ticket is a claim about a **process**: a person moved a card. The two are related only by trust. Tickets get closed because the work shipped, but also because a sprint ended, because the reporter left, because someone believed a colleague, or because the scope changed and nobody updated the description. An auditor asking for proof of remediation is asking you to close that gap with an observation rather than an assertion. ## The artefact that matches the claim The rule that found it is the natural instrument for showing it is gone, because it is the same test applied to the same kind of input. What you show is a **pair**: 1. The run that raised the finding — rule, resource address, timestamp, result. 2. A later run of the same rule over current recorded state or inventory, where the same resource appears in the scanned set and produces no result. The pair matters. A single clean run only shows the present; it says nothing about whether the condition ever existed or whether anything changed. The pair shows a transition under a constant test, which is exactly the claim `this was open and is now closed`. ## Defending the negative The hardest part of this answer, and the part that separates a strong candidate, is knowing that an empty result is ambiguous. `The rule returned nothing` has at least four causes: - **The resource was fixed.** The intended one. - **The resource no longer exists.** Also a legitimate closure — you cannot violate a rule if you were deleted — but it is a different fact and should be stated as such rather than presented as a fix. - **The resource fell out of scope.** It moved to another account, another workspace, or the inventory export the scan reads was narrowed. The resource is still out there, still wrong, and simply invisible now. - **The rule changed.** An exclusion was added, a path was ignored, a match condition was tightened, a severity threshold was raised. The clean result then comes from the rule, not from the estate. So evidence of closure needs three things next to the result: **which rule** (pinned to a version or a content hash, or diffed against the version that raised the finding), **what was scanned** (the scope, and ideally the resource's presence in the scanned set), and **when**. With those, `no result` means something. Without them it is unfalsifiable. ## Why the re-run, specifically over state There is no plan for a resource nobody is changing. If you wanted to prove closure at the plan gate you would have to invent a change to the resource just to make it appear in a document, which is both artificial and, for a production database, unwise. Re-running the rule over recorded state or an inventory export needs no change at all: the resource is in the input because it exists. That also means closure evidence is cheap to produce on demand, which is the practical reason to prefer it over anything hand-assembled. Being asked in a review to demonstrate a fix, and being able to answer by running the rule, is a much stronger position than promising to look for the change record. ## What this looks like in an answer - Name the mismatch: the ticket evidences a workflow state, the rule evidences the condition. - Offer the pair of runs, not a single clean one. - Volunteer the ambiguity of a negative result before the auditor finds it, and say how you remove it: pin the rule version, state the scope, show the resource was in the scanned set. - If the resource was deleted rather than fixed, say so explicitly instead of letting a silent absence stand in for a remediation. ## The failure to avoid The weak version of this answer offers whatever is easiest to export — a ticket list, a screenshot of a settings page, the deployment record for the change that supposedly fixed it. Each shows that something happened; none shows that the condition the rule tests has stopped holding. A screenshot in particular is a point-in-time picture of one attribute, taken by an interested party, with no scope and no test behind it.
- What if the resource was deleted rather than fixed?That is still a legitimate closure, but state it explicitly. Show the resource absent from the current inventory and record that it was decommissioned, rather than presenting a silent empty result. In a rule output a deleted resource and a remediated one look identical, and letting an auditor assume the wrong one is how a finding gets closed on a resource that actually moved.
- Why show the original failing run as well as the clean one?A single clean run only evidences the present. It cannot support the claim that a specific finding was remediated, because it never establishes that the condition held. The pair — the run that raised it and a later run under the same rule and scope that does not — is what evidences a transition rather than a snapshot.
- How could a re-run mislead if the rule changed in between?If the rule was narrowed — an exclusion added, a match condition tightened, a threshold raised — the clean result reflects the rule, not the estate, and the resource may be unchanged. Pin the rule to a version or content hash in the evidence, or diff it against the version that raised the finding, so the reader can see the test was constant.
A closed ticket is a maintenance logbook entry saying the alarm was repaired. Re-running the rule is pressing the test button while the auditor watches.
saying these in an interview costs you the question
- Offers the ticket status as the evidence of remediation
- Shows one clean run with no scope stated
- Cannot distinguish fixed from no longer scanned
- Re-runs a narrowed rule and calls the result closure
- Submits a console screenshot as proof of a fix