Draft review is a factual and decision-readiness control, not an opportunity to negotiate uncomfortable findings away. The customer supplies product, environment and business context; the provider remains responsible for independent technical conclusions and evidence.
The review should involve a small authorised group representing security, engineering, product or service ownership and risk. Legal, privacy, compliance or operations join where the content affects their responsibilities. Broad circulation increases exposure because a draft can contain exploitable detail and unredacted artefacts.
Use one controlled comment log, clear deadlines and an evidence-based dispute process. The goal is a final report that is accurate, reproducible, appropriately prioritised and explicit about coverage and limitations.
Control the draft and review channel
Confirm document version, classification, recipients, storage location and comment owner. Use a secure system with access logs and avoid unmanaged email copies.
Set a review deadline that preserves time for evidence resolution and quality control. Late, fragmented comments increase inconsistency and can delay final issuance.
- Named draft version.
- Least-privilege reviewers.
- Single controlled comment log.
- Review and resolution deadlines.
Verify engagement identity and baseline
Check customer and product names, provider, testing dates, environment, release, hosts, applications and API versions. Correct factual errors with authoritative references.
Ensure the report distinguishes staging from production and records material changes during testing. A finding on an old build must not appear to describe a later release without qualification.
- Product and service owner.
- Build and configuration baseline.
- Environment and target identifiers.
- Assessment and report dates.
Reconcile authorised and reported scope
Compare the final target list, roles, tenants, workflows and exclusions with the SOW, rules and approved change log. Confirm that removed and added items are visible.
The executive summary and conclusion must not imply organisation-wide coverage when only selected applications or identities were assessed.
- Original and changed scope.
- Applications, APIs and clients.
- Roles, tenants and data states.
- Explicit exclusions.
Review the coverage record
Check which operations, workflows, authorization boundaries and techniques were completed and which were sampled, blocked or unavailable. Request clarification where a vague “tested” label hides depth.
Coverage is not the number of requests or tools. It should let the customer understand what security decisions and attack paths the provider actually challenged.
- Target and operation coverage.
- Identity-object-tenant matrices.
- Critical workflow coverage.
- Completed versus constrained work.
Examine every limitation and assumption
Validate account failures, unstable systems, unavailable roles, production restrictions, third-party exclusions and environment differences. Confirm the operational impact of each limitation.
Do not delete limitations for appearance. Resolve a factual error, perform agreed additional work through change control or preserve the uncertainty for the risk owner.
- Technical and access constraints.
- Sampling boundaries.
- Environment differences.
- Residual assurance effect.
Check finding reproducibility
For each material finding, confirm the target, identity, prerequisites, request or action, observed result and authoritative impact. Engineering should reproduce safely where practical.
If reproduction fails, compare versions, data, controls and timing before declaring the issue false. The provider should review evidence and update status transparently.
- Exact affected baseline.
- Clear prerequisites and steps.
- Expected versus observed behaviour.
- Safe control or comparison case.
Review evidence quality and minimisation
Evidence should prove the claim without exposing unnecessary customer data, secrets or other tenants. Verify redaction, screenshot context and request-response integrity.
Ask the provider to rotate or remove inadvertently captured credentials according to the rules. Redaction must not make reproduction impossible for authorised engineers.
- Sufficient proof of impact.
- No avoidable personal or secret data.
- Consistent timestamps and identifiers.
- Secure linked artefacts.
Validate affected scope and root cause
Check whether the finding affects one endpoint, a shared service, multiple roles, all tenants or a configuration class. Separate confirmed reach from plausible but untested variants.
A remediation that changes only the demonstrated request may leave the root cause intact. The report should guide teams toward the shared control where evidence supports it.
- Confirmed affected components.
- Systemic-control hypothesis.
- Related paths tested.
- Unverified variants.
Calibrate severity with documented context
Review exploitability, privilege, user interaction, data sensitivity, transaction impact, reach and compensating controls. Supply evidence for business facts that the tester could not independently know.
Do not lower severity solely because exploitation is inconvenient to fix or because a control is planned. The final rationale should state current conditions and distinguish temporary mitigations.
- Technical preconditions.
- Confidentiality, integrity and availability impact.
- Tenant or population reach.
- Verified compensating controls.
Check remediation guidance for practicality
Engineering should confirm that recommendations address root cause and fit the architecture without turning the provider into the system designer. Ask for control objectives and verification criteria when implementation choices vary.
Identify short-term containment and permanent remediation separately. Ensure the report does not prescribe an insecure shortcut or an obsolete library version.
- Root-cause control objective.
- Immediate containment.
- Permanent design or configuration fix.
- Retest acceptance criteria.
Review executive language and assurance boundaries
The executive summary should explain material risk, coverage, limitations and required decisions in plain language. It should align with the technical findings and must not claim certification or the absence of vulnerabilities.
Check that totals and severity distribution match the detailed report. Avoid sales language, unsupported breach predictions and broad claims about systems outside scope.
- Accurate risk themes.
- Consistent finding counts.
- Visible limitations.
- Point-in-time, scoped conclusion.
Resolve disputes through evidence
Classify comments as factual correction, clarification, severity context, evidence challenge, remediation question or editorial change. Assign provider and customer owners and record disposition.
If parties disagree, preserve both the technical basis and documented customer context. Commercial pressure should not determine whether a reproducible security weakness remains in the report.
- Comment identifier and owner.
- Supporting evidence.
- Provider response.
- Accepted, revised or unresolved disposition.
Approve finalisation and protect the record
Confirm all agreed corrections, unresolved items, distribution list, final readouts and retest plan. The provider performs final independent quality review before issuance.
Retain the approved final version and comment disposition according to policy. Destroy or archive drafts deliberately so teams do not later circulate an obsolete finding state.
- Reconcile scope, coverage and limitations.
- Resolve finding and severity comments with evidence.
- Confirm executive and technical consistency.
- Authorise final issuance and controlled distribution.
Use NIST SP 800-115 for assessment reporting context and the OWASP Web Security Testing Guide for application testing context. Apply contractual confidentiality and the organisation’s evidence-retention rules.
Use draft review to improve truth and usability
A strong customer review makes the report more accurate and actionable without weakening independent assurance. It connects technical evidence to the correct product context and accountable owners.
WIMD uses controlled comments, coverage reconciliation, evidence-based severity review and final quality control so the issued report can support engineering, risk and customer decisions.