Support Notes Field Contains Full Card Numbers
A customer-support app on OutSystems has a free-text Case notes field used by 120 agents. A data-protection review sampled 500 cases and found 38 contained full credit-card numbers, 14 contained bank account numbers, and 9 contained health details. The notes are stored in a database table, displayed on the case screen, included in a nightly CSV export to a data warehouse, and written to application logs when an error occurs. The app has no retention rule; cases are kept indefinitely. Agents are told not to enter card data, but the field is used for pasted customer emails. The company processes payments through a PCI DSS Level 1 provider and wants to reduce scope; legal requires breach notification if card data is exposed. There are 12,000 open cases and 300,000 historical cases. The team can change the app and add a masking service, but cannot immediately change the data warehouse contract.
1. Identify the sensitive-data flows and the highest-risk exposure. What should be remediated first?
Read the worked answer
The flows are: notes stored in the database, rendered on the case screen, exported nightly to the warehouse, written to application logs on error, and copied into backups. The highest-risk exposure is likely the logs and the CSV export, because they spread full card numbers to systems with broader access and weaker controls, and logs are often retained and searched by many people. The UI is also high risk but at least stays within the support role. First contain: stop logging notes and error payloads, purge or restrict existing logs, and restrict the export. Then mask the UI and remediate stored data. Card numbers bring PCI DSS scope; bank and health data bring other obligations. Do not start with a nine-month warehouse redesign while full PAN is still flowing to logs.
2. Propose a remediation plan that reduces PCI scope without immediately changing the warehouse contract.
Read the worked answer
Classify and scan notes with card-number and bank-account patterns, then sample and confirm. Redact or tokenize full PANs in historical and open cases in batches with an audit trail; replace with a token or masked last four. Keep the warehouse schema unchanged but send masked or tokenized values, so the contract still works; if the warehouse genuinely needs full values, route them through a tokenization service with restricted access. Mask the case screen for all but a small authorized role. Add retention: close cases purge notes after the defined period, with legal-hold exceptions. Prevent re-entry with input validation that rejects PAN patterns, a warning, and log sanitization. Monitor with DLP alerts and periodic sampling. Record the prior exposure for legal assessment.
3. How do you prevent re-introduction, and what evidence proves the fix?
Read the worked answer
Prevent re-introduction with layered controls: field validation that rejects card-number patterns, UI guidance, log redaction at the logging layer, export policy that only allows masked values, data classification on the notes field, and code review for any new export or log statement. Agents should not be the only control. Evidence: before-and-after scans of open and historical cases with counts, a sample export showing no full PAN, log review showing redacted errors, retention job logs, access review for the masking service, and DLP alerts tested with a synthetic card number. Also show that the warehouse received masked values and that backups follow the same retention. If any full PAN remains, document the residual risk and owner.