Skip to content

Legal and Insurance

Software products do not exist in a legal vacuum. The moment they ship to users, take payments, store data, or integrate with another system, they create obligations that are not described in any architecture diagram. Most of those obligations live in contracts, regulations, and insurance policies that engineers rarely read but routinely affect.

This chapter is not legal advice. It is a map of the kinds of obligations software work creates, so that the engineering organization knows when to bring in the people who do specialize.

Categories of Obligation

A few areas of legal and operational exposure show up in nearly every product:

  • Contracts. What did you promise the customer, in writing? Uptime commitments, data-handling commitments, response times, indemnification clauses, and integration requirements all create work the engineering organization will eventually have to honor.
  • Intellectual property. Who owns the code, the design assets, the trained models, the data, and the configurations? Ownership in a vendor-client relationship is often less clear than the parties assume.1
  • Privacy and data protection. Regulations like GDPR (EU), CCPA (California), HIPAA (US healthcare), and others impose specific obligations on how personal data is collected, stored, processed, and deleted. The penalties are real and growing.
  • Compliance frameworks. SOC 2, ISO 27001, PCI DSS, and industry-specific equivalents create ongoing operational requirements: audit trails, access controls, and evidence of controls being followed.
  • Liability. When something goes wrong (data breach, downtime, incorrect output that causes business harm), who is responsible and how much exposure exists?
  • Insurance. Errors and omissions, cyber liability, general business insurance, and contract-required coverage. The insurance industry has opinions about how software is built and run, and those opinions show up as policy exclusions.
  • Data handling. Where data is stored geographically, who has access, how long it is retained, when it must be destroyed, and how it crosses borders.

Each of these categories has its own specialist. The engineering organization's job is not to be that specialist. It is to know that the obligation exists, and to involve the right people early.

Why This Matters to Engineering

It is tempting to treat legal and insurance as out-of-band concerns that someone else handles. They are not. Several of the most expensive incidents in modern software history started with an engineering decision that looked routine at the time:

  • A contract uptime commitment that nobody told the on-call team about turns a routine outage into a contract breach.
  • A region setting that put data in the wrong country turns a configuration choice into a regulatory violation.
  • A logged field that should not have been logged turns standard observability into a privacy breach.
  • An open-source license that requires source disclosure turns a dependency choice into an IP exposure.

None of these are problems the legal team can fix after the fact. They are designed in.

What This Looks Like in Practice

A few habits keep legal and insurance considerations in the engineering conversation early enough to matter:

  • Read the contract before signing the architecture. Engineering should see customer contracts, vendor contracts, and any commitments that mention uptime, data handling, security, or response time. If the contract says four nines and the system can deliver two, that is an engineering problem with a contractual deadline.
  • Identify what data is regulated, and treat it differently. Personal data, health data, payment data, and financial data carry obligations that other data does not. Knowing which fields fall into which category should not be tribal knowledge.
  • Make license types visible in dependency management. Open-source licenses range from permissive (MIT, BSD, Apache) to copyleft (GPL, AGPL). Some are incompatible with commercial use. The cost of finding out late is rebuilding the integration.
  • Document data flows. A simple diagram of where each kind of data enters the system, where it is stored, who can access it, and where it leaves is useful for engineering, legal, security, and audit. The same artifact serves all four.
  • Bring legal in early on irreversible decisions. Vendor selection, data residency, customer contract templates, and acquisition due diligence are all easier to get right than to fix.

Not legal advice

This guide is not legal advice. The point is to recognize that software products create legal and operational obligations, and that the cheapest time to involve the right specialists is before the decisions are made.

See also: Total Cost of Ownership, Owning vs Licensing, Observability, Incident Response.

  1. Intellectual property questions in vendor-client software work are particularly easy to get wrong. Default contract terms often vest ownership with the vendor unless explicitly reassigned, while clients frequently assume the opposite. The cheapest time to clarify is in the original statement of work, not after delivery. ↩