Start with the assessment, then the price.
There is no single assessment that fits every business. Reviewing a public website, examining a customer portal with several user roles, and assessing an internal network involve different questions and access arrangements. Counting pages or IP addresses alone can miss the work that matters.
Describe the outcome you need: checking a new release, investigating access boundaries, or giving your IT team a clearer remediation plan. Then identify the systems and workflows that support that outcome. A smaller assessment with explicit boundaries can be easier to act on than a broad proposal with unclear coverage.
What changes the amount of work?
Ask how these factors affect the proposed engagement. They help explain why two apparently similar quotes can cover substantially different work.
- Scope: the agreed domains, applications, API endpoints, network assets and exclusions.
- Complexity: distinct roles, integrations, tenant boundaries and business workflows that need examination.
- Access: whether suitable accounts, documentation and a representative environment are available.
- Operational constraints: testing windows, sensitive systems and coordination with third-party providers.
- Deliverables: reporting detail, evidence handling, a findings discussion and any agreed follow-up.
- Retesting: which fixes will be checked, when, and whether that work is included or separately scoped.
Compare coverage and deliverables.
Ask each provider to describe what will be tested, the access they expect, the techniques or activities excluded, and how the results will be communicated. Establish whether the proposal covers an automated scan, a penetration test, a configuration review, or a combination. Those services can answer different questions.
A proposal should make it possible to explain what your business is buying. Clarify whether the report will help the people responsible for fixes understand affected systems, potential impact and next steps. Also ask how urgent findings will be communicated during the assessment and who will be available for the final discussion.
Send a brief that supports a useful quote.
For an initial enquiry, include your business context, the systems you own or are authorised to assess, your main concerns and any deadline. For an application, describe the main workflows and user roles. For a network, describe the intended test position and the asset groups you want considered.
Leave passwords, client records and detailed security evidence out of the initial email. Agree on a suitable way to share assessment material after the first conversation. If the scope is uncertain, make that uncertainty part of the discussion rather than guessing at an asset list.
Plan for the work after the report.
Budgeting should account for the time your developers, IT provider or system owners need to review findings and implement changes. Decide who will own that work and how you will confirm that important fixes have addressed the original issue.
Blackcube Solutions scopes engagements individually. We discuss the environment, authorisation, deliverables and any follow-up before proposing the assessment. This guide describes pricing factors; it is not a rate card or a quote for your systems.
Further reading.
- NIST SP 800-115Background on planning and conducting security assessments, rather than Australian market pricing.
Discuss the right scope.
These services can support a conversation about your systems and assessment goals.