Teams should keep databases focused on application records, not high-risk secrets or payment data. Plaintext passwords, credit card details, and large binary files create unnecessary exposure, complicate access control, and increase recovery effort. A safer pattern is to store only references or hashes where appropriate, use purpose-built systems for files, and limit retained sensitive data to what the business truly needs.
How teams should decide what never belongs in a database
A good rule is to treat the database as the system of record for business entities and operational references, not as the default vault for anything sensitive. The decision should be driven by blast radius, retention need, and whether the data can be substituted with a token, hash, pointer, or external system of record without breaking the business process.
That means teams should first ask what the database would expose if compromised, backed up, replicated, or queried by a broader set of operators than originally intended. If the answer includes durable secrets, regulated payment data, or bulk attachments that have no real need to sit beside application records, the safer choice is usually to keep them elsewhere and store only a reference or derived value in the database.
What data usually fails the “never store it here” test
The clearest exclusion candidates are credentials and other authentication material, because a database leak turns a single app compromise into immediate account abuse. Plaintext passwords never belong there, and even recoverable secrets should be evaluated carefully because the database often has wider access paths, broader replication, and longer backup retention than a dedicated secret store.
Payment card data is another strong exclusion case unless the business has a specific, controlled, and compliant reason to retain it. The same thinking applies to highly sensitive personal data, API keys, private signing material, and large file blobs that are not actually part of a transactional record. If the application only needs to look up the item, store a pointer, checksum, or surrogate key instead of the raw content.
For file content, the main issue is not only confidentiality but operational gravity. Large binaries increase backup time, restore complexity, and database growth, and they make routine maintenance more expensive than a purpose-built object store or content service. That trade-off is usually a sign the database is being asked to do two jobs at once.
How to make the storage decision in practice
Start with a simple classification question: would exposing this field create direct harm, and does the application truly need the raw value to function? If the answer is yes to harm and no to raw necessity, do not store it in the database. Use a tokenized, hashed, encrypted, or externally hosted form only when that alternative still satisfies the use case.
Then check lifecycle behavior. Some data becomes problematic not because it is sensitive in isolation, but because it lingers across replicas, backups, analytics exports, and test environments. If a field cannot be deleted, rotated, or re-created cleanly, it is often too risky to keep inline with ordinary application records.
Also separate “can be stored” from “should be stored.” Databases are good at structured records, search, joins, and transactional consistency. They are poor places to accumulate secrets, long-lived high-value payloads, or objects whose access rules differ sharply from the rest of the schema. Purpose-built systems usually handle those cases better.
Risk and Threat Considerations
Databases amplify the impact of sensitive-data mistakes because one compromise can expose live records, backups, replicas, and administrative exports at once. The most dangerous pattern is storing data that an attacker can immediately monetize or reuse, especially secrets, authentication material, and high-value personal or payment data.
Failure mechanism: The database becomes a concentration point for data that should have had tighter scope, shorter retention, or stronger compartmentalization. A single misconfigured query path, overly broad role, stolen backup, or injected application query can then expose far more than the application actually needs.
Impact: Breach scope expands, recovery becomes slower, and the team may have to rotate secrets, invalidate sessions, reissue credentials, or purge data across many downstream systems. In practice, the cost of storing the wrong thing is often much higher than the cost of designing a separate storage path up front.
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 ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Plaintext passwords and secrets are credential material managed by this control. |
| AC-6 — Least Privilege | Minimising sensitive data in databases reduces who can access high-risk material. | |
| SC-28 — Protection of Information at Rest | Sensitive data kept in databases must be protected against disclosure from stored copies and backups. | |
| Recommendation — Store only non-recoverable credential representations and rotate any exposed secrets immediately. Limit database exposure to the minimum fields needed for the application’s function. Apply stronger protection or relocate data when storage creates unacceptable disclosure risk. | ||
| ISO/IEC 27001:2022 | A.5.12 — Classification of information | The decision hinges on classifying which data is too sensitive for database storage. |
| A.8.10 — Information deletion | Retained sensitive data should be minimised and removed when it is no longer needed. | |
| Recommendation — Classify fields by sensitivity before deciding whether they belong in the database. Define deletion and retention limits for data that does not need long-term database storage. | ||
Practitioner Guidance
What to verify: For each sensitive field, verify whether the application needs the raw value, a reversible form, or only a reference. If the answer is “only a reference,” remove the raw data from the database design and make that constraint part of schema review.
Decision rule: If the field can be used to authenticate, authorize, pay, or directly impersonate a user or system, treat it as disallowed by default unless a specific control and retention need have been documented. If it is only needed for lookup, display, or workflow linkage, store the minimum derived value needed to keep the process working.
What practitioners underestimate: Backups and replicas are part of the storage decision. A field that seems acceptable in the primary database can become far riskier once it is copied into analytics, snapshots, lower environments, or disaster recovery systems.
Practitioner takeaway: The safest database design is usually the one that stores the least sensitive version of the data that still lets the business function, and nothing more.
Related resources from NHI Mgmt Group
- How should security teams decide between tokenization and encryption for sensitive data?
- How should security teams protect sensitive data stored by mobile apps on iOS?
- How do security teams decide whether to redact, mask, or remove sensitive data from documents?
- How should security teams implement data loss prevention for sensitive data stored on servers and databases?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 27, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
