Offensive Security Consulting: Scope, Standards and Choosing a Provider

Consider a hypothetical case. A small B2B software company is about to sign its first large enterprise contract, and the customer's security team asks for "a recent penetration test report." The head of engineering has three proposals on the desk. The first promises to "test the application against the OWASP Top 10" in two weeks. The second is called a red team and says almost nothing about boundaries. The third lists ASVS requirements with version numbers, spells out exclusions and includes a retest after fixes. All three are sold as offensive security services, and at first glance they look easy to compare on price and timing.

The example is invented, but the problem in it is real: the proposals answer different questions. One looks for known classes of bugs, another checks whether the team would notice an attack, the third produces traceable assessment results against a defined set of controls. A buyer who does not know which question they are asking ends up with a report they cannot show the customer, cannot hand to engineers and cannot compare with the next one. Below we look at how offensive security consulting works, what each engagement format actually proves, how to use standards without bureaucracy, and how to recognise a provider whose results you can put to work.

What you are actually buying under the name "offensive security"

Offensive security consulting is work by specialists who examine your systems the way an attacker would, but with explicit written authorization, within agreed boundaries and under rules that protect the live environment. Buyers usually want three things: an independent view of weaknesses that can genuinely be exploited; evidence engineers can work with; and confidence that the work follows recognised methods rather than one tester's habits.

The label covers a whole family of activities. NIST SP 800-115, the Technical Guide to Information Security Testing and Assessment published in 2008, treats penetration testing, vulnerability scanning and other examination techniques as parts of a single assessment process. It also states two goals worth keeping in mind on any project: finding vulnerabilities in a system or network, and verifying compliance with a policy or other requirements. Discovery and verification are different jobs, and which of them matters most shapes everything else.

It matters just as much to understand what such a project is not. A penetration test is not certification, attestation or an auditor's opinion on the adequacy of controls. It shows what could be found and confirmed within specific boundaries on specific dates. The absence of a finding in the report does not prove the absence of vulnerabilities.

Finally, offensive work does not replace secure development. CISA's Secure by Design initiative starts from the view that the burden of cybersecurity too often falls on customers and smaller organisations, and that technology manufacturers should take ownership of product security at leadership level. A consulting engagement is most valuable when it supports that ownership: not merely listing bugs, but explaining why they arose and helping close entire classes of defects.

Which question the engagement answers: formats and what they prove

A costly procurement mistake is comparing formats that answer different questions. It is easier to start not from the name of the service but from the evidence you need to obtain.

Vulnerability scanning

Scanning gives wide, repeatable coverage. It moves quickly across many assets and reports potential problems: outdated versions, risky settings, known vulnerabilities. Without additional validation it may not show the consequences in your particular environment, and it can produce false positives. Scanning suits regular hygiene and change control well, and it is a poor answer to the question "what can an attacker really do?"

Penetration testing

A penetration test tries to confirm that a weakness is exploitable within agreed boundaries and to show the consequences. The evidence is stronger, and coverage for the same effort is narrower. Much of the value lies in chains: several medium-severity findings look harmless on their own but together open access to other users' data. It is worth remembering the limit of such evidence: one successful exploitation shows that an attack is possible under the recorded conditions, but says nothing about how often it would happen.

Verification against ASVS requirements

Verification against selected OWASP ASVS requirements answers a different question: which defined controls are supported by evidence at the agreed level of rigour? It is useful when a customer or auditor needs traceable assessment results. Each finding is tied to a requirement identifier that both sides understand the same way. Even so, such verification remains evidence rather than a certificate: it helps gather proof but does not issue a legally meaningful opinion on compliance.

Red teaming and assume breach

Adversary emulation exercises, often called red teaming, test not only prevention but also detection and response: whether the monitoring team would notice the attacker's actions and what it would do. The terminology here is not standardised, so a provider's claims need to be examined on substance: which objectives, which constraints, which success criteria, and how production systems are protected.

A separate variant is the assume breach assessment. It starts from a pre-agreed compromised state: for example, the tester holds an ordinary employee account or access to a single workstation. This saves time and lets the work focus on lateral movement and privilege escalation. But the result of such a project does not prove that the initial access could have been obtained from outside: that is an assumption, not a finding. We covered how to choose the starting point and success criteria in detail in our piece on assume breach assessments.

External attack surface assessment

If the question is "what of ours is even visible from the internet," you need attack surface discovery: finding domains, services, cloud resources and forgotten test environments. There is an important caveat. Discovering an asset does not mean permission to test it: before moving to active checks you need to confirm that it really belongs to the customer and that the customer is entitled to authorize work on it. How to build that validation and prioritise the findings is covered in the article on external attack surface assessment.

Standards as a shared language between buyer and provider

Standards in an offensive engagement are not there to make the report look weighty. They let both sides agree in advance on planned coverage; records of executed tests and their results are needed to confirm actual performance. Not every project needs the same documents, though: a web application calls for one set of reference points, an industrial network for quite another.

OWASP WSTG: a catalogue of tests

The OWASP Web Security Testing Guide is essentially a shared catalogue of tests for web applications. This article uses WSTG release 4.2 as a versioned reference without claiming the project's current status. Mapping a methodology to WSTG categories shows planned coverage and exclusions for the applicable web work; executed-test records and results confirm what was actually performed. Pin the chosen release in the contract.

OWASP ASVS: verifiable requirements with a version

ASVS was created to normalise the range of coverage and rigour in web application security verification on the market. This article uses version 5.0.0 without claiming that it remains current. The standard itself recommends referencing requirements with a version prefix, for example v5.0.0-1.2.5, because numbering may change between releases. For procurement this is a practical detail: a versioned identifier makes a finding traceable and a retest reproducible, even when a different provider performs it.

OWASP Top 10: a vocabulary for leadership

The OWASP Top 10 (the 2025 release, with 2021 and 2017 before it) is intended as an awareness document and a first step towards secure development. It is a convenient language for talking to leadership, but it is not a test plan. The phrase "test the OWASP Top 10" is much narrower and harder to verify than a scope tied to specific WSTG tests and ASVS requirements.

NIST SP 800-115: a process skeleton

SP 800-115 was published in September 2008 and superseded SP 800-42. It offers practical guidance on planning and conducting technical tests, analysing findings and developing risk mitigation strategies, and it highlights the strengths and limitations of each technique. Formally, the guide describes an assessment in three phases: planning, execution, and post-execution, which covers analysing results and making recommendations. The document does not provide a complete method for modern cloud and API scenarios, and NIST itself presents it as an overview of key elements rather than a complete testing programme. As a process skeleton, however, it remains useful.

For specialised work these documents are not enough. When assessing operational technology, for example, it makes sense to rely on sector material, including CISA's guidance for OT owners and operators on what to consider when choosing digital products, and to bring in separate qualified expertise.

Where to look first: weakness classes and their root causes

An experienced consultant does more than run through tests. They understand which classes of weakness deserve particular attention in your stack and can explain a finding through its root cause.

The MITRE CWE Top 25 for 2025 helps here, as a ranking of serious weaknesses behind published vulnerabilities. It is important to read it correctly: CWE classifies types of weakness, not the probability of exploitation in a particular system. A high place on the list does not mean you have that bug or that it will certainly be used against you. For the buyer, the list's value is elsewhere: it is a handy way to check whether a report explains root causes or only symptoms.

MITRE also publishes the related CWE Top 10 KEV Weaknesses list, which ranks weaknesses using the CISA Known Exploited Vulnerabilities catalogue, that is, vulnerabilities with recorded exploitation. It is a useful reference for prioritisation because it highlights weakness classes represented in a catalogue of vulnerabilities with confirmed exploitation. The ranking itself does not establish the exploitation likelihood of a particular system.

CISA's Secure by Design material points the same way: it includes alerts on cross-site scripting, OS command injection and directory traversal, and a joint CISA and FBI alert is devoted to buffer overflows. ASVS, for its part, contains requirements on protection against OS command injection. When a weakness class appears at MITRE, CISA and OWASP alike and is relevant to your stack, it should be named explicitly in the scope rather than left to the hope that the provider will check it by default.

The difference between a symptom and a cause is easy to show with a hypothetical example. A report says: "XSS in the search field." A developer escapes one parameter, the retest passes, and a month later the same bug turns up in the catalogue filter. A good report would have put it differently: automatic template escaping is disabled in the module, so any user-supplied string in that module is potentially dangerous. That wording leads to fixing the class, not the instance.

HTTP mechanics a consultant should explain to developers

Web testing demands confident command of HTTP, and a good report speaks to developers in that language. Individual HTTP requests do not carry memory of earlier exchanges, but applications maintain state over HTTP: a server-side session may be keyed by a cookie, while other schemes use tokens. So the tester checks how a session is issued, what it is bound to, when and how it is invalidated, and what happens to it after logout or a password change.

Two mechanisms are frequent sources of misconfiguration. Content Security Policy can restrict resource loading and, when reporting is configured, surface policy violations; it is an additional layer of defence, not a substitute for correct output encoding. CORS determines whether a script in the browser may read a response from another origin, and it is not a server-side authorization mechanism. An overly permissive CORS policy is dangerous when the browser sends usable credentials and the policy makes a sensitive response readable to a foreign site; a strict policy still does not protect an API from direct requests. Cross-Origin-Resource-Policy has a similar subtlety: it can stop a page from obtaining the body of certain no-cors responses, but it does not necessarily prevent the request itself from being sent. A consultant who confuses these mechanisms with access control will give wrong recommendations.

Trade-offs the buyer manages

Depth versus breadth

A narrow, deep test of one critical application can find chains that broad scanning misses. Broad scanning, in turn, can find forgotten assets outside the boundaries of the deep test. SP 800-115 rightly stresses the strengths and limitations of each technique: no single method gives complete confidence, and choosing between them is a management decision.

Realism versus safety

The closer testing comes to a real attacker's behaviour, the more convincing the evidence and the higher the operational risk. That risk is managed before the start: written authorization, boundaries, testing windows, emergency contacts and stop conditions. The environment is a separate question. Testing on staging is safer, but its results cannot be carried over to production without caveats: configuration, data, integrations and security controls there may differ.

Point-in-time check versus continuous confidence

A report reflects the system on the testing dates. WSTG itself notes that its versioned releases reflect the state at the time of release, and the same logic applies to test results. With frequent releases, it is more useful to plan checks around specific security-relevant changes: a new authentication mechanism, a new external integration, a change in the access model. That does not mean every commit needs its own penetration test. How to identify such changes and build checks around them is discussed in our article on change-triggered penetration testing.

Finding bugs versus removing causes

CWE presents understanding root causes as the route to eliminating whole classes of defects, such as memory safety or injection problems. Secure by Design urges manufacturers to reduce exploitable defects already at the design stage. A project that merely lists symptoms leaves the organisation with the same bugs in the next release.

Authorization, safety rules and data handling

Authorization is not a formality. Permission must come from every party entitled to approve testing of the affected assets and environments. If the application runs in the cloud, relies on third-party SaaS, a CDN or a contractor's hosting, those parties may have their own rules on acceptable testing. One executive's signature on a letter does not make an attack on someone else's infrastructure acceptable.

Before the start, record the list of assets and explicit exclusions, testing windows, emergency contacts on both sides and the conditions under which work stops immediately: service instability, for example, or signs of a real compromise. Vague answers to these questions in a proposal are a serious reason for caution.

Agree on data separately. During a test the provider may encounter personal data, secrets and tokens even when collecting them is not the objective. Sensible practice is to collect only the minimum necessary in logs and evidence, redact secrets, restrict access to the material, protect its integrity, and define the retention period and deletion procedure in advance. Nor should you assume that a "read-only" test account is automatically safe: if it can see other people's documents or configurations, that is already significant access.

If you are not yet sure which question your project should answer and which assets belong in it, this is easy to discuss with Pentest.red before any cost estimate. The page on agreeing a pentest scope describes what information about assets, environments and constraints is worth preparing for that conversation.

Turning findings into operational change

The NIST Cybersecurity Framework 2.0 is meant to help organisations understand and improve their management of cybersecurity risk; it includes profiles, quick-start guides and informative references. Offensive findings become more useful when expressed as gaps against target outcomes in your CSF profile: a technical fact then becomes a management decision with a specific owner.

It is sensible to set remediation priority not only by severity label but also by exploitability and external exposure. A medium-severity vulnerability in a public API may need attention before a critical finding on an isolated internal test environment. Mapping to the CWE Top 10 KEV Weaknesses and CISA guidance is one prioritisation input alongside potential impact, existing controls and applicable obligations.

Some findings point not to a configuration error but to a product decision. Secure by Design material urges manufacturers to make basic security features such as multi-factor authentication and logging available by default rather than as a paid extra. If a test reveals gaps precisely here, the product team, not just the administrators, should fix them.

The retest closes the loop. Versioned ASVS identifiers and references to WSTG tests let the same or a different provider check a fix against the same criterion. ASVS requirement lists are published in machine-readable formats, including CSV and JSON, so coverage is easy to track in your own tools. Bear in mind that a retest's conclusion applies only to the stated scope and conditions: fixing one endpoint does not prove its neighbours are protected. More on proving that fixes actually work is in the article on penetration test remediation validation.

If a provider offers AI-assisted analysis or reporting, scrutinise it as rigorously as any other method: how humans double-check the conclusions, where customer data goes and who has access to it.

Choosing a provider: checking methodology and reports

Since ASVS was created to even out uneven coverage and rigour on the market, the first procurement check is methodological transparency. Ask to see how the methodology maps to WSTG categories for web work, to ASVS requirements where selected application controls need verification, and to a process that includes planning, execution, analysis of results and development of mitigations.

Second, the report. A strong report identifies the affected assets, describes safe reproduction, explains the consequences, names the CWE weakness class, references versioned requirements and gives recommendations a developer can carry out. Website descriptions are not enough: ask for a redacted sample.

Third, authorization and safety, discussed above. Fourth, use existing buyer guidance. CISA publishes Secure by Demand guidance for software customers negotiating with suppliers, and a separate guide for OT owners and operators. They help you ask every supplier the same questions. A more detailed scheme for comparing proposals is in our article on penetration testing vendor comparison.

A few questions quickly separate a mature provider:

• Which WSTG categories and versioned ASVS requirements are in scope, and which are excluded?
• How do you map findings to CWE classes, and what do you write about the root cause?
• What authorization, stop conditions and emergency contacts do you require before starting, and from whom?
• Is a retest included, and will its results reference the same identifiers?
• Can you show a redacted sample report and deliver results in machine-readable form?
• Who exactly does the work, and how is report quality checked before delivery?

A working cycle from question to retest

The formal phases of SP 800-115, planning, execution and post-execution, describe the assessment process itself. The buyer benefits from adding a practical cycle that starts before the test and ends after it. This is not a requirement of the standard but the author's working scheme.

1. Frame the questionDecide what evidence you need: discovery, coverage, evidence against selected controls or resilience to attack
2. Set boundaries and authorizationRecord assets, exclusions, windows, data handling, stop conditions and permission from every party empowered to approve the testing
3. Run the testingPerform the agreed checks and record the conditions under which each finding was confirmed
4. Analyse root causesWhere applicable, map findings to CWE and web/API requirements; assign remediation owners
5. RetestRepeat the original scenario and relevant variants or justify an equivalent check; state the limits of the conclusion

The first step matters more than it seems. A project with a vague question risks ending in a report nobody can act on. The second step pins down the set of reference points: for a web application, a WSTG release and versioned ASVS requirements; for talking to leadership, the OWASP Top 10; for prioritisation, the CWE Top 25 and Top 10 KEV; for linking to governance, a CSF 2.0 profile. For other types of system the set will be different.

After the test, every finding should reach a specific team with a deadline that reflects risk, operating conditions and applicable regulatory or contractual obligations. Successive reports are worth comparing by the same requirement identifiers, so you can see whether entire weakness classes disappear rather than just individual instances. That is exactly the outcome both CWE and Secure by Design push towards.

If you want to run this cycle with an external team, the terms can be discussed with Pentest.red: the description of penetration testing services will help you understand the format of the work, while the specific scope, acceptance criteria and retest are best agreed for your system. Tasks beyond an ordinary penetration test, such as legal certification or assessment of industrial processes, require separate qualified expertise.

What makes offensive security consulting useful

Offensive security consulting is useful when it is authorized by everyone entitled to approve it, rests on reference points both sides understand, and is tied to removing root causes. OWASP provides a test catalogue and verifiable requirements, NIST SP 800-115 a process skeleton, CWE a language of weakness classes, and CISA shifts responsibility towards secure design and informed procurement.

Back to the three proposals from the opening. Choose not by the broadest promise but by which one answers your question, shows its methodology, ties findings to versioned requirements, explains causes and includes a retest with clear limits on its conclusion. That approach turns a one-off report into traceable evidence for verifying fixes and tracking weakness classes across releases; the report itself does not guarantee a reduction in risk.