NIST SP 800-53A Rev. 5 Appendix D describes penetration testing as a controlled, point-in-time attempt to understand system weaknesses under agreed rules of engagement. That description is particularly useful in a technology acquisition: a test can produce evidence for a decision, but its result has to name the tested systems, assumed attacker, access level and limitations.
Quick answer. Commission an M&A penetration test against a specific deal decision, such as whether an exposed application needs remediation before integration or whether a planned identity trust should be delayed. Pre-close testing requires the target's written authorization and often a deliberately narrow scope; a post-close test can examine internal and cross-company paths once access and ownership are clear. Stingrai can scope human-led penetration testing around those decisions and provide findings to the people who will own the fixes.
This guide is for corporate development teams, acquiring CISOs, integration leaders and technology investors buying a product or operating company. It is about the test deliverable and its boundaries. Stingrai's private equity vendor ranking addresses provider selection across a portfolio; this article addresses what a transaction test must prove so that a deal team can use its results.
What a penetration test adds to due diligence
Cyber due diligence collects many types of evidence: policy documents, asset inventories, architecture diagrams, incident history, access reviews and prior assessments. A penetration test asks a narrower question. Within an authorized set of systems and time constraints, can an assessor demonstrate a weakness that affects a defined business or integration risk? The answer helps prioritize remediation and may change the sequence of technical integration. It is not a complete estimate of hidden exposure or a guarantee that untested systems are safe.
NIST SP 1326 defines due diligence for information and communications technology suppliers and products as researching and verifying pertinent information for decisions about new acquisitions or existing systems. Its scope is ICT supplier assessment. It is useful here as a discipline for checking claims and identifying the criticality of an acquired technology supplier. It is not a merger regulation, a requirement to run a penetration test or a checklist that covers the whole target company. The acquirer should decide what evidence the deal requires.
One practical division is between known posture and demonstrated behavior. A target may provide an earlier report, an asset list and a remediation tracker. These show what was examined and what the target says changed. A new, scoped test can check a live application or trust boundary and retest a claimed fix. The two evidence types should be reconciled rather than treated as substitutes. A finding closed in a ticket is still a question until the test environment shows the intended behavior.
Start with the decision and authority boundary
Before requesting a quote, name the decision owner and the decision they need to make. A corporate development lead may need a short list of risks affecting closing conditions. An integration lead may need to know whether network connectivity or single sign-on can be enabled. A product leader may need to budget remediation for a customer-facing API. Those are different scopes, even when the same target is involved.
The target's authorization is equally important. The acquirer does not automatically gain permission to test a target's infrastructure merely because the transaction is contemplated. The written rules should identify legal owner, approved domains and accounts, permitted test techniques, start and stop times, handling of sensitive data and emergency contacts. Third-party hosted systems, partner APIs and shared cloud accounts may require separate permission or an explicit exclusion. NIST Appendix D says organizations specify both the components subject to testing and the attacker profile used in the exercise.
A pre-close test should be designed for the time and information the target can safely provide. With limited access, an external application and remote access scope may be appropriate. With target cooperation, authenticated roles, source-assisted review or cloud configuration context may answer a higher-value question. The point is to state which view of the environment the assessors had. An outside-in test cannot silently stand in for an internal network or identity assessment.
Match the test window to the transaction decision
Transaction window | Question the test can answer | Limit to state in the report |
|---|---|---|
Before close | Can the approved external surface or customer application demonstrate a weakness relevant to the deal? | Target permission, supplied accounts and the short test window constrain coverage |
After close, before connection | What internal, cloud and identity paths could cross into the acquirer's estate? | Segmentation and trust may still be changing |
After integration | Did the chosen remediation and identity controls work in the joined environment? | The result reflects the integrated state on the retest date |
Figure 1: A transaction testing decision map proposed for technology buyers. Source: NIST SP 800-53A Rev. 5, Appendix D.
The table is an editorial planning model, not a mandated schedule. A deal may close without a pre-close test because authorization or time is unavailable. The investment committee then needs an explicit deferred-test item, named owner and integration restraint. Hiding the gap beneath the word “assessed” creates a worse decision than acknowledging it.
Choose attack paths that matter to an acquirer
For a software acquisition, customer-facing applications and APIs may expose customer data or business transactions. The test should include authenticated roles and tenant boundaries, particularly when the product has administrative, customer and reseller views. A pure scan cannot resolve whether one customer can act on another customer's object. The web application service Stingrai describes includes grey and white-box options, business logic and sensitive data exposure testing.
Identity is often a more consequential integration question than a single web finding. The acquirer should map the target's identity provider, privileged accounts, service accounts, cloud roles, remote access and inherited trust. The test objective can be stated as: what would an approved low-privilege user or a controlled assumed-breach position reach before the estates are connected? This is a defensive scope definition, not an exploit recipe. The finding should show the trust boundary and the control that failed.
Cloud and network work should follow the intended integration architecture. Identify the accounts, subscriptions, virtual networks, management planes and shared services that will become reachable. If the target uses a transition services agreement or retained parent infrastructure, clearly mark who can authorize those assets. A report that names a vulnerability in an excluded parent network would be unusable and could exceed the agreed test authority. See Stingrai's cloud penetration testing service for the distinct cloud scope that may sit beside application testing.
Ask for evidence that supports a deal decision
An investment committee needs a short, defensible answer, not a stack of raw scanner results. Request an executive summary that separates confirmed risks from unresolved limitations and explains the likely consequence for closing, integration or a remediation reserve. A technical annex should map each finding to the affected asset, role, trust path, proof observed, recommended fix and verification status. These are proposed deliverables for a transaction, not a claim that NIST prescribes a deal report template.
Request a scope and coverage appendix as well. It should list assets actually tested, access level, environment, approved exclusions, test dates and material conditions that narrowed coverage. Appendix D's point-in-time framing matters here: a report issued before a product release or an identity migration may not describe the joined environment. If an acquirer relies on the report later, the report must make that change visible.
The finding disposition should be usable after closing. Assign an owner on the target and acquirer side, decide which fixes must precede connectivity and which can be scheduled, and specify what the retest will prove. A working proof of concept can be redacted for broader sharing while the remediation team retains enough detail to reproduce the issue safely. Stingrai's PTaaS platform supports live finding delivery, direct tester discussion and report redaction, which can help keep the transaction audience and engineering audience aligned.
Do not mistake a scan for transaction assurance
NIST Appendix D says an effective penetration test goes beyond vulnerability scanning to provide proof of mission risk and considers architectural weaknesses and trust relationships. In an acquisition, those trust relationships include planned identity federation, administrative access, shared networks and data migration paths. The buyer should ask the vendor how it will test the chosen path under the target's permission and how the report will explain what remained untested.
At the same time, a short penetration test cannot answer whether the target has been compromised historically, whether every code dependency is trustworthy or whether governance is mature. Those questions may call for separate compromise assessment, architecture review, software supply chain work or document diligence. SP 1326's research categories include provenance, resilience, foundational cyber practices and supply chain tiers for ICT suppliers, illustrating why due diligence is broader than a single technical test. Commission each workstream for the decision it can actually support.
Vendor questions for a technology acquisition
Ask prospective testers to name the exact decision the engagement will inform and the access they need to reach it. Ask how they will distinguish a confirmed risk from a hypothesis when a short window prevents deeper testing. Ask whether the same team can review an application, cloud account and identity trust path under one coordinated set of rules, or whether separate specialists and reports are needed.
Then ask about evidence handling. Who sees live findings? Can the buyer share an executive version without disclosing sensitive reproduction detail? Which target staff receive remediation guidance? How will the vendor verify fixes after the ownership and infrastructure change? Finally, request a written list of exclusions in the quote. If two vendors propose different access levels, their prices and findings will not be directly comparable. Stingrai's quote process produces an agreed statement of work with scope, timeline and deliverables, as described on its PTaaS page.
Where Stingrai fits
Stingrai is a Toronto-headquartered, CREST-accredited penetration testing company. Its human-led engagements can be scoped to web applications and APIs, cloud environments and network or identity testing, depending on what the acquisition decision requires. The service is available as one-time testing or a continuous program through Enterprise pricing, which is custom quoted. For a deal team, the value of the scope is a clear boundary and a finding record that can move from diligence into integration and remediation.
The buyer should still request the named testers, precise access model, report audience and retest terms in the statement of work. A small, time-boxed pre-close test may be the right first slice; a broader post-close assessment should be agreed separately where the acquisition changes the environment. Stingrai's penetration testing can produce evidence for compliance and assurance programs relevant to the acquired business, while the acquirer decides how to use it in its broader diligence process.
Frequently Asked Questions
Does an M&A cyber due diligence review require a penetration test?
There is no universal penetration test requirement created by NIST SP 1326. That publication guides due diligence on ICT suppliers and products. A deal team should commission a penetration test when a specific technical question about the target's reachable systems or planned integration needs controlled evidence. Contract terms, sector rules and the target's risk may create separate obligations that the buyer must check for the particular transaction.
Can the buyer test the target before closing?
Only with written authorization from the target and any other relevant asset owner. The rules of engagement should identify assets, accounts, techniques, time windows, data handling and emergency contacts. A limited pre-close test can still help a decision if the report clearly states the access and systems actually examined. Without permission, defer active testing and document the unanswered question.
What should the investment committee receive?
The committee should receive a concise summary of confirmed risks, the business or integration decision each risk affects, the remediation owner, the proposed timing and the material coverage limits. The technical team should retain the detailed evidence and reproduction context. The summary should distinguish a tested control from a policy claim and an untested area from a clean result.
When should the acquirer retest after closing?
Retest after the relevant fix or integration change is complete, using the environment and trust path that will operate going forward. A pre-close result is a point-in-time observation under its original rules of engagement. If identity federation, network routing, cloud ownership or a customer application changes, define a new objective and scope for the changed path rather than treating the older result as current.
Related reading
References
NIST, SP 1326: Cybersecurity Supply Chain Risk Management Due Diligence Assessment Quick-Start Guide, July 2026.
NIST, SP 800-53A Rev. 5, Appendix D: Penetration Testing, January 2022.
Stingrai, About Stingrai, PTaaS platform and pricing.
Talk to Stingrai
Bring the deal objective, target authorization and proposed integration architecture to Get a Quote or book a free discovery call. Stingrai can define the authorized test window and evidence that the transaction team needs.
