Map the encryption layers
IBM Z encryption is a collection of capabilities across hardware, operating systems, storage, databases and network services. Plan coverage by following a workload’s data through those layers. This guide uses z/OS documentation, with the linked z/OS 3.2 material as a reference; establish the supported features for your actual hardware, software, maintenance level and storage configuration.
IBM describes pervasive encryption as an approach to broad protection of data in flight and at rest. A planning review should identify the mechanism used at each boundary instead of treating the phrase as one universal switch.
| Layer | Question for the workload | Verification evidence |
|---|---|---|
| Storage and volumes | Which stored copies are covered by the storage system? | Configuration and documented key dependencies, including replicas. |
| z/OS data sets | Which supported data sets are created with encryption? | Eligibility, allocation metadata, key label and access tests. |
| Database or application | Does the service apply additional field or database protection? | Product configuration and application access paths. |
| Network traffic | Where are TLS or other approved protected channels established? | Endpoint identity checks and actual negotiated protection. |
| Backups and exports | What protection follows copies beyond the original system? | Restore tests, export format and destination key availability. |
On a narrow screen, scroll the table sideways. Keyboard users can focus the table and use the arrow keys.
A privileged application may legitimately read data after decryption. Continue to review account privileges, service identities and plaintext output destinations.
Understand labels, keys and authorization
For supported z/OS data-set encryption, a key label identifies an encryption key held in the Integrated Cryptographic Service Facility, or ICSF, cryptographic key data set, or CKDS. IBM’s data-set encryption documentation explains the AES-256 DATA-key relationship and the ways labels can be supplied through allocation and policy controls.
The label is an identifier, not the secret key. The documented setup also requires the relevant ICSF and hardware master-key configuration. Data-set permissions and permission to use the key are related but separate controls; an intended user needs the required authority for both paths.
Record who owns keys, who administers data and who approves recovery. Protect the key repository and recovery material under the organization’s separation-of-duties process. Avoid copying production key material into change tickets or ordinary troubleshooting logs.
Use the documentation for the exact data-set type and release. A policy that affects newly allocated data sets should not be assumed to encrypt every existing object retrospectively. Verify conversion or migration requirements before scheduling the change.
Build a representative pilot
- Inventory the workload: data-set types, volume and storage policies, batch and online access, replicas, exports and retention requirements.
- Confirm prerequisites with the system, storage and security administrators. Record hardware/OS levels, relevant maintenance, ICSF configuration, key label and permissions.
- Use non-sensitive representative data to allocate or migrate through the documented process. Inspect the resulting encryption attributes rather than relying on a successful job completion.
- Run the expected read/write paths with approved service identities. Check an authorized test identity lacking the required permissions and confirm expected denial.
- Measure workload response time, throughput and resource use under comparable conditions. Include batch windows and contention, not only an isolated encryption operation.
- Create a backup or replica through the intended operational path and restore it in the planned recovery environment.
IBM’s Getting Started with z/OS Data Set Encryption provides a fuller implementation and recovery reference. Use it with release-specific documentation and your local change process.
Rehearse recovery with the keys included
Restoring an encrypted data copy requires the appropriate key path and compatible environment. Document key backups, master-key handling, repository state, access rules and the procedures that keep them aligned. Never assume that transferring a CKDS file between differently configured environments is sufficient.
A key change also affects retained data. Identify older data sets and backups that still need earlier keys before archiving or destroying anything. Keep an inventory of those dependencies so cleanup can be reviewed.
Turn the pilot into a deployment decision
The decision record should show coverage, eligibility exceptions, authorization results, representative performance and successful recovery. Assign an owner to every unresolved dependency and identify the condition that would stop or roll back the rollout.
Vendor throughput and performance ratios refer to particular systems, configurations and measurements. For your decision, compare representative workload measurements using the same test definition and record any differences in hardware or software.
Repeat the relevant checks after a platform upgrade, storage-policy change, cryptographic configuration change or revised backup path. A useful encryption program keeps coverage and recoverability visible throughout the workload’s life.
Keep a usable review record
Download the ibm z encryption planning record (plain text). Save a copy, fill it out in a text editor, and keep it with your approved project records.