What Should a Security Consulting SOW Include?

A security consulting statement of work should pin down seven things before anyone signs: in-scope systems with explicit exclusions, the named individuals doing the work, deliverables with format and acceptance criteria, a timeline with milestones and dependencies, the methodology by name, the pricing model with the specific events that trigger a change order, and retesting or revision terms. The test fits in one sentence. If the statement of work cannot say exactly what you receive and who produces it, you are not buying a defined outcome, you are buying hours. This walks each section with the language to ask for and the omission that costs buyers money.

It applies across engagement types. A readiness project, a virtual CISO retainer, and a penetration test have different content in these sections, but all seven sections belong in all three.

Key takeaways

• Seven sections belong in every security consulting SOW: scope with exclusions, named individuals, deliverables with format and acceptance criteria, a timeline with milestones and dependencies, the methodology by name, the pricing model with change-order triggers, and retest or revision terms.
• The test fits in one sentence. If the SOW cannot say exactly what you receive and who produces it, you are buying hours rather than a defined outcome.
• Scope is where change orders come from. A dispute about whether a subsidiary was included is a dispute about the sentence nobody wrote.
• Acceptance criteria are the part almost nobody asks for and everybody needs. Without one, "the report is finished" is the vendor's opinion.
• Name your own dependencies too. Most engagements that slip, slip because a client dependency was late, and a SOW that never named it turns that into an argument instead of a schedule.

1. Scope, with exclusions written down

The scope section should name the systems, environments, entities, and locations in play, and it should be specific enough that a stranger could tell whether something is in or out.

For a penetration test, that means targets: applications, URLs or IP ranges, user roles, APIs, whether testing is authenticated, and whether production or a staging environment is in play. For a compliance engagement, it means legal entities, product lines, the criteria or controls in scope, and the systems that support them.

Then the part most proposals omit. Ask for an explicit exclusions list. Every honest scope has one, and its absence is either an oversight or a deliberate ambiguity. Exclusions worth naming: engineering remediation, third-party systems you do not control, physical and social engineering testing, evidence collection during an observation window, subsidiary entities, and the audit or assessment itself.

The reason to insist is that scope is where change orders come from. A dispute about whether a subsidiary was included is a dispute about the sentence that was never written.

2. Named individuals

The statement of work should name the people who will deliver, with their role, and ideally with a stated proportion of the work. If a firm is unwilling to commit names contractually, it is reserving the right to staff the engagement with whoever is free at the time.

Two things to ask for alongside the names: a named alternate, so a holiday is not a crisis, and a notice commitment if the assigned practitioner changes. Neither is unusual, and both take one sentence each.

This is the section that most predicts whether the deliverable will need rewriting.

3. Deliverables, with format and acceptance criteria

A deliverable list should say what you receive, in what format, and how you both know it is done.

Format matters more than it sounds. A policy set delivered as editable documents you own is a different asset from a policy set that lives in a portal you lose at renewal. A test report delivered as a PDF plus a machine-readable findings list is more useful than a PDF alone. An attestation letter for customer distribution should be named separately from the technical report, because they serve different audiences.

Acceptance criteria are the part almost nobody asks for and everybody needs. Something as simple as "findings are accepted when each carries a severity, an affected asset, reproduction steps, and a recommended remediation" gives you a definition of done. Without one, "the report is finished" is the vendor's opinion.

4. Timeline, milestones, and the dependencies on you

A schedule with a single end date is a wish. What you want is milestones: kickoff, scoping sign-off, fieldwork window, draft delivery, review period, final delivery, and retest window where applicable.

Just as important, the SOW should state what the firm needs from you and by when: environment access, credentials, a point of contact with authority, evidence, and interview availability. Most security engagements that slip, slip because a client dependency was late, and a SOW that never named the dependency turns that into an argument. Naming it turns it into a schedule.

5. The methodology, by name

The methodology section should reference something written down by someone else.

For technical testing, that means naming the OWASP Web Security Testing Guide for web applications, the Penetration Testing Execution Standard for engagement structure, or NIST SP 800-115 for technical assessment planning and execution. For compliance work, it means the framework and its assessment guidance: the trust services criteria for SOC 2, Annex A and the ISMS clauses for ISO 27001, NIST SP 800-171A objectives for CMMC Level 2.

A named methodology gives you three things: a shared vocabulary, a way to check the deliverable against an external standard, and a defense when a customer or auditor asks how the work was done. "Our proprietary methodology" gives you none of them.

For testing specifically, ask the SOW to state the balance of manual testing to automated scanning. That single sentence is the most reliable written distinction between a penetration test and a scan with a cover page, and penetration test versus vulnerability scan explains why the distinction survives into what your auditor will accept.

6. Pricing model, and what triggers a change order

Fixed fee, time and materials, and retainer are all legitimate. What matters is that the model is stated and that the boundary is drawn.

For fixed fee, list the change-order triggers explicitly: added systems or entities, added criteria or controls, scope discovered during fieldwork, re-scheduling caused by access delays, and out-of-hours work. For time and materials, state the estimate, the notification threshold at which you are told the estimate will be exceeded, and whether there is a cap. For a retainer, state what is included per period, whether unused time carries forward, and what the escalation rate is for surge work.

Also make expenses explicit: travel, tooling, subscriptions, and any project-management uplift. These are ordinary costs and unremarkable when disclosed. They become a problem only when they arrive after signature.

7. Retesting and revision terms

For testing engagements, the retest question is the single most common source of surprise cost. Ask three things: is one retest round included, how long is the window after final delivery, and what is the scope of the retest, meaning the fixed findings only or the full original scope.

For compliance engagements, the equivalent is revision terms: how many review cycles on a deliverable are included, and what happens if your auditor asks for changes to a document the firm produced. A firm that will not revise a policy its own draft caused an auditor to reject has moved a cost onto you quietly.

While you are there, ask what happens to your data at the end: retention period, deletion commitment, and whether findings are used in anonymized form. That is a two-line clause and worth having.

When a lighter document is the right answer

Not every engagement deserves a fifteen-page SOW.

A two-day advisory review or a single workshop can reasonably be a one-page order that names the person, the date, the output, and the fee. Insisting on a full instrument for small work adds cost without reducing risk, and firms that produce a heavy document for a two-day job are often charging you for the document.

The threshold we use is simple: if the work has a deliverable someone else will rely on, or if it runs long enough for the staffing to change, it needs all seven sections. Below that, name the person, the output, and the price.

Where Top Floor fits

Our statements of work carry all seven sections, including the exclusions list and the named practitioners, because the alternative is a change-order conversation we would rather not have either. Our penetration testing SOWs state the manual-to-automated balance and the retest window, and our compliance as a service and virtual CISO documents state what is included per period and what is not.

If you are reviewing someone else's SOW and want a second read, that is a short conversation rather than an engagement, and we would rather you sign a good document than a vague one.

How to decide this week

Take the SOW in front of you and check it against the seven sections. Mark the missing ones.

Then send the firm one email asking for the three that most reliably go missing: the exclusions list, the named individuals, and the acceptance criteria for each deliverable.

If the answer to any of the three is that they will be agreed later, treat later as never. Those three are agreed before signature or they are agreed from a weak position.

Frequently asked questions

What should a penetration testing SOW include?

The seven core sections plus four testing-specific ones: the exact targets, meaning applications, URLs or IP ranges, APIs, and user roles; whether testing is authenticated and against production or staging; the stated balance of manual testing to automated scanning; and the retest terms, meaning whether a retest round is included, the window after final delivery, and whether it covers only the fixed findings. Naming a methodology such as the OWASP Web Security Testing Guide or NIST SP 800-115 gives you something external to check the deliverable against.

What are acceptance criteria in a consulting SOW?

They are the written conditions under which a deliverable is considered complete, and they convert "the report is finished" from an opinion into a test. A workable example for a test report is that each finding carries a severity rating, the affected asset, reproduction steps, and a recommended remediation. For a compliance deliverable it might be that every in-scope control has an implementation description, an owner, and a named evidence source. Without acceptance criteria you have no defined point at which the work is done.

Should a statement of work name the individual consultants?

Yes, and it is reasonable to insist. What you receive is produced by specific people, and a document that commits only to a qualified team allows the firm to staff you with whoever is available. Ask for the named practitioners, a named alternate, and a notice commitment if the assignment changes. A firm with genuine depth will offer all three without friction.

What triggers a change order in a fixed-fee security engagement?

The triggers should be listed in the SOW rather than left to interpretation. The usual set is added systems, environments, or legal entities; added criteria or controls; scope discovered during fieldwork that was not visible at proposal; delays caused by access or evidence availability; and out-of-hours or on-site work not originally planned. A fixed fee with no enumerated triggers is a starting price, because every addition becomes a negotiation after you have committed.