Article by Prof. Hernan Huwyler, MBA, CPA, CAIO
AI GRC Director | AI Risk Manager | Quantitative Risk Lead
Speaker, Corporate Trainer and Executive Advisor
Top 10 Responsible AI and Risk Management by Thinkers360
How to examine personnel data, payroll controls, and access rights across SAP HCM with confidence and precision.
Auditing
an SAP Human Capital Management (HCM) environment is one of the most
consequential engagements an internal auditor or external reviewer can
undertake. Payroll errors, unauthorized access to employee records, and
misconfigured benefit plans can expose an organization to financial
loss, regulatory penalties, and reputational damage, all traceable to
configuration decisions buried deep in a system that most auditors never
fully explore.
This guide walks you through the major audit domains in SAP HCM in a logical, field-ready sequence. For each area,
you will find the specific transaction codes (T-codes) to use, the
tables and objects to examine, what to look for as a potential finding,
and practical recommendations you can bring back to management. Whether
you are new to SAP audits or refining an existing program, this guide
gives you a structured, repeatable approach that covers configuration,
authorization, and reporting controls.
A note on terminology: throughout this guide, references to the IMG mean the Implementation Guide, accessed via SPRO (System Customizing Implementation Guide).
The IMG is where nearly all SAP configuration lives, and access to it
is itself a significant control risk. Every section will remind you to
check who can get in there, because the person who can change
configuration often does not need to.
1. Enterprise Structure and Personnel Configuration
The
enterprise structure is the foundation on which everything else in SAP
HCM is built. Before a single employee record is created, the system
must know how the organization is structured: which company codes exist,
which personnel areas belong to those companies, and how employee
groups and subgroups are defined. When this foundation is poorly
configured or poorly controlled, every downstream process inherits the
problem.
What you are reviewing here is whether
the personnel areas (PA), personnel subareas (PSA), employee groups
(EEG), and employee subgroups (ESG) have been defined in a way that
reflects actual business requirements, and whether access to change
that structure is appropriately restricted.
Start by accessing the IMG to view the enterprise structure definition.
T-code: SPRO → Enterprise Structure → Maintain Structure → Definition → Human Resources
Then look at the underlying tables directly using SM31 (Table Maintenance):
- T500P — Personnel areas
- T501 — Employee groups
- T503K — Employee subgroups
- V_001P_all — Extended table maintenance for personnel areas
From an auditor's perspective, the key questions are: Do the
personnel areas map correctly to the company codes established in
Financial Accounting? Are employee groups defined with enough
granularity to support security, reporting, and processing rules? Are
there any orphaned or test structures left over from implementation that
were never cleaned up?
The authorization objects to examine are S_IMG_GENE (generate enterprise IMG), S_IMG_ACTV (perform functions in the IMG), and S_PRO_AUTH (new authorizations for projects). Run a user list from SU10
or using your security reporting tool to identify everyone who holds
these objects. A common finding is that a broad group of IT or HR staff
retained IMG access after go-live, far beyond the implementation team
that legitimately needed it.
SAP S/4HANA note: In S/4HANA, organizational structures are increasingly managed through the Organizational Management Fiori apps and the Business Partner model. The underlying table logic is similar, but auditors should also check the Manage Workforce
app permissions and the corresponding authorization roles in the Fiori
launchpad, as these can grant effective configuration access outside the
traditional IMG path.
2. Master Data Controls
Master data in SAP
HCM is the heart of the employee record. It covers everything from
hiring actions and personal information to bank details, recurring
payments, and organizational assignments. If someone can manipulate
master data without appropriate controls, the consequences range from
ghost employees on the payroll to unauthorized pay changes to concealed
conflicts of interest.
This domain covers several interconnected areas, each deserving its own attention.
Personnel Actions
Personnel
actions are the formal business processes that move employees through
the employment lifecycle: hiring, transferring, terminating, retiring.
In SAP, each action triggers a series of infotypes — structured screens
that capture the information needed to complete that action. The action
is initiated through PA40 (Personnel Actions), and the infotypes are maintained through PA30 (Maintain HR Master Data) and displayed through PA20 (Display HR Master Data).
When
auditing personnel actions, your first step is to review the action
menu configuration in the IMG and verify that the list of available
actions matches what the company has officially sanctioned. Then check
whether user groups have been configured to restrict which actions each
HR role can execute. An HR generalist responsible for onboarding should
not be able to process terminations, and vice versa.
The most important authorization object here is P_ORGIN (HR Master Data),
which controls access by infotype, personnel area, employee group,
employee subgroup, subtype, and organizational key. This granularity is
what makes SAP authorization both powerful and complex. A poorly
designed role that grants access to all infotypes with all authorization
levels is effectively giving a user full read and write access to every
employee record in the system.
Key infotypes to flag during your review include:
- IT 0000 — Personnel Actions
- IT 0001 — Organizational Assignment
- IT 0002 — Personal Data
- IT 0008 — Basic Pay
- IT 0009 — Bank Details
- IT 0014 — Recurring Payments and Deductions
- IT 0015 — Additional Payments
A common and serious finding is that users who enter or approve pay data also have access to run PA40
for terminations or rehires. This represents a segregation of duties
failure that could allow fraudulent manipulation of the employment
record without a compensating review.
T-codes to use: PA40, PA30, PA20, PA10 (Personnel File), PA70 (Fast Data Entry), SARP (HR Report Tree)
Infogroups and Dynamic Actions
Infogroups
define which infotypes appear — and in what sequence — when a personnel
action is executed. Auditors often overlook this area, but it matters
significantly. If the infogroup for a hire action omits the bank details
infotype, an employee could be set up in the system without a payment
method, creating a gap that payroll would have to work around manually.
Dynamic
actions are SAP's automated triggers: when a condition in one infotype
is met, the system automatically presents another infotype for data
capture. For example, if an employee's marital status changes in IT 0002
(Personal Data), the system should trigger the benefits enrollment
screen (PA90) to capture updated dependent information. If dynamic
actions are not correctly configured, these downstream processes fail
silently.
To review dynamic actions, navigate through SPRO
→ Personnel Management → Personnel Administration → Setting Up
Procedures → Create Dynamic Actions. Then actually test them: execute a
personnel action that should trigger a dynamic action and confirm it
fires correctly. Configuration that looks right in the IMG does not
always behave correctly at runtime.
Infotype Screen Control and Authorization
Screen
control allows the system to show or hide specific fields within an
infotype based on the user's role. This is an important privacy and
compliance mechanism. For example, fields containing Social Insurance
Numbers or date of birth should not be visible to users whose role does
not require that information.
To review screen controls, use SPRO
→ Personnel Management → Personnel Administration → Customizing User
Interface → Determine Screen Modifications. Then walk through key
infotypes manually using PA20 and PA30
and confirm that sensitive fields are being suppressed for roles that
should not see them. A finding here — sensitive fields visible to users
without a business need — can trigger obligations under privacy
legislation such as GDPR or applicable state and provincial privacy
laws.
The authorization object P_PERNR is worth
specific attention. This object controls whether a user can access their
own personnel number, and in many implementations, it is not
restricted, meaning an HR administrator or payroll clerk can view and
potentially modify their own record. This is a self-service risk that
should always be tested.
Organizational Key
The
organizational key (field VDSKI in IT 0001) provides a powerful
secondary layer of access control. It allows an administrator's access
to be restricted to only the employees assigned to them, going beyond
the coarser controls of personnel area and employee group. When properly
implemented, an HR business partner supporting a specific department
can only see and maintain records for employees in that department.
Review the organizational key setup through SPRO
→ Personnel Management → Personnel Administration → Organization Data →
Organizational Assignment → Set Up Organizational Key. Check tables T527 (organizational key control), T527A (creation rules), and T5270
(descriptions). Then test it: use a test user account that has an
organizational key restriction and attempt to access an employee outside
that restriction. The system should deny the access.
In many SAP
implementations, the organizational key is defined but never enforced —
meaning the configuration exists but the key is not actually assigned in
user master records. This is a common gap that provides a false sense
of security.
Menu Options, Objects on Loan, and Cost Distribution
Three additional master data areas deserve attention, though they are often skipped in routine audits.
Menu options accessible through PA30's auxiliary functions — including the ability to delete a personnel number (PU00), change payroll status (PU03), and change the date of hire (PA41)
— carry significant fraud risk. The ability to delete a personnel
number or change a hire date can be used to manipulate service
calculations, benefit entitlements, and payroll history. Access to these
functions should be extremely limited.
Objects on loan are tracked in IT 0040 and should be cross-referenced against IT 0032 (Internal Control) for asset number linkage and against IT 0014 (Recurring Payments/Deductions) for any associated perquisite deductions. Use PE03 (Feature Maintenance) to check feature ANLAC,
which controls the number of loan objects and asset number validation. A
common finding is that objects on loan are tracked inconsistently, with
no recurring deduction set up to reflect the taxable benefit value.
Cost distribution in IT 0027
is the mechanism that splits an employee's costs across multiple cost
centers or controlling objects. View this infotype through PA30
and confirm that the cost centers referenced are valid and match the
employee's actual organizational assignment. Mismatches between the cost
center in IT 0001 and the distribution in IT 0027 can produce incorrect
financial postings that financial auditors may catch only at period
close.
Master Data Reports
Master data reporting is a critical control layer, and access to certain reports is itself a risk. Reports like RPAUD00 (Logged Changes for Infotype Data)
provide an audit trail of who changed what in employee records and when
— this is your primary evidence source for investigating unauthorized
changes. Ensure this report is available to auditors and compliance
staff, and check whether change logging has been activated for all
sensitive infotypes.
Access to reporting is controlled through P_ABAP (HR: Reporting) along with P_ORGIN and P_ORGXX. Use SA38 (ABAP Reporting) and SE38 (ABAP Editor) to review which programs users can execute. A finding here is that broad access to SA38
effectively bypasses infotype-level authorization, because some reports
read HR clusters directly rather than going through the standard
authorization checks.
T-codes for reporting: PM00 (Personnel Administration Reporting), SA38, SE38, SARP
3. Organizational Management
Organizational
Management (OM) in SAP defines the formal structure of the company:
organizational units, jobs, positions, and the relationships between
them. It is tightly integrated with Personnel Administration (PA), and
when that integration is functioning correctly, a personnel action
automatically updates the organizational assignment of an employee. When
it is not, you end up with position data that contradicts what is in
the employee's master record.
PA/PD Integration
The
integration between Personnel Administration and Personnel Development
(Organizational Management) is controlled by a switch in the IMG. Verify
that this switch is active by navigating through SPRO →
Personnel Management → Organizational Management → Integration → Set Up
Integration with Personnel Administration → Basic Settings. Look for
the entry PLOGI/ORGA, it should have an "X" value indicating integration is active.
T-code: OOPS
can also be used to check integration settings directly. If integration
is off, organizational assignment changes made through personnel
actions will not flow through to the OM side, meaning position
assignments will be out of date. This matters for access control,
reporting, and succession planning.
Organizational Structure, Jobs, and Positions
The organizational structure should reflect the company's actual hierarchy. Use OOOE (Overview of Organizational Units) to browse the structure and PPOC (Create Organizational Units) or PO10 to examine individual units. For jobs, use PO03 (Create Job Object) and PSOC (Job Report Tree). For positions, use PO13 (Create Position Objects) and PSOS (Report on Positions).
When
reviewing positions, confirm that each position has the required
relationships established: position to job (object S to object C) and
position to organizational unit (object S to object O). Positions
without these relationships, known as unrelated objects, are a
maintenance and reporting problem. Use the organizational structure
drill-down in the OM detailed maintenance screen to identify unrelated
objects, or run report RHSTRU00 (Organizational Structure) through SA38.
A
common audit finding in this area is that positions are created for
reporting or security purposes but never properly linked to jobs or
organizational units, resulting in a fragmented org chart that does not
accurately represent the company.
T-codes to use: OOOE, PPOC, PO10, PO03, PO13, PP70, PP01, PPOM, PSOG, PSOO
Work Locations
Work centers (locations) in SAP OM are maintained through PO01 (Maintain Work Centers) and reported through PSOA (Reports on Work Centers).
The audit focus here is straightforward: do the work centers configured
in the system reflect actual company locations, and are they properly
linked to organizational units and cost centers? Misaligned work center
data can affect time management configuration, particularly the
assignment of personnel subarea groupings and public holiday calendars.
4. Payroll Controls
Payroll
is the highest-risk area in any SAP HCM audit. Errors here are not
theoretical — they result in employees being overpaid or underpaid,
incorrect tax remittances, and erroneous general ledger postings. The
audit approach in payroll requires both a configuration review and a
rigorous access control review, because the two risks reinforce each
other.
Payroll Accounting Areas
Payroll accounting areas
define the pay cycle groupings: which employees are paid together, on
what schedule, and under what processing rules. Review these using OH00 or through the IMG path: Payroll Accounting → Basic Settings → Payroll Organization → Check Payroll Accounting Area. Feature ABKRS defaults the payroll area assignment for each employee.
The
audit concern here is over-complexity. Too many payroll accounting
areas create unnecessary administrative burden and increase the risk of
an employee being assigned to the wrong area — leading to incorrect pay
frequency or missed payroll runs. The right number of payroll areas is
the minimum required to handle genuinely different processing rules.
T-code: PA03 (Personnel Control Record)
is essential in this area. It shows the current status of each payroll
area — open, released, or exited — and prevents retroactive changes when
a payroll area is in a released or exited state. Auditors should verify
that the control record process is being followed properly and that no
one is manually reversing the payroll area status to make retroactive
changes outside the normal correction process.
Pay Infrastructure and Wage Types
Wage
types are the building blocks of payroll calculation. They determine
how employees are paid, what deductions are taken, what is taxable, and
how everything posts to the general ledger. The authorization to create
and maintain wage types should be restricted to individuals who have no
responsibility for entering or approving pay — this is a fundamental
segregation of duties control.
Review the wage type catalog
through the IMG: Personnel Management → Personnel Administration →
Payroll Data → Basic Pay → Wage Types → Check Wage Type Catalog. The
relevant tables are V_512W_T (wage type texts), V_52D7_B (wage type groups), and T511 (wage type attributes).
Pay
particular attention to permissibility settings. SAP allows you to
restrict which wage types are available for which employee subgroups and
personnel subareas. If permissibility is not properly configured, a
user could manually enter a wage type that should not apply to a
particular employee — for example, a bonus wage type applied to an
hourly worker not eligible for bonuses.
Also review the payroll schemas and rules using PE01 (Personnel Calculation Schemas) and PE02 (Personnel Calculation Rules).
These define the logic that drives the payroll calculation engine.
Unauthorized changes to schemas or rules can silently alter payroll
results for large groups of employees. Access to PE01 and PE02 should be
treated with the same sensitivity as access to financial system
configuration.
T-codes to use: PE01, PE02, PE03, PCIK (Payroll Accounting Activities), SM31
Basic Pay and Other Payroll Data
Infotype IT 0008 (Basic Pay)
is the most sensitive infotype in the system. It stores salary rates,
pay scale assignments, and the pay scale groups and levels that drive
compensation. Review the authorization on this infotype carefully using P_ORGIN
with the infotype value set to 0008. Confirm that access is limited to
HR administrators whose job function requires it, and that payroll
clerks can read but not modify it unless that is an explicit business
requirement.
The self-access risk is particularly important here.
Auditors should always test whether employees — especially HR staff —
can access and modify their own IT 0008 record. Use a test user account
to attempt this, and confirm the system blocks it. P_PERNR controls this check, but it must be actively configured.
Other payroll infotypes requiring access control review include:
- IT 0009 — Bank Details (a classic target for payroll fraud)
- IT 0014 — Recurring Payments and Deductions
- IT 0015 — Additional Payments
- IT 0066 through IT 0068 — Garnishment Order, Debt, and Adjustment
- IT 0224 — Tax Information
Bank details deserve special mention. A user who can change IT
0009 without compensating review controls can redirect another
employee's pay to a personal account. This is one of the most frequently
observed payroll fraud mechanisms in SAP environments, and it is
preventable with proper authorization and a detective report that
identifies changes to bank details within the pay cycle.
T-codes to use: PA30, PC00 (HR Payroll Menu), PCIK, PA03
Running Payroll and Off-Cycle Payroll
The payroll run itself is executed through the payroll driver and managed through the payroll menu. Key T-codes include PC00 (HR Payroll Menu), PC1K (Payroll Menu for Canada),
and the simulation capability accessible through the payroll menu path.
Always verify that simulation runs are available and that auditors or
finance staff can run simulations without triggering an actual payroll.
Segregation
of duties in the payroll run process means that the person who
maintains employee master data (basic pay, bank details) should not be
the same person who initiates and releases the payroll run. Review the Personnel Control Record (PA03) to understand the release workflow, and map the user access against the org chart to confirm this segregation exists.
Off-cycle
payroll runs warrant particular scrutiny. These are by definition
exceptions to the normal cycle, and they carry a higher risk of
unauthorized payments — whether through adjustment checks, on-demand
checks, or manual checks. Run a list of all off-cycle runs in the audit
period and review the authorization and business justification for each.
The access to initiate off-cycle runs should be limited and
well-documented.
Key authorization objects for payroll: P_ABAP, P_TCODE, P_PCLX (payroll clusters PCL1 through PCL4), P_ORGIN, P_ORGXX, P_PERNR, S_TMS_ACT
Payroll Reports
Access to payroll reports is a proxy for access to payroll data. Reports like RPCALCKO (Payroll Simulation), RPCEDTKO (Remuneration Statements), and RPCLJNKO (Payroll Journal)
contain sensitive compensation information for all employees in a
payroll area. Restrict access through authorization groups assigned in SE38 and verify through the P_ABAP object.
A practical audit step: run SA38 and search for programs matching RPC* to see all payroll-related programs. Then cross-reference who has access to those programs via P_ABAP and determine whether that list is appropriate.
5. Time Management
Time
management in SAP HCM encompasses holiday calendars, work schedules,
time recording, absences, overtime, and attendance. It sits at the
intersection of HR, payroll, and operations — and errors here ripple
through into pay calculations, labor cost reporting, and compliance with
collective agreements.
Holiday Calendars and Work Schedules
The
public holiday calendar defines which days are recognized as holidays
and how employees are compensated for working on those days. Review the
calendar configuration through SPRO → Global Settings → Maintain Calendar, or use SCA1 (Display Public Holidays) and SCA2 (Display Public Holiday Calendar). Table THOL contains the holiday entries.
Auditors
should verify that the calendar accurately reflects the company's
recognized holidays by jurisdiction, particularly important in
organizations operating across multiple provinces or states where
statutory holidays differ. A single incorrect holiday class (full day
versus half day, for example) can result in systematic payroll errors
for every employee affected.
Work schedules are more complex. They
are built in layers: break schedules feed into daily work schedules,
which feed into period work schedules, which combine with employee
subgroup groupings and public holiday calendar assignments to produce
the work schedule rule recorded in IT 0007 (Planned Working Time). Use PT01 (Create Monthly Work Schedule), PT02 (Change), and PT03 (Display) to review schedules. Feature SCHKZ controls how work schedules default into IT 0007 based on employee subgroup.
The
audit question is whether work schedules adequately — but not
excessively — cover all the variations required by the workforce. Too
few schedules force workarounds. Too many create maintenance complexity
and inconsistency.
Tables to review: T550P (break schedules), T550 (daily work schedules), T551A (period work schedules), T508A (work schedule rules)
Time Recording
Time
recording in SAP captures exceptions to the standard work schedule:
absences, attendances, overtime, and substitutions. Data enters the
system either through direct entry in PA61 (Maintain Time Data) or through time recording terminals feeding into the HR cluster. The time evaluation driver RPTIME00 then processes this raw data into compensated hours and feeds results to payroll.
Audit
focus here centers on three risks. First, can a time administrator
change their own time records? This self-service risk — controlled via P_PERNR
— is a common finding. Second, are overlapping time entries detected
and rejected? SAP has built-in collision handling for infotype time
constraints, but these must be correctly configured. Third, is there a
clear workflow for supervisory approval of time entries, particularly
overtime, before data is passed to payroll?
Key infotypes in time
recording include IT 2001 (Absences), IT 2002 (Attendances), IT 2003
(Substitutions), IT 2004 (Availability), IT 2005 (Overtime), IT 2006
(Absence Quotas), and IT 2007 (Attendance Quotas).
T-codes to use: PA61, PA63, PA30, PA51 (Display Time Data), PT40 (Time Management Pool), PT60 (Time Evaluation), PT63 (Personal Work Schedule)
Absences, Vacation Tracking, and Overtime
Absence management and vacation tracking are closely linked. Leave types are defined in table T533 and flow into IT 0005 (Leave Entitlement). Absence quota type 99
must be assigned to vacation to ensure that vacation taken in IT 2001
automatically decrements the quota in IT 0005. Run report RPTLEA30 to verify that leave entitlements are being generated correctly.
A
frequent audit finding is that employees have taken more vacation than
their quota allows, with no system-enforced control preventing it. SAP
can be configured to warn or prevent over-quota absences, but this
requires explicit configuration of quota deduction rules. Check whether
these rules are active and whether someone is reviewing exception
reports regularly.
Overtime is recorded in IT 2005
and can trigger either additional pay or compensatory time, depending
on the wage type assigned. The audit concern is access: who can record
overtime in IT 2005? If employees can enter their own overtime without
supervisor approval in the system, the compensating control must be a
robust manual review process. Use PT40 (Time Management Pool) to view time management exceptions and pending approvals.
T-codes to use: PA61, PT40, PA53, SA38, SE38
Key reports: RPTABS20 (Absence & Attendance Overview), RPTLEA00 (Leave Overview), RPTCMP00 (Time Leveling)
SAP S/4HANA note: In SAP SuccessFactors integrated
environments, time and attendance data may be captured in SuccessFactors
Time Tracking and pushed to S/4HANA via integration middleware.
Auditors should verify that the integration mapping correctly handles
absence types and that quota balances reconcile between the two systems.
The Fiori app My Time Events and its underlying authorization objects in S/4HANA differ from the classic PA61 authorization model.
Time Evaluation
Time evaluation is the engine that converts raw time data into compensated results. Schemas and rules configured in PE01 and PE02
define how time is evaluated, which hours qualify for premiums, how
overtime thresholds are calculated, and how time balances are
maintained. Access to modify these schemas carries the same risk as
access to payroll schemas: unauthorized changes can silently alter how
every employee's time is calculated.
Year-end time processing adds
another layer of risk. Quotas must be transferred to the new year,
leave credits must be either carried forward or paid out per policy, and
calendars and schedules must be generated for the coming year. Use PT60 (Time Evaluation), PE01, and PE02 to review these processes. Table T511K/LVACR
controls the leave accrual constant (defaulting to 1.25 days per month
in standard SAP), verify this matches the company's policy.
T-codes to use: PE01, PE02, PT60, PT61 (Time Statement), PU22 (Archiving Results)
6. Compensation Management
Compensation
management controls how salary ranges are defined, how budget is
allocated for merit increases, and how compensation awards are processed
and activated. The key risk is that compensation changes bypass the
defined approval workflow and are entered directly into the system
without appropriate authorization.
Review the plan and budget setup using HRCMP0001, HRCMP0002, and HRCMP0003.
Ensure that plan periods are defined and that budget structures are
approved before increases are processed. The salary structure review
focuses on whether pay grade ranges accurately reflect the company's
compensation policy and whether any employees fall outside their
assigned grade range.
For the compensation process itself, HRCMP000
is the primary transaction for processing merit and incentive
increases. The workflow should include submission, approval, and
activation steps — and each step should be performed by a different
role. Auditors should verify that the person who submits an increase
cannot also activate it into the employee's basic pay record.
The
relevant infotypes for compensation management are IT 0008 (Basic Pay),
IT 0014 (Recurring Payments), IT 0015 (Additional Payments), IT 0025
(Appraisals), IT 0380 (Compensation History), and IT 0381 (Employee
Eligibility). Access to IT 0380 in particular provides a historical
record of all compensation changes — this is a useful evidence source
for auditors investigating unusual pay activity.
T-codes to use: PA30, PA97 (Compensation Matrix), PA98 (Administration — Salary Increase), PA99 (Release), HRCMP000
7. Benefits Administration
Benefits
administration in SAP HCM manages the definition of benefit plans,
enrollment of employees, vendor and cost configuration, and the
integration of benefit deductions with payroll. The complexity of this
area — especially when pre-tax and post-tax contributions, imputed
income, and contribution limits are involved — makes it a fertile ground
for both configuration errors and access control gaps.
The benefits configuration lives under SPRO → Personnel Management → Benefits. Note that to view the Benefits section of the IMG, users must have the parameter BEN added to their user parameters via SU52. This is itself a control — only those who need to configure benefits should have this parameter set.
Benefit Areas, Plans, and Eligibility
Benefit
areas define the top-level grouping (for example, US benefits versus
Canadian benefits) and control which payroll areas are associated with
each benefits configuration. Review the benefit area setup through the
IMG and feature BAREA. Then review the benefit programs, employee benefit groups, and plan year definitions under the Basic Settings section.
For
each plan type , health, insurance, savings, confirm that eligibility
rules have been configured correctly. The key control is that the
enrollment screen presented to an employee shows only the plans for
which they are eligible. If eligibility rules are misconfigured, an
employee could be enrolled in a plan they are not entitled to, or more
commonly, be excluded from a plan they should have access to. Use PA90 (Benefits Enrollment Screen) to test enrollment for sample employees and confirm that only eligible plans appear.
The ELIGR feature drives the assignment of eligibility rules to employees. Review this feature in PE03 and confirm its logic matches the company's benefit eligibility policy.
Vendors, Costs, and Default Plans
Benefit
providers or vendors should be set up in the system only after going
through the company's standard vendor selection process, including
competitive bidding where applicable. Verify that each benefit provider
in SAP corresponds to an approved vendor in the accounts payable system.
The cost formulas associated with each plan should be reviewed for
accuracy, particularly when plan costs change at the beginning of a new
plan year.
Default benefit plans, plans that employees are
automatically enrolled in without an active election, carry a specific
audit risk. If defaults are misconfigured, employees may be enrolled in
plans they did not choose, potentially triggering incorrect deductions
and benefit costs. Review default plan configuration through the IMG
under Flexible Administration and check tables T5UB6 (Health Plans) and T5UB7 (Insurance Plans).
T-codes to use:
PA90, PA85 (Employee Demographics), PA86 (Benefit Change), PA87
(Eligibility Change), PA91 (Enrollment Forms), PA93 (Benefits
Configuration), PA94 (Benefits Report Tree), SU52
Family Members and Enrollment Controls
Family and related persons data is maintained in IT 0021
and feeds directly into benefits enrollment for dependents and
beneficiaries. The types of relationships allowed in the system are
configured through the IMG, and they should reflect the company's
defined benefit eligibility for dependents. Unauthorized additions of
dependents, particularly in health plan and life insurance contexts, are a real fraud risk that auditors should test by reviewing IT 0021
changes during the audit period using RPAUD00.
8. Career, Succession Planning, and Recruitment
Career
and succession planning in SAP HCM identifies critical positions and
maps qualified candidates against them using qualification profiles. The
qualifications catalog, maintained through OOQA (Setting Up Qualification Catalog),
defines the skills and competencies against which positions and persons
are evaluated. The decay meter feature — maintained through OOHW, reflects the diminishing relevance of qualifications over time.
Audit
focus here is on data integrity and access. Who is responsible for
maintaining qualification objects and profiles? Is the qualification
catalog kept current, or are there qualifications that no longer exist
in practice but remain active in the system? Are succession planning
reports, particularly SAPMHTAQ (Succession Planning), restricted to authorized users?
T-codes to use: OOQA, OOHW, PP01, PSQ1 through PSQ8, PSR2 through PSR5
For
recruitment, the audit concern is whether the applicant administration
process supports segregation of duties: the person who creates a job
requisition should not also approve it, and the person who processes an
applicant hire should not have unrestricted access to manipulate the
applicant status throughout the selection process. Review applicant
status changes through the recruitment module and confirm that status
transitions follow the defined workflow.
9. Extended Checks: Change Logs, User Tables, and Double Verification
No SAP HCM audit is complete without a set of extended checks that cut across all the domains reviewed above.
RPAUD00 (Logged Changes for Infotype Data)
is the single most valuable report for a forensic or control review. It
shows every change made to HR infotypes, including who made the change,
when, what the old value was, and what the new value is. Run this
report for all sensitive infotypes (IT 0008, IT 0009, IT 0014, IT 0015)
over the audit period and look for changes made outside business hours,
changes that were quickly reversed, and changes made by users to records
in their own organizational area.
Employee number integrity
should be checked to ensure there are no duplicate records, no gaps in
the numbering sequence that suggest deleted records, and no personnel
numbers that appear in multiple payroll areas simultaneously. Use SE16 (Data Browser) to query personnel number tables directly.
Double
verification, sometimes called four-eyes control, should be
configured for the most sensitive changes. In practice, this means that a
change to bank details or basic pay entered by one user must be
explicitly confirmed by a second user before it takes effect. Verify
whether double verification has been activated in the system and, if so,
whether it is working as intended by testing a sample change and
observing whether the confirmation prompt appears.
User table access is the final frontier. Tables accessible through SM30 and SM31
contain configuration data that, if modified directly, can alter system
behavior without leaving the same audit trail as a standard
transaction. Run a list of users with access to table maintenance and
confirm this list is limited to basis and authorized configuration
staff.
T-codes for extended checks: SE16, SM30, SM31, SA38, RPAUD00, SU10
10. Performance Appraisals
Performance appraisals in SAP HCM
are not just an HR formality — they are a direct input into payroll.
When configured correctly, the results recorded in IT 0025 (Appraisals) automatically trigger changes to IT 0008 (Basic Pay),
moving an employee up or down a pay scale group and level chain based
on their appraisal outcome. This tight integration between performance
management and compensation is powerful, but it also means that a
misconfigured appraisal setup — or unauthorized access to appraisal
records — can produce unintended salary changes at scale.
The
configuration starts with defining the appraisal criteria themselves.
These are the dimensions on which employees are evaluated: problem
solving, quality of work, teamwork, and so on. Each criterion is defined
in table T513F and assigned a weight in table T513H.
Those weights default automatically into IT 0025 when an appraisal
record is created, so auditors should verify that the weights in the
table match the company's approved appraisal policy documentation.
Discrepancies between what the policy says and what the system
calculates are a frequent and underappreciated finding.
Appraisal criteria are further defined for specific main appraisal features using tables T510U_C and T5J59, and the grouping of personnel subareas and employee subgroups is controlled through tables T001P_L and T503_F.
The principle here is that employees who are evaluated against the same
criteria should be grouped together — so that pay scale group and level
chains can be applied consistently across comparable roles.
From a
security standpoint, the critical question is who can create or modify
IT 0025 records. Because appraisal results feed directly into basic pay
changes, unauthorized access to this infotype is effectively
unauthorized access to payroll. Use your authorization review of P_ORGIN
with infotype 0025 specified to generate the user list, and then
cross-reference it against the list of users with access to IT 0008.
Anyone appearing on both lists holds a significant segregation of duties
conflict — they can set the appraisal result and benefit from the pay
change it triggers.
Also confirm that the appraisal process is
being followed procedurally. The system can be configured correctly and
still be bypassed if managers are directly entering results without
going through the defined review and approval steps. Ask for a sample of
completed appraisal records and trace them back to the underlying
approval documentation.
Related infotypes: IT 0001 (Organizational Assignment), IT 0002 (Personal Data), IT 0008 (Basic Pay), IT 0025 (Appraisals)
T-codes to use: PA30 (Maintain Master Data), PA20 (Display Master Data)
Tables: T513F, T513H, T5J12, T510U_C, T5J59, T001P_L, T503_F
11. Recruitment
The
recruitment module in SAP HCM manages the full applicant lifecycle —
from vacancy creation and advertising through applicant administration,
selection, and ultimately conversion to an employee record. Because
recruitment sits at the boundary between the outside world and the HR
system, it carries specific risks around data integrity, unauthorized
access to applicant information, and the integrity of the hire decision
itself.
Integration Settings and Applicant Number Control
The
first thing to verify in a recruitment audit is whether the module is
properly integrated with Personnel Administration (PA) and
Organizational Management (PD). This integration is controlled by the
same PLOGI/ORGA switch reviewed in the Organizational
Management section. When integration is active, internal applicants can
have their existing employee data made available in the recruitment
process — controlled by feature PRELI — and employee data from the administration side is available for recruitment processing via feature PRELR.
Feature NUMAP
controls whether applicant numbers are assigned internally by the
system or entered manually. Internal assignment is always preferable
from a control standpoint: manual number assignment creates the risk of
duplicate applicant records or deliberate manipulation of applicant IDs
to obscure a candidate's history in the system.
To verify these settings, navigate through SPRO
→ Personnel Management → Recruitment → Basic Settings → Set Up
Integration with Personnel Administration. Also check the number range
configuration for applicant numbers, which defines the valid range and
whether gaps are allowed.
Vacancy Management and Advertising
In SAP, a vacancy formally triggers the recruitment process. If integration with Organizational Management is active and IT 1007 (Vacancy)
is enabled, every unfilled position flagged as vacant automatically
enters the recruitment pipeline. Auditors should verify whether IT 1007
has been activated and whether the vacancy status on positions is being
kept current — an organization with hundreds of positions marked as
vacant when only a handful are actively being recruited creates noise
that obscures legitimate openings and can complicate headcount
reporting.
Each vacancy in the system is assigned a personnel
officer, a line manager, and a staffing status. Confirm that these
assignments are complete and accurate. A vacancy with no assigned
personnel officer has no designated owner, meaning no one is formally
accountable for the recruitment process for that position.
Recruitment instruments and media — the channels through which positions are advertised — are defined in the IMG under SPRO
→ Personnel Management → Recruitment → Workforce Requirements and
Advertising. Review whether the media and instruments configured reflect
the company's actual recruiting practices, and whether there are any
active advertising channels that are no longer in use but have not been
deactivated.
Menu path for vacancy maintenance: Human Resources → Personnel Management → Advertising → Vacancy → Maintain
Applicant Administration and Selection
Applicant data is maintained through PB30 (Maintain Applicant Master Data),
the recruitment module's equivalent of PA30. Applicants are classified
by applicant group (differentiating temporary versus permanent, external
versus internal) and applicant range (further classification within the
group). These groupings can be used to restrict access — an HR
recruiter responsible for external hiring should not have access to the
files of internal applicants who have applied for positions under a
different business unit's purview.
The infotypes involved in applicant administration closely mirror the employee master data structure:
- IT 4001 — Applications
- IT 4000 — Applicant Events
- IT 4002 — Vacancy Assignment
- IT 4004 — Change Action Status
- IT 4005 — Applicant's Personnel Number
Additional data captured during the recruitment process includes
IT 0022 (Education), IT 0023 (Previous Employment), and IT 0024
(Qualifications) — the last of which feeds directly into the
qualifications catalog if the Career and Succession Planning module is
integrated.
The selection process — comparing applicant
qualifications against position requirements — uses the same
qualifications catalog infrastructure reviewed in the Career and
Succession Planning section. Auditors should confirm that selection
decisions are documented in the system and that the applicant status
trail in IT 4004 reflects the actual decision sequence. A candidate who
moves from "In Process" to "Hired" without intermediate status records
may indicate that the formal selection process was bypassed.
Key authorization objects: PLOG, P_APPL (Applicant), P_PCLX
T-codes to use: PB30, PA30, SPRO (IMG)
12. Training and Development
Qualifications and Course Administration
The
Training and Development module in SAP HCM manages the formal
connection between employee competencies and business requirements.
Qualifications are the skills, certifications, and competencies attached
to employees and positions. When a qualification expires or decays
below a required proficiency level, the system should flag it for
renewal. When an employee completes a training course, their
qualification record should be automatically updated to reflect the new
or refreshed competency.
The qualifications catalog is the
foundation of this module. It must be defined and configured before
qualifications can be assigned to positions or employees. Key tables
include P1000 (object descriptions), P1001 (relationships between objects), and P1025 (the decay meter, which defines the lifespan of a qualification before it needs to be recertified). Report RHXQCATO
provides an overview of the qualifications catalog and is a useful
starting point for reviewing whether the catalog is current and
well-maintained.
T-code: PO11 is used to maintain
qualification objects. During the audit, review whether qualifications
attached to high-risk or regulated roles — safety certifications,
professional licenses, compliance training completions — are being
tracked with appropriate decay meters and renewal workflows. A
qualification catalog that is never updated becomes a compliance
liability rather than a control.
Course administration is managed
through a set of business event transactions. Training programs are
defined as business event types (PO04), with resources (instructors, rooms, materials) and costs attached. Individual events are planned using PV10 and created using PV11. Attendance bookings, cancellations, and rebookings are managed through PV15, which also handles the transfer of learning objectives to the attendee as qualifications upon course completion.
Cost transfer to Controlling is handled through PVIC,
which posts training costs to the relevant cost centers. Auditors
reviewing training and development should confirm that costs are being
transferred correctly and that the cost assignment matches the
organizational unit of the attendee rather than a generic training cost
center.
A common finding in this area is that the qualifications
module is configured but not maintained — qualifications are assigned to
positions at implementation and never updated as job requirements
evolve, and course completion records are not consistently loaded into
the system. The result is a qualification profile that looks complete on
paper but does not reflect reality.
T-codes to use: PO04, PV10, PV11, PV15, PVIC, PO11, OOQA
Key authorization objects: PLOG, P_ORGIN, P_TCODE
13. PD Authorizations and Structural Security
Understanding Structural Authorizations
Standard
SAP authorization — the profile and role-based access control reviewed
throughout this guide — works by restricting what a user can do based on
transaction codes, infotypes, and organizational fields. Structural
authorization adds a second dimension: it restricts which objects in the
organizational hierarchy a user can access based on their position in
that hierarchy.
When structural authorizations are active, a
user's access to positions, organizational units, and persons is
determined by a structural profile that defines a root object and an
evaluation path through the organizational structure. A regional HR
manager, for example, might have a structural profile rooted at their
regional organizational unit, giving them access only to positions and
persons within that region — even if their standard authorization role
would otherwise allow broader access.
This makes structural
authorization a powerful and important control in large organizations
with complex hierarchies. But it also requires careful maintenance: if
organizational structures change and structural profiles are not
updated, users may retain access to organizational units they no longer
support, or lose access to ones they now do.
Structural authorizations are activated by running report MPPAUTSW, which sets the authorization switch in the system. Verify that this has been done by checking tables T77PS and T77UA through SM31
or the IMG path: Personnel Management → Organization Management → Basic
Settings → Authorizations Management → Structural Authorizations.
Profiles are maintained through OOSP (Maintain PD Profiles) and assigned to users through OOSB (Assign PD Authorization). A profile can also be attached directly to a position through PO13,
meaning it takes effect automatically for whoever holds that position —
an elegant approach that reduces the maintenance burden when people
change roles.
The link between an employee's HR record and their system user account is established through IT 0105 (Communications), specifically the system user name subtype. Report RHPROFLO
maps authorization profiles to system user names and is a useful
cross-reference tool for auditors verifying that structural profiles are
correctly assigned.
T-codes to use: OOSP, OOSB, PO13, PP70, SA38, SM31
Key authorization objects: PLOG, P_ORGIN, S_PROGRAM
When
auditing PD authorizations, the central questions are whether
structural authorization is actually in use, whether profiles are
correctly rooted in the organizational hierarchy, whether there is a
documented process for updating profiles when the organization changes,
and whether someone is formally responsible for creating and maintaining
those profiles. In many implementations, structural authorization was
activated at go-live and then effectively abandoned — profiles exist but
are never reviewed, and organizational changes flow through without
triggering corresponding profile updates.
SAP S/4HANA note: In S/4HANA environments using SAP
SuccessFactors for talent management, structural authorization concepts
carry over but are implemented differently in the Fiori-based role
model. The Business Role Management app and IAM (Identity and Access Management)
framework in S/4HANA replace some of the traditional T77PS/T77UA
table-based controls. Auditors should verify whether structural
authorization is enforced at the S/4HANA layer, the SuccessFactors
layer, or both — and whether there are gaps at the integration boundary.
14. Extended Security Checks
The final audit
domain pulls together a set of checks that cut across the entire SAP
HCM system. These are the controls that catch what everything else
misses — the edge cases, the residual access risks, and the evidence
trail that allows you to reconstruct what happened when something goes
wrong.
Extended Master Data Check and P_ORGXX
The authorization object P_ORGXX
enables an extended check on HR master data based on administrator
field assignments in IT 0001. This is not active in the standard SAP
system and must be explicitly turned on by running program MPPAUTSW and setting the AUTH_SW
switch — typically done by the ABAP development team. When active, it
restricts access to employee records based on who is designated as the
HR administrator, time recording administrator, or payroll administrator
for that employee in IT 0001.
The administrator assignments are:
- SACHP — HR Master Data Administrator
- SACHZ — Time Recording Administrator
- SACHA — Payroll Administrator
- SBMOD — Administrator Group (defined through feature PINCH)
This mechanism provides a very granular, person-level access
control that supplements the coarser personnel area and employee group
controls of P_ORGIN. To test whether it is working,
transfer a test employee to a different department and then attempt to
access that employee's record using a user account linked to the
previous department's administrator. The system should deny access.
The
audit question here is whether this level of control is actually
required and whether, if it has been activated, it is being maintained
correctly. Administrator field assignments in IT 0001 are only as
current as the last time someone updated them — and in practice, they
often lag behind organizational changes.
Employee Number Security and P_PERNR
Authorization based on personnel number, controlled through P_PERNR,
allows access to be restricted to specific employee records — most
commonly an employee's own record. This is the mechanism that enforces
the rule that employees cannot view or modify their own salary or time
data.
The check is not active by default. To activate it, run program MPPAUTSW through SE38 and turn on the AUTH_SW switch. The relevant field values in the P_PERNR object are:
- AUTHC — Authorization level (read, write, etc.)
- INFTY — Infotype
- SUBTY — Subtype
- PSIGN — Interpretation of the user/personnel number assignment: "I" gives authorization for the assigned personnel number only; "E" gives authorization for all personnel numbers except the assigned one
The assignment of user names to personnel numbers is maintained in table V_T513A, viewable through SM31.
Auditors should pull this table and verify that every HR, payroll, and
time management user has a personnel number assignment that correctly
restricts their self-access.
A practical test: identify a payroll
administrator in the system, log in as that user (or use a test account
with the same profile), and attempt to access that administrator's own
IT 0008 Basic Pay record. The system should block it. If it does not,
P_PERNR is either not active or not correctly configured.
T-codes to use: SE38, SM31, SA38
Key authorization objects: P_ORGIN, P_ORGXX, P_PERNR
Double Verification
The
double verification concept in SAP HCM provides a formal two-person
approval requirement for sensitive data changes. The first person enters
data into a locked record at authorization level E (entry). A second person then reviews and approves the change by unlocking the record at authorization level S (supervisor) or D (display and approve). The record cannot proceed to payroll processing until it has been through both steps.
This
control is most valuable for high-risk transactions: additional
earnings entered in IT 0015, bank detail changes in IT 0009, and manual
time entries that affect overtime calculations. Verify whether double
verification has been configured for these infotypes and test it by
entering a change as a level-E user and confirming that the record is
locked pending approval.
To review the profiles of HR and payroll
users and verify their authorization levels, navigate through Tools →
Administration → User Maintenance → Users, enter the username, and
display the associated profiles. Drill into each profile to confirm that
authorization levels are correctly assigned — no single user should
hold both level E and level S or D for the same infotype and
organizational scope, as this would allow them to enter and approve
their own changes.
Change Log Monitoring: List Changes
The
history tables for user master, authorization, and profile changes are
among the most important evidence sources available to an SAP auditor.
They record who changed what in the security configuration and when —
making them essential for both ongoing monitoring and incident
investigation.
The key history tables are:
- USH02 — Change History for Logon Data
- USH04 — Change History for Users
- USH10 — Change History for Profiles
- USH12 — Change History for Authorizations
Access these tables through SE16 (Data Browser) by entering the table name directly, or use SE17 (General Table Display). The change document transactions provide a more structured view: SU01
for profile changes, and the change documents menu path under Tools →
Administration → User Maintenance → Repository Infosys for user and
authorization changes.
During the audit, review these tables for
the period under examination and look for changes made outside business
hours, changes made immediately before or after a payroll run, and
changes to highly privileged profiles or roles. Also look for changes
that were quickly reversed — this pattern can indicate someone
temporarily elevated their own access to perform an unauthorized action
and then removed the evidence from the current state.
T-codes to use: SE16, SE17, SU01
User Tables and Critical Access Reports
The
final set of checks uses SAP's built-in user reporting capabilities to
provide a comprehensive view of who has access to what across the
system.
The most important user tables are:
- USR01 — User Master (current active users)
- USR04 — User Modification Data and Number of Profiles
- USR11 — Profiles assigned to users
- USR12 — Authorization values
To get a complete listing of all user tables, navigate to SE16, enter USR*
in the table name field, and use the dropdown to display all tables in
the USR namespace. Similarly, all user-related reports can be found by
entering RSUSR* in SA38.
The two most critical user reports for an SAP HCM audit are:
RSUSR001
— Lists all currently active users in the system. Run this and compare
it against the company's active employee list. Any system user without a
corresponding active employee record is a potential ghost account and
should be investigated immediately.
RSUSR005 —
Lists users with critical authorizations. This report can be configured
to flag specific authorization object and field value combinations that
the company has defined as high-risk. If this report has not been
configured with a meaningful critical authorization profile, recommend
that as a remediation action.
One check that should never be skipped: search for any user in the production environment with the profile SAP_ALL.
This profile grants unrestricted access to every transaction and every
object in the system. It should exist only in development and sandbox
environments for technical testing purposes. Finding it in production —
on any account, including technical or basis accounts — is a critical
finding requiring immediate remediation.
To view the full range of
user access information, navigate through Tools → Administration → User
Maintenance → Repository Infosys and explore the sub-menus for Users,
Profiles, Authorization Objects, Activity Groups, Transactions,
Comparisons, Where-Used Lists, and Change Documents. This menu structure
gives you a complete picture of the authorization environment and is
where experienced SAP auditors spend a significant portion of their
fieldwork time.
T-codes to use: SE16, SE17, SA38, SU01, SU10
Key reports: RSUSR001, RSUSR005
Essential SAP Audit & HR Resources
SAP Trust Center: Compliance and Audit Reports
- Why you need it: This is the ultimate starting
point for IT and compliance auditors. The SAP Trust Center provides
official, downloadable SOC 1, SOC 2, and ISO audit reports for SAP’s
cloud environments (including SuccessFactors). It is essential for
verifying third-party assurances and understanding SAP's shared
responsibility model.
SAP Help Portal: SAP ERP Human Capital Management (HCM)
- Why you need it: For organizations still running
on-premise SAP HR, this is the official documentation hub. Auditors
should bookmark this page to cross-reference standard Infotypes, backend
tables, and traditional T-codes (like PA30 and PT60) when verifying
system configurations against business policies.
SAP Help Portal: SAP SuccessFactors HCM Suite
- Why you need it: As noted in our audit guide,
modern HR processes like Recruitment and Performance Appraisals have
heavily migrated to the cloud. This portal provides the official
technical documentation necessary to audit SuccessFactors' role-based
permissions (RBP), APIs, and S/4HANA integration points.
SAP Community: Governance, Risk, and Compliance (GRC)
- Why you need it: The SAP Community is an invaluable
resource for real-world audit scenarios. The GRC topic page is filled
with expert discussions, blogs, and Q&As regarding Segregation of
Duties (SoD) conflicts, structural authorizations, and mitigating
insider threats using SAP Access Control.
SAP Security Baseline Template (SAP Support Portal)
- Why you need it: SAP publishes an official
"Security Baseline Template" (often referenced via SAP Note 2253549)
that details the absolute minimum security configurations every SAP
system should have. Auditors can use these official baselines to measure
a client's password policies, extended security checks, and
authorization limits.
ISACA: IT Audit Frameworks and SAP Audit Programs
- Why you need it: ISACA is the global gold standard
for IT auditing. While not an SAP-owned site, ISACA provides
independently developed, peer-reviewed SAP ERP audit programs and
frameworks (like COBIT). Auditors should leverage ISACA's whitepapers to
align their SAP HR and financial audit procedures with globally
recognized risk management standards.
Closing Thoughts
Auditing
SAP HCM effectively requires a combination of technical literacy and
process understanding. The T-codes and tables in this guide give you the
access points, but the judgment calls, the pattern recognition, and
the ability to connect a configuration gap to a business risk are what
separate a meaningful audit from a checkbox exercise.
A few principles to carry through every section of this work:
The
IMG is the master key to the SAP HCM kingdom. Anyone with broad IMG
access can change virtually any configuration setting. Always start your
audit by identifying who has S_IMG_GENE and S_IMG_ACTV in their profiles, and treat that list as a high-risk population requiring additional scrutiny.
Self-access
to HR records, the ability of an employee, administrator, or manager
to view or modify their own data — is a recurring control gap. Test it
in every domain. P_PERNR is the authorization object that should be preventing it, but it is frequently misconfigured or omitted.
Change logging is your evidence. RPAUD00
should be running, and its output should be reviewed regularly by
someone independent of the HR and payroll teams. If change logging is
not activated for sensitive infotypes, recommend it as a priority
remediation.
And finally, keep your findings in context. SAP HCM
is a complex, deeply configurable system, and most organizations
implement only a portion of its capabilities. What matters is not
whether every feature is used, but whether the features that are in use
are properly controlled, and whether the controls in place are actually
working.
This guide was developed by Hernan Huwyler as a
practical reference for internal auditors, external reviewers, and
compliance professionals working in SAP HCM environments. It is intended
to support audit planning, fieldwork execution, and finding development
across the full scope of the HR module.
