No SMF, no mainframe SOC. It's that simple and that serious. When a security team decides to extend its SOC coverage to the IBM Z mainframe, the first question isn't which tool to install, but where the telemetry comes from. On Windows or Linux, the answer is straightforward: event logs, syslog, auditd, EDR agents. In mainframe cybersecurity, the answer has a name of its own: System Management Facility, universally known as SMF. SMF records are the native z/OS mechanism for logging system activity, and they have been doing so since the 1970s, long before the concept of a SIEM existed. Everything that happens on a mainframe —who logs in, which datasets they open, which jobs they submit, which security profiles they change, which TCP connections they establish— is reflected in the SMF records. If it isn't in SMF, for audit purposes it didn't happen. This article explains what they are, which ones are critical for z/OS security, what risks appear when they aren't managed properly, and how SMF records analysis turns raw telemetry into actionable intelligence for the SOC.

What SMF is and how it works

SMF is a z/OS subsystem that acts as the system's notary. When a relevant event occurs—a batch job that ends, a user accessing a protected dataset, a RACF profile that changes—the corresponding z/OS component writes an SMF record with the details of the event. These records are identified by a numeric type (SMF record type), numbered from 0 to 255, which indicates which subsystem generated them and what information they contain. IBM reserves types 0 to 127 for the operating system and its subsystems, and leaves types 128 to 255 for third-party products. In total, there are more than a hundred types defined by IBM, each with its own subtypes. Records are written in real time. Traditionally, they are stored in special datasets called SMF datasets (named SYS1.MANx); in modern installations, they can also be directed to System Logger log streams. When a dataset fills up, z/OS automatically switches to the next one. The dump-and-archive process—performed by the IFASMFDP utility (or IFASMFDL when log streams are used), what many teams colloquially call the "SMF dump"—is critical: if it fails, the oldest records are overwritten, and the evidence is lost forever. This operational detail has direct compliance implications. DORA, NIS2 and PCI DSS require audit records to be retained for defined periods. If the SMF dump process is not properly configured and monitored, the organization can lose evidence without even knowing it.

SMF records analysis: the critical types for the SOC

Not all SMF records are equally relevant to security. These are the ones any mainframe security monitoring strategy needs to know and watch.

Types 80 and 83: the heart of the security audit trail

Type 80 is the most important record for any auditor or security analyst. It is generated by the External Security Manager —RACF, ACF2 or TopSecret— and captures every security event on the system:
  • Resource access attempts (successful and failed).
  • Changes to user and group profiles.
  • Modifications to special attributes (SPECIAL, OPERATIONS, AUDITOR).
  • Changes to dataset and resource protection rules.
  • Management operations on the ESM itself.
Type 83 is documented by IBM as a "Security events" record and complements type 80. Its subtype 1 captures dataset access auditing managed by RACF, while later subtypes capture other system security events (among them LDAP activity, data compliance events and auditing of components that invoke RACF audit services). Type 81 documents RACF initialization: it records the ESM options and configuration in effect at system startup. For the SOC, it works as a security configuration baseline, making it possible to detect drift when someone changes critical RACF options. For the SOC, these types are the mainframe equivalent of the Windows Security Event Log. The difference is that here there is no agent forwarding them automatically: you have to go and get them.

Type 90: system and SMF configuration changes

Type 90 records system status changes and operator commands: system parameter modifications, time changes, and —most relevant for security—changes to the SMF configuration itself (SET/SETSMF commands). It is the record that exposes anyone trying to tamper with the system clock or the audit mechanism itself to hide their activity. Watching type 90 is, in practice, watching the integrity of the audit trail.

Type 30: who ran what and when

Type 30 captures the complete lifecycle of jobs and sessions in z/OS: start, intermediate steps and termination. It includes the user who submitted the job, the job identifier, the programs executed, the datasets accessed and the return codes. For the SOC it is fundamental for correlating activity: if a type 80 record shows anomalous access to a payroll dataset, type 30 reveals exactly which job caused it, who launched it and from where.

Type 92: activity in z/OS UNIX System Services (USS)

Type 92 records activity in the z/OS USS (Unix System Services) subsystem: file creation and modification, permission changes, process execution and system calls. It is the equivalent of auditd on Linux, but inside the mainframe. USS is frequently the most neglected attack vector in z/OS. Analysts unfamiliar with the mainframe tend to ignore it because "it doesn't look like a mainframe." Mistake: an attacker who gets a USS shell with UID 0 has practically unlimited access to the system.

Type 119: TCP/IP network events

Type 119 is generated by the z/OS TCP/IP stack (Communications Server) and captures network connections, protocol errors, and communication-related security events. It is the starting point for detecting lateral movement to or from the mainframe.

Types 14, 15, 17 and 18: dataset activity

Types 14 and 15 record the opening of datasets for read and write, respectively. Type 17 records dataset deletion, and type 18 their renaming, a common technique for hiding files or evading name-based protection rules. For an analyst investigating a possible data exfiltration, these records are essential: they reveal exactly which files were opened, when, by which user or job, and whether someone tried to delete or disguise them.

Types 110 and 100/101/102: critical middleware (CICS and Db2)

Type 110 records CICS Transaction Server activity (transaction statistics and monitoring), while Db2 uses several types: 100 for statistics, 101 for accounting, and 102 for performance and audit traces (the IFCID records, which include the Db2 audit trace). In installations where critical applications run on CICS or where data resides in Db2, these records are an indispensable part of the audit trail. Don't confuse them: type 102 belongs to Db2, not CICS.

The problem no one mentions: volume and complexity

A mid-sized mainframe at a bank or insurer can generate several gigabytes of SMF records per day. In large installations, we're talking about tens of gigabytes. The granularity is extraordinary, but working directly with that mass of binary data is practically unfeasible without the right tools. The concrete challenges facing any team trying to do mainframe auditing on SMF without a specialized solution are four:
  • Proprietary binary format: SMF records are not text. Each type has its own layout, with fixed- and variable-length fields that change across z/OS versions. Parsing them correctly requires deep knowledge of IBM's technical documentation, measured in thousands of pages.
  • Cross-type correlation: a real security event is rarely reflected in a single record type. Relating a type 80 to its type 30 job, to the type 14/15 datasets it opened and to the type 119 network connection that started it requires correlation logic well beyond a simple grep.
  • Retention management: SMF records must be archived, indexed and kept accessible for the periods required by applicable regulations. Without a robust process, evidence is lost or becomes impossible to recover when an audit or forensic investigation needs it.
  • Lack of normalization: the same event may be encoded differently depending on whether the ESM is RACF, ACF2 or TopSecret. A SIEM that ingests events without accounting for these differences will produce false positives, false negatives or simply incorrect data.
On top of these four challenges sits a silent risk: if the SMF buffers saturate, z/OS starts to lose records and signals it through type 7 (SMF data lost). That record is, paradoxically, the proof that the audit trail itself has gaps. If no one watches it, the loss goes unnoticed and the organization discovers the hole precisely when it needs that data for an investigation or an audit.

Event correlation and anomaly detection in z/OS

The real value of SMF records analysis lies not in any isolated type, but in mainframe security event correlation. A single record rarely tells the whole story; it is the relationship between several types that reveals an attack pattern. Consider a typical case of z/OS anomaly detection: repeated failed access (type 80) followed by an atypical successful access (type 80) to a high-value dataset, correlated with the bulk opening of that dataset (type 15) within a batch job (type 30) launched outside the usual time window, and preceded by an unusual network connection (type 119). None of those events, on its own, justifies an alert. Their correlation does. That is the difference between a mainframe SOC that sees isolated dots and one that reconstructs the full sequence of an incident.

How DataPASS turns SMF into intelligence for the SOC

DataPASS natively addresses all the problems described. It is designed specifically for z/OS and understands SMF records with no additional agents, intermediate connectors or manual transformations. Its handling of SMF is structured in three layers:
  • Native ingestion and decoding: DataPASS reads z/OS SMF datasets directly, decodes all security-relevant types and normalizes their content into a uniform data model. The analyst doesn't need to know whether they're looking at RACF type 80 events or USS type 92 activity records: the platform abstracts and presents it coherently.
  • Automatic cross-type correlation: the platform automatically relates types 80, 30, 14/15 and 119 to detect the patterns a manual analysis would miss, enabling end-to-end mainframe logging and traceability.
  • Compliance evidence generation: DataPASS maps SMF events to the controls of applicable regulatory frameworks—DORA, NIS2, PCI DSS, SOX, GDPR—and generates the z/OS audit evidence reports external auditors need. Instead of exporting terabytes of binary records for an audit request, the team delivers structured reports that demonstrate compliance with specific controls.

What poor SMF management really costs

Picture the scenario —one any mainframe auditor will recognize as plausible—: during a PCI DSS compliance inspection at a financial institution, auditors request the access records for the payment systems over the last twelve months. The institution cannot provide them because the IFASMFDP process has failed silently for several months and the records have been overwritten. The result: a critical non-conformity, a long and costly remediation process, and exposure to penalties. It is not a security problem in the strict sense. It is an SMF management problem, and it is exactly the kind of operational failure that occurs when the SMF dataset dump is not monitored with alerts. This case illustrates something mainframe security teams know well but rarely reaches CISOs and governance teams: SMF is not just a logging mechanism; it is the only evidence of what happens on the mainframe. Poor management affects not only the ability to detect attacks, but directly the ability to demonstrate compliance to regulators and auditors.

z/OS security checklist: the minimum you should verify about SMF

If you manage or audit the z/OS security of a mainframe environment, these are the questions you should be able to answer affirmatively today:
  • Is the SMF dump process (IFASMFDP/IFASMFDL) automated and monitored with failure alerts?
  • Are types 80, 83, 81, 90, 30, 92, 119, and 14/15/18 actively collected and archived?
  • Is type 7 (SMF data lost) monitored to detect record loss from buffer saturation?
  • Are changes to the SMF configuration and the system clock (type 90) watched as part of audit-trail integrity?
  • How long are archived SMF records retained? Do they meet applicable regulations?
  • Is there a correlation mechanism that cross-references events from different record types?
  • Can the SOC query historical SMF records in under an hour during an incident?
  • Are SMF records integrated into the corporate SIEM with correct normalization?
If the answer to any of these questions is negative or "I don't know," the mainframe has a blind spot that no other security tool can compensate for.

Frequently asked questions

How do you automate audits in z/OS?

Automating audits in z/OS means no longer treating SMF records as files reviewed by hand. The practical route is to continuously collect the relevant types (80, 83, 30, 92, 119, 14/15), normalize them into a uniform model, and apply correlation rules and control mapping that generate evidence reports with no manual intervention. That is precisely the continuous-auditing approach to SMF.

How do you detect unauthorized changes in z/OS?

Unauthorized changes leave a trail across several record types: profile and special-attribute modifications in type 80, job activity in type 30, and USS file-system changes in type 92. Reliable detection requires correlating these types and comparing activity against a baseline, so that a change outside the change window or made by an atypical account raises an alert.

How does SMF differ from a SIEM?

SMF is the data source: the native record of everything that happens in z/OS. A mainframe SIEM is the layer that ingests, normalizes, correlates, and alerts on that data. Without SMF, the SIEM has nothing to ingest on the mainframe; without proper normalization and correlation, SMF data is nearly unusable. The two are complementary, not mutually exclusive.

Conclusion

SMF records are the foundation on which any mainframe auditing and detection capability in z/OS rests. They are the primary source of truth about what happens on a mainframe: without them, the SOC operates blind on the system that probably processes the most critical transactions in the business. Their technical complexity—binary format, massive volume, heterogeneity across types and ESMs—is real, but it is no excuse to ignore them. It is precisely why tools like DataPASS exist: so that deep knowledge of z/OS internals is not a prerequisite for having security visibility over it. A SOC that understands SMF is a SOC that truly covers the mainframe. Want to know how DataPASS integrates SMF records into your continuous-auditing strategy? Contact the Bsecure team for a technical demonstration tailored to your environment.