In this section

Data Security Engineering in Practice: What the Work Actually Looks Like

Module 0

Nobody will ever ask you to deploy a sensitivity label. The work does not arrive in the shape of the product, and learning to hear what a request is actually asking is most of the skill.

Scenario

Four things land in your week. A client's procurement team sends a security questionnaire. HR mentions that a senior engineer resigned on Friday and his last day is in three weeks. Rachel forwards a report that a proposal appeared at a competitor. And the executive team has decided Copilot goes live next month. Every one of them is your job, none of them mentions Purview, and only one of them is urgent in the way it appears to be.

The questionnaire

A client sends forty questions and one of them matters: can you demonstrate that our data is identified and protected in your environment?

What it is really asking is whether you have evidence. Not whether you have controls, which anyone can claim, but whether you can produce something that shows the control existed, applied to their data specifically, and worked. That is a question about classification and about measurement, and it has a nasty property: it is asked in the present tense about the past. Whatever you build after the questionnaire arrives cannot answer it for last year.

The honest answers are usually one of three. You have the evidence, which is rare. You do not and you say so and describe what you are building, which is respectable and occasionally loses the contract. Or you write something that sounds like the first while being the second, which is what most organizations do and is the reason procurement teams have stopped believing questionnaires.

There is a detail worth knowing before your first one. The questionnaire is rarely written by anybody who understands it. It is a template, assembled by a procurement team from a framework, and the person sending it cannot tell a strong answer from a fluent one. That sounds like an invitation to write fluently, and it is a trap, because the questionnaire is not the audit. It is the thing that gets attached to the contract, and the contract is what gets read in the year somebody sues.

Modules 2, 8 and 10. Classification is what makes their data identifiable as theirs. Retention is what makes the record survive long enough to produce. Audit is what turns "we think so" into a timeline.

The leaver

HR tells you somebody resigned. Most organizations respond by disabling an account on the last day, which is theatre: the interesting window opened weeks ago, on the day the person decided to leave and before anybody knew.

What this is really asking is whether you can tell the difference between a person doing their job unusually and a person taking their work with them. Those look identical in a log. An engineer who downloads forty documents in an afternoon is either preparing a handover or building a portfolio, and the only thing that separates them is context nobody has captured: the resignation date, the sequence, whether the material was ever theirs to have.

This is also where the discipline gets uncomfortable, because the control you are being asked to build watches employees. Doing it badly produces four hundred alerts a week and a culture problem. Doing it well requires a privacy posture, an agreement with HR and Legal about what is in scope, and thresholds somebody signed off.

The other thing nobody warns you about is that most leavers are not malicious, and the ones who are do not look different at first. An engineer who takes a folder of their own design work is usually not planning to harm anybody; they think of it as their portfolio, they have thought that at three previous employers, and nobody has ever told them otherwise. Your control has to work in a world where the most common case is ordinary and the rare case is indistinguishable from it for the first two weeks.

Module 9, and it is the module with the most non-technical content in the course for exactly that reason.

The incident

A proposal has surfaced somewhere it should not be. Rachel wants to know how.

What this is really asking is a forensic question about content rather than about an actor, and it is the request most likely to expose everything you did not do. Can you tell who had it? Can you tell who moved it, and when, and to where? Can you tell whether the copy at the competitor is your copy or one their new hire brought with them from a previous employer?

The answer depends almost entirely on decisions made months earlier. Audit retention that was never extended. Labels that were never applied, so there is nothing to trace. A classifier that never fired on the document in the first place, so no policy ever saw it move. You cannot investigate your way out of an instrumentation problem, and the day you find that out is the worst possible day to find it out.

Notice what the request assumes. Rachel says "how", and "how" presumes there is a chain of events to reconstruct. Half the time the honest finding is that the proposal left by a route so ordinary nobody logged it: forwarded to a personal address in 2023, or handed over on a USB stick by someone who has since left, or emailed to the client who emailed it onward. Not every disclosure has a villain, and an investigation that goes looking for one will find something, which is worse than finding nothing.

Module 10, and it is the module that most reliably makes people go back and re-read Module 8.

The AI rollout

The executive team wants Copilot next month, and somebody has asked you to confirm it is safe.

What this is really asking is whether your organization's oversharing is survivable now that finding things is easy. Copilot respects the permissions you already have. That sentence is meant to be reassuring and it is the entire problem: everything it can reach, somebody could always reach, and the only thing that ever protected you was that nobody could find it. An assistant that can answer "what do we pay our engineers" using a spreadsheet in a library nobody remembers sharing has not breached anything. It has performed a discovery exercise you never ran.

Which makes this the request that audits every decision in the first five phases of this course. It is not a new discipline and there is no separate Copilot security product. It is a searchlight.

The uncomfortable part is the timing. You will be asked to confirm it is safe, on a date already announced, by people who have bought it. Nobody is asking whether to do it. And the only true answer, if the first five phases were never done, is that you cannot tell, because the thing that determines the risk is whether your permissions and your labels reflect what your organization intended, and nobody has ever checked.

Module 11, and it is last in the course for the same reason it is last in reality.

Trade-off

Four requests, one week

All four landed. You have one week and no team. There is no right answer here, and the reason there is no right answer is the useful part: each one is urgent on a different clock, and only one of those clocks is visible to the person who set it. Pick what you work on, then read what it cost.

What gets your week?

Pick the one you would defend to Rachel.

The request nobody makes

There is a fifth item and it never arrives in your inbox, because there is nobody whose job it is to send it.

What data do we hold that would hurt us, and where is it? No client asks, because they only care about theirs. HR does not ask. The board does not ask, because they assume somebody knows. And it is the question that determines whether the other four are answerable, so somebody has to raise it, and that somebody is you.

That is an odd thing to say about a technical role, and it is the honest description of the job. The work that saves you is the work with no requester, no ticket, and no deadline, and it competes for your week against four things that have all three. That competition is not won by being right. It is won by being able to say, in a sentence somebody senior will act on, what the organization cannot currently answer and what it would cost to change that.

Which is why this course spends its longest module on classification and its most uncomfortable section on measuring one. Not because either is enjoyable. Because a number is the only argument that survives a room where everything else has a deadline attached.

The shape they share

When the request arrives, and when it was decided months ago last quarter the request lands You did the quiet work classified the estate extended audit retention labelled the proposals nobody thanked you You can answer it in an afternoon, with evidence, and it looks like luck Or you cannot and no amount of this week fixes it Or you did not there was nothing to show for it

Every request in this job is answered by a decision taken long before it arrived, which is why the work that gets funded is never the work that saves you.

All four requests share a structure: the question arrives now and the answer was determined earlier. That is uncomfortable because it means the work that matters is the work nobody is asking for, in a quarter when nothing has happened, against a risk that is theoretical until it is not.

It is also why the discipline is worth learning properly rather than reactively. The engineer who can answer the questionnaire is not smarter than the one who cannot. They are the one who classified the estate eighteen months ago while somebody senior was asking why it was taking so long, and who wrote down what it did not cover while everybody else was celebrating that it was finished. That is the whole trick, and it is available to anybody willing to do unglamorous work in a quiet quarter.

Section 0.5 is the other half of that honesty: the things Purview cannot do, which you need to know before you promise any of the above.