Those data classes create different regulatory questions and therefore different proof requirements. Trading data raises market-conduct concerns, customer data raises privacy and fair-lending issues, and training data raises lineage and reproducibility issues. If all three are governed the same way, the evidence will be too generic to answer the examiner’s actual question.
Why the control set has to follow the data class, not the department
Financial institutions do not govern trading data, customer data, and model-training data the same way because each one carries a different business duty, different evidence standard, and different failure mode. The right control set has to prove the institution can meet the exact question regulators, auditors, and internal risk owners will ask about that data class, not a generic “secure data” answer.
Trading data usually has to support market integrity, surveillance, retention, and access traceability. Customer data has to support privacy, consent, purpose limitation, and fairness obligations. Model-training data has to support provenance, reproducibility, and leakage control, because the institution may need to explain what entered the model and whether the dataset was fit for the intended use.
That is why one evidence package cannot cleanly satisfy all three. A control can be strong and still be the wrong control if it cannot show the specific handling, retention, lineage, or access logic demanded by the underlying data class. Institutions that flatten these distinctions often end up with controls that look comprehensive but fail the actual exam question.
How trading, customer, and training data diverge in practice
Trading data is usually judged through a conduct and supervision lens. The institution needs records that are timely, complete, tamper-evident, and available for monitoring, dispute resolution, and regulatory reconstruction. A simple “data is encrypted” statement does not answer whether trades can be reconstructed, reviewed, or supervised.
Customer data is different because the central issue is not only protection, but lawful use. Privacy obligations, retention limits, and data minimization matter, and fair-lending or discrimination concerns can surface when customer attributes influence downstream decisions. Strong EU General Data Protection Regulation (GDPR) controls help when the question is whether the institution can justify collection, processing, and security of personal data.
Model-training data introduces another layer: the institution must show where the data came from, whether it was licensed or permitted, how it was transformed, and whether the training set can be reproduced or audited later. For that reason, lineage, dataset versioning, and controls over feature sources matter more than they would for ordinary operational storage. This is also where training contamination or secret leakage can become a direct governance problem, not just a technical one.
What controls and evidence each data class usually needs
Different data classes require different proof artifacts. Trading data usually needs surveillance logs, retention schedules, immutability or write-once handling where appropriate, and access records that show who could see or alter the record. Customer data usually needs classification, privacy impact review, access restriction, and evidence that sharing decisions followed policy and legal basis. Training data usually needs dataset manifests, source approvals, lineage records, and controls that show sensitive inputs were excluded or masked when required.
For model-training data, the control question is often whether the dataset can be re-created and defended. That means the institution should be able to show source inventory, transformation logic, labelling rules, and approval history. The stronger the use case, the more important it becomes to prove that the dataset was controlled before training, not only protected after the fact.
Trading and customer records can sometimes share infrastructure, but they should not share evidence assumptions. A surveillance record and a consent record are not interchangeable, even if both live in the same storage platform. The institution needs control design that preserves the business meaning of the record, not just the file’s technical integrity. Controls for cloud handling and identity scope are easier to defend when they are aligned to that record purpose, as reflected in CSA Cloud Controls Matrix guidance on IAM and data security domains.
Risk and Threat Considerations
When institutions treat these data classes as the same, the biggest risk is mismatched evidence. That can leave a firm unable to prove market supervision, unable to justify personal-data use, or unable to explain how a training set was assembled and governed. The control may exist, but it will not answer the examiner’s actual question.
Failure mechanism: A generic control framework collapses distinct data obligations into one evidence pattern, so the institution collects logs and approvals that do not match the regulatory or model-governance issue being tested.
Impact: Supervisory findings, remediation work, and loss of trust can follow, especially when the firm cannot reconstruct trading activity, justify customer-data processing, or prove training-data lineage.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 sets the technical controls, while GDPR and ISO/IEC 27001:2022 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| GDPR | Art.5 — Principles Relating to Processing of Personal Data | Customer data handling hinges on lawful purpose, minimisation, and accountability. |
| Art.25 — Data Protection by Design and by Default | Customer-data workflows need privacy controls built into collection and use decisions. | |
| Art.32 — Security of Processing | Customer-data protection requires appropriate technical and organisational safeguards. | |
| Recommendation — Map customer-data controls to Art.5 principles and retain proof of lawful, limited processing. Embed privacy-by-design into customer-data pipelines and document default restrictions. Apply Art.32 controls to customer data and retain evidence of appropriate security measures. | ||
| NIST SP 800-53 Rev 5 | AU-11 — Audit Record Retention | Trading records need durable audit evidence for reconstruction and supervision. |
| AU-6 — Audit Record Review, Analysis, and Reporting | Trading data governance depends on reviewable monitoring evidence. | |
| AC-6 — Least Privilege | All three data classes need role-specific access limits to reduce exposure. | |
| Recommendation — Retain trading records long enough to support reconstruction and supervisory review. Review trading logs for anomalies and preserve the reporting trail for oversight. Restrict access to each dataset by role and business need. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Different data classes require different access rules and approvals. |
| A.5.34 — Privacy and protection of PII | Customer data requires privacy-specific controls and documentation. | |
| A.8.24 — Use of cryptography | Sensitive trading, customer, and training data often needs cryptographic protection. | |
| Recommendation — Define access rules per data class and enforce them consistently. Apply privacy controls to customer data and keep evidence of how PII is protected. Use cryptography where it protects the data class without replacing governance evidence. | ||
Practitioner Guidance
What to verify: For each data class, verify that the control owner can produce the exact proof the reviewer would ask for, for example trade reconstruction evidence for trading data, lawful-processing evidence for customer data, and source lineage for training data. If the same artifact is being reused everywhere, the control design is probably too broad.
What good looks like: The institution maintains separate evidence narratives by data class, even when the underlying platform is shared. That usually means one set of controls for supervision and retention, one for privacy and fairness, and one for lineage and reproducibility.
Practitioner takeaway: The key decision is not how to secure the storage layer, but how to prove the right obligation for the right dataset. If the evidence cannot answer the exact regulatory or governance question, the control is mis-scoped.
Related resources from NHI Mgmt Group
- Should financial institutions prioritise customer rights handling or data security controls first under DPDPA?
- How should financial institutions use trusted third-party TIN data without weakening CIP controls?
- What breaks when AI model metadata and training data checks are not wired into governance controls?
- How should financial institutions contain a breach when an employee email account is compromised and sensitive customer data may have been exposed?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 12, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org