Why nobody does this at small deal sizes
Because the cost of the work looks large next to the cost of the asset, and because there is no adviser whose job it is to insist. A few days of security review against a purchase that might be a year of profit feels like ceremony, so it gets skipped in favour of checking the revenue.
The reasoning inverts under examination. Deal size caps the upside, not the downside. A data-protection finding, an undisclosed breach or a compromised sending domain costs what it costs regardless of what you paid, and the smaller buyer is precisely the one with no legal team, no cyber cover and no incident-response retainer to absorb it. The exposure is not proportional to the ticket. That is the whole point.
What you actually inherit on completion day
Four things, all of which existed before you owned the asset and all of which become yours the moment you do:
- A data-processing position. Whatever personal data the business holds, on whatever basis it was collected — including none.
- A credential estate. Every account, key, token and integration the business runs on, plus everyone who has ever had a copy.
- A dependency tree. The libraries, plugins, runtimes and services the thing is built on, at whatever patch level they were abandoned.
- A reputation position. Domain age and standing, sending reputation, blocklist history, and whatever the previous owner did with the mailing list.
The revenue is what you are buying. These four are what you are assuming, and only one of them shows up in a profit-and-loss statement.
The data liability is the expensive one
Because it is the only one that can outlive the asset. If the business holds customer records, a marketing list or user accounts, you inherit both the data and the lawful basis the previous owner relied on. Under GDPR and the Spanish framework, a list collected without valid consent does not become lawful because it changed hands — and the new controller is the one who answers for it.
This matters disproportionately for the assets most worth buying in Spanish-speaking markets. Lead-generation platforms and niche media properties are valuable precisely because they have accumulated audiences, and accumulated audiences are exactly where collection practices from six years ago are least likely to survive inspection.
Three questions settle most of it before completion:
- How was each dataset collected, and what was disclosed at the time? Ask for the actual form, the actual checkbox, the actual privacy notice as it stood — not a description of them.
- Where does the data physically sit, and who else can reach it? Including former contractors, agencies and the analytics stack.
- Have deletion and access requests been handled, and is there any record of it? The absence of a single request in five years is itself a finding.
Where the answers are unsatisfactory, the options are narrow and worth knowing in advance: re-permission the list, delete the unsupportable portion, or decline the deal. Buying it and hoping is not a third option — it just moves the liability onto you.
The risk is not an attacker
In small acquisitions the realistic incident is not an intrusion. It is a credential that was never revoked. These businesses are usually run by one person over many years, which produces a predictable estate: one administrator login shared with a designer in 2021, an agency that still has the ad account, a former contractor whose key is in an old repository, a personal password manager holding everything.
Almost none of this is malice. It is the ordinary residue of a business run informally by someone who never expected to sell it — the same informality that creates the transferability problem described in the succession piece. But on completion day it means the set of people who can reach your new asset is larger than the set of people you know about, and nobody has an inventory.
What we check before completion
Deliberately short. This is a few days of work, not a penetration test.
- Inventory every account and who can access it. Domain, registrar, DNS, hosting, code repository, payment processor, ad platforms, email, analytics, app stores. Ask specifically who else has ever had access, and expect the first answer to be incomplete.
- Verify domain and DNS control. Registrar lock, expiry date, who the registrant actually is, and whether the email records — SPF, DKIM, DMARC — are configured or absent.
- Check sending and blocklist history. A domain with a damaged sending reputation is expensive and slow to rehabilitate, and it does not appear anywhere in the accounts.
- Audit the dependency tree. Not for elegance — for whether it can be patched at all. An unsupported runtime or an abandoned plugin with no upgrade path is a rewrite wearing an asset’s clothes.
- Map the personal data. What is held, where, on what basis, and who processes it on the business’s behalf.
- Ask directly about past incidents. Whether anything was ever compromised, and what was disclosed to users. An undisclosed historic breach is a liability that transfers with the asset.
The completion-day rotation
The single most valuable hour of the whole transaction. Transfer ownership through each platform’s own mechanism rather than handing over passwords — that leaves an audit trail and actually removes the seller’s access, which a shared password does neither of. Then rotate everything that cannot be transferred that way.
| Asset | Action at completion | Why |
|---|---|---|
| Domain / registrar | Transfer registrant; enable lock and 2FA | Losing the domain loses the business |
| Platform accounts | Ownership transfer, then remove all other users | Shared logins leave no trail and never expire |
| API keys and tokens | Regenerate every one; treat old values as burned | They exist in places nobody remembers |
| Payment processor | New entity, new keys, verified payout account | The one place money can be redirected |
| Handover access | Named accounts, scoped, with an expiry date | Handovers need access; shared admin logins do not |
Swipe to see the whole table →
What we price, and what we walk away from
Most findings are priceable. Unpatched dependencies, missing email authentication, a messy credential estate — these are work, and work has a number. We deduct it, say plainly that we are deducting it, and get on with the transaction.
Three findings are different, because they are not work:
- A customer database whose collection cannot be evidenced. You would be buying a liability with an audience attached.
- An unresolved breach that was never disclosed. The obligation transfers, and the clock did not stop.
- A codebase that cannot be updated without a rewrite. Then the price is the rewrite, and the asset is the audience — which is a different deal, at a different number.
The general rule sits in the same place as everything in the valuation piece: verifiable problems get priced, unverifiable ones get declined.
How we think about it at Thinktier
Security sits in the operating system rather than in a budget line — the argument made at greater length in the posture piece. Acquisition is simply the moment it becomes unavoidable, because it is the one day you take on somebody else’s decisions in a single transaction.
The practical position we hold is that diligence findings should be boring and early. A few days of inventory work before signing converts an unbounded liability into a line item, and a line item can be negotiated. The buyers who get hurt at this size are almost never the ones who found something alarming. They are the ones who never looked.
Sources
- Regulation (EU) 2016/679 (General Data Protection Regulation) — EUR-Lex, European Union, 2016-04-27
- Ley Orgánica 3/2018, de 5 de diciembre, de Protección de Datos Personales y garantía de los derechos digitales — Boletín Oficial del Estado, 2018-12-05
- Email sender guidelines — Gmail Help, Google
- A03:2025 – Software Supply Chain Failures — OWASP Top 10:2025, OWASP Foundation, 2025
- Secrets Management Cheat Sheet — OWASP Cheat Sheet Series
- More than a Password — Cybersecurity and Infrastructure Security Agency (CISA)
Q&A — structured for AI search
- Do you need security due diligence on a small acquisition?
- Yes, and more than at large deal sizes rather than less, because nothing else compensates for it. A large acquirer has insurance, a legal team and an incident-response retainer absorbing what diligence misses. A buyer of a small digital asset has none of that, so an inherited breach or an unlawful customer database lands directly on the new owner. The work is a few days; the exposure is unbounded.
- What are the biggest security risks when buying a website or SaaS?
- In order: a customer database you have no lawful basis to hold, credentials that were shared rather than transferred, dependencies that are unsupported or unpatched, and domain or sending reputation that arrives already damaged. The unifying feature is that all four are inherited rather than caused — they exist before you own the asset and become yours the moment you do.
- What happens to personal data when you acquire a digital business?
- You inherit the processing and the obligations attached to it, including the lawful basis the previous owner relied on — or the absence of one. Under GDPR and the Spanish framework, a marketing list collected without valid consent does not become lawful because it changed hands, and the new controller is the one who answers for it. Verifying how the data was collected, what was disclosed and whether deletion requests were honoured belongs in diligence, not in the first month of ownership.
- How do you transfer accounts and credentials safely at completion?
- By transferring ownership of the account rather than the password, and by rotating every secret on the day. Ownership transfer through the platform's own mechanism leaves an audit trail and removes the seller’s access; sharing a password does neither. Everything that cannot be transferred that way — API keys, service credentials, tokens embedded in code — is regenerated on completion day, and the old values are treated as compromised because in practical terms they are.
- Should the seller keep access after the sale?
- Only deliberately, only scoped, and only for a defined period. Handovers genuinely need the seller involved, so the answer is not zero access — it is named accounts with limited permissions and an expiry date, rather than the shared administrator login that has been in use for six years. The failure mode is not malice; it is a credential that stays valid on a personal device long after anyone remembers it exists.
- What security problems make you walk away from an acquisition?
- A customer database whose collection cannot be evidenced, an unresolved breach that was never disclosed to users, and a codebase whose dependencies cannot be updated without a rewrite. The first two are legal liabilities that outlive the purchase price; the third is a rebuild disguised as an asset. Most other findings are priceable rather than disqualifying.
Federico Noya
Founder & Operator, Thinktier
Writes about how AI search, distribution architecture and operating discipline compound across the Thinktier portfolio.