Unit 06 · Chapter 4 · 10 min read

Privacy, payment data, and secure evidence

Protect the information that makes risk decisions possible.

The fraud team wants more data. The security team wants fewer copies. Both can be right. The design task is to make useful evidence available to the right control without turning every log into a customer dossier.

Map data to a purpose

A data inventory should state what is collected, why it is needed, where it moves, who can access it, and how long it remains. Separate required records from optional analytical data. The relevant privacy and security duties depend on the entity, product, and jurisdiction.

Use purpose-limited datasets and documented access. A fraud feature pipeline may need a count or token rather than a raw document. Challenge new fields at the point of collection, when removal is easiest. Once a sensitive field enters logs, exports, and backups, reducing its spread becomes much harder.

Data minimization is an architecture choice. If a decision needs to know whether a credential passed a check, it may not need to copy the raw credential into every downstream event. A purpose-built reference or limited assertion can reduce exposure while preserving the evidence necessary for review. The design must still account for who can retrieve the underlying material and under what conditions.

Logs deserve particular attention because they often collect information outside the intended product database. Error messages, debugging payloads, screenshots, and support exports can create secondary stores of sensitive data. Apply data classification and access rules to these paths. A secure primary database does not compensate for unrestricted copies in ordinary operational tools.

Map data to a purpose Map data to a purpose — the flow Follow the sequence. Use minimum suitable data and retention. Collect Define the necessary purpose Route Map every consumer and copy Limit Use minimum suitable data and retention — Follow the sequence. Use minimum suitable data and retention. Chapter sources · Open image

Map data to a purpose Map data to a purpose — the distinction These concepts answer different questions. Read each definition in the context of the section. Raw evidence Detailed source material Derived feature Limited information for a defined decision — These concepts answer different questions. Read each definition in the context of the section. Chapter sources · Open image

Map data to a purpose Data-purpose map Fictional teaching record. No raw document needed. Data-purpose map Illustrative data; not a real customer record or a prescribed policy. Raw document identity vault Restricted proofing use Feature verified status Decision use Analytics aggregate completion No raw document needed Many controls need a result rather than raw evidence — Fictional teaching record. No raw document needed. Chapter sources · Open image

Map data to a purpose Map data to a purpose — control and failure modes Many controls need a result rather than raw evidence. The branches show why alternative designs fail. Control design Use the least detailed data that meets the purpose. Many controls need a result rather than raw evidence. Failure mode 1 Collect everything for possible future use. That expands exposure without a defined need. avoid Failure mode 2 Ignore exports. Copies remain part of the data system. avoid Failure mode 3 Treat a token as automatically anonymous. Linkability and access still matter. avoid — Many controls need a result rather than raw evidence. The branches show why alternative designs fail. Chapter sources · Open image

Keep payment secrets out of ordinary systems

PCI DSS provides security requirements for environments that store, process, or transmit payment account data, with scope determined by the actual environment and applicable requirements. Tokenization and hosted collection can reduce exposure but do not automatically remove every responsibility.

Map where account data can enter: forms, logs, support attachments, webhooks, analytics, and error traces. Redact at the source. Do not store sensitive authentication data such as card verification codes after authorization where prohibited. Verify the actual integration rather than relying on a vendor badge as proof that your application cannot leak data.

Keep payment secrets out of ordinary systems Keep payment secrets out of ordinary systems — the flow Follow the sequence. Check logs support and failure paths. Capture Use the approved payment-data path Tokenize Pass references to downstream systems Verify Check logs support and failure paths — Follow the sequence. Check logs support and failure paths. Chapter sources · Open image

Keep payment secrets out of ordinary systems Keep payment secrets out of ordinary systems — the distinction These concepts answer different questions. Read each definition in the context of the section. Tokenized workflow Reduces direct account-data handling Zero responsibility Not implied by using a token provider — These concepts answer different questions. Read each definition in the context of the section. Chapter sources · Open image

Keep payment secrets out of ordinary systems Logging boundary Fictional teaching record. No card secret payload. Logging boundary Illustrative data; not a real customer record or a prescribed policy. Payment form hosted collection Approved capture path Application event payment token Reference only Error log redacted No card secret payload Failure logs and support tools are common overlooked routes — Fictional teaching record. No card secret payload. Chapter sources · Open image

Keep payment secrets out of ordinary systems — control and failure modes

Control design

Verify every path that can expose payment data. Failure logs and support tools are common overlooked routes.

Failure mode 1avoid: Log full request bodies by default. They can contain sensitive data.
Failure mode 2avoid: Store verification codes for later convenience. Post-authorization storage can be prohibited.
Failure mode 3avoid: Assume a vendor badge proves your scope. Your implementation still matters.

Failure logs and support tools are common overlooked routes. The branches show why alternative designs fail. Chapter sources · Open image

Use least privilege and separation

Least privilege gives a role the access required for its task. Separation of duties prevents one actor from controlling every part of a sensitive operation. Apply both to customer evidence, rule changes, manual payouts, and restricted-fund releases.

Use server-side authorization and periodic access review. Time-bound elevated access should have a reason, approval, and audit trail. Monitor service accounts as well as people. A broadly privileged automation token can bypass careful human permissions. Test that removed roles lose access in active sessions and downstream tools.

Use least privilege and separation Use least privilege and separation — the flow Follow the sequence. Remove access when the need ends. Role Define the permitted task Grant Limit scope and duration Review Remove access when the need ends — Follow the sequence. Remove access when the need ends. Chapter sources · Open image

Use least privilege and separation Use least privilege and separation — the distinction These concepts answer different questions. Read each definition in the context of the section. Role membership Named access assignment Effective access What the actor can actually do across systems — These concepts answer different questions. Read each definition in the context of the section. Chapter sources · Open image

Use least privilege and separation Access review Fictional teaching record. Bounded exception. Access review Illustrative data; not a real customer record or a prescribed policy. Analyst case evidence read Task-specific scope Payout release not permitted Separate authority Temporary access expires today Bounded exception Named roles can hide broader actual permissions — Fictional teaching record. Bounded exception. Chapter sources · Open image

Use least privilege and separation Use least privilege and separation — control and failure modes Named roles can hide broader actual permissions. The branches show why alternative designs fail. Control design Test effective access including service accounts. Named roles can hide broader actual permissions. Failure mode 1 Rely only on hidden buttons. Server actions still need enforcement. avoid Failure mode 2 Keep temporary access forever. The original need can expire. avoid Failure mode 3 Ignore automation credentials. They can carry high-impact authority. avoid — Named roles can hide broader actual permissions. The branches show why alternative designs fail. Chapter sources · Open image

Define retention deletion and legal holds

Retention should follow applicable duties and approved purpose. A deletion request, account closure, or policy expiry can trigger different handling depending on legal requirements and holds. Implement the decision as a recorded workflow.

Map deletion across primary stores, search indexes, caches, exports, and backups. Some systems remove data through scheduled expiry rather than immediate physical deletion; document the behavior accurately. A legal hold should be scoped and reviewed, not used as a universal reason to keep everything forever. Preserve evidence that the lifecycle action completed as designed.

Deletion is not a single database command. A record can exist in indexes, derived features, object storage, backups, provider systems, and review exports. Map those copies and define how retention, legal holds, and deletion apply to each. A legal hold may suspend normal deletion for relevant evidence, while unrelated data can remain subject to its ordinary schedule. Keep an auditable record of the decision and execution without retaining the very sensitive content that the deletion was intended to remove.

Define retention deletion and legal holds Define retention deletion and legal holds — the flow Follow the sequence. Track the action across all copies. Classify Determine the record and applicable retention Decide Apply expiry request or legal hold Execute Track the action across all copies — Follow the sequence. Track the action across all copies. Chapter sources · Open image

Define retention deletion and legal holds Define retention deletion and legal holds — the distinction These concepts answer different questions. Read each definition in the context of the section. Account closure Ends a product relationship Record deletion Separate lifecycle action under applicable rules — These concepts answer different questions. Read each definition in the context of the section. Chapter sources · Open image

Define retention deletion and legal holds Retention workflow Fictional teaching record. Separate purpose and lifecycle. Retention workflow Illustrative data; not a real customer record or a prescribed policy. Customer account closed Relationship event Required records retained under policy Defined duty Optional analytics scheduled deletion Separate purpose and lifecycle Closure does not imply one rule for every record — Fictional teaching record. Separate purpose and lifecycle. Chapter sources · Open image

Define retention deletion and legal holds — control and failure modes

Control design

Treat retention as a scoped auditable workflow. Closure does not imply one rule for every record.

Failure mode 1avoid: Delete required evidence indiscriminately. Some duties require retention.
Failure mode 2avoid: Keep all data under a vague legal hold. Holds need scope and review.
Failure mode 3avoid: Forget search and exports. The record can remain exposed elsewhere.

Closure does not imply one rule for every record. The branches show why alternative designs fail. Chapter sources · Open image

Design secure incident evidence

Security incidents need reliable logs, timestamps, affected-system records, and containment evidence. Logs should help establish what happened without unnecessarily exposing customer secrets. Protect integrity and access to the incident record.

Plan for breach assessment and notification duties under the applicable framework. Do not assume every incident has the same clock or audience. Coordinate security, legal, compliance, operations, and customer support. Preserve the distinction between confirmed access, possible exposure, and actual misuse so communications remain accurate as the investigation develops.

Design secure incident evidence Design secure incident evidence — the flow Follow the sequence. Apply the relevant notification and remediation process. Contain Limit ongoing access or leakage Establish facts Preserve reliable incident evidence Respond Apply the relevant notification and remediation process — Follow the sequence. Apply the relevant notification and remediation process. Chapter sources · Open image

Design secure incident evidence Design secure incident evidence — the distinction These concepts answer different questions. Read each definition in the context of the section. Possible exposure Data may have been accessible Confirmed misuse Evidence shows a harmful use — These concepts answer different questions. Read each definition in the context of the section. Chapter sources · Open image

Design secure incident evidence Incident fact register Fictional teaching record. Uncertainty remains. Incident fact register Illustrative data; not a real customer record or a prescribed policy. System restricted evidence store Potential scope Access confirmed unauthorized Known fact Exfiltration not yet established Uncertainty remains Incident claims must track the evidence — Fictional teaching record. Uncertainty remains. Chapter sources · Open image

Design secure incident evidence Design secure incident evidence — control and failure modes Incident claims must track the evidence. The branches show why alternative designs fail. Control design Separate confirmed facts from unresolved scope. Incident claims must track the evidence. Failure mode 1 Publish a complete-loss claim immediately. The investigation may not support it. avoid Failure mode 2 Log secrets to improve debugging. That creates another exposure. avoid Failure mode 3 Use one notification rule for all incidents. Requirements depend on facts and jurisdiction. avoid — Incident claims must track the evidence. The branches show why alternative designs fail. Chapter sources · Open image

Chapter connections

This chapter builds on Fair lending, explainability, and adverse action. Continue with Sponsor banks, vendors, and third-party risk to follow the next part of the system. Use the glossary for terminology and risk mathematics for formulas and worked calculations.

Sources

Reviewed 2026-09-17