Multi-Brand Data Protection Design

Format: .pdf, .doc, .docx, .rtf, .txt, .md

Your working design as a document (Markdown, PDF, or a clearly formatted Word/Google doc). It must cover, for the repositories above:

• A classification scheme with a tier assigned to each repository and a stated reason tied to that repository's actual data
• A DLP control mapping to at least the egress channels represented above (e.g., the partner export, the support-ticket system), naming what each control detects and why
• A DSPM approach for ongoing discovery/posture visibility, distinct from your DLP design
• Encryption and key-management standards — at rest and in transit — for at least your highest-sensitivity repository, including a key-lifecycle approach and where tokenization applies
• A data-access governance and retention/deletion design, explicitly accounting for the legal-hold exception
• An AI data governance design for the ai-support-copilot-corpus repository — training-data/RAG-source controls and prompt/response DLP — scoped to stay out of App & AI Security's territory

You do not need to build software or deploy infrastructure. A structured written design is sufficient. Include a brief note at the top explaining how the document is organized.

Format: .pdf, .doc, .docx, .rtf, .txt, .md

Section A — Design Rationale (300–500 words)

• Why did you tier the repositories the way you did? Which repository was hardest to classify, and why?
• Which DLP/DSPM controls did you choose and why? What did you consider and reject?
• What does "medium risk" or a flagged event look like in your design, and what happens next — a block, a review queue, something else?
• What are the most important things you'd add or change with more time?

Section B — Production Ownership

Part B1 — Incident Runbook: Two weeks after your DLP rules go live on the partner-fulfillment-export channel, the rule starts blocking the legitimate weekly redemption-file transfer to the fulfillment vendor — delaying reward shipments to real platinum-tier members. Write a runbook for the on-call responder who gets the alert. Include at least 3 concrete, actionable steps. The first step should not be "escalate to the policy author."

Part B2 — AI Reasoning (complete without AI assistance): Describe a scenario where an AI assistant would give you a plausible but incorrect classification scheme or DLP/encryption design for this kind of multi-brand data estate — and explain specifically how you would catch it before relying on it.

Section C — AI Usage Log (Mandatory)

This is not a trick. We want to see how you work with AI — not whether you used it. For each significant interaction with an AI tool, briefly note: what you asked the AI to help with / what it gave you / what you kept, changed, or rejected — and why. Three interactions documented is sufficient.

Format: .mp4, .mov, .webm

Record as MP4 or MOV and upload directly on the Provn platform as a separate file. Structure your video as follows:

1. Summary (60 seconds): The problem, your approach, and your recommendation in one minute
2. Design walkthrough (3–4 minutes): Walk through your classification scheme, your DLP/DSPM and cryptography/key-management design, and one key trade-off you made
3. AI data governance & Section B walkthrough (2 minutes): Walk through your AI data governance design, your incident runbook (Part B1), and your AI reasoning answer (Part B2)
4. Mandatory AI question (1–2 minutes): Walk me through one moment where you disagreed with, pushed back on, or redirected what the AI gave you — and what you did instead. Name the specific moment. Explain what the AI produced that didn't meet the bar, what you did differently, and why.
5. Reflection (30–60 seconds): What would you do differently or add with more time?

Speak naturally, as if briefing your CIO directly. Communication is assessed on clarity of technical ideas and logical structure for a broad audience — not verbal polish, accent, or filler words.