Review customer contact SQL change

[prantikmedhi]

Summary

• expand the sample customer contact query to include realistic sensitive fields
• add a short demo voiceover script for the three-minute walkthrough
• create a PR that exercises the MetaReview comment flow against a believable SQL diff

Test plan

• Open the PR and confirm the MetaReview workflow starts automatically
• Check that the review comment calls out sensitive fields from the SQL diff
• Review workflow logs if the action needs environment secrets or metadata access

[github-actions]

🛡️ MetaReview Data Risk Scan

Risk Level	Score
🟡 MEDIUM	6.0/10

Verdict: Requires immediate attention to PII handling and access controls.

Summary

This Pull Request introduces examples/customer_contact_review.sql. The SQL snippet indicates the selection of sensitive customer contact information, including customer_full_name, phone_number, ssn, and credit_card, filtered by non-null email and phone_number.

Risks

• Medium Risk (Score 6.0): The primary concern is the direct exposure of multiple highly sensitive PII fields (credit_card, email, phone_number, ssn).
• Data Security: Directly querying and potentially exposing these PII fields increases the risk of unauthorized access, data breaches, and misuse if not managed with stringent security protocols.

Impact

• Data Governance: Introduction of an asset containing these specific PII types requires strict adherence to existing data governance policies for sensitive data, including data access, retention, and usage.
• Compliance: Depending on the data's jurisdiction and purpose, this could have significant compliance implications (e.g., GDPR, CCPA, PCI DSS).
• Security Posture: Increases the overall security burden and potential attack surface for sensitive customer data within the platform.

Recommended Action

1. Justification: Provide a clear and documented business justification for selecting each specific PII field (credit_card, ssn, email, phone_number) within this particular asset.
2. Access Controls: Confirm and document that granular access controls are implemented for examples/customer_contact_review.sql to ensure only authorized personnel or systems with a legitimate need can access this sensitive data.
3. Data Minimization: Evaluate if data masking, tokenization, or hashing can be applied to fields like credit_card and ssn if the full, unmasked values are not strictly required for the asset's intended purpose.
4. Data Catalog Documentation: Ensure this new asset is fully documented in the data catalog, explicitly noting the sensitive PII it contains and its designated purpose.