Most of the people in this database never signed up for it.

For everything a contractor loads into the product — vendors, contacts, proposal recipients, uploaded documents — the contractor is the controller and Wire-In is the processor. The contractor decided to collect it, and Wire-In has no relationship with the people it describes.

For its own account records — who holds a login, which organization, which role, billing contact — Wire-In is acting on its own behalf. The addendum has to name that boundary rather than sweep everything into one role, because the obligations differ on either side of it.

Under the California statutes the equivalent framing is business and service provider, and the corresponding no-sale, no-share, no-retention-for-own-purposes commitments belong in this document.

Processing lasts as long as the subscription, plus whatever export and deletion window the terms of service settle on. The two documents have to agree on that number, and today neither has one.

The addendum should attach to the main agreement rather than stand alone, so that a single termination ends both.

Employees of the customer who hold accounts. Employees of subcontractors who are invited to bid, whether or not they ever register. Client-side contacts who receive a proposal link. Occasionally an individual named on a certificate of insurance or a W-9, where the vendor is a sole proprietor.

The last group is the one most often missed in a template, and it is exactly the group whose document contains a taxpayer identification number.

Business contact data: names, work email addresses, phone numbers, job roles. Company-level data that is not personal: trades, service areas, contractor license numbers, ratings.

File contents, which are the exception to everything else. Certificates of insurance and W-9s are stored as uploaded files. A W-9 contains a taxpayer identification number, and for a sole proprietor that number can be a social security number.

The annex should state precisely what the system does and does not do with those files: it stores them in a private bucket, records a filename, storage key, content type, size, uploader and kind, and does not extract, index, search or display any identifier inside the document. No column exists in the schema to hold a tax identifier. That precision is what makes the annex defensible.

Wire-In processes the data to run the product for the customer, and for nothing else. In practice the instruction is the customer using the software, plus anything separately agreed in writing.

Whether customer data may be used to improve the product, to build cross-customer benchmarks, or to train any model has to be answered here in one unambiguous sentence. Nothing does today, and a reviewer will look for this clause first.

The usual clause assumes a team with onboarding, background checks and role-based internal access. Wire-In is currently operated by one person, and the addendum should describe the arrangement that actually exists rather than a control environment that does not.

An honest, narrow statement here is more defensible than a borrowed paragraph, and it will survive the follow-up question. It should be revisited the moment a second person has production access.

This becomes Annex B. It should be built from the security overview, which describes the isolation model, the file storage model, the authentication model and the gaps, each traceable to a specific file in the codebase.

The load-bearing measure is tenant isolation enforced by Postgres row-level security rather than by application filtering, with a policy on every tenant table and a runtime role that has no bypass. It is regression-tested against a live database on every change, and the test asserts that an unfiltered query returns nothing belonging to another tenant.

The annex must carry the gaps as well: there is no third-party audit, no penetration test, no multi-factor authentication and no security response headers today. Listing them is what makes the rest of the annex credible.

Four: Vercel for hosting, Supabase for the database, authentication and file storage, Stripe for payment processing, and Resend for transactional email.

The addendum needs a maintained public list, a notice period before a new sub-processor is engaged, and a stated consequence if the customer objects. Notice with no consequence is not a right, and a reviewer will say so.

Stripe is worth calling out separately because card data never reaches Wire-In at all — checkout is hosted by Stripe and the customer is redirected to it. That is a narrower relationship than the other three.

There are none today. The application, the database and the file storage are all in the United States, and customers are United States general contractors.

This section still needs drafting rather than deleting, because the first Canadian or United Kingdom customer makes it load-bearing overnight, and that is a bad moment to discover the transfer mechanism was never agreed.

Most requests will reach the contractor, not Wire-In, because the contractor is the one with the relationship. The addendum should say how a request is passed on, what Wire-In will do, and within what period.

What the product can actually do today is the constraint: records can be edited and deleted through the interface, but there is no bulk export of everything about one person and no automated erasure. The commitment has to match the tooling, or the tooling has to be built first.

A concrete period, counted from becoming aware, and what the notification will contain. A number that cannot be met in practice is worse than a longer one that can.

There is no incident response plan and no on-call rotation today, and error tracking is not enabled. Those are prerequisites for any commitment made here, not details to work out afterwards.

What a customer gets back, in what format, within what window, and when the copies are destroyed — including files in object storage, which are the easiest thing to forget.

None of this is automated today. The clause and the mechanism should land in the same change, so that the document never describes a process that does not run.

There is no SOC 2 report, no ISO 27001 certificate and no third-party penetration test. Any audit clause has to work without one, so what a customer can reasonably ask for should be spelled out rather than left to a generic right of inspection.

What does exist is unusually concrete for a company this size: the isolation model is in a readable migration file, and the adversarial test suite that proves it can be run by anyone with the code. Offering that under an appropriate agreement is a stronger answer than an audit clause nobody will ever exercise.

Annex A — the processing details: subject matter, duration, nature and purpose, categories of data and of data subject. Mostly assembled from the sections above.

Annex B — technical and organizational measures, derived from the security overview and kept in step with it.

Annex C — the sub-processor list, with location and purpose for each, maintained as a living page rather than frozen into a signed PDF.