What is examined in a z/OS and RACF audit?

On the entitlement side, among other things the holders of special rights, overly broad default settings, permanently active warning modes, rules that bypass logging, technical IDs with elevated rights and the authentication methods. On the system side, privileged program libraries, in-house system extensions, protection of central configuration data sets, the UNIX level, logging and segregation of duties.

Why are entitlement and system reviews carried out together?

Because entitlements are only worth as much as the system foundation they rest on. Anyone with write access to a privileged program library can bypass entitlement checks. A pure entitlement audit misses that path.

Which frameworks are the findings mapped to?

Depending on the organisation, to DORA, the German NIS2 implementing act, ISO/IEC 27001:2022, PCI DSS 4.0.1 and the BSI IT-Grundschutz module for IBM Z. In addition we use the CIS benchmark for z/OS, which already ships with mappings to several of these frameworks.

z/OS and RACF Audit — Entitlements, System Integrity, Compliance

Why

The risk is rarely where you expect it

The spectacular findings are not the forgotten test users. They are the quiet escalation paths: an ownership chain that allows a password reset. A permission to act under someone else's identity. An entry that grants access and bypasses logging.

Such paths are not found by looking; they are found by systematically analysing the entitlement inventory against actually observed usage. That is why we review both together: the entitlements and the system foundation they rest on.

Eight review areas that produce findings in almost every audit — the interesting ones appear at their intersections.

Scope

Two sides of the same question

An entitlement audit without a look at system integrity checks door locks in a house whose walls can be moved. That is why both belong together.

Entitlements

Holders of special rights: number, assignment, actual usage
Overly broad default settings and permanently active warning modes
Rules that permit access while bypassing logging
Technical IDs and system services with elevated rights
Residual and unused IDs, shared functional IDs
Authentication: password rules, encryption, MFA, certificates

System integrity

Privileged program libraries: inventory and write access
In-house system extensions and interventions — origin and evidence
Protection of central system and configuration data sets
UNIX level: superuser rights, file system permissions, special attributes
Logging: is it written at all, retained, and actually analysed
Segregation of duties between administration, systems programming and audit

The premise: the vendor commits that no unauthorised program can gain authorisation. That commitment only holds as long as the installation does not undermine it itself. That is exactly where the review begins.

Typical findings

What we almost always find

Not a list to fear — a list to work through. Nearly all of it can be cleaned up without interrupting operations.

Too many holders of special rights, often on technical or shared IDs
Broad access rights on libraries that should not have them
Warning mode as a permanent state rather than a migration aid
Residual IDs still present in access lists

Shared functional IDs without personal attribution
Outdated encryption algorithms for passwords
Technical services that bypass all checks — without documented justification
Incomplete logging: data is written but never analysed

Regulatory frame

From technical finding to audit evidence

A report that merely lists commands and rights does not help the audit function. We map every finding to the framework your organisation is assessed against.

DORA — directly applicable since 17 January 2025; access and entitlement management, logging, operational resilience testing
NIS2 / BSIG — the German implementing act came into force on 6 December 2025, with registration, reporting and risk management obligations
ISO/IEC 27001:2022 — the transition period ended on 31 October 2025; only the 2022 edition is certifiable
PCI DSS 4.0.1 — the originally future-dated requirements have been mandatory since 31 March 2025
BSI IT-Grundschutz — the IBM Z module and its implementation guidance

A practical bridge: since October 2025 there is an updated CIS benchmark for z/OS with mappings to PCI DSS, DORA and NIST among others. That turns a technical review directly into regulatory evidence — no home-grown translation table required.

What you receive

A findings list with risk rating and mapping to the applicable framework
A remediation plan prioritised by effect and effort — not alphabetically
A management summary readable without z/OS knowledge
A proposal for a repeatable review cycle rather than a one-off snapshot

After the audit

A finding is only worth something if it does not come back

Recertification

A repeatable cycle: who confirms which rights, at what interval, with what evidence — tool-supported rather than by spreadsheet.

SIEM integration

Feed security-relevant events into your existing SIEM — with defined use cases instead of a raw data flood.

Break-glass

Emergency IDs with a defined process, automatic logging and mandatory follow-up — instead of permanently granted privileges “just in case”.

What this audit is

A structured, reproducible review of configuration, entitlements and logging based on native utilities and your own operational data — with prioritisation and an implementation proposal.

What it is not

Not a penetration test, not a product certification, not legal advice. Where a legal assessment is required we say so — and supply the technical basis for it.

When were your entitlements last reviewed in full?

We start by looking at scope and data availability — that determines whether a full review or a focused cut makes sense.

Request an audit See the methodology