Scoping a penetration test: rules of engagement and deliverables

Reference article · 5 min read

A penetration test is an authorized, time-boxed attempt to reach systems or data the way an attacker would, followed by a written account of what worked. It is not a vulnerability scan, though scanning usually comes first. The report is the product, and its usefulness is set by the scope and rules written beforehand.

Most agencies arrive here because something outside IT asked for it: a grant condition, an insurance application, a council directive, or a rule tied to regulated data. The trigger determines what the report must demonstrate and who reads it, so write it down and build the statement of work around it.

The engagements agencies buy

External network test. Internet-facing addresses and services: firewalls, VPN portals, mail gateways, public web servers. The usual first engagement, and the easiest to scope.
Internal network test. Testing from inside, simulating a contractor or a compromised workstation. Covers privilege escalation, lateral movement, directory weaknesses, and segmentation between office, control, and public safety networks.
Web application test. One application at a time, including authenticated testing as each user role. A permit portal with three roles is a different engagement from a brochure website.
Social engineering. Phishing, voice pretexting, or both, measured by who clicks, who submits credentials, and whether anyone reports it.
Physical. Attempts to enter facilities, reach network jacks or server rooms, or clone badges. Often paired with social engineering.
Red team exercise. Tests detection and response rather than cataloging vulnerabilities. A separate purchase.

Writing a scope a firm can price

Vendors price from counts, so supply them: external hosts, internal subnet sizes and site counts, applications with their user roles, whether testing is authenticated, employee counts for phishing, and addresses for physical work. Say whether testing runs against production or a staging copy. "Test our network" produces bids that cannot be compared, and a change order later.

Rules of engagement

Include the rules of engagement in the solicitation as a draft exhibit.

Authorization. A signed authorization from an official with authority over the systems, naming the firm, the scope, and the dates. Unauthorized computer access is a crime under state and federal law, so this document protects both parties and should be carried during physical testing.
Testing windows. Business hours, after hours, or both, plus blackout periods such as elections, tax deadlines, payroll runs, and budget close.
Out of bounds systems. Name them: dispatch and 911, life safety systems, industrial control devices, and legacy servers that may not survive a scan. Excluding a system is a legitimate decision. Leaving it unstated is not.
Stop conditions. When the tester must stop and call, who answers overnight, and how a suspected outage is reported.
Techniques and data. Denial of service and destructive actions prohibited unless allowed in writing, and a stated method for storing and destroying any personal information found.
Who knows. Whether IT staff and monitoring vendors are told in advance. Unannounced testing measures detection, but someone must be able to confirm the activity is authorized.

Social engineering needs more: advance approval of pretexts, no impersonation of a named individual or another agency, notice to human resources and any bargaining unit, and agreement that results are not used for discipline.

Systems the agency does not fully control

Major cloud providers publish policies stating what testing customers may run against their own resources and what still requires notice or approval. Those policies change, so require the vendor to confirm current terms in writing before testing begins. Hosted applications usually cannot be tested without the provider's permission, and the same holds for shared infrastructure at a county or state data center.

Deliverables and the required retest

Require an executive summary in plain language, a methodology section, and a separate finding for each issue with a severity rating, affected assets, reproduction steps, evidence, and specific remediation guidance. Also require a narrative showing how access was chained together, a machine-readable finding list that can feed a corrective action plan, an attestation that accounts and tools created during testing were removed, and briefings for technical staff and leadership. Name the scoring method so ratings compare year over year.

Then require a retest. Price it in the base award, set the window in which the agency may request it after reporting remediation, limit it to previously reported findings, and require a short report marking each finding fixed, partially fixed, or open. Without a retest, the agency owns a list rather than an outcome.

The finished report and public records law

Assume the report will be requested. Most states exempt records that would jeopardize the security of information systems or public facilities, but the wording and breadth vary. Confirm with counsel before the report exists rather than after a request arrives. Make the report the agency's record by contract, ask for a summary that can be shared with the governing body, and keep exploit detail and raw evidence in separate files.

What to ask vendors, and what to require

Provide a redacted sample report from a comparable engagement.
Identify the individuals who will perform the work and their qualifications.
Explain how findings are validated so false positives stay out of the report.
State where testing data and drafts are stored, who may access them, and how they are destroyed.
Confirm screening for staff who may encounter regulated data, and name subcontractors.

Carry into the contract: confidentiality, certified data destruction, notification if testing causes an outage, agency ownership of the report, no use of the agency name in marketing, and the rules of engagement as an exhibit. Program requirements change, so confirm current obligations with the official source or counsel.

HQT provides cybersecurity services to state and local government agencies, including security testing support and remediation planning.

Frequently asked questions

What is the difference between a vulnerability scan and a penetration test?

A vulnerability scan is largely automated and reports conditions that may be exploitable, usually as a long list with severity labels. A penetration test uses those results as a starting point and has a human attempt to exploit and chain weaknesses to reach something that matters, then documents the path. If a grant, insurer, or auditor asks for a penetration test, a scan report will usually not satisfy it, so read the underlying requirement closely before writing the scope.

How often should an agency have a penetration test performed?

The answer usually comes from whatever created the requirement rather than from a general rule. Some frameworks and card data requirements call for testing at a set interval and after significant changes to the environment, while grant conditions and insurance applications state their own expectations. Many agencies settle on a regular external test plus additional testing when a major system or network change goes live. Confirm the interval with the official source for the program that applies to you.

Is a penetration test report a public record?

It is a record of the agency, so it falls under the state public records act unless an exemption applies. Most states have an exemption for records that would jeopardize the security of information systems or public facilities, but the scope and wording differ, and some exemptions cover only portions of a document. Talk to counsel before the report is written, and structure the deliverables so that a shareable summary exists separately from exploit detail and raw evidence.

Do we need to notify our cloud provider before testing?

Major cloud providers publish policies describing what customer testing is allowed against the customer's own resources and what still requires notice or approval, and those policies are revised over time. Software as a service applications are different, because the agency does not own the environment and generally cannot authorize testing of it. Require the selected vendor to confirm the current terms in writing and to document any notice or approval before testing begins.

Should the retest be included in the original contract?

Yes. Buying the retest separately after remediation usually means a new requisition, new pricing, and a delay that outlasts the memory of the original engagement. Write the retest into the base award with a defined request window, a limit to previously reported findings, and a short report marking each finding fixed, partially fixed, or open.