The city payment form already receives a processor token after card settlement, but the app still stores full card PANs in DynamoDB "for convenience." What is the correct data-minimization action?
Select an answer to reveal the explanation.
Short Explanation
If the processor already handed you a token, clinging to the full PAN is keeping the spare house key under the mat after the locksmith finished. Drop the PAN; keep the token.
Full Explanation
Once a city payment form already receives a processor token after card settlement, retaining full primary account numbers in DynamoDB for convenience violates data minimization. The correct action is to stop retaining full PANs, keep processor tokens or references needed for refunds and reconciliation, and delete unnecessary card data. Municipal payment applications reduce breach blast radius when the city vault stores references the processor understands rather than raw card numbers the city no longer needs to process charges.
Replicating full PANs into CloudWatch Metrics as custom dimensions fails because metrics systems become yet another store of card data and are often widely readable. Encrypting PANs with a publicly shared password so any microservice can decrypt without KMS fails conceptually—shared passwords are not least-privilege cryptography and encourage unnecessary retention. Printing PAN lists to nightly PDF reports on unencrypted EBS fails because it creates cleartext secondary copies outside the minimized store.
Exam caveat: tokenization does not remove obligations for any PAN remnants still in logs, backups, or support exports; purge those paths too. Operational check: query DynamoDB and backups for PAN-shaped attributes, confirm only processor tokens remain for settled payments, and verify report jobs no longer render full card numbers.