As the title says, in the rules of engagement I have my scope, used method, etc. but I've been wondering if I should also include a list of tools (such as NMAP, Dirb/Ffuf, etc.) that might be used.

And if not, how should I be transparent with the client about the way I'm going to perform the pentest?

My concern is that management will not understand the tools I'd like including in the RoE, even with a small description trying to explain the purpose of the tool.

2 Answers 2


You should explain your methodology, but a full list of tools usually isn't included for several reasons:

  • You don't actually know all the tools that you're going to use before you've finished testing.
  • Most clients don't really care and won't read it anyway.
  • Some tools have names that are not very professional, which doesn't look great in a formal document.
  • No one cares that you use "Notepad" or "Google Chrome", so adding things like that is a waste of time.
  • It perpetuates the idea that pentesting is just running a load of tools against the target.

Management don't need to know and understand all of the tools. When they get a builder in to build them a new office, they don't ask for a list of every tool that they're going to use. They hire a professional, and leave those decisions up to them.

If the client asks, you can give them a list at the end of the engagement (or an indicative list before you start). But it's not something I would do as standard.

  • 2
    "Most clients don't really care and won't read it anyway." That's not really an argument in my opinion. Commented Sep 20, 2022 at 8:13
  • 10
    @infinitezero It means the list has no value to the client. Isn't creating value for the client the point? Commented Sep 21, 2022 at 12:31
  • 1
    @infinitezero goes to standard practice. Doesn't mean you wont get that one guy who wants it. Commented Sep 21, 2022 at 16:51

There is no rule, but in addition to the executive summary you will normally submit a more technical report with your findings.

The executives usually don't have a clue about tech, but there is usually an IT team, who will look at your report too, and assess the results. Quite probably they will take part in remediation of the flaws, possibly with assistance of the pentesters. So they deserve some insight. In fact there may even be a fully-fledged network security team on site. If you defeat their defenses, they will want to know the details, and they should get them.

I personally like to provide technical appendices, that includes not only the tools used, but sometimes, the exact commands that were typed. You can easily record the output of a terminal session (for example using GNU screen) and then do copy-paste into your report.

What's the point? The point is to provide commands or attack scenarios that can be reproduced by the technical team later, in order to verify that the flaws have indeed been patched. And it's something they could run anytime, for example after making configuration changes or adding infrastructure components.

Even a simple nmap command is useful and worth quoting, if it's been instrumental in locating a vulnerable endpoint. No need to quote every tool you know or you've used, but rather quote the tools that actually helped you during that assignment.

If you find a flaw, you've done a good job, congratulations. But if you explain the methodology this is even better because the readers are going to learn a thing or two, and perhaps they will be able to incorporate the methodology in their own business process.

As the saying goes, don't just give a man fish - teach him how to fish (or phish).

  • 3
    I'm assuming your technical appendices only include the tools that were successful, not the ones that didn't get you anywhere?
    – Mast
    Commented Sep 19, 2022 at 18:02

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .