Does ISO 27001 Require Encryption at REST
When teams ask does iso 27001 require encryption at rest, the direct answer is no. The standard lets your risk assessment decide when and where you encrypt stored data. If your risk check shows sensitive files face exposure, auditors expect you to encrypt them. Most modern cloud teams turn on disk and database encryption for all production stores. How does iso 27001 require encryption at rest in practice ISO 27001 uses a risk-based framework instead of a fixed checklist of technical tools. An
Encryption at Rest + ISO 27001: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
When teams ask does iso 27001 require encryption at rest, the direct answer is no. The standard lets your risk assessment decide when and where you encrypt stored data. If your risk check shows sensitive files face exposure, auditors expect you to encrypt them. Most modern cloud teams turn on disk and database encryption for all production stores.
How does iso 27001 require encryption at rest in practice
ISO 27001 uses a risk-based framework instead of a fixed checklist of technical tools. Annex A includes a control for cryptography, which covers both data in transit and at rest. You must write a clear policy on how your team uses cryptographic controls and keys. This policy maps back to your data classification rules and your risk register.
Suppose your database holds customer emails, phone numbers, card numbers, or national IDs. Your risk review will flag the danger of a stolen drive or exposed backup file. To lower that risk, you commit to encrypting those storage volumes and database snapshots. Once you write that rule in your policy, the auditor checks that you follow it.
For engineers and AI agents, disk encryption happens deep in the cloud storage layer. The cloud host encrypts blocks as it writes them and decrypts them on read. Apps, scripts, and AI agents do not change how they query the database. They log in with standard credentials and read plain text rows as usual.
Why encryption at rest leaves live database sessions exposed
Encryption at rest only protects data when someone steals a physical disk or raw snapshot. The moment the database engine starts up, it unlocks those blocks for authorized users. When an engineer or AI agent logs in, the database returns plain text results. Disk encryption does nothing to restrict what happens inside an active query session.
Many teams rely on static credentials and broad database roles for day-to-day maintenance. If a script or user holds a valid role, the storage layer decrypts every row by default. An engineer running a quick check can pull thousands of customer emails and card numbers. An AI agent with a read role can pull sensitive phone numbers into its prompt.
Encryption at Rest + ISO 27001: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
ISO 27001 also requires strict access control, event logs, and data masking practices. Turning on disk checkboxes satisfies the storage rule, but it leaves runtime access wide open. Auditors now look closely at how you govern live queries from people and automated tools. You need clear logs of every command and ways to mask sensitive fields in results.
How to pair storage encryption with runtime data controls
Start by classifying every data store so you know where sensitive records live. Turn on storage and backup encryption across all cloud volumes and managed databases. Store your encryption keys in a dedicated key service and rotate them on a schedule. Document these steps in your cryptography policy so your auditor can verify them fast.
Next, close the gap between encrypted disks and live user or agent sessions. Replace shared static database keys with individual logins tied to your identity provider. Add query-level logging so you can prove who read which table and when. Use runtime data masking to rewrite matched fields like national IDs or card numbers in results.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev runs beside those services as an open-source proxy, a sidecar for your Postgres or API. It inspects requests coming in and results going back on the wire.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run. On responses, hoop.dev data masking rewrites matched sensitive values in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
Which ISO 27001 control covers encryption at rest?
Annex A control 8.24 in the 2022 revision covers the use of cryptography. It requires you to define and apply rules for encryption and key management based on risk.
Can we pass an ISO 27001 audit without encrypting every disk?
Yes, if your risk assessment proves a disk holds only public or low-risk data. You must document that decision in your Statement of Applicability and get management sign-off.
Does disk encryption satisfy ISO 27001 data masking rules?
No, Annex A control 8.11 covers data masking as a separate runtime practice. Disk encryption protects stored files, while data masking rewrites sensitive fields during live queries.