From scope to sign-off.

Start with the business question the test should answer.

1. Ask which services, data and business activities matter most. Identify realistic threats to those services.
2. Agree measurable goals, such as whether an unauthenticated user can reach a restricted service or read another test user’s record.
3. Record the test approach: white box, grey box or black box. State what each tester knows and which accounts will be provided.

Make it clear which systems and actions are allowed.

1. List IP addresses, CIDR ranges, domains, URLs, API endpoints and approved environments. Include IPv6 where it is used.
2. Identify exclusions, shared hosting, outsourced services and fragile systems. A wildcard domain does not automatically authorise testing every related address.
3. Confirm ownership and obtain written approval before adding newly discovered assets. Keep an approved target list separate from research results.

Turn the brief into written rules of engagement.

1. Obtain written permission from an authorised client representative before active testing. Check the conditions of relevant hosting and cloud providers.
2. Agree which actions require additional permission: credential attacks, social engineering, data access, privilege changes, pivoting, persistence and disruptive tests.
3. Set testing windows with a time zone, source addresses, rate limits and the process for scope changes. Name the person who may approve those changes.

Decide how testers and the client will respond to problems.

1. Name a primary contact, backup contact and an emergency contact. Verify the contact route before testing.
2. Agree urgent finding notification times, progress updates and a secure way to share evidence.
3. Define stop conditions such as service instability, unexpected personal data, a suspected live incident or access to an out-of-scope system. Stop the affected activity, record what happened and get approval before resuming.

Allow enough time for both broad discovery and manual investigation.

1. Map the objectives to test areas, such as internet exposure, authentication, access control, transport security and supported software.
2. Agree whether authenticated checks, a full TCP port range, selected UDP services and web or API testing are included. Record any sampling approach.
3. Identify constraints such as WAF blocking, unavailable accounts or restricted time. Define when to report a coverage gap rather than silently omit it.

Make your results traceable and keep client data protected.

1. Use a separate workspace or test machine for the engagement. Patch it, encrypt storage and restrict access to the testing team.
2. Synchronise clocks and record the time zone. Capture tool and plugin versions and verify downloads from the official project.
3. Prepare an asset inventory, activity log, finding register and change log. Keep credentials in an approved secret store, rather than command histories or shared notes.

Collect only the evidence needed to support each finding.

1. Agree what may be collected, where it may be held and who may access it. Set retention and deletion dates for evidence and backups.
2. Choose approved secure channels for transferring reports and raw evidence. Decide how secrets and personal data will be redacted.
3. Confirm whether any hosted tool sends targets, results or telemetry to another service. Do not submit client data to public AI, cloud analysis or interaction services without approval.

Know how you will test access and undo changes.

1. Where required, request separate test users for each relevant role, plus two users with the same role for ownership checks.
2. Agree account lockout limits, test data, MFA arrangements and the allowed number of failed attempts. Do not weaken production controls merely to make testing easier.
3. Ask the client to confirm recovery readiness for risky checks. Define who restores service and how changes or test artefacts will be removed.

A tool’s default options may exceed the agreed brief.

1. Inspect scan policies, templates, wordlists, recursion, redirects and any checks that write data or call external services.
2. Pin tool and template versions for repeatability. Try unfamiliar or risky checks in an isolated lab before client use.
3. Set scope allowlists and exclusions at each stage. Review output before passing it to another tool. Keep a human approval step before exploit execution or changes.

Resolve the final gaps before requests reach the client’s systems.

1. Walk through the target list, test window, emergency contacts and exclusions with the client.
2. Confirm source addresses, connectivity, account access and whether monitoring teams should expect the activity.
3. Record approval to start. If a dependency is missing, agree a revised plan and state the effect on coverage.

Use public information to build a candidate asset list.

1. Review the organisation’s public sites, registration records, certificate transparency records and public technology references.
2. Use passive discovery sources to identify names and infrastructure. Record the source and observation date, as records may be old.
3. Treat discovered assets as leads. Confirm ownership and scope before making direct requests to them.

Understand how approved names connect to services.

1. Record relevant A, AAAA, CNAME, MX, NS and TXT responses. Distinguish authoritative responses from cached resolver results.
2. Check whether names point to a CDN, reverse proxy, third-party service or an old environment. A shared IP address may serve many unrelated customers.
3. Only perform zone transfer attempts, dictionary discovery or takeover validation when allowed. Do not register third-party resources to prove a suspected takeover without approval.

Correlate the available records before scanning.

1. Compare the approved asset list with passive search results and client records. Include externally reachable VPNs, remote administration, mail and development services.
2. Check IPv4 and IPv6 coverage and note which paths are reachable from your agreed test location.
3. Keep public search-engine observations separate from current direct observations. A historic banner is not proof that a system is still exposed.

Catch scope mistakes before automation multiplies them.

1. Review host files for duplicate targets, expanded ranges and accidental third-party entries.
2. Confirm how tools handle DNS changes and redirects. Stop a redirect or resolution chain from expanding testing outside approved systems.
3. Start with a small agreed sample and check traffic, output and client service health before broadening.

Identify reachable ports without confusing reachability with security.

1. Begin with the agreed port set, then expand to the full TCP range if it is in scope and time permits. Use documented timing and concurrency settings.
2. Confirm whether failed host discovery hides reachable services. Use no-ping scanning only where suitable and authorised.
3. Record open, closed and filtered states separately. Recheck unexpected results and distinguish a blocked scan from a closed service.

UDP needs its own coverage and careful interpretation.

1. Select UDP ports based on the agreed brief and likely services, such as DNS, NTP, SNMP or VPN endpoints.
2. Use modest concurrency and client-agreed limits. UDP checks can be slow and silence alone does not prove a port is closed.
3. Confirm open or ambiguous results with a suitable protocol request where allowed. Record open-or-filtered results as uncertain.

A port number and a version banner are clues, not conclusions.

1. Use a normal protocol exchange and selective version detection to identify the software and protocol.
2. Record banners, TLS certificates and the observed behaviour. Distinguish direct observations from a tool’s guesses.
3. Review service-specific options before running scripts. Do not run all discovery or vulnerability scripts as a blanket default.

Find the routes and roles that need deeper investigation.

1. For each approved web origin, record redirects, virtual hosts, login points, API documentation and available test roles.
2. Crawl within explicit host and path boundaries. Exclude logout, delete, payment and other state-changing actions unless agreed.
3. Record each endpoint, method, parameters and required role. Include alternate API versions and test environments that are explicitly in scope.

Look for useful exposure without collecting unrelated data.

1. Inspect relevant public documents, robots.txt, sitemaps, scripts and obvious exposed backup or configuration paths within the agreed limits.
2. Look for internal names, software references, repository links or secrets. Do not assume an unlinked path is access controlled.
3. Record a small redacted sample. If a live secret is suspected, notify the client and agree any validation rather than using it across other services.

Use the observed attack surface to guide the next phase.

1. Group assets by service, technology and business purpose. Mark high-value access paths and externally exposed management systems.
2. Develop testable hypotheses, such as whether an old VPN service is affected by a relevant vendor advisory.
3. Reconcile discoveries with the client. Turn unresolved access problems, missing accounts and unconfirmed assets into explicit limitations.

Track checks so that omissions remain visible.

1. For each asset or service group, list applicable checks, test user or role, tool or manual method and evidence reference.
2. Use statuses such as planned, tested, not applicable, blocked and not tested. Explain blocked or skipped work.
3. Reconcile the matrix with the inventory throughout the engagement, including newly approved assets.

Use scans to identify leads and improve coverage.

1. Update feeds before the agreed scan, then record the engine and feed or template versions used. Select only relevant approved checks.
2. Set scope, timeouts and concurrency. Exclude disruptive checks unless explicitly approved, and watch for errors or service impact.
3. For authenticated scans, verify that authentication actually succeeded and the expected permissions were available. Mark partial or failed authentication.

Confirm applicability before reporting a known vulnerability.

1. Compare observed products with vendor advisories, supported release information and CVE records. Identify the affected component and its prerequisites.
2. Consider vendor backports and hidden version details. Seek authorised configuration evidence or a non-destructive validation when a banner is insufficient.
3. Check CISA KEV and FIRST EPSS for additional prioritisation context. These signals do not prove that a particular target is exploitable.

Check the way exposed services protect communication and remote access.

1. Review certificate trust, validity, hostname matching and chain handling using the actual service hostname.
2. Assess supported protocols, cipher choices and key exchange against the client’s agreed baseline and current vendor guidance.
3. For SSH, review algorithms, key strength and permitted authentication methods. State whether the finding is an observed negotiation result or a configuration fact.

Choose checks that fit the protocol and business purpose.

1. For DNS and mail, assess permitted access, information exposure, transport protection and relevant configuration. Relay tests must use controlled addresses and agreed limits.
2. For SMB, RDP, databases and management interfaces, check exposure, access restrictions, authentication and encryption. Avoid writing or enumerating production data unless needed and approved.
3. Review VPN and edge devices using vendor advisories and the allowed methods. Do not apply an intrusive check simply because a service looks old.

Check the complete sign-in journey, not only the password field.

1. Use test accounts to assess login, password reset, MFA, session expiry, logout and account recovery where these paths are in scope.
2. Check that rate limiting, lockout and error messages behave as agreed. Keep failed-attempt tests within the documented account limits.
3. Review token handling, cookie attributes and invalidation after logout or credential changes. Never put reusable tokens in report screenshots.

Prove that access is enforced on the server.

1. Use two test users with the same role to check whether one can read or change the other’s agreed test record.
2. Compare lower-privilege and higher-privilege roles across endpoints, methods and sensitive fields. Check APIs as well as browser pages.
3. Test only approved records and tenants. A hidden button or client-side restriction is not proof that access is enforced.

Follow a structured method for the web coverage that was agreed.

1. Select relevant OWASP WSTG test cases and record their versioned references. Assess input handling, file upload, path handling, request processing and server-side access to other services.
2. Check workflow rules using test data, including whether steps can be skipped or restricted fields changed. Avoid production transactions.
3. Agree any out-of-band callback service and data destination before use. Stop if validation would reach an unapproved internal or external target.

Keep an external test distinct from an internal or cloud configuration review.

1. Check approved internet-facing storage, development endpoints, remote access and identity entry points for unintended exposure.
2. For authenticated cloud, directory or tenant testing, agree a separate permission set and exact account, subscription, project or tenant boundaries.
3. Do not treat linked cloud resources, federation partners or internal systems reached through a weakness as automatically in scope.

Turn scanner output into defensible findings.

1. Reproduce each issue with the least disruptive reliable check. Classify it as confirmed, unverified or false positive, and explain the reason.
2. Group repeated instances where the root cause and fix are shared, while preserving every affected asset. Keep distinct attack paths understandable.
3. Use the agreed severity scheme. Where CVSS is used, include the version, vector and rationale, then add business context and exploitation evidence.

Test the hypothesis that matters to the client.

1. Define the suspected weakness, access needed, expected outcome and the smallest proof that would support it.
2. Check that exploitation, any privilege change and the target asset are permitted by the rules of engagement.
3. Agree any extra approval, recovery steps or monitoring needed before execution. If proof is too risky, document the limitation and supporting evidence.

Understand unfamiliar code before it touches client infrastructure.

1. Read the relevant exploit or module and its dependencies. Check for destructive behaviour, unrelated callbacks and data collection.
2. Match the method to the observed product, architecture and configuration. A CVE name alone is not enough.
3. Where possible, test against a comparable isolated environment. Record the source, version or hash and the settings selected.

Demonstrate the weakness without unnecessary access.

1. Execute the agreed check against a confirmed in-scope asset during the approved window.
2. Use a benign marker, test record or limited response to prove the result. Avoid bulk extraction or production changes.
3. Record the exact steps and outcome. Stop once the required evidence is obtained, and notify the client if the result meets the urgent escalation criteria.

Describe what the proof actually allowed.

1. Identify the account, role, host and service context available after the successful test.
2. Check a limited set of agreed capabilities using test data or safe read-only actions.
3. Separate demonstrated access from assumptions. Do not claim administrator access, broad data exposure or full compromise without evidence.

Find whether the access boundary can be crossed.

1. Review relevant configuration, assigned rights and trust relationships within the approved host or directory scope.
2. Choose a controlled validation rather than running every local enumeration or exploitation script.
3. Use a benign proof for any approved privilege change and record all changes. Do not collect unrelated secrets merely because the new role allows it.

A path to another system still needs its own scope check.

1. Confirm each destination, identity and technique against the approved target list before making a connection.
2. Assess whether existing permissions, trust or network access allow a controlled action on the destination.
3. Limit pivoting and remote execution to the agreed proof. Record the complete chain and remove temporary routes, tunnels or sessions afterwards.

A discovered secret creates a handling task as well as a finding.

1. Record the location and a redacted identifier for the secret. Do not paste the full value into shared notes or report drafts.
2. Get approval for any credential validation or offline password assessment. Agree the target, attempt limit and handling of recovered values.
3. Ask the client to rotate or revoke exposed secrets and record the recommendation. Do not test them against unrelated services.

Help the client understand what its monitoring observed.

1. Agree whether detection validation is part of the engagement and which team will review the logs.
2. Give the team timestamps, source addresses and agreed indicators for the actions performed.
3. Record what was detected, missed or not reviewed. A penetration test alone does not establish complete monitoring effectiveness.

Keep the engagement controlled when the result differs from the plan.

1. Pause the affected activity if there is instability, unexplained access, out-of-scope exposure or evidence of a possible live incident.
2. Preserve a limited audit record and notify the named contact. Avoid further investigation beyond the testing authorisation.
3. Agree who will restore service or handle the incident. Resume only after the agreed authority confirms the revised plan.

Make the result useful for remediation and later verification.

1. End test sessions and remove temporary artefacts as agreed. Record outstanding changes for the client.
2. Link each step in the attack path to a finding and evidence reference. Explain any alternative conditions that could change the result.
3. State which fixes would break the path, then carry the verified evidence into the report.

Make it useful for both decision-makers and technical teams.

1. Include document control, classification, recipients, testing dates, objectives and an executive summary.
2. Document scope, methodology, coverage, limitations, a findings summary and the detailed technical findings.
3. Include remediation priorities, retesting arrangements, cleanup status and supporting references. Keep confidential raw evidence in an agreed separate location if needed.

Explain the business meaning of the results.

1. State the main risks in plain English and describe the most important demonstrated attack paths.
2. Identify the changes that would reduce the most exposure. Explain where immediate action is needed.
3. Describe material limitations and any positive controls observed without implying that untested systems are secure.

Give the client enough detail to reproduce and fix it.

1. Record a stable finding ID, title, affected assets, prerequisites, description and observed result.
2. Include reproducible steps, redacted evidence, the impact demonstrated and a clear severity rationale.
3. Recommend a practical fix and a verification method. Link vendor guidance and relevant CVE, CWE or versioned test-case references.

Use scores consistently without letting them replace judgement.

1. Use the client’s agreed rating method. For CVSS, show the version and full vector as well as the score.
2. Explain how exposure, privileges, business importance, demonstrated access and existing controls affect the result.
3. Use KEV or EPSS as dated prioritisation inputs where relevant. Do not describe EPSS as certainty or a CVSS score as the whole business risk.

Make the boundaries of the conclusion visible.

1. Compare the final target list with the coverage matrix and state which checks were completed.
2. List unreachable assets, blocked scans, missing roles, time restrictions and excluded techniques.
3. Describe whether WAF or allowlisting conditions affected testing and whether internal, cloud or dedicated application testing was outside scope.

A finding should survive independent review.

1. Ask a qualified reviewer to follow the reproduction steps where practical, using the agreed environment or retained evidence.
2. Confirm asset identifiers, timestamps, severity, request and response details and the proposed fix.
3. Remove secrets, personal data and client identifiers that are not needed by the intended recipient. Use evidence references consistently.

Leave no untracked test changes behind.

1. Reconcile the change log against test accounts, files, scheduled jobs, agents, sessions, tunnels and configuration changes.
2. Remove approved test artefacts and verify the result. Coordinate secret rotation, account removal or restoration with the client.
3. Do not delete security logs or evidence of the test from client systems. State any item that remains, who owns it and when it will be resolved.

Make the next action clear and achievable.

1. Describe the root cause and the recommended configuration, code change or vendor update.
2. Where an immediate fix is not possible, explain an interim control and its limits.
3. Identify the service owner where known, the agreed target date and the evidence needed to confirm the fix. Avoid claiming a universal remediation deadline.

Check that the intended recipients can act on the result.

1. Send the final version through the agreed secure route and confirm receipt.
2. Walk management through priorities and the technical team through findings, evidence and remediation.
3. Answer questions, record accepted corrections and issue a controlled revision if needed. Keep a record of which version each recipient received.

Set a clear boundary for the follow-up.

1. Agree which finding IDs, assets, roles and attack paths will be retested and when.
2. Record changes to the environment and whether regression checks are included.
3. Keep the original result intact. Retest outcomes should reference it rather than silently rewrite the original assessment.

Check that the client is ready for a meaningful retest.

1. Ask the client which fixes are in place and request relevant change references.
2. Confirm target addresses, application versions, accounts and test data. Recheck that the retest permission and window are current.
3. If an asset is unavailable or a fix is incomplete, agree whether to defer the test or record it as not retested.

Test the same security boundary that failed previously.

1. Follow the original reproduction steps with equivalent privileges and conditions.
2. Check that the root cause is addressed rather than only the original input or path being blocked.
3. Where agreed, test a small set of related paths and regression cases. Record any limitations caused by a changed environment.

Use terms that do not overstate what was verified.

1. Mark each issue resolved, partially resolved, unresolved or not retested.
2. State the date, test method, evidence and remaining exposure. Explain any changed severity rather than silently replacing it.
3. Record newly discovered issues separately and follow the agreed process for additional scope and urgent notifications.

A fixed component may not remove every route to the same outcome.

1. Where included, repeat the key steps that connected the original entry point to the demonstrated impact.
2. Confirm which changes broke the path and whether equivalent authorised routes remain.
3. Explain any parts that could not be retested. Avoid claiming that all routes are closed after checking one route.

Keep the original assessment and follow-up easy to compare.

1. Reference the original report version and list the retest dates, scope and environment changes.
2. Summarise resolved, partially resolved, unresolved and not retested findings, with evidence links.
3. State that the result applies to the checks and conditions observed at that time. Do not present it as a guarantee of future security.

End the access that was granted for the engagement.

1. Reconcile supplied accounts, API keys, VPN profiles, certificates and allowlist entries with the client.
2. Have the responsible owner remove or expire them and rotate shared or exposed secrets where appropriate.
3. Verify revocation using an agreed check. Record any remaining access and its named owner.

Apply the retention plan across all working copies.

1. Review working machines, shared folders, report drafts, cloud storage and backups used during the engagement.
2. Delete or retain each category according to the agreement and record any permitted exception.
3. Confirm who owns any retained evidence and when it will be reviewed or deleted. Do not claim secure erasure of backups you cannot verify.

Make sure no operational task is left without an owner.

1. Confirm receipt of final reports, cleanup records and the retest results where included.
2. Record open questions, accepted risks and client actions without treating silence as acceptance.
3. Close the engagement administration, including invoices or internal approvals where relevant.

Improve the method without carrying client secrets into future work.

1. Review estimation, test coverage, tool performance, communication and the usefulness of the report.
2. Record repeated root causes and procedural improvements using anonymised examples.
3. Update checklists, lab tests or report guidance. Keep client-specific evidence in the agreed engagement records.

Help the client decide what should happen after this test.

1. Recommend checks for material changes, newly exposed services and systems that were outside scope.
2. Suggest a focused reassessment or specialist application, identity or cloud review where the evidence supports it.
3. Agree follow-up responsibility and timing based on the client’s risk and obligations, rather than assuming one test covers everything.