Microsoft Purview Data Ownership: Who Owns It When You Have No CISO or DPO?

Microsoft Purview Data Ownership Quick answers

• Is data protection IT’s job or the business’s? Neither alone, IT owns the tooling and enforcement; the business owns the judgment on what’s actually sensitive.
• Who decides what’s Confidential vs Internal? Departmental champions who understand their own data, not IT guessing on their behalf.
• How do you find where your sensitive data lives? Export your SharePoint site and library list, then review it with each department directly, don’t ask abstractly.
• How do you get other departments to care? Ask concrete, scenario-based questions (“who’d be pulled into the room tomorrow if something went wrong?”) instead of abstract ones about “data protection.”
• How strict should sensitivity labels and DLP be? Start lenient, let champions tell you where controls are too tight per department, then tighten gradually.
• Do you actually need a Data Protection Officer? Usually not, GDPR only requires one for large-scale monitoring or special-category data processing, regardless of headcount. Germany is the exception (20+ staff processing data). Either way, you still need real ownership.

Who owns data protection in an SMB?

If you’ve searched for anything like “who owns data protection when you don’t have a CISO,” you’ve probably found a lot of enterprise advice that assumes you have a governance team, a DPO, and a budget to match.

Most of it isn’t written for a small business where “IT” means you and maybe one other person.

TL;DR: before we get into the detail: you don’t need to hire a CISO to fix this, and it isn’t purely IT’s job either.

Ownership needs to be split. IT owns the Purview tooling, the policies, the enforcement, the technical rollout. But deciding what actually counts as sensitive, in each part of the business, isn’t something IT can answer alone. That has to come from the people who use the data day to day.

We call this the departmental champions model, and it’s the same approach we use on every Purview engagement with SMBs who don’t have a dedicated compliance function. The rest of this post walks through exactly how it works, and where most rollouts go wrong without it.

Is data protection IT’s job or the business’s job?

Neither, entirely. That’s usually where the confusion starts.

It’s a fair question to ask, because in most SMBs, IT is the team that gets handed the Purview licence and told to “sort out data protection.” So it looks like an IT project. It gets budgeted like one, staffed like one, and when it stalls six months later, it gets blamed on IT for “not finishing it.”

1. But think about what data protection actually requires.
2. Someone has to decide whether a spreadsheet of supplier pricing is sensitive.
3. Someone has to know whether HR’s exit interview notes need tighter handling than the general staff directory. Someone has to understand why Sales treats a signed contract differently to a draft proposal.

This is a business decision and IT usually isn’t close enough to any single department to make it accurately.

IT owns the mechanism, the business owns the judgment. IT configures the labels, sets up the policies, and makes sure the controls actually work. But what gets labelled sensitive, and how strictly it should be handled, has to come from the people who deal with that data every day, not from IT guessing on their behalf.

This is why Purview projects that stay purely “IT’s problem” tend to stall, because nobody outside IT ever gets asked what actually matters to protect.

Fix that split early, and everything else, buy-in, sensible controls, actual adoption, gets a lot easier.

Who decides Data is Confidential vs Internal?

You might be thinking “If IT doesn’t own that decision, who does?”

This is where most Purview conversations get stuck, because the honest answer is: it depends on who you ask, and that’s exactly the problem.

For example:

• Ask Finance, and “Confidential” means anything with a number attached to it.
• Ask Sales, and it means client contracts, not much else.
• Ask HR, and almost everything they touch feels sensitive by default.

That’s why a single, centrally-decided classification scheme rarely survives contact with real departments. It either gets built too loosely (and misses things that genuinely matter to one team) or too strictly (and buries everyone in labels they don’t understand or trust).

A “better” classification policy written by IT is not the answer. It’s putting the decision closer to the people who actually understand the data, what we call departmental champions.

Rather than IT deciding what’s Confidential across the whole business, each department gets someone who understands their own data well enough to make that call for their team, and to flag what genuinely needs protecting versus what doesn’t.

We’ll get into exactly how to pick a champion and get useful answers out of them shortly.

For now our TL;DR is: classification is a judgment call, and it needs to sit with whoever’s judgment is actually relevant to that data.

IT can build the mechanism. It can’t make the call for every department at once.

If you show someone in Finance a library literally named “2024 Supplier Contracts”, they’ll immediately tell you what’s in it and how sensitive it is.

Ask them abstractly what data they handle, and you’ll get “invoices and stuff, I think”, technically true, practically useless.

A quick example of what this looks like in practice: you export the SharePoint list, send Sales their three relevant sites, and ask them to flag anything sensitive. They come back and tell you the “Signed Agreements” library needs tight controls, but the “Marketing Assets” library next to it doesn’t need anything beyond default access.

That’s a usable, specific answer, and it came from a five-minute look at real site names, not a cold question about “data.”

This is also why data mapping should happen before you finalise your label taxonomy, not after. You want your labels built around what people actually told you they have, not a guess at what a “typical” business might hold. Once you’ve mapped the data this way, classifying it becomes a much smaller step, you’re refining real answers, not starting from a blank page.

How do you get other departments to actually care?

Most departments don’t ignore Purview projects because they don’t care about data protection. They ignore them because nobody’s ever asked them a question that feels relevant to their day-to-day.

Ask a department head “do you support this data governance initiative?” and you’ll get a polite yes, followed by silence. It’s a fine question, but it doesn’t ask anything they can act on. We need to reframe how we ask questions to get the desired answer.

Reframe 1

Instead of “who owns data protection in your company?”, ask: “if a data protection issue happened tomorrow, who’d be pulled into the conversation first?”

Same underlying question, completely different answer.

The first version invites a shrug, because “data protection” as a title doesn’t map to anyone’s actual job. The second gets you real names, because everyone can picture the moment something goes wrong, and everyone knows, instinctively, who’d get the phone call.

Those names are your real stakeholders, whether or not their job title says so.

Reframe 2

Instead of “have you had any data incidents?”, ask: “has something sensitive ever gone to the wrong person by mistake, and if so, what happened next?”

This works because most departments have a near-miss story, even if it never got formally logged.

Once someone tells you that story, you’ve usually found an existing (if undocumented) process for handling incidents, and a very motivated stakeholder, because they remember exactly how stressful that afternoon was.

Reframe 3

Instead of “will this project be a priority for you?”, ask: “if an auditor asked you tomorrow to prove where your customer data is stored, could you answer confidently?”

This one tends to land hardest with department heads who’ve never thought about data protection as something with real business consequences.

It turns an abstract compliance exercise into a specific, slightly uncomfortable hypothetical, which is usually enough to shift “sure, whenever” into genuine urgency.

It’s important to phrase that these questions are not trick questions, they’re just closer to how people actually think, instead of how a compliance framework describes the same idea.

Ask the abstract version, and you’re relying on someone translating it into something relevant to them, which most people won’t bother doing in a five-minute conversation. Ask the concrete version, and you’ve done the translating for them.

This is the same principle your departmental champions should use later, when they’re figuring out what’s actually sensitive in their own team’s data. Getting buy-in and getting useful classification answers are, underneath it, the same skill.

Download Your Purview Engagement Questionnaire

If this is resonating with you and you don’t know where your sensitive data lives (and neither does most of your team), then download CloudGuard’s very own Purview Stakeholder Questionnaire and pre-engagement spreadsheet. These are the real questions we ask at the start of every Purview engagement, and the spreadsheet we use to capture the answer, covering governance, licensing, endpoint readiness, pilot planning and insider risk.

Nothing depends on memory, and nothing gets missed because a champion gave you a vague answer the first time round.

Sensitivity labels are annoying your users, how strict is too strict?

This is usually the point where a Purview rollout either sticks or quietly falls apart.

What goes wrong? Applying maximum-strictness controls across the entire business from day one.

It feels like the responsible choice, you’re protecting data, so why not protect it as tightly as possible? But most SMBs haven’t worked with sensitivity labels or DLP before, and dropping a fully-locked-down policy on a workforce that’s never seen one produces a predictable result: blocked emails that should have gone through, confused staff pinging IT constantly asking what label to use, and eventually, people quietly finding workarounds.

At that point, the control hasn’t made data safer. It’s just moved the risk somewhere you can’t see it.

Start lenient and ratchet up. Roll out labels and DLP policies in a more permissive mode first, enough to build habits and get people used to labelling things, without blocking legitimate work.

Let your departmental champions tell you, department by department, when a control is too loose or too tight for how their team actually operates. Sales might need looser rules around sharing signed contracts externally; Finance might need much tighter rules around anything with account numbers on it. There’s no single “right” strictness level across a whole business, that’s exactly why champions matter here, not just for classification.

Once people are used to the basic habit of labelling and a policy exists to observe (rather than block), you can tighten it gradually, department by department, as your user base gets more comfortable with the new way of working.

We’re not saying you need to be permanently lenient, sequencing is important. Security and usability aren’t opposites you’re forced to balance forever, they’re a curve you move along deliberately, starting where your users actually are, not where a compliance framework assumes they should be.

Do you actually need a Data Protection Officer?

This is the question that causes the most confusion, and whilst there are specific compliance criteria when managing certain data classifications and organisational responsibilities, the role does not have to be a full time or internal appointment (Quick note before we do: this is general information, not legal advice, if you’re genuinely unsure, it’s worth a conversation with a lawyer who knows your specific situation and jurisdiction.)

The headcount myth. A huge number of SMBs assume that once they hit a certain employee count, they’re legally required to appoint a DPO. That’s not actually how  GDPR works. Under Article 37(1), a Data Protection Officer is only mandatory if one of three specific things is true: your core activities are carried out by a public authority, your core activities involve regular and systematic monitoring of people on a large scale, or your core activities involve large-scale processing of special category data (health, biometric, criminal records, and similar).  

Notice that none of these relate to employee headcount. A 150-person company that doesn’t do any of those three things isn’t required to appoint a DPO under the GDPR, regardless of headcount. 

The exception worth knowing: Germany. Under Germany’s Bundesdatenschutzgesetz (BDSG), a DPO becomes mandatory once a business constantly employs at least 20 people dealing with automated processing of personal data, a threshold that was actually raised from 10 to 20 in a 2019 amendment.  

If you have any German entity or German-based staff, this is genuinely worth checking , because it’s a real legal requirement that catches a lot of SMBs off guard. Outside of Germany, this specific rule doesn’t apply, but always check your local implementation, since a handful of other EU states have their own variations. 

If you don’t legally need one, can you just skip data protection ownership?

No, and this is really the point of this whole post. Not requiring a DPO is very different from data protection ownership in any organisation.  

That’s exactly what the departmental champions model is solving for: real ownership and real classification decisions, without needing a job title that doesn’t make commercial sense at your size. 

One more thing worth knowing, if you’re tempted to just name your IT manager as DPO on paper: the GDPR allows a DPO to hold other responsibilities, but only if those responsibilities don’t create a conflict of interest (Article 38(6)).  

Guidance from the Article 29 Working Party, the body of EU data protection regulators that existed before the GDPR’s current oversight structure, specifically calls out senior roles that shouldn’t double as DPO, and head of IT department is named directly as one of them.  

The logic makes sense once you think about it: a DPO is meant to oversee and challenge how data is processed, and the person configuring and running that processing isn ot independent.. 

Most SMBs without large-scale monitoring or special-category data processing genuinely don’t need to hire a DPO. But that’s a reason to build a real ownership model, like departmental champions, not a reason to leave the question unanswered. And if you do need one, don’t default to making it your IT manager’s second job; that’s the one option regulators have specifically flagged as a poor fit. 

What comes next

Getting ownership right, champions assigned, data mapped, controls tuned per department, is the foundation everything else sits on.

Once that’s in place, the next question is usually: what do you actually do with labels, DLP, and auto-labelling once the basics are working?

That’s exactly what we cover in Episode 3 of Purview Perfection: label taxonomies, DLP protection measures, and the risks of auto-labelling that catch a lot of SMBs out.

If you’re still working out what you’re actually licensed for before any of this, start with Episode 1, where we break down Purview functionality across M365 licence tiers.

And if you’d rather skip ahead, our Purview ASSESS service is built around exactly this discovery process or grab our free Stakeholder Question Guide and Pre-Engagement Questionnaire, the same tools we use on real engagements, to start mapping your own data today.

Why CloudGuard?

Purview deployments fail for predictable reasons, skipped steps, wrong sequencing, governance decisions made without the right business context. We’ve built our approach specifically to avoid those failure points.

• 25+ years in cybersecurity, 15+ specifically in the Microsoft security stack
• Microsoft Security Architect–level consultants, Microsoft Solutions Partner status for Security, Data & AI and Azure
• CREST CCRTS certified, NCSC-Assured Service Provider, ISO 9001, ISO 27001, Cyber Essentials Plus

We’ve built Purview roadmaps across housing, critical infrastructure, and utilities, including a review at Stonewater Housing that identified 93 million stale data items and directly informed their retention policy.

We’re not here to sell the most expensive licence. We’re here to help you pick the right one, even when that means telling you to wait six months before upgrading.