Best Practices and Compliance Procedures

These recommendations help you operate the Data Sensitivity module effectively and maintain a strong compliance posture. The first three sections cover data hygiene practices that reduce PII exposure in your environment. The final section describes how to submit a Data Subject Access Request (DSAR) for processing.

Input fields should not contain PII

To comply with data protection regulations, please ensure that free-text input fields (such as description, notes, and comment fields) do not contain personally identifiable information (PII). This includes names, email addresses, phone numbers, national ID numbers, or any other data that could directly or indirectly identify an individual. Storing PII in unstructured fields makes it significantly harder to honor data subject rights and may create compliance obligations that are difficult to fulfill. We recommend reviewing your data entry workflows and applying appropriate data minimization practices before inputting records.

Table names and schema names should not contain PII

Table names, schema names, and other structural metadata should not include personally identifiable information. For example, avoid naming a table after a specific customer, employee, or individual (e.g., john_doe_records or user_12345_data). Metadata such as object names is often stored in system logs, audit trails, and monitoring tools where standard data protection controls may not apply. Using PII in these identifiers can inadvertently expose sensitive information and complicate your ability to respond to data subject access or deletion requests.

Create views for tables with names that contain PII

If your existing tables have names that include personally identifiable information, we recommend creating views that expose the same data under anonymized or abstracted names. This allows downstream consumers, reporting tools, and integrations to reference the view rather than the underlying table, reducing the surface area where PII-bearing identifiers appear in logs, query history, and audit trails. Migrating references to views also makes it easier to rename or restructure the underlying tables in the future as part of a broader data hygiene effort, without breaking dependent workflows.

Data Subject Access Requests (DSAR) manual request procedure

If you receive a Data Subject Access Request (DSAR) (a request from an individual to access, correct, or delete their personal data held within your account) please submit a request to your Bigeye representative. Our team will work with you to identify and retrieve the relevant data within the legally required timeframe. Please include as much context as possible in your request, such as the data subject's identifier and the scope of data involved, to help us process it efficiently. Note that response times may vary depending on the complexity and volume of data involved.