Yes. A snapshot is a complete copy of the database at one moment, so restoring one into staging, or sharing it with another account, puts every production row in that environment. Treat snapshot creation, sharing and restore as controlled actions, and use masked or synthetic baselines for test systems instead.
How snapshots slip into staging
The path is usually helpful rather than careless. A developer wants realistic data, so they restore last night's snapshot into a staging instance. Another team asks for a copy in their own cloud account, so someone shares the snapshot. Months later the staging instance is still there, with production data, weaker access rules and no monitoring.
Cloud providers document these features openly. Amazon's RDS documentation says that sharing a manual snapshot, whether encrypted or unencrypted, enables authorized accounts to copy it. It also says snapshots containing private information should not be shared publicly, that encrypted snapshots cannot be shared as public, and that you cannot restore a database instance from a snapshot that is both shared and encrypted without extra steps. Other providers have similar mechanisms, so check yours.
Where copies hide
| Place | How a copy arrives | Control |
|---|---|---|
| Staging database | Restore from a production snapshot | Block restores across environments |
| Another cloud account | Snapshot sharing | Restrict who may share, log it |
| Developer laptop | Dump exported for debugging | Policy plus audit |
| Analytics sandbox | Replicated or restored tables | Mask at the pipeline |
| Old snapshots | Never expired | Lifecycle rules |
Steps to get control
- Inventory snapshots. List manual and automated snapshots, their age, their encryption status and any accounts they are shared with.
- Find restored copies. Look for non production instances created from production snapshots. Most platforms record the source identifier on the instance, which makes this a quick query.
- Restrict sharing. Use permissions so only a small group can share snapshots, and require approval for any cross account share. Never make a snapshot public if it holds private information.
- Encrypt with managed keys you control. The provider note about default keys matters: snapshots encrypted with a default key may not be shareable, and a key you manage gives you a revocation lever.
- Add lifecycle rules. Expire manual snapshots after a set period unless tagged with an owner and reason.
- Block cross environment restore. Use policy to prevent a staging role from reading production snapshots at all.
- Offer a better baseline. Publish a masked or synthetic snapshot that staging may restore, so nobody has a reason to reach for the real one.
Think about it with a policy mindset
Under data protection principles, data should be limited to what is necessary and kept no longer than needed. A forgotten snapshot in a test account fails both tests. This is general information, not legal advice, so ask counsel how it applies to you.
Mistakes to avoid
- Assuming that encryption alone makes sharing safe. The recipient account can still read the data if you shared it with them.
- Letting automated test pipelines create snapshots with no expiry.
- Treating a restored instance as temporary but forgetting to tag it with an owner.
- Overlooking exports to object storage, which have their own sharing settings.
Quick check
Can I make a snapshot public if it is encrypted?
The AWS documentation says encrypted snapshots cannot be shared as public. Sharing with specific accounts is a separate action and still gives them a full copy.
How do I find snapshots shared with other accounts?
Use your provider's console or API to list snapshot attributes. Schedule that check weekly and alert on new shares.
Sources
Last reviewed: 19 October 2026.
