Why a customer security review asks for security testing
If a customer's security questionnaire or vendor review asks for a penetration test, you need to answer it with evidence, and the test should be scoped to the services that customer buys and reported in a form their security team can review. Before you commission anything, read the request closely: it may name a test type, a tester qualification, a report format or a recency window, and each of those shapes the scope you agree. Ask the customer's security contact which of those points are firm and which are preferences, and record the answer in writing before you talk to a provider.
Customers ask for testing because they are trying to reduce specific risks in a service they will depend on. The usual concerns are exposed services and management interfaces that should not be reachable from the internet, weak authentication and session handling, tenant isolation in multi-customer platforms, and data exposure through APIs, storage or error messages. A self-attested questionnaire answer says the controls exist. An independent test shows whether they hold against the service as deployed, which is why many reviewers treat a tester's report as stronger evidence than a list of policies. Expect the reviewer to read the report for what was tested and what was excluded, not only for the headline result.
The request usually arrives in the middle of a sales cycle, often with a deadline tied to contract signature or a go-live date, and that pressure tends to push teams toward a generic test that does not match the customer's services. Start by mapping the components the customer will actually use, including the production environment, APIs, identity integration and hosting, and agree the boundary with the customer in writing. Ask your provider how the test will be documented, whether the report can be shared with a customer under a non-disclosure agreement, and how long the test will take to schedule. Those answers determine whether the evidence arrives in time to close the review.
What a customer-facing penetration test scope usually covers
A customer review rarely asks for a test of the whole company. It asks whether the services that touch its data were tested, and by what boundary. Each card below is a scoping decision that should be written down before testing starts, so the report and the customer's questionnaire describe the same system.
Production services the customer uses
Start with the services the customer actually buys, not the whole product catalog. List the production hostnames, tenants, regions and release versions in scope, and match them to the service description in the contract or security addendum. Ask the provider to confirm whether staging, demo or sandbox environments are included, since a customer will often assume production was tested when only a copy was. Record the exact build or version tested so the findings can be traced later.
Applications and APIs behind the service
The customer's data usually moves through web front ends, mobile clients and APIs rather than through one server. Scope should name the applications, the API versions and the authentication flows that handle customer sessions, password resets, single sign-on and data export. Confirm whether third-party integrations and webhooks are covered, because a review that ends at the login page does not show how data leaves the system.
Cloud accounts and tenants holding their data
Identify the cloud accounts, subscriptions, projects, clusters and storage buckets where the customer's records, backups and logs sit. Testing should state which provider rules apply and which controls are configuration reviews rather than active attacks. Ask whether backup stores, log pipelines and analytics copies are in scope, since customer data often persists in places the architecture diagram omits.
Administrative and privileged roles
Administrative access is where a single weakness can expose many customers, so scope should name the privileged roles tested, such as support staff, tenant administrators and platform operators. Check whether the test includes role boundaries between customers, privilege escalation between tiers and the controls on break-glass accounts. A test that uses only a standard user account will not show whether those boundaries hold.
Rules of engagement
The rules of engagement set how testing is performed: testing windows, source IP ranges, permitted techniques, denial-of-service restrictions, handling of customer data encountered during testing and the contact for stopping a test. Agree them in writing and share the tester source addresses with the customer's security team if the customer requires allow-listing. These rules protect both sides and become part of the evidence an auditor or customer may ask to see.
Out-of-scope items stated in writing
Every exclusion must be written down. Name the systems, third-party services, physical sites and test types that are not covered, and state why. Common examples include hosted payment pages operated by a processor, shared infrastructure owned by a cloud provider, and social engineering. A written exclusion list stops a customer from assuming coverage that was never tested, and it should match the system description or service boundary the customer is buying.
How a customer-driven penetration test runs, phase by phase
The sequence turns a customer's request into a scoped test, a report the customer can read, and closed findings backed by retest evidence. Each phase ends with a document or check that the next phase depends on.
Agree scope against the customer's questionnaire
Start by reading the security questionnaire or vendor review and listing what the customer actually asks for: which systems, which test types, and which report they expect. DeployOpen then maps those requests to the in-scope applications, APIs, hosts, cloud accounts and user roles, and records any exclusions. Scope is written into a statement of work that both parties sign before testing begins. The closing check is a scope document the customer confirms in writing, so the report later matches what was promised. Ask your provider to confirm timing in that written statement of work, since no durations are fixed here.
Set rules of engagement and access
Define how testing will be performed: permitted test windows, source IP addresses, test accounts and their roles, data handling rules, prohibited actions such as denial-of-service testing, and who to contact if a critical issue appears mid-test. Confirm any provider-specific testing rules for cloud or hosted services, and confirm whether the customer's own hosting provider must be notified. The output is a signed rules of engagement document and a list of emergency contacts. Testing does not start until both are on file.
Confirm the testing methodology and test accounts
Before testing, the provider states the methodology it will follow, typically referencing public guidance such as the OWASP Web Security Testing Guide for applications and APIs, and general penetration testing practice aligned with NIST SP 800-115. The customer supplies test accounts for each role, and the provider verifies that those accounts reach the intended functions. This step confirms that testers can reach the attack surface the scope describes. The closing check is a short kickoff note listing the methodology, the test accounts and any known constraints.
Execute testing within the agreed boundaries
Testers perform reconnaissance, mapping of functions and trust boundaries, and then manual testing of authentication, authorization, input handling, session management, business logic and configuration against the scope. Automated tools support coverage but do not replace manual validation. Testers log activity and raise critical issues to the customer contact as they appear, not only at the end. The step closes when every in-scope item has been tested or documented as untested with a reason, and the working notes are preserved.
Validate findings and assign severity
Each candidate finding is reproduced, confirmed as exploitable or not, and rated against a stated severity method so the customer can compare it with its own risk register. Findings that cannot be confirmed are removed rather than reported as likely issues. Each confirmed item records affected components, conditions, business impact and a remediation direction the customer's engineers can act on. The closing check is an internal quality review by a second tester on the highest-rated findings.
Deliver the report and agree on the summary
The provider issues a full technical report for the customer's engineers and, where requested, a shorter executive summary. Sharing rules matter here: many customers accept a summary letter confirming that a test occurred, its scope, dates and the tester's independence, while holding back the full findings. Agree the format and recipients before issuing anything. The step closes when the customer confirms receipt and the report reflects the signed scope, with no findings silently dropped.
Retest and close findings with evidence
The customer remediates findings and asks for a retest. The provider repeats the original test steps for each fixed item and records whether the fix works, whether it is partial, or whether the issue remains. Each finding is closed only with retest evidence, such as a dated note describing the verified result, and open items carry a remediation plan with an owner. The retest phase is where findings are closed with evidence, and it produces the updated report or retest letter that a customer's security team typically files alongside the original.
Summary letters versus full reports: what customers accept
A summary letter and a full technical report answer different questions, and customers rarely need both to be the same document. A summary letter states that a penetration test was performed, the scope it covered, the dates, the testing approach and the high-level outcome, usually with the number of findings by severity and whether the critical and high items were retested. A full report contains the methodology, each finding with its evidence, affected components, risk rating, remediation advice and retest results. Procurement teams typically accept the letter to close a vendor review, while the customer's security team reads the full report under a non-disclosure agreement. Some customers accept only the letter, and some ask for the full report from the start, so confirm the format before the test begins.
Full findings carry risk once they circulate beyond the people who need them. A report describing unpatched systems and exploitable weaknesses in your environment is sensitive even after the issues are fixed, and every additional recipient widens the exposure. Agree a disclosure process in writing before the test: who on the customer side may receive the full report, whether it can be shared with their auditors or insurers, how it is transmitted and stored, how long it is kept, and whether the summary letter is the only document released to general procurement. Ask the customer whether its questionnaire wording says "report", "letter" or "attestation", because those words are often used loosely and the difference matters to the reviewer.
DeployOpen issues testing reports and summary letters that describe the test it performed, but it does not issue audit reports, attestations or certifications. Only independent auditors or certification bodies can give those, so a DeployOpen letter should never be presented as a compliance opinion or certificate. Before the test, confirm in writing with the customer which format its questionnaire accepts, whether the letter must be signed by a named individual, and whether the customer expects the letter to be dated within a particular window. Put the answer into the statement of work so the deliverable matches what the reviewer will actually accept.
Which weakness categories customers look for in reviews
This table lists the weakness categories customer security reviews usually probe, what each looks like in a hosted SaaS service, and why the customer cares. Use it to check whether your test scope covers the areas a reviewer is most likely to question, then confirm the evidence you can show for each.
| Category | What it looks like in a hosted service | Why the customer cares |
|---|---|---|
| Authentication and session management | Login, password reset, MFA enrollment and recovery, token lifetime, and how sessions end on logout or inactivity | Weak sign-in controls are the most direct route to a customer's data, and reviewers ask how accounts are protected end to end |
| Access control and tenant isolation | Whether one customer's users can view or change another customer's records, and whether administrative roles are limited to what they need | In multi-tenant platforms, a boundary failure exposes data across organizations, which is often the central question in a vendor review |
| Injection and input handling in APIs | How the service validates data from users, integrations and uploads before it reaches databases, queries or downstream systems | Input handling flaws can expose or alter data at scale, and reviewers expect testing against current OWASP guidance for web and API risks |
| Exposed management interfaces and cloud misconfiguration | Administrative consoles, dashboards, debug endpoints, storage buckets and network rules reachable from the internet or from unintended networks | Exposed administration surfaces and misconfigured cloud settings are common causes of breaches, and customers ask which were checked and how often |
| Secrets and data exposure | API keys, credentials and certificates stored in code, images or logs, and sensitive data returned in responses or error messages beyond what is needed | Exposed secrets let attackers act as the service, and reviewers ask how keys are stored, rotated and monitored |
| Patch and vulnerability management | How known vulnerabilities in the platform, its libraries and its hosting layer are tracked, prioritized and closed, and how quickly critical items are addressed | Customers want proof that known weaknesses are found and fixed, not only that a test happened once, so they ask for remediation records and retest results |
What different customer types expect in the same test
Enterprise SaaS buyers usually run vendor reviews through a security questionnaire, then ask for supporting evidence for the answers. Their questions tend to focus on whether an independent tester examined the production application and its APIs, how recently that happened, how serious findings were handled, and whether fixes were checked. Most buyers do not need the full technical report. They want enough detail to judge the program.
- Test currency: Expect questions about the date of the most recent test and whether it followed a significant release.
- Scope statement: Buyers ask which applications, APIs, tenants and environments were in scope, and which were excluded.
- Tester independence: Questionnaires often ask who performed the test and whether they had a role in building the system.
- Findings and remediation: Expect requests for a summary of severity levels and the status of critical and high items.
- Retest evidence: Buyers often ask whether corrections were verified by retesting, not only reported as fixed.
Before you share anything, confirm which items your customers' review actually requires, and whether a SOC 2 examination already answers some of them. The SOC 2 penetration testing page is the natural next read for that overlap.
Financial services and payment customers often map their review to a specific framework, so the questions are more prescriptive. Payment processors and their acquirers look at PCI DSS requirement 11.4 closely, and banks and fintech providers increasingly ask how DORA applies to their ICT providers. The review tends to test whether the scope matches the cardholder data environment or the critical functions the customer depends on.
- Internal and external tests: Under PCI DSS 11.4.2 and 11.4.3, buyers expect internal and external penetration tests at least every 12 months and after significant changes.
- Correction and retest: PCI DSS 11.4.4 requires exploitable findings to be corrected and the testing repeated to verify the corrections, so buyers ask for retest evidence.
- DORA alignment: Under DORA Article 24(6), a financial entity must test ICT systems supporting critical or important functions at least yearly, so vendors serving those functions face that expectation through contracts.
- Threat-led testing: If a customer has been identified for threat-led testing under DORA Article 26, it may ask providers to support that exercise, which runs on a three-year cycle.
- Payment flows: Expect questions about authentication and payment flows specifically, not only general application testing.
Confirm early whether the customer wants a PCI DSS-specific report, a general summary, or both, because the methodology and scope definitions differ. The PCI DSS penetration testing page and the DORA threat-led testing page cover the requirement details.
Healthcare customers, including providers, health plans and their business associates, usually review vendors against the HIPAA Security Rule and often ask about HITRUST alignment. The HIPAA Security Rule does not use the term penetration testing. It requires periodic technical and nontechnical evaluation under 45 CFR 164.308(a)(8), and NIST SP 800-66 Rev. 2 suggests penetration testing as part of that evaluation where reasonable and appropriate. Questionnaires therefore ask how testing fits into the risk analysis and which systems holding ePHI were covered.
- ePHI scope: Buyers ask whether the systems that create, receive, maintain or transmit ePHI were tested, and how the scope was chosen.
- Evaluation cadence: Expect questions about how often evaluations occur and what triggers an extra test after a change.
- Proposed rule awareness: The January 2025 proposed Security Rule revision would require penetration testing at least every 12 months, but no final rule had been published as of October 2026, so confirm the status before quoting it.
- HITRUST evidence: Where a HITRUST assessment is in play, penetration test reports can serve as evidence for requirement statements.
- Remediation records: Buyers want to see that significant findings were tracked to closure.
Ask the customer which framework its review actually uses, since the expectations change between a HIPAA questionnaire and a HITRUST assessment. The HIPAA penetration testing page and the HITRUST page go deeper on how each framework treats the test.
Public sector and defense buyers tend to tie their review to a named control set, and they often ask whether the tester is independent and whether the test covers the full system boundary. For defense contractors, the question is usually answered by CMMC. Under CMMC Level 3 requirement CA.L3-3.12.1e, penetration testing is required at least annually or when significant security changes are made, combining automated scanning with ad hoc tests by subject matter experts. CMMC Level 2, based on NIST SP 800-171 Rev. 2, has no explicit penetration testing requirement, although vulnerability scanning and assessment expectations still apply.
- Level-specific expectations: Confirm whether the customer's contract requires Level 2 or Level 3, since the testing language differs.
- Annual and change-driven testing: Expect requests for dates and triggers for each test, not only the most recent one.
- Automated and expert testing: Level 3 reviews may ask how scanning and manual subject matter expert work were each covered.
- Federal baselines: Where NIST SP 800-53 Rev. 5 applies, CA-8 Penetration Testing is selected in the high baseline, and CA-8(1) adds an independent penetration testing team in that same baseline.
- Evidence retention: Buyers ask for test plans, results and remediation records that can be produced during an assessment.
Confirm the level, baseline and contract clauses before you agree on scope, because a test built for a commercial review may not meet a federal one. The penetration testing for CMMC page explains the Level 2 and Level 3 differences in more detail.
What you receive and what it closes in the customer review
A customer security review usually asks for proof that testing happened, what it covered, and whether the findings were fixed. The deliverables below answer those questions in different ways, so the buyer should agree the full set in writing before testing starts.
Full technical report
The full report records each finding with its affected component, reproduction context at a defensive level, severity rating, and recommended fix. Customers rarely receive it in full because it contains detailed system information about your environment. Ask the provider to confirm the rating method it uses and whether the report includes the methodology and scope sections a security engineer will read first. Agree in advance who inside your organization may read it.
Executive summary
The executive summary gives leadership and procurement a short account of the test's overall outcome, the highest-risk themes, and the status of critical findings. It suits questionnaire answers and board reporting, but it does not show enough detail for a technical reviewer to accept the test on its own. Confirm that it states the testing dates and the tester's approach so that its claims can be traced back to the full report.
Summary letter
A summary letter is a short statement, signed by the testing provider, that confirms the test took place, the systems and environments in scope, and the test dates. Many customers accept it when they cannot receive the full report. It does not state the findings and is not an audit opinion or certification. Ask the provider whether it will sign one, what it may say about findings, and how long it stays valid after the test.
Retest report
The retest report shows which original findings were verified as fixed, which remain open, and which were accepted as risk. It is the document that closes the loop a reviewer asks about, because it shows the fix was checked rather than assumed. Confirm the retest window and whether retesting is included in the original quote or priced separately. A retest should cover the same systems and methods as the original finding.
Remediation record per finding
The remediation record tracks each finding from identification to closure, with the owner, the fix applied, the date, and the evidence used to verify it. Reviewers ask for this when they want to see how the vulnerability process works, not only the test result. Keep the record in your own ticketing system so it remains available after the provider's engagement ends. Set retention periods with your compliance lead before the test begins.
Test plan
The test plan records the objectives, scope boundaries, rules of engagement, testing windows, named contacts, and testing methods agreed before work starts. It is the document that shows a customer the test was planned and authorized, and it lets you check that the scope matches the systems the customer relies on. Ask for it to be shared with your own change management team so that testing does not trigger incident response.
How retest evidence closes findings in a customer review
A finding is closed only when a retest verifies the fix. Until then, the original report shows the issue as open, and a customer reviewer will read it that way. A retest report should list each finding with its current status (for example, resolved, partially resolved or still open), the evidence the tester reviewed for each one, and the date of that review. Reviewers look for that per-finding trail, so a single sentence saying the issues were fixed carries little weight. Exploitable findings should be corrected and then retested, and the requirement to repeat testing after corrections is written into the PCI DSS penetration testing requirement (11.4.4), which many customers use as their benchmark even when they are not PCI-scoped.
Agree the retest scope and timing in writing before the first test starts. Decide which findings will be retested, whether the retest is limited to the original targets or extends to the fix areas, and whether the tester will review configuration changes, code diffs or only re-run the same checks. Customers usually expect the retest date to fall after the fixes are deployed to the production environment, not in a staging copy, so confirm that the deployment date and the test window line up. Keep the change record for each fix: the ticket, the deployment date, the affected component and the approver. Without it, a tester cannot tie a status to a specific change, and the customer cannot confirm that what was tested is what runs in production.
A retest does not replace a new test after a significant change. A retest confirms that named findings were corrected; it does not establish that the rest of the system is still secure after the fixes or after a new release. If the fixes changed authentication, data flows or network paths, ask the tester whether a fresh test is needed, and check whether your customer contract or security questionnaire defines what counts as a significant change. Tell the customer which parts of the report are closed by retest and which remain open with a documented mitigation plan, because a clean retest on a narrow scope will not satisfy a reviewer who expected the whole system to be covered.
Questions vendors ask before a customer review requires a test
Can a customer accept a summary letter instead of a full penetration test report?
Sometimes, but the customer decides, and most will ask for the underlying detail once they read the letter. A summary letter states that a test happened, who performed it, the period covered and the general outcome. A full report contains the scope, methodology, findings with severity, evidence of exploitability and remediation status, which is what a security team needs to judge the risk. Before you share anything, ask the customer's security team in writing which format their questionnaire or contract accepts. Plan for a redacted full report or a letter that points to a retest, because a letter with no supporting detail often prompts follow-up questions. Confidentiality terms for the report should be agreed up front so the customer can review it without you breaching your own obligations.
How long does a customer-driven penetration test take, and what drives the duration?
The duration depends on scope size, the number of applications and environments, the test type, and how quickly access and answers arrive. The main drivers are the number of in-scope hosts, endpoints, user roles and integrations, whether testing is internal, external, or both, and whether the environment is production or a staging copy. Delays usually come from slow account provisioning, unclear ownership of systems, and remediation discussions that run after the report. DeployOpen does not publish a schedule, so the timeline is set in the written scope. Ask any provider for the phases they expect (scoping, testing, reporting, debrief) and the dates each one depends on from your side. Allow additional calendar time for the customer's own review queue, which you do not control.
Can our own engineering team run the penetration test on our product?
Your team can run internal scanning and remediation, but customers usually expect an independent tester, and an in-house test may not be accepted as evidence. Independence matters because the people who built a system have assumptions about it that an outside tester challenges. Many customer reviews ask who performed the test, their qualifications and whether they had a reporting line that could influence the outcome. Your engineers remain essential for providing context, reproducing findings and fixing issues. A common split is an external provider for the formal test and an internal team for continuous scanning between tests. Confirm the independence and qualification expectations in the customer's questionnaire before you decide who performs the work.
What must our team prepare before a penetration test starts?
The main preparation is access, contacts, and a clear change calendar, and most delays trace back to one of these. Typical items include:
- Test accounts for each user role, plus any test tenant or staging environment agreed in scope
- Written authorization from the system owner, and confirmation of which third-party services are excluded
- A named technical contact who can answer questions and a named escalation contact for critical issues
- A change freeze window or notice to your operations and monitoring teams so alerts are handled correctly
- Current architecture diagrams, data flow information, and a list of in-scope hosts and applications
Agree on backup and rollback steps for any test environment that changes state. Ask the provider to list these prerequisites in the written scope so nothing is discovered on the first day of testing.
Is a retest included, and when does a customer need one?
A retest is usually a separate, defined piece of work, so check whether it appears in your written scope. Its purpose is to confirm that the fixes for reported findings work, which is how findings are closed in most review processes. A customer will typically want a retest after high or critical findings are fixed, and after any significant change to the tested system. Ask the provider how retest results are documented, whether the retest report can be shared with the customer, and whether the retest covers all findings or only those you select. Keep your own remediation records alongside the report, because customers often ask for evidence of when each issue was fixed and how.
Does a penetration test satisfy a compliance framework requirement?
A penetration test can serve as evidence for a framework requirement, but it does not certify compliance on its own. Each framework sets its own rules for who tests, how often, what is in scope and what records must be kept. PCI DSS, for example, defines methodology, testing frequency and retention requirements in its requirement 11.4 family, while a SOC 2 examination depends on how the test fits the system description and the auditor's testing. Auditors and certification bodies decide whether evidence is sufficient, and DeployOpen does not issue audit reports, attestations or certifications. Before commissioning a test, identify the framework clause your customer or auditor cites, and ask both the provider and the assessor how they expect the evidence to look.
What does a penetration test cost, and which parts of the price change?
The cost depends on the written scope, so there is no standard figure to quote here. The main components are the tester's time for scoping, testing, analysis, reporting and debrief, plus any retest, and the number of in-scope applications, endpoints, environments and user roles. Costs rise with broader scope, more test types, production testing, complex authentication, and tight timelines. They fall when access is ready on day one, systems are well documented, and the report format is agreed early. Ask any provider for a quote that lists each component separately, states which items are one-time and which recur on each retest or annual cycle, and names the assumptions behind the price. DeployOpen does not publish a price list and provides quotes from a written scope.
What to ask a testing provider before you sign
A customer's security review tends to judge the test as much as the findings, so the provider's own credentials, paperwork and handling rules matter. The cards below cover the checks to make before you sign, and each one produces a document you can hold the provider to.
Tester qualifications and independence
Ask who will perform the test, what experience they have on your platform type, and whether they sit in the team that builds or operates the system. Customers and assessors often ask whether the tester is organizationally independent from the build team. PCI DSS requirement 11.4.3 uses that exact test of independence, so ask the provider to state in writing how it separates testers from delivery staff. Ask for named credentials in the statement of work rather than a general claim of expertise.
Written scope and rules of engagement
The scope should list the systems, environments, domains, IP ranges, accounts and test types that are in bounds, along with the testing window and any excluded third-party services. Rules of engagement cover permitted techniques, such as whether denial-of-service or social engineering is allowed, and the contacts to call if something breaks. Confirm that the scope matches the system description your customer reviewed, because a mismatch is the most common reason a report is rejected.
Report and letter formats offered
Ask what the provider delivers: a full technical report, an executive summary, a letter confirming the test occurred, or a retest report. Each serves a different reader. Full reports hold the detail your engineers need, while summary letters are easier to share with customers without exposing unpatched weaknesses. Request a sample of each format before signing, and confirm which one the provider expects to release to third parties.
Handling of sensitive findings and data
Testers handle credentials, personal data and unpatched weaknesses during a test, so ask how each is stored, who can access it, how long it is kept and how it is destroyed. Ask whether findings are transmitted encrypted and whether the provider will sign a confidentiality agreement covering both your data and the findings. Clarify how critical findings are reported during the engagement, not only at the end.
Retest terms and verification
Clarify whether retesting is included, how many rounds it covers, what window applies after the initial report, and how the retest is documented. Under PCI DSS requirement 11.4.4, exploitable findings must be corrected and the testing repeated to verify the corrections, so a retest is part of the evidence chain, not an optional extra. Ask for a retest report that names each finding and states whether it is closed, partly closed or still open.
Attestations and references
Ask whether the provider issues attestations or certifications. DeployOpen does not issue audit reports, attestations or certifications, and independent auditors and certification bodies make those determinations. Ask for sample redacted reports and references you can verify independently, and confirm that the provider's own statements match what your customer or assessor will accept.
How DeployOpen scopes, tests, reports and retests
This sequence turns a customer's questionnaire request into a written scope, a tested target, a report and summary letter the customer can review, and retest evidence that shows which findings were closed. Each step ends with a document or check the buyer can file with their review.
Agree the written scope with the customer
Before any work starts, DeployOpen's team reviews the customer's security questionnaire, the systems that serve their account, and the test types the review asks for. The result is a written scope that names the target, the test types, the environments, the testing windows and the deliverables. Both parties sign off on it. The step is done when the customer confirms that the scope answers the questions in their review, and anything they cannot accept has been removed or changed in writing. Ask for this scope document before you commit to a test, since it is what your reviewer will compare the report against.
Confirm access, rules of engagement and contacts
The scope is paired with rules of engagement: which hosts, accounts and data are in bounds, which activities are excluded, how the client's own infrastructure or hosting provider is involved, and who to call if testing affects a live service. Where the target runs on a third party's platform, the team checks that the provider's testing rules allow the work. The step closes when the client's technical contact and an escalation contact are recorded and access has been provisioned in the client's environment. Confirm these terms with your own legal and hosting teams, since they vary by organization.
Run the test against the agreed target
DeployOpen's security testing team carries out the work against the agreed target, using a methodology matched to the test type, such as application, API, cloud, infrastructure or self-hosted platform testing. Testers record what they tried, what they observed and the evidence behind each weakness, and they do not go beyond the agreed scope. If a serious issue appears during testing, the team raises it with the client contact before the engagement ends. The step is complete when testing against the scope is finished and the working notes are ready for review.
Rate and document each finding
Each weakness is written up with a description, the affected component, the evidence that supports it, the business impact in the client's context, a severity rating and a recommended fix. Severity ratings follow a scale the client can see and question during review. The team checks that each finding can be reproduced from the write-up before it leaves the testing team. The step closes when the findings list is internally reviewed and ready for the client's sign-off. Ask which rating scale is used so that you can map it to your customer's own risk categories.
Deliver the report and summary letter
The client receives the full technical report and, where requested, a summary letter that a customer or assessor can read without the technical detail. The summary letter states the test type, the scope and dates, the tester's approach at a high level, and the count of findings by severity. The full report is kept for the client's own records and is shared with a customer only if the client chooses. The step is done when the client confirms receipt and asks no open questions about the scope or the findings. Confirm with your customer which document they will accept before the test starts.
Plan remediation and retest the fixes
The client assigns owners and target dates for each finding and fixes the issues in their own environment. DeployOpen then retests the corrected items against the original scope and records whether each finding is closed, partly closed or still open. The retest result is written up as a separate document with the original finding reference, so a customer can trace each item from report to closure. The step closes when every critical and high finding has a documented retest result or a risk acceptance signed by the client. This retest record is the piece most reviewers ask for when they check whether findings were resolved.
Keep evidence and schedule ongoing testing
The client files the scope, report, summary letter, retest record and remediation tickets together so they can answer later questions from customers or assessors. DeployOpen can also support regular testing under a retainer, which covers repeat tests after significant changes or on a fixed cadence agreed in writing. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications, so the client's auditor or certification body makes the final determination. The step is done when the client has a filed evidence pack and a decision on whether ongoing testing fits its review cycle.
