90.6% of cloud storage still leaves stored data unencrypted on storage servers, based on a 2025 market snapshot. That number should reset the conversation around data at rest protection, because the central question isn't whether teams use encryption somewhere in the stack, it's whether stored customer data, backups, and logs stay protected when systems are offline, mounted, restored, or rehydrated for processing.
For SaaS and support platforms, that distinction matters. Customer transcripts, uploaded documents, audit trails, and analytics exports often live across databases, object storage, archives, and backup layers. If one of those layers is left out, or if keys and access controls are weak, the protection boundary is thinner than the compliance checkbox suggests.
Table of Contents
- Why Data at Rest Protection Demands More Than Encryption
- Technical Controls for Protecting Stored Data
- The Hidden Risk of Data Rehydration in AI Workflows
- Implementation Checklist for SaaS and Support Platforms
- Mapping Controls to Regulatory and Compliance Requirements
- Testing and Monitoring Your Data at Rest Controls
- Building a Layered Defense Strategy for Stored Data
Why Data at Rest Protection Demands More Than Encryption
90.6% of cloud providers leave stored data unencrypted on their storage servers, according to a widely cited 2025 market snapshot tied to inadequate data encryption costs. That's the uncomfortable baseline. Encryption is still essential, but the gap shows why data at rest protection has to be treated as a control stack, not a single setting.
What counts as data at rest
AWS defines data at rest as persisted data in non-volatile storage, including block storage, object storage, databases, archives, and IoT devices. NIST uses the same broad idea in its data-at-rest guidance, and the practical takeaway is simple. Anything written to storage and not actively being processed belongs in the at-rest category.
Practical rule: If a support transcript, backup file, or audit log can survive a reboot, it needs to be treated as stored data, not as a temporary application artifact.
That definition matters because SaaS teams often split responsibility across application, infrastructure, and operations. One team encrypts the database, another handles object storage, and a third owns backup jobs. Without a deliberate policy, one of those layers ends up exposed.
Why the risk model starts with storage compromise
The main threat isn't theoretical. It's physical theft, unauthorized storage access, and mishandling after a system is powered off. Once an attacker has the media, confidentiality depends on whether the keys, the access path, and the authorization boundary still hold. Azure's reference architecture makes the underlying mechanism plain, symmetric encryption protects data as it's written and read back, but the keys must live separately in a secure location with identity-based access control and audit policies. The separation is the point. If the storage is compromised but the keys aren't, plaintext shouldn't fall out with the disk.
That's why AWS recommends secure key management, enforced encryption at rest, automation, and access control together. Encryption without access governance is brittle. Access governance without encryption leaves sensitive media readable if the storage layer is copied, stolen, or mounted elsewhere. In support platforms, this is especially relevant because customer records rarely stay in one place. They move through transcripts, documents, exports, and logs, then sit in backup systems long after the ticket is closed.
The best way to think about data at rest protection is this, storage compromise should not equal data exposure. That only works when encryption, key custody, and access policy are all in place and validated continuously.
Technical Controls for Protecting Stored Data
Different storage controls solve different problems, and teams get into trouble when they treat them as interchangeable. Full-disk encryption, file-level encryption, database controls like Transparent Data Encryption, and tokenization all reduce risk, but they don't cover the same threat surface. A SaaS platform handling support data usually needs more than one.
Choosing the right encryption layer
The broad patterns are straightforward:
- Full-disk encryption protects an entire volume. It's useful when you want broad coverage with minimal application changes, especially for laptops, self-managed servers, or attached volumes.
- File-level encryption targets specific files or directories. It works when only a subset of stored data is sensitive, but it can leave operational gaps if teams forget which paths matter.
- Transparent Data Encryption, or TDE, protects database files at rest without forcing application changes. Microsoft's relational storage guidance treats TDE as always-on for stored data, which makes it a common fit for managed database workloads.
- Tokenization replaces sensitive structured fields with tokens. It's not encryption in the strict storage sense, but it can reduce exposure when teams only need to preserve format or referenceability for certain fields.
Here's the decision rule I use in practice. If the platform needs broad storage coverage with low friction, start at the disk or database layer. If a few fields need special treatment, tokenization can shrink the blast radius. If the storage substrate is mixed, layer the controls instead of forcing one method to do everything.
| Method | Threat Surface Covered | Key Management Complexity | Best For |
|---|---|---|---|
| Full-disk encryption | Lost or stolen media, exposed attached volumes | Moderate | Servers, laptops, backup volumes |
| File-level encryption | Specific documents, exports, and archives | Moderate to high | Sensitive folders, staged files, shared repositories |
| TDE | Database files and database-managed storage | Moderate | Relational databases and managed SQL services |
| Tokenization | Sensitive structured fields | High | Payment-like fields, identifiers, partial exposure reduction |
How key separation changes the threat model
NIST and AWS both treat secure key management as part of the control, not an add-on. Azure's reference architecture is explicit, the same symmetric key encrypts and decrypts stored data, but the key has to live elsewhere with identity-based access and audit controls. That separation changes the outcome. If an attacker steals storage but can't reach the keys, they should get ciphertext. If they compromise the key store, the boundary collapses.
Keep keys out of the same trust zone as the data they protect. If the same compromise can expose both, the encryption is mostly decorative.
That's why role-based access control matters even for encrypted systems. Operations staff may need to manage backups without seeing plaintext, while a small set of security and platform roles should control key operations. In many environments, the right answer is not “encrypt more,” it's “restrict decryption more tightly.” AgentStack's encryption skill is a good example of this principle in product design, since it uses AES-256-GCM for data at rest and includes secure key derivation with Argon2id. The technical pattern is familiar, but the operational discipline around key access is what keeps it useful.
The Hidden Risk of Data Rehydration in AI Workflows
Encrypted storage can still leak data when the platform has to wake it up. That's a critical oversight. In AI and automation pipelines, stored content is repeatedly pulled into memory, caches, indices, and inference flows so the system can search it, summarize it, or route it to another model. Every one of those steps creates a temporary plaintext window.
Where plaintext windows appear
A support platform that ingests documents, routes conversations across models, and produces analytics doesn't just read storage once. It rehydrates data for retrieval, chunking, classification, search, answer generation, and reporting. Even if the underlying store stays encrypted at rest, the operational exposure happens when the content is mounted, queried, or copied into an intermediate layer.
That's why the critical control question is not only “is it encrypted?” It's “who can decrypt it, where does it land after decryption, and how long does it remain readable?” NCSC guidance makes that boundary more concrete by requiring attention to who can access the data and whether it is protected when a device is powered off or only integrity-checked before use. The storage layer can be sound while the processing layer is sloppy.
A support platform often has more exposure points than a classic CRUD application. Documents may be indexed for search, transcript fragments may be cached for response generation, and analytics jobs may copy records into separate stores. If those pipelines reuse the same keys or broad service accounts, a single credential problem can expose more than the primary database.
Why zero-trust thinking fits stored data
The cleaner model is zero-trust for stored data. Encrypt by default, minimize decrypted scope, and watch for unusual movement instead of assuming storage encryption is enough. NHIMG's guidance on protecting data at rest, in use, and in motion says to map those states separately, because one policy can hide gaps. That advice lands well in AI systems, where a single ticket payload can pass through several processors before a human ever sees it.
Operational takeaway: Treat rehydration as a security event. If a workflow needs plaintext, grant the narrowest possible access, for the shortest possible time, and log the path.
The practical consequence is that security teams need visibility into caches, search indexes, analytics exports, and model pipelines, not just primary databases. In a support stack, those layers often carry the most sensitive derived data because they consolidate many customer interactions into a few high-value stores. When that happens, encryption at rest still helps, but it's no longer the whole story.
For a related platform pattern, see the question answering system example and notice how retrieval pipelines create more transient exposure than a simple static repository does.
Implementation Checklist for SaaS and Support Platforms
The right implementation plan starts with what can fail without warning. In SaaS and support systems, that usually means inconsistent encryption coverage, weak key segregation, and storage layers that drift out of policy after manual provisioning. A clean checklist helps because it turns a vague security goal into verifiable controls.
What to validate before launch
Start with platform-level coverage, not just the primary application database.
- Enable platform-level encryption. Use AES-256-GCM where the platform supports authenticated encryption for stored data. Verify that databases, object stores, document repositories, and backups are covered, not just the live production schema.
- Separate keys from data. Store encryption keys in a secure system with identity-based access controls and audit logging. The validation test is simple, a storage-only compromise should not yield plaintext.
- Lock down roles. Apply role-based access control to both storage and key-management operations. If a support engineer can restore data, that role shouldn't automatically be able to decrypt everything.
- Export and retain audit logs. Keep logs for access to sensitive storage, key operations, and restore events. Export them to a system the storage admins can't rewrite.
- Test deletion and residency paths. If the platform claims GDPR support, confirm data export, deletion, and residency behavior across all persistent stores, including backups.
AgentStack fits naturally into this checklist as one platform example. Its enterprise controls include AES-256-GCM encryption for data in transit and at rest, exportable audit logs, role-based access control, and GDPR features for data residency, deletion, and export.
What to automate after launch
Manual checks miss drift. AWS's guidance on at-rest protection recommends automation because teams forget to apply the same settings to every new workload. That matters in cloud environments where one service gets encrypted by default and another arrives unprotected through a one-off deployment script.
Use automated policy checks to catch the mistakes humans make during provisioning, recovery, and backup creation.
A useful validation loop looks like this:
- Configuration scans to confirm encryption flags are enabled on every storage service.
- Backup checks to prove archive copies inherit the same protection as primary data.
- Key policy reviews to ensure only approved identities can decrypt or rotate keys.
- Restore drills to confirm encrypted data comes back correctly without expanding who can read it.
The point isn't to pile on controls for their own sake. It's to make sure the platform behaves the same way in production, recovery, and incident response. That's where most configuration drift shows up.
Mapping Controls to Regulatory and Compliance Requirements
Compliance frameworks rarely ask for encryption in isolation. They ask for technical safeguards, access governance, logging, and, in some cases, data handling rules that span the full lifecycle. The smartest implementation strategy is to map one control to several obligations instead of building separate control stacks for every framework.
How technical controls satisfy multiple frameworks
GDPR pushes teams toward data residency, deletion, and defensible processing. In practice, that means stored-data controls need to support deletion across primary stores and backups, and access to sensitive records must be limited and auditable. SOC 2 Type II expectations push in the same direction, because auditors want evidence that security controls operate consistently over time, not just during a point-in-time review.
For HIPAA, the lesson is even starker. Protected health information needs layered safeguards, which is why a general healthcare resource like the healthcare data protection guide is useful background when teams are designing access and storage controls for regulated support flows. Disk encryption alone doesn't address who can retrieve, restore, or export sensitive records.
The technical mapping usually looks like this:
- Encryption at rest supports confidentiality expectations across all three frameworks.
- Key management and access controls support minimum necessary access and auditability.
- Retention and deletion controls help with GDPR and records management obligations.
- Exportable logs make it easier to prove control operation during audits and investigations.
For product teams, the practical question is which controls satisfy multiple requirements at once. A well-designed key-management policy, for example, can support security, auditability, and operational separation of duties without needing a separate process for each regulation. The same is true for backup encryption and retention governance.
How compliance and risk connect financially
The financial case is easier to ignore until it isn't. Independent industry research places the average data-breach cost at $4.9 million in 2024, up from $4.2 million in 2021, $4.6 million in 2022, and $5.0 million in 2023. That trend doesn't prove every breach will hit the average, but it does show why leadership treats stored-data protection as more than a technical preference. The same report says 73% of organizations prioritize data-at-rest encryption and 64% prioritize cloud encryption, which signals that this has become mainstream control design rather than a niche concern. Those figures come from the 2025 global encryption trends report at Encryption Consulting's 2025 overview.
A more useful way to think about compliance is risk reduction through shared controls. If one encryption and logging model can satisfy multiple obligations, the platform gets simpler to defend and easier to audit. That's also why teams building AI-heavy support products should align compliance planning with governance, as discussed in the AI governance and compliance guide.
Testing and Monitoring Your Data at Rest Controls
If you don't test stored-data controls, you're trusting config files and assumptions. That's a weak bet. Encryption, key rotation, and access policy all need to be validated after deployment because recovery paths, backup jobs, and emergency access often bypass the happy path.
How to prove controls still work
Start with key rotation. Confirm that keys rotate on schedule, old keys are retired correctly, and current data remains readable after rotation. The operational risk isn't the math, it's accidental lockout, stale permissions, or lingering access to retired keys.
Then test access reviews. Look for overly broad roles on storage systems, backup consoles, and key-management services. In many environments, the cleanest finding isn't “no encryption,” it's “too many people can decrypt.” That's still a security failure.
Simulation helps too. Run tabletop exercises for scenarios like compromised storage credentials or exfiltrated backup media. The goal is to see whether defenders can spot the problem and contain the blast radius before the attacker uses the recovered data. Don't keep these exercises theoretical. Include restore paths, admin break-glass access, and evidence collection.
How to spot suspicious stored-data access
Continuous monitoring should flag access patterns that don't fit normal behavior. That includes bulk decryption requests, restore activity from unexpected locations, and unusual movement from backup systems into working environments. The alert doesn't need to be fancy to be useful. It just needs to show that something is reading more stored data than it should.
Monitoring rule: Build alerts around decryption volume, restore events, and key use from unfamiliar identities. Those signals are often earlier than a confirmed incident.
For teams with mature security operations, the best place to start is the control plane around storage and keys. For smaller organizations, log export and simple alerting are still valuable if they catch abnormal access to encrypted repositories. If you need a reference point for continuous governance in regulated environments, monitoring for NIST 800-171 is a useful companion concept even when your platform isn't in a defense contract. The underlying idea is the same, controls only matter if they keep operating after the first deployment.
For broader AI-enabled support platforms, enterprise AI security becomes part of the same monitoring story, because decrypted data often flows into adjacent systems that weren't designed to be the primary trust boundary.
Building a Layered Defense Strategy for Stored Data
A strong data at rest protection program doesn't start with the crypto library. It starts with scope, then adds controls that survive operational reality. The safest pattern is layered, platform encryption, isolated key management, strict authorization, logging, and monitoring of every place stored data gets rehydrated.
I've seen the same failure pattern repeat across SaaS teams. They enable encryption on the main database, then forget backups, archives, and staging buckets. They protect the volume, then let too many people into the key store. Or they secure the storage layer, then pull the same customer content through analytics and AI pipelines without narrowing the plaintext window. The result is a control that looks solid on paper and leaks in practice.
A practical starting order looks like this. First, encrypt every persistent layer that holds customer data. Second, isolate keys from the data they protect and lock down who can use them. Third, enforce audit logging on both storage and key operations. Fourth, review rehydration paths in caches, indices, analytics jobs, and support automation. After that, add continuous compliance checks so drift gets caught before a review or incident does.
The target isn't perfect secrecy. It's making sure storage compromise, backup exposure, or a temporary processing window doesn't turn into full plaintext access. That's the difference between checking a compliance box and reducing risk.
If you're building or reviewing a support platform, visit AgentStack to see how encrypted storage, role-based access, audit logs, and AI workflow controls fit into one system. It's a practical place to start if you want your customer data protected at rest and handled more carefully when it's rehydrated for automation, search, or support responses.