Attacks a system deliberately to find how it breaks before someone else does.
Why this one is hard to judge
Claims are easy and evidence is often confidential, which makes references and method the only real signal.
What to ask for
Ask for a specific vulnerability they found in a system, and how they found it.
Ask how they decide when to stop testing and call a system safe enough.
Ask for an example where their finding was dismissed, and what happened next.
Ask what they do differently when testing a system that talks to real customers.
The mistake most hirers make
Hirers expect a red teamer to produce a clean list of fixed vulnerabilities and get uneasy when the report is messy and inconclusive. Real red teaming often ends with judgement calls, not certainty. Someone who claims a system is now safe after testing has misunderstood the job.
What good looks like after 90 days
A documented set of tested weaknesses, with clear notes on which were fixed and which were accepted. At least one finding that changed how the system was built or deployed. A working relationship with engineers where findings get acted on, not filed away.
How we assess it
Against a rubric that is published in full, on evidence the practitioner supplies and a reviewer checks. Where something has not been verified, the profile says so.