Continuous pentesting, sized to your operation

Below 50

You cannot test what you cannot see, and attackers do not wait for the list to be ready: they build their own with public tools in hours. Before any test, map what the company exposes to the internet, with an owner per asset. Even an incomplete first version changes the scope of every testing conversation.

50 to 79

The surface is partly known, and the unknown part is precisely the attacker's favorite: they look for the forgotten, not the watched. It is worth confronting your list with an external enumeration done from the outside in. The difference between the two is your blind spot.

80 or above

A mapped surface with owners is the right foundation in your answers. The next gain is continuous freshness: attack surface changes with every deploy, and a six-month-old map describes a different company.

Below 50

Without human-led testing, the environment's security is a hypothesis that has never been confronted. Scanners cover the known; business logic flaws and chains of small weaknesses only appear when someone tries. A first test on the most exposed assets turns the hypothesis into a list of facts.

50 to 79

Testing exists, but as an event: it happens when the audit asks or when budget is left over. The jump in this range is tying tests to environment triggers: a major change, a new system, a new integration. Risk is born at the pace of the business, not the pace of the calendar.

80 or above

A structured cadence in your answers. The next refinement is varying depth and technique by criticality: the system that processes payments deserves more testing time than the corporate website, and a test that is always the same becomes a routine the environment learns to pass.

Below 50

Offensive testing without written authorization exposes both the company and the tester: legally, there is no difference between an informal test and an attack. Scope, window, targets and an emergency contact in a signed document is the minimum before any attempt. That includes the quick test by someone in-house.

50 to 79

Authorization exists, but the edges are loose: third parties, cloud, what to do about a serious finding. The edges are what cause incidents mid-test. A standard rules-of-engagement document, reviewed by whoever answers for legal, solves this once and serves every test that follows.

80 or above

Mature rules of engagement in your answers. Keep the document alive: every cloud provider updates its own testing policies, and the emergency contact from two years ago may no longer work there.

Below 50

A test whose report never becomes a fix has only produced a confidential document describing how to break into the company. Before the next test, give the previous one a destination: every finding with an owner, a deadline by criticality and a verifiable status. It is the least glamorous part of the cycle and the one that decides whether it is worth anything.

50 to 79

Findings enter a workflow, but remediation treats the symptom pointed out, not the pattern. When a test finds a flaw, the next question is where else the same mistake was repeated: the answer tends to multiply the report's value without costing another test.

80 or above

Structured remediation in your answers. The next gain is feeding the start of the cycle: patterns that keep appearing in tests become development requirements and build checks, and the flaw stops being born.

Below 50

Without retesting, fixed is a claim, not a fact: some fixes do not close the flaw, only the path the report described. Requiring a fresh exploitation attempt after every critical fix is the habit that turns reports into security. Without reproducible evidence, you cannot even know what to retest.

50 to 79

Retesting happens, but depends on who remembers or what the calendar allows. Formalize it: a critical fix only closes with a documented new exploitation attempt. And demand evidence in reports; a finding without reproducible steps generates debate, not remediation.

80 or above

A working retest cycle in your answers. The refinement is history: tracking how long each criticality takes between finding, fix and retest gives leadership a number it understands and gives the technical team its budget argument.

Below 50

If only the main web application gets tested, whole fronts of the environment go unconfronted: the API behind the mobile app, the cloud configuration, the internal network behind the perimeter. Attackers pick the least watched door, not the most famous one. Widen scope in the order of what exposes the most critical data.

50 to 79

Scope goes beyond the website, but there is still untouched territory, and the internal network is usually the largest piece. A test that assumes a compromised credential answers the question that matters: the perimeter fell, what is left? The answer tends to reorganize priorities.

80 or above

Broad coverage in your answers. The next step is chaining fronts the way attackers do: from API to cloud, from workstation to internal network, in one continuous scenario instead of isolated tests. That is where the paths no single-front test reveals show up.