o-network. One integrated a third-party analytics tool that sends behavioral event data to the vendor's servers. One modified the recommendation engine to use purchase history data for a new use case the privacy team had not been told about. None of these decisions went through a privacy review. The privacy team found out when a researcher flagged two of the four features on social media.
The Product Velocity Problem
Modern software product teams operate on weekly or biweekly sprint cycles. Features are designed, built, tested, and shipped continuously. Privacy review processes built around formal DPIA requirements — designed for significant new processing activities, assessed over weeks — are not calibrated for sprint velocity. The formal process is appropriate for significant new processing. It is too slow and too heavy for the continuous stream of smaller decisions that collectively determine the privacy posture of a shipping product.
The privacy risk created at sprint velocity is not primarily the risk of a single catastrophic decision. It is the accumulation of individually small decisions — adding a data field here, changing a default there, integrating a vendor tool, expanding a use case — that together shift the product's data practices significantly without triggering any formal review. Each individual decision was below the threshold that would have required a DPIA. The aggregate change over a year of sprints may have materially changed the product's privacy posture.
Privacy risk in product development is not only in the big decisions that trigger formal review. It is in the accumulation of small decisions that each fall below the review threshold and collectively move the product further from the privacy principles the organization claims to uphold.
The Four Decisions That Needed Privacy Input
Extending Data Collection
The three new fields added to the onboarding flow collect data the product did not previously collect. Data minimization requires that collection be limited to what is necessary for the stated purpose. 'Helpful for personalization' is a purpose description that does not establish necessity. The fields may collect data that creates special category implications, that extends the product's data footprint in ways that affect existing retention and deletion obligations, or that creates new legal basis questions for processing. A privacy review would have asked these questions. The sprint shipped without one.
Changing Default Privacy Settings
Changing a default setting from private to visible-to-network is one of the most consequential privacy decisions a product team can make. Default settings are what most users will experience — users who do not read settings pages, users who trust that the default reflects the platform's judgment about what is appropriate. A default that shifts user data from private to visible-to-network is a decision that affects every user who has not actively set their preferences. Under GDPR, privacy-by-default requires that the most privacy-protective settings be the default. Changing defaults toward less privacy protection requires a legal basis assessment that did not happen.
Integrating a Third-Party Analytics Tool
The integration sends behavioral event data to a vendor whose data practices, subprocessor relationships, and data retention policies the privacy team has not reviewed. The data being sent may include personal data that the organization is responsible for protecting. The vendor relationship requires a data processing agreement before processing begins. The integration shipped without a vendor assessment or a DPA. The personal data is now flowing to a vendor that has not been assessed for compliance with the organization's data protection obligations.
Expanding a Use Case Without Assessment
Using purchase history data for a recommendation engine use case that was not disclosed to users at collection creates a purpose limitation issue. Personal data collected for one purpose may not be used for an incompatible purpose without a new legal basis or user notification. Whether the new recommendation use case is compatible with the original collection purpose is a legal question that requires assessment. The decision to expand the use case without that assessment has created a potential processing-beyond-consent situation at scale.
Building Privacy Into Sprint Velocity
The organizations that have made meaningful progress on this problem have built a lightweight privacy review mechanism that operates at sprint velocity rather than at DPIA velocity. The mechanism is not a full DPIA for every feature — that would stop shipping. It is a structured set of questions that product managers answer as part of the feature design process, before development begins, that surfaces the features that need privacy input.
The screening questions are simple: Does this feature collect new personal data categories? Does it change how existing personal data is used? Does it integrate a new third-party tool that will process personal data? Does it change a default setting that affects user privacy? A 'yes' to any of these questions triggers a conversation with the privacy team, not a full DPIA — a 30-minute review that identifies whether a more formal assessment is needed or whether the feature can proceed with specific design constraints.
The privacy team does not review every feature. They review every feature that answers 'yes' to a screening question. The screening is done by the product manager. The privacy review is triggered when needed. The velocity impact is minimal. The coverage is meaningfully better than the current state in most organizations, which is that privacy reviews happen when the privacy team finds out about a feature — which may be after it ships.
Build the privacy screen into the sprint process. The conversation before development costs minutes. The remediation after shipping costs months.
Put the privacy question at the feature design stage, not at the post-launch audit. The earlier the question is asked, the cheaper it is to answer correctly.
Enterprise practitioner perspective. Not legal advice. Part of the Deep Trust Governance Series by Verisq. Get the free weekly Breach Digest.