Before I run a single request against a target, I spend an hour answering questions that have nothing to do with exploits. It is the least glamorous part of the job and the one that most changes the result.
Who can reach what
An endpoint that requires an authenticated session with a verified email is a different risk than the same endpoint on the public internet. Most misconfigured-object reports I see ignore this distinction, which is why they get argued about in triage.
I map the entry points first: what is anonymous, what needs a session, what needs a role, and what is only reachable from inside the network. The list is usually shorter than the documentation suggests.
Who owns the asset
A vulnerability on a hostname nobody maintains is still a vulnerability, but the remediation path changes entirely. Before testing I want to know which team, vendor or contractor is responsible for each component, because a finding without an owner is a finding that will not be fixed.
This is also where scope creep gets caught early. If the CDN is managed by a third party, my testing window and permissions need to reflect that.
What the data is worth
Technical severity and business impact are different numbers. An IDOR that exposes a user's own profile settings is low. The same flaw on invoices, medical records or API keys is not.
Knowing what the system stores tells me where to spend my time. It also tells me how to write the finding so the person holding the budget understands why it matters.
What changes when you do this first
You test fewer things and find more that matters. The report gets shorter, the severity arguments get calmer, and the fixes land with the team that can actually make them.
That is the trade I would make every time.