Security, privacy, and compliance as engineering responsibilities

Security, privacy and compliance are engineering responsibilities: the systems that hold customers' data, the code that exposes or protects it, and the obligations the organisation has taken on are built and operated by engineers, 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 because they have their own judgment calls — triaging a scanner's four hundred findings, sizing a compliance request against a delivery quarter, deciding what data may be sent to which tools — and because their failure modes are distinct and expensive. The competency is not being a security engineer. It is treating a vulnerability, a privacy obligation or a compliance requirement as the team's own work, prioritised by risk rather than deferred to a function or frozen in fear; assigning ownership for gaps that span teams; weighing a mandate honestly against delivery; and, at scope, owning these as organisational risk at the executive level. It matters because the cost of getting them wrong is paid in customers' trust and in law, and because the most common failure is not negligence but diffusion: everyone assumed another team owned it. The examinations test it through the paralysed team and the scanner, the engineer with unaudited production access, the "two-week" compliance request, the gap that spans four teams, and the mandate that requires re-architecting the organisation.

1. Engineering owns it. A security finding, a privacy obligation or a compliance requirement in a team's system is the 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 what the blast radius is; fix the class where a class exists.
3. Privacy and access are everyday decisions. Who can see production data, where copies of personal data live, what is logged — these are decided in ordinary engineering choices before they are incidents.
4. Assign an owner to a gap that spans teams, and fix the pattern. A finding across several teams with no owner needs a named one and a class-level fix — the pipeline that produces the pattern, not today's instances.
5. Weigh a mandate honestly against delivery. Distinguish what is mandatory from what is merely requested; size it against the quarter; take the trade-off to the level that owns the priority. Neither "no" nor silent absorption.
6. At scope, it is organisational risk owned at the executive table. Investment, accountability and exposure stated in business terms; a mandate that requires re-architecting systems led as a programme, sequenced by risk rather than by who shouts.

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

Threat modelling practice

The discipline, given its standard treatment in Adam Shostack, Threat Modeling: Designing for Security (2014), of asking 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. For managers its value is that it makes security a design activity rather than a scan at the end, and that its questions are ones a manager can ask in a design review without being a security engineer. Its limit is that a threat model is a snapshot; systems and threats move, 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 treats as the answer to the paralysed team: prioritise findings by exploitability — is the vulnerable path reachable — and exposure — what does it give an attacker, and to how many — and fix the class where several findings share a cause. 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

The principles set out in Ann Cavoukian, Privacy by Design: The 7 Foundational Principles (2009): privacy as the default, embedded in design rather than bolted on, with data minimised and its handling visible. For engineering managers the practical content is the everyday decisions — what is collected, where it is copied, who can read it, what is logged, how deletion actually works across systems — and the recognition that a deletion request that finds personal data duplicated across four systems, two backups and an analytics warehouse is a design failure that was made one decision at a time.

Security of AI-generated code research

The finding in 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) that generated code carries known vulnerability classes at a substantial rate, and its consequence for this unit: 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 is an argument against the tools; both are arguments for treating them as part of the system's attack surface.

Compliance as a programme practice

Not a named model but the executive-scope practice for a security or compliance mandate that touches many systems: ownership, sequencing by risk, explicit capacity, honest roadmap impact and reporting, led like the strategic effort it is. Its failure is the mandate squeezed invisibly into team slack, which is how mandates are missed and how the organisation learns it was never serious.

The finding triage

When a scanner or an audit produces a list, the team sorts it before it acts: reachable or not, what it exposes and to whom, whether several findings share a cause. The output is a short list of classes to fix, ordered by risk, with the unreachable findings recorded and deferred rather than either fixed first or ignored.

The access review

Quarterly, the team lists who can read or write production data and why. Standing write access with no audit trail is removed the week it is found, not at the next review; the engineer who had it is not the problem, the grant was.

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, did we do a good job. The manager asks them; the engineers answer them; 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, what it will take — and the manager takes the result, with its delivery impact and 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, funds the fix to the pattern — the shared library, the pipeline check, the template — and tracks it to completion across every team. Instances fixed one at a time regrow.

The exposure register

At executive scope, a short register of the organisation's security, privacy and compliance exposure in business terms — what is most likely, what is most costly, what is unowned — reviewed with the risks the executive personally tracks, and the basis of the investment argument at the executive table.

At team scope the object is the team's own security practice and a vulnerability in its service, and the manager treats the 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 — ownership assigned, the pattern fixed — and the honest weighing of a compliance requirement against delivery, distinguishing the mandatory from the requested. At executive scope security, privacy and compliance are organisational risk owned at the executive level: investment and accountability stated in business terms, a mandate that requires re-architecting systems led as a programme sequenced by risk, and a serious vulnerability class across many services prioritised as exposure with explicit capacity rather than squeezed into slack. The pattern is in How Judgment Scales; the incident structure a security incident follows is DE-3 Reliability, incident response, and operational ownership.

• Treats a security finding, a privacy obligation or a 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, fixes the class, and neither freezes nor ignores. team
• Recognises a privacy or access-control problem — standing production access, personal data copied where it should not be, sensitive values logged — in an everyday decision. 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 rather than 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 — mandatory versus requested, sized 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 in the standards floor at the boundaries, and leaves the tools inside teams to the teams. org
• Failure mode — patching a cross-team finding instance by instance. org
• Failure mode — accepting "two weeks" from legal for a quarter of 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 the executive level — investment, accountability, exposure — in business terms. exec
• Leads a mandate that requires re-architecting systems across the organisation as a programme: ownership, sequencing by risk, capacity, reporting. exec
• Prioritises a serious vulnerability class across many services as business exposure, with explicit capacity and 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 in the cushions. 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 on a finding is an hour not on features, and every finding left is exposure. Triage by exploitability and exposure is what makes the trade-off a decision rather than a reflex in either direction.

Ownership versus expertise. Engineering owns security and does not have a security engineer's depth. The security function advises, audits and builds the shared tooling; the team owns the work in its own system. The failure is on either side: the team that defers everything, and the function that owns nothing it can change.

Access versus friction. Engineers need production access to operate systems, and standing access is the most common privacy failure. The judgment is in scoped, audited, time-bounded access that is inconvenient enough to be deliberate and available enough not to be circumvented.

Mandate versus quarter. A compliance requirement is often non-negotiable in substance and negotiable in scope and timing. Sizing it honestly and distinguishing the mandatory from the requested is what lets the manager neither refuse it nor absorb it.

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

A senior manager with five teams receives the results of an external security audit. The same class of gap — services accepting unvalidated input on internal interfaces, on the assumption that internal callers are trusted — appears in eleven services across four of the five teams. The audit lists them as eleven findings. Each team, asked, 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 are to ask each team to fix its own findings, which fixes eleven instances and leaves the template to produce the twelfth, or to escalate the whole thing to the security function, which does not own any of the services and cannot change them.

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

The four affected teams keep their own instances in the migration plan, with dates, but the dates follow the shared fix rather than preceding it; a team that patches its instance by hand this week has done work the library will redo. The security function is given the plan and a reporting cadence, and asked for 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 without answering: what else did that template produce, and where else is "internal callers are trusted" an assumption? The answer becomes the next item on the exposure register.

What the senior manager does not do is treat eleven findings as eleven tasks, or treat security as the security function's problem. Both are 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 yes.
• CC-5 Values, integrity, and ethical judgment under pressure — 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 risk order; record and defer the unreachable. Neither freeze at the count nor ignore it.
2. An engineer has had unaudited write access to production data for months. What is the problem?
   Answer

   The grant, not the engineer. Standing, unaudited access is removed the week it is found and replaced with scoped, audited, time-bounded access; the quarterly access review is what should have found 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 a design activity, and they do not require a security engineer to ask.
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, distinguish what is mandatory from what is requested, and take the trade-off — delivery impact and options — to the level that owns the priority. Neither refuse it nor absorb it into the quarter silently.
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 — the shared library, the pipeline check, the template — migrated in exposure order and tracked across every team. Instances fixed one at a time regrow 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

   Because a mandate squeezed invisibly into team slack is how mandates are 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 most costly — stated at the executive table and kept on the short list of risks tracked personally. The function advises and audits; the exposure is the executive's.

• Adam Shostack, Threat Modeling: Designing for Security (2014) — threat modelling as a design discipline; 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.