Legal playbook · AI Employee: Lex

Privacy Review for New Features

Every launch privacy-reviewed

Install this playbookBack to marketplace
The problem

Every product team wants to ship faster; every privacy review takes 3-6 weeks and becomes a blocker they route around. Features quietly launch with PII collection that legal didn't see; the DPO learns about it during a customer question or an incident. By then the data is collected, mapped to systems that weren't privacy-cleared, and pulling it back means a migration nobody has time for.

At a glance
Trigger
Form
Approvals
Privacy counsel sign-off
What it does
Writes to your systems
Systems
Product · Ironclad · Privacy KB
How it feels in production

An hour-by-hour walkthrough.

PM Priya opens a feature-launch record in Jira: "Recommendation Engine" — will collect user behaviour signals for personalisation, will call OpenAI for embedding generation, will store 24 months of interaction history. Lex picks up the record within 5 minutes, parses the launch description, and drafts a Privacy Impact Assessment: - Data types collected: user_id, product_view events, search queries, click sequences (behavioural PII) - Data flows: app → analytics warehouse → embedding service (OpenAI, US, EU→US transfer) → recommendation cache - Retention: 24 months (customer profile), 30 days (raw events) - Legal basis: legitimate interest (personalisation), user consent required for EU (GDPR) - Cross-border transfer: EU→US via OpenAI, requires SCCs + transfer risk assessment - User rights impact: DSAR must include recommendation-cache deletion; access request must include behavioural data - Similar prior features: link to the two previous PIAs on related features + their decisions Legal reviewer reads the draft. Adds a required condition: consent banner update for EU users to include recommendation processing. Approves subject to condition. Product team updates the consent banner; Lex verifies the update and marks approval complete. The feature launches with the PIA on file, the DSAR playbook updated to include the recommendation cache, the compliance obligations documented. A future audit sees the full trail. No feature ships without privacy sign-off, and privacy sign-off doesn't ship as a bottleneck.
How it works

Step by step.

  1. 01

    Detect feature-launch records + parse scope

    Read feature-launch records from Jira / Linear / Notion. Classifier identifies privacy-relevant features (PII collection, cross-border transfers, third-party data sharing, retention beyond baseline).

    Jira · Linear · Notion · Privacy-relevance classifier
  2. 02

    Draft the Privacy Impact Assessment

    PIA template: data types, flows, retention, legal basis, cross-border, user-rights impact. Draws from the launch description + system design docs + similar prior features. Highlights novel elements.

    Reasoning · PIA template · Historical PIA library
  3. 03

    Cross-reference DSAR / retention / consent updates needed

    New data types may require: DSAR playbook updates, retention rule additions, consent banner updates, subprocessor list additions, DPA amendments. Lex flags each; approval carries the update-list.

    DSAR runbook · Retention policy · Consent management · Subprocessor list
  4. 04

    Legal review + conditional approval

    Legal reviewer approves as-drafted, requests changes, requires conditions, or blocks pending significant redesign. Conditions tracked to fulfilment before approval marked complete.

    Web UI · Slack · Teams · Approval flow
  5. 05

    Verify conditions + release for launch

    Conditions verified: consent banner updated, DSAR runbook updated, subprocessor list updated. Feature-launch record marked privacy-approved. PIA filed for audit. Post-launch scan for scope creep.

    Consent management · DSAR runbook · Subprocessor registry · Audit log
Systems and wiring

What you connect to make this run.

Jira · Linear · Notion · Product management

read+write

Feature-launch records with launch descriptions + design docs. Read for scope; write privacy-approval status + PIA link so launch gates cannot pass without approval.

OneTrust · TrustArc · Consent management

read+write

Consent-banner state + user-consent records. Verify banner updates for new data types; ensure consent records propagate to the systems consuming the data.

Retention policy · Subprocessor registry

read+write

Retention rules per data type; subprocessor list of third parties processing data. Updates required for launch flow through here + reflected in customer-facing DPA amendments.

PIA library · Compliance documentation

read+write

Historical PIAs + compliance analysis. Similar prior features surface as reference; new PIA becomes reference for future similar features. Compounds over time.

What changes

Before and after, honestly.

Time from feature-launch record to PIA drafted
Before
3-14 days (waiting for legal bandwidth)
After
Under 30 minutes
Legal reviewer time per PIA
Before
4-12 hours
After
45-90 minutes (review + condition-setting)
% of features shipped with privacy review
Before
50-75%
After
98%+ (mechanism prevents un-reviewed launches)
Post-launch privacy incidents (PII collection surprises)
Before
3-8 per year
After
0-1 per year
Related

Playbooks that pair with this one.

Legal

Data Subject Request Routing

New features may add DSAR-relevant data types; runbook updated as part of approval.

Security

Privacy / Data Deletion

Deletion inventory updated to include new systems from launched features.

Security

Vendor Security Review

New subprocessors require vendor security review + DPA before launch.

Frequently asked

Answers about this playbook.

What if the feature doesn't collect PII (pure computational feature)?

Fast-track review: Lex classifies non-privacy-relevant, files a lightweight record noting the classification with reasoning, and marks approved automatically. Reviewer can spot-check the classification.

How does it handle features that use AI / LLMs?

AI-specific PIA questions: model provider, data sent to model, model retention policy, training-use permissions, cross-border transfer of prompts. Modern PIA templates include these; older ones being updated as we encounter each pattern.

Can it review third-party integrations we plug in?

Yes — third-party integration is a special feature type. Vendor security review + DPA + subprocessor addition all flow from the same trigger.

What about features that change scope after launch?

Post-launch scope changes require an amendment PIA. Product changes affecting data collection, retention, or sharing route to the same review flow with the prior PIA as baseline.

How does this interact with our internal launch process?

Privacy approval becomes a required gate in the launch process alongside security review + go-to-market readiness. Same launch record; parallel review streams.

See it run on your data.

Free plan, no credit card. Connect the systems this playbook needs and run it against a past event first.

Book a demoMore Legal playbooks