‹ All interview questions

Security

Your organization discovered that user PII from the sys_user table is being exposed to unauthorized users…

Senior · ServiceNow · Feb 2026

The question

Your organization discovered that user PII from the sys_user table is being exposed to unauthorized users through a vulnerability in Access Control Lists (ACLs). The sys_user data is synchronized nightly from your corporate SSO system. You need to implement a data privacy strategy that protects PII in non-production environments while maintaining system functionality. Walk me through your diagnostic approach, explain the trade-offs between anonymization and deletion, and describe what happens if you anonymize sys_user records that are actively synchronized by SSO.

The Real Question

This scenario tests whether candidates understand the interconnected nature of data privacy, identity management, and system integration in production environments. The core challenge isn't just implementing anonymization—it's recognizing that sys_user data has unique constraints because SSO resynchronization can undo anonymization efforts, creating a false sense of security.

A great answer demonstrates three critical diagnostic steps: First, identify that the vulnerability is an ACL misconfiguration allowing unauthorized access. Second, recognize that sys_user anonymization alone is insufficient because SSO will resynchronize user records nightly, restoring the original PII. Third, understand that the real solution requires layered controls: fixing ACLs, implementing data classification before anonymization, and addressing the SSO resynchronization risk.

The Solution

The real toolset (don't invent APIs): First fix the read ACLs on the sensitive sys_user fields (System Security > Access Control, verified with Debug Security Rules and impersonation). For protecting PII in non-production, use platform capabilities rather than custom anonymizer scripts: exclude or scrub sensitive tables as part of the instance clone process (clone excludes and data preservers/cleanup scripts), and, if licensed, ServiceNow's Data Privacy / data anonymization tooling to classify and de-identify PII fields. Hand-rolled anonymization scripts routinely miss journal entries, attachments, and audit shadows.

Senior Considerations

  • Root Cause vs. Symptom: Fixing ACLs is the immediate mitigation, but anonymization alone won't prevent future exposure if SSO resynchronizes data. Candidates should discuss implementing a 'no resync' flag or excluding non-prod from SSO synchronization entirely.
  • SSO Resynchronization Risk: Great answers acknowledge that anonymized data loses permanency when integrated with external identity systems. There is no mechanism to ensure de-identification permanency while SSO keeps resynchronizing the same records, making this a critical architectural consideration.
  • Trade-off Analysis: Anonymization preserves data structure for testing but is reversible through SSO. Deletion is permanent but breaks dependent processes and testing scenarios. The superior approach is environment separation: exclude non-prod from SSO sync, then anonymize freely.
  • Data Classification First: Candidates should explain that classification must precede anonymization. Unstructured data (attachments, journal entries) cannot be anonymized, so classification determines what can actually be protected.
  • Structured vs. Unstructured Data: sys_user has both: structured fields (email, phone) and unstructured (comments, attachments). A complete solution addresses both, not just the easy part.
  • Testing Strategy: Mention validating anonymization in a clone of non-prod before production implementation, and defining success metrics (verify PII removal, confirm system functionality, test SSO behavior post-anonymization).
  • Compliance Documentation: Senior architects document the decision rationale—why this approach meets compliance requirements while acknowledging the SSO resynchronization gap—and define monitoring to detect if SSO inadvertently restores PII.