The Compliance Decisions We Made Before Writing a Line of Code

Category: Customer Trust & Third-Party Risk Tags: privacy by design, tenant isolation, data minimization, deletion, SOC 2, GDPR, dogfooding

The retrofit conversation is always the same and I have been in it from both chairs. A product has traction, an enterprise deal appears, and the customer's security review asks four questions that turn out to be architectural. Can you delete one customer's data without touching anyone else's. Can you prove tenant A never sees tenant B. Where does this data physically sit. What did this user do, and when, and can you show me. Nobody asked those questions while the schema was being written, so the answers are no, not really, wherever the default region is, and we have some logs. What follows is six to twelve months of expensive remediation, and one or two items that never get properly fixed because fixing them means a migration nobody will fund.

PivotRisk is building a hosted platform, and it is currently a design rather than a product. That makes this the one moment when these decisions are nearly free, so we made them now and I am writing them down while they are still falsifiable. This is the second piece in a series where we run our own compliance program in public, and the same rules apply as in the first one: nothing below is a control that exists today. These are decisions, dated 16 August 2026, about a system that has not been built. When they become real they will be described with the date they became real, and if we change our minds I will write that too.

Why the Retrofit Is So Expensive

It is worth being precise about which things are cheap now and brutal later, because the asymmetry is not uniform. Some controls genuinely can be added at any time. Encryption in transit, most policy documents, access reviews, security training: none of those care much when you start.

The expensive ones are the properties that live in the shape of the data. Isolation is the clearest case: if tenants share tables and separation depends on every query carrying the right filter, then isolation is a property of your code review process forever, and one missing clause in one endpoint is a cross-tenant disclosure. Deletion is the second: if a customer's records are scattered across a dozen tables, an analytics pipeline, a search index, and a backup regime nobody designed for erasure, then honoring a deletion request means engineering work per request, so the honest answer to a customer's DPA question is a promise about effort rather than a capability. Data inventory is the third and the most quietly damaging, because if you never recorded which fields hold personal data and why, then every future privacy question, every records-of-processing exercise, every subject access request begins with an archaeology project across a codebase nobody remembers writing.

Each of those is a schema decision wearing a compliance costume. That is why the cheapest time to make them is when the schema is a drawing.

The Decisions

Five, and I will state them as what they are, which is design constraints we have committed to rather than features we have shipped.

Isolation is architectural, not a query filter. Each tenant's data gets its own database rather than a shared table with a tenant column. This costs us operational complexity and it buys the ability to answer the isolation question with a boundary rather than a promise about code discipline. It also makes several other things fall out cheaply: per-tenant export is a copy, per-tenant deletion is a drop, and a tenant-scoped backup is possible without filtering.

The schema is the privacy policy. The strongest form of data minimization is not collecting a field, because a field that does not exist cannot leak, cannot be subpoenaed, cannot be retained too long, and never appears in a breach notification. The duty of care capability is the sharp end of this, since it involves knowing where employees are, and I wrote separately about why that data is both necessary and dangerous. The decision is that we collect the coarsest location that answers the question rather than continuous position, and that every personal-data field has to justify itself against a stated purpose before it enters the schema at all.

Export and delete are release-one endpoints. Not a roadmap item, not a support ticket workflow, not a script an engineer runs. The reasoning is partly regulatory and mostly practical: a deletion path that is exercised from the first day stays working, whereas one added in year three has to contend with every downstream copy created in years one and two. Building it early also forces the data inventory to be honest, because you cannot write a complete deletion routine without knowing every place the data went.

Residency is a placement decision, made before there is anything to move. Offering EU data residency is straightforward if the architecture assumed from the start that a tenant is placed in a region. It is a migration project if everything was provisioned in one place and a customer later asks. Since our isolation model already puts each tenant in its own store, placement becomes an attribute of provisioning rather than a re-platforming exercise.

We are not writing our own authentication. Identity goes to a managed provider with enterprise single sign-on support. This is the least interesting decision on the list and probably the highest expected value, because rolling your own session handling, password reset, and SSO integration is a reliable way to generate the exact vulnerability class enterprise buyers ask about most.

The Demo Environment Is the Golden Image

One decision sits slightly outside the compliance frame and turns out to matter more than it looks. Our demo will not be a separate mock application. It is a real tenant on the real architecture, seeded entirely with synthetic data, and customer instances get created by copying it.

That has a consequence worth naming: because the demo is the template, it has to stay clean permanently, and provisioning has to be scripted and repeatable from the first day rather than assembled by hand and documented later. The compliance benefit is that the path a real customer's environment comes into existence through is the path we exercise every time we show the product, so it is tested constantly rather than performed rarely. The rule that makes it safe is absolute and easy to state: no real personal data ever enters the demo tenant. The moment someone loads a real employee roster in to make a demo more convincing, the golden image becomes a data protection incident that gets copied into every future customer environment.

What This Costs, and Where We Might Be Wrong

It would be a poor advertisement for our own honesty rules to present five decisions with no downside. Per-tenant databases are more operational work than a shared schema, and at small scale they are objectively more machinery than the customer count justifies. Cross-tenant analytics, the kind that would let us tell customers how their risk posture compares to peers, becomes materially harder, and that is a real product cost we are accepting deliberately rather than a problem we have solved. Building export and delete before we have a single customer means shipping later than we otherwise would.

There is also a subtler failure mode I want to name because it is the one I would flag in a client's program. Designing against GDPR, SOC 2, and the NIST Privacy Framework before ever being assessed against them risks building to a checklist rather than to an obligation, which produces controls that look right and protect nobody. The mitigation we are using is to work from what the data actually is and who it belongs to, then map to the frameworks afterward, rather than starting from a control list and inventing data practices to satisfy it. That ordering is the same one I argued for in the frameworks worth your time: the framework confirms the program, it does not generate it.

What You Can Hold Us To

Since none of this is built, the useful thing to publish is the list of artifacts that will exist and what each will be dated with. There will be a data inventory naming every personal-data field, its purpose, and its retention, and it will carry the date of its last review. There will be a subprocessor list with the date each was added. There will be a statement of which regions a tenant can be placed in, describing regions we actually operate in rather than ones we could. Export and deletion will be described by what the endpoint does and when it shipped. Any certification will be named with its scope, its audit period, and its report date, or it will not be mentioned at all.

Until those dates exist, this article is a set of intentions, and intentions are exactly what I criticized in the opening piece of this series. The difference between an intention and the future-tense trust page I complained about is not sincerity, it is falsifiability: these decisions are specific enough that you will be able to tell whether we kept them, and I have put them somewhere public where the comparison is easy to make. If the platform ships with tenants sharing a table and a deletion process that involves filing a ticket, this article will be the evidence, and it will be right there in the search results next to whatever we say instead.