Privacy Design Checklist 1.2.4-1

Purpose

The article introduces the Privacy Decision Flow — the framework for determining when to hide, when to attest, and when to disclose personal information. This sidebar operationalizes that framework as a checklist: a sequence of structural questions that a system designer, institutional architect, or policy evaluator can apply to any system that collects, processes, stores, or transmits personal information.

The checklist is not a compliance exercise. It is a design discipline — a set of questions that must be answered before the system is built, not after a breach has occurred. Each question maps to a component of the privacy by design innovation. A system that cannot answer all of them affirmatively has not met the design standard.

Before Collection

Is this information necessary? The first question is whether the system needs this information at all. If the system's purpose can be accomplished without collecting the information, the information must not be collected. This is the minimization principle: do not acquire what you do not need. The burden of justification falls on the system, not on the person.

What is the specific, bounded purpose? If the information is necessary, the purpose must be stated in terms that are specific enough to test. "Improving the user experience" is not a purpose — it is a category broad enough to justify any collection. "Verifying that the person meets the eligibility threshold for this specific service" is a purpose. The specificity of the purpose determines the scope of the collection.

Can the purpose be accomplished through attestation rather than collection? If the system needs to verify a fact about a person — age, qualification, eligibility, membership — can a third-party attestation or a zero-knowledge proof accomplish the verification without the system collecting the underlying data? Attestation is the design preference. Collection is the fallback when attestation is structurally insufficient.

At Collection

Is consent informed, specific, and genuine? The person must understand what information is being collected, for what purpose, by whom, and under what conditions it may be shared. The consent must be specific to the purpose — not a blanket authorization. And the consent must be genuine — meaning the person has a meaningful alternative to consenting. If refusal means exclusion from conditions that are effectively mandatory, the consent is structurally coerced and fails this question.

Is the scope limited to what the purpose requires? The collection must not exceed the stated purpose. If the purpose is eligibility verification, the system collects eligibility data — not behavioral history, not location data, not communication patterns. Scope limitation is enforced architecturally (the system is designed so that excess data cannot be collected) rather than by policy (a document says the system will not collect excess data, but the architecture permits it).

Is the person informed about the threat model? The person should understand what risks the system's architecture protects against and what risks remain. This is not a liability disclaimer. It is the privacy analogue of informed consent in medical practice: the person should know what the system can and cannot protect.

During Processing and Storage

Is access compartmentalized? Only the functions that require the information have access to it. Access is restricted by architectural design, not by organizational policy. Compartmentalization means that a breach or failure in one function does not expose data held for a different function.

Is the data encrypted at rest and in transit? Encryption is a structural requirement, not an optional security enhancement. Data that is stored unencrypted or transmitted in cleartext is exposed to any actor who gains access to the storage or the channel — regardless of authorization.

Is custody clear? Who holds the encryption keys? If the system operator holds the keys, the person's privacy depends on the operator's integrity. If the person holds the keys, the person's privacy depends on their own key management. The custody arrangement must be explicit, and the person must understand who can access what under which conditions.

Is purpose-binding enforced architecturally? Data collected for one purpose must not flow to another purpose without meeting the full Privacy Decision Flow requirements — including fresh, specific consent. Purpose-binding must be enforced by the system's architecture (data is structurally inaccessible outside its designated purpose) rather than by policy alone.

At Disclosure

Does the disclosure satisfy all four conditions? Every disclosure must meet: necessity (the recipient's purpose cannot be accomplished without this specific information), proportionality (only the minimum required information is disclosed), informed consent (the person understands and authorizes this specific disclosure), and structural enforcement (the boundary conditions are maintained by architecture, not by the recipient's assurance of compliance).

Is the disclosure logged and auditable? The system must maintain a record of what was disclosed, to whom, when, and for what stated purpose. The person must be able to access this record. The audit log itself must be designed so that it does not create a new privacy vulnerability — it records the disclosure event without duplicating the disclosed data.

Is there a mechanism for revocation? Can the person revoke consent for future use of disclosed information? The revocation mechanism must be structurally effective — not a request that the recipient may or may not honor, but a design feature that terminates the recipient's access when consent is withdrawn.

Ongoing

Is there a review cadence? The system's privacy design must be periodically reassessed — not because the original design was flawed, but because the threat model changes, new re-identification techniques emerge, and the purposes for which data was collected may drift over time. Review cadence is the privacy-specific application of the epistemic feedback rituals established in (1.2.1).

Does the system degrade safely when privacy is compromised? If a breach occurs, does the system's architecture limit the damage? Compartmentalization, encryption, and minimization each reduce the blast radius of a compromise. A system that stores everything, in one place, unencrypted, with broad access has no safe degradation capacity. A system designed under privacy by design limits what can be exposed by limiting what was collected, how it was stored, and who could access it.