Track Security Reviews Without Promising Their Completion
Track security-review intake, evidence, clarification and decision separately, with named responsibility and explicit unknown duration.
10/24/20263 min read
A completed questionnaire is not a completed security review. Sales teams often know when they sent a document but not when the buyer accepted its scope, assigned a reviewer or reached a decision. Treating those events as one milestone creates unsupported close dates and promises that neither security team has made.
The sales record should help coordinate legitimate review work without becoming a substitute for it. Capture the review boundary, responsible parties, evidence status and next checkpoint. Leave duration unknown when the relevant reviewer has not supplied a reliable estimate.
Establish the review boundary first
Describe the proposed product or service, the environment under discussion and the information the buyer says it needs to assess. A review for a limited demonstration may not cover production use, new data categories or a later integration. Record those boundaries so a favorable result is not reused outside its stated scope.
NIST's NIST SP 1305: Cybersecurity Supply Chain Risk Management Quick-Start Guide emphasizes communicating supplier requirements and responsibilities in a way that reflects the supplier relationship. The milestone method below is an original coordination aid, not a NIST certification process or a claim that every buyer must follow the same sequence.
Ask who coordinates the review and who can communicate its decision. The salesperson can own timely responses from their organization, but cannot accept risk on the buyer's behalf. Nor should a commercial manager replace the responsible technical reviewer simply because a quarter-end date is approaching.
Use states that describe evidence, not optimism
Separate requested, scoped, submitted, clarification pending and decision recorded. Adapt the labels to the buyer's actual process. “Submitted” means a defined evidence package reached the approved channel. “Decision recorded” requires the authorized outcome and any conditions; it does not necessarily mean approval.
Track an internal response target separately from a buyer review estimate. If your security team commits to answering one question by Friday, record that commitment. Do not turn it into “security approval Friday.” A checkpoint is when status will be reviewed, not a guarantee that all issues will be resolved.
Keep sensitive technical materials in the approved repository with appropriate access. The ordinary opportunity record usually needs a reference, scope and status rather than copied architecture details, credentials or a complete assessment. Do not upload confidential evidence to an unapproved tool merely to produce a sales summary.
A fictional milestone record
Consider fictional Willow Analytics evaluating a workflow application for a limited pilot. The buyer requests a security review before any use of its production data. All dates and events here are illustrative.
19 October: review requested for the named pilot scope; production-data use remains prohibited pending the required decision.
21 October: seller submits the approved questionnaire and supporting references through the designated channel; receipt confirmed, completeness not yet confirmed.
23 October: reviewer requests clarification of one data-retention setting; seller's security lead owns the response.
27 October: seller's internal response target for that clarification; not an approval deadline.
Completion estimate: unknown; buyer has not provided one.
Decision authority: buyer's designated security-review function, with procurement and commercial decisions recorded separately.
The sales summary reads: “Clarification pending; seller response targeted for 27 October; buyer review duration unknown.” It does not read: “Security complete next week.” The former gives the team an actionable responsibility while preserving the actual limit of its knowledge.
Respond correctly to scope and outcome changes
If Willow later adds a production integration, return to the scope question. Ask the review coordinator whether the existing assessment covers that change and what additional work is required. Do not copy the pilot's eventual status to the expanded use case automatically.
If the reviewer records a conditional acceptance, preserve the conditions and the owner responsible for meeting each one. A condition that must be satisfied before use is not a post-launch housekeeping task. If the reviewer declines, record the decision accurately and route any proposed alternative through the authorized process.
The review record should also distinguish a technical decision from a purchasing decision. Passing the required review does not establish budget approval, agreement on commercial terms or a signed contract. Those remain separate sources of uncertainty.
At each pipeline review, ask what evidence changed, which party owns the next response and whether the proposed use remains within scope. Those questions support responsible coordination without pushing specialists to promise a result or date they cannot support.
Continue with Create a Weekly Pipeline Review That Ends with Decisions or Keep Research Notes Separate from Customer Commitments.