Data governance and GDPR for Glasgow organisations: controls that produce evidence

The question that exposes an analytics estate is simple: who could see this dataset last quarter? In most organisations the honest answer takes a week of investigation.

This page covers data governance and compliance for analytics estates in Glasgow: what the Information Commissioner's Office (ICO) expects under UK GDPR and the Data Protection Act 2018, which sector rules bite hardest given the local economy of retail and commercial banking, insurance and reinsurance, and industrial machinery and engineering, and how to implement controls in Microsoft Purview and Power BI that produce evidence rather than paperwork.

What the Information Commissioner's Office (ICO) expects of an analytics estate

Under UK GDPR and the Data Protection Act 2018, four obligations land on an analytics estate harder than the rest: collect no more than you need, keep it no longer than you must, control who can reach it, and be able to answer an access or erasure request. Analytics estates fail these quietly: a warehouse accumulates every column from every source because it was easier than deciding, retention defaults to forever, and permissions are granted to individuals who then change role.

• UK GDPR data-minimisation and storage-limitation duties apply directly to analytics copies of personal data, which is where most estates quietly fail.
• Consumer Duty outcome monitoring has made customer-level analytics a supervisory expectation for regulated firms, not an optional capability.
• SECR energy and carbon reporting requires auditable activity data, which usually means the same lineage discipline as financial reporting.
• The Procurement Act 2023 regime governs public-sector buying routes, including analytics work bought through frameworks.

None of this requires a governance department. It requires four things that can be implemented in weeks: a catalogue people actually search, classification that drives retention and labelling, access granted through groups, and evidence that can be produced without a project.

Sector rules that bite in Glasgow

Glasgow's economy means the governance conversation here is not generic. With Scotland's largest financial services and shared-services base and engineering and shipbuilding activity on the Clyde shaping the local client base, these are the obligations that come up in practice.

Insurance and reinsurance

Claims data frequently includes health and criminal-conviction information, which attracts the stricter GDPR special-category conditions. Policy, premium and claims data where the same risk is represented differently in underwriting, finance and claims systems, and where development over time is the whole point.

The practical consequence for an analytics estate is that access design cannot be retrofitted. Row-level and object-level security have to reflect how authority is actually delegated in the organisation, and the design needs testing from a non-privileged account rather than assumed from documentation.

Retail and commercial banking

Account-level data is both personal data and commercially sensitive, so row-level security and export control are design requirements rather than later hardening. Typical systems in scope: core banking platform, general ledger, card and payment processors, credit decisioning systems and CRM.

Public sector

Freedom of information and transparency duties mean published figures must be reproducible, and disclosure control has to be applied in the pipeline.

Who can see what, and how you prove it

This is the question that exposes an estate, and the fix is unglamorous. An estate built on individual grants can only be evidenced by investigation. One built on directory groups aligned to your control model can be evidenced by running a report.

The sequence is always the same: extract the permissions that actually exist, design groups around how the organisation really delegates authority, migrate and remove the individual grants, then make the evidence self-service so your second line runs the report instead of raising a request. For a business in insurance and reinsurance, the groups normally need granularity by function and by entity or site.

Classification, labels and the export problem

Where data escapes, it is normally through a spreadsheet someone needed for a legitimate reason. That is why the control has to travel with the file rather than live in a policy document. Sensitivity labels applied in Power BI travel with the exported file, so encryption and access restrictions persist outside the platform, and export can be blocked entirely for specific labels or audiences.

The classification scheme has to align to the information security policy you already have rather than introduce a competing taxonomy, and retention has to be enforced against your actual obligation under UK GDPR and the Data Protection Act 2018 instead of kept forever by default. Every control is then verified from a non-privileged account, because the most common finding in a governance review is a restriction that was configured correctly and never actually tried.

Working with British organisations: the practical constraints

• Most UK engagements run remote-first with on-site workshops for definition sessions and go-live.
• IR35 and off-payroll rules make a fixed-scope statement of work cleaner than a day-rate contractor arrangement for many clients.
• Public-sector buyers typically route analytics work through established frameworks rather than open tenders.

UK GDPR diverges from the EU regime in places, so an organisation operating on both sides needs a position on each rather than one pack covering both. Where you process EU personal data as well, both regimes apply and the documentation has to reflect that.

A 90-day plan that produces evidence

1. Days 1 to 15: assessAccess extract versus policy, data map, classification gaps, retention reality. Output is a risk-ranked remediation plan, ordered by exposure rather than by ease.
2. Days 15 to 35: defineAn operating model that names who owns what, a classification scheme, retention rules tied to the actual obligation, and access standards. Agreed with legal and with the business, because a scheme they did not approve will not survive contact with them.
3. Days 35 to 70: implementPurview scanning and catalogue populated, labels published and applied, access rebuilt onto groups, lineage switched on, suppression implemented in measures.
4. Days 70 to 90: evidenceAccess evidence reporting, audit pack generation, steward training, and the first governance review run with your team rather than for them.

That sequence works because each stage produces something usable on its own. If the programme stops after the assessment, you still hold a risk-ranked plan an auditor would accept. Book a technical review if you want that assessment for a Glasgow organisation.

We work across United Kingdom and deliver into neighbouring markets regularly. Nearby pages worth reading if your group has sites elsewhere: Birmingham, Cardiff, Northampton, Norwich, Peterborough and Portsmouth.

Frequently asked questions