SAP Security Audit Checklist: Complete Guide for BASIS Administrators

If you manage SAP systems, you already know the drill — security isn’t a one-time project, it’s a daily discipline. But between user administration, transport management, and system performance, security audits often end up on the back burner. That’s a mistake I’ve seen cost organizations dearly.

In this guide, I’ll walk you through a complete SAP security audit checklist — the key transactions you need to know, what to check daily vs weekly vs monthly, and the best practices that keep your SAP landscape secure. Whether you’re prepping for an audit or building a security routine from scratch, this is your playbook.

What Is SAP Security Auditing?

SAP Security Auditing is the process of monitoring user activities, identifying security risks, ensuring regulatory compliance, and detecting unauthorized system access. It’s not just about ticking boxes for compliance — it’s about knowing exactly what’s happening in your systems at all times.

Think of it as the CCTV system for your SAP landscape. You don’t install cameras because you expect a break-in every day. You install them so that if something happens, you know who, when, and how.

Key Transactions for SAP Security Audits

Here are the essential transactions every BASIS administrator should have in their security toolkit:

Configuring the Security Audit Log (SM19)

The first step in any SAP security audit is making sure the audit log is actually switched on. You’d be surprised how many systems I’ve walked into where SM19 was never configured.

Transaction SM19 lets you:

• Enable Security Audit Logging for your system
• Configure which events to audit (logons, transactions, RFC calls)
• Set the audit log file size and retention period
• Define static and dynamic audit configurations

Events You Should Monitor

• User Logon / Logoff — every successful and failed attempt
• Failed Logon Attempts — critical for detecting brute force attacks
• Transaction Execution — especially sensitive transactions like SU01, SM30, SE38
• User Lock/Unlock Activities — who locked whom and why
• RFC Logins — system-to-system communication monitoring

Analyzing Audit Logs (SM20)

Once SM19 is configured, SM20 is where you actually review what’s happening. Regular SM20 analysis should be part of your weekly routine.

Key checks in SM20:

• Failed login attempts — look for patterns (same user, different IPs)
• Unauthorized access attempts — users trying transactions they shouldn’t
• Critical transaction usage — who ran SU01, SE16, SE38 recently
• User activity monitoring — unusual hours, unusual terminals

User Security Review with SUIM

SUIM (User Information System) is probably the most underutilized security tool in SAP. It gives you a wealth of reports for your SAP security audit:

Locked Users

Path: SUIM → Users → By Logon Data

Review all locked users regularly. A large number of locked accounts could indicate a brute-force attack in progress.

Users Without Roles

Path: SUIM → Users → Users By Complex Selection Criteria

Users without roles are either misconfigured or orphaned. Either way, they need attention.

Critical Users to Monitor

• SAP* — the super-user. Should only be used for emergencies.
• DDIC — the data dictionary owner. Lock this account after system setup.
• Emergency Users — firefighter IDs should have logged usage.
• Firefighter IDs — review their activity logs regularly.

As I covered in my SAP certificate renewal guide, maintaining secure access controls goes hand-in-hand with keeping your system certificates valid and trusted.

Failed Login Monitoring

Unexpected failed login patterns are often the first sign of a security issue. Use SM20 and SM21 together to get the full picture:

• Repeated Failed Logins — check for scripts or automated attacks
• Unauthorized Login Attempts — users trying to access after hours
• User Lock Events — too many failed attempts trigger auto-lock

The goal here is early detection. A brute force attack that runs for 48 hours before anyone notices is a failure of process, not technology.

Authorization Checks with SU53 and ST01

When users report authorization errors, don’t just add the missing object and move on. Use the data to identify patterns:

• SU53 — shows the last authorization error for a user. Quick diagnostic.
• ST01 — system trace for detailed authorization flow analysis.

For more on system tracing and diagnostics, check my post on SAP Tracing for Effective Troubleshooting.

Role and Authorization Review

Use PFCG and SUIM to run regular authorization reviews:

• Identify critical authorizations — SAP_ALL, SAP_NEW, S_ADMI_FCD
• Find unused roles — roles assigned to no users should be deleted
• Flag excessive privileges — does a junior user really need SAP_ALL?
• Check Segregation of Duties (SoD) — no single user should create a vendor and process an invoice

For a broader look at SAP security topics including IAS and Identity Authentication, see my SAP BTP and IAS FAQ post.

Daily Security Checklist

Here’s what you should be doing every day:

User Administration

• 📋 Review locked users
• 📋 Review failed login attempts
• 📋 Verify critical user activity (SAP*, DDIC, emergency IDs)

System Monitoring

• 🔍 Check SM21 system logs for security errors
• 🔍 Check SM20 security audit logs
• 🔍 Verify background jobs aren’t running suspicious programs

Authorization Monitoring

• 🔒 Analyze SU53 authorization failures
• 🔒 Review critical role assignments
• 🔒 Validate user access for terminated employees

Weekly Security Checklist

• 📅 Review inactive users (those not logged in for 30+ days)
• 📅 Remove unused roles and orphaned assignments
• 📅 Review critical authorization assignments
• 📅 Analyze audit logs for patterns
• 📅 Validate emergency access user usage
• 📅 Check password compliance (temporary passwords, password expiry)

Monthly Security Checklist

• 📊 Full user access review
• 📊 Comprehensive role review
• 📊 Compliance validation against your regulatory framework
• 📊 Security audit report generation
• 📊 Segregation of Duties (SoD) analysis
• 📊 Emergency user access review and recertification

SAP Security Best Practices

1. Enable Security Audit Logging — you can’t review what you didn’t record.
2. Review Critical Users Regularly — SAP* and DDIC should be locked unless actively needed.
3. Remove Inactive Users — terminated employees should be locked on their last day.
4. Monitor Failed Login Attempts — set up alerts for unusual patterns.
5. Follow the Least Privilege Principle — give users exactly what they need, nothing more.
6. Review Authorizations Periodically — roles change, users change roles. Keep up.
7. Perform Regular Compliance Checks — if it’s not documented, it didn’t happen.
8. Secure Emergency User Access — firefighter IDs should require approval and full logging.

For official guidance, refer to the SAP Security Audit Log documentation on the SAP Help Portal.

Security Audit Flow

Here’s how the complete audit process should flow in your organization:

User Activity
    ↓
Security Audit Log (SM19) — Capture everything
    ↓
Audit Analysis (SM20) — Review and investigate
    ↓
Security Review — Validate against policies
    ↓
Corrective Action — Fix issues found
    ↓
Compliance Reporting — Document for auditors

Conclusion

An effective SAP security audit program isn’t about complex tools or expensive software. It’s about discipline — having a clear checklist, running it consistently, and acting on what you find.

Start with the daily checks. Build up to weekly and monthly reviews. Automate where you can (SM19 configuration, SM20 alerts), and document everything for compliance.

The key transactions — SM19, SM20, SUIM, SM21, SU53 — are all you need to build a rock-solid security monitoring routine. Master these, and you’ll never walk into an audit unprepared.

What does your SAP security audit routine look like? Any transactions I missed? Drop a comment below or reach out — I’m always keen to learn how others approach this.