A penetration test begins with authorization, not with scanning. Rules of engagement define what may be tested, when testing may occur, which techniques are prohibited or restricted, how sensitive data must be handled, who can approve changes, and what conditions require the test to stop. That governance is central to CompTIA PenTest+ PT0-003, which remains the current PenTest+ exam series in 2026.
Good rules of engagement protect both the organization and the testers. They turn a broad statement such as “test our environment” into an executable contract that separates approved security assessment from unauthorized activity. They also reduce operational risk by defining escalation paths before a test triggers an outage, affects a third party, or uncovers a critical issue that cannot wait for the final report.
Authorization must identify who can approve the test
Written authorization should name the organization, the testing team, the responsible business owner, and the people empowered to change scope or stop activity. The engagement may also need legal, privacy, safety, or compliance review when regulated data, employee monitoring, international systems, healthcare environments, or critical infrastructure are involved. The tester should understand which approvals are conditions of the test and which are only informational. A verbal request from a system administrator is not enough when the test may affect production systems, customer data, cloud services, or third-party infrastructure. The tester should be able to show that the person granting permission has authority over the assets in scope.
If subsidiaries, vendors, managed service providers, or cloud tenants are involved, clarify which party controls each asset. Ownership and permission are not always the same. A company may use a hosted service without having the right to test the provider’s infrastructure. The rules of engagement should distinguish customer-controlled resources from provider-managed components.
Scope should be expressed as assets and boundaries, not vague intent
Define in-scope networks, applications, APIs, identities, wireless environments, cloud accounts, domains, and physical locations as precisely as practical. Also define what is out of scope. Exclusions can protect fragile legacy systems, life-safety technology, third-party services, production databases, or environments undergoing unrelated change.
Scope should explain how dynamic assets are handled. It should also describe whether shared services such as centralized identity, DNS, logging, CI/CD, or management platforms are included. A test aimed at one application can reach a shared control plane that affects many systems, so shared dependencies need their own boundary decisions rather than being assumed in scope. Cloud IP addresses, autoscaled workloads, containers, and ephemeral test systems may change during the engagement. Instead of relying only on static addresses, the agreement can use account, subscription, project, tag, domain, or ownership criteria to determine whether a newly created asset is included.
Testing windows and rate limits reduce operational risk
Time restrictions matter when testing could affect business operations. Some activities may be permitted only during maintenance windows, while low-impact reconnaissance may be allowed throughout the engagement. Define the organization’s time zone, blackout periods, and emergency-change windows so there is no ambiguity.
Rate limits and concurrency limits can protect fragile services from accidental overload. Define whether automated scanners may use production credentials, whether lockout thresholds must be respected, and how testers should handle account throttling. A test should not create a denial-of-service condition through authentication attempts, queue exhaustion, excessive API calls, or resource consumption simply because the technique is technically non-destructive. Rules should identify whether load testing, stress testing, denial-of-service simulation, high-volume password testing, or large-scale fuzzing are excluded unless separately approved. A penetration test should demonstrate security risk without creating an uncontrolled availability incident.
Prohibited techniques should be explicit
Do not assume everyone shares the same definition of acceptable testing. The engagement should state whether social engineering, phishing, physical access, wireless attacks, credential harvesting, persistence, destructive actions, data exfiltration, or testing of employees’ personal devices is allowed. If a technique is approved only in simulated form, define what simulation means.
Safety restrictions are especially important for actions that could affect many systems or people. For social engineering, define which employee groups may be contacted, which pretexts are prohibited, whether credential collection is simulated, and how distressed or vulnerable users should be handled. For physical testing, define restricted areas and safety rules. Authorization should be specific enough that a tester never has to improvise the ethical boundary. For example, a test may allow validating that an account has excessive privilege while prohibiting modification of production data. It may allow demonstrating a path to a sensitive repository while using a synthetic marker instead of copying real records.
Cloud and SaaS testing must respect provider policies
Cloud testing adds another authorization layer. Providers publish their own security-testing policies and acceptable-use rules. AWS, for example, allows customers to assess listed customer-controlled services without prior approval but prohibits testing AWS infrastructure and prohibits denial-of-service activity. Microsoft directs customers to its penetration-testing rules of engagement. Other providers and SaaS vendors have different terms.
The engagement owner should verify provider requirements immediately before testing because service lists and policies change. SaaS platforms may prohibit security testing entirely unless the customer uses a designated program or receives written approval. Multi-tenant systems are especially sensitive because a test against one tenant can affect shared infrastructure or data belonging to another customer. Record which policy version was checked, which cloud resources are in scope, and whether any notification or approval is required. Shared responsibility does not create permission to test infrastructure that belongs to another tenant or the provider.
Data handling rules protect the organization during the test
Testing can expose credentials, personal information, secrets, proprietary source code, and regulated records. Define what data may be collected, where it may be stored, who can access it, how long it may be retained, and how it will be destroyed. Encryption requirements should cover both transfer and storage.
Use minimum necessary evidence. The rules should define how secrets discovered during testing are protected and whether testers may use them to validate further access. A credential can provide strong evidence without being exercised against every reachable system. When additional validation is needed, use the narrowest action that proves the risk and remains within the authorized objective. A screenshot, metadata record, or synthetic proof may demonstrate access without copying an entire sensitive dataset. If real data must be captured for verification, document the reason and limit the sample. The rules should also specify whether testers may place files or markers on systems and how those artifacts will be removed.
Escalation paths should be usable in real time
The contact list needs more than names. Define primary and backup contacts, communication channels, expected response times, and what the tester should do if nobody responds. Critical vulnerability discovery, unexpected production impact, suspected real attacker activity, or evidence of a breach should have explicit escalation rules.
Agree on stop conditions. Include evidence of real compromise by an unrelated attacker, unexpected access to another organization’s data, loss of system stability, signs of safety impact, or a tester reaching infrastructure whose ownership is unclear. The correct response to uncertainty is to pause and escalate, not to continue until someone objects. A tester should know when to pause immediately because system stability, safety, customer impact, or legal boundaries are uncertain. The organization should also define who can authorize restart after a stop. This prevents pressure to continue simply because the engagement clock is running.
Changes to scope require controlled reauthorization
Penetration tests evolve as new attack paths are discovered. A web application may lead to an internal API, a cloud identity may expose another project, or a vendor connection may become relevant. Discovery does not automatically expand permission. The tester should request approval before moving into a new asset or technique outside the agreed scope.
Record scope changes in writing, even if the approval process is lightweight. Maintain a running engagement log of major decisions, approved changes, emergency contacts, and pauses. That record helps reconcile tester actions with production alerts and gives the organization an audit trail if a later incident review questions whether activity was authorized. The change should identify the new target or technique, why it matters, any additional risk, and who approved it. This protects the tester and gives the final report an accurate account of what was actually authorized.
Closeout should include cleanup, evidence return, and reporting expectations
The test plan should define how created accounts, temporary rules, files, tokens, payload markers, and other artifacts are removed. It should also specify how the team will verify cleanup. Professional rules of engagement focus on accountable execution in a real environment, so cleanup should be treated as an explicit deliverable rather than an informal final task.
Define reporting format, severity method, retest expectations, and evidence-handling deadlines before testing begins. Retesting should focus on whether the specific control weakness was corrected, not on silently expanding into a new assessment. If remediation changes the architecture substantially, agree whether the follow-up is a limited validation or a new engagement with refreshed rules. If stakeholders understand how findings will be delivered and validated, the engagement is less likely to end with disputes about scope or proof. Engagement management is part of modern penetration-testing practice, not administrative overhead.
Define how evidence is handled before testing begins. Screenshots, packet captures, credential material, exploit output, and copied data may contain sensitive information even when the test is authorized. The rules of engagement should state where evidence can be stored, who can access it, how it is transferred to the client, and when temporary copies must be destroyed so the assessment does not create a new data-protection problem.