Seven-Question Assessment Reference

These questions assess different dimensions of a finding. Technical validity depends on independent reproduction and evidence; scope, program eligibility, duplicate status, and presentation quality are recorded separately. The active workflow owns sequencing, report completion, and submission disposition. A negative answer is not by itself a technical rejection.

The 7 questions

1. Is the asset in scope?

Check the engagement's scope.md (recon/decepticon's RoE doc):

• In-scope domain list
• In-scope IP/CIDR list
• Out-of-scope explicit exclusions (test envs, staging, third-party CDNs/CDN-managed subdomains where the org doesn't own the underlying machine)

An asset outside approved scope must not receive target-facing testing. Record the scope constraint and policy source separately from any existing technical evidence; scope exclusion does not refute that evidence.

2. Is there real-world impact?

Distinguish demonstrated harm from hypothetical consequences. Concrete impact statements include:

• "An attacker can read victim user X's PII (email, name, DOB, SSN)"
• "An attacker can post on behalf of victim user X"
• "An attacker can transfer funds from victim user X's account"
• "An attacker can persist code on the production server"
• "An attacker can pivot to internal network 10.0.0.0/8"

If the finding's impact is "configuration is non-default" or "the manual recommends X but the deployment does Y" without concrete attacker-reachable harm, record the observed behavior and impact limitation without claiming an unsupported vulnerability or severity.

3. Does the PoC actually prove the impact?

The validate_finding result is necessary but not sufficient. The PoC must demonstrate the IMPACT, not just trigger the vector.