An audit is only as useful as the plan it leaves behind. The report should be something another developer could pick up and work through without phoning the auditor.
Ask for a sample report before anything else. An anonymised report from a recent audit shows the depth you'll get. Each finding should name the file, app or setting involved, explain why it matters and rate its severity. A branded export of a free speed test doesn't count.
Insist on a remediation plan with hours. Every finding needs an effort estimate and an owner: a change your team can make in the admin, a developer task, or a decision only you can take. Findings should be sorted into fix now, fix with the next theme update, and leave alone. That last group matters, because not every old snippet is worth paying to remove.
Keep the audit separate from the fix. Buy the audit at a fixed fee and treat remediation as a separate quote. Ask the auditor whether they're comfortable with another developer doing the work. If the report reads like a pitch for a rebuild, get a second opinion before you commit.
Match the auditor to your stack. A single-theme store with a dozen apps needs a strong theme developer. A Plus store with expansion stores, B2B, Functions and an ERP feed needs someone who has worked across all of those, and their sample report should show it.
Tell them what changed and when. The auditor works faster with a timeline: theme installs and updates, apps added and removed, agencies that have had access, integrations switched on. An afternoon spent on that list saves paid hours of detective work.
Red flags. A report produced entirely by automated scanners. A headless rebuild recommended before anyone has opened the code. No questions about integrations or who else works on the store. A request for your store owner password.