How to Use SAP Audit Information System for Security Reviews

The SAP Audit Information System (AIS, transaction code SECR) is the native, purpose-built tool for conducting structured, repeatable security reviews across SAP ECC and S/4HANA environments. To use it effectively for a security review, you configure audit classes, define logon and change monitoring parameters, then evaluate the generated log data for unauthorized access attempts, privilege misuse, and configuration drift. This process transforms raw system logs into actionable audit evidence, directly supporting SOX compliance, ISO 27001 certification, and SAP Security Baseline adherence. For enterprise teams managing complex SAP landscapes, however, the manual review process inherent in native AIS often creates bottlenecks; dedicated solutions like CyberSilo SAP Guardian can automate log aggregation and correlation to provide a continuous security monitoring overlay.

Understanding the SAP Audit Information System

The SAP Audit Information System is not a standalone application but an integrated architecture within the SAP NetWeaver Application Server ABAP stack. It relies on system-wide audit logging governed by the security auditor profile (SAP_ALL equivalent via audit profile assignments) and the audit index files stored in table SNCSYSACL and related structures. When a user triggers an auditable event—such as accessing a critical transaction like SE16 (table browser), SU01 (user maintenance), or modifying an authorization object via SM30—the AS ABAP dispatcher writes an audit entry to both static and dynamic audit log files.

Administrators access these logs through SECR, which provides an interactive filter interface over the collected data. The key insight is that AIS captures events based on three hierarchical layers: audit class, audit level, and audit filter. Understanding this hierarchy is the foundation of any effective security review.

Audit Classes, Levels, and Filters

SAP defines four audit classes that determine which category of events are subject to logging. The system logs events at four possible levels: inactive (no logging), critical (only high-severity events), medium (wider events), and low (maximum detail). Within each class, you can apply filters—either by specific user IDs, transaction codes, or authorization objects—to reduce log volume while maintaining audit coverage.

Audit Class

Events Captured

Typical Use in Security Reviews

Class 1 – Logon/Logoff

Successful and failed dialogs, RFC logons, HTTPS logons, system user impersonations

Detect brute-force attacks, unauthorized service accounts, and terminal session misuse

Class 2 – Transaction Start

Every start of a transactional or reporting program

Identify sensitive transaction usage, segregation of duties violations, and privilege escalation

Class 3 – File and Customizing Changes

Changes to system tables, client settings, transport requests, and cross-client data

Track configuration drift, unauthorized system modifications, and change management compliance

Class 4 – Authorization Failures

All authorization checks returning insufficient authorization

Pinpoint SoD conflicts, excessive role design, and attempted privilege escalation

A well-structured security review activates at least Class 1, 3, and 4 at a medium logging level across all productive clients. Class 2 is typically reserved for sensitive SAP standard transactions only—logging every start of every program generates overwhelming data that rapidly degrades both storage and reviewability.

Configuring SAP Audit Logging for Security Reviews

Before any review can begin, the system audit profile must be active and correctly configured. SAP AIS is not event-driven by default in many standard installations—security teams must explicitly enable logging parameters via transaction code SM19 (maintenance of audit log settings in AS ABAP) and SE38 program RSM13000 (to activate the audit data collector).

Define the Security Auditor Profile

Access transaction SU01, create or assign a user to the S_AUDIT authorization object with the value SECR or the predefined role SAP_AUDITOR. This user will execute the review sessions. Ensure the auditor profile is not a superuser—auditors must have read-only access to audit logs but no authorization to change them.

Activate Static Audit Logging (SM19)

Run SM19 and set the deployment context for each client under review. For each audit class, define the logging level and filter criteria. A secure baseline for enterprise reviews is: Class 1 = low (full), Class 2 = critical (SAP standard sensitive transactions only), Class 3 = medium, Class 4 = low. Save the static configuration to table TESTS.

Configure Dynamic Audit Logging (SM18/SARA)

For forensic reviews or targeted investigations, use SM18 to activate dynamic logging filters—you can specify exact user IDs, transaction codes, or date ranges for granular capture without increasing long-term log volume. Dynamic logging writes to the file system under directory /usr/sap/{SID}/DVEBMGS{n}/sec/ and must be archived regularly via SARA.

Test the Configuration

Perform a test logon with a non-privileged user and trigger a known authorization failure. Immediately call up SECR and verify the entry appears. Repeat for each audit class. If entries appear in SECR but not in the underlying file system, the collector program may be failing—check job SAP_AUDIT_COLLECTOR in SM37.

Critical Compliance Note: For SOX and PCI DSS audits, the audit log configuration itself must be version-controlled and auditable. Any change to SM19 settings must generate a separate log entry. If you use transport management to deploy audit configurations, ensure transports are tracked in a change management system. Native AIS does not automatically alert when audit logging is deactivated — implement a separate monitoring check to verify the audit profile is active at least every 24 hours.

How to Run a Security Review with SECR

Once audit logging is active and collecting data for a defined period (typically 30–90 days for a full review cycle), you use transaction SECR to query the archives. SECR provides a structured selection screen where you choose audit class filters, date ranges, and optional user-specific criteria.

Step-by-Step SECR Workflow

Open SECR and Define Selection Criteria

Navigate to SECR from the SAP Easy Access menu (or via SE38 for report RSECR100). On the initial screen, select the audit class most relevant to your current investigation. For a comprehensive security review, run the query four separate times — once per audit class — to avoid mixing event types and causing data overload.

Select Date Range and Source

Specify the review period. Use the "From" date as the start of your review window and "To" date as the end. Native AIS stores logs in static files on the application server. If your landscape uses archive file management, you must also specify the archive path under "General Data Selection" to include offline logs. This step is frequently overlooked in initial reviews, leading to incomplete datasets.

Apply User and Event Filters

To narrow the review to high-risk users, enter user IDs in the selection field. For insider threat detection, include all users but filter by authorization failures (Class 4) on sensitive objects like S_TCODE, S_USER_AUT, or S_CTS_ALL. For compliance audits, do not filter by user — display all events globally.

Execute and Analyze Output

Execute the report. The output list shows:

Timestamp and source client
Terminal ID and user ID
Transaction code or program name
Authorization check results (pass/fail with missing authorization values)
Message text containing specific error codes (e.g., ABAP runtime error SU_PRIVILEGE_CHECK)

Sort by user ID to identify patterns — a single user with multiple authorization failures in a short period indicates a potential threat. Export the list to a local file via the EAR_0001 program or using the standard export-to-Excel function available in newer SAP GUI versions.

Logs That Are Critically Important

Not all audit entries carry equal weight. During a security review, prioritize these specific event types:

Failed authorization checks (Class 4): Especially on objects S_TCODE and S_USER_AUT — these indicate users attempting transactions outside their role authorization. A high density of failures for a specific transaction (e.g., SE16, SE37) is a red flag for privilege escalation attempts.
RFC logon attempts (Class 1): Check for logon spikes from non-SAP systems or anonymous RFC connections — these often precede data extraction attacks.
Customizing changes (Class 3): Particularly changes to authorization objects, user buffer settings, or transport route configurations. Any change to the audit profile itself (SM19 parameter changes reflected in the log) must be immediately investigated.
System user logons (Class 1 with user type SYSTEM): System accounts like DDIC, SAP*, or custom RFC users should not be used for interactive logons. Their appearance in audit logs is a compliance violation under SAP Security Baseline and most regulated frameworks.

Interpreting Audit Logs for Compliance Evidence

AIS logs serve as direct evidence during a compliance audit when processed correctly. Each audit entry in the output list contains structured fields that mapping directly to control objectives under SOX (Section 404: internal controls over financial reporting), ISO 27001 (A.12.4: logging and monitoring), and PCI DSS (Requirement 10: track and monitor all access).

The critical mapping is between the user identity field and the transaction context field. For segregation of duties (SoD) reviews, export Class 2 and Class 4 logs, then correlate against a SoD control matrix. If a user in a Payables role appears to have executed transaction FB60 (enter invoices) and transaction F-53 (release payments) within the same session window, that is a direct SoD violation that must be flagged, documented, and remediated.

For SOX auditors specifically, AIS output must show:

Complete coverage of all financial system modules (FI, CO, TR, MM, SD) during the audit period
Evidence that all privileged user activity was logged continuously
That failed authentication attempts were captured and are attributable to specific user IDs, not just terminal IPs
That no gaps exist in the logging timeline — any period without log entries must be explained and should correspond to known system maintenance windows

Executive Risk Insight: In many enterprise SAP landscapes, the default AIS configuration captures only 20-40% of the events needed for a full compliance review. The most common gap is the absence of "read-only" access logging — viewing critical master data tables via SE16 does not trigger a change, so it is not logged under Class 3. To close this gap, manually assign the sensitive transactions to Class 2 filters in SM19 or implement an external monitoring tool that decodes ABAP table access events. Our CyberSilo SAP Guardian automatically maps these read events to compliance controls.

Limitations of Native SAP AIS

While AIS is essential, it is also constrained. Enterprise teams conducting quarterly or monthly security reviews at scale encounter several structural limitations:

No real-time alerting: AIS generates log files retroactively — you cannot trigger an email alert or API call when a critical authorization failure occurs. By the time the log is reviewed, the event may be hours or days old.
Log file storage fragmentation: In a distributed system with multiple application servers, each instance generates its own log files. AIS pulls these into a consolidated view only if the audit content collector program runs correctly — single-server failures cause data gaps.
No cross-system correlation: In S/4HANA environments integrated with BTP, AIS cannot correlate an authorization failure in SAP ERP with a corresponding API call in a BTP Cloud Foundry subaccount. The audit trail breaks at the system boundary.
No automated remediation workflow: When a violation is identified, SAP provides no native mechanism to automatically disable the user ID, enforce step-up authentication, or notify a compliance officer — each violation requires manual triage.

Closing the Gap Between Manual Audit Logs and Continuous Security

If your team spends more than 10 hours per week manually exporting, reviewing, and correlating AIS logs across multiple SAP systems, you have outgrown native SAP AIS. CyberSilo SAP Guardian provides continuous ingestion of all audit classes with automated alerting, cross-system correlation (ECC, S/4HANA, BTP), and built-in compliance reporting mapped to SOX, ISO 27001, and PCI DSS control frameworks. Schedule a technical demonstration to see how your security review cycle time can shrink from days to minutes.

Talk to Our Team Explore CyberSilo SAP Guardian

Conducting an Insider Threat Review Using AIS

Insider threats are the most difficult security events to detect because the user already possesses legitimate credentials. AIS-based review patterns can uncover anomalous behavior if the reviewer knows which signatures to look for. The classic insider threat detection method relies on baseline profiling: establish a 30-day activity baseline for each privileged user, then compare current-period audit logs against it using Class 2 and Class 4 data.

Anomalous Behavior Signatures

When reviewing AIS logs for insider threats, concentrate on three patterns:

Off-hours logons (Class 1): Users who never work weekends suddenly logging in on a Saturday at 1 AM from a terminal ID that maps to an administrative server rather than their usual workstation.
Transaction sequence escalation (Class 2): A user executing SE16 (table view) then found in SM30 (table maintenance) within the same session — the first transaction may be reconnaissance, the second indicates attempted data modification.
Authorization failure patterns (Class 4): Multiple failures on different authorization objects within a 15-minute window — the user is systematically probing for privileges they do not have.

For each potential insider threat identified, the reviewer should extract the complete user session log from the AIS files, cross-reference the user's last role change date (SUIM report RP_GEN_AUDIT), and compare the user's job function description against the transactions executed. This triangulation provides the evidence basis for escalating to HR or legal review.

Automating Recurring Security Reviews

Manual SECR-based reviews should be reserved for deep-dive forensic investigations or annual compliance audits. For routine monthly or quarterly reviews, the process can be partially automated even within native SAP — but with important caveats.

You can schedule the audit content collector (program RSM13000) as a nightly job via SM36 to automatically archive logs to a central file system. Then use variant programming to execute the SECR report with predefined filters and output the results to a spool list that can be automatically exported via SM37 job steps. Some enterprises use ABAP report RSECR100 direct calls within a custom Z-program to generate formatted audit logs and send them via email (function module SO_NEW_DOCUMENT_ATT_SEND_API1) to the security team.

However, this native automation still lacks correlation. Our CyberSilo SAP Guardian platform ingests these same AIS logs and enriches them with identity context, user risk scoring, and threat intelligence feeds — providing a unified dashboard for cross-system security review that covers on-premise ECC, cloud-hosted S/4HANA, and BTP environments without the manual export step.

Compliance Mapping: SAP AIS to Major Frameworks

Below is a mapping of the audit classes and log types available in SAP AIS to specific control objectives in the three most common compliance frameworks:

Control Requirement

Framework(s)

SAP AIS Audit Class

Verification Method

User access authentication

SOX 404, ISO 27001 A.9.4.2, PCI DSS 8.1

Class 1

Check failed logon attempts exceeding threshold (e.g., 5 within 10 minutes)

Privileged access monitoring

SOX 404, PCI DSS 10.2.1, GDPR Art. 33

Class 2 (sensitive transactions only)

Review SU01, SE16, SM30, RZ10, ST05 usage by non-administrator users

Configuration change control

SOX 404, ISO 27001 A.12.1.2, PCI DSS 11.2

Class 3

Cross-check all customizing changes against approved transport requests

Segregation of duties enforcement

SOX 404, PCI DSS 7.1.4

Class 4

Identify users with access to incompatible transaction groups via Class 4 logs

For each framework, the review cadence differs: SOX Section 404 requires quarterly reviews with annual certification, ISO 27001 requires internal audits at planned intervals (typically semi-annual), and PCI DSS mandates log review at least daily for cardholder data environment systems. Your AIS review schedule should align with the strictest applicable framework.

Advanced AIS Techniques for SAP Basis Security

Experienced Basis administrators can extend native AIS capabilities beyond standard SECR output. One technique involves creating custom audit classes for specific authorization objects that are not monitored by default. Using the S_AUDIT object attributes, you can define filters for custom Z-authorization objects that control critical custom business logic — essential when running SAP in heavily customized industries like manufacturing or financial services.

Another advanced method uses the RSECR100 program variant technique: store multiple selection screen variants (transaction OOSB for report RSECR100) that reflect different security review scenarios:

Variant SOX_Q1_2025: Full system audit with all Class 1/2/3/4 logs for the entire quarter, output to spool for archiving
Variant INSIDER_DAILY: Only Class 4 failures exceeding 3 per user per day, output to email
Variant CHANGE_REVIEW_WEEKLY: Only Class 3 logs for the past 7 days, excluding the administrator service account

While these techniques improve operational efficiency, they still require manual interpretation. For teams managing landscapes of 5+ SAP systems, the administrative burden of maintaining variants, scheduling jobs, and collecting output across systems leads to review cycle times of 2–3 weeks. An integrated security platform that centralizes audit log analysis reduces that cycle to under 4 hours.

Security Baseline Alert: The SAP Security Baseline (February 2025 release) mandates that audit logging must be active on "all productive systems" at minimum Class 1 (critical), Class 3 (medium), and Class 4 (medium). Systems that do not meet these thresholds are considered non-compliant and may face penalties in regulated industries. Audit logs must be retained for a minimum of 12 months for forensic use. Use AIS to verify compliance but plan for automated import into a SIEM or dedicated SAP security monitoring solution for continuous compliance validation.

Common Pitfalls to Avoid in SAP AIS Reviews

Even experienced security teams make recurring errors when relying on AIS for critical reviews. Below are the most common failures and how to prevent them:

Relying on a single application server's logs: In multi-instance environments, audit logs are distributed. If the review consumes logs only from the primary instance (DVEBMGS0), critical events captured on secondary instances are invisible. Always verify the audit content collector is running on every AS ABAP instance.
Ignoring log file rotation and archiving: SAP AIS log files have configurable rotation limits. When the file reaches its maximum size, the oldest entries are overwritten without notification. Set file retention to 90 days minimum for compliance, and archive logs daily via SARA to avoid data loss.
Assuming AIS captures all events: Events triggered by background jobs (SM37), batch input sessions, and RFC calls from trusted partners often use a different logging pathway. For comprehensive coverage, these event types must be captured using the SM18 dynamic filter with appropriate RFC login parameters, or through an external monitoring layer.
Failing to protect the audit log itself: The standard installation stores AIS files under the SAP kernel directory, writable by user <SID>adm and root. A malicious superuser can delete or alter logs without detection. Implement file system encryption and separate the log storage path to a network-attached storage volume with restricted write access for the auditor profile only.

Move Beyond Manual Log Review — Automate Your SAP Security Audits

If manual AIS log exports are delaying your quarterly compliance reporting, it is time to evaluate an automated alternative. CyberSilo SAP Guardian directly integrates with SAP AIS, BTP audit logs, and RFC network monitoring to provide a unified security view with pre-built compliance dashboards, automated alert triage, and real-time insider threat detection. Schedule a 30-minute technical demo tailored to your SAP landscape.

Schedule a Demo See SAP Guardian Features

Our Conclusion & Recommendation

The SAP Audit Information System remains a foundational tool for security reviews in SAP environments, providing the critical logging infrastructure necessary to meet SOX, ISO 27001, and PCI DSS compliance requirements. When used correctly—with active audit classes, properly configured filters, and regular data export—AIS equips security teams with forensic evidence needed to detect unauthorized access, insider threats, and configuration drift. However, for enterprise organizations managing multi-system landscapes with on-premise and cloud environments, the manual limitations of native AIS introduce unacceptable latency in detection and response cycles.

Our strategic recommendation is two-tier: maintain native AIS configuration as the compliance baseline, but layer a dedicated SAP security monitoring solution on top that ingests AIS logs, correlates them across systems, and provides continuous alerting. CyberSilo SAP Guardian is engineered specifically for this purpose—it connects to your existing AIS data sources, automates log ingestion, and applies threat detection models tuned to SAP-specific attack patterns. It reduces the time required for a comprehensive security review from weeks to hours while providing the real-time visibility that native AIS cannot deliver. For CISOs and SAP security architects evaluating their compliance posture in 2025, this layered approach offers the most cost-effective path to audit readiness.

Contact our security team to discuss how we can optimize your SAP security review process for your specific system landscape and compliance obligations.

Start Your Free SAP Security Assessment

Receive a detailed evaluation of your current SAP AIS configuration, compliance coverage gaps, and a customized roadmap for improvement — no commitment required.

Request Assessment Learn About SAP Guardian