Data Classification, Privacy, and Protection Requirements

The refund console inventoried in Chapter 5 records a reason for each refund. In the primary database, that reason sits beside a customer identifier and transaction. It also travels through a queue, appears in an operator audit event, enters a support case, reaches a report export, and survives in backups. One proposed analytics job would copy it again. A later proposal would send support cases to a hosted model for summarization.

Calling the database “encrypted” answers almost none of the resulting questions. Which people may read the reason? May it appear in logs? How long may the support copy live? Can an analyst export it? Must deletion reach the backup? May the model provider retain a prompt containing it?

Classification turns the inventory into those decisions. It is useful only when every material copy inherits enforceable rules for access, movement, use, retention, and disappearance.

Classify the harm, then the handling

A workable scheme uses few enough labels that an engineer can predict their consequences. This is a baseline; an organization may rename the levels, but each name must lead to a defined handling rule.

“Regulated” adds obligations; it does not reduce the base class. Payment, health, identity, communications, employment, or location data may require particular processing, residency, retention, evidence, or response depending on jurisdiction, contract, and use. Apply the stricter of the handling class and the applicable obligation. Obtain qualified privacy or legal review for the obligation; engineering remains responsible for making it enforceable.

Secret-equivalent operational material deserves the restricted posture even when it is not a credential. Break-glass procedures, signing workflows, exploitable incident detail, sensitive detection logic, and unreleased response plans can give an adversary much of the advantage a secret would.

Format is weak evidence of harm. A customer number may be modestly sensitive by itself and highly sensitive when it links a person to a medical claim. A stable device identifier or rare location pattern can remain identifying after direct names are removed. Aggregates, predictions, risk scores, embeddings, and other derived data need their own assessment: derivation can reveal or concentrate information rather than sanitize it.

For each data type, consider four failures separately:

• Disclosure: who is harmed when an unauthorized party reads it?
• Modification: what money, access, safety, entitlement, or evidence can be changed if it is corrupted?
• Unavailability: which operation or recovery promise fails when it cannot be retrieved?
• Misuse: what harm follows when validly collected data is retained, combined, inferred from, or used for another purpose?

The confidentiality class sets a minimum handling posture. Integrity, availability, use, and regulatory obligations can add controls. A public software release manifest, for example, needs little confidentiality but strong integrity. A restricted audit trail needs both tight reading access and protection against alteration.

Follow one value through every copy

Start with the inventory rather than a blank classification form. For the refund reason, trace collection at the console, transmission through the API and queue, processing by the worker, storage in the database, inclusion in telemetry, sharing through support and reporting, retention in backups, and eventual deletion. At every step, record the human or workload identity, purpose, boundary crossed, recipient, and owner.

The record should expose control decisions, not merely draw arrows:

Data: refund reason joined to customer and transaction identifiers
Class: confidential; restricted when free text contains credentials or high-risk personal data
Purpose: decide, explain, reconcile, and audit a refund
Authoritative store: commerce database
Material copies: work queue, dead-letter queue, operator audit event,
  support case, report export, analytics table, backup
Access: refund operators by case; supervisors for escalation; service identities
  by named operation; analysts receive minimized fields, not free text by default
Transmission: authenticated and encrypted across every network or third-party boundary
Logging: reason text excluded; event records actor, case, decision, amount band,
  outcome, policy version, and trace identifier
Retention: owner-approved schedule per copy; support and exports expire independently
Deletion: primary and searchable copies deleted or de-identified by workflow;
  backup expiry documented; restore procedure prevents deleted data from silently returning
Secondary use: analytics uses coded reason categories; hosted AI use denied pending review
Evidence: schema rules, access policy, export control, log test, retention job result,
  deletion reconciliation, backup configuration, and review approval

The highest class present usually governs a container until the fields are separated. One reset token in a support note makes the whole note restricted. An authorization header in a log event changes the log store’s exposure. If separation is practical, store or reveal sensitive fields through a narrower path instead of forcing every user of the larger record to receive them.

Copies include queues, dead-letter payloads, caches, reports, spreadsheets, screenshots, support tickets, temporary files, debug dumps, logs, traces, backups, test fixtures, analytics tables, prompts, outputs, embeddings, fine-tuning files, and evaluation sets. The weaker copy is often the actual control boundary.

Turn the class into requirements

Write requirements against each material copy. “Handle as confidential” is not implementable. The refund record produces decisions in nine areas.

Collection and processing. Collect the reason needed to decide and explain the refund, not an unrestricted biography of the customer. Prefer a coded reason with bounded free text. Validate that downstream jobs use it only for recorded purposes. Separate identifiers from attributes when the join is unnecessary.

Transmission. Internal data stays within authenticated, intended channels. Confidential and restricted data is encrypted across every network and third-party boundary, with peer identity verified. Restricted flows use approved protocols and configurations without an unreviewed downgrade or plaintext fallback.

Storage and keys. Confidential and restricted data is encrypted in primary stores, backups, and exports. Restricted stores use controlled keys and monitored administrative paths. Encryption does not compensate for a broad query role: database, key, and backup access are separate authorities and should be granted accordingly.

Human and workload access. Internal access may be group-managed. Confidential access requires a business purpose, owner-approved roles, and periodic review. Restricted access is individually attributable, narrowly scoped, time-bounded where practical, and logged. Support views reveal only the fields needed for the active case; elevated views require a reason and leave an audit event.

Limit secondary use and sharing

Sharing and export. Name the recipient, fields, purpose, destination, onward-sharing rule, retention, and revocation path before a confidential export leaves its governed store. Restricted or regulated exports require formal review and minimized, masked, or tokenized fields where those transformations preserve the task. A managed destination and expiry are part of the approval.

Analytics. Default to coded refund categories instead of free text. Restrict joins that increase identifiability, prevent unmanaged downloads, and review whether an aggregate can expose a small group or rare event. Approval follows the resulting dataset, not only its source tables.

AI use. Before real data enters a prompt, retrieval index, tool call, trace, evaluation set, or human review queue, document the data classes, authorized readers, model and tool boundaries, application and provider retention, deletion path, external actions, and output recipients. Test retrieval authorization against cross-user and cross-tenant requests. Restricted data is denied by default until isolation, access, retention, output, and contractual controls are approved. Use synthetic data while those answers are missing.

Retention and deletion. Give each copy a duration or event-based trigger, an owner, an enforced deletion mechanism, and evidence of its last successful run. A primary-record deletion is incomplete if searchable exports, support attachments, or vector indexes remain. Backups may expire on a documented rotation rather than support immediate record deletion, but restore procedures must prevent expired data from quietly becoming live again. Holds and other exceptions need authority, scope, and an end condition.

Recovery. Availability needs are explicit even for sensitive data. Define backup, restore, and integrity requirements from operational harm, then apply the same access, encryption, residency, retention, and audit controls to recovery copies. A backup that cannot be restored is not protection; a broadly readable backup is a second breach surface.

Make telemetry useful without copying the incident

The console needs enough evidence to reconstruct a refund: actor, subject or case identifier, action, policy or authorization result, time, trace identifier, amount band where useful, and outcome. It does not need the raw refund narrative, authentication header, session token, or full payment identifier.

Use field allowlists for security events. Redact before the event leaves the application, and test redaction with representative sensitive values. Never log passwords, API keys, private keys, recovery codes, session tokens, raw authorization headers, cookies, signed URLs, full payment data, or unnecessary personal data. Prefer credential identifiers, token issuers and safe subjects, failure reasons, last characters where permitted, and vault references.

Emergency diagnostic capture is an exception, not a new default. Record the approver, exact fields, destination, readers, start and expiry time, and purge method. Constrain sampling and access, then verify deletion. If a secret reaches telemetry, stop further capture, restrict or purge affected copies as policy permits, rotate the secret, and preserve the incident evidence needed to understand access.

Verify the journey, not the label

A release reviewer should be able to choose any protected data type and follow it from collection to disappearance. The evidence should include:

• classification rationale covering disclosure, modification, unavailability, misuse, and applicable obligations;
• a flow with sources, stores, processors, identities, recipients, boundaries, third parties, and every material copy;
• schemas or collection rules that demonstrate minimization and purpose;
• encryption and key configuration for primary, exported, and recovery copies;
• access policy, approval records, elevated-use audit events, and review results;
• automated tests proving forbidden fields do not enter logs and unauthorized users cannot retrieve protected records or embeddings;
• export, analytics, and AI-use decisions with destination and retention controls;
• retention-job results, deletion reconciliation, backup expiry, and restore behavior;
• an owned exception with compensating controls and expiry for any unmet requirement.

Classification is finished when an engineer can inspect a copy and know what controls it must have, how those controls are proven, and who must act when they fail. With the refund console’s data paths and handling rules visible, threat modeling can now ask a sharper question: how might an attacker or trusted user defeat them?