## Data Flow Diagram: Data Privacy Vault Access Control
### Overview
This diagram illustrates the architectural flow of sensitive data through a "Data Privacy Vault." It demonstrates how raw, tokenized data is ingested into a secure vault and subsequently retrieved by different organizational departments ("Support" and "Marketing") with specific, role-based redaction and masking policies applied to the output.
### Components
* **Input Data Block (Left):** A dark purple container holding a JSON object with tokenized/obfuscated values.
* **Access Control (Left):** A vertical, light-gray rectangular gateway positioned between the Input Data and the Vault.
* **Data Privacy Vault (Center):** A central, white-background rectangular box representing the secure storage and processing engine.
* **Access Control (Right):** A vertical, light-gray rectangular gateway positioned between the Vault and the output blocks.
* **Output Data Blocks (Right):** Two dark purple containers holding JSON objects, representing data retrieved by specific departments.
* **Support:** Labeled vertically to the right of the top output block.
* **Marketing:** Labeled vertically to the right of the bottom output block.
### Content Details
#### 1. Input Data (Left)
The input is a JSON object containing tokenized strings:
* `"full_name"`: `"98aav8dfyd"`
* `"ssn"`: `"8463528957154825"`
* `"dob"`: `"ad3420o23n434"`
* `"email"`: `"ko2390f32nf"`
#### 2. Output Data (Right)
The output is split into two distinct JSON objects based on the department requesting the data.
**Support Department Output (Top Right):**
* `"full_name"`: `"John D***"` (Partial name revealed)
* `"ssn"`: `"XXX-XX-3627"` (Partial SSN revealed)
* `"dob"`: `"*REDACTED*"` (Date of birth hidden)
* `"email"`: `"j***@gmail.com"` (Partial email revealed)
**Marketing Department Output (Bottom Right):**
* `"full_name"`: `"John Doe"` (Full name revealed)
* `"ssn"`: `"*REDACTED*"` (SSN hidden)
* `"dob"`: `"XXXX-05-17"` (Partial DOB revealed)
* `"email"`: `"john.doe@gmail.com"` (Full email revealed)
### Key Observations
* **Tokenization:** The input data is entirely obfuscated, suggesting that the application layer only handles tokens, not raw PII (Personally Identifiable Information).
* **Differential Redaction:** The "Access Control" layer on the right acts as a policy enforcement point. It applies different masking rules based on the requester:
* **Support** is granted access to partial identity and contact info, but not the date of birth.
* **Marketing** is granted access to the full name and email, but not the SSN.
* **Flow Direction:** The diagram follows a strict left-to-right progression: Ingestion (Tokenized) -> Vault -> Policy Enforcement -> Role-Specific Output.
### Interpretation
This diagram demonstrates a **Data Privacy Vault architecture**, a security pattern used to decouple sensitive data from business applications.
The "Data Privacy Vault" acts as the single source of truth for PII. By storing the mapping between the tokenized input (seen on the left) and the actual data, the vault allows the organization to maintain security while still providing necessary information to downstream systems.
The "Access Control" layers are critical here; they represent the implementation of **Attribute-Based Access Control (ABAC)** or **Role-Based Access Control (RBAC)**. The diagram highlights that security is not "all or nothing." Instead, it is granular: the system dynamically masks or reveals specific fields based on the "need to know" of the requesting department. This minimizes the risk of data exposure by ensuring that no single department has access to the full, unredacted dataset unless explicitly authorized.
