Two quotes for the same product can describe very different work. The scope, access, complexity and reporting needs that shape a quote, and the questions to ask before you compare totals.
- Published
- Updated
- Reading time
- 6 min read
- By
- Zaaf review desk
In this guide
A useful security budget starts with a written scope. There is no single figure or delivery time that describes every startup: applications, roles, integrations, access and reporting requirements all change the work.
This guide explains what to put in a brief and how to compare proposals on what they actually include, without leaning on old market ranges that never described your system in the first place.
What a quote should describe
Ask every provider to separate the assessment scope, preparation, testing, reporting and follow-up. A quote for an unauthenticated external check is not directly comparable with one covering logged-in workflows, multiple roles and connected cloud services.
| Part of the proposal | What to clarify | Why it matters |
|---|---|---|
| Systems | Applications, APIs, environments and exclusions. | Anything not listed is not tested, whatever the total says. |
| Access | Accounts, roles, test data and who sets them up. | Missing access quietly turns a deep assessment into a shallow one. |
| Depth | The workflows and security questions to investigate. | This is where two similar totals buy very different work. |
| Delivery | Report format, review meeting and retest terms. | The report is what your buyer reads, not the testing days. |
Request a current written quote after scoping. Any figure you see before the scope exists describes someone else's system.
What shapes the quote
Five things move the number more than anything else. None of them is the provider's logo.
- Scope. Number of applications, user roles, API endpoints and cloud environments. More surface means more work.
- Access. Authenticated testing across real roles takes longer than an unauthenticated look at the edge, and it finds the problems buyers actually ask about.
- Complexity. Multi-tenant boundaries, payment flows, third-party integrations and custom authorisation logic all need more careful work than a brochure site.
- Reporting. Reports shaped for SOC 2 or ISO 27001 evidence, an attestation letter, or a buyer-facing summary each add work beyond the findings themselves.
- Retest. Verifying your fixes may be included or billed separately. Always ask, because the retest is what closes a finding.
Plan the schedule as well as the budget
Ask for separate dates for access readiness, testing, draft reporting and final delivery. A promised start date is not the date your buyer can review the final report.
- ScopeList systems, roles and integrations, with exclusions.
- AccessAgree accounts, test data and testing windows.
- OutputsDefine the report, the review meeting and the retest.
An illustrative case: the assessment is ready to start, but the second user role and a test integration are not available. The calendar slips even though the provider has capacity. List these dependencies in the brief and give each one an owner before you confirm a date.
After material changes to the application, discuss whether affected areas need further testing. A report describes the scope and state that were assessed; it does not automatically cover later releases.
Questions to ask before you compare
Send the same brief to every provider, then ask the same questions of every proposal. The answers are what you compare.
- What exactly is in scope? Which hosts, APIs, roles and environments, and what is explicitly excluded.
- Is testing authenticated? With which roles, and does it cover the boundaries between tenants or accounts.
- Who validates the findings? Whether a person reviews each finding and its evidence before it reaches you.
- What does the report contain? Evidence for each finding, expected and observed behaviour, a fix, and a summary your buyer can read.
- Is a retest included? How many, within what window, and whether the result is recorded against the original finding.
- What do you need from us, and when? Accounts, data, contacts and approvals, each with a date.
If your buyer requires a particular accreditation, report type or testing method, confirm that requirement and the provider's eligibility before you buy. Do not assume that one kind of assessment automatically substitutes for another.
Before you send the brief
A good brief makes every quote you receive easier to read. It also shortens the scoping call, which shortens the calendar.
Before you send
A quick final check
Common questions
What determines the cost of a security assessment?
Mostly scope, access, complexity, reporting and retest terms. The number of applications, roles and APIs, whether testing is authenticated, how intricate the authorisation logic is, and what the report has to prove all change the amount of work.
Why do two quotes for the same product differ so much?
Usually because they describe different work. One may cover a single unauthenticated surface, the other logged-in workflows across several roles with a retest. Compare what is included before you compare totals.
Should a retest be included in the quote?
Ask. Some providers include it, others bill it separately. A retest dated after the fix is what lets a reviewer close a finding, so know how it is handled before you sign.
How long does it take to get a report?
It depends on access readiness, testing time, review and reporting. Ask for a separate date for each stage, and list your own dependencies, such as test accounts, so the schedule does not slip on your side.
NoteThis is general assessment-planning guidance, not a quote or a guarantee of buyer acceptance; scope, availability and follow-up work are agreed in the engagement terms.