Okay, let's review the statement of work.
The statement of work is typically made well after the requirements
and scope of the pen test have been established.
This document serves as a blueprint for the activities that the
pen tester will take to achieve the project goals and can
include time and pricing information.
A quote would serve as a high‑level statement of work,
while this document provides the specifics of the tests
to be conducted and their timing.
The details of the SOW include a project description
outlining the client's requirements and how they will be
achieved via the tasks represented.
This will typically include the scope and,
at least at a high level, may list out IPs,
systems, or applications.
For example,
if you're quoting that you'll do five days of black box
pen testing against an application, it makes sense to list out its name and URL.
Next, we outline the specifics of the tasks to be formed.
This should be the hours or days of effort followed by what you'll be doing.
This section can be done in phases in case you're doing an
engagement that will take some time and the client wants to
have some deliverables along the way.
The deliverables are outlined as well.
And I would recommend acceptance criteria, which is typically left out.
The reason why you want to include it is because at the end
of the test you may say that you're done,
but your client may have a different view and require you to do more.
Having a clear indication of what complete means here is a good
way to ensure that everyone's on the same page.
Financials are next, which include the summary of hours or days,
dollars for the different types of attacks,
and the time frame in which this test will be done.
Don't leave the test open ended.
For example,
I've had people ask if I could work on a test until I find something,
and the answer is no.
You have a fixed amount of time to do the work.
Should you uncover a possible attack vector at the end of your time frame,
you can always let the client know and see if they want to pursue it further.
Lastly, and again reiterate disclaimers,
and responsibility,
crashing a server or deleting production data are
things that can happen during a test.
Ensure that you're protected and that the client
understands this and has a plan for recovery.