For the person buying the test

Three things get sold as a penetration test.

They cost about the same and arrive looking about the same. APEX exists so you can tell which one you are buying before you pay for it.

01

A scan with a covering letter

A CVE scan. A tool is pointed at the estate by somebody who was told to point it there, the output is tidied into a template, and it is sent over. It reports what is already published about software you are running. Nobody attempted to exploit anything, so nothing in it was ever proven — and by construction it can only ever find what somebody else already found and wrote up. It will not once find something unpublished, because it is not looking. It is sold as a penetration test and priced like one.

Ask which findings they exploited. Ask to watch one.

02

A real test by a competent tester

Genuine work by somebody who knows what they are doing — a methodology, actual exploitation, findings that hold up. The limit is arithmetic: one person, a fixed window, an estate far larger than they can cover. They prioritise, which means deciding in advance what to leave untouched.

Ask what they did not get to, and why.

03

An engineer who could do the second one, amplified

Everything above, plus coverage no individual could reach unaided — every request, every parameter, every reachable path — because the model does the volume and the engineer supplies the judgement about what matters. Your data stays inside approved systems while it happens, and every finding still arrives with code somebody else ran.

This is what the credential certifies.

The three arrive looking similar and cost similar money. The credential exists so you can tell which one you are getting before you pay for it, instead of finding out when somebody else gets in.

What the credential guarantees

“You have that cert?” Then these are true.

They don’t need AI to do the job. They know how to use it to do more than they could alone.

The engineer is doing the work, not the model.

One exam phase runs with generative AI disabled entirely, and it is a pass/fail gate no score elsewhere can compensate for. The oral defense also runs with the models off — the board picks lines out of their code and their report and asks them to explain it, live, unprepared.

They can do your engagement with the AI unplugged. It just takes them longer.

They understand your infrastructure, not just a methodology.

Before they are allowed to attack anything, they have to build a full enterprise estate themselves — cloud and on-premise virtualisation, a routed core, remote access, perimeter, a mixed Windows, Linux and macOS fleet, managed mobile devices and a working voice platform — and defend every design decision they made.

You cannot break what you cannot build. They built it.

Your data does not end up in somebody’s chatbot.

They build the controls themselves — classification, outbound inspection, per-engagement isolation, canaries, fail-closed routing — and then those controls are attacked. A confirmed leak of protected data ends the exam attempt on the spot, whatever the rest of the score says.

There is finally a credential that fails people for the thing a lot of testers are quietly doing right now.

They find what a scan never will.

The exam requires an original, non-public issue derived from code, architecture, state or runtime behaviour. A scanner result, a version match or a copied exploit is explicitly not accepted as a finding. Where a known vulnerability is present it gets documented — but the exploitation is original, because a published proof only establishes that a version matched, not that it is genuinely reachable past your controls in your configuration.

We do not take the easy way into your network. A CVE scan can only ever find what somebody else already published.

Every finding came with working code that somebody else ran.

Not a description of an attack, not a screenshot, not a severity rating — an executable proof the candidate wrote, that a reviewer takes into a clean environment and runs, and that visibly crosses the security boundary being claimed. If it does not run, the finding does not exist. Model output is a hypothesis, never a finding.

You are not paying for a beautifully formatted list of maybes. Somebody proved every line of it.

The report tells you what was *not* tested.

Coverage is accounted for explicitly: every surface is mapped either to evidence or to a stated limitation. Missing a designated critical issue is a fail even when every submitted finding is accurate. Silence about coverage is scored as a gap, not as completeness.

A clean report that quietly skipped half your estate is the thing that gets you breached.

The honest part

Used properly, they miss far less than they would alone.

Used properly, AI removes most of that compromise. The same engineer can cover volume no human could work through unaided — every request, every parameter, every reachable path — while still applying the judgement that decides what actually matters and what a finding really means.

That is the whole point of the credential. Not faster reports. The same expert judgement, applied across a far larger surface, with the client’s data staying where it belongs while it happens.

It is still not a guarantee.

A qualified engineer can miss something — anyone telling you otherwise is selling you something. The credential establishes that the person is capable, that your data was governed, and that whatever they reported was proven with code somebody else ran. Not that your estate is now safe.

It says nothing about the firm.

It certifies a person, not their employer, and it is deliberately open to engineers at firms that compete with us. Scope, contract, insurance and how the firm handles your data at an organisational level are separate questions. Still ask them.

Use this on anyone

Six questions worth asking any tester.

Ours or somebody else’s. If a vendor answers these well, that tells you more than any logo on a proposal — including this one.
  1. Which AI did you use on my engagement, and what did it see?

    A confident answer names the provider, the deployment, and the data classes it was allowed to touch. "We use AI to help" is not an answer.

  2. Can you show me the log of what was sent to it?

    If there is no log, nobody knows what left your environment — including them.

  3. Which findings did you personally reproduce by hand?

    The honest answer is a number. If it is "all of them" on a large report, ask how long that took.

  4. What did you not test, and why?

    Every real engagement has gaps. A tester who claims none either did not look or is not telling you.

  5. Can you show me the proof-of-concept code, and will you run it in front of me?

    This is the one that separates a report from a document. If the "proof of concept" is a screenshot and a paragraph, you were told a vulnerability exists — you were not shown one.

  6. Could you have found this without AI?

    Not a gotcha. You are asking whether the tool amplified an expert or replaced one.

We are handing you these knowing some get asked of us. That is the point — a firm that would rather you did not ask is telling you something.

Checking it

Name and number, together.

Verification needs the holder’s name and their credential number. A number on its own returns nothing — the registry confirms a person you are already looking at rather than acting as a browsable directory of certified engineers. Status is live, so a suspended or revoked credential shows as such immediately, whatever the printed certificate says.

One thing worth doing today

Find out where the source code and screenshots from your last penetration test ended up. Most buyers have never asked, and most contracts do not cover it — because when those contracts were written, the question did not exist.

More detail on the standard itself: the evidence standard and the data-protection standard.