How to Run Cyber Diligence That Puts Numbers on Deal Risk

Executive summary

Buyer-side cyber diligence is only useful when it changes the buyer's understanding of value, cost, timing, control, or ownership.

The earlier acquirer-side cyber diligence guide explains what buyers should look for and what not to accept. This article is the next layer down: how to actually run the work and turn cyber evidence into deal economics.

A useful diligence process should produce a decision record that answers these questions:

• What technical conditions were verified?
• Which management claims were supported by evidence?
• Which issues could affect revenue, operations, customers, contracts, regulation, insurance, or integration?
• What would it likely cost to remediate?
• What is the likely business exposure if the buyer closes without fixing or containing it?
• Should the issue affect price, reserve, escrow, indemnity, closing conditions, day-one work, or post-close backlog?

That is a different product than a vulnerability scan. A scan may tell you a firewall is exposed or an endpoint is missing a patch. Diligence has to explain whether that fact matters to the deal, what evidence proves it, what it could cost, and what the buyer should do before money changes hands.

The output should be usable by the deal lead, CFO, counsel, integration lead, IT/security owner, and executive team. If the report cannot be converted into a dollar range, a condition, a reserve, an owner, or a post-close work item, it is not finished.

Start with the deal model

Do not start by asking for every security policy.

Start by understanding how the buyer expects to make money from the acquisition.

The diligence lead should capture a short deal model before requesting evidence:

• Target revenue and gross margin, even as rough ranges.
• Critical products, services, plants, offices, customer portals, billing paths, production systems, and fulfillment systems.
• Systems the buyer expects to integrate, leave separate, retire, or migrate.
• Customer, regulatory, insurance, and contract commitments that depend on security claims.
• Expected close date and transition services agreement assumptions.
• The buyer's materiality threshold for cyber issues.

Materiality does not have to be perfect. It does have to be stated.

A $25,000 issue may matter in a small owner-operated services deal and be background noise in a larger platform acquisition. A $250,000 remediation item may be acceptable if it is known before signing and budgeted. The same item becomes a problem when it is discovered after close, blocks integration, and forces emergency spending.

NIST SP 800-30 treats risk assessment as decision support for leaders choosing a response to identified risks. That is the correct frame for cyber diligence. The job is not to produce a long list of defects. The job is to produce enough evidence for the buyer to choose a defensible deal response.

Build the diligence worksheet before the evidence request

The fastest way to avoid cyber diligence theater is to build the worksheet before the document request.

Use one row per deal-relevant risk scenario. The worksheet can live in a spreadsheet, a diligence tracker, or a deal-room workpaper. The format matters less than the fields.

A practical row should include:

• Risk scenario: The plain-English thing that could go wrong.
• Business function: Revenue, production, finance, payroll, customer support, regulated data, contract delivery, or integration.
• Asset or access path: Email, identity provider, ERP, EHR, CRM, OT system, customer portal, source code, domain registrar, DNS, MSP remote tool, backup platform, or cloud tenant.
• Evidence requested: The artifact or system view needed.
• Evidence received: What was actually provided.
• Evidence strength: Assertion, document, system export, direct observation, independent validation.
• Business consequence: What happens if the issue is real.
• Remediation cost range: Low, expected, and high.
• Exposure range: Low, expected, and high business loss if the issue realizes.
• Deal lever: Price, reserve, seller action, closing condition, indemnity, insurance review, day-one control, first-100-day work, or backlog.
• Owner: Buyer executive, integration lead, IT/security, counsel, insurance advisor, finance, seller, MSP, or vendor.
• Open uncertainty: What remains unknown and whether the unknown itself matters.

NIST IR 8286A and IR 8286B are useful here because they push cybersecurity risk toward documented scenarios, likelihood, impact, enterprise objectives, response selection, and projected response cost. For a deal team, that means the worksheet should not stop at "high risk." It should explain what business objective is threatened, what response is proposed, and what that response costs.

Request evidence in waves, not all at once

A bloated request list burns goodwill and buries the useful evidence.

Start with the evidence most likely to change the deal:

• Identity: Admin role exports, MFA enforcement, break-glass accounts, stale users, service accounts, privileged groups, conditional access policies, and logs showing actual enforcement.
• Email and finance paths: Mailbox forwarding rules, delegated access, payment-change approval workflow, banking portal admins, payroll admins, finance SaaS admins, and recent suspicious activity history.
• Recovery: Backup scope, backup admin list, restore test evidence, excluded systems, recovery time, recovery point, immutable or offline copy status, and failed restore notes.
• Endpoint and server coverage: Managed endpoint list, unmanaged devices, EDR or antivirus coverage, unsupported operating systems, critical servers, and exceptions.
• Remote and vendor access: VPN, RMM, MSP tools, contractor accounts, vendor admin access, shared accounts, MFA status, and offboarding records.
• Data: Sensitive data locations, regulated data types, customer data flows, shared drives, cloud storage, SaaS exports, and vendors touching the data.
• Incident history: Prior ransomware, business email compromise, fraud, data exposure, security notices, insurance claims, law enforcement contact, and legal-reviewed incident records when appropriate.
• Customer and insurance representations: Cyber insurance application answers, customer security questionnaires, security addenda, SOC reports if any, and contract security obligations.
• Integration surfaces: Network diagrams, domain trust relationships, API connections, source code repositories, customer portals, OT segmentation, and systems expected to connect to the buyer.

The first wave should answer whether the buyer has a material problem. The second wave should quantify it. The third wave should support deal language, reserve sizing, or integration planning.

Do not expand into a full control assessment unless the initial evidence shows a material unknown. If backup evidence is clean, spend the time elsewhere. If backup evidence is missing, inconsistent, or scoped to the wrong system, escalate.

Validate the things that change ownership risk

The technical work should be focused. Broad testing is often slower than the deal timeline and less useful than targeted validation.

Validate the areas where a false answer could hurt the buyer immediately after close.

For identity, do not accept "we have MFA." Look at the enforcement policy, admin exclusions, emergency accounts, domain/DNS accounts, cloud admins, finance admins, and remote access accounts. If the target uses Microsoft 365 or Google Workspace, a screenshot is weaker than a live export or direct screen-share review of admin roles and policy assignments.

For MSP access, identify the actual remote management platform, named technician accounts, shared accounts, MFA status, logging, contract responsibility, and termination mechanics. If the MSP can push scripts to every endpoint but the target cannot name who approves that access, the buyer has an ownership problem.

For backups, ask for the last successful restore test of the system that actually matters. A backup success dashboard is not the same as restore evidence. The buyer needs to know whether the target can rebuild the billing system, production scheduler, ERP, file server, customer portal, or identity platform that keeps the company operating.

For endpoint coverage, compare the business's device inventory to the security tool inventory. A green dashboard covering 80 devices does not help if the business has 135 devices and the missing 55 include executives, servers, shop-floor machines, or remote laptops.

For data, follow the FTC's basic but important discipline: know what personal information exists, where it lives, how it enters and leaves the business, and who can access it. In acquisition diligence, that same map supports privacy review, customer contract review, insurance underwriting, integration scoping, retention cleanup, and remediation budgeting.

For incident readiness, use NIST SP 800-61 Rev. 3 and CISA ransomware guidance as practical anchors. The buyer should verify response ownership, communication paths, backup restoration, containment ability, and recovery priority before the company becomes part of the buyer's environment.

Convert findings into dollars without pretending to know the future

Cyber diligence does not need fake precision. It needs defensible ranges.

Use two numbers for each material issue:

• Remediation cost: What the buyer expects to spend to fix or contain the condition.
• Exposure range: What the buyer could lose if the condition realizes before it is fixed.

Remediation cost is usually easier. Build it from visible parts:

• Outside advisory or technical labor.
• Internal labor diverted from integration or operations.
• Tool licensing or replacement.
• Vendor or MSP project fees.
• Hardware, hosting, backup storage, or migration costs.
• Legal, insurance, privacy, or customer-contract review when the issue touches those lanes.
• Temporary controls needed to close safely.
• Rework caused by integration delays.

Exposure range is harder, but the buyer can still make it concrete. Start with business impact, not fear.

A simple model is:

Exposure range = lost gross margin + response cost + recovery cost + legal/regulatory/customer cost + integration delay cost + insurance friction

Use ranges. Mark assumptions. Tie every assumption to the business.

If a production system outage would stop $80,000 of daily revenue at 45 percent gross margin, the gross-margin exposure starts around $36,000 per day. If restore evidence is missing and the realistic outage range is three to ten business days, the direct margin range starts around $108,000 to $360,000 before response labor, rebuild cost, customer credits, expedited shipping, regulatory review, or integration delay.

That does not mean the buyer should cut the price by exactly $360,000. It means cyber diligence has given finance and the deal team a rational input for reserves, seller action, closing conditions, transition sequencing, and post-close funding.

IBM's 2025 Cost of a Data Breach report is useful as context because it shows breach costs can be material, with IBM reporting a $4.44 million global average and a $10.22 million U.S. average for studied breaches. Do not blindly paste those numbers into a small business deal. Use them as a reminder that incident cost is broader than tools and cleanup. Then model the target's actual revenue, data, obligations, downtime tolerance, and control gaps.

FAIR is also useful conceptually because it pushes risk discussions toward frequency, magnitude, and financial terms rather than color charts. In a deal, that does not require a full Monte Carlo model. It can be enough to express the material issues as low, expected, and high dollar ranges with clear assumptions and sensitivity drivers.

Example: no proven recovery for the revenue system

Condition: The target says backups are handled by the MSP, but the seller cannot produce a restore test for the ERP and customer billing system. The MSP dashboard shows successful backup jobs, but no evidence of a full application restore.

Evidence strength: Written dashboard evidence exists for backup job completion. There is no system-generated or direct-observation evidence that the revenue system can be restored.

Business consequence: If ransomware, deletion, hardware failure, cloud-account lockout, or MSP error affects the system, the buyer may own a business that cannot bill customers, ship work accurately, or prove receivables during the first weeks after close.

Cost translation:

• Remediation cost: Backup architecture review, restore test, admin access cleanup, immutable copy setup, documentation, and a recovery runbook.
• Exposure range: Daily gross margin at risk multiplied by expected outage days, plus emergency MSP/project labor, customer credits, finance cleanup, and delayed integration work.
• Deal lever: Seller provides restore evidence before close, or buyer creates a remediation reserve and requires a day-one recovery validation.

Example numbers:

Revenue affected: $1.2M per month
Gross margin: 45 percent
Daily gross margin: about $18,000
Plausible outage: 5 to 12 business days
Direct margin exposure: about $90,000 to $216,000
Response and rebuild: $50,000 to $150,000
Customer credits and operational cleanup: $25,000 to $100,000
Practical reserve discussion: $165,000 to $466,000, before legal or regulatory issues

The diligence finding should not say, "Backups are inadequate. High risk."

It should say the buyer has not seen evidence that the revenue system can be restored, the direct business exposure could plausibly land in a six-figure range, and closing safely requires pre-close restore evidence or a funded day-one recovery workstream.

Example: uncontrolled MSP access

Condition: The MSP has a remote management tool on all endpoints and servers. Technician accounts are shared. MFA status is unclear. The target does not know whether former MSP employees still have access.

Evidence strength: Contract exists. Tool dashboard exists. Named-user access evidence is missing.

Business consequence: The buyer may inherit a privileged third-party access path that can alter endpoints, deploy software, access files, and disrupt operations. This also creates integration risk because the buyer cannot safely connect or trust the environment until vendor access is understood.

Cost translation:

• Remediation cost: RMM account export, named-user conversion, MFA enforcement, stale account removal, logging configuration, contract responsibility review, emergency access process, and possible MSP transition.
• Exposure range: Incident response cost if the tool is abused, operational disruption if the tool is misconfigured, and integration delay if the buyer pauses connectivity.
• Deal lever: Seller action before close, closing condition for access evidence, day-one containment, or escrow if MSP transition cost is material.

Example numbers:

Immediate access cleanup: $5,000 to $20,000
MFA/logging/process repair: $10,000 to $35,000
MSP transition or tool migration: $25,000 to $125,000
Integration delay: estimate by buyer team cost plus delayed synergy value
Practical reserve discussion: $40,000 to $180,000, depending on whether the MSP must be replaced

Example: unknown regulated or contract-sensitive data

Condition: The target says it does not have sensitive regulated data, but customer contracts require specific security commitments and the file shares include exports with customer personal information. Nobody can explain retention, access, or vendor processing.

Evidence strength: Management assertion conflicts with file-share samples and contract language.

Business consequence: The buyer may inherit privacy, customer-notification, regulatory, insurance, or contract obligations that were not reflected in the deal model. Counsel may need to review whether representations, warranties, disclosure schedules, or post-close obligations need adjustment.

Cost translation:

• Remediation cost: Data discovery, access cleanup, retention cleanup, vendor review, policy correction, customer-contract evidence, and counsel-led obligation review.
• Exposure range: Customer remediation, contract breach arguments, notification analysis, insurance friction, delayed integration, and higher support burden.
• Deal lever: Pre-close investigation, counsel escalation, reserve, disclosure schedule cleanup, specific seller representation, or delayed integration of affected repositories.

This is where cyber diligence must stay disciplined. Trawvid Sec can organize the security facts and technical evidence. Counsel owns legal interpretation. Insurance advisors own insurance placement and coverage interpretation. Finance owns valuation treatment. The cyber diligence provider should make those handoffs concrete instead of pretending a technical report can replace them.

Write findings so finance and counsel can use them

A technical finding should be rewritten before it goes to the deal team.

Weak version:

"Critical vulnerability on externally exposed server. High risk. Patch immediately."

Deal-useful version:

"The externally exposed customer portal runs an unsupported framework version with known exploitable weaknesses. The target provided a screenshot of the server but no vulnerability management record, patch plan, compensating control, or incident review. If exploited before migration, the issue could affect customer access, regulated data, customer notice obligations, incident response cost, and integration timing. Buyer should require seller to isolate or patch the portal before close, confirm logs are preserved, and reserve $X to $Y for emergency stabilization and replacement planning. Remaining uncertainty: whether the portal has already been accessed by an unauthorized party."

Every material finding should include:

• Condition.
• Evidence.
• Evidence gap.
• Business consequence.
• Cost range.
• Time range.
• Deal lever.
• Owner.
• Open uncertainty.
• Recommended next action.

That structure forces the work to be useful. It also prevents the report from becoming a pile of technical trivia.

Separate price adjustment from remediation reserve

Not every dollar becomes a price cut.

A price adjustment is a valuation argument. A remediation reserve is a funding argument. A closing condition is a control argument. An indemnity or representation issue is a legal-risk allocation argument. A day-one task is an ownership-control argument.

The diligence report should not pretend those are the same thing.

Use this logic:

• If the issue reduces expected earnings, customer confidence, contract value, or growth assumptions, it may affect valuation.
• If the issue requires predictable cleanup after close, it may need a remediation reserve.
• If the issue creates immediate ownership danger, it may need seller action or a closing condition.
• If the issue creates uncertain liability, it may need counsel review for representations, warranties, indemnity, disclosure schedules, or holdback structure.
• If the issue is real but bounded, it may belong in the integration backlog with budget and owner.

The Yahoo-Verizon transaction is the public example everyone recognizes because the numbers were visible. Yahoo's 2017 Form 10-Q disclosed a $350 million reduction in sale consideration tied to data security incidents and shared responsibility for certain post-closing cash liabilities. Most deals will not look like Yahoo. The lesson is narrower and more useful: cyber facts can become price, liability allocation, closing-condition, and post-close-cost facts.

Know when to stop

More testing is not automatically better diligence.

Keep investigating when the next evidence request could change one of these decisions:

• Whether to proceed.
• Whether to change price.
• Whether to reserve funds.
• Whether to require seller action before close.
• Whether counsel needs to adjust transaction language.
• Whether insurance applications or coverage assumptions need review.
• Whether integration must be delayed, isolated, or resequenced.
• Whether day-one containment is required.

Stop or defer when the issue is real but does not affect the transaction. Put it in the post-close backlog with an owner, priority, and rationale.

A buyer should not pay for endless cyber archaeology. The work is complete when additional investigation is unlikely to change valuation, deal terms, capital reserve, closing conditions, integration path, or first-100-day priorities.

How Trawvid Sec fits

Trawvid Sec can help buyers run cyber diligence that produces decision-grade evidence instead of generic security noise.

That can include:

• Building the diligence worksheet and evidence request waves.
• Reviewing identity, backup, endpoint, remote access, MSP, data, incident, and integration evidence.
• Converting material findings into cost ranges, exposure ranges, and deal levers.
• Separating pre-close blockers from day-one containment and post-close backlog.
• Coordinating security facts with counsel, finance, insurance advisors, integration leads, IT, and MSPs without pretending to replace those roles.
• Turning diligence findings into an owned risk register and funded integration workstream.

This is security advisory, not legal advice, accounting advice, insurance brokerage, deal representation, or a guarantee that every issue has been found.

Summary

Cyber diligence succeeds when the buyer can use it.

The buyer should leave with verified evidence, known unknowns, cost ranges, exposure ranges, owners, timing, and deal levers. The work should identify which cyber issues affect price, reserves, closing conditions, insurance review, integration sequencing, or day-one control.

A finding that cannot be tied to business consequence may still matter later. It just may not belong in the deal decision.

The point is not to make every target look bad. The point is to give the buyer a clearer view of what it is buying, what it must fix, what it must fund, what it can safely defer, and what uncertainty should cost before ownership transfers.