A client asks for a penetration test. The MSP knows the infrastructure, administers access and already handles the support queue. That proximity helps organize the engagement, but it does not settle the decisions that make an assessment defensible: what will be tested, who can authorize it, how far execution may go and what evidence will be sufficient. A reliable service carries those decisions through the entire engagement, from proposal to retest. A report without that connection leaves essential questions unanswered.
Start with the question the test needs to answer
Before discussing tools, establish why the client is asking. An API security review, a contractual obligation and an assessment following a migration can require different engagements. The document requested by the client may be called a pentest without specifying depth, assets or acceptance criteria. The MSP needs to turn that intention into testable questions and confirm whether the proposed deliverable will satisfy the party requesting it.
Asking whether a portal is reachable from the internet is different from asking whether a user can access another organization’s records. The first question directs surface discovery; the second requires examining authorization and isolation, with suitable identities and testing conditions. The proposal should explain which questions will be examined, which require additional access and which will remain outside the engagement. This precision prevents a familiar service name from concealing an undefined deliverable.
A bounded assessment does not demonstrate that the entire environment is free of vulnerabilities. Its conclusions apply to the assets, conditions and techniques actually examined. Recording those conditions makes the result more useful: readers can understand what the team observed and decide where further investigation is needed.
Wardizon turns that preparation into an operational workflow: the MSP registers the customer, organizes the scope and sends authorization for signature before execution. Findings and the report remain connected to the assessment performed. The commercial conversation can therefore start with a defined deliverable: assess authorized conditions, present the evidence and work with the customer on what needs treatment.[3]
The RoE bounds execution and keeps responsibility visible
NIST SP 800-115 includes a Rules of Engagement template in Appendix B and treats assessment planning as a distinct activity. That reference helps separate permission to test from the operational decisions that direct execution.[1]
In practice, the commercial agreement organizes the relationship between the parties; the RoE records authorized activities and their limits. Administrative access is not permission to carry out any offensive technique. The MSP should identify the client representative authorized to approve the scope and clarify who is responsible for dependencies operated by third parties. Necessary permissions from providers and other asset owners do not arise automatically from the client’s signature.
The signature does not remove operational risk or confer immunity from liability. An authorized test can still cause impact, exceed its boundaries or handle data improperly. The work is to reduce ambiguity, establish responsibilities and preserve decisions. Specific legal questions belong in negotiation and appropriate professional advice for the parties; they should not be settled through promises of absolute protection in a technical proposal.
Write scope so that two people reach the same operational decision
A domain list is a starting point, not a complete definition of the test. For each target, record its identifier, environment, owner and relevant exclusions. Clarify whether a domain includes subdomains, whether an address can change and how the team should respond when it discovers a different destination. Redirects and trust relationships can lead to systems the client does not own. Discovering an asset does not authorize testing it.
Consider a hypothetical engagement: the approved portal redirects authentication to a shared identity provider. Testing the application’s login flow does not authorize attacking that shared service. The team must distinguish the behavior of the application under assessment from controls operated by the third party, and obtain any necessary permissions before expanding the work. The same discipline applies to storage, payments and integrations discovered while using the application.
The document should allow an objective answer when uncertainty arises: was this action, against this target, with this identity and during this window authorized? If one of those conditions is missing, the team should clarify it or request new authorization. Resolving uncertainty during preparation generally costs less than reconstructing decisions after execution.
Make the testing window workable for the people operating the environment
Authorization validity and the execution window are related but distinct decisions. A current document does not make every hour suitable for testing. Agree permitted periods, the reference time zone, scheduled changes and conditions that prevent a run from starting. At the beginning of each execution, confirm that the target remains correct, the environment is stable and the emergency contact is available. Valid authorization can coexist with an operational condition that requires postponement.
Also establish who can stop the engagement and how the team will communicate that decision. Availability loss, unexpected behavior or discovery of an out-of-scope system need a known response. The record should show what was running, what condition was observed and what decision followed. An unavailable stakeholder should not be treated as permission to continue. Specify the route for escalation before the team needs it.
These checks belong to the MSP’s operating process. When selecting a platform, establish which boundaries it enforces technically and which rely on operator procedures. A configuration option alone does not demonstrate that every rule is implemented or that exception paths are covered.
Agree depth, identities and permitted impact before execution
Surface discovery, testing without credentials and authenticated testing answer different questions. The scope should describe the access available and what the team may do with it. In an application with several roles, an administrator account does not replace examining boundaries between ordinary users, managers and organizations. Test accounts should represent the relevant relationships without unnecessarily relying on real customer records. Missing access should appear as a limitation, not disappear from the final coverage statement.
Exploitation requires an explicit decision about purpose and limits. Confirming an authorization flaw may require a small piece of evidence; collecting a larger volume of data can add exposure without improving the conclusion. The objective is to demonstrate the authorized condition with proportionate impact. If the necessary proof exceeds the agreed boundaries, record the restriction and return the decision to the responsible stakeholder.
Automation cannot independently settle the meaning of a business workflow or accept risk on the client’s behalf. It can reduce repetitive work; interpretation of context, consequences and exceptions still requires technical judgment.
Separate suspicion, confirmation and demonstrated impact
OWASP WSTG v4.2 recommends reviewing false positives and writing reports that enable reproduction of results. It also calls for documenting root cause, testing technique, severity and remediation. These are useful criteria for evaluating the substance of a deliverable beyond its finding count.[2]
The MSP needs to distinguish three questions: is there an indication of a weakness, has the weakness been confirmed and what impact was actually demonstrated? An identified software version can support suspicion without proving that the deployed configuration is exploitable. An unexpected response can confirm improper behavior without demonstrating access to an entire database. Preserve those distinctions in the report, including cases where scope restrictions prevented the test from advancing.
Priority also depends on context. External exposure, prerequisites, required privileges and business criticality help direct remediation. A technical rating should not be presented as a precise measure of the client’s financial loss. If the asset owner has not yet validated the context, state the assumption and identify what information is needed for a decision. A qualified conclusion is more useful than an unsupported assertion of certainty.
Collect enough evidence while limiting the exposure the test creates
Useful evidence identifies the target, time, access conditions, observed behavior and procedure needed for verification. The person fixing the issue must understand what happened and be able to reproduce the condition in an appropriate environment. Isolated screenshots and generic descriptions leave room for conflicting interpretations. When reproduction depends on state or a sequence of operations, document that dependency. Keep enough context to distinguish the actual observation from a similar-looking failure.
The volume collected should be justified by the demonstration. Prefer test records and minimized samples when they are sufficient. Remove secrets and personal information from broadly distributed materials, and restrict access to technical detail. Assign responsibility for storage, sharing, retention and disposal. Evidence used to fix a vulnerability does not need to circulate with the same permissions as an executive presentation. Decide how authorized reviewers will obtain the detail they require.
Hashes can support integrity checks on an artifact. They do not independently establish that its content is true, that a signer had authority or that the operation stayed within scope. Evidence quality depends on the combination of technical records, context and disciplined handling.
Delivery requires a decision about remediation
Each material finding should have an owner, an intended action and a verification criterion. Fixing the cause, applying a mitigation and accepting the risk are different decisions; the history needs to show which one was selected. If the team introduces a temporary barrier, preserve the outstanding work on the underlying cause. A status change should not erase the condition originally observed or make a temporary measure appear permanent.
A retest examines the condition that produced the finding under the authorization for the new execution. Compare previous and current behavior, record the relevant version or configuration and document limitations. A connection error does not demonstrate that an authorization flaw has been fixed. If the application is unavailable for examination, the result is an inability to verify, not a conclusion that it is secure. Keep that distinction visible to whoever accepts the remaining risk.
A material change in target or depth requires new authorization. Recurrence must preserve that relationship: every execution needs to fit within a valid RoE. Repeating tests helps observe change; it does not turn the engagement into unrestricted coverage of the entire environment.
Organize the service around its ability to close the loop
The client sets business priorities, provides the agreed conditions and identifies who can decide about risk. The MSP organizes scope, coordinates execution, interprets results and follows remediation with the responsible teams. The platform supplies the contracted functions; the existence of a feature does not automatically transfer service decisions to it. Keep that division clear when a development team or another supplier is involved, including who has authority to deploy a change.
In a recurring service, delivery capacity depends on validation and remediation as well as execution. An MSP producing more reports than it can discuss accumulates unfinished work. Track movement between stages to identify where the service loses effect. Compare similar scopes and record changes before treating a trend as improvement or deterioration.
- Delivered coverage: targets and scenarios examined against those authorized, with exclusions documented.
- Validation time: elapsed time between an indication and the decision to confirm or dismiss it.
- Exposure time: the period between confirmation and verified remediation, considered against the agreed priority.
- Completed retests: fixes examined against those ready for verification.
- Repeated causes: weaknesses with the same underlying cause returning across comparable cycles.
Where the Wardizon workflow fits into the service
In Wardizon, the MSP assembles the scope and sends the authorization request to the named approver. The MSP warrants that this address belongs to the client; this is not independent identity verification by the platform. The signing link is valid for 60 minutes. The signed scope is frozen into an immutable snapshot bound to the document and signature hashes. A material change requires a new RoE.[4]
The platform requires a signed RoE before starting a test. On paid plans, each RoE is valid for 30 days and carries up to 30 executions — at most one per calendar day. Those limits describe authorized recurrence; they do not replace the operational agreement about when execution is appropriate. Co-branded reports present the MSP’s branding alongside “Powered by Wardizon”.
The trial runs Basic surface discovery. The trial’s RoE carries three executions. This assessment is deliberately not a penetration test and should be presented to the client with that distinction. Testing with or without credentials requires a login email on your company’s own domain; consumer mailboxes are limited to the trial and Basic. The trial demonstrates the authorization and delivery workflow without establishing conclusions about the depth of paid assessments.
Define the first cycle before expanding the client portfolio
Select a concrete need, identify the assets and confirm who approves the work. Prepare accounts, the execution window and stop conditions; agree how findings will be presented and who can remediate them. After execution, review evidence and limitations before delivering the report. The client discussion should end with recorded decisions and a planned retest for material fixes. Do not let scheduling the next run replace following through on the current findings.
Service quality appears in that sequence. The client can relate what was authorized to what was examined, understand the distinction between suspicion and confirmation, and verify the outcome of agreed actions. That traceability allows an MSP to expand a penetration testing operation while keeping recurring delivery useful to the people responsible for reducing risk.
Prepare the engagement with the Rules of Engagement template before sending the authorization request to your client.