Overview
The Data Breach workflow is organized around two primary components: PII Detection and PII Entity Extraction. The purpose of this use case is to help reviewers identify personally identifiable information in source documents and then extract the underlying entities in a structured form for downstream review, validation, and reporting.Use Case Scope
The Data Breach workflow supports document review scenarios where teams need to find sensitive information quickly, understand what types of PII are present, and convert findings into structured entities that can be acted on consistently. This two-stage approach is useful because detection answers whether sensitive data exists, while entity extraction answers what specific values and categories were found.Core Components
PII Detection
PII Detection is the first review layer in the Data Breach workflow. Its role is to scan the submitted content and determine whether PII is present, where it appears, and how it should be categorized for reviewer attention. In practice, this component should help users triage large sets of documents by surfacing sensitive-content indicators before deeper extraction and validation take place.Typical reviewer actions
- Open the Data Breach workflow and submit or select documents for review
- Run PII Detection against the available content
- Review detection results in the interface, including any highlighted or tagged content spans
- Filter or prioritize documents based on presence and concentration of sensitive data
- Move high-value or high-risk findings into entity extraction for structured review
Typical detection categories
Common PII categories can include names, addresses, phone numbers, email addresses, government-issued identifiers, dates of birth, account numbers, or other identifiers that can be used to identify an individual. The exact taxonomy used in the product should follow the labels exposed in the UI and any internal policy definitions adopted by the review team.PII Entity Extraction
PII Entity Extraction is the second review layer. After the system detects relevant sensitive content, this component extracts the actual values and presents them as structured entities for validation and downstream workflows. Structured extraction is especially important in breach review because teams often need more than a binary PII indicator; they need normalized fields that support analysis, reporting, deduplication, and remediation activities.Typical reviewer actions
- Open a document or result set that has already been processed for PII Detection
- Review extracted entities grouped by type or source location
- Validate the extracted values and correct any false positives or formatting issues
- Use extracted entities to support incident analysis, quality control, and reporting
- Export or hand off validated entities for operational follow-up
Expected extraction outputs
Depending on the configuration exposed in the UI, extraction outputs may include:- Entity type, such as person name, email address, phone number, postal address, or account identifier
- Extracted value as it appears in source content
- Confidence, status, or reviewer validation state
- Source location metadata, such as page, section, document, or snippet reference
- Review notes or tags for downstream workflow handling
Suggested User Flow
- Enter the Data Breach workspace and load the target documents or records.
- Run PII Detection to identify records containing sensitive information.
- Review flagged content and prioritize documents that require deeper analysis.
- Run PII Entity Extraction to capture the specific sensitive values in structured form.
- Validate extracted entities and prepare the reviewed output for reporting or next-step remediation.