What buyers ask AI before choosing a cybersecurity firm

Buyers ask who is authorised to do the specific audit they need, what a test or certification will cost and take, and what to do in an incident. Most of these questions are forced on them by a regulator or a customer, so the buyer is hunting for a named document rather than for better security in general.

The questions, in the words buyers use

Who is allowed to do it

• "Which auditors are empanelled by CERT-In"
• "Who can issue a safe to host certificate for a government project"
• "Can any consultant do a SOC 2 audit, or does it need an audit firm"
• "Our bank client wants an audit by a specific type of firm, who qualifies"

Cost and time

• "VAPT cost for a web app, an API and a mobile app"
• "ISO 27001 cost and timeline for a company of our size"
• "Difference between a vulnerability scan and a penetration test"
• "How long does a SOC 2 observation window take"

Compliance

• "How quickly must a cyber incident be reported in India"
• "How long do we have to keep logs and where"
• "What does the Digital Personal Data Protection Act require of us"
• "Do we need a data protection officer"

Incident

• "We are hit by ransomware, what do we do in the first hour"
• "Do we have to report it, and to whom"
• "Should we pay"
• "Who does forensics and how fast can they start"

What a good answer looks like

Name the requirement and say exactly who can satisfy it, including the cases where that is not you. A firm that says "for this you need an empanelled auditor and we are not one, here is what we do instead" is more useful than one that blurs it, and useful is what gets quoted.

Explain the difference between a scan and a test plainly, because that is where buyers get overcharged and they know it. Publish what a report contains, ideally a table of contents from a real engagement with the client details removed.

Publish price bands against a defined scope: how many applications, how many endpoints, whether retesting is included. And publish the reporting timelines with the source, not from memory.

Where you are probably missing

• Empanelment and certification status unclear, which in this category reads as a reason to skip you.
• No price bands, so the cost question goes to somebody else.
• No page per named requirement, only a services list using your vocabulary instead of the buyer's.
• No incident response page and no answered number.
• No sample report structure, although buyers cannot tell two proposals apart without it.
• Nothing on what stays the client's responsibility, which every serious buyer wants stated.

What to publish first

• A status page: empanelment, certifications, scope, validity, and what you are not.
• One page per requirement, named after the document the buyer was told to get.
• Scope and price bands for testing work, with retesting policy.
• An incident response page with a contact that is answered out of hours.
• A plain explanation of the reporting and log retention rules, with the official source and a date.

Every one of those pages is written from work you already do. The only new part is saying it in the words a frightened buyer types.

A worked example of the scan against test answer

This is where buyers get overcharged, so it is the page that earns the most goodwill. Here is a complete version.

Explain what an automated vulnerability scan is: a tool runs against the application and reports known issues from its signature set. It is quick, it is cheap, it is repeatable, and it finds missing patches, weak configurations and known component flaws. Then explain what it cannot find: a broken authorisation check where one user can read another user's records, a business logic flaw such as applying a discount twice, a sequence of steps that bypasses payment, or a privilege escalation that needs a human to reason about roles.

Then explain manual penetration testing: a tester works through the application with defined roles, tries to break the logic, chains findings together, and writes up reproduction steps. Say roughly what drives the effort: the number of user roles, the number of workflows that involve money or personal data, and whether interfaces and a mobile application are in scope.

Finish with the honest guidance: a scan on a schedule plus a manual test at each significant release covers most organisations, and a manual test alone with no scanning between releases leaves long gaps. Then say which of the two a buyer is likely to be quoted when they asked for the other.

What these questions do not include

They do not include tooling preferences or your methodology's brand name. Buyers do not search for those and cannot evaluate them.

They also do not include a promise of security. No test makes an organisation secure, and a page implying it does is the kind of claim that gets a firm distrusted in a category where the reader is often technical.

And they do not include the part that stays with the client. Fixing the findings, managing patching and training staff are the client's work, and a page that pretends otherwise sets up a failure.

Common questions

Why do buyers arrive already knowing the document they need?

Because somebody else told them: a regulator, an enterprise customer's procurement team, an insurer or an investor. That is why pages named after your services do badly and pages named after the document do well.

Should we say when a buyer does not need us?

Yes. A startup with one application and no regulated data often needs a scan, a configuration review and some developer training rather than a full audit programme. Saying so is what makes your advice on the larger engagements believable.

How do we answer the ransomware question responsibly?

By describing the first steps in order: isolate, preserve evidence rather than rebuilding immediately, identify what was accessed, check the reporting obligations and their timelines, and involve legal counsel early. On payment, state the position plainly: it does not guarantee recovery, it may carry its own legal exposure, and it should never be the first decision.

Do we need to explain the data protection law if we are not lawyers?

Write the operational part: what data you help a client discover, classify, restrict and log, and what belongs to their legal adviser. Staying inside your own scope is itself a trust signal.

What should our incident page promise?

Only what you can keep. A response time you actually staff, a channel that is genuinely monitored, and a clear statement of what happens in the first hours. An unanswered emergency number is remembered for years.

What to do first

Write the scan against test page today. It is one page, it is honest about how your own industry overcharges, and it is the page a technical buyer will send to their manager.