Tutorial 15: Document Security & Redaction

1. Identity Information
   - Full names, nicknames
   - Dates of birth
   - Social Security Numbers (SSN)
   - Driver's license numbers
   - Passport numbers
   - Tax ID numbers

2. Contact Information
   - Personal email addresses
   - Cell phone numbers
   - Home addresses
   - GPS/location data

3. Financial Information
   - Bank account numbers
   - Credit card numbers
   - Routing numbers
   - Credit limits/balances

4. Medical Information
   - Diagnoses
   - Medication names
   - Hospital/provider names
   - Medical record numbers

5. Organizational Information
   - Employee IDs
   - Internal job titles
   - Company phone extensions
   - Internal email addresses

6. Biometric Data
   - Fingerprints
   - Facial recognition data
   - Signature samples

I need to scan a set of discovery documents for personally identifiable information.

Please create a comprehensive PII detection protocol that:

1. Identifies all SSNs (XXX-XX-XXXX format and variants)
2. Finds dates of birth (MM/DD/YYYY patterns)
3. Locates home addresses (full street addresses, not business)
4. Detects personal email addresses
5. Identifies personal phone numbers (cell vs. business)
6. Flags medical information (diagnoses, medications, treatment)
7. Detects financial account numbers
8. Identifies driver's license and passport numbers

For each PII type found:
- Exact location in document
- Context (sentence containing the PII)
- Sensitivity classification (High/Medium/Low)
- Regulatory requirement (GDPR/CCPA/HIPAA/other)

Create a detection checklist with regex patterns for each category.

Analyze this document set for named entities:

1. Names of individuals (first and last)
   - Distinguish from business names
   - Identify repeated individuals
   - Link variations (Dr. Smith vs. Robert Smith)

2. Organizations (companies, institutions)
   - Distinguish from personal business entities
   - Identify headquarters vs. branches
   - Classify as vendor, client, competitor

3. Locations (specific addresses)
   - Distinguish home from business addresses
   - Identify sensitive locations
   - Map geographic distribution

4. Relationships (who knows whom)
   - Family relationships
   - Business relationships
   - Professional relationships

Create an entity relationship diagram showing connections.
Format results as a CSV with: Entity Name | Entity Type | Location(s) | Context | Sensitivity Level

Classify identified PII by sensitivity level:

HIGH SENSITIVITY (must redact in all productions):
- SSNs and government ID numbers
- Financial account numbers
- Medical diagnoses and treatment details
- Specific home addresses
- Personal cell phone numbers

MEDIUM SENSITIVITY (redact unless necessary to case):
- Personal email addresses
- Individual first and last names (if not party/witness)
- Dates of birth
- Employer names and locations

LOW SENSITIVITY (may not require redaction):
- Job titles
- Business phone numbers
- Professional affiliations
- Public appointment positions

Create a redaction priority matrix showing which PIIs must be redacted
in each type of production (opponent, court, third-party custodian, etc.).

Create a PII detection and classification protocol for:
- 500 discovery documents (mix of emails, attachments, forms)
- Multiple document formats (PDF, Word, Excel, images)
- International addresses and phone numbers
- Medical, financial, and employment information

Your protocol should include:

1. Complete PII type detection list with patterns
2. Sensitivity classification scheme (with 3-4 levels)
3. Production-type specific rules (opponent vs. court)
4. False positive handling procedures
5. Quality control checklist (verification process)
6. Timeline estimate for automated vs. manual review
7. Cost/benefit analysis of different redaction approaches

Estimate: How long would manual review take? How much time does
Claude-assisted detection save?

I have a set of discovery documents that need redaction before production.

Please create a redaction workflow that includes:

1. Document inventory (count, types, formats)
2. PII identification (all instances of SSN, addresses, phone numbers)
3. Redaction strategy (which PII redacts in which productions)
4. Batch processing approach (how to handle all documents efficiently)
5. Output naming convention ([ORIGINAL-FILENAME]_REDACTED_[DATE])
6. Version control (track original vs. redacted)
7. Verification checklist (how to confirm redactions)
8. Audit trail (who redacted what, when, why)

Create templates for:
- Redaction decision memo (documenting redaction choices)
- Verification checklist (QA process)
- Production certificate (certifying redactions completed)

Redact this document according to our production rules:

RULES:
- SSNs: Replace with [SSN REDACTED]
- Addresses: Replace with [ADDRESS REDACTED]
- Phone numbers (personal): Replace with [PHONE REDACTED]
- Medical information: Replace with [MEDICAL INFO REDACTED]
- Financial account numbers: Replace with [ACCOUNT REDACTED]

PRESERVE:
- Employee names and titles (not redacted unless specifically marked)
- Business phone numbers and addresses
- Company email addresses

Process:
1. Identify all PII that matches redaction rules
2. Replace with appropriate placeholder
3. Note each redaction in a separate log:
   - Original content (for verification)
   - Redaction reason
   - Page/location in document
4. Maintain consistency (same PII = same replacement)
5. Format output as clean version for production

Output both:
a) Clean redacted document (for production)
b) Redaction log (for verification and privilege log)

I need to redact a 150-page PDF discovery document.

Create a PDF redaction workflow including:

1. OCR detection (ensure all text, including in images, is identified)
2. Text layer redaction (search for PII in PDF text)
3. Image layer redaction (identify PII in embedded images/scans)
4. Metadata scrubbing (remove author, creation date, edit history)
5. Form field completion (redact pre-filled form fields)
6. Annotation handling (redact handwritten notes if needed)
7. Bookmark and link preservation (maintain document structure)
8. Output verification (ensure no redacted text is selectable)

For PDF redaction, compare:
- Using redaction tools (creates opaque boxes)
- Using masking (overlays content)
- Using removal (deletes content entirely)

Which approach is most appropriate for legal discovery?
What are the risks of each approach?

Create a batch redaction protocol for 250 documents across multiple custodians:

Requirements:
- Different redaction rules for different custodians
- Track which documents have been redacted
- Maintain version control
- Create verification logs
- Generate production certificate
- Handle mixed document formats

Your workflow should include:

1. Document intake and categorization
2. Custodian-specific redaction rules
3. Batch processing approach (reduce manual work)
4. Quality control sampling (use a risk-based sample size; escalate for high-risk documents)
5. Problem escalation (how to handle difficult cases)
6. Final verification before production
7. Production logging and documentation

Create a project timeline and resource estimate.

We're redacting discovery documents in multiple formats:
- PDFs (scanned and native)
- Microsoft Word (with tracked changes)
- Excel spreadsheets (with formulas and hidden columns)
- PowerPoint presentations
- Scanned TIFFs and JPGs
- Email with embedded images and attachments

Create a format-specific redaction guide that addresses:

1. PDF Scans
   - Text detection/OCR limitations
   - Image redaction techniques
   - Metadata stripping

2. Microsoft Word
   - Hidden text in tracked changes
   - Comments and revision history
   - Embedded objects and OLE files
   - Headers/footers/page numbers

3. Excel
   - Hidden columns and rows
   - Cell comments and notes
   - Formula bar content (may differ from displayed value)
   - External links and connections

4. PowerPoint
   - Speaker notes
   - Slide comments
   - Embedded content
   - Hidden slides

5. Email Files
   - Metadata (To, From, CC, BCC, Date, Subject)
   - Message body
   - Embedded images
   - Attachments

For each format, specify:
- Highest PII risks
- Difficult redaction areas
- Verification requirements
- Tools required

I have scanned documents (JPG and TIFF files) containing sensitive information.

Create an image redaction workflow:

1. OCR Processing
   - Convert image text to searchable format
   - Identify confidence levels (low confidence = manual review)
   - Handle handwritten notes vs. typed text
   - Address image quality issues (faded, rotated, multi-page scans)

2. PII Detection in Images
   - Locate SSNs, addresses, phone numbers
   - Identify medical, financial, or other sensitive data
   - Note location (pixel coordinates or describe location)

3. Redaction Application
   - Create blackout boxes over sensitive information
   - Ensure boxes completely obscure text
   - Verify no text is visible under redaction
   - Apply consistently formatted boxes

4. Output Options
   - Marked-for-redaction version (for reviewer approval)
   - Final redacted version (black boxes applied)
   - Searchable PDF (OCR'd text with redactions applied)

Create a quality control checklist for image redactions.
What percentage of images should be manually verified?

Some of our discovery documents contain embedded objects:
- OLE objects in Word documents
- Embedded Excel sheets in PowerPoint
- Linked images and files
- Embedded fonts and resources

Create a protocol for identifying and redacting embedded objects:

1. Detection
   - How to identify embedded content
   - Tools to extract embedded objects
   - Risks of missing embedded content

2. Risk Assessment
   - Which embedded objects pose PII risks?
   - Which can be safely left as-is?
   - Which should be removed entirely?

3. Redaction Strategy
   - Redact within embedded objects?
   - Remove entire embedded object?
   - Replace with placeholder?
   - Document handling decisions?

4. Verification
   - How to confirm embedded content is redacted
   - Tools to check for hidden content
   - Audit trail requirements

Provide specific examples of high-risk embedded content.

Before producing discovery documents, we need to remove all metadata.

Create a metadata scrubbing protocol covering:

DOCUMENT METADATA:
- Author name and initials
- Company name
- Creation date
- Last modified date
- Last modified by
- Template name
- Subject and keywords
- Comments and notes

EMAIL METADATA:
- Original message ID
- Internet headers (containing server routing)
- Original timestamp and timezone
- BCC recipients (if any)
- Sent on behalf of (delegation)
- Folder location

DOCUMENT PROPERTIES:
- Edit history
- Tracked changes (accept/reject to remove)
- Comments and revision marks
- Hidden text or comments
- Variable values
- Links and external references

For each metadata type:
1. Specify if it must be removed or can be preserved
2. Describe removal method for each format
3. Verify removal technique (how to confirm?)
4. Risk if metadata is not removed (privacy/strategic concerns)

Create a format-by-format metadata removal checklist.

You have a document set with mixed formats requiring redaction:

DOCUMENTS:
- 50 PDF files (mix of scanned and native)
- 30 Word documents (with tracked changes)
- 20 Excel spreadsheets
- 10 PowerPoint presentations
- 5 email export files (with embedded images/attachments)
- 40 scanned TIFF images (poor quality, handwritten notes)

REDACTION RULES:
- Redact all SSNs, home addresses, personal phone numbers
- Redact medical diagnoses and treatment information
- Remove metadata from all documents
- Strip tracked changes and comments from Word
- Redact form fields and hidden columns from Excel
- Remove speaker notes and comments from PowerPoint

Create a complete project plan including:

1. Document assessment (by format type)
2. Format-specific redaction strategy
3. Quality control approach (especially for images)
4. Team resource requirements
5. Timeline and milestones
6. Verification procedures
7. Risk mitigation (what could go wrong?)
8. Production certificate requirements

Estimate total time and cost.

I need to de-identify a document set for demonstrating workflows
to opposing counsel's technical team (they can't see real names).

Create a de-identification strategy that:

1. Assigns replacement tokens to each individual:
   - Person A = [INDIVIDUAL-001]
   - Person B = [INDIVIDUAL-002]
   - Witness A = [WITNESS-001]
   - Expert A = [EXPERT-001]

2. Maintains consistency throughout the document set
   - Every instance of "John Smith" becomes [INDIVIDUAL-001]
   - His email "john.smith@company.com" also becomes [INDIVIDUAL-001]
   - His role "Sales Manager" is replaced with [SALES ROLE-001]

3. Preserves document utility
   - Relationships between people remain clear
   - Timeline remains intact
   - Document references still work

4. Creates a de-identification map (kept confidential):
   - [INDIVIDUAL-001] = John Smith [SSN: 123-45-6789]
   - [SALES ROLE-001] = Sales Manager
   - [COMPANY-A] = TechCorp Inc.

5. Verification process
   - No original names remain in de-identified version
   - No identifiable personal information remains
   - Map is securely stored separately

Create a de-identification template showing both original
and de-identified versions of a sample document.

Create a pseudonymization protocol that differs from anonymization:

ANONYMIZATION (irreversible):
- Cannot identify original person even with the key
- Example: Replace SSN with random hash value

PSEUDONYMIZATION (reversible, keyed):
- Can re-identify with the lookup table
- Useful for clinical trials, marketing analysis
- Example: Replace SSN with token "PSN-001987-AC"

Develop a workflow that:

1. Assigns pseudonym to each individual:
   - Original: Susan Johnson, DOB 1978-03-15, SSN 234-56-7890
   - Pseudonym: PSN-001
   - Maintains first letter of last name? Or fully random?

2. Applies pseudonym consistently across documents
   - All mentions of Susan Johnson → PSN-001
   - All her contact info → PSN-001
   - Her role/title → kept but separated from pseudonym

3. Creates secure pseudonym table
   - Stored separately from production documents
   - Encrypted storage
   - Access controlled and logged
   - Retention/deletion policy

4. De-reversal procedure
   - How to re-identify if needed for litigation
   - Audit trail requirements
   - Authorization controls

Create a pseudonym assignment algorithm that:
- Generates unique identifiers
- Prevents accidental re-identification
- Allows batch processing
- Creates audit trail

Create a de-identification protocol for this scenario:

You're preparing a 100-document sample set for:
- Opposing counsel's technical team review
- Expert reviewer who doesn't need to know identities
- Client training/demo purposes
- Regulatory authority (anonymized for public guidance)

Requirements:
- All individuals identified only by role/function
- No SSNs, addresses, phone numbers
- No company names (use descriptive codes)
- Timeline and document references preserved
- No identifiable information remains
- De-identification map kept secure and separate

Your protocol should include:

1. De-identification mapping
   - All individuals and their replacements
   - All companies and their replacements
   - All sensitive roles and replacements

2. Verification checklist
   - No original names appear
   - No contact information appears
   - No government IDs appear
   - Relationships still clear
   - Timeline still coherent

3. Access controls
   - Who can access original vs. de-identified versions?
   - How are documents shared?
   - How is de-identification map protected?

4. Audit trail
   - Who created de-identified version?
   - When was it created?
   - What changes were made?
   - Who has accessed it?

I need to create realistic test/demo documents based on real discovery
documents, without using actual client/party information.

Create a data masking and sample generation protocol:

1. ANALYZE ORIGINAL DOCUMENTS
   - Document types and formats
   - Data fields and content structure
   - Relationship patterns (who communicates with whom)
   - Timeline and date ranges
   - Topic themes and vocabulary

2. GENERATE REALISTIC SAMPLES
   - Create fictional individuals (realistic names, but not real people)
   - Assign fictional roles and departments
   - Create fictional companies and subsidiaries
   - Generate realistic dates and timelines
   - Use realistic communication patterns
   - Match vocabulary and terminology of originals

3. MAINTAIN RELATIONSHIPS
   - Preserve who-reports-to-whom structure
   - Preserve communication patterns (who talks to whom)
   - Preserve timeline logic (event sequence)
   - Preserve document references (reports, memos, etc.)

4. CREATE REALISTIC ATTACHMENTS
   - Generate sample spreadsheets (realistic structure, fake data)
   - Generate sample reports (same format, new content)
   - Generate sample emails (same tone, new substance)

5. VERIFICATION
   - Does sample data look realistic?
   - Can documents be used for training/demo?
   - Any remnants of real information?
   - Are relationships and timelines logical?

Generate 10 sample documents that would work for:
- Staff training
- Opposing counsel demo
- Expert witness review
- Court system demo
- Technical platform testing

We're setting up a test environment for our litigation support platform.

Create a protocol for populating test environment with safe data:

1. DATA SOURCE STRATEGY
   - Option A: Use synthetic/generated data (completely fictional)
   - Option B: Use real data with masking applied
   - Option C: Use real data with approved subset
   - Pros/cons of each approach

2. DATA MASKING RULES
   - Which fields are masked?
   - How is masking applied? (Hashing, replacement, encryption)
   - Is masking reversible?
   - Can test data be used for performance testing?

3. DATA VOLUME
   - How much test data do you need?
   - Sample size for realistic testing
   - Scaling for performance testing
   - Balancing realism with efficiency

4. DATA RELATIONSHIPS
   - Maintain referential integrity
   - Preserve business logic
   - Test realistic scenarios
   - Support edge case testing

5. ACCESS CONTROLS
   - Who can access test environment?
   - What data can they see?
   - Audit logging for test data access
   - Retention/deletion policy for test data

Create a test data strategy for a litigation platform
that needs 100+ realistic sample documents.

Create a protocol for generating demo/training documents:

REQUIREMENTS:
- Documents must look and feel real
- Must demonstrate actual workflows and challenges
- Cannot contain any actual confidential information
- Must be suitable for external sharing (client, opposing counsel)
- Must include realistic examples of:
  * Privilege issues
  * Responsive vs. non-responsive
  * PII redaction needs
  * Metadata problems
  * Format conversion issues

DEMO DOCUMENT SCENARIOS:

1. DISCOVERY PRODUCTION DEMO
   - 25 documents showing typical issues
   - Include examples of proper and improper redactions
   - Show metadata challenges (tracked changes, comments)
   - Show format challenges (PDFs, scans, emails)

2. PRIVILEGE LOG DEMO
   - 15 documents with privilege assertions
   - Range of privilege types (attorney-client, work product)
   - Examples of proper vs. improper assertions
   - Show withholding rationale

3. REDACTION VERIFICATION DEMO
   - Examples of properly applied redactions
   - Examples of inadequate redactions
   - Show detection techniques
   - Demonstrate verification checklist

4. DEPOSITION TRANSCRIPT DEMO
   - Sample testimony with PII
   - Examples of privilege issues
   - Show redaction strategy
   - Demonstrate transcript analysis

Create a master demo document set suitable for:
- Client training on redaction procedures
- Staff onboarding on discovery workflows
- Opposing counsel platform demo
- Court system demonstration
- Regulatory authority briefing

Estimate: How much time to create realistic demo set?
What are the key challenges?

Design a complete test data strategy for a legal tech platform:

PLATFORM FEATURES (that need test data):
- Document upload and indexing
- Automatic PII detection
- Redaction workflow
- OCR for scanned documents
- Email threading
- Timeline generation
- Deposition transcript analysis
- Search functionality (full-text)

TEST DATA REQUIREMENTS:

1. Volume and Mix
   - At least 500 documents for realistic testing
   - Multiple formats (PDF, Word, Excel, Email, Images)
   - Mix of quality (clear, poor scans, handwritten)
   - Various document types (emails, reports, contracts, etc.)

2. Realistic Content
   - Industry-specific vocabulary
   - Realistic workflows and communication patterns
   - Realistic timelines
   - Realistic relationships between individuals

3. Challenge Documents
   - Documents with all PII types (SSN, addresses, DOB, etc.)
   - Scanned documents with poor OCR challenges
   - PDFs with embedded objects
   - Emails with extensive attachments
   - Documents with privilege issues

4. Verification
   - No actual confidential information
   - Safe to share with vendors/contractors
   - Safe to use in production demo

Your test data strategy should include:

1. Data generation approach
2. Content guidelines (realistic but fictional)
3. QA/verification checklist
4. Access controls
5. Retention/destruction policy
6. Cost estimate
7. Timeline to completion

Present as if proposing to your managing partner.

Our discovery production includes personal data from EU residents.

Create a GDPR-compliant discovery protocol:

1. DATA MINIMIZATION
   - Only produce information relevant to case
   - Redact personal data not necessary for case
   - Assess each document: Is PII necessary?
   - Balance legitimate legal need vs. privacy rights

2. PERSONAL DATA IDENTIFICATION
   - All data that relates to identified/identifiable individual
   - Includes not just obvious identifiers but:
     * Nicknames and pseudonyms
     * Business email addresses
     * Employee/customer IDs
     * Device identifiers (IP addresses)
     * Combination of factors (e.g., job title + department = identifiable)

3. SPECIAL CATEGORIES (Enhanced Protection)
   - Racial or ethnic origin
   - Political opinions
   - Religious or philosophical beliefs
   - Trade union membership
   - Genetic data
   - Biometric data
   - Health data
   - Sex life or sexual orientation data

   For special categories: Extra caution, possible complete redaction

4. LEGAL BASIS FOR PROCESSING
   - What legal basis justifies producing PII?
   - Is court order sufficient?
   - Must you limit disclosure to parties' lawyers?
   - What data retention period?

5. DATA PROTECTION IMPACT ASSESSMENT (DPIA)
   - Assess privacy risks of production
   - Document alternative approaches
   - Apply minimization techniques
   - Document decision-making

6. TRANSFER RESTRICTIONS (if sending outside EU)
   - Standard Contractual Clauses (SCCs)
   - Adequacy decisions
   - Data protection agreements with recipients
   - Supplementary measures to address risks

Create a GDPR compliance checklist for discovery productions.

California Consumer Privacy Act impacts discovery if documents
relate to California residents.

Create a CCPA-compliant discovery protocol:

1. CCPA "PERSONAL INFORMATION" (Broader than GDPR)
   - Name and contact information
   - Commercial information
   - Internet/browsing activity
   - Geolocation data
   - Sensory information (voice, video)
   - Professional information
   - Education information
   - Inference data (profiles, predictions)

2. CONSUMER RIGHTS IN DISCOVERY
   - Right to know what information exists
   - Right to delete (can litigation hold override?)
   - Right to opt-out of sale (but e-discovery may require review)
   - Right to non-discrimination
   - Right to limit use and disclosure

3. BUSINESS OBLIGATIONS
   - Privacy notice (if personal info being processed)
   - Service provider contracts (confidentiality agreements)
   - Data retention/deletion schedule
   - Response to deletion requests (conflict with litigation hold?)

4. DISCOVERY-SPECIFIC ISSUES
   - Can you produce personal information without consumer consent?
     * In response to law enforcement request: Yes, with notice
     * In response to civil subpoena: Limited circumstances
     * In litigation: Generally yes, but consider privacy impact
   - Conflict between litigation hold and deletion rights
   - Timing of destruction after litigation ends

5. CCPA AUDIT TRAIL
   - Document what personal information you have
   - Document who has accessed it
   - Document retention periods
   - Document deletion procedures

Create a CCPA compliance framework for discovery productions
involving California residents.

Create a comprehensive privilege log redaction protocol:

WHAT GETS REDACTED IN PRIVILEGE LOG?

1. SUBSTANTIVE CONTENT
   - Redact descriptions of privileged communications
   - Don't describe the legal advice given
   - Don't summarize work product analysis

   GOOD: "Email from outside counsel regarding litigation strategy"
   BAD: "Email from outside counsel recommending settlement threshold of $2M"

2. PARTICIPANT IDENTIFICATION
   - Parties/in-house counsel: Usually not redacted
   - Outside counsel: Usually not redacted (it's public knowledge)
   - Third parties: Sometimes redacted (e.g., document custodian)
   - Consultants vs. attorneys: May need redaction

3. DATE AND DOCUMENT IDENTIFICATION
   - Production numbers: Not redacted (you're producing the log)
   - Document dates: Usually not redacted
   - Document names: Redact if descriptive (see above)
   - Page numbers: Not redacted

4. PRIVILEGE ASSERTION
   - Type of privilege: State clearly (attorney-client, work product)
   - Basis for assertion: Describe without revealing content
   - Privilege holder: Identify
   - Asserting party: Identify clearly

5. WITHHELD DOCUMENTS
   - Clearly mark as "WITHHELD ON GROUNDS OF PRIVILEGE"
   - Don't include in production
   - But DO include in privilege log

TEMPLATE ENTRIES:

Good Entry:
"Email dated 1/15/2024, from outside counsel to company management,
regarding legal strategy in pending litigation.
Privileged attorney-client communication.
WITHHELD ON GROUNDS OF ATTORNEY-CLIENT PRIVILEGE"

Poor Entry (reveals too much):
"Email dated 1/15/2024, from Smith & Associates LLP to John Doe
recommending settlement offer of $5 million to avoid costly trial.
Work product - attorney strategy.
WITHHELD ON GROUNDS OF ATTORNEY WORK PRODUCT"

Create a privilege log template and redaction guide.

Our discovery production includes information about third parties
(vendors, competitors, customers) who didn't request privilege.

Create a protocol for third-party data protection:

1. ASSESSMENT QUESTIONS
   - Is the information about identifiable third party?
   - Would third party want this information protected?
   - Is the information business confidential or personal?
   - Would disclosure harm third party's competitive position?
   - Would disclosure violate third party's privacy?

2. PROTECTION OPTIONS

   Option A: PRODUCE WITHOUT PROTECTION
   - Responsive and not privileged
   - No third-party confidentiality obligation
   - No alternative to avoid production
   - Example: Public regulatory filing

   Option B: PRODUCE WITH CONFIDENTIALITY DESIGNATION
   - Mark as "CONFIDENTIAL - THIRD PARTY INFO"
   - Restrict access to parties' attorneys only
   - Include in protective order
   - May require third-party consent notification

   Option C: REDACT THIRD-PARTY SPECIFIC INFORMATION
   - Remove business confidential or personal details
   - Redact trade secrets
   - Redact sensitive personal information
   - Preserve core responsive information

   Option D: REQUEST PROTECTIVE ORDER
   - Seek court order limiting access
   - Justify need for protection
   - Propose access restrictions
   - Requires court approval

3. DOCUMENT HANDLING
   - Track which documents contain third-party info
   - Flag for confidentiality review before production
   - Include confidentiality legend on documents
   - Add to privilege log if withheld entirely
   - Document decision rationale

4. THIRD-PARTY NOTIFICATION (sometimes required)
   - Some jurisdictions require notifying affected third parties
   - Opportunity to seek protective order
   - Timeline for third-party response
   - Impact on production schedule

Create a third-party data handling matrix for:
- Vendor information
- Customer information
- Competitor information
- Employee information
- Patient/health information
- Financial partner information

Specify which protection level applies to each category.

Create a comprehensive compliance protocol for a discovery production
involving multiple jurisdictions and privacy frameworks:

SCENARIO:
- Producing 5,000 documents in multi-state litigation
- Documents involve: 8 employees, 15 customers, 3 vendors
- Locations: California, New York, Texas, and EU (2 employees)
- Contains: Financial data, medical information, personnel records

REQUIREMENTS:
- CCPA compliance (CA residents)
- GDPR compliance (EU residents)
- State privacy laws (NY, TX privacy standards)
- Industry standards (healthcare data)
- Company policies (confidentiality agreements)
- Court orders (judicial constraints)

Your protocol must include:

1. JURISDICTION-BY-JURISDICTION ANALYSIS
   - What privacy laws apply?
   - What's the legal basis for production?
   - What special protections apply?
   - Who must approve the production?

2. DATA CLASSIFICATION
   - Map all 5,000 documents
   - Identify PII by type and sensitivity
   - Classify by jurisdiction/person
   - Flag special categories (health, financial)

3. PRODUCTION DECISIONS FOR EACH DOCUMENT
   - Produce as-is?
   - Produce with redactions?
   - Withhold as privileged?
   - Request protective order?
   - Notify third party before producing?

4. PROTECTIVE MEASURES
   - Confidentiality designations
   - Access restrictions
   - Secure transmission methods
   - Recipient tracking

5. DOCUMENTATION
   - Production memo
   - Redaction decisions and rationale
   - Privilege log (if applicable)
   - Certificate of compliance
   - Audit trail

6. TIMELINE AND RESOURCES
   - Estimated review time
   - Team members needed
   - Budget
   - Critical path

7. QUALITY CONTROL
   - Random sampling verification
   - Redaction completeness check
   - Privilege assertions verification
   - Compliance checklist

Present this as a proposal to a litigation partner.
How would you handle conflicts between CCPA deletion
rights and litigation hold obligations?