Four reasons, and the evidence for each.

What you are actually buying

Security testing is sold on an assumption that is rarely stated: that the work behind two reports is comparable, so the deciding factor is price. It is not comparable.

The difference between an automated scan presented as a penetration test and a manual assessment that carries findings to proof is roughly a factor of ten in effort and the whole of the value. When you compare proposals, the question that separates them is how many days of manual testing are in the number, and who specifically performs them.

The second question is what happens after the report. A finding you cannot reproduce is a finding your developers will argue with rather than fix, and an engagement that ends at the report leaves you to discover on your own that a fix was partial.

What CERT-In empanelment does and does not mean

It is the credential clients ask about most and understand least, so it is worth being precise. Empanelment means CERT-In has assessed the firm as competent to conduct information security audits, and it is a hard requirement for a great deal of government and regulated work. Without it, your report will not be accepted where the rules call for an empanelled auditor.

What it does not mean is that every empanelled firm delivers comparable work. Empanelment sets a floor, not a ceiling. The list is long, the method varies enormously across it, and the difference between two empanelled reports for the same system can be the difference between a document that closes a compliance obligation and a document that also makes you safer.

Ask about the method, not just the listing. Ask how many days are manual, who performs them, and whether the person testing will be on the debrief call.

Why free retesting changes the incentives

Look at what a paid retest does to the incentives on the firm that wrote the report. It rewards volume of findings over accuracy of findings, and it rewards remediation guidance vague enough to require a second look.

We include retesting for a self interested reason as much as an ethical one. Knowing we will have to come back and verify every fix at our own cost makes us write remediation advice that works the first time.

It also produces the most useful number in the engagement, which is how many fixes were partial. In practice a meaningful proportion of remediation closes the specific case in the report and leaves the same class of issue open two endpoints away. You only ever discover that if somebody looks.

The reporting standard, in detail

• An executive narrative for people who will not read the annexe, business consequence first
• A technical annexe with the exact request, payload and reproduction for every finding
• Severity argued from demonstrated impact rather than a score copied from a database
• Suspected but unproved issues kept in a separate observations section, clearly labelled
• Remediation sequenced by what to do first, not an undifferentiated list
• Evidence organised the way your regulator asks for it, so nobody reformats it later

Questions worth asking any security firm, including us

• How many days of the quoted effort are manual, and who performs them
• Is retesting after remediation included, or billed as a second engagement
• Will the engineer who tested my system be on the debrief call
• What happens to my findings data after the engagement closes
• Can I see a redacted report from an engagement in my sector
• If you find nothing serious, do I still get a report that says so plainly

How we compare on the things that are hard to compare

Firms differentiate on the measurable and compete on price for the rest, which pushes the whole market towards whatever is easy to count. Three things that are hard to count and matter more than most of what appears in a proposal.

Continuity: whether the engineer who tested your platform last year is available this year, which determines how much of your second assessment is spent re-learning your architecture rather than testing it.

Willingness to be argued with: whether the walkthrough is a presentation or a technical discussion where findings can be downgraded when your team knows something we did not, and occasionally upgraded when they know something worse.

And what happens when we find nothing serious. A firm that cannot produce a clean report is a firm whose findings you cannot trust when they are severe.

Where we are not the right choice

If your requirement is genuinely a compliance tick at the lowest defensible cost, there are firms who will do that for less than we will, and we will tell you so rather than compete on it.

If you need engineers embedded on your premises full time for a year, our engagement based model with continuity between engagements is the wrong shape, and stretching it into staff augmentation serves nobody well.

If your estate is entirely on one hyperscaler and your requirement is configuration review, the native tooling plus a competent internal engineer will get you most of the way for a fraction of the cost.

We would rather lose those three conversations early than deliver badly and have you discover it at the end.

How an engagement usually starts

A thirty minute call with an engineer rather than a salesperson, in which we try to work out what you actually need. Occasionally that call ends with us recommending less work than you asked for.

From there, a written scope with the effort broken out by activity, a named lead, a start date, and the short list of what we need from you: test accounts at each privilege level, an environment resembling production, a technical contact who can answer inside a day, and written authorisation.

Nothing in that process requires you to commit before you understand what you would be committing to.