Security, privacy, and compliance as engineering responsibilities

Security, privacy and compliance are engineering responsibilities. Engineers build and operate the systems that hold customers' data, the code that exposes or protects it, and the means of meeting the obligations the organisation has taken on, and no security function can own what engineering does not. v1.0 left all three implicit inside quality and risk. v3.0 gives them a competency of their own because they involve their own judgment calls, such as triaging a scanner's four hundred findings, sizing a compliance request against a delivery quarter, or deciding what data may be sent to which tools, and because the ways they fail are distinct and expensive. The competency does not require being a security engineer. It requires treating a vulnerability, a privacy obligation or a compliance requirement as the team's own work, prioritised by risk instead of being deferred to a function or frozen in fear. It also means assigning ownership for gaps that span teams, weighing a mandate honestly against delivery and, at scope, owning all of this as organisational risk at executive level. It matters because getting it wrong costs customers' trust and has legal consequences. And the most common failure is diffusion, not negligence: everyone assumed another team owned it. The examinations test it through a team paralysed by a scanner, an engineer with unaudited production access, a "two-week" compliance request, a gap that spans four teams, and a mandate that requires re-architecting the organisation.

1. Engineering owns it. A security finding, privacy obligation or compliance requirement in a team's system is that team's work, prioritised alongside everything else. A security function advises, audits and supports. It cannot own what it does not build.
2. Triage by exploitability and exposure, not by count. Four hundred findings are not four hundred equal risks. Prioritise by what is reachable, what it exposes and how large the blast radius is, and where a class exists, fix the class.
3. Privacy and access are everyday decisions. Who can see production data, where copies of personal data live and what gets logged are all settled in ordinary engineering choices, long before they become incidents.
4. Assign an owner to a gap that spans teams, and fix the pattern. A finding that spans several teams with no owner needs a named one and a class-level fix. The fix goes into whatever produces the pattern, such as the pipeline, not into today's instances.
5. Weigh a mandate honestly against delivery. Separate what is mandatory from what is merely requested, size it against the quarter, and take the trade-off to the level that owns the priority. Refusing it is wrong, and so is absorbing it silently.
6. At scope, it is organisational risk owned at the executive table. Investment, accountability and exposure are stated in business terms. A mandate that requires re-architecting systems is led as a programme and sequenced by risk, whoever happens to be shouting loudest.

Security engineering has a large practitioner literature and a growing research one. The unit draws on both and grades each.

Threat modelling practice

Adam Shostack, Threat Modeling: Designing for Security (2014) gives this discipline its standard treatment. It asks four things of a system: what are we building, what can go wrong, what are we going to do about it, and did we do a good job? Its value to managers is that it makes security part of design instead of a scan at the end, and that a manager can ask its questions in a design review without being a security engineer. Its limit is that a threat model is a snapshot. Systems and threats move on, and a model nobody revisits describes a system that no longer exists.

Risk-based triage practice

Not a named model, but the practice this unit offers as the answer to the paralysed team. Findings are prioritised by exploitability (is the vulnerable path reachable?) and by exposure (what would it give an attacker, and how many people are affected?), and where several findings share a cause, the class is fixed. Its provenance is ordinary security practice. Its failure modes are the two the examinations present: freezing at the count, and ignoring it.

Privacy by design practice

Ann Cavoukian, Privacy by Design: The 7 Foundational Principles (2009) sets out the principles: privacy as the default, built into design instead of bolted on, with data minimised and its handling visible. For engineering managers the practical content lies in everyday decisions about what is collected, where it is copied, who can read it, what is logged and how deletion works across systems in practice. It also means recognising that when a deletion request finds personal data duplicated across four systems, two backups and an analytics warehouse, that is a design failure, made one decision at a time.

Security of AI-generated code research

Hammond Pearce, Baleegh Ahmad, Benjamin Tan, Brendan Dolan-Gavitt and Ramesh Karri, Asleep at the Keyboard? Assessing the Security of GitHub Copilot's Code Contributions (2022) found that generated code carries known classes of vulnerability at a substantial rate. For this unit, the consequence is that generated code is scanned and reviewed for those classes on the paths where they matter, and the data sent to AI tools is governed like any other data flow. Neither point argues against the tools. Both argue for treating them as part of the system's attack surface.

Compliance as a programme practice

Also not a named model. This is the executive-scope practice for a security or compliance mandate that touches many systems. It has ownership, sequencing by risk, explicit capacity, an honest roadmap impact and reporting, and it is led like the strategic effort it is. It fails when the mandate is squeezed invisibly into team slack, which is how mandates get missed and how the organisation learns it was never serious about them.

The finding triage

When a scanner or an audit produces a list, the team sorts it before acting. Is each finding reachable? What does it expose, and to whom? Do several findings share a cause? The result is a short list of classes to fix, in order of risk. Unreachable findings are recorded and deferred; they are neither fixed first nor ignored.

The access review

Every quarter, the team lists who can read or write production data and why. Standing write access without an audit trail is removed in the week it is found, without waiting for the next review. The problem was the grant, and the engineer who held it is not to blame.

Threat modelling in the design review

For any system that handles personal or financial data, the design review includes the four questions: what are we building, what can go wrong, what will we do about it, and did we do a good job? The manager asks them, the engineers answer them, and the answers are kept with the design.

The mandate sizing

When a compliance request arrives, the team sizes it honestly: what is mandatory, what is requested, and what it will take. The manager takes the result, with its impact on delivery and the options, to the level that owns the priority. The request is neither refused nor absorbed.

The cross-team owner

When a finding spans several teams, the manager of managers names an owner for the class. They fund a fix to the pattern itself (the shared library, the pipeline check, the template) and track it to completion in every team. Instances fixed one at a time grow back.

The exposure register

At executive scope, the organisation keeps a short register of its security, privacy and compliance exposure in business terms: what is most likely, what would cost most, and what has no owner. It is reviewed alongside the risks the executive tracks personally, and it is the basis of the investment case at the executive table.

At team scope the object is the team's own security practice and any vulnerability in its service. The manager treats that work as the team's, triages by risk, and catches privacy and access problems in everyday decisions. At organisational scope the object becomes a class of gap across several teams, where ownership is assigned and the pattern fixed. It also covers weighing a compliance requirement honestly against delivery and separating the mandatory from the requested. At executive scope, security, privacy and compliance are organisational risk owned at executive level. Investment and accountability are stated in business terms. A mandate that requires re-architecting systems is led as a programme sequenced by risk, and a serious vulnerability class across many services is prioritised as exposure, with explicit capacity, instead of being squeezed into slack. How Judgment Scales sets out the pattern; the incident structure a security incident follows is in DE-3 Reliability, incident response, and operational ownership.

• Treats a security finding, privacy obligation or compliance requirement in the team's system as the team's own work, prioritised by risk. team
• Triages a scanner's findings by exploitability and exposure and fixes the class, without either freezing or ignoring them. team
• Spots a privacy or access-control problem in an everyday decision, such as standing production access, personal data copied where it should not be, or sensitive values in logs. team
• Asks the threat-modelling questions in a design review without being a security engineer. team
• Governs generated code and the data sent to AI tools as part of the attack surface.
• Failure mode: deferring security to a function that does not build the system. team
• Failure mode: paralysis at the count. team
• Failure mode: ignoring the count. team
• Failure mode: discovering unaudited production access in an incident instead of a review. team
• Assigns a named owner and a class-level fix when the same gap appears across several teams. org
• Weighs a compliance requirement honestly against delivery, separating mandatory from requested and sizing it against the quarter, and takes the trade-off to the level that owns the priority. org
• Handles a privacy obligation that touches four teams' systems by establishing who owns each part before assuming another team does. org
• Puts security baselines into the standards floor at the boundaries, and leaves the tools inside teams to the teams. org
• Failure mode: patching a cross-team finding one instance at a time. org
• Failure mode: accepting "two weeks" from legal for a quarter's work, or refusing the mandate. org
• Failure mode: every team assuming another owns the obligation. org
• Owns security, privacy and compliance as organisational risk at executive level, stating investment, accountability and exposure in business terms. exec
• Leads a mandate that requires re-architecting systems across the organisation as a programme, with ownership, sequencing by risk, capacity and reporting. exec
• Prioritises a serious vulnerability class across many services as business exposure, with explicit capacity and an honest roadmap impact. exec
• Keeps security posture on the short list of risks tracked personally. exec
• Failure mode: treating security capacity as something teams find down the back of the sofa. exec
• Failure mode: a mandate squeezed invisibly into team slack until it is missed. exec
• Failure mode: learning the organisation's exposure from the breach. exec

Risk versus delivery. Every hour spent on a finding is an hour not spent on features, and every finding left open is exposure. Triage by exploitability and exposure turns the trade-off into a decision, where otherwise it would be a reflex in one direction or the other.

Ownership versus expertise. Engineering owns security without having a security engineer's depth. The security function advises, audits and builds the shared tooling, and the team owns the work in its own system. Either side can fail: the team that defers everything, or the function that owns nothing it can change.

Access versus friction. Engineers need production access to operate their systems, and standing access is the most common privacy failure. The judgment lies in access that is scoped, audited and time-bounded, inconvenient enough that using it is deliberate and available enough that nobody works around it.

Mandate versus quarter. A compliance requirement is often non-negotiable in substance and negotiable in scope and timing. Sizing it honestly and separating the mandatory from the requested is what lets the manager avoid both refusing it and absorbing it.

Programme versus slack. It is tempting to spread a mandate that touches every system as a small tax on every team, and that is how it gets missed. Leading it as a programme costs visible capacity, and it is the only version that finishes.

A senior manager with five teams receives the results of an external security audit. One class of gap appears in eleven services across four of the five teams: services that accept unvalidated input on internal interfaces, on the assumption that internal callers can be trusted. The audit lists these as eleven separate findings. When asked, each team says the pattern came from a shared service template written three years ago by a team that no longer exists, and each assumes that fixing the template is someone else's job. The security function has filed the findings and asked for remediation dates.

The two easy answers both fail. Asking each team to fix its own findings fixes eleven instances and leaves the template free to produce a twelfth. Escalating the whole thing to the security function hands it to a group that owns none of the services and cannot change them.

The senior manager treats it as a class with no owner. They name one, the platform team lead, who has the closest claim to the template and to the shared library it produces. They then fund a fix to the pattern. It has three parts: an input-validation layer in the shared library, a pipeline check that fails any service without it, and a migration of the eleven services in order of exposure, starting with the two internet-adjacent ones. The ordering is triage. A finding in the service that handles payment callbacks is not the same risk as one in an internal reporting job, and the audit's list did not make that distinction.

The four affected teams keep their own instances in the migration plan, with dates. The dates follow the shared fix, because a team that patches its instance by hand this week has done work the library will redo. The security function receives the plan and a reporting cadence, and is asked for the one thing it can do that the teams cannot: a targeted re-test of the two highest-exposure services when the migration lands.

The senior manager also asks the question the audit raised and left unanswered. What else did that template produce, and where else does the organisation assume that internal callers can be trusted? The answer becomes the next item on the exposure register.

The senior manager does not treat eleven findings as eleven tasks, and does not treat security as the security function's problem. Either would be how the twelfth finding arrives.

• TJ-2 Technical debt: security exposure as a sibling of technical debt, prioritised the same way.
• TJ-3 Code review and quality standards: the security baseline in the standards floor, and generated code checked as a class.
• TJ-5 AI-assisted engineering: data sent to AI tools, and the vulnerability profile of generated code.
• DE-3 Reliability, incident response, and operational ownership: the incident structure a security incident follows (restore, communicate, diagnose).
• DE-1 Prioritisation under constraint: where a mandate goes in the queue, and the cost of saying yes.
• CC-5 Values, integrity, and ethical judgment under pressure: making the costly right call when a compliance requirement is inconvenient.

1. A scanner reports four hundred dependency vulnerabilities and the team is paralysed. What is the right move?
   Answer

   Triage by exploitability and exposure: which vulnerable paths are reachable, what they expose and to whom, and which findings share a cause. Fix the classes in order of risk, and record and defer the unreachable ones. Do not freeze at the count, and do not ignore it.
2. An engineer has had unaudited write access to production data for months. What is the problem?
   Answer

   The grant, and not the engineer. Standing, unaudited access is removed in the week it is found and replaced with access that is scoped, audited and time-bounded. The quarterly access review is what should have caught it.
3. What are the four threat-modelling questions a manager can ask in a design review?
   Answer

   What are we building? What can go wrong? What are we going to do about it? Did we do a good job? They make security part of design, and asking them does not take a security engineer.
4. A "two-week" compliance request arrives; legal calls it mandatory; your sizing says a quarter. What do you do? org
   Answer

   Size it honestly, separate what is mandatory from what is requested, and take the trade-off, with its delivery impact and options, to the level that owns the priority. Do not refuse it, and do not silently absorb it into the quarter.
5. A security audit finds the same class of gap across several teams and nobody owns the fix. What is the fix? org
   Answer

   A named owner for the class, and a fix to the pattern itself (the shared library, the pipeline check, the template), migrated in order of exposure and tracked across every team. Instances fixed one at a time grow back from the same source.
6. Why is a compliance mandate that touches every system led as a programme rather than distributed as a small tax on each team? exec
   Answer

   A mandate squeezed invisibly into team slack is how mandates get missed, and how the organisation learns it was never serious. A programme has ownership, sequencing by risk, explicit capacity and reporting, and it finishes.
7. What does an executive own about security that cannot be delegated to a function? exec
   Answer

   The organisation's exposure as business risk (investment, accountability, what is most likely and what would cost most), stated at the executive table and kept on the short list of risks the executive tracks personally. The function advises and audits, and the exposure stays with the executive.

• Adam Shostack, Threat Modeling: Designing for Security (2014): threat modelling as a design discipline, and the four questions.
• Ann Cavoukian, Privacy by Design: The 7 Foundational Principles (2009): privacy by design.
• Hammond Pearce, Baleegh Ahmad, Benjamin Tan, Brendan Dolan-Gavitt and Ramesh Karri, Asleep at the Keyboard? Assessing the Security of GitHub Copilot's Code Contributions (2022): the vulnerability profile of AI-generated code.