When would you run LINDDUN GO instead of a full per-element LINDDUN pass, and what do you give up?
answer
- Lightweight form, same seven types
- Cards carry the prompts, not the analyst
- Optimised for participation and cadence
- You lose a defensible coverage claim
- Portfolio call: broad versus deep
basics
~20 sLINDDUN GO is the lightweight card-based form: a deck of prompting cards worked against a rough system sketch with non-specialists. It trades the full method's exhaustive per-element coverage and its defensible record for speed and reach.
solid answer
~50 sUse LINDDUN GO when the constraint is attention rather than rigour: an early design where the data model is still moving, a team with no privacy specialist, or a recurring slot inside delivery that a per-element matrix would never survive. Each card carries one threat type with a prompting question and examples, so engineers, product and legal can all take part without learning the full method first. What you give up is coverage you can defend — GO produces whatever the cards prompted the room to see, with no record of which element and threat-type pairs were considered, so a miss looks exactly like an absence. Reserve the full per-element pass for high-risk processing whose data model is settled and where you need a documented, reviewable result. In practice most organisations run GO broadly and the full method on the few systems that carry the real exposure.
go deeper
Know that LINDDUN comes in a lightweight card-based form as well as the full method, and that both work from the same seven privacy threat types.
Be able to describe the mechanical difference: prompting cards against a rough sketch versus an exhaustive walk of every element against every applicable threat type.
Show you choose by constraint. Moving design, no specialist, or a recurring delivery slot points to the lightweight form; settled high-risk processing that must be defended later points to the full pass.
Own the portfolio argument: yield is coverage multiplied by frequency, so run the light form broadly and spend scarce specialist effort deep on the few systems carrying real exposure, while stating plainly what the light form does not evidence.
## What GO is LINDDUN GO is the lightweight variant of the method. Instead of building a detailed model and walking every element against every applicable threat type, you work from a rough sketch of the system with a deck of cards. Each card represents one threat type instance and carries a prompting question, typical examples, and hints about where it usually bites. The room works through the deck against the sketch and records what the prompts surface. The design goal is participation. The full method rewards someone who already knows the seven types and the element mapping; GO puts the knowledge on the cards, so a product manager, a legal reviewer and two engineers can reach useful findings in an hour without a privacy specialist facilitating from theory. ## When GO is the right call - **Early design.** The data model is still moving. A per-element pass against a design that will be different next week is effort spent on elements that will not exist. - **No specialist available.** GO is the difference between a rough pass happening and nothing happening. A rough pass that finds three real threats beats a rigorous one that is never scheduled. - **Recurring cadence.** A short session that fits inside a normal delivery rhythm gets repeated. A day-long matrix exercise gets deferred, then skipped, then dropped. - **Building shared vocabulary.** After a few sessions the team starts naming linkability and detectability unprompted in design reviews, which is worth more over a year than one thorough report. ## When only the full pass will do - **High-risk processing** where the consequence to individuals is severe and the design is settled enough to model properly. - **Anything you must be able to defend later** — a review, an internal assurance process, a decision you will be asked to justify. "We had a card session" is not a coverage claim; "we walked these eleven elements against the applicable threat types and here is why we dismissed each of these" is. - **Systems where the interesting threats are structural**, living in a specific store or a specific derived copy rather than in a category the deck would prompt for generically. ## A worked example of what GO catches An office runs desk-occupancy analytics by aggregating badge swipes and wifi association events into a presence feed. Security has already classified the dataset as non-sensitive: no names in the feed, no content, no customer data. A card session over the aggregation process gets somewhere the security classification did not, because the cards ask questions the classification never posed: - **Detectability** — can it be told that a particular badge was present on a given day at all? Presence on a date is the harm even with no other field. - **Linkability** — do the badge identifier and the device MAC join, and does the joined series persist across weeks into an attendance record? - **Unawareness** — do employees understand that a system introduced as desk-occupancy planning produces per-person attendance timelines? - **Non-compliance** — is the feed being used for the purpose it was announced for, or has it drifted into performance management? The adversary here is the employer operating the system, and the asset is employee personal data. That combination is exactly the one an aggregate, non-sensitive classification is blind to, and it is why the session is worth an hour even though nothing about the data looks confidential. ## The judgment to state in an interview The honest position is a portfolio one. Rigour is not free, and a method's real yield is coverage multiplied by how often it actually runs. GO maximises the second factor at a real cost to the first. So run GO broadly — every meaningful design, on a cadence, with the delivery team in the room — and spend the scarce specialist effort on a full per-element pass for the handful of systems where the exposure justifies it. Say out loud what GO does not give you, so that nobody later mistakes a card session for an assurance result. What both forms share is the seven threat types: GO does not add categories or change the taxonomy, it changes how you elicit against it.
- What exactly do you lose by only ever running LINDDUN GO?A coverage claim you can defend. The full pass leaves a record of which elements were crossed with which threat types and why each dismissal was made, so a gap is visible as an unfilled cell. GO leaves the findings the cards happened to prompt, with no map of what was never asked. That is acceptable for most systems and unacceptable for the few whose processing carries serious consequences for individuals.
- A team says a desk-occupancy dataset is non-sensitive, so no privacy pass is needed. Your response?Sensitivity of the stored field is not the test; the inference is. Badge and wifi presence events with no names still aggregate into per-person attendance timelines, which support conclusions about health, religious observance, union activity and performance. The adversary in that model is the employer operating the system, which is precisely the position a security-oriented data classification does not consider. That is an hour of card session well spent.
- Does LINDDUN GO change the threat taxonomy?No. It elicits against the same seven threat types; what changes is the elicitation mechanism, from an exhaustive element-by-threat-type walk to a set of prompting cards worked against a rough system sketch. Anyone claiming GO introduces extra categories or drops some of the seven has confused the lightweight delivery format with a different method.
A checklist a whole crew can run before every flight, versus a full teardown inspection. The checklist catches more in a year because it actually happens every time; the teardown is what you do for the airframe that carries the real risk.
saying these in an interview costs you the question
- Says GO adds or removes threat types
- Treats a card session as audit-grade coverage
- Claims lightweight modelling is always inferior
- Runs the full pass on every service regardless of risk
- Judges rigour without accounting for how often it runs
- Accepts a non-sensitive label as reason to skip