By Graeme Forbes Graeme Forbes on LinkedIn ·
“Why is governance so complicated?” is something I hear a lot from business stakeholders. The root cause is usually that capabilities and habits have built up over time, a long way from the core of the business. They are shaped by historical complexity that hasn’t been revisited with modern capabilities and methods. The person who owns the system has never been given a tangible way to manage it that also lets them make meaningful decisions.
If I try to mend a modern car with traditional tools, I can fix the normal user-serviceable parts, but it is very hard to get under the bonnet. The technology has moved on, and we have reluctantly accepted that when it breaks, a computer gets plugged in to diagnose the problem and a mechanic provides the fix. I may own the car, but there are strict limits on what I can change. Cross certain boundaries and it triggers a re-evaluation, which can mean higher running costs or a car that won’t start.
Governance has moved on, like the car
Businesses still understand governance from the legacy perspective rather than the modern reality. Like cars, core systems have become larger, faster, more complex and close to impossible for people to get into or across. That calls for a layered approach to governance, where policy drives the behaviour, the right access control capability implements it, and observable metrics report on it.
I spent two years employed at one company, working this through with the directors, the CISO, governance, engineering, finance, HR, IT and the wider business. It is a fundamental change in how things are done, not a plaster stuck on the process. AI makes it much easier to bridge the gaps and become an organisation where business strategy is translated into policy automatically. What it can’t change is entrenched behaviour.
Top down or bottom up
There are two fundamental ways of driving access controls: top down or bottom up.
The traditional way of granting and adjudicating access is bottom up. It normally shows up as “computer says no”, or a sharp intake of breath and “that’s complicated”. That runs against the whole job of technology, which is to enable. The business relies on technology to deliver its top-down assumptions: keeping its performance edge, building the capabilities its strategy needs and meeting demand as it scales.
In the age of AI, this maps best to a chain where each layer has one job:
- Business-defined policy sets the intent.
- Mandatory access control (MAC) sets the limits.
- Attribute- and role-based access control (ABAC and RBAC) grant access.
- Rules add context.
- Discretionary access control (DAC) delegates within those bounds.
| Model | What policy creates | Artefacts | Owner | Example |
|---|---|---|---|---|
| PBAC, policy-based (the source) | The policy itself | Policy statements, policy as code, exceptions register | Governance council or CDO | Personal data accessed only for a stated purpose, by authorised UK staff |
| MAC, mandatory (the ceiling) | Fixed sensitivity tiers | Classification scheme, data labels, user clearances | Information security | Restricted data needs Restricted clearance, with no exceptions |
| ABAC, attribute-based (the grant) | Fine-grained conditional grants | Attribute dictionary, rules-engine policies | Data governance and the platform team | Allow if department is Finance and the data’s region matches the user’s |
| RBAC, role-based (ABAC where the attribute is a role) | Coarse, job-based bundles | Roles, permission matrix, joiner, mover and leaver mappings, segregation of duties rules | IAM and HR-aligned role owners | The analyst role gets read access to the curated layer |
| Rule-based (ABAC where the attribute is context) | Contextual guardrails | Rule sets, conditional access, network rules | Security operations | No production data outside 07:00 to 19:00, or off the network |
| DAC, discretionary (delegation) | Limited owner discretion | Access control lists, sharing links, delegated grants with expiry | Data owners and stewards | An owner shares a dataset with a project team for 30 days |
Where to start
A policy-driven approach shortens the distance between the person accountable for a change and the place it is implemented. The first step in modernising is to build the current policy state from the controls you already have, compare it with the state you want, and then check the processes actually in use.
The people in the loop check that the automation is working within bounds and leaving a valid audit trail. If that sounds more and more like driving the business the way you drive a modern car, letting the sensors and computers take on more of the cognitive load, that’s exactly the idea. The main thing is to build the observability that lets you trust the processes, and confirm that policy is being translated without losing its intent. Historically, trust has broken down where that intent was bent to fit existing capabilities, rather than kept intact through updated processes and technology matched to the value of the change.
The main outcome of a good policy-driven approach is that a business owner feels in control of their dependencies. They get a clear idea of the risk and cost a change will carry before they make it. Asking a question becomes rewarding, rather than a matter of getting past institutional barriers and an aversion to the process.
How the family fits together
