Penetration tester certifications: which ones mean something

A certification is not a guarantee of quality. It’s proof that a person once passed an exam, not that they’ll deliver a good test for you. It says nothing about how they work under a deadline, how they write a report, or whether they’ll notice something nobody asked about.

It is useful all the same, in two ways. It narrows the field, because a vendor without a single hands-on exam on the team is a different case from one whose people got through an environment they had to actually break into. And it says what the qualification covers, which you can’t read from the company name or the length of the proposal.

It’s used badly when it’s counted. Ten acronyms in a proposal don’t mean a test ten times better: they can overlap, they can be ten years old, and they can belong to a person who won’t be on your engagement.

What decides is what the candidate does during the exam and what they hand in afterward. Both are usually in the issuer’s public exam description, and that says more than any ranking of certifications.

The third row is the most valuable for a client and nobody talks about it in proposals. From a penetration test you don’t get a score or a list of captured systems; you get a report. An exam that requires and grades a report verifies exactly the part of the work you will eventually see.

A hands-on exam guarantees nothing either. Proof that someone once broke into a prepared environment over a weekend isn’t proof that they’ll find the same at your company. The exam environment is built to be breakable. Your network isn’t built that way.

Knowledge exams aren’t useless; they just measure something else. For roles that don’t run tests, meaning security management, compliance, and vendor oversight, breadth is more useful than the ability to break one system. The problem starts only where a knowledge certification is passed off as proof that someone can test.

The acronym says nothing about the format, and neither does the word “certified” in it. One exam that ends with a submitted report has the word in its official name. Another that ends with submitting flags doesn’t.

It’s also misleading that industry usage and the issuer’s official form routinely diverge. With one issuer, the official exam name contains neither the word “certified” nor the acronym by which the certification is referred to in proposals. The acronym was coined by the industry, not the issuer.

The practical consequence is simple: look for the issuer’s exam description, not an interpretation of the acronym. The description is public and tells you what the candidate had to do.

Certifications also differ in subject, and that difference gets lost in proposals entirely. One exam verifies testing of web applications, another networks and domain environments, another cloud accounts and permissions, another running a scenario-based operation, and the newest additions are exams on systems with AI and machine learning.

An exam on web applications says nothing about Active Directory, and vice versa. When you’re asking for an internal network test, a certification on applications is no use to you, however demanding it was. So ask about qualification for what you’re ordering, not qualification in general.

No, and it’s the most common snap judgment you’ll hear in this area.

A mandatory course says nothing by itself about the difficulty of the exam. There are demanding hands-on exams for which the issuer requires its own course and allows no other route, and there are tests that can be passed without any preparation from the issuer at all. With the widespread knowledge certifications, the course is often just one of two routes, the other being documented experience.

What tells you about the exam is what the candidate has to do during it, not how they got to it.

That depends on the issuer, and for a specific certification you’ll find it in their exam description. For a client, though, another date matters more: when the holder passed it. The field has moved on, so an exam from several years ago says less about today’s work than a recent one, even if the certificate itself never expired.

Proposals regularly mix these two things up, yet they are two different claims. ISO/IEC 27001 is a certification of an information security management system, meaning the company and its processes. It says nothing about whether a specific tester can break into your application.

A personal certification, on the other hand, is proof about a person and says nothing about how the vendor handles your data. Both make sense; they just answer different questions. What an auditor expects to see for the standard has its own entry: certification of the company, not the person.

Acronyms are the weakest of the available clues. Three questions say more, and none of them requires you to know your way around certifications.

• Who specifically will be on the engagement, and what qualification they have for what you’re ordering.
• Which methodology the test will follow, and what exactly is in scope.
• What the report looks like. Ask to see a real deliverable, not a slide from a presentation.

The last question is the most telling and the least asked. The report is the only thing you keep from the engagement, and the difference between vendors shows in it sooner than in certifications: whether a finding can be reproduced from its description and whether the remediation priority makes sense. We describe what a deliverable that shows real quality looks like with the service, and which methodology the test follows has its own entry.

The criterion from the second section measures us too, so we apply it to ourselves: the certifications we hold are all hands-on, two of them also require written work to be submitted and graded, and in one of those the report is in the form it would go to a client. Who actually runs our tests is listed on the team page. And if you’d like to look at a report before asking us anything, request a sample from our test infrastructure: there is no client in it, so we can send it to anyone.