Evidence Review Standard
1. Purpose
Evidence review determines whether material is safe to retain, share, coordinate, or publish. The review is not merely editorial; it is a control point for authorization, privacy, exploitability, and credibility.
2. Review Outcomes
Evidence may be classified as:
- publishable: safe for public release after normal editorial review;
- restricted: may be used for coordination but not published;
- sensitive: requires limited access, encryption, and minimization;
- reject: should not be retained or handled further except for minimal audit record;
- hold: preserve pending legal, vendor, safety, or DRB decision.
3. Intake Checklist
For each evidence artifact, record:
- source;
- collection date;
- collector or reporter;
- authorization basis;
- affected product or system;
- data class;
- sensitive fields present;
- reproduction value;
- publication value;
- recommended handling;
- reviewer and date.
4. Authorization Review
Ask:
- How was this obtained?
- Was the reporter authorized to observe it?
- Did collection require bypassing controls?
- Did collection require accessing another person’s data?
- Did collection affect service availability or integrity?
- Would retaining this material create legal or privacy risk?
- Can a safer substitute prove the same point?
If the authorization basis is unclear, do not publish and do not share further until clarified.
5. Sensitive-Data Review
Search for:
- credentials;
- API keys;
- private keys;
- OAuth tokens;
- session cookies;
- authorization headers;
- personal names;
- email addresses;
- phone numbers;
- addresses;
- account numbers;
- customer IDs;
- medical or financial data;
- internal hostnames;
- private IP ranges;
- source paths;
- ticket IDs;
- proprietary code;
- non-public vendor statements.
Sensitive material should be removed, replaced, or summarized unless essential for restricted coordination.
6. Exploitability Review
Ask whether the artifact gives a reader more offensive capability than necessary.
High-risk indicators include:
- complete exploit path;
- payload strings;
- bypass technique;
- target-specific endpoint sequence;
- working exploit code;
- reliable crash-to-control details;
- credential extraction instructions;
- automation logic;
- post-exploitation guidance;
- chaining instructions.
When high-risk indicators are present, convert to defensive summary, coordinate privately, or delay publication.
7. Redaction Review
Redaction must be verified in the final rendered artifact, not only in source files.
Review:
- source Markdown;
- generated HTML;
- attached files;
- screenshots;
- PDFs;
- SVGs;
- JSON datasets;
- source maps;
- metadata;
- alt text;
- titles and descriptions;
- hidden document content.
8. Evidence Quality Review
Evidence should be sufficient and not misleading.
Reject or mark limitations when evidence is:
- unverifiable;
- inconsistent;
- taken out of context;
- scanner-only without validation;
- based on a stale version;
- missing affected conditions;
- dependent on unconfirmed assumptions;
- impossible to reproduce safely;
- collected outside scope.
9. Publication Review Gates
Before publication, confirm:
- authorization basis is documented;
- vendor awareness is documented when applicable;
- sensitive data is removed;
- exploitability is appropriately limited;
- severity language matches evidence;
- remediation status is accurate;
- all links resolve;
- filenames and paths are durable;
- no private notes or draft comments remain;
- reviewer signs off.
10. Reviewer Independence
Where possible, the person approving publication should not be the only person who collected the evidence. High-impact reports should receive independent technical review and independent redaction review.
11. Rejection Note
When evidence is rejected, record only enough to explain why. Do not preserve harmful material simply to prove that it was harmful.