Accepting a Shared-Operator Risk on Record

Most risk in a small software business is not managed. It is noticed, discussed, and then absorbed into the general background of things everybody vaguely knows.

That is not the same as accepting it, and the difference only becomes visible at one moment: when the risk materialises and somebody asks whether it was considered.

We ran into a case where two apps share one company as developer of record and one backend between them, and a regulatory regime in one market attaches liability to the operator rather than to the product. The right answer was to ship, exclude that market, and revisit at scale.

The point of this piece is not that decision. It is the shape of the record we wrote, because the shape transfers to any business shipping with a known risk.

Five sections

1. The decision, dated, with a named decision-maker.

Ours reads: decided 22 September 2026, by the owner, status accepted, revisit on scale. Then the decision in the owner’s actual words — “we will take the risk and ship; if it scales, we will migrate to separate systems.”

Quoting the decision-maker verbatim matters more than it sounds. A paraphrase written by the person implementing the decision drifts toward whatever makes implementation easiest.

2. What is being accepted, enumerated.

Not “there is regulatory risk”. A numbered list of the specific facts that create it. Ours had three: one company holds both products on both stores; both run on one backend with accounts in a shared table; and the second product’s architecture is unchanged.

Enumerating forces precision, and precision is what lets you notice later when one of the items stops being true.

3. What materially reduces it, and is already done.

The mitigations that exist today, each with a verification date. Ours names the market exclusion and records that it was verified in both store consoles on a specific date, with the country counts observed.

A mitigation listed without evidence of being in place is an intention.

4. What this acceptance does NOT cover.

This is the section that makes the document safe to have, and it is the one most risk registers omit.

Ours says, in substance: this is a decision about risk, so it cannot make a false statement true or a store rule optional. It then lists the things that remain hard requirements regardless — the privacy policy must be live and accurate, and no page may claim encryption the system does not provide.

Without that section, a risk acceptance becomes a general-purpose permission slip. Somebody finds it later, sees that risk was accepted, and treats an unrelated obligation as covered.

5. The trigger for revisiting.

“Revisit on scale” is imperfect — it is not a number. It is better than nothing, and the honest version of where that decision actually sits.

★ Insight ------------------------------------- The load-bearing section is the fourth. A risk acceptance is a statement about uncertainty you have chosen to carry, and it has no power over facts or over third-party rules. Conflating those is the most common misuse: a team accepts a risk, and six months later a different person reads the acceptance as authorisation to skip a requirement. Writing the boundary into the document is the only reliable defence, because the document will be read by someone who was not in the room. -------------------------------------------------

Who should sign it

The decision-maker, and that is usually not the person who wrote it.

This sounds procedural and it is the difference between a record and a memo. An engineer can describe a risk precisely and cannot accept it, because accepting a risk is a commercial decision about the business’s exposure. The owner, director or whoever carries that authority has to be the named party.

Two practical consequences.

The description has to be readable by that person. If the enumerated facts require the reader to understand the architecture, they will sign something they have not understood, and the record is then evidence of a process rather than of a decision.

The decision-maker’s own words belong in it. Ours reads “we will take the risk and ship; if it scales, we will migrate to separate systems.” That sentence carries the reasoning and the intent in a way no summary written afterwards does, and it is the part that will still make sense in two years.

Why write it at all

Three reasons, in increasing order of importance.

It survives the people. The person who made the decision may not be there when it matters. The document is the only thing that carries the reasoning.

It makes the risk reviewable. An enumerated risk with a stated trigger can be brought back deliberately. An absorbed one can only be rediscovered.

It changes what “we considered it” means. There is an enormous difference between a business that can produce a dated record naming the decision-maker, the reasoning and the mitigations, and one whose position is that it was discussed. Both may have thought equally hard. Only one can demonstrate it.

What this is not

It is not a legal document and ours says so in the first line — written by an engineer, not a lawyer, and not legal advice.

That disclaimer is not a hedge. A risk acceptance written by the people who understand the system, honestly, is genuinely useful even without legal review, and waiting for legal review is how these never get written. The document’s job is to record a decision, not to establish that the decision was correct.

When not to write one

A risk acceptance is the right instrument for a specific situation, and reaching for it in the wrong one causes harm.

Do not use it where the answer is simply a requirement. A store rule, a legal obligation or a contractual term is not a risk to be accepted — it is a condition of operating. Writing an acceptance for one of those creates a document that appears to authorise non-compliance, which is worse than having nothing.

Do not use it to defer a decision. “Accepted, revisit later” with no trigger and no owner is a way of ending a conversation, and it reads in hindsight as a decision that was made.

Do not use it for a risk you have not enumerated. If the description is a category rather than a list of specific facts, the acceptance cannot later be checked against reality, and nobody will notice when one of its premises stops holding.

The test we use: could somebody who was not in the room read this and tell whether the situation has changed? If not, it is a note rather than a record.

The template

If you are shipping something with a known risk this quarter, the page is:

• Decided: date * By: name * Status: accepted / accepted with conditions / rejected
• The decision, in the decision-maker’s words.
• What is being accepted — numbered, specific.
• What reduces it, already done — each with a verification date.
• What this does not cover — the obligations that remain regardless.
• What would trigger revisiting.

Twenty minutes. It is the difference between a decision and an omission, and the two are indistinguishable until the day they are not.

---

Awesome Apps is an app developer in Sydney building iOS and Android apps for Australian businesses. General information, not legal advice.