Governance decisions that are cheap on day one

Nobody books a governance workshop. Governance arrives later, usually as a question: an auditor asking where the data is held, a client security questionnaire with forty items on it, a privacy complaint, or a board member asking what the AI tool everyone is using does with the information staff paste into it.

By then the answers are expensive. Not because the decisions are hard, but because there is production data in the system and every change has become a migration with a legal conversation attached.

Four decisions account for most of that pain. All four can be made in a half-day before a line of code is written, and all four cost close to nothing at that point.

Why retrofitting is the expensive part

On day one, each of these is a sentence in a design document. Somebody decides, somebody writes it down, and the build proceeds accordingly. The cost is an hour of attention.

Two years later the same decision is a different animal. There is live data, so changing where it sits is a migration. There are integrations, so changing who can read it means auditing every caller. There is history, so introducing a deletion rule means deciding what to do about everything already stored under no rule at all. And there are people relying on the current behaviour, so any change needs a communications plan.

The bottom-right cell is the one worth reading twice. The other three are expensive. Logging is the one where the answer can simply be that the information does not exist, and no budget recovers it.

Residency: decide it for the backups and the logs too

AWS, Azure and Google Cloud all offer Australian regions, so the primary question is usually easy to answer. The part that catches people is everything around the primary store.

• Backups and snapshots, which are sometimes replicated to a second region by a default nobody chose.
• Logs and telemetry, which frequently leave the region through a monitoring product.
• Managed services that process rather than store, including transcription, translation, search and model inference.
• Support arrangements where a vendor's engineers can access data from wherever they are based.

The honest answer to "where is our data?" is a list, not a region name. Producing that list at design time takes an hour. Producing it during a client security review, under a deadline, takes a fortnight and finds surprises.

Retention: a deletion rule is a design input

Most systems are built to keep things. Deletion, where it exists at all, tends to be a manual act by an administrator rather than a rule the system runs.

That is a defensible choice as long as it is a choice. What is not defensible is discovering, seven years in, that you hold every document a client ever sent, that your privacy policy says you keep information only as long as necessary, and that nobody can define necessary for any of it.

The design-time version is simple. Name the classes of data the system will hold, put a retention period against each, and build the deletion path while you are building the storage path. It is a field and a scheduled job. Retrofitted, it becomes a policy exercise across records nobody ever classified.

Access: model the roles before there are exceptions

Access models do not usually fail at design. They fail one urgent request at a time. Someone needs to see one report, so they are granted a permission directly. It is the right call in the moment, it is never revisited, and eighteen months later the only accurate description of who can see what is the permissions table itself.

Three or four named roles agreed at the start, with a rule that access is granted by role rather than by person, prevents most of that. It also makes offboarding a single action instead of an investigation, which matters more than it sounds: the accounts that cause trouble are usually the ones belonging to people who have already left.

Logging: decide what a future auditor will ask for

The test for logging is not whether a developer could debug the system. It is whether you could reconstruct, months later, what happened to one record and why, in a form that satisfies somebody external.

• Who or what acted, including automated processes acting on nobody's behalf in particular.
• What changed, with the previous value, not just the new one.
• What information the decision was based on, which is the part that matters most for anything automated.
• When, in a timezone that is stated rather than assumed.

This matters twice over where AI is involved. A decision an automated step took cannot be explained after the fact unless the inputs and the reasoning were recorded at the time. "The model decided" is not an answer anyone accepts, and it is the only answer available if the logging was not designed in.

The half-day version

None of this requires a governance function or a framework. For most projects it is one session, with the right four or five people in the room, producing a page.

1. 01List the classes of data the system will hold, in plain language rather than schema names.
2. 02For each class: where it lives, where its backups and logs live, how long it is kept, and who can see it.
3. 03Name three or four roles, and agree that access is granted by role and reviewed on a date.
4. 04Write down what gets logged for every action that changes a record or makes an automated decision.
5. 05Note the assumptions you could not resolve, and who owns resolving them. An open question with a name against it is governance. An open question without one is a risk.

The short version

Residency, retention, access and logging are cheap at design time and expensive afterwards, and logging is the one that can become impossible rather than merely costly. Spend the half-day. The output is a page, and it is the page you will be grateful for when somebody external asks a question you have not thought about in two years.