Masking PII in Audit Logs
When forwarding audit or troubleshoot logs to an external connector (such as Cribl, Splunk, or Datadog), you can enable Mask PII Data to automatically obscure personally identifiable information before it leaves Descope. This lets you send logs to third-party platforms without exposing raw user data.
Enabling Mask PII Data
Configure this setting per connector when setting up or editing an audit connector in the Descope Console. Enable the Mask PII Data toggle in the connector configuration panel.
What gets masked
Masking applies to two parts of each log record:
- externalIDs — the login identifiers associated with a user (emails, phone numbers)
- data — custom key-value fields whose field name matches a known PII pattern
Descope identifies PII fields by name (case-insensitive):
| If the field name contains… | Masking applied |
|---|---|
email, e-mail, mail, sentTo | Email masker |
phone, mobile, telephone, tel | Phone masker |
name, first_name, last_name, full_name, given_name, family_name, display_name, middle_name | Name masker |
external_id, externalid | Email or phone masker, depending on value format |
Substring Matching
Field names are matched using substring search (case-insensitive). This means short patterns like tel, mail, or name will also match unintended fields (e.g., tel matches hotel, telemetry, or intel). When adding custom fields to the data object, avoid using these substrings in field names unless you want them masked.
What does NOT get masked
The following fields remain in plain text regardless of the setting:
| Field | Examples |
|---|---|
| Internal Descope IDs | User IDs, Project IDs, Tenant IDs, Actor IDs |
| Timestamps | occurred |
| Action types | LoginSucceed, UserCreated |
| Authentication method | OTP, OAuth, Magic Link, etc. |
| IP address & geo data | remoteAddress, geo |
| Device information | Browser, OS, device type |
| Flow & execution metadata | Flow IDs, Execution IDs, Request IDs |
Any data field whose name does not match a PII pattern | Custom app metadata, feature flags, etc. |
Example
Here's an example audit record for a LoginSucceed event:
Without masking
{
"type": "LoginSucceed",
"userID": "U2ESG1VEKbTdXnKk1AX3",
"externalIDs": ["jane.doe@company.com", "+12025551234"],
"occurred": "2024-09-10T14:22:05Z",
"method": "otp",
"remoteAddress": "203.0.113.42",
"data": {
"full_name": "Jane Doe",
"plan": "enterprise"
}
}With masking enabled
{
"type": "LoginSucceed",
"userID": "U2ESG1VEKbTdXnKk1AX3",
"externalIDs": ["jan*****@com****.com", "+1*********1234"],
"occurred": "2024-09-10T14:22:05Z",
"method": "otp",
"remoteAddress": "203.0.113.42",
"data": {
"full_name": "J**e D**",
"plan": "enterprise"
}
}When To Mask PII Data
Enable Mask PII Data if:
- You must meet compliance requirements such as GDPR or HIPAA when sharing logs with third parties
- You are sending logs to an external vendor and want to minimize PII exposure
- Your analytics rely on action types, user IDs, or timestamps rather than raw email or phone values
Leave it disabled if:
- You need exact email or phone matching for fraud detection or alerting workflows
- You correlate log events by login identifier across multiple systems
- You need to identify and contact users directly based on audit log data