A consumer app survives a breach. Users grumble, reset passwords, move on. A B2B company often does not. Your customers are companies with their own compliance obligations, their own boards, and contract clauses that let them terminate the moment you disclose an incident involving their data. One breach, and the churn isn't a spike — it's a cascade. The enterprise logos that took eighteen months to close leave in a quarter.
So this is not a story about a worst case. For a B2B company, a serious breach is frequently the case. The end of the company.
The math is not subtle
The average breach for a US company runs past $9M, and for regulated data or healthcare the figure is higher. But the average is a distraction. The number that matters for you is the conditional one: given a breach, what fraction of your enterprise contracts have a clause that lets the customer walk? For most B2B SaaS companies the answer is "nearly all of them," because every enterprise security review you passed required you to agree to those clauses.
Now weigh that against the cost of prevention. The full prevention architecture below — defense-in-depth, encryption, real access control, monitoring — costs a fraction of one enterprise contract to build correctly the first time. The asymmetry is the entire argument. You are spending tens of thousands to protect a business that a single incident can zero out.
The prevention work is unglamorous. It is encryption config and access reviews and audit logs and network segmentation. None of it demos well. All of it is cheaper than the alternative by two orders of magnitude.
Defense-in-depth, plainly
The core idea is that no single control should be load-bearing. Defense-in-depth means layering controls so that any one of them failing — and one always eventually fails — doesn't hand over the company. The attacker has to defeat several independent barriers, and each one buys you detection time.
The layers, outermost to innermost:
network ── segmentation, private subnets, no public DB
identity ── strong auth, MFA, scoped service identities
authorization ── per-resource permission checks, least privilege
data ── encryption at rest + in transit, field-level for PII
detection ── audit logs, anomaly alerts, access monitoring
A flat architecture has one layer. The database is reachable from the application, the application is reachable from the internet, and once you're in, you're in everything. Defeating one control defeats the system. That is the architecture that ends companies, and it is the architecture most early products ship with because it's the simplest thing that works.
Encryption that does work, not work-on-paper
Encryption in transit is table stakes: TLS everywhere, no exceptions, including service-to-service traffic inside your own network. The internal-traffic-is-trusted assumption is how a single compromised service becomes a network-wide sniffing operation.
Encryption at rest is where the real decisions live. Full-disk encryption at the infrastructure layer is the baseline and it's nearly free — turn it on. But full-disk encryption only protects against someone physically stealing the disk. It does nothing against an attacker who has valid database access, because to the database the data is plaintext.
For your highest-sensitivity fields — PII, credentials, anything that turns a breach into a disclosable event — you want field-level encryption: the data is encrypted before it's written and decrypted only by the services that legitimately need the cleartext. Now an attacker who exfiltrates the database table gets ciphertext. The keys live in a separate key management service with their own access control. Breaking the database and breaking the key store are two different attacks.
The discipline that makes this real: define what's in scope (anything that, if disclosed, triggers a notification obligation), encrypt that at the field level, and keep the keys somewhere the database credential can't reach.
Access control as the spine
Most breaches aren't exotic. They're an attacker obtaining some legitimate access and then moving freely because nothing constrained where that access could go. The single most effective structural defense is least-privilege access control enforced at every layer.
Human access: every employee has the minimum access their role requires, access is reviewed on a schedule, and it's revoked the day someone leaves — not the week someone remembers. The departed contractor whose credentials still work is a recurring opening line in breach reports.
Service access: every service has a scoped identity that can reach only its own data and secrets. A compromise of the analytics service must not be able to read the payments database. This is the blast-radius principle — you're not preventing every compromise, you're guaranteeing that a compromise stays small.
Data access: every read and write checks not just "is this actor authenticated" but "is this actor permitted this specific record." This is the authorization layer that stops one customer's user from reading another customer's data by changing an ID. We treat this as architectural — enforced at the service boundary so no developer can forget it — and it's covered further in application security for funded startups.
The kill-chain, and where you break it
A breach is rarely one event. It's a chain, and you only have to break one link to stop the whole thing. Understanding the chain tells you where to spend.
1. initial access ── leaked credential, vuln, phishing
2. foothold ── attacker runs code or holds a valid session
3. escalation ── from limited access to broader access
4. lateral movement ── from one service/system to others
5. exfiltration ── data leaves the building
6. impact ── disclosure, extortion, contract loss
You will not perfectly prevent step 1. Credentials leak, dependencies have CVEs, people get phished. A security strategy built on "never let them in" fails on contact with reality. So you build to break the later links.
Break escalation (3): least privilege means initial access lands the attacker somewhere small with nowhere up to go. The compromised service identity can read its own secrets and nothing else.
Break lateral movement (4): network segmentation and scoped service identities mean the attacker who owns one service can't reach the next one. This is the highest-value break point, because step 4 is what turns a contained incident into a company-ending one.
Break exfiltration (5): field-level encryption means the data they reach is ciphertext without the keys. Egress monitoring means a large unusual data transfer triggers an alert while it's happening.
Detect throughout: audit logs and anomaly alerting on access patterns mean you find out at step 2 or 3 instead of reading about it from a third party at step 6. The difference between a contained incident and a disclosure is almost always detection time.
Detection is half the architecture
Prevention gets the attention; detection determines the outcome. The breaches that end companies are the ones that ran undetected for months, where the disclosure has to say "we don't know the full scope and the exposure window was 200 days." The breaches that don't end companies are the ones caught early, contained, and disclosed with "exposure was bounded, here's exactly what was affected."
The detection layer: a centralized, append-only audit log of every access to sensitive data, in a store the application can't modify. Alerting on the patterns that signal compromise — a service identity reading records it never reads, a spike in failed authorization checks, a large egress transfer, access from an impossible location. And an incident response process that has actually been run once, so the first time you exercise it isn't during the real thing.
What fixed looks like
Your architecture has layers, and no single one is load-bearing. The database isn't reachable from the internet. Services run with scoped identities in segmented networks. Sensitive fields are encrypted at the field level with keys in a separate key store. Human access is least-privilege and reviewed; departed staff are revoked same-day. Every data access is both authenticated and authorized per-resource.
An append-only audit log records every sensitive access, and anomaly alerts fire on the patterns that precede a real breach. You have run your incident response process at least once. And if an attacker does get initial access, the architecture guarantees they land somewhere small, can't move sideways, find ciphertext if they reach the data, and trip an alert on the way out. You can see this layered approach built into a real system in the ClearVault engagement.
This is for you if
You're a B2B company holding customer data under contracts that let your customers leave if you disclose a breach — which is to say, almost every B2B company. You understand that the prevention architecture is cheap insurance against an existential outcome, and you want it built before you need it rather than reconstructed after.
This is build and hardening work starting around $50k for a focused defense-in-depth pass on an existing system, and a core part of larger build engagements ($100k+) where the architecture is layered from the start.
It's not for consumer apps where a breach is a bad week rather than a closed company, and it's not for teams that want a one-time scan instead of an architecture. A scan tells you where the holes are today. Defense-in-depth is what keeps the next one from reaching anything that matters.