Each role has its own question

You ask your team. You get the answer "it is under control". That answer is honest and most likely correct.

But that answer is the knowledge of a person, not the output of a system. Ask the same question six months from now, when that person has moved on, and you will not get the same confidence.

The commitment you gave the board rests somewhere you cannot see.

Governance does not invent a new process. It takes the good processes you already have out of personal dependency.

The rule a change was approved under sits inside the record, together with the rule as it stood that day. Even after the rules change, an old record is still read against the rules of its own day.

The answer you give the board then rests on a verifiable record rather than on someone's memory.

Identity management is in place. Privileges are defined, access is reviewed, privileged accounts are monitored.

Then a manager asks for some data. An authorised person runs a permitted query, puts the result in a file and sends it. No rule is broken.

Who took which data for what stated reason, which fields went out in the clear, and where the file ended up are nowhere recorded together.

Reading production data is treated as seriously as changing it: request, reason, approval and delivery live in a single record.

Which field is masked stops being a person's decision and becomes the rule's decision. If a field goes out in the clear, that approval is recorded separately.

Evidence is not gathered afterwards. The delivery produces the record, and that record can be verified from outside the system that keeps it. This requires a signing key and an external digest store to be configured; on an unsigned package the verification script reports UNSIGNED.

Every server has its own record. Some have a monitoring tool, some have system logs, some have only a backup history.

Answering "which server did this change reach" means looking in several places. The answer is usually found, but it takes time.

Environments drift apart over time. The difference between test and production grows through small interventions nobody planned.

The server becomes a parameter of governance. A query result request can target several servers and the outcome for each is recorded separately; a change request goes to a single server, because there is no shared transaction across servers.

The scope list covers eight paths, and it includes privilege changes and maintenance work. In most organisations those sit outside scope.

Object history shows every request that touched an object through the product. The "current definition on the server" comparison reads the object as it is on the target right now; a change made outside the product can be read in that current definition, but the product does not detect it on its own.

The audit plan is set, a sample is drawn, evidence is requested from the relevant team. The team gathers it and you wait.

What arrives is screenshots, printed emails and hand prepared spreadsheets. All of it may be accurate. None of it is independent.

The sample is kept small, because gathering evidence for each item costs the team a week. A small sample means narrow assurance.

Evidence is not gathered afterwards. The action produces it. That also lowers the burden on the audited team, so both sides gain.

Every record carries the rule set that was in force that day. Even after the rules change, an old action is read against the rules of its own day.

Every skipped step is recorded with its reason. An exception stops being invisible and becomes reviewable.

The evidence file can be verified independently of the system that keeps it. You perform the verification rather than being told the result. This requires a signing key and an external digest store to be configured; on an unsigned package the verification script reports UNSIGNED.

That sentence means nothing without a mechanism behind it, so here it is. Every package delivered to you is a zip containing the data itself, an identity file listing the SHA-256 digest of every file in the package, a verification script and, where a signing key is configured, the RSA signature over that identity file and the public key that checks the signature.

Package verification runs on your machine. Nothing connects to the product and nothing goes over the network. The PowerShell that ships with Windows, or openssl, is enough.

The records themselves live in a SQL Server 2022 append-only ledger table. The ledger digest is taken every hour by default; where a signing key and an external output folder are configured, it is signed and written to the organisation's own immutable store. If these two settings are not made there is no outside digest to compare against and the verification is not independent. On a copy restored from backup in the organisation's own environment, you run SQL Server's own procedure against those digests or watch it being run; the backup does not leave the organisation. On the same copy you also see which database account wrote each record. The period package reconciles every request of the period from two separate sources, so the question "did I see them all" has an answer too.