GDPR Employee DSR Automation

Automates GDPR-style employee Data Subject Request (DSR) processing. Scans a Google Drive folder, evaluates each file for relevance to the requester, redacts third-party PII and sensitive content, and produces an export pack with a reference PDF and decision logs.

What It Does

1. Takes a requester identity (name + identifiers) and a Google Drive folder URL
2. Recursively scans Drive for documents (Docs/Sheets, Word/Excel/PDF, email .eml files)
3. Evaluates each record using a 14-step decision logic (identifier matching, relates-to analysis, incidental mention exclusion, privilege detection, security content flagging)
4. Redacts third-party PII (emails, phone numbers) and security-sensitive content
5. Creates a numbered output folder in Drive with redacted/extracted copies
6. Generates a Reference PDF (decision memo) and decision logs (CSV + JSON)

Quick Start

# 1. Clone and enter project directory
cd dsr-automation

# 2. Set up Google Cloud credentials (see below)

# 3. Run setup + start
chmod +x setup_and_run.sh
./setup_and_run.sh

Google Cloud Setup

1. Create a Google Cloud Project

• Go to Google Cloud Console
• Click the project dropdown at the top of the page and select New Project
• Give it a name (e.g. "DSR Automation") and click Create
• Make sure the new project is selected in the dropdown before continuing

2. Enable the Google Drive API

• In the left sidebar, go to APIs & Services > Library
• Search for "Google Drive API"
• Click on it and press the Enable button
• Wait for it to finish enabling before moving on

3. Configure the OAuth Consent Screen

This tells Google what your app is and who can use it.

• In the left sidebar, go to APIs & Services > OAuth consent screen
• Select External as the user type and click Create
  • (Internal is only available for Google Workspace orgs)
• Fill in the required fields:
  • App name: anything (e.g. "DSR Tool")
  • User support email: your Gmail address
  • Developer contact email: your Gmail address
• Click Save and Continue
• On the Scopes page, click Add or Remove Scopes
  • Search for Google Drive API or paste: https://www.googleapis.com/auth/drive
  • Check the box and click Update, then Save and Continue
• On the Test users page, click Add Users
  • Enter your Gmail address (the one you'll sign in with when running the tool)
  • Click Add, then Save and Continue
  • This step is required — without it, Google will block sign-in with a "403: access_denied" error
• Click Back to Dashboard

4. Create OAuth Credentials

• In the left sidebar, go to APIs & Services > Credentials
• Click Create Credentials at the top, then select OAuth Client ID
• For Application type, choose Desktop app
• Give it a name (e.g. "DSR Desktop Client") and click Create
• A dialog will appear with your Client ID — click Download JSON
• Save the downloaded file as credentials.json in the project root:

  dsr-automation/credentials.json
  

5. First Run — Browser Sign-In

On the first run, a browser window will open asking you to sign in with your Google account:

• Sign in with the same Gmail you added as a test user in Step 3
• You may see a warning: "Google hasn't verified this app" — click Continue
  • This is normal for personal/test OAuth apps
• Grant the requested Drive permissions
• After approval, the browser will show a success message and the terminal will continue
• A token.json file is saved locally so you won't need to sign in again until the token expires

Note: For production use, limit scopes to minimum necessary (drive.readonly for read-only, drive.file for app-created files only). This project uses the full drive scope for simplicity.

Configuration

Copy .env.example to .env and fill in values:

cp .env.example .env

Variable	Description	Default
GOOGLE_CREDENTIALS_FILE	Path to OAuth credentials JSON	credentials.json
GOOGLE_TOKEN_FILE	Path to cached OAuth token	token.json
SOURCE_DRIVE_FOLDER_URL	Default Drive folder URL/ID	(prompted at runtime)
OUTPUT_PARENT_FOLDER_ID	Parent folder for output (optional)	(alongside source)
TIMEZONE	Timezone for timestamps	America/Los_Angeles
OUTPUT_FOLDER_PREFIX	Prefix for output folder name	DSR_EXPORT
LOG_LEVEL	Logging level	INFO

Usage

# Using the setup script (recommended)
./setup_and_run.sh

# Or manually
source .venv/bin/activate
python -m dsr_exporter

The CLI will prompt for:

1. Testing mode — optionally generate sample files in the Drive folder
2. Requester identity — name, email(s), employee ID, usernames, phone
3. Source folder — Google Drive folder URL or ID
4. Processing runs automatically with progress output

Output

The tool creates an output folder in Drive containing:

File	Description
(1) filename.ext, (2) ...	Numbered, redacted/extracted copies
Reference_Notes_*.pdf	Decision memo with per-record rationale
decision_log.csv	Machine-readable decision log
decision_log.json	Structured decision log with metadata

Decision Logic

Each record goes through a 14-step evaluation:

1. Identifier matching — Does the file contain requester name/email/ID?
2. Relates-to analysis — Is the content about the requester (HR, performance, account activity)?
3. Incidental mention exclusion — Is the requester only on a CC line or signature?
4. Partial extraction — Can we extract just the relevant portions?
5. Third-party PII — Redact emails/phones not belonging to the requester
6. Legal privilege — Withhold attorney-client privileged content (heuristic)
7. Security content — Redact passwords, API keys, vulnerability details
8. Intelligibility — Ensure output is understandable with context headers

Decisions: INCLUDE, PARTIAL, EXCLUDE, WITHHOLD

Redaction Strategy

• Emails: Regex-based detection; third-party emails replaced with █REDACTED█
• Phone numbers: US format patterns; non-requester phones redacted
• Security content: Patterns like password:, api key:, token: redacted
• Format-specific: Native redaction for .docx, .xlsx, .pdf, .eml

Limitations

• Name-based PII detection is limited to emails and phone numbers
• Legal privilege detection is keyword-based (heuristic)
• Third-party redaction defaults to redact; balancing test not implemented
• PDF redaction uses PyMuPDF annotations (visual redaction, not pixel-level)

Project Structure

dsr-automation/
  README.md
  requirements.txt
  .env.example
  .gitignore
  setup_and_run.sh
  dsr_exporter/
    __init__.py
    __main__.py          # Entry point
    cli.py               # Interactive CLI
    config.py            # Environment config
    auth.py              # Google OAuth flow
    drive_client.py      # Drive API operations
    content_loader.py    # File download + text extraction
    evaluator.py         # 14-step decision logic
    redactor.py          # PII redaction pipeline
    exporter.py          # Output folder + upload
    reference_pdf.py     # Decision memo PDF
    sample_generator.py  # Test content generator
    models.py            # Data models
    logging_utils.py     # Log file setup
  logs/                  # Run logs (gitignored)
  out/                   # Local output staging (gitignored)
  tmp/                   # Temp files (gitignored)

Testing

Generate sample content during a run by answering "y" to the testing mode prompt. Sample files include:

• In-scope: Performance reviews, HR cases, activity logs, training certs
• Out-of-scope: Newsletters, other employee docs, meeting invites, policy docs
• Needs redaction: Multi-employee reports, employee directories, security audit reports
• Privileged: Legal advice documents and attorney-client emails

Sample files are generated with varied dates spanning 2021–2026 to demonstrate handling of historical records.