NIST SP 800-115 vs PTES: which one should your penetration test follow?
A buyer who must document a penetration testing methodology should know that PTES works best as the engagement structure and NIST SP 800-115 works best as the technique and program reference. Use PTES when you need a step-by-step execution and reporting flow that a provider can follow from pre-engagement interactions through to reporting. Its seven main sections (pre-engagement interactions, intelligence gathering, threat modeling, vulnerability analysis, exploitation, post exploitation and reporting) map directly onto a statement of work and a findings report. Use NIST SP 800-115 when you need a government-origin technique guide, a phased view of testing as an ongoing program, and a rules of engagement template in Appendix B that you can adapt. Its four penetration testing phases (planning, discovery, attack and reporting) are coarser than PTES, so it leaves more of the execution detail to the provider's own procedures.
The two are often combined, and the NIST guide itself supports that. It notes that organizations often mix techniques to reach an in-depth assessment at an acceptable level of risk, and it does not endorse one methodology over another. A practical pattern is to write the rules of engagement from NIST's Appendix B, run the engagement in PTES sections, and keep a schedule of periodic penetration tests alongside the regularly scheduled scanning that NIST recommends. Before you adopt either, confirm with your provider which sections they will actually deliver and how they map their report to your internal template.
For PCI DSS requirement 11.4.1, the requirement asks for a documented penetration testing methodology built on industry-accepted approaches, with coverage of the entire cardholder data environment perimeter and critical systems, testing from inside and outside the network, segmentation validation, and application-layer and network-layer testing. Neither NIST SP 800-115 nor PTES is named as the mandated methodology, so your assessor decides whether your document is acceptable. Ask your assessor which references they accept, record the choice and the mapping to each sub-requirement in your methodology document, and confirm with your provider that the scope and reporting will produce the evidence your assessor expects.
How NIST SP 800-115 and PTES differ on structure, scope and guidance
This table sets NIST SP 800-115 against PTES on how each organizes a test, how far each goes into technical detail, and how current each one is. Read each row as a question to put to your own testing scope, not as a ranking of which standard is better.
| Dimension | NIST SP 800-115 | PTES |
|---|---|---|
| Primary purpose | A technical guide to information security testing and assessment, covering review, identification, analysis and validation techniques, with penetration testing as one technique among several | A penetration testing process standard covering tests from a routine web application or network test to a full red team engagement |
| Structure | Four penetration testing phases: planning, discovery, attack and reporting | Seven main sections: pre-engagement interactions, intelligence gathering, threat modeling, vulnerability analysis, exploitation, post exploitation and reporting |
| Rules of engagement | Provides a rules of engagement template in Appendix B that buyers can adapt | Places pre-engagement interactions as its first section, so scoping and agreement come before any testing begins |
| Technical depth | Describes techniques at a general level across many assessment types, and does not endorse one methodology over another | Main page sets out the process; technical guidance is published separately, so the buyer must check which technical references the provider follows |
| Published version | Dated September 2008 on the NIST publication | Main page describes it as v1.0; a planned v2.0 would add intensity levels for expected adversary sophistication |
| Maintenance status | Confirm with NIST whether a newer revision is in progress before citing it as current | Confirm the status of the planned v2.0 and of the separately published technical guidance before citing either |
| Best fit | Scoping a broad assessment program that mixes reviews, scanning and penetration testing, and a citable government reference | Scoping a defined penetration test or red team engagement where process steps and reporting are the main gap |
| What to confirm in a statement of work | Which NIST phases map to each deliverable and which Appendix B terms apply to your systems | Which PTES technical guidance version the provider uses and whether intensity levels are part of the agreed scope |
Which methodology fits which buyer situation
When the main driver is an assessor asking for a documented methodology, the question is less about which document is more detailed and more about which one you can point to, map to your procedures and defend. NIST SP 800-115 is a government technical guide that states NIST does not endorse one methodology over another, so it reads as a neutral reference that you adapt. PCI DSS requirement 11.4.1 asks for a documented penetration testing methodology built on industry-accepted approaches, which means your choice must be justified in your own program documents, not just named.
- Neutral framing: NIST SP 800-115 frames testing as one part of a broader assessment program, which suits organizations that need to show a documented, risk-based approach.
- Phase structure: Its four phases (planning, discovery, attack and reporting) map cleanly onto a written procedure and an evidence trail.
- Rules of engagement: Appendix B gives a template that assessors commonly look for during review of scope and authorization.
- PTES as a complement: PTES's seven sections give more operational depth on pre-engagement and reporting, which can fill gaps in a procedure built on NIST.
- Scope of the requirement: Confirm with your QSA which methodology reference they accept, since the standard requires industry-accepted approaches without naming one.
Check with your assessor and qualified security assessor before you finalize the methodology document, because acceptance is their call, not the publisher's.
For one bounded engagement, such as an external network test or a single web application, the methodology matters less than the technical catalog your testers use during execution. PTES describes its scope as spanning from a routine web application or network test up to a full red team engagement, and its technical guidance is published separately, which makes it a practical process frame for a single job. NIST SP 800-115 gives the broader assessment context but leaves most technique detail to the tester, so a web test usually needs a more specific reference alongside it.
- Process frame: PTES's pre-engagement and reporting sections give a clear structure for scoping, rules and deliverables on one target.
- Technique depth: For web applications, pair the process with a dedicated test catalog rather than relying on either general document alone.
- Network work: NIST's review and validation technique categories help define when scanning and penetration testing should run together.
- Condition to change: If the statement of work is for an application test, the web catalog should be named explicitly in the contract.
- Confirm: Ask the provider which technical guidance their testers follow and whether it is written into the deliverables.
Confirm that the chosen reference is cited in the statement of work and that the provider's report uses the same phase names.
A red team engagement tests detection and response against a realistic adversary goal, not only the presence of vulnerabilities. PTES explicitly covers engagements up to full red team scope, which makes it a common process reference for adversary-style work. NIST SP 800-115 notes that organizations often combine techniques to reach an in-depth assessment at an acceptable level of risk, which supports layering a red team exercise on top of other testing. For regulated financial entities, TIBER-EU is the more specific framework, running threat intelligence-based red team tests with at least 12 weeks of active testing and mandatory purple teaming.
- Goal-based scope: Red team work defines objectives and rules up front, so the rules of engagement section carries more weight than in a standard test.
- Process reference: PTES's threat modeling and post-exploitation sections give structure for adversary-style phases.
- Layered model: NIST's guidance on combining techniques supports pairing red teaming with scans and penetration tests.
- Regulated scope: Where a regulator runs TIBER-EU or CBEST, that scheme's requirements govern the exercise, not a general methodology.
- Future item: PTES's planned v2.0 would add intensity levels to state adversary sophistication; confirm its release status before writing it into a contract.
Ask the provider how they will handle the rules of engagement, deconfliction and detection measurement before scope is signed.
An internal security team writing its own test standard usually needs both references, because they answer different questions. NIST SP 800-115 supplies the assessment framing, the technique categories and the rules of engagement template. PTES supplies a process model with seven concrete sections and separate technical guidance. The main decision is which one anchors the standard and which one fills gaps, and that choice should follow who will read the document and who will audit it.
- Anchor choice: Use NIST SP 800-115 as the anchor when auditors and leadership expect a government-published reference.
- Process detail: Borrow PTES's section structure when testers need concrete steps for intelligence gathering and reporting.
- Technique coverage: Add a web or application catalog for testers who work on applications, since neither general document covers web techniques in depth.
- Currency: Record the version and date of every reference you cite, and review the standard when a referenced document changes.
- Governance: Name an owner who maintains the standard and records each deviation.
Before publishing the standard, have a qualified assessor confirm that the combination satisfies any requirement it is meant to support.
How the phases of each approach map onto an engagement
The fastest way to compare these two documents is to set the four penetration testing phases in NIST SP 800-115 (planning, discovery, attack and reporting) beside PTES's seven sections and see where the lines fall. NIST's planning phase covers what PTES calls pre-engagement interactions, including scope and the rules of engagement, for which NIST supplies a template in Appendix B. NIST's discovery phase is where PTES does most of its extra work. PTES gives intelligence gathering and threat modeling their own sections, ahead of vulnerability analysis. NIST folds those activities into discovery without naming threat modeling as a step. A team that wants a threat model in its statement of work should ask for it by name, because the NIST phase names do not make it a separate deliverable.
The two documents also differ in where they place the testing itself. NIST classifies penetration testing as a target vulnerability validation technique, alongside password cracking, social engineering and application security testing, and separates it from passive review techniques that pose minimal risk to systems. NIST also suggests regularly scheduled network and vulnerability scanning, interspersed with periodic penetration testing. PTES treats exploitation and post exploitation as sections of one bounded engagement, which maps most closely onto NIST's attack phase. The planning consequence is that a NIST-based program runs a scanning cadence and a penetration testing cadence, while a PTES-based engagement is a single exercise with its own start and close. Neither document contains the other, so a buyer should treat them as complementary.
What each approach finds and what it misses
NIST SP 800-115 and PTES answer different questions. One structures a continuing program of reviews, scans and tests, and the other structures a single engagement around an adversary path. The cards below show what each approach surfaces, where each leaves gaps, and what a buyer should verify before relying on either one.
Findings from a NIST-structured program
NIST SP 800-115 treats testing as a mix of review techniques, target identification, and vulnerability validation. Its guidance suggests regularly scheduled network and vulnerability scanning, interspersed with periodic penetration testing. This pattern surfaces configuration drift and known weaknesses between tests, and the periodic tests confirm whether those weaknesses can be chained. Check that your program records which technique produced each finding, so you can show coverage across techniques rather than a single annual report.
Findings from a PTES engagement
PTES organizes a test from pre-engagement interactions through threat modeling, vulnerability analysis, exploitation, post exploitation and reporting. Because threat modeling comes before exploitation, the findings tend to be attack paths that connect several weaknesses toward a business target, not isolated issues. Ask the provider how the threat model was agreed with you and which assets were named as objectives in the rules of engagement.
Gaps in pure technique checklists
A checklist of techniques shows that a test touched each area, but it does not show whether the techniques were combined into an attack chain. NIST notes that organizations often combine techniques to reach an in-depth assessment at an acceptable level of risk, which a checklist alone does not guarantee. Ask for evidence that the tester moved from one finding to the next, and for an explanation of where the technique list stopped.
Gaps in engagement-only scope
A single PTES engagement usually covers the scope and objectives agreed for that window. Assets outside the agreed scope, and weaknesses that appear after the test, go unexamined until the next engagement. This gap matters most for fast-changing cloud and CI environments. Confirm how the program schedules scanning and retests between engagements, and who owns that calendar.
Automated-only testing does not satisfy PCI requirements
The PCI SSC penetration testing guidance describes penetration testing as essentially a manual process and states that simply running an automated tool does not satisfy the requirement. A scanner run labeled as a penetration test can produce a long report while missing chained exploitation and logic flaws. Before scoping, ask whether the tester will perform manual exploitation and document the methodology used, whichever reference you adopt.
Which methodology to cite for PCI DSS 11.4.1
Requirement 11.4.1 asks for a documented penetration testing methodology built on industry-accepted approaches, not for a named framework. Read against the requirement, your methodology document has to cover the full perimeter of the cardholder data environment and critical systems, testing from both inside and outside the network, segmentation validation, and both application-layer and network-layer testing. PCI DSS v4.0 does not name NIST SP 800-115 or PTES, so the choice is yours to make and defend. Pick the one that best matches the scope you will test and the depth your team can produce, then write it into the methodology document with its version and the sections you rely on. NIST SP 800-115 is a technique guide that says it does not endorse one methodology over another, and PTES is a seven-section execution standard with technical guidance published separately. Many assessors accept either as the base, and many buyers cite PTES for workflow and NIST for technique detail. Confirm that choice with your QSA before the engagement starts, since acceptance is their call.
Be careful with the phrase manual work. The PCI SSC's *Penetration Testing Guidance* (v1.1, September 2017) describes penetration testing as essentially a manual process and states that simply running an automated tool does not satisfy the penetration testing requirement. Your methodology should therefore show where human-led exploitation, chaining and business logic testing happen, and the scan output should be treated as input to that work rather than as the test. Ask any provider to name the testers who will perform the manual phases, the tools they will use, and how their findings will be verified and reported against the CDE scope. A methodology that lists only tool categories will be harder to defend.
Before you sign the statement of work, check three things with the tester and the QSA: that the methodology citation names a specific version and the sections used, that the segmentation validation step is described in the same document, and that the scope statement traces each in-scope system back to the CDE boundary. Also confirm whether the QSA expects the methodology to be cited in the report on compliance or only in the supporting evidence, because the answer changes how much detail the methodology document needs. The PCI DSS v4.0 SAQ D for Service Providers is a useful place to see how the requirement is framed for service providers, but the authoritative wording and any assessor expectations should be confirmed directly with your QSA.
What drives cost and effort under each methodology
Neither NIST SP 800-115 nor PTES sets prices or durations, so the cost of a test follows from the written scope and the methodology the provider applies. The cards below cover the drivers that move effort most, and the questions to put to any provider before accepting a quote.
Scope size and in-scope systems
Effort scales with the number of in-scope hosts, applications, networks and cloud accounts, and with how many of them are critical. NIST SP 800-115 treats planning as a distinct phase, so the provider must agree the target list, IP ranges and application versions before testing starts. Ask the quote to state the count of systems per layer, whether segmentation validation is included, and what happens if the target list changes mid-engagement.
Depth of exploitation and manual work
PTES places exploitation and post-exploitation as separate sections, and each one adds hours of manual work that automated scanning cannot replace. PCI SSC's penetration testing guidance describes the activity as essentially manual, so a quote that is mostly tool output will carry lower effort than one that includes manual exploitation. Ask which phases are manual, which tools are used, and how far post-exploitation is permitted to go.
Pre-engagement and rules of engagement
PTES makes pre-engagement interactions its first section, and NIST SP 800-115 provides a rules of engagement template in Appendix B. Drafting the rules, agreeing contacts, escalation paths and testing windows takes client and provider time before any testing begins. Ask whether the quote includes this work, who signs the rules of engagement, and whether a second round of drafting is priced in.
Reporting depth and format
PTES places reporting last and treats it as a deliverable in its own right, while NIST SP 800-115 lists reporting as the fourth penetration testing phase. A short findings list costs far less to produce than a report with reproduction steps, risk narrative, executive summary and remediation guidance for each finding. Ask the quote to specify report sections, the number of review cycles, and whether the report is delivered in a format your ticketing or GRC tool can import.
Retest and remediation validation
Retesting after fixes is usually a separate line item, and it recurs each time a finding is remediated. Under a methodology that re-validates detections after testing, the client may need extra cycles to confirm that fixes hold. Ask whether one retest round is included, how retests are scoped, which findings qualify, and whether validation of fixes is billed per finding or per day.
Client-side staff time
The client carries effort that rarely appears in the provider's quote: scoping workshops, access provisioning, test accounts, monitoring staff during testing, and review of findings. These costs fall on internal teams and are easy to undercount. Ask the provider to list the client roles and hours it expects, which systems require change tickets, and who is responsible for coordinating with hosting providers or cloud platforms.
What each approach hands you at the end of the engagement
This table compares the artifacts a NIST SP 800-115 aligned program and a PTES-structured engagement typically produce, row by row. Read the cells as typical outputs, then use the final row to confirm each item in the statement of work, since neither guide mandates a specific deliverable format.
| Deliverable | NIST SP 800-115 aligned program | PTES-structured engagement |
|---|---|---|
| Signed rules of engagement | Built from the rules of engagement template in Appendix B, covering scope, timing, contacts and authorization | Produced in the pre-engagement section, which covers scope, goals and client interactions before testing starts |
| Methodology document | Describes the planning, discovery, attack and reporting phases and the techniques chosen for the assessment | Maps the seven main sections to the work performed, with technical guidance referenced separately |
| Phase or section records | Records per phase, such as planning decisions, discovery results and attack activity | Records per section, such as intelligence gathering, threat modeling and exploitation notes |
| Findings report | Typically a report covering validated vulnerabilities and the reporting phase outputs, format set by the provider | Typically a reporting section covering findings, impact and recommendations, format set by the provider |
| Evidence | Captured per technique and per phase; retention and chain of custody are not defined by the guide, so confirm them | Captured during exploitation and post exploitation; retention and handling are not defined by the standard, so confirm them |
| Retest output | Not specified by the guide; a retest is usually a separately scoped activity, so request it explicitly | Not specified by the standard; request a retest and its output in the statement of work |
| Confirm in the statement of work | Named methodology, rules of engagement version, report format, evidence handling and retest terms | Named methodology version, rules of engagement version, report format, evidence handling and retest terms |
How long does a penetration test take and what does it need from my team?
Is NIST SP 800-115 or PTES mandatory for a penetration test?
Neither document is a law or regulation, so neither is mandatory on its own. NIST SP 800-115 is a technical guide, and NIST states that it does not endorse one methodology over another. PTES is a community standard with seven main sections, and its technical guidance is published separately. What makes a methodology required is the obligation you operate under. For cardholder data, PCI DSS requirement 11.4.1 requires a documented penetration testing methodology built on industry-accepted approaches, so the document must exist and be defensible to your assessor. Confirm which approaches your assessor accepts before you sign a statement of work.
What drives the cost of a penetration test?
The provider is paid for tester time across planning, testing, reporting and any retest, so cost follows the work in scope. The main drivers are the number of systems and applications, whether testing covers only external targets or also internal and authenticated access, whether social engineering or a red team exercise is included, and whether testing runs against production or staging. The engagement itself is usually a one-time cost per cycle. The recurring part is the cadence: CIS Controls v8.1 Safeguards 18.2 and 18.5 ask for external and internal penetration tests at least annually. DeployOpen engagements are usually fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and it does not publish a price list. Ask every provider for an itemized quote that shows days by role, assumptions, included retests and report formats.
How much of my team's time does a penetration test need?
The time your team commits depends on the scope and the access model, so ask the provider for expected client hours by role before the test starts. In most engagements, a named executive sponsor signs the rules of engagement, a technical contact approves test windows, system owners provide accounts and access, and someone triages findings and assigns fixes. NIST SP 800-115 provides a rules of engagement template in Appendix B, which is a useful checklist for capturing these roles, contact points and emergency procedures. Your team should also plan time for a retest after remediation, which is often where delays appear. Ask the provider to confirm which of these tasks they expect you to perform and which they perform themselves.
Can my own team run a penetration test using NIST SP 800-115?
Yes, NIST SP 800-115 is written for organizations that conduct their own assessments. It describes four penetration testing phases: planning, discovery, attack and reporting. The guide also explains that penetration testing uses real exploits against production systems and data and carries high risk, while review techniques are passive and pose minimal risk. An in-house team needs skilled testers, safe exploitation practices, careful change control and a reporting process that fits your risk register. Independence is a separate question. NIST SP 800-53 control CA-8 has an enhancement for an independent penetration testing agent or team, and SP 800-53B selects CA-8 only in the high baseline. If your obligations require independence, an external provider or an independent internal team may be needed.
Does PTES cover red teaming as well as penetration testing?
Yes, the PTES main page states that its scope runs from a routine web application or network test to a full red team engagement. It also says a planned v2.0 would add intensity levels, so an organization can state how sophisticated an adversary it expects. Confirm the current status of that version with the publisher before you cite it. A red team exercise usually needs more than the standard test plan. It requires an agreed adversary profile, clear limits on what testers may do, and a method for deciding when to stop. Regulator-led schemes add further rules. TIBER-EU, for example, requires at least 12 weeks of active testing and mandatory purple teaming, and it produces no pass or fail result. Ask the provider which adversary model they will use and how they will document it.
How do penetration tests fit with scheduled vulnerability scanning?
NIST SP 800-115 suggests regularly scheduled network and vulnerability scanning, interspersed with periodic penetration testing. Scanning is low risk and can run often, while penetration testing is deeper and runs on a planned cycle. The two do different jobs, so a scanner report does not replace the manual work. The PCI SSC's penetration testing guidance says that simply running an automated tool does not satisfy the penetration testing requirement. In practice, scans catch known weaknesses at volume, and the penetration test validates exploitability, chains weaknesses together and checks whether your detections fire. CIS Safeguard 18.4 asks for security measures to be validated after each test. Ask providers how they will use your scan output as input, how they will separate automated findings from manually validated ones, and how they will report false positives.
Do I need a CREST-accredited provider for a penetration test?
CREST accreditation is not a general requirement for every penetration test, but some schemes name it. CREST is a UK not-for-profit company that accredits member companies and certifies individuals in disciplines including security testing, red teaming and threat intelligence. The Bank of England names CREST as the accreditation and certification body for CBEST. Check whether your regulator, customer contract or assurance scheme names a specific body or certification. If it does, ask the provider for the exact accreditation scope and the certifications held by the people who will test your systems, then verify both with CREST directly. DeployOpen does not issue audit reports, attestations or certifications, and independent auditors and certification bodies do that work. Ask every provider for the same written evidence so the comparison stays fair.
How to combine NIST SP 800-115 and PTES in one program
Most mature programs do not pick one of these documents. The practical pattern is to use NIST SP 800-115 for program logic and PTES for the mechanics of each engagement. NIST suggests regularly scheduled network and vulnerability scanning, interspersed with periodic penetration testing, and it provides a rules of engagement template in Appendix B. Use that template to set the governance layer: who authorizes testing, which systems are in scope, testing windows, emergency contacts and what happens when a tester reaches production data. PTES then supplies the engagement sections (pre-engagement interactions, intelligence gathering, threat modeling, vulnerability analysis, exploitation, post exploitation and reporting) that testers follow inside each window. Confirm with your team that the rules of engagement signed under Appendix B reference the PTES sections the testers will use, so that scope and authorization are not reinterpreted mid-test.
An illustrative example: a bank runs quarterly authenticated vulnerability scans and an annual external penetration test. The scanning calendar and the rules of engagement follow the NIST structure. Each penetration test is then contracted as a PTES-structured engagement, with the pre-engagement section producing the scope, the threat model and the reporting format. Findings from each test feed back into the scan schedule, so that the next quarter's scans check whether the exploited weaknesses have been closed. The same bank might also map the PTES report sections to its risk register, so the security committee sees the same finding identifiers across both processes. Nothing in this example is a requirement. It shows one way the two sets of artifacts can share identifiers and dates.
Before you rely on this structure, confirm two things. First, ask your assessor or qualified security assessor whether a documented program built this way satisfies the methodology wording in PCI DSS requirement 11.4.1 for your environment, and get the answer in writing. Second, confirm that your testing firm will deliver a report and a rules of engagement that map to both documents, and ask how the firm handles the PTES technical guidance, which is published separately from the main page. Those two confirmations decide whether the combined program is an efficient model or a source of audit disagreement. Keep the mapping document under version control so changes to either standard are visible when you next review the program.
How DeployOpen scopes and runs penetration tests against a chosen methodology
The sequence below turns a chosen methodology into a written, bounded test whose evidence the client keeps and can hand to an assessor. DeployOpen performs the testing and reporting, while the client's assessor or certification body decides what the evidence proves.
Choose the methodology and map it to the client's obligations
Before scoping, the client and DeployOpen agree which reference will structure the test. NIST SP 800-115 gives a four-phase technique guide that does not endorse one methodology over another, while PTES offers seven sections with technical guidance published separately. Where a payment or regulatory requirement applies, the team confirms with the assessor which methodology they will accept. Output: a short methodology decision record naming the reference and the requirements it serves.
Define the fixed written scope
DeployOpen and the client define the targets, network and application boundaries, included environments, test types and exclusions in a written scope document. Most engagements are fixed-scope, so scope, deliverables and timelines are agreed in writing before any testing begins. Output: a signed scope statement that lists in-scope systems and the reasons for each exclusion.
Agree rules of engagement and testing windows
The parties complete the rules of engagement, covering permitted techniques, testing windows, source IP addresses, emergency contacts, data handling and the procedure for stopping a test. NIST SP 800-115 provides a rules of engagement template in Appendix B that teams can adapt. Output: signed rules of engagement that the client's operations and security staff have acknowledged.
Gather intelligence and model threats
Testers collect information about the targets from documentation, architecture diagrams and interviews, then model the threats that matter for the scope. This is the step where PTES's intelligence gathering and threat modeling sections and NIST's discovery phase overlap most. Output: a target inventory and threat notes that justify the attack paths the testers will attempt.
Run discovery, vulnerability analysis and controlled exploitation
Testers identify weaknesses, validate them and attempt exploitation within the rules of engagement, following the chosen methodology's phase order. Automated scanning supports the work, but the testing is manual at its core, which is the approach PCI SSC's guidance expects for penetration testing. Output: a log of attempted actions, validated findings and any evidence collected during exploitation.
Document post-exploitation and reporting
Where the scope allows, testers measure impact after exploitation and record how far an attacker could move. The report maps each finding to the test steps and affected assets so the client can reproduce it and assess it. Output: a draft report with reproducible steps, risk context and recommended remediation for each finding.
Retest fixes and support evidence for assessment
The client remediates findings, and DeployOpen verifies the fixes and records the outcome. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications, which independent auditors and certification bodies provide. Ongoing retesting is available under a retainer, and pricing for both the test and any retainer follows from the written scope, since DeployOpen does not publish a price list. Output: a retest record and an evidence package that the client's assessor can review.
