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

Most governance programmes we are asked to rescue failed for the same reason: they were designed to be complied with rather than to be useful.

This page covers data governance and compliance for analytics estates in Konstanz: what the federal commissioner (BfDI) and the Land data protection authorities expects under the EU GDPR and the Bundesdatenschutzgesetz (BDSG), which sector rules bite hardest given the local economy of higher education and research, software and technology, and precision engineering and instruments, and how to implement controls in Microsoft Purview and Power BI that produce evidence rather than paperwork.

What the federal commissioner (BfDI) and the Land data protection authorities expects of an analytics estate

Under the EU GDPR and the Bundesdatenschutzgesetz (BDSG), 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.

• Betriebsrat co-determination is the single most underestimated factor in German analytics projects: any reporting that could be used to assess individual employee performance generally needs a works agreement before launch.
• MaRisk and BAIT expectations mean financial-sector data lineage and documentation standards are explicit, not inferred.
• The Lieferkettensorgfaltspflichtengesetz requires supply-chain due-diligence data that most ERP estates do not hold in reportable form.
• GoBD rules on retention and immutability of accounting-relevant data affect how analytics copies of financial data are stored.

None of this requires a governance department. The working parts are a catalogue people search, classification that changes what happens to the data, access delegated through groups, and evidence on demand. None of that requires a governance function.

Sector rules that bite in Konstanz

Konstanz's economy means the governance conversation here is not generic. With a research university with strong computer science and precision engineering and instruments shaping the local client base, these are the obligations that come up in practice.

Software and technology

Product telemetry on identifiable users needs a lawful basis and consent handling, and SOC 2 or ISO 27001 evidence often covers the analytics estate. Product event streams at very high volume alongside subscription, billing and support data that must be joined at account grain to be useful.

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.

Healthcare provision

Health data attracts the stricter GDPR special-category conditions, and small-number suppression must be enforced in measures including drill-through. Typical systems in scope: electronic patient record, patient administration system, theatre scheduling, LIMS and e-rostering.

Precision engineering and instruments

Calibration and measurement traceability records are audited under quality standards, and retention periods are long.

Who can see what, and how you prove it

This is the question that exposes an estate, and the fix is unglamorous. The difference is between an afternoon of investigation and a parameterised report. Individual grants accumulated over years require the first; groups that mirror your control model allow the second.

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 software and technology, the groups normally need granularity by function and by entity or site.

Classification, labels and the export problem

Most estates lose control of data at the export button. The intent is almost always benign, which is precisely why policy alone does not stop it. 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 the EU GDPR and the Bundesdatenschutzgesetz (BDSG) 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 German organisations: the practical constraints

• Specification discipline is higher than in the UK: expect a written Fachkonzept and a documented acceptance process, and plan for it rather than resisting it.
• Works council consultation should be scheduled at the start of a project, not discovered during user acceptance testing.
• Many Mittelstand clients prefer German-language documentation and stakeholder sessions even where the project team works in English.

The most underestimated factor in German governance projects is works council co-determination. Any reporting that could be used to assess individual employee performance generally needs a works agreement before launch, and discovering that during user acceptance testing is expensive. We schedule that consultation at the start.

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: defineNamed owners and stewards, a classification scheme, retention rules and access standards, all signed off by legal and by the business rather than written by the data team alone.
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 Konstanz organisation.

We work across Germany and deliver into neighbouring markets regularly. Nearby pages worth reading if your group has sites elsewhere: Freiburg im Breisgau, Göttingen, Leipzig, Bochum, Bielefeld and Potsdam.

Frequently asked questions