“Can you update the supplier's bank details?”
Monday morning. Hana in Sandline's finance team pauses over the request.
Who asked? Who checked? Will the next payment use those details?
That's our way into “what is data governance”. Sandline Supplies is our fictional distributor, and it runs on Beezr. Let's follow one change: who decides, what enforces the rule, and what proof stays behind.
What is data governance?
Data governance is agreeing how to handle data and who answers for it. Then you build controls to make those rules stick.
Think of a shared key cupboard. Someone owns it. Each person gets only the keys their job needs.
It covers meaning and quality too. What counts as an active supplier? Which bank account is approved?
Who settles a dispute between procurement and finance?
DAMA says governance sets out who answers for data, its policies and decision rights. NIST describes processes to ensure data is formally managed across the whole business. You need both the decision and a way to carry it out.
A permission can't tell whether a bank account is real. Hana can't enforce a policy if everyone can edit the fields.
What are the data governance roles?
The GDS ownership model splits the work three ways. Owners answer for data and approve changes.
Stewards do the daily work. Custodians store and protect it to the owner's rules.
Borrow the jobs, even if you don't use the titles.
| Responsibility | Sandline assignment | The question this person answers |
|---|---|---|
| Data owner | Hana owns the supplier payment-data policy | What evidence is enough to approve a change? |
| Data steward | Omar checks supplier details and prepares requests | Is the request complete, and does it refer to the right supplier? |
| Technical custodian | Karim configures and tests the controls | Can the wrong role bypass the intended route? |
| Approver | Hana reviews each bank-change request | Should these proposed details become the approved details? |
| Data user | Procurement and finance use the permitted fields | Which details may I use for this task? |
Hana owns the policy and approves requests here. That's Sandline's choice, not a software rule. Omar prepares; Hana reviews.
Least privilege means giving people only the access their work needs. Separation of duties means splitting the jobs. Both are controls in NIST SP 800-171 Revision 3.
Letting one person request and approve a bank change needs a risk review.
A data governance example: changing bank details
Kestrel Safety, our fictional supplier, sends new bank details. Omar wants a current record. Hana wants a proposed account kept apart from an approved one.
This is a build you can configure in Beezr. It uses modules, rules for field access and workflows with approval steps. It's an example design, not a ready-made template.
Follow one bank-change request
- Omar Create the records — link a Bank Change Request to the supplier.
- Omar Propose the change — add details and a reason; lock approved supplier fields for his role.
- Hana Check and decide — verify the request, then approve or reject it.
- Workflow Update on approval — use a Smart Script in the approved branch. Rejection leaves the supplier unchanged.
- Permitted users Read approved details — show bank fields only to profiles that need them.
- Hana and Karim Check the trail — inspect the request, approval history and workflow run.
Sandline · example
The change is waiting. That's the point.
Omar creates the linked request in Beezr. His profile makes approved supplier bank fields read-only. Writing a proposal leaves the payment details alone.
Hana checks it against Sandline's policy. Here, she checks with a supplier contact known through a separate route. Sandline must arrange that human check.
She can ask for clarification if needed. Approval sends the workflow to the update step. Rejection takes a different branch.
The approval history keeps the decision, who made it and when. The request holds proposed values and the reason. Workflow history shows the steps and errors.
Lock submitted requests so the proposal can't change beneath the review. Agree how to send a fixed request back for review. Test who can edit the supplier directly too.
Which control enforces each rule?
Put policy and control side by side. A blank control cell is work to do.
| Sandline's policy | Control to configure in Beezr | What it doesn't settle |
|---|---|---|
| Only procurement prepares supplier changes | Role with a permission profile allowing the relevant module and request creation | Whether the requester has checked the source |
| A proposal must identify the supplier | Supplier relation on the request and a completeness check in the form rule book | Whether the chosen supplier is the intended one |
| Requesters cannot overwrite approved bank details | Read-only or hidden bank fields for their profile | Which exceptional administrators still have edit access |
| Finance must approve before publication | Approval task, then a separate approved branch that performs the update | Whether the verification was done well |
| Sales doesn't need bank-account details | Hidden bank fields in the sales profile | Copies already shared outside the application |
| Sensitive bank fields need storage protection | Field encryption after workspace setup, with an active key selected on each relevant field | Whether a permitted user should see the value |
| We must explain the bank-change decision | Related request record, approval history and workflow run history | A general old/new history of every bank-field edit |
| We want a history of approval-status changes | A lookup status field with Track changes enabled | Changes made before tracking was enabled |
How Beezr does it
Check the access and the history. Beezr narrows access through application, module, record and field permissions. Each role carries one profile. People can edit a field, only read it, or have it hidden.
Creation history keeps who created the record and when. For lookup fields, Track changes keeps old and new values, who and when. It starts when enabled.
Use the request and approval workflow to explain this bank change.
Field encryption needs workspace setup first. Then add a key and choose the active key on each field. Include sensitive fields on both the request and supplier.
What belongs in a data governance framework?
Write one short page before shopping for tools. Say who owns the data and what each field means. Set rules for quality, access, approval, proof and review.
Define “approved bank details”. Has someone approved the request, or has the update finished? Finance should check the update before using the new values.
Plan for an absent approver, a failed update and removing temporary access. Month-end won't always follow the perfect route.
| Starting point | Where it helps | The honest catch |
|---|---|---|
| Written responsibilities and definitions | Nobody agrees who decides or what a field means | The agreement still needs to reach the working process |
| Access and approval controls | People can make consequential changes through the wrong route | Controls can faithfully enforce a poorly chosen policy |
| An inventory or data catalogue | Nobody knows which records exist or who uses them | Knowing where data lives doesn't resolve a disputed bank change |
| One critical record, followed end to end | You need to prove a complete policy and control chain | It covers that process first; wider dependencies still need review |
What should you fix first?
- If no one owns the decision → assign an owner — the builder needs an agreed rule.
- If the wrong person can make the change → test access and approvals — make the rule hold.
- If you don't know who uses the data → map records and users — find the work a change affects.
- If you can't explain a decision → design the proof — check which records and histories you need.
Myth / Reality
“We bought a tool, so the data is governed.” Tools can hold definitions, restrict access or route approvals. People still choose the rules and review decisions. Test a real record.
How do you start this week?
Choose one record whose wrong value could change a decision. Bring its owner, the person preparing it and the systems lead.
Try a normal request, rejection and failed update. Try again with a role that should have no access. Write down expected and actual results; give each gap an owner.
Ask who decides, where proposals wait and who may edit them. Then check proof of approval and a completed update. Name who deals with a no, a question or a failed step.
Our take
Our take. Start with one record you can follow. It gives the owner and builder something to test and fix. Once it works, take the same care with the next process.
Key takeaways
- If you're technical: test roles and both branches. Check which history each step keeps.
- If you're not: ask to see one request through to its approved update.
- Set rules for what data means and its quality too.
- A proposal, a decision and a finished update are separate proof.
Govern the supplier record in Beezr
Build a request finance can review before approved values change.
- Create the modules — Suppliers and related Bank Change Requests, with details and a reason.
- Set role access — let procurement propose; lock approved fields and hide them where unneeded.
- Build approvals — name the approver. Split approved and rejected branches; put the update Smart Script after approval.
- Check the proof — inspect creation, approval and run histories. Enable Track changes on lookup statuses you need to track.
- Set up encryption — arrange workspace setup; choose active keys on sensitive fields in both records.
Questions readers ask
Data governance vs data management: what's the difference?
Governance sets who decides and which rules apply. Management is the work done under those rules.
People prepare requests, make the agreed change and keep records up to date. DAMA lists governance among 11 data management knowledge areas.
What is a data governance framework?
It links people and rules to the checks that make them work. Write who decides, what valid data means and what proof you need. Test it on a record.
What do a data owner and steward do?
The owner answers for decisions; the steward handles daily work and issues. That's the GDS distinction.
Here, Hana sets the rules for payment data. Omar gets each request ready.
What are data governance controls?
Our example locks approved fields, hides unneeded details and requires approval before updating. Its control map pairs each rule with a control and a remaining human check.
Which data governance tools do I need?
You may need to agree what a field means. Or list your data, limit access or route a review.
Ask to see your change process and its proof. Compare that with your policy before choosing.
Sandline Supplies is a fictional example company.
Sources
- What is Data Management? · DAMA International · Undated; accessed 2026-10-17
- Data governance (glossary entry, from CNSSI 4009-2022) · NIST Computer Security Resource Center · Accessed 2026-10-17
- Data ownership model · Government Digital Service · 2026-04-16
- Protecting Controlled Unclassified Information, SP 800-171 Revision 3 · NIST · 2024-05