Security testing starts with a boundary you can explain.

What makes a security assessment authorized?#

An authorized security assessment is an investigation whose owner has approved a specific question, environment and set of activities before those activities occur. The practical starting point is a written statement connecting the person granting permission to the systems they can actually authorize. A company name, purchase order or public hostname is not a complete boundary. An engineering lead might own an application while a customer owns its tenant and a supplier operates its identity service.

NIST SP 800-115 includes planning and rules of engagement in its assessment process, with a template covering purpose, boundaries, risks and coordination. Treat that as a starting structure, then make the decisions specific to your operation. RFC 9116 separately explains that publishing security.txt does not itself grant testing permission. A reporting contact tells you where to send a concern; permission comes from the applicable policy or agreement and its actual terms.

Write the objective as a question the owner can act on. For example: may a member of the fictional North workspace download a document owned by the fictional South workspace? This produces a bounded investigation and a useful release decision. A request to prove that an entire business is secure produces neither. Where authority remains unclear, continue preparation through agreed documentation review and resolve the missing decision before starting the disputed activity.

Define assets and permitted activities separately#

Asset scope describes where the work may happen. Activity scope describes what the team may do there. Record the application, environment, relevant release, interfaces, tenants, test accounts and supporting components. Then describe the methods needed to answer the objective. Reading approved configuration, reviewing source code and exercising a normal application flow have different operational effects. Access to one environment does not silently authorize availability testing, account recovery changes or inspection of every record inside it.

Make the boundaries usable at the moment a tester encounters something unexpected. An asset entry should have an unambiguous identity and an owner; an activity entry should state its limits and required coordination. Avoid broad phrases such as all associated systems when the association itself is what the investigation will uncover. If a new dependency appears, record it as an unresolved scope item. The owner can then approve a narrowly described addition, arrange supplier participation or accept that the original question has a remaining limitation.

Separate business coverage from technical inventory. Reviewing invoice download authorization does not mean reviewing every function of the billing platform. Describe the roles and workflows covered, including important denied outcomes. This keeps the final conclusion tied to evidence instead of letting a long hostname list imply a comprehensive assessment.

Choose a method that answers the actual question#

Use this decision table as a planning aid, not a universal testing prescription. Begin with the least disruptive method that can establish the relevant behavior. Combine methods when one leaves a meaningful blind spot: code can explain an intended access check while a controlled request shows whether the delivered application reaches it. Agree increased operational exposure explicitly instead of treating more intrusive activity as evidence of a better assessment.

Resolve shared services and provider restrictions#

A staging label does not make every dependency a staging dependency. Sign-in may reach a production identity provider; an attachment may live in shared storage; a payment action may contact a supplier. Trace the approved workflow far enough to identify those transitions before testing. Assign each dependency one clear treatment: included with authority, replaced with a controlled substitute, observed without active testing, or excluded. Record what that treatment means for the question the assessment can answer.

Provider terms are an additional boundary. AWS, for example, publishes a policy distinguishing permitted customer testing from prohibited activities and testing that requires a separate process. Verify the current policy applicable to the actual service and activity rather than borrowing approval from another provider or an older engagement. Customer permission to review an application is not ownership of the cloud provider's underlying service or another customer's resources.

For a shared component, ask what happens to unrelated users when the approved activity runs. A test account can still trigger global notifications, consume a shared quota or cause a real downstream job. Those effects belong in the plan. If the team cannot explain them, replace the dependency or reduce the activity until the operational owner can make an informed decision.

Plan evidence around the claim, not the available data#

Decide what observation would establish the issue before collecting evidence. For an authorization boundary, a synthetic record appearing in the wrong test tenant may be enough. For a rejected action, useful evidence might be a sanitized response, an unchanged fixture and an audit event identifying the decision. Collecting an entire customer export rarely improves that claim. A clear evidence plan also prevents the report from depending on screenshots whose context no one can reproduce.

Assign evidence a custodian, access rules and a removal point. Keep tokens, passwords and real private records out of ordinary activity logs and shared issue trackers. If a diagnostic artifact unavoidably contains sensitive material, treat the raw artifact separately from the report excerpt. Sanitization should preserve what supports the finding: which boundary was crossed, the relevant role and action, and the observed consequence. Replacing everything with a blank rectangle makes the artifact safer but can also make it useless.

Agree an unexpected-data procedure. Stop collecting, preserve only the minimum context required to explain the event, notify the operational contact and decide whether the assessment can resume. The team should not improvise wider access to determine how far the issue goes. The scope can be revised deliberately if additional evidence is actually needed.

Fictional worked example: a document portal before release#

This fictional defensive example concerns Meridian Documents, an invented portal with two synthetic workspaces called North and South. The release owner wants to know whether document downloads remain separated after a new search feature launches. No client engagement or measured outcome is being described. The team owns a staging application and its test records; it does not own the production identity provider used by the wider business.

The owner writes one objective: a North member must not receive South document contents through direct download, search results or generated exports. Included assets are the staging portal, its API and a dedicated export worker. Included identities are two test members and one test workspace administrator. The source revision is recorded. Real tenants, the production login service, bulk traffic, destructive actions and supplier endpoints are excluded. Staging login is replaced with an approved test identity configuration.

Preparation exposes a complication: exports are written to a storage account shared with another staging product. The owner authorizes only the Meridian fixture prefix and configures a separate worker identity for it. The test plan includes an allowed North download, a denied North-to-South request, a mixed search and an export with synthetic documents from both workspaces. Expected outcomes are described before the requests run, including absence of South content and absence of any unauthorized state change.

The agreed stop conditions include unexpected real documents, an unexplained identity transition and operational degradation reported by the staging owner. The team uses a shared activity identifier and a named contact during the test window. A report records the fixture identifiers, response classification and worker outcome. It contains no session values. If the export returns a South fixture to the North test member, the finding can demonstrate the boundary failure without reading any customer document.

The owner then commissions a focused correction and retest. The worker must apply the approved workspace policy when it creates an export, and download authorization must apply when the result is retrieved. The retest repeats both allowed and denied cases on the corrected revision. The final conclusion concerns the three inspected delivery paths in that environment. Supplier login behavior and other portal functions remain explicitly unassessed, making the release decision understandable instead of overstated.

Make stop, scope change and resume separate decisions#

A stop procedure needs more than an emergency phone number. Identify who can stop the work, how that instruction reaches the testers, what activity ends immediately and who decides when it may resume. Include signals that do not originate from the assessment team, such as an operator seeing unexpected queue growth or a support team receiving customer complaints. A named deputy matters when the primary contact is unavailable.

After a stop, distinguish an operational problem from a proposed scope addition. Restoring the environment does not authorize a new activity. A change record should say what changed, who approved it, which exclusion is affected and which test may resume. Keep earlier decisions in the record so the report can explain why coverage differs from the initial plan. In a short engagement, a simple versioned decision log can be more usable than an elaborate workflow nobody follows.

Define how the team treats urgent findings. The technical report may take time, while an exposed boundary needs a prompt owner decision. Send an agreed minimal finding record through the approved channel and let the accountable team choose the response. Urgency increases the value of clear coordination; it does not enlarge the tester's authority.

Verify readiness before the first active check#

Read the plan from the perspective of someone joining the engagement midway through the week. They should be able to identify the approved target, select the right test account, recognize an excluded transition and stop the work without interpreting an informal chat history. Run a short readiness review with the operational owner and resolve contradictions before the test window begins.

• Confirm the authorizing owner, the systems within their authority, and the agreement version applicable to this activity.
• Record the release, environment, approved interfaces, tenants, accounts and synthetic fixture locations.
• Connect each permitted method to the question it answers and document its operational limits.
• Trace shared identity, storage, notification, payment and background-processing dependencies.
• Check current provider terms and supplier permission where the proposed activity reaches their systems.
• Verify the emergency channel, stop authority, deputy contact and procedure for resuming work.
• Confirm evidence access, sanitization, retention, unexpected-data handling and report recipients.
• Agree how denied outcomes, remediation and remaining coverage limits will be recorded.

Deliver a conclusion with a visible boundary#

A decision-ready result states what was tested, against which version, using which identities, and with which limitations. OWASP's reporting guidance separates scope, limitations and technical findings and emphasizes material engineers can use to reproduce and resolve an issue. Use those distinctions to keep confirmed behavior separate from a hypothesis or an inaccessible component. A record that says no issue observed must also show where observation stopped.

Give each finding an expected result, observed result, consequence, evidence reference and proposed correction. Then assign an owner for verification. A remediation ticket is a plan to change behavior; a completed code change is evidence of implementation; a focused retest is evidence about the corrected condition. Keep those statuses distinguishable so a release owner can see what decision remains.

Start the next assessment with the unanswered question of highest consequence. This may be a supplier boundary, a production delivery difference or a nearby workflow sharing the same control. It should be a new scoped decision with its own authority and evidence, not an automatic continuation of every discovery made during the first engagement.