Penetration testing for SOC 2

Penetration testing for SOC 2: what the criteria say and why your auditor will ask

The Trust Services Criteria do not name penetration testing as a requirement, yet auditors and customers routinely expect evidence that one was performed and acted on. The criteria are principles, and the way you meet them is through your own controls. A penetration test is one of the most direct ways to show that those controls work, which is why it appears so often in examination fieldwork and in customer security reviews. Before you commission anything, read the system description and the controls you have written against it, because the test only earns its place if it tests what those controls claim.

In practice, penetration testing most often supports the criteria covering vulnerability management, security monitoring, change management and remediation. Vulnerability management is where auditors look first: they want to see that you identify weaknesses, rank them and close them. Security monitoring and change management matter because a test shows whether detection fires and whether significant changes trigger retesting. For remediation, the CIS Controls map their penetration test remediation safeguard 18.3 to SOC 2 criterion CC3.2, which is a useful cross-reference when you explain your process, though it is a mapping by CIS and not a statement in the criteria themselves. Confirm the exact criteria your auditor will select before scoping, since that choice drives what the test must cover.

The points of focus in the 2022 revision guide how you design and evaluate controls. They are characteristics to consider, not separate requirements, so a missing point of focus is not a finding in itself. Use them as a checklist for your own control design, then explain in your system description how your penetration testing program addresses the relevant ones. Ask your auditor early which points of focus they will evaluate, and ask your test provider whether the report can map findings and retest results to your control descriptions in the terms the auditor uses.

How to scope penetration testing to your SOC 2 system description

A SOC 2 penetration test is only as useful as its boundary. The cards below walk through the decisions that tie the test to the system description, the commitments in it and the parties that support it, so the auditor can trace each tested system back to the scope they examined.

Anchor the boundary to the system description

The system description defines the services, infrastructure, software, people, procedures and data inside the examined system. Start the test scope from that document, not from a list of hosts. Every production component the description names, including identity, logging and administrative paths, should either be in the test or be recorded with a reason for exclusion. Ask your auditor to confirm that the boundary in the test letter matches the one in the description.

Production and non-production environments

Test production when the system description says customer data or commitments run there, because the auditor evaluates the controls that operate in production. Staging or pre-production environments can be tested when they share code, configuration or identity providers with production, but the report should say so. If a non-production environment holds real customer data, treat it as in scope. Confirm the test window and the change freeze with the operations team before work starts.

Cloud accounts, tenants and clusters

List every cloud account, subscription, project, tenant and Kubernetes cluster that hosts in-scope workloads or stores in-scope data. Shared services such as central logging, identity or networking often sit in a separate account, and they still affect the controls described. Confirm each provider's published testing rules before scoping, and record which tests fall under the shared responsibility model so that provider-managed layers are not reported as tested by you.

Applications, APIs and user roles

Name each in-scope application and API, then list the user roles that access them, such as customer, administrator, support agent and service account. Testing only the public login page leaves privileged paths unreviewed, and privileged paths are where access control commitments are most often tested. Agree in writing whether authenticated testing uses seeded test accounts, which roles are covered and how credentials are handled.

Subservice organizations need separate treatment

Hosting providers, payment processors and managed security services may carry part of the controls in the description. Their systems are generally not yours to test, so the scope should separate what you test directly from what you rely on through their own reports or contracts. Ask whether each subservice organization is carved out or included in the description, and document the approach your auditor accepts for it.

Rules of engagement and exclusions

Rules of engagement state the permitted techniques, testing hours, source addresses, escalation contacts, stop conditions and data handling rules. Exclusions, such as denial-of-service testing or social engineering, should be listed with the reason. Confirm that the rules are signed by a named owner and that the tester's independence from the people who built and operate the system is recorded, because the report's credibility depends on both.

What the Trust Services Criteria do not say about penetration testing

The 2017 Trust Services Criteria with the 2022 revised points of focus do not require a penetration test. They do not set a testing frequency, name a tester qualification, define the depth of testing or say that a third party must perform it. The criteria describe outcomes the system must achieve, such as identifying and managing vulnerabilities and monitoring for threats, and leave the mechanism to the service organization. The points of focus help you design and evaluate those controls, but they are characteristics to consider, not separate requirements to pass. Before you commission anything, read your own control descriptions and confirm which vulnerability management and monitoring controls you have committed to in the system description.

A penetration test is therefore one way to evidence those controls, not the control itself. In practice it answers questions an examiner will ask: how do you find weaknesses that scanning misses, how do you decide which findings matter, and how do you know the fixes worked? The auditor decides whether the evidence is sufficient based on how your controls are designed and whether they operated consistently across the examination period. A test that is well scoped but never acted on, or a scope that omits the systems in your description, will not carry the control on its own. Ask your auditor early which controls they expect the test to support, and record that answer in your planning notes.

How a SOC 2 penetration test runs from scoping to retest

The sequence turns a system description into a bounded test, a report the auditor can read, and retest evidence that shows each finding was closed. Each phase produces a document that stands on its own in the examination file.

Confirm the system description and in-scope components
The client's SOC 2 system description defines the services, infrastructure, software, people, data and boundaries the examination covers. DeployOpen maps that description to the hosts, applications, APIs, cloud accounts and identity services that support the in-scope criteria, and records which components are excluded and why. The step closes with a written scope statement the client approves, so the auditor can trace every tested asset back to the system description.
Agree rules of engagement and access
Testing rules cover permitted techniques, testing windows, source addresses, test accounts, data handling, stop conditions and the escalation contact if a critical issue appears during testing. Where a cloud provider or SaaS vendor publishes its own testing policy, the rules follow it. The client confirms in writing who may authorize testing and who receives urgent findings. The step is complete when both parties sign the rules of engagement and the test accounts are provisioned with the agreed privileges.
Prepare the test plan and methodology
The tester documents the test plan before active work starts. It names the methodology, which for web and API components is often the OWASP Web Security Testing Guide, and may add ASVS as the verification standard for application controls. The plan lists the test types, such as authentication and session handling, access control, input handling and configuration review, and maps each to the criteria the client wants evidence for. The plan is complete when the client accepts it as the reference for what the report will and will not say.
Execute testing within the agreed boundaries
Testers perform reconnaissance, manual testing and tool-assisted checks within the rules of engagement. They record activity with timestamps so every finding can be reproduced by the client's team in a controlled manner. Testers pause and notify the escalation contact when they find a condition that could expose sensitive data or disrupt service. The step closes when the planned test cases are complete, and the tester keeps a working log of what was attempted, what succeeded and what was excluded.
Validate findings and assign severity
Each candidate issue is confirmed by the tester, checked for false positives and rated using a severity scale agreed in the plan, with the rating explained in the report. Testers record affected components, the conditions needed to exploit the weakness, and the business impact in the client's environment. Findings that cannot be confirmed are removed rather than carried into the report. The step is complete when every finding has a severity, an evidence record and a reproducible description written at a level the auditor and engineering team can follow.
Deliver the report and remediation plan
The report states scope, methodology, test dates, tester qualifications and independence, findings with evidence and severity, and the limitations of the test. It is written so the client can share the full report with the auditor, and the client decides whether a summary goes to customers. The client assigns owners and target dates for each finding, and the remediation tracker records every change. The step closes when the client accepts the report and the tracker is in use.
Retest remediated findings and record closure
After the client reports fixes, the tester repeats the original test for each closed finding and checks that the control now works as intended. The retest report states, for each finding, whether it is closed, partially addressed or still open, with the evidence used to decide. Findings accepted as risk stay open in the record with the approving owner named. The step is complete when the retest report and the updated tracker are filed together, which gives the auditor a traceable path from finding to fix to verification.

Which weakness categories a SOC 2 penetration test should target

This table lists the weakness categories a penetration test of a SOC 2 in-scope system should probe, what each looks like in that system, and which Trust Services Criteria it bears on. Read it as a scoping checklist: each row should map to a boundary, identity path or change process named in your system description.

Weakness category	What it looks like in an in-scope system	Why it matters to the criteria
Broken authentication and session handling	Weak login flows, missing multi-factor enforcement on administrative paths, session tokens that persist after logout or password change, and password reset logic that can be abused	Supports logical access controls (CC6.1) and authentication of users before access to system resources is granted
Access control flaws	Users reaching records or functions outside their role, such as one customer viewing another's data, or standard accounts reaching admin functions through direct requests	Relates to least privilege and restriction of access (CC6.1, CC6.3) and to confidentiality commitments where they apply
Injection and input validation	Unsanitized input reaching databases, command interpreters or templates in the application, API endpoints that accept unexpected parameter types	Bears on system operations and the integrity of processing (PI1 when in scope) and on protection against unauthorized changes to data
Misconfigured cloud and network services	Storage buckets or management ports reachable from the internet, overly permissive security groups, default credentials on hosted services, and unmanaged egress paths	Relates to boundary protection and restriction of network access (CC6.6) and to configuration management under the system operations criteria (CC7.1)
Exposed administrative interfaces	Consoles, dashboards, debug endpoints or remote access gateways reachable from untrusted networks without strong access controls or logging	Bears on restriction of privileged access (CC6.1, CC6.2) and on monitoring of activity by privileged users (CC7.2)
Weaknesses in change and patch paths	Unpatched components with known exploitable flaws, build pipelines that deploy without review, and secrets stored in code or pipeline variables	Supports change management (CC8.1) and the identification and remediation of vulnerabilities (CC7.1), where findings must be tracked to closure (CC3.2)
Logging and detection gaps	Security-relevant events not recorded, logs not forwarded to a central store, or alerts that do not fire during the test's own activity	Bears on monitoring of system components for anomalies (CC7.2) and on the evidence the auditor can use in a Type 2 period
Data exposure in responses and storage	Verbose error messages, personal or confidential fields returned in API responses, backups or exports readable by unintended roles	Relates to confidentiality (C1.1, C1.2) and privacy commitments where the system description includes them

How the test changes for SaaS platforms, cloud estates and self-hosted systems

In a multi-tenant SaaS product, the provider runs one application that serves many customers, so the auditor's question is usually whether one customer can reach another's data or functions. The test therefore centres on the application and its APIs, the tenant isolation model, authentication and session handling, and administrative interfaces. The system description defines which services, regions and support tools are inside the boundary, and the test scope should follow that list rather than the marketing site or an arbitrary subset of endpoints.

Tenant isolation: Testing focuses on whether identifiers, queries, caches and background jobs keep customer data separated, using test tenants you own.
Authentication and session paths: Login, single sign-on, password reset, token lifetimes and privilege changes are usually the highest-value areas.
Administrative and support tooling: Internal consoles that can act across tenants are often inside the system description and need explicit coverage.
Test accounts and data: Ask for dedicated tenants with realistic but non-production data, and confirm that no live customer records are touched.
Production or staging: Confirm whether the test runs against production, a production-like environment or both, and what change control applies.

Before signing, check that the written scope names each tenant model, environment and admin interface the auditor will expect to see covered.

What drives the cost and duration of a SOC 2 penetration test

This table lists the main cost components of a SOC 2 penetration test, who is paid for each, and what to ask for in a quote. Scope drivers such as applications, cloud accounts, user roles and retest rounds set most of the effort, so compare quotes against the same written scope. A quote follows from that written scope, not from a standard rate.

Cost driver	Who is paid for what	What to ask for in a quote
Applications and APIs in the system description	The tester's effort to map, authenticate to and test each in-scope application and API, including shared services they call	A list of each application and API by name, with the owner, the environment and whether it is in the system description
Cloud accounts and subscriptions	Configuration review and testing time per account, plus the time to confirm provider testing rules and the shared responsibility split	Account count, provider, whether production and non-production are both covered, and any excluded accounts
Internal and external network scope	External testing of public addresses and internal testing from a foothold or network position, each with its own setup and reporting time	IP ranges or address counts, the locations tested, and whether internal testing is included or optional
User roles and privilege levels tested	Time to test authorization between roles, such as customer, staff and administrator, each requiring separate accounts and access checks	The number of roles per application, who provides test accounts, and whether tenant isolation is tested
Test depth and methodology	Time spent on automated scanning versus manual testing of logic, authentication and access control flaws	Whether the test is a black box, gray box or white box effort, and which methodology and checklists the tester applies
Environments tested	Preparation and testing time for each environment, and any extra work to verify findings against production-like data	Which environments are in scope, whether production testing is allowed, and the testing windows and change freezes
Retest scope and timing	A retest is usually a separate, smaller effort to verify that the findings from the first round were closed, and it is often priced as a follow-on item	Whether one retest round is included, how long the tester will hold the findings open, and how retest evidence is written up
Report format and deliverables	Time to write the full report, an executive summary and a remediation plan, and any separate summary letter for customers or auditors	Sample report structure, whether a separate letter is included, and what the auditor or customer will receive and in what format

How the report and retest serve as evidence in a Type 1 or Type 2 examination

A Type 1 examination assesses design at a point in time, while a Type 2 examination assesses whether controls operated effectively over a period. That difference decides how much a penetration test helps. In a Type 1, the test shows that the vulnerability management control was designed and was working on the date assessed, so the report is supporting evidence rather than proof of ongoing operation. In a Type 2, a test performed inside the examination period, followed by a retest that confirms findings were closed, carries much more weight because it shows the control operating across the period. Confirm the examination window with your auditor before you fix the test date, and plan the retest so it also falls inside that window where possible. The auditor decides what evidence is sufficient. DeployOpen does not issue audit reports, attestations or certifications, and a penetration test report is one input the auditor weighs alongside the rest of the control evidence. Before testing starts, agree in writing with your auditor which items they will accept: the full technical report or a summary, the statement of scope and its link to the system description, the date and tester identity, the list of findings with severity and status, and the retest evidence that closes each finding. Ask them whether they want the report, the remediation tickets, or both, and how they will handle findings that are accepted as risk rather than fixed.

Keep the evidence trail connected from end to end. Each finding should map to a ticket with an owner, a remediation date, a description of the fix, and a retest result that references the original finding identifier. Note any finding that is risk-accepted and record the approval. Auditors commonly sample these items, so a report that cannot be traced to a closed ticket is weaker than one that can. Share the scope and retest plan with your auditor early, because a retest performed by the same team that wrote the original report should be explained, and the auditor may ask how the tester was kept independent of the remediation work. Finally, decide how the report will be shared with customers. Many customers accept a summary letter with the full report available under a non-disclosure agreement, but this is a commercial decision that should match what your auditor is willing to rely on. Treat the auditor's acceptance criteria as the baseline, then add the customer-facing material on top, so the same evidence set answers both audiences without being rewritten for each one.

What you receive and whether it satisfies your auditor or customer

A penetration test for SOC 2 produces several artifacts, and each one serves a different reader. The cards below cover what the report contains, how retest evidence closes findings, and which version fits an auditor versus a customer, so you can agree acceptance before testing starts.

Scope and methodology section

The report should state which systems were tested, mapped to the system description your examiner is reviewing, and which test types were performed, such as external network, internal network, web application or API testing. It should also name the methodology used and the testing dates. Check that every system named in the in-scope boundary appears here, and that any exclusions match the boundary your auditor has accepted. Ambiguous scope is the most common reason an examiner asks follow-up questions.

Findings with severity ratings

Each finding should include a description, the affected asset, the severity rating and the reasoning behind it, along with the weakness category it falls under. Ask how severity is assigned and whether it reflects your environment, not only a generic score. Findings should describe the weakness and its impact without step-by-step exploitation detail, since the report may be shared with customers and auditors. A finding without a clear severity basis is hard for a Type 2 examiner to evaluate against your remediation process.

Remediation advice and retest results

Remediation guidance should be specific enough for an engineering team to act on, and each finding should record its status after retest: resolved, partially resolved, accepted risk or open. Retest evidence is what closes a finding in an examination, so ask whether retesting is included in the fixed-scope quote and whether it is performed by the same tester. Keep retest dates and the corrected configuration evidence together so the examiner can trace each finding from report to closure.

Full report for auditors

The full report is the document your SOC 2 auditor will request when testing forms part of the evidence for the trust services criteria in scope. It contains technical detail the auditor needs to assess the testing process, so it should not be widely distributed. Confirm with your auditor, before testing begins, that the report format, depth and tester qualifications meet their expectations. Testing does not itself produce an opinion; the auditor's examination determines whether the controls operated effectively.

Summary letter for customers

A summary letter is a shorter document that states the test was performed, its scope, the period, the tester type and the high-level outcome, with open findings described at a general level. Customers reviewing vendors often accept this in place of the full report, but many will request the full report under a non-disclosure agreement. Agree the summary format with your key customers before testing, because a letter that omits retest status tends to prompt follow-up requests.

Tester independence and evidence retention

Record who performed the test, their qualifications and whether they were organizationally independent from the team that built or operates the system. Store the report, the signed scope document, the rules of engagement and retest records in a location your auditor can access for the examination period. Ask your provider how long they retain working papers and whether they will provide them on request. Auditors often ask about tester independence, so having this documented up front avoids delays.

What you need to prepare before the test starts

Clear preparation shortens scoping and reduces disruption, and for a SOC 2 test it starts with the system description. Before the provider scopes the work, gather the current system description and an asset list that matches it: the in-scope services, production and supporting environments, data stores, identity providers, and the third-party services the system relies on. If the asset list and the description disagree, the scope will be argued over in the kickoff call instead of agreed in writing. Confirm which systems carry the commitments made to customers, because those are the systems an auditor and a customer will expect the test to cover.

Next, arrange access and named people. Ask the provider what test accounts it needs, typically one standard user and one privileged role per in-scope application, plus any API credentials, and create them with the roles a real customer or administrator would hold, not with shared or permanent super-user rights. Name a technical contact for each in-scope system who can answer questions within the working day, a contact who can approve changes to firewalls or rate limits, and an escalation contact for anything that looks like a live incident. Agree the change freeze windows in advance so that deployments do not land during active testing, and record who can stop the test.

Hosting and cloud providers have their own rules, so check them before the test is booked. Confirm whether your provider requires notice, pre-approval or a published testing policy for the services in scope, and whether third-party SaaS platforms in the system description permit testing at all. Decide how sensitive data will be handled: ask for test data rather than production customer records, agree how any credentials, personal data or screenshots found during testing are stored and deleted, and confirm where the report and evidence will be kept. Confirm these points with each provider and with your own legal and privacy teams rather than assuming the answers.

Questions buyers ask about SOC 2 penetration testing

Does SOC 2 require a penetration test?

No. The AICPA 2017 Trust Services Criteria do not name penetration testing as a required control activity, so no criterion says you must run one. What the criteria do require is that you manage vulnerabilities, detect and respond to threats, and monitor controls that protect the system described in your report. A penetration test is a common way to show that those controls work, and auditors and customers frequently ask for one. Your auditor decides what evidence is sufficient for your system, so confirm the expectation with them before you commit to a scope.

How often should a SOC 2 penetration test be done?

The Trust Services Criteria do not set a frequency. The interval should follow your risk assessment, your change rate and what your auditor and customers accept. Many organizations align the test with the audit period, so that evidence covers the whole Type 2 window rather than a single day. Test again after significant architecture changes, new externally exposed services or major releases. If a frameworks you also follow sets a frequency, such as annual testing in PCI DSS or CIS Safeguard 18.2 guidance, use the stricter interval so one test can serve both needs.

Who may perform a SOC 2 penetration test, and does independence matter?

SOC 2 does not prescribe a tester qualification, so the answer comes from what your auditor and customers will accept. In practice, buyers look for a tester with demonstrable technical skill in the systems in scope, a written methodology and a report that names the scope, dates and findings clearly. Independence matters for credibility. Testers who build or operate the system they attack are less persuasive as evidence. Ask prospective providers how they separate testing from remediation, and confirm the requirement with your auditor. For reference, PCI DSS requirement 11.4.3 requires a qualified tester with organizational independence, which many buyers adopt as a sensible benchmark.

Is a vulnerability scan enough for SOC 2?

A vulnerability scan can satisfy part of your vulnerability management evidence, but it is usually not enough on its own. Scans identify known weaknesses at a point in time. A penetration test checks whether those weaknesses, and combinations of them, can be exploited against your actual architecture, including authentication and access paths. Many buyers run scans continuously and add periodic penetration tests for the external perimeter and high-risk applications. Ask your auditor whether they expect both, and keep the scan results and remediation records with the test report so the evidence reads as one lifecycle.

What affects the cost and duration of a SOC 2 penetration test?

Cost and duration follow the written scope. The main drivers are the number of in-scope systems, such as external hosts, web applications, APIs and cloud accounts, the depth of testing (authenticated or unauthenticated, internal or external), the number of user roles to test, and whether retesting is included. Testing a system description with many services costs more than a narrow test of one customer-facing product. Ask for a quote that lists in-scope assets, test types, methodology, reporting format, retest terms and who performs remediation verification. DeployOpen works on fixed-scope engagements, with scope, deliverables and timelines agreed in writing before work starts, so the quote follows from that scope.

What does the client need to provide for a penetration test?

The client usually provides the scope inputs, access and people. You will need an up-to-date system description and network or asset inventory, test accounts for each role, agreed testing windows, named contacts for escalation, and written authorization covering the systems and cloud providers involved. Confirm each provider's published testing rules before testing cloud resources. Expect time from your engineers to answer questions, validate findings and review draft results. Clear inputs shorten the engagement and reduce the risk that testing disrupts production or reaches systems outside the agreed scope.

Can our own team run the SOC 2 penetration test internally?

An internal team can perform testing, but the question is whether the evidence will be accepted. Auditors and customers generally look for a tester with appropriate skill, a documented methodology and sufficient separation from the team that built and operates the system. If internal staff test their own work, expect questions about independence and objectivity. Many organizations use internal teams for continuous scanning and triage, then commission an external tester for the formal annual report. Confirm acceptance with your auditor before the engagement, and keep the methodology, scope, findings and retest records together for the examination.

What to check before you sign with a penetration testing provider

A SOC 2 penetration test is only as useful as the provider behind it and the paperwork around it. The cards below cover the decisions that determine whether the report will hold up with your auditor and your customers. Check each item in writing before work starts.

Tester qualifications and independence

Ask who will run the test, what security certifications or track record they hold, and whether they will be independent of the team that builds, operates or monitors the controls being tested. A tester who also runs your vulnerability management or remediation work weakens the test as evidence, because the auditor may question whether the findings were filtered. Ask for named testers and their experience with systems similar to yours. Confirm that DeployOpen's testers can be named in the statement of work.

Written scope tied to the system description

Require a written scope that maps each in-scope asset to the system description used in your SOC 2 examination. Confirm which production hosts, applications, APIs, cloud accounts and identity components are included, and which are excluded with a stated reason. Ask how the scope will change if your architecture changes during the examination period. Mismatches between the tested assets and the described system are a common reason auditors question a report.

Rules of engagement and testing windows

The rules of engagement set what the tester may do, when, from where and what happens if something breaks. Check the permitted techniques, the source IP ranges, the testing window, the named contacts for escalation, and the stop conditions. Confirm how the provider handles accounts with real customer data and whether third-party platforms are in scope. Any constraints from your cloud provider's testing policy should be written into this document.

Sample report and redaction approach

Ask for a sample report before you sign, and confirm what it contains: an executive summary, methodology, scope, each finding with severity and evidence, and remediation guidance. Agree in advance how sensitive details will be redacted when the report is shared with customers or auditors. A sample that shows only a headline score or a generic template will not help you judge the depth of the work. Confirm whether the report states the dates, scope and tester names that an auditor will look for.

Retest terms and finding closure

Clarify whether retesting is included, how many rounds are covered, how long after the initial report it must be completed, and how retest results are documented. Your auditor will look for evidence that significant findings were corrected and verified, so a retest that confirms closure matters as much as the original report. Ask whether the retest is priced in the original quote or sold separately, and whether it can cover findings that you remediate after the examination window closes.

Data handling, insurance and confidentiality

Testers handle sensitive system details, credentials and sometimes customer data. Confirm where test artifacts are stored, how long they are retained, who can access them, and how they are deleted at the end of the engagement. Ask for the provider's confidentiality terms and the professional liability and cyber insurance coverage they carry. Check whether the agreement covers subcontractors and whether any testing data leaves your environment or the provider's secured systems.

How DeployOpen scopes, tests, reports and retests for SOC 2

DeployOpen starts from the system description and the boundary the auditor will examine, then agrees a written, fixed scope before any testing begins. We run the test, document results and remediation status in a form your auditor and customers can trace, and offer retesting so findings can be closed with evidence.

How we scope

We map the penetration test boundary to the systems named in your SOC 2 system description and the in-scope Trust Services Criteria.
Scope, deliverables and timelines are agreed in writing before work starts, since most engagements are fixed-scope.
Confirm with your auditor whether they expect external, internal, application or cloud testing, because the criteria do not prescribe a method.

How we build

We set rules of engagement, test accounts and time windows with your team so production risk is agreed in advance.
Testing covers the agreed application, API, network and cloud components, with weakness categories recorded against each in-scope system.
Testing is performed against the agreed scope only, and any change to scope is documented in writing before it is tested.

How we hand over

You receive a written report that lists each finding, its affected system, severity, evidence of exploitability and recommended corrective action.
Remediation tracking records owners, status and dates for each finding, so the auditor can trace how issues were closed.
Documents are structured to support your auditor's review, and DeployOpen does not issue audit reports or attestations.

How we support

Retesting verifies that corrective actions for in-scope findings work, and the retest results become part of the evidence set.
Ongoing support, upgrades and continuous testing are available as retainers for organizations that test on a recurring cycle.
Confirm with your auditor which retest window and report format they accept before the engagement is scheduled.