A payroll bureau's own staff can read your employee records - where does the trust boundary go?
answer
- granted access, not corporate ownership
- external on a DFD does not mean untrusted
- insider who never has to escalate
- disclosure and tampering dominate here
- minimise, segregate, demand attribution
basics
~20 sDraw the boundary around granted access, not around the company. Bureau operators who can read every payroll record sit inside the zone that handles employee data, so operator misuse is an in-scope threat your model has to name.
solid answer
~50 sThe instinct is to put the line at the company edge and treat the bureau as an external entity, which quietly makes its staff outsiders. Granted privilege, not corporate ownership, decides the placement: a bureau operator holding read access to every employee record for 400 employers is inside the data-handling zone exactly as your own payroll clerk is, and belongs on the diagram as a principal inside it. Two things follow. First, the threat you must enumerate is an insider with legitimate access - information disclosure over records they had no business need for, tampering with bank details before a payment run, and repudiation if their actions are not individually attributable. Spoofing and elevation of privilege matter less here, because they do not need to escalate anything. Second, you cannot deploy preventive controls inside another company, so the mitigations shift to what you can influence: send fewer fields, require per-employer segregation, and require per-operator logs you are entitled to receive.
go deeper
Remember that a supplier's staff who hold access to your data are inside your trust boundary. Being a different company does not make someone untrusted or out of scope on the diagram.
Explain why granted access, not employment or legal entity, decides placement, and name the threats it exposes: disclosure by an operator with no business need, tampering with payment details, and unattributable actions.
Show the asymmetry in practice: you cannot deploy controls inside another company, so argue the mitigations you actually own - minimising the fields sent, requiring segregation, and buying per-operator attribution you can obtain as evidence.
Own the position that accountability does not move with the work. Decide how your organisation assigns an internal owner to every threat sitting inside a processor, and what you do when that owner has no lever.
## The wrong line and the right one A small employer outsources payroll to a bureau that also serves 399 other employers. The obvious diagram puts a trust boundary at the edge of the employer's own systems: inside is the HR application, outside is the bureau, drawn as an external entity, with a flow of employee records leaving. That diagram is not wrong so much as it is *misleading about people*. It implies the bureau's staff are outside the zone where employee data is trusted - and they are not. A bureau operator opens a record, reads a home address and a salary, edits a bank account, releases a payment run. Functionally that operator holds the same privilege as an internal payroll clerk. The boundary test is **where does trust or privilege change**, and it did not change between your clerk and their operator; both were granted the same access to the same data. So the honest placement is: the boundary sits where the *data leaves your control*, and the bureau's operators sit **inside** the zone that handles employee data, drawn explicitly as a principal there rather than hidden inside an anonymous external box. The word *external* on a DFD means external to the system, not untrusted - conflating the two is what buries the insider threat. ## What the placement makes visible Once operators are drawn inside the data zone, the enumeration writes itself, and it is dominated by threats that assume access rather than seek it: - **Information disclosure** (confidentiality) is first. Any of the bureau's operators can read records for employers they are not working on today. The relevant question is not *can they break in* but *what limits which records an operator may open*. - **Tampering** (integrity) is second and is where the money is: changing a payee bank account shortly before a run. - **Repudiation** (non-repudiation) is the one teams skip. If operators share a login, or if their actions land in your system as a single bureau service account, no action can be attributed to a person, and neither party can reconstruct what happened. - **Spoofing** and **elevation of privilege** are comparatively minor. An adversary who was *granted* the privilege has no need to impersonate anyone or escalate. - **Denial of service** exists in the mundane form of a missed payroll run, and is worth one line rather than a paragraph. Contrast that with a perimeter-shaped model, which spends its effort on the transport of the file and the authentication of the upload - both real, both far less likely to be where the loss comes from. ## The employment-status trap Ask the same question of a contractor sitting at a desk in your own office with identical access. Nothing changes. Employment status, badge colour, legal entity and even country are not inputs to boundary placement; **granted access is the only input**. The difference between the two cases is not where the line goes, it is *which controls you can actually apply*. For your contractor you can enforce technical controls directly. For the bureau you cannot deploy anything inside their walls. That asymmetry is what makes this a senior question. The mitigation set for an insider you do not employ is a different shape: - **Reduce what crosses.** The strongest control you fully own is sending fewer fields and fewer records. A field never transferred cannot be disclosed by anyone on the far side. - **Require structural separation.** Ask for per-employer segregation of records and operator scoping, so an operator's reach is bounded by assignment rather than by the whole book of business. - **Buy attribution.** Insist that actions on your data are attributable to a named operator and that you can obtain that trail. Non-repudiation is one of the few properties you can demand contractually and later verify from evidence, and it is the direct counter to the repudiation threat above. - **Keep the decision points you can.** For instance, a change of employee bank details confirmed on your side rather than accepted from theirs turns their tampering threat into something your own process can catch. ## Aggregation changes the picture One more move an interviewer will push on: the bureau holds the same data for 400 employers. That concentration is a property of *their* environment, not yours, but it belongs in your model because it changes the likelihood side of the risk: their store is a far more attractive target than your own HR database, and cross-employer leakage is a threat class that no control of yours touches. Draw the co-tenancy inside the processor, name the threat, and be explicit that your mitigation is limited to minimisation, segregation requirements and evidence - not to anything you can deploy. ## Responsibility, not accountability Outsourcing the processing does not outsource being answerable for the employees' data. The employer remains the party those employees will hold responsible. So every threat that lands inside the bureau still needs a named owner on your side who tracks it - otherwise the model has a whole trusted zone with no one watching it.
- Does it change anything that the bureau also processes payroll for 399 other employers?Yes - draw co-tenancy inside the processor. The concentration makes their store a far more attractive target than your own HR system, and cross-employer leakage is a threat no control of yours can prevent. Your mitigations narrow to data minimisation, a requirement for per-employer segregation, and evidence that the segregation exists.
- Your own contractor has the same access from a desk in your office. Is the boundary different?No. Granted access is the only input to placement, so both sit inside the data-handling zone and both are insiders in the model. The only difference is which controls you can apply: technical enforcement for your contractor, and minimisation, contractual requirements and evidence for the bureau's staff.
- Which threat categories dominate for an operator who already holds legitimate read access?Information disclosure first, since they can open records with no business need. Then tampering - altering bank details before a payment run - and repudiation, if actions arrive as a shared service account and cannot be pinned to a person. Spoofing and elevation of privilege are minor, because someone granted the privilege has nothing to escalate.
- What is the single most effective mitigation you fully control here?Reducing what crosses the boundary at all - fewer fields, fewer records, shorter retention on their side. It is the only control that needs no cooperation from the other organisation, and a field you never send cannot be disclosed, altered or aggregated by anyone over there.
A locksmith who holds a copy of your key is inside your security model whether or not he is on your payroll. The lock does not distinguish employees from suppliers; it distinguishes who holds a key.
saying these in an interview costs you the question
- Places the trust boundary at the company edge by default
- Treats external entity on a DFD as meaning untrusted
- Skips the insider threat because the vendor signed a contract
- Focuses on file transport while ignoring operator access
- Believes outsourcing the processing outsources accountability