Chapter 14 — Privacy foundations
Lesson map
Lesson 14 published. Map, example, EX040.
flowchart TD
N0["Learning outcomes"]
N1["14.1 Minimisation"]
N2["14.2 Redaction"]
N3["14.3 Purpose limitation"]
N4["14.4 Access"]
N5["14.5 Cross-border"]
N6["14.6 Breach risk"]
N7["14.7 Re-identification drills"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX040"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["14.1 Minimisation"]
N2["14.2 Redaction"]
N3["14.3 Purpose limitation"]
N4["14.4 Access"]
N5["14.5 Cross-border"]
N6["14.6 Breach risk"]
N7["14.7 Re-identification drills"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX040"]
[Learning outcomes]
|
v
[14.1 Minimisation]
|
v
[14.2 Redaction]
|
v
[14.3 Purpose limitation]
|
v
[14.4 Access]
|
v
[14.5 Cross-border]
|
v
[14.6 Breach risk]
|
v
[14.7 Re-identification drills]
|
v
[Worked example] --> [Exercise EX040]
Learning outcomes
You will (1) minimise customer data in evidence; (2) redact; (3) respect retention.
14.1 Minimisation
Proof beats bulk extracts of customer tables.
A tester needs to show that a weakness exists, not to collect what it exposes. If an API returns other customers' balances, one response containing a synthetic account's balance proves the flaw just as well as ten thousand real ones, and it creates no new copy of real customer data. Every extra record captured has to be stored, protected, reported and deleted, and it may itself become a reportable breach. Sam stops a test as soon as he has the first response that proves the issue. He records how many records the endpoint could have returned, rather than retrieving them to prove it.
14.2 Redaction
Mask account numbers; keep digits that prove the issue if needed.
Redaction should remove identity while keeping the proof. A screenshot showing that customer A's session displayed customer B's statement only needs the last four digits of each account number to show that the two differ. The full numbers add risk and no evidence. Names, addresses and balances are blacked out with solid boxes. Blur can sometimes be reversed and cropping can leave text in image metadata. Sam redacts on a copy, keeps the unredacted original in the vault under its retention date, and hashes both, so a reviewer can confirm the redacted image came from the original evidence.
14.3 Purpose limitation
Engagement evidence is not a marketing analytics source.
Customers' data reached the testing team for one reason, which was to check the bank's security under a signed agreement. Using the same screenshots to study how customers use the app, or to illustrate a sales deck, is a new purpose the customers never expected and the agreement never covered. Privacy law in many jurisdictions treats that change of purpose as needing its own legal basis. The practical rule at TRB is simple. Evidence answers questions about the engagement it came from, and any other question needs separate data that was collected for that purpose.
14.4 Access
Need-to-know on evidence vaults.
The evidence for one engagement is read by its testers, its reviewer and the custodian, and by nobody else by default. A developer fixing a finding sees the finding's description and the redacted proof, not the raw capture. A manager sees status and severity. Access requests outside those roles go to the engagement lead with a reason and an end date. Need-to-know also limits damage. If one tester's account is compromised, the attacker reaches one engagement's evidence, not every screenshot the team has taken in five years.
14.5 Cross-border
Cloud regions may implicate rules; legal advises.
Evidence stored in a cloud service sits in a particular region, and backups or support access may reach others. If the evidence contains personal data about customers in one country and the storage or the vendor's support staff are in another, data-transfer rules may apply, along with the bank's own commitments to its regulator. Testers are not expected to interpret those rules themselves. They are expected to notice when evidence is about to cross a boundary, for example uploading to a new tool or sharing with an overseas vendor, and to ask legal before doing it.
14.6 Breach risk
Evidence vaults are high-value targets; protect them.
A testing team's vault holds the bank's weaknesses, proof of how to reach them and samples of the data behind them, which together make an attacker's roadmap. The vault therefore gets controls at least as strong as the systems it describes: multi-factor authentication, logged access, encryption at rest, short retention and its own place in the incident plan. If the vault were compromised, the bank would have to treat every unfixed finding in it as potentially known to an attacker. That is why TRB prioritises fixes for weaknesses recorded in an exposed vault, whatever their original severity.
14.7 Re-identification drills
Re-identification drills pair a redacted screenshot with public org charts. If a peer can name the person, redaction fails the gate. Sam now prefers synthetic personas in most teaching screenshots.
The drill tests what a reader can work out, not just what was blacked out. A screenshot of an internal admin page might hide a name but leave a job title, a branch code and a timestamp, and together with a public organisation chart those identify one person. Peers get ten minutes and only public sources. A successful identification is not counted as a mistake by the redactor. It shows that the redaction rule missed a kind of field, and the rule is updated.
14.8 A library of synthetic evidence
A library of synthetic screenshots covers common findings so learners need not handle real customer pixels. Sam contributes one new synthetic each term.
Each entry recreates a typical finding on a mock-up of TRB's interfaces, such as a statement page showing the wrong customer, an error message leaking a stack trace or an admin panel reachable without login, using invented data throughout. Training, report templates and conference talks draw from the library instead of from engagement folders. Building an entry takes a few hours, and it permanently removes the temptation to redact a real screenshot for a slide.
14.9 Purpose tags on evidence
Evidence files tagged with purpose; secondary use requires a new tag and approval. Marketing cannot "just borrow" engagement screenshots.
The tag is set at upload. In most cases it is engagement evidence, and for a few files it is engagement evidence plus approved training use. FindingsDesk checks the tag whenever a file is copied to another workspace or attached to anything other than a finding, and blocks the action if the purposes do not match. Adding a purpose requires the engagement lead's approval and a privacy check. The tag turns a policy sentence into a check that runs every time a file moves.
14.10 Learners choose the synthetic example
Synthetic screenshot library item SS-17 shows a fake customer "Ada Example" with account ••••4242. Learners prefer it to redacting real screens. Sam measures that preference and funds more synthetic art.
The preference is practical as well as ethical. Redacting a real screenshot properly takes a learner twenty minutes and a reviewer's check, while the synthetic one is ready to use and carries no risk if it ends up in the wrong place. Sam tracks how often each library item is used. The most-used items show which findings learners write about most, and those are the next ones turned into synthetic versions.
14.11 A blocked copy to a design folder
Purpose tags blocked a well-meaning trainee from dropping engagement screenshots into a UX redesign folder. The refusal felt petty and protected a hundred customers.
The trainee's idea was reasonable on its face. The screenshots showed real confusing screens that the design team wanted to improve. They also showed real customers' names and partial balances, and the design folder was shared with an external agency. The fix took one afternoon. The trainee described each confusing screen in words and the design team rebuilt it with synthetic data. The agency got what it needed and no customer data left the bank.
14.12 Keeping synthetic personas obviously fake
Synthetic Ada Example has a style guide so artists keep her obviously fake.
A synthetic persona that looks too real causes the problems it was meant to prevent. Readers may assume it is a redacted real customer, or the details may accidentally match a real person. The style guide fixes the giveaways: names from an agreed invented list, account numbers ending in well-known test digits, addresses on streets that do not exist in TRB's region, and dates in a reserved test year. Anyone who sees those markers can recognise teaching material at a glance.
14.13 Agreements with illustrators
Artists sign a CLA that Ada Example may not resemble real customers. Legal insisted; Sam agreed happily.
Illustrators sometimes base faces and handwriting on people they know or on stock photographs of real people. In a bank's training material, a persona that resembles a real customer could imply that the customer's account was involved in a security finding. The contributor agreement makes the artist confirm that every likeness is invented, and gives TRB the rights to reuse and change the artwork. That second part matters as much as the first, because synthetic examples must be updated when the real interfaces change.
14.14 Desk visits for new analysts
Privacy coaches at TRB include a five-minute desk visit when a new analyst first opens the evidence vault. Sam scripts the visit: show retention dates, show access list, show one redaction fail example, ask the analyst to repeat the minimisation rule in their own words. Desk visits catch bravado better than LMS modules. Analysts sign a tiny card that stays in the vault foyer.
A rule learned from a document is easily forgotten. A rule shown at the desk on the analyst's own screen, with their own engagement's retention date, tends to stick. The redaction failure example is chosen to be uncomfortable: a screenshot that looked clean until a colleague named the person in it. Asking the analyst to restate the rule shows whether they understood it or just nodded along.
Worked example (synthetic TRB)
Sam redacts all but last four digits before attaching a screenshot to F4.
Synthetic case — Riverstone Transit Bank (TRB). The bank, Sam Ito, TrackScope/FindingsDesk/PulseMap and all figures are invented for teaching.
Errors and limits
This book grants no authority to test real banks or payment systems. Labs use documentation-range addresses and synthetic data only; exploit code is never provided.
Exercises
- EX040 — Minimisation. Why not export the full customer table for a finding? Rubric: 3 = privacy/purpose/ROE; 2 = partial; 1 = need it; 0 = none.
- EX041 — Redaction. What does Sam redact in the screenshot example? Rubric: 3 = account numbers except last four / personal identifiers; 2 = partial; 1 = vague; 0 = none.
- EX042 — Vault. Why protect evidence vaults strongly? Rubric: 3 = concentrated sensitive proof data; 2 = partial; 1 = no need; 0 = none.
Synthesis
Privacy is minimisation, redaction, purpose limits and vault hygiene.
Continue studying — chapter 14 of 40
← Chapter 13 (draft) · Course chapter index · Chapter 15 (draft) →