When I landed a role in telecoms, it was a fun company, chaotic in the right ways. I was hired as a Senior Data Engineer, but as always, that also meant DBA. Predominantly on-prem. Big estate. Lots of moving parts.
Then I got handed a governance project.
That meant 5am train to Manchester. In for 7am. Check the estate if needed. Then straight into a day of meetings with:
- Me — the new guy
- The Head of Governance
- A room full of section leads
And here’s the important bit:
I wasn’t just attending.
I was responsible for building the DBA side of the data policy.
Suddenly this wasn’t just about tickets.
It was about writing rules the company would stand behind.
Governance (As a DBA First Sees It)
Most DBAs first encounter governance through access control.
“Administer access.”
It sounds operational.
But it’s actually the frontline of corporate risk.
You set up:
- A ticketing process
- SLAs
- Evidence logging
- Separation of duties
- Least privilege rules
The idea looks simple:
- Person or app requests access.
- Ticket logged.
- Data owner approves.
- DBA implements.
- Evidence attached.
- Audit trail preserved.
Clean. Controlled. Sensible.
In practice?
Chaos.
Where It Breaks
An application gets built.
No SQL access scoped.
Deployment tomorrow.
Now they need elevated access “urgently”.
You review it and realise:
- The access is too broad.
- The role model is weak.
- It violates least privilege.
- It bypasses separation of duties.
You push back.
The conversation escalates.
And here’s the thing most engineers don’t realise:
When risk is clearly explained, leadership usually sides with risk mitigation over delivery speed.
Not because they love slowing things down.
But because they understand something fundamental:
Risk doesn’t scale linearly.
One bad access model multiplied across an estate becomes exposure.
What I Was Actually Building
In those meetings I started to understand something.
Governance isn’t just:
- Owner
- DBA
- Ticket
It’s structured.
It needs defined roles:
- Owner – Accountable for the data.
- Processor – Operates on the data.
- Auditor – Verifies controls independently.
My responsibility was to define:
- What sysadmin actually means.
- Who can grant it.
- Under what circumstances.
- How access is approved.
- How access is revoked.
- How changes are evidenced.
- How separation of duties is enforced.
- How emergency access works.
- How it is audited.
Not “how we normally do it.”
But how we can prove we do it.
That’s a big difference.
The Auditor Perspective
At a certain size — or especially if you’re regulated or publicly listed — governance stops being optional.
Auditors don’t care if:
- You’re busy.
- The project was urgent.
- The team meant well.
They care about:
- Documented policy.
- Repeatable process.
- Evidence.
- Testing of controls.
If they ask:
“Show me how sysadmin is granted.”
You can’t reply with:
“Dave normally sorts that.”
You need:
- Policy document.
- Approval workflow.
- Logged evidence.
- Review schedule.
- Role definition.
- Access review cadence.
Even if you were doing everything right —
If it’s not written down and testable:
From an audit perspective,
It didn’t happen.
The Shift
Before that project, governance felt like friction.
After building the DBA side of the policy, I saw it differently.
Governance isn’t bureaucracy.
It’s risk architecture.
It’s how a company proves to:
- Regulators
- Shareholders
- Customers
- Itself
That it understands what could go wrong.
And that it controls it.
The Bit Engineers Need to Hear
Governance is not anti-engineering.
It’s engineering with accountability.
If you want to move toward:
- Data Architect
- Platform Lead
- CTO
- Public company scale
You can’t treat governance as paperwork.
It’s design.
Because the moment your system holds value —
Money, data, reputation —
Someone will ask:
Who owns this?
Who can change it?
Who checks it?
Show me the evidence.
If you can answer confidently —
You’re not just a DBA.
You’re part of the company’s risk framework.
Gareth Winterman