Security, privacy, and accessibility
Privacy Engineering Requirements Checklist for Custom Software
A practical checklist for turning privacy obligations and risks into software requirements, data controls, understandable user experiences, test evidence, and operating ownership.
Published by Kennedy Gichobi · Fact-checked by OpenAI Codex research review · Published · 1335 words
Begin with purpose, people, and data actions rather than a policy page
Privacy engineering starts by describing what the software does with information about people. For each workflow, name the person or group, business purpose, decision, data elements, collection source, transformation, inference, recipient, storage, retention, and deletion path. Include information entered by users, imported from customers, created by staff, observed through devices, inferred by analytics, copied into support tools, and emitted through logs. A privacy notice cannot correct an architecture whose processing was never mapped.
Draw a data map over the system architecture. Show browser or mobile clients, APIs, databases, file storage, search indexes, queues, analytics, monitoring, backups, exports, administrators, customer tenants, vendors, and regional transfers. Mark the organization or role responsible at each boundary. NIST’s Privacy Framework is a voluntary risk-management tool rather than a law, and NIST privacy engineering guidance treats maps and design artifacts as inputs to assessing how data processing can create problems for individuals.
Assign legal, product, and technical decisions to qualified owners
Identify the organization determining purposes and means, organizations processing on its behalf, independent recipients, internal data owners, security owners, and people responsible for answering rights or support requests. Record jurisdiction, user location, sector, age considerations, employment or customer context, contractual restrictions, and any sensitive or consequential processing. Qualified privacy or legal counsel must determine applicable obligations, lawful grounds, notices, assessments, agreements, and transfer mechanisms; a developer should make those decisions implementable, not invent them.
Convert reviewed obligations and risk decisions into acceptance criteria. Examples include requiring a purpose before enabling a field, separating optional use from service delivery, documenting a retention rule, obtaining an authorized approval before a new recipient is added, or supporting export and deletion across named systems. Avoid a generic requirement to “be GDPR compliant” or “use encryption.” It cannot be tested, assigns no owner, and conceals which people, processing, law, and risk the project actually addresses.
Minimize collection and choose protective defaults
Challenge each data element: is it necessary for the stated purpose, at this precision, for this duration, linked to this identity, and visible to this audience? A birth month may satisfy a reminder workflow that does not need a full date and year. A service region may support dispatch without retaining continuous location. Aggregate, truncate, tokenize, pseudonymize, or process locally when that still achieves the outcome. Document why the remaining information is necessary so future features do not inherit unexplained collection.
Set defaults around the ordinary user outcome rather than maximum future reuse. Optional analytics, public visibility, marketing, contact discovery, location history, model training, or data sharing should not silently activate because a configuration value was omitted. The UK Information Commissioner’s Office describes data protection by default as limiting use to what is necessary for each specific purpose and recommends integrating appropriate technical and organizational measures throughout the lifecycle. Exact legal application depends on context, but protective defaults are also easier to explain and test.
Make notices, choices, and account controls part of the workflow
Place explanations where people make decisions. State what information is requested, why it is needed, whether it is required, who receives it, and what material consequence follows from declining. Separate genuinely optional purposes. Do not use a single preselected checkbox to conceal unrelated processing or force users through manipulative settings. Maintain versioned notice and preference evidence when it is necessary to demonstrate what the person saw and chose, without collecting excessive behavioral data in the process.
Design account controls for access, correction, export, objection or restriction, withdrawal, and deletion as applicable to the reviewed policy and law. Define identity verification proportionate to the request and risk; asking for more sensitive information than the account contains can worsen the problem. Explain pending, partial, rejected, and completed outcomes, including information retained for a valid reason. Route complex requests to trained staff with deadlines and evidence rather than presenting a button whose background job quietly fails.
Design retention and deletion across active, derived, and recovery systems
Create a retention schedule tied to purpose, policy, contract, and reviewed legal requirements. Include primary records, attachments, versions, audit evidence, analytics, search indexes, derived profiles, caches, queues, monitoring, support tickets, exports, test datasets, and backups. Define the event that starts each period and the owner of exceptions or legal holds. “Delete after seven years” is incomplete if nobody knows whether the clock starts at collection, transaction, account closure, or the end of a dispute.
Implement deletion as an observable workflow with idempotent steps, authorization, scope preview, dependency handling, retry, and completion evidence. Decide whether derived aggregates can remain without being linkable and how restored backups avoid resurrecting deleted active records. Test one record, an entire account, a tenant closure, a failed downstream vendor request, and a hold that overrides ordinary deletion. Provide operators a reconciliation queue instead of marking the request complete when only the primary database changed.
Govern vendors, telemetry, analytics, and new secondary uses
Inventory every service receiving personal or customer information: hosting, email, error reporting, analytics, payments, search, maps, AI providers, customer support, communication, identity, and data warehouses. Record data categories, purpose, account owner, region, retention, access, subprocessors, training or reuse terms, deletion capability, export, incident notice, and exit plan. Configure and verify the actual account; a vendor’s marketing statement does not prove the project uses a protective setting or contract.
Keep production telemetry useful without making it a shadow database. Define allowed event schemas, sanitize free text and URLs, prevent secrets and document contents from entering logs, restrict access, and set retention. Review new dashboards, model features, data enrichment, experimentation, and marketing uses against the original purpose and user expectations. A technically convenient reuse can change privacy risk even when no new field is collected. Establish a lightweight change review that product and engineering teams can actually follow.
Test privacy behavior with representative people and failure scenarios
Build acceptance tests from the map and risk assessment. Verify optional fields, protective defaults, role and tenant boundaries, preference changes, exports, corrections, deletion, retention jobs, vendor failures, revoked access, account closure, support impersonation controls, and administrative audit evidence. Use synthetic or carefully governed test data. Scan code and configuration where helpful, but do not treat automated security checks as proof that notices are understandable, choices are fair, or a processing purpose is appropriate.
Evaluate unusual paths: a person without access to an old email address, duplicate accounts, a minor or vulnerable user where relevant, a disputed correction, an export containing another person, a deletion during an active job, a restored backup, a tenant migration, and a vendor that cannot complete a request. Involve product, engineering, security, privacy, support, and representative users according to risk. Record residual risk and the authorized decision rather than quietly converting every unresolved concern into technical debt.
Require operational ownership and evidence in the delivery agreement
Before commissioning the work, provide the reviewed purposes, data categories, people affected, jurisdictions, current systems, vendors, retention expectations, sensitive workflows, and existing assessments. Require deliverables to include an updated data map, role and tenant model, processing inventory, configuration evidence, retention implementation, request procedures, test results, incident and vendor contacts, deployment ownership, and a backlog of explicitly accepted residual risks. Privacy features without an operating owner decay as the product changes.
Use the application security requirements checklist for the surrounding security controls and the AI document processing requirements checklist when automated extraction or models process documents. Then explore custom software development or share the users, workflow, data, recipients, retention, integrations, reviewed obligations, and desired outcome through the project questionnaire. This checklist supports engineering planning and does not replace legal advice.
Authoritative references
Related software planning guides
- Application Security Implementation Roadmap for Product Owners
- Software Developer Security Due Diligence for Product Owners
- Application Security Requirements Checklist for Software Buyers