The necessary ones make the site work. The others measure which pages help and which ads bring the people who need DM11. Your choice, and you can revisit it from the footer.
PENETRATION TESTING
A penetration test is an authorised, agreed attack against your systems, carried out by someone who does it professionally. It does not hand back a list of possible flaws: it hands back a demonstration of what an intruder could actually do, with the path taken, evidence at each step, and what held. It is the difference between knowing a door might be unlocked and watching someone walk through it.
No test starts without formal authorisation, a written scope and signed rules of engagement. That is not paperwork: it is what separates a penetration test from unauthorised access, and what protects both sides when something goes off script. DM11 runs the work with PTES phases declared in the contract, application coverage from OWASP, and the path described in MITRE ATT&CK terms.
Who runs the test
CEH, Certified Ethical Hacker from EC-Council
CPTE, penetration testing engineering from AcadiTI
SYCP and SYWP, penetration testing and web application testing from Solyd
17 years of governance, risk and compliance
WHAT IT IS
A penetration test is run by a person with tools helping, not by a tool with a person watching. That order explains almost everything that follows: the price, the timeline, what the report can assert, and why two proposals with the same name deliver work that cannot be compared. What you buy is the skill of someone who chains small flaws together until they reach something that matters, not the number of findings.
A vulnerability scan finds and lists known flaws, broadly and mostly automatically, and it is routine work that should run all year. A penetration test confirms what can actually be exploited and measures how far someone could get after the first door. If the report you received runs to dozens of pages of colour-coded findings with not one sentence about what anyone managed to do with them, you bought a penetration test and received a scan under another name. The two complement each other, and the full comparison lives on the pentest versus vulnerability assessment page.
Without formal authorisation from whoever owns the asset, the same set of actions is unauthorised access. So the work begins with a document defining what is in scope, what is out, who authorises it, in which window, with what stop criterion, and who gets called if something goes off script. Where third parties sit in the path, a cloud provider, an access provider or the firm running your security, how each one is handled is written down before the first packet.
DM11 uses PTES for the execution structure, from pre-engagement to reporting, OWASP for application coverage with the Top 10 and ASVS, and MITRE ATT&CK to name the path taken. The three solve different problems and none replaces another. One practical effect is that your infrastructure team can check afterwards whether detection would have seen that path, which turns the report into an input for improvement rather than only an audit document.
There is no penetration testing certificate, here or anywhere, and be wary of anyone offering one. What exists is a report in two layers, an executive summary for the board and a technical report with evidence, reproduction steps and remediation per finding, plus the record of the retest of whatever was fixed. That set is what goes to the audit, to the customer who asked, and to the regulator. When someone needs a document issued by an accredited third party, ISO 27001 or SOC 2 answers that, and this report goes into those audits in full as evidence.
WHEN IT MAKES SENSE
In two of them the requirement arrives from outside, with a deadline. In the third it comes from inside, and that is usually the one that produces the most useful result.
PCI DSS requires a documented methodology and an annual test from anyone processing card data. Brazil's central bank cybersecurity resolutions require a penetration test at least annually, carried out with independence and impartiality by a specialist engaged for that purpose. Large customers in due diligence and certification audits ask for the same thing in another format. In those cases the report leaves your company and will be read by someone who was not there.
A new application exposing customer data, a cloud migration, an integration that gave a partner access to your environment, a merger that joined two networks nobody knows in full. Here the value is not in finding many flaws, it is in discovering early which new path was opened by a change everybody approved while looking at something else.
The least common reason and usually the most rewarding. After buying endpoint protection, email filtering and monitoring, the only way to know what they stop is for someone to try to get past them. The conversation changes when the report shows what the defences blocked, what they merely logged and what they ignored, because the next investment decision is then made on data rather than on a vendor brochure.
TRANSLATING THE ASK
Counting addresses does not describe effort. These are the four ways the ask usually arrives, with what each one means and what genuinely changes the size of the work.
| What they asked for | What that actually means | What changes the size |
|---|---|---|
| We need a penetration test of our infrastructure | A test of what is exposed and what sits behind it, with exploitation and post-exploitation. It is the format that answers regulatory requirements and due diligence. | How many genuinely different services exist, not how many addresses. A large range of repeated services moves fast; a heterogeneous environment does not. |
| We want our application tested | An application test with OWASP coverage, including business logic and access control between user roles, which is where the expensive flaws usually sit. | The number of user roles, business logic complexity, third-party integrations, and whether documentation or source code is available. |
| A customer asked for evidence of an annual test | What a third party will read is the report. It needs scope, method, dates, the qualifications of whoever ran it, findings with evidence, and proof of the retest. | The scope the requester accepts, which is rarely the whole environment, and whether the retest must be complete within the same cycle. |
| We want to know whether our defences work | The focus moves from the list of flaws to detection coverage: what the defences blocked, what they only logged, and what got through without a trace. | Whether there will be a window with blocking active, a window with the tester allowed through in a controlled way, or both, which is what separates good news from useful news. |
The scoping conversation happens before the proposal, and DM11 helps write that requirement even when the work is going out to the wider market. It lets you compare suppliers on work rather than on price.
STORIES
We change our customers' names with the same confidentiality that will protect your company later. The names change, the pattern of the problems repeats. Where a customer authorises it, we share named references in a conversation.
Digital platform
The request arrived as a web application test, with a screen count in the proposal. The application had several user roles, including an administrative role used by external partners, and no previous test had looked at what one role could do with another's identifier. As written, the scope obliged nobody to look at that.
We rewrote the scoping requirement before the proposal, swapping a screen count for a matrix of roles: what each one should be able to see, and what should be refused. Coverage followed OWASP with each requirement verified item by item, and exploitation continued into post-exploitation to measure the reach from each role.
The most serious flaws were not in the screens the request listed, they were on the boundary between two roles, which no screen count would ever have reached. Scope written that way became the template for the company's later engagements.
Retail
After moving part of the environment to the cloud, the company kept its scanning routine and considered the matter closed. The migration had been approved on architecture, on cost and on availability. Nobody had asked what became reachable from outside that had not been before, because that question belonged to none of those three approvals.
We agreed the handling of the cloud provider and the window in the rules of engagement, which is the part that most delays this kind of test. Reconnaissance started from what was exposed after the migration, and the attack hypotheses were tied to what the business could not afford to lose rather than to what was easiest to test.
The path we found started at a service that had existed all along and that the migration had begun to expose. The fix was a configuration change and came quickly; what stayed was the process change, with testing becoming a migration trigger rather than a loose annual item on the calendar.
B2B services
The requirement came in the contract: an annual penetration test, with evidence. The company priced the whole environment, the figure alarmed everyone, and the discussion turned into a negotiation about discount. Nobody had asked the customer which scope they accepted, and the assumption was that they wanted everything.
We helped write the missing question and put it to the customer in writing, alongside what the report would contain: scope, method, dates, the qualifications of whoever runs it, findings with evidence and proof of the retest. With the answer in hand, the scope was designed around what the requester actually reads, and the retest went into the same cycle instead of being left for later.
The work ended up the size of the real requirement rather than the size of the fear. And from the first cycle the company had the document the customer asked for, with the retest completed within the contract deadline.
HOW WE RUN IT
Each phase ends in something you can verify without taking our word for it. That is the point of a declared method: a report another professional can audit is worth more than one only its author understands.
The phase buyers most often skip and the one that most protects both sides. It records what is in and out of scope, the approach, the windows, the immediate stop criterion, how third parties such as cloud and access providers are handled, and whether any test that could affect availability is authorised. Formal authorisation and emergency contacts are recorded before the first packet.
A written scope, with what is in and what is out
Rules of engagement, windows and stop criterion
Formal authorisation to test, and emergency contacts
Agreed handling for cloud, access providers and other third parties
Delivery milestoneScope and authorisation signed, with no scope question left open.
We map what exists and what the world already knows about your company, and turn that into attack hypotheses tied to what your business cannot afford to lose. Without this phase the test becomes a hunt for isolated flaws, and the result is an unprioritised list nobody knows how to use. The hypotheses are validated with your team before any exploitation.
The attack surface mapped, separating exposed from internal
Public information about the company, where it is in scope
Attack hypotheses tied to what the business cannot afford to lose
Prioritised targets, agreed with you before exploitation
Delivery milestoneHypotheses validated with your team, with priority agreed in writing.
We confirm in practice what can actually be exploited, which is the difference between suspicion and fact, and then measure how far someone could get after the first door. Post-exploitation is the phase most often missing from cheaper proposals and the one that most changes investment decisions. In applications, coverage follows OWASP with the Top 10 and ASVS. Critical findings are reported the same day, without waiting for the report.
Confirmation through exploitation, with evidence of what was obtained
Real reach demonstrated, with the chained path
Application coverage from OWASP, with each requirement verified item by item
Immediate notification of critical findings, with initial recommendations
Delivery milestoneA critical flaw is reported the same day it is confirmed.
The report comes in the two layers PTES itself defines, an executive summary and a technical report, with the path described in MITRE ATT&CK terms so your team can check detection and not only remediation. Once fixes are in, we retest what was corrected and record the outcome, which is the document audits usually ask for alongside the report.
An executive summary for the board, without jargon
A technical report with evidence, reproduction and remediation per finding
The path taken, named by MITRE ATT&CK tactic and technique
A retest of what was fixed, with the outcome recorded
Delivery milestoneEvery finding closed or accepted in writing, with the retest on record.
HOW LONG IT TAKES
We do not publish a standard timeline, because a published timeline becomes a promise and penetration testing scope varies widely. The first conversation already shows which of these factors your company is in, and it is what produces the scoping requirement.
A large range of repeated services moves quickly. A single application with many user roles, complex business logic and third-party integrations consumes far more. The scoping conversation separates those two cases, and it happens before the proposal.
With no information, much of the time goes into reconnaissance, and the result resembles what an external attacker would face. With access to documentation or source code, the same time is spent looking for flaws rather than looking for doors. Both choices are legitimate, they deliver different things, and the decision is recorded in the scope.
An environment that can only be tested outside business hours, a system with a seasonal peak, authorisation pending from a cloud provider and advance notice to a managed security provider move the calendar more than the technical work does. That conversation starts early, because it is usually the longest part of the whole project.
FREQUENTLY ASKED
The questions that come up in almost every first meeting, answered without hedging.
A vulnerability assessment is broad and mostly automated: it finds and lists known flaws by severity, and it works as year-round routine. A penetration test is deep and mostly manual: a specialist tries to exploit the flaws to prove what an attacker could do, and measures how far they could get after the first door. One answers what might be wrong; the other answers what can actually be done. They complement each other, and several requirements ask for both: PCI DSS, for example, requires quarterly scanning and an annual test.
You do, and we do not start without it. Without formal authorisation from whoever owns the asset, the same set of actions stops being a test and becomes unauthorised access. The document defines what is in and out of scope, who authorises it, the execution window, the immediate stop criterion, whether any test affecting availability is permitted, and who gets called if something goes off script. Where third parties sit in the path, such as a cloud provider, an access provider or the firm running your security, how each is handled is also written down beforehand.
It could, if nobody agrees the rules beforehand, and that is exactly why the first phase exists. The rules of engagement record whether any test affecting availability is authorised, which systems are out of scope, in which window the work happens, who gets called if something goes off script, and the immediate stop criterion. With that on record, the risk of an outage stops being luck and becomes your decision, made with information and before anything starts.
There is not, neither for your company nor for the report, and it is worth being wary of anyone offering one. What exists is the report with a declared method, and it is the people running the test who hold certifications, such as CEH, CPTE and Solyd's penetration testing tracks. When your customer or your auditor needs a document issued by an accredited third party, ISO 27001 or SOC 2 answers that, and the test report goes into those audits in full as evidence.
It is, and it is a contractual deliverable rather than a courtesy. Once your team has made the fixes, we retest what was corrected and record the outcome per finding, closed or accepted in writing. That record is asked for by auditors as often as the report itself, because it is what shows the list did not sit still. If your remediation timeline is long, that goes into the scope from the start rather than becoming a discussion later.
Ask each supplier to declare, phase by phase, what will be done. Five questions separate almost everything: which phases are included, whether post-exploitation is part of the work or it ends at confirming the flaw, whether there is a retest and within what timeframe, who runs it and with what qualifications, and exactly what the report will contain. Where a proposal says only a penetration test of a number of addresses, there is nothing to compare, and the price difference will stay unexplained. DM11 helps write that requirement even when your company is taking the work to the wider market.
It depends on who is asking and on what changes in your environment. PCI DSS requires an annual test from anyone processing card data, and Brazil's central bank cybersecurity resolutions require at least an annual test with independence from whoever runs it. Outside a formal requirement, the practical rule is annually, plus a test whenever something material changes: a new exposed application, an environment migration, an integration that opened access to a partner. Between tests, what covers the year is vulnerability management, which is routine work and does not replace the test.
We do, and it is a different scope rather than an extension of a traditional test. An AI system is attacked through routes an ordinary application does not have: manipulating the input to change the model's behaviour, extracting what it learned, poisoning the data that feeds it. The reference that catalogues those techniques is MITRE ATLAS, not ATT&CK. If your case involves a model in production in front of customers, the conversation starts there and usually comes alongside AI governance.
A short conversation already produces the phase-by-phase requirement your company can take to the market. It lets you compare suppliers properly, and it lets you engage us knowing exactly what you get at each step.
Comparisons on this subject
See all 13 comparisonsPTES · versão 1.0; a edição mais recente do wiki é de dezembro de 2015 · accessed on
OWASP Foundation · edição 2025, primeira revisão desde 2021 · accessed on
OWASP Foundation · ASVS 5.0 · accessed on
The MITRE Corporation · v19.1, publicada em 28/04/2026 · accessed on
This page is informational and describes how DM11 reads and applies the sources above. It does not reproduce the text of any standard, does not replace reading the official document, and does not replace an audit, a certification, an independent assessment or legal advice. Where a standard requires formal assessment, it is carried out by an accredited body, auditor or assessor, always separate from whoever did the preparation.