Skip to content

Define scan scope and targets

Why scope matters as much as what you scan, and how to think about “in-scope.”

Updated · scope · configuration

Scan scope is the single configuration decision that most affects both your finding volume and your compliance story. Too broad and you drown in findings on assets you don't care about. Too narrow and auditors will ask uncomfortable questions.

Start with what's auditable

If you're heading toward SOC 2 or ISO 27001, the scope of your security program should match the scope of the audit. Scanning only your production environment while your compliance scope says “production + sandbox” creates an evidence gap. Align first, then optimise for noise later.

Scope types

  • Inclusion list: explicit domains/accounts/repos that are in scope. Safest default.
  • Tag-based: “anything tagged production” — powerful for cloud, but depends on your tag discipline.
  • Auto-discovered: Cyvex discovers new external assets and adds them automatically. Great for surface, risky for internal scanning.

Document the exceptions

Every out-of-scope asset should have a written reason (legacy system, third-party managed, etc.). When an auditor asks “why isn't this scanned,” an answer of “we forgot” is much worse than “it's vendor-managed and out of scope per our ISMS policy.”