A customer asks whether privileged access is reviewed regularly. The questionnaire offers Yes, No, and a comment box. Before choosing Yes, ask a more useful question: what would you show if the customer asked you to substantiate that answer?

A policy describes the intended process. A completed review can show what happened. A system check can reveal whether access matches the approved decision. These are different kinds of evidence.

NIST SP 800-53A Revision 5 organizes control assessment around three methods: examine, interview, and test. Examination reviews assessment objects; interviews clarify how a control works and where evidence can be found; tests exercise mechanisms or activities under specified conditions. Those distinctions are useful when preparing a customer response, even when the customer is not requesting a NIST assessment.

The approach below is Piton’s practical application of that distinction. It is a preparation aid, rather than a certification checklist.

Build a short record for each important claim

Start with the requests most likely to affect the customer’s decision. For each one, record:

  • The claim: the precise behavior you can support, including its scope.
  • The owner: the person or team responsible for the control and its evidence.
  • The evidence: the source, the date or period covered, and what it demonstrates.
  • The boundary: systems, identities, or circumstances the answer excludes.
  • The gap: what remains unverified and the action needed to resolve it.

A link without an explanation makes the reviewer do the interpretation. Add one sentence that connects the evidence to the claim. Keep a distinction between a control that exists, a control that operated during a particular period, and a control whose effectiveness has been tested.

A fictional example: privileged access

Consider a company preparing an answer about access reviews. Its written procedure covers production administrator accounts, but the latest completed review excludes deployment service identities.

An overly broad answer would say that all privileged access is reviewed. A more defensible response describes the production administrator review, identifies its completion date and owner, and states that deployment identities are being assessed separately. The evidence record links the approved review and the relevant account inventory. The remaining work has an owner and a date for the next update.

That response gives the customer something concrete to evaluate. It also exposes an internal task the company can finish, rather than hiding it inside a questionnaire answer. The example describes no actual Piton client or engagement.

Another fictional example: backup recovery

A customer asks whether the service can be restored after data loss. The company has daily backups and successful job notifications. Its last recovery exercise restored a database into a test environment, but did not restore uploaded files or verify that the complete application worked.

The backup jobs support a claim that copies were created. The exercise supports a narrower claim: the tested database could be restored under the recorded conditions. Neither establishes recovery of the whole service within the customer’s required time.

A useful answer states what was restored, when the exercise happened, and what was checked. It separates observed recovery time from a planned recovery target. The follow-up is to exercise the remaining components, verify application behavior, and record dependencies such as encryption keys and account access.

The evidence record names the test owner and links the results. Until the broader exercise is complete, the answer keeps that limitation visible. This example is also fictional; it is not a Piton engagement result.

A checklist before submitting the questionnaire

Use this as a final review of the important answers:

  • Match the scope. Does the evidence cover the product, environment, and identities the customer is asking about?
  • Check the period. Is the evidence current enough for the claim? Explain any changes since it was collected.
  • Separate plans from results. A procedure or target is different from a completed review or an observed test result.
  • Name the owner. Who can explain the evidence, approve the answer, and complete any follow-up?
  • State the limitation. Make partial coverage and untested assumptions visible. Give remediation commitments only when the owner has agreed them.
  • Prepare the evidence for sharing. Check permissions and remove secrets, personal information, and unrelated customer material before sending it through the agreed channel.

Keep the final answer, supporting evidence record, and open actions together. That gives the next reviewer a clear starting point and makes it easier to notice when an old answer no longer fits.

Make the next review easier

Keep approved answer text alongside its supporting record. Reuse it only after checking whether the systems, scope, owners, and evidence have changed. A current policy date does not automatically make an older operating record current.

Before sharing evidence, agree what the customer needs and choose an appropriate channel. Remove unrelated account details, credentials, and confidential material. A concise description or redacted extract may answer the question; if it does not, discuss the additional evidence required.

If the deadline is close, separate what you can substantiate now from what needs follow-up. That makes both the response and the internal work easier to manage.

Bring the difficult requests to Piton’s customer-review engagement, or prepare a scope brief with the decision, deadline, and claims that need evidence.