In this section

What Data Security Engineering Is: The Job, Not the Product

Module 0

Job adverts describe this role as owning Purview. That is a description of a licence, not of a job, and it is the reason people arrive in the role expecting to configure something and discover they have been handed an argument.

Scenario

Rachel forwards you an email from a client's procurement lead. It asks, in one sentence, whether Northgate can confirm that its contract data has never left the organization unprotected. There is no framework attached, no control reference, no questionnaire. Just the question. You have a tenant with E5 on it and nobody has ever tried to answer this.

The question underneath every request

That email is the job in miniature, and the first thing to notice is that it is not a technical question. It is a question about evidence, and it has three parts hiding inside it: what counts as contract data, where does it live, and what would we be able to say if it had left.

None of those are answered by a product. The first is a business definition that somebody in Legal has to make. The second is an inventory nobody has. The third is a claim you have to be able to defend, which means it needs a record that existed before the question was asked.

Data security engineering is the discipline of turning questions like that into controls that can answer them, and then proving the controls work. That is the whole job. Everything else, every portal, every policy, every classifier in this course, is instrumentation for that sentence.

What you actually do all day

Strip the product away and the work has four repeating shapes.

You establish what the organization holds. Not in the abstract. Specifically, with a number: 4,127 client contracts, of which roughly half predate the numbering scheme. This is the part people skip, because it produces no deployable artifact and it is where all the arguments are.

You make the data recognizable to a machine. Somebody has to teach a system that a document is a contract, and the system has no idea what a contract is. It has patterns, tables, forms and examples. Choosing between those is an engineering decision with a cost, and getting it wrong is not one broken control.

You decide what happens when it moves. Blocking is one answer. Warning is another. Recording it and doing nothing is a third, and it is sometimes correct. Every one of those is a trade between the risk and the friction, and the friction is paid by people who did not ask for it.

And you prove it works. This is the part that separates the discipline from an implementation project, and it is why the course refuses to move past classification until you can measure one. A control you cannot measure is a belief.

Two of the four decisions are not yours, and step four is the one nobody will ever chase you for.

The deliverables are not what you would expect

Ask an engineer what they produced last quarter and in most disciplines the answer is a thing that runs. Here the durable artifacts are mostly sentences.

The scope definition is a sentence Legal wrote saying what counts as a contract, precise enough to sort the documents in the middle. Without it, nothing downstream can be measured, because you cannot count errors against a category nobody has defined.

The coverage statement is the list of what your programme does not cover, written down, signed by the people who agreed to it. It is the deliverable nobody wants and the one an auditor finds first if you did not write it.

The false-positive rate is a number with a described sample behind it. Not "the classifier is pretty good". A rate, with a method, that somebody can repeat.

And then, yes, the configuration: classifiers, labels, policies, retention. Those are real and this course builds all of them. But they are the easy half, and they inherit their worth from the three sentences above.

Who you cannot do this without

Identity security has a satisfying property: you can mostly do it yourself. The subject is a user, the authority is yours, and the argument is with a product rather than a person.

This job does not work that way, and the sooner that lands the better. You do not own the definitions. Legal owns what a contract is. HR owns what a leaver looks like. The business owns which client would sue. You can build any control you like and you cannot decide what it is for, and a control built on your guess at somebody else's definition is a control that will be wrong in a way nobody notices until it matters.

Which changes what good looks like. A strong data security engineer is not the one who knows the most about the portal. It is the one who can get Legal into a room, ask the question that produces a decision rather than a discussion, write down what was decided, and then build to it. The portal work is downstream of that and it is the part that can be looked up.

Which is why the reasonable first move is the wrong one. You have been handed Purview and a mandate, so you open the portal and start with the thing that looks most like progress: a policy. It produces something visible in an afternoon and it is how most deployments begin. But every screen in that portal asks a question only the business can answer, and answering it yourself is the fastest route to a programme that enforces your assumptions about somebody else's risk. The teams still running their deployment in year three started with the argument rather than the product.

Trade-off

The first move

Rachel Okafor, CISO

"The client wants confirmation that their contract data has never left us unprotected. I would like to be able to say something true. What are you doing about it this week?"

This is the first decision of the job and there is no right answer, which is the point. All four are defensible, all four are what somebody actually does, and each one charges you something. Pick the one you would take back to Rachel, then read what you bought. This is how every module in this course works.

What do you do first?

Pick the one you would defend.

What each one costs

A is the one most people pick, and it is the trap this section is about. It feels like progress because it produces something visible by Friday, and Rachel can see it. What you have actually done is answer Elena's question yourself: you decided what a contract is by choosing what to match. If she later rules that a reference quoted inside a proposal counts, your classifier is wrong and every control you scope to it inherits that. Worse, A defunds B: once there is a working thing on the screen, nobody funds the argument that should have come first.

B is correct and it is not free. Elena will ask why you want it, and if you arrive without an answer you will get a reasonable no. It also produces nothing you can show anyone, which is a real cost when a CISO is waiting. But it is the only step here that makes every later step measurable, because a false-positive rate is arithmetic over a definition and there is no definition yet.

C is cheaper than it looks and better than its reputation. A pretrained classifier pointed at the estate costs an afternoon and returns a number, and every decision after this changes shape depending on whether the answer is four hundred documents or forty thousand. The catch is that a number without a definition is exactly the 4,318 that opens Module 2: it tells you the size of something you have not yet agreed on.

D is the hardest to say and it is not the coward's answer. Telling a CISO the question is not answerable yet costs you standing in the moment and buys you the right to answer it properly. It only works if the second half is present: what you need, from whom, by when. Without that it is just a no.

What actually happens on a good week. D and B are the same conversation, and C runs alongside them because it costs nothing and arms them both. A comes last, when it can be built against something. If that ordering feels obvious now, notice that A is still what most organizations do, and they are not staffed by fools. They are staffed by people who were asked a question on Monday and wanted to have moved by Friday.

The three jobs this gets confused with

Because the discipline is young and the title is new, you will be mistaken for three other roles, and each mistake costs you something specific.

You are not GRC. GRC asks whether a control exists and whether there is evidence of it. You build the control and produce the evidence. The distinction matters on the day somebody proposes a policy that satisfies a framework and protects nothing, which happens more often than anyone admits: a rule scoped so narrowly it can never fire is a green row on a compliance sheet and a lie in the estate. Elena is on your side. Her job is not your job.

You are not privacy. Privacy asks whether you should hold the data at all, for how long, and on what lawful basis. That question sits upstream of yours and it is a better question, but it is not the one you are paid to answer. Where the two meet is retention, and the meeting is not always friendly, because a privacy officer wants less data and an investigator wants more.

And you are not the SOC. The SOC responds to an alert about an actor. You respond to a question about content. The overlap is real and it arrives in Module 10, when a case needs both, and the friction is usually that the SOC wants to know who while you can only tell them what.

Be clear about this early, because all three will offer you their framing and the framings are load-bearing. Take GRC's and you build for the audit. Take privacy's and you argue about whether the data should exist while it walks out of the building. Take the SOC's and you go hunting an attacker in an incident that was a well-meaning employee and a shared link.

It is not identity security with different portals

The comparison is worth making explicitly, because most people arrive here from identity or endpoint and the transfer is worse than it looks.

Identity security has a subject: a user, a session, a token. It exists at a moment, it can be revoked, and when your control fires the user knows immediately because they cannot sign in. Endpoint security has an object: a device you enrolled, running your agent, which you can isolate. Both have something to hold on to, and both tell you when they break.

Data has neither. It has no session to revoke and no agent to install. It is copied rather than accessed, so a single item becomes forty across mail, chat, a laptop and a supplier's inbox, and every copy is now a separate object with its own fate. It leaves through channels that all look exactly like work, because they are work. And the thing you are protecting is a property of the content rather than of the container it happens to be sitting in this morning.

The consequence is the one this course is built around: when data security fails, nothing tells you. A firewall rule that is wrong breaks something and somebody rings you within the hour. A classifier that is wrong produces a clean dashboard, a healthy-looking programme, and a number that leadership repeats in a board pack. It stays wrong for as long as nobody measures it, which in most organizations is permanently.

That property is why this course spends its largest module on classification and its most uncomfortable section on measuring one. Not because classification is interesting. Because it is the only place the silence can be broken.

Section 0.2 gets you oriented in the product itself, which has been renamed three times and hides several of its most important controls behind names that describe what Microsoft sells rather than what you do.

← Previous Next →

Reading width