Fraud Risk along the Employee Lifecycle – Onboarding Turns Identity into Access
This article is the second deep dive in the Fraud Risk along the Employee Lifecycle article series.
The umbrella article introduced the Employee Lifecycle as a practical lens for identifying HR Fraud Risk across hiring, onboarding, role changes, incentives, access rights and offboarding.
The first deep dive, Identity Risk Starts in HR, focused on the earliest control-relevant question:
Who is this person?
This second deep dive moves one step further.
Once a person has been accepted as a legitimate organisational identity, the organisation must answer a different question:
What is this person now allowed to do?
That is the control significance of onboarding.
Onboarding does more than welcome a new employee, contractor or external user. It translates identity into operational capability. It assigns roles, activates accounts, grants access, connects the person to workflows, defines approval paths, issues equipment and places the person inside the organisation’s control environment.
In other words:
Identity creates presence. Onboarding creates capability.
And capability is fraud-relevant.
Onboarding as a Control Event
Onboarding is often treated as an administrative or operational process.
In practice, however, it is the point where the organisation turns a person record into operational capability.
Several control-relevant steps happen at this stage:
- identity, contract and employment status are confirmed
- roles and organisational assignments are recorded
- access requests are submitted and approved
- accounts, devices and collaboration tools are activated
- role templates and approval workflows are applied
- exceptions are granted, documented or left unresolved
From a Fraud Risk perspective, these are not merely onboarding tasks.
They are control decisions.
Onboarding determines whether a person can enter systems, see data, initiate transactions, approve workflows, influence master data, access confidential information or participate in control-relevant processes.
That conversion matters because many fraud schemes require more than intent. They require capability.
Capability may mean access to a finance system.
It may mean the ability to approve invoices.
It may mean visibility into payroll data.
It may mean permission to change supplier master data.
It may mean access to confidential customer information.
It may mean the ability to submit expenses, approve timesheets, create purchase requests, change bank details or override controls.
Onboarding is where many of these capabilities are first created.
From Identity to Role
The first control translation in onboarding is usually role assignment.
A person does not only become “active”. They become active in a role.
That role may be called a job title, position, function, employment type, project assignment or access profile. The terminology differs across organisations. The control logic is similar.
A role tells the organisation what the person is expected to do.
But it also tells systems and control owners what the person may be allowed to do.
This makes role assignment fraud-relevant.
A role can drive:
- system access
- workflow participation
- approval authority
- Segregation of Duties checks
- cost centre assignment
- reporting lines
- data visibility
- physical access
- training requirements
- policy obligations
- monitoring expectations
A role is therefore not only an HR attribute.
It is a control-relevant organisational fact.
If the role is wrong, incomplete, copied from another person or selected only for administrative convenience, downstream controls may start from the wrong assumption.
Access Provisioning Is a Fraud Control Surface
Access provisioning is one of the most underestimated Fraud Risk points in onboarding.
The reason is simple: access is often created by IT, but justified by HR and the business.
Identity and Access Management systems may provision accounts, assign groups, enforce authentication and remove access. But many access decisions depend on HR-driven information: employment status, role, organisational unit, manager, location, contract type and start date.
If the HR basis is wrong, the technical access process may still work exactly as designed.
The wrong person may receive access.
The right person may receive excessive access.
A contractor may receive employee-like access.
A temporary exception may become permanent.
A role template may grant more than the person actually needs.
This is why onboarding should not be reduced to account creation.
Access is not only about whether a user can log in.
It is about what organisational capability the user receives after login.
NIST Identity and Access Management describes Identity and Access Management as a capability that helps ensure the right people and things have the right access to the right resources at the right time. That formulation is useful for workforce environments because “right access” depends not only on technology, but also on role, status and organisational context.
This is where onboarding can create the conditions for later Access Rights Abuse, weak Segregation of Duties, Control Override, Override of Approval Limits or Data Manipulation.
The Risk of Access Templates
Role-based access templates are useful.
They make onboarding faster.
They reduce manual decisions.
They create consistency.
They can support standardisation, auditability and efficiency.
But they also create a specific Fraud Risk: the risk that an access template becomes a substitute for judgement.
A template may be outdated.
It may include legacy rights.
It may have been designed for a broader role than the person actually holds.
It may not reflect recent process changes.
It may include access rights that were added for convenience and never removed.
It may have been copied from a high-performing employee, a predecessor or a manager without considering whether the new joiner requires the same authority.
The problem is not the existence of role templates.
The problem is uncontrolled trust in them.
A role template should answer the question:
What access is required for this role?
It should not quietly become the answer to a different question:
What access did someone similar once have?
Initial Access Can Become Long-Term Risk
Onboarding is a high-pressure moment.
The new joiner is expected to become productive quickly. The manager wants no delay. IT wants complete requests. HR wants a smooth start. Business teams may treat access as urgent.
This creates a familiar pattern:
Access is granted “for now”.
Additional rights are added “just in case”.
A broad role profile is used “to avoid delays”.
Temporary access is granted “until the process is clarified”.
An exception is approved “because the person starts tomorrow”.
Each of these decisions may be understandable in isolation.
But the Fraud Risk arises when temporary access is not reviewed, broad access is not reduced and onboarding exceptions become part of the permanent control reality.
This is one reason why onboarding and later role changes are connected.
Access granted at onboarding can remain in the background for years. It may only become visible when the person changes role, moves departments, gains authority or exploits an old permission.
The risk is created early.
It may materialise much later.
Segregation of Duties Starts at Onboarding
Segregation of Duties is often discussed in relation to finance systems, procurement processes or ERP controls.
That is correct, but too late if the conflicting access has already been granted.
From an Employee Lifecycle perspective, Segregation of Duties should start at onboarding.
The question is not only whether a transaction was later approved by the right person.
The question is also whether the organisation prevented toxic combinations of access and authority from being created in the first place.
Examples include:
- creating suppliers and approving supplier payments
- changing vendor bank details and releasing payments
- entering invoices and approving invoices
- submitting expenses and approving expenses
- maintaining payroll data and approving payroll changes
- creating purchase orders and approving goods receipt
- administering user rights and approving own access
- changing master data and executing related transactions
These combinations may not create fraud by themselves.
But they reduce the need for collusion, weaken detective controls and make Control Override easier.
Onboarding is therefore a critical point for preventive Segregation of Duties controls.
Role, Access and Authority Are Different
A common weakness in onboarding is the failure to distinguish clearly between role, access and authority.
They are related, but not the same.
Role describes the organisational function.
Access describes what systems, data and workflows the person can use.
Authority describes what the person can decide, approve, release or override.
An employee may have access to a procurement system without authority to approve purchase orders.
A finance employee may see payroll data without authority to change bank details.
A manager may approve expenses without system administrator rights.
A project lead may influence spending without formal budget ownership.
Fraud Risk often appears where these distinctions are blurred.
The person may not formally “own” a process, but may have the practical ability to influence it.
The person may not be a system administrator, but may have enough access to change relevant data.
The person may not be the official approver, but may be able to route workflows, prepare approvals or influence the person who approves them.
Weakly governed approval authority can later support Control Override, Management Override of Controls or an Override of Approval Limits.
This is why onboarding should not only ask:
Which systems does this person need?
It should also ask:
What can this person do inside those systems?
And:
What decisions will the organisation accept from this person?
External Users: The Hidden Onboarding Gap
Some of the largest onboarding risks do not come from employees.
They come from people who are allowed to act like employees without being governed like employees.
Contractors, consultants, temporary staff, vendor users, outsourcing personnel and project-based external users may receive access that is operationally similar to employee access.
In some organisations, these users are onboarded outside standard HR processes.
They may enter through IT, Procurement, Vendor Management, a project office or a local business unit.
That can create fragmented ownership.
HR may not own the record.
IT may not know the business purpose.
Procurement may know the vendor but not the individual user.
The business manager may assume that someone else handles end dates, access reviews and offboarding.
This is where external access becomes a hidden onboarding gap.
External users should not fall between governance models.
They may not be employees in a legal sense, but they can still create employee-like risks: Access Rights Abuse, Audit Trail ambiguity, insider risk, Data Protection Law exposure, GDPR / DSGVO risk and residual access after the engagement ends.
At onboarding, every external identity should have at least:
- a named business owner
- a defined access purpose
- a defined start date
- a defined end date
- a clear role or assignment
- access limited to the mandate
- review obligations
- offboarding responsibility
Without these elements, external access can become a long-running control blind spot.
The Identity Lifecycle Management Playbook is useful in this context because it treats identity as something that must be created, modified, maintained and deactivated over time. That lifecycle view is directly relevant for contractors and other external users.
Onboarding and Zero Trust Thinking
The Employee Lifecycle Fraud Risk Lens is not a cybersecurity model.
But there is a useful connection to Zero Trust thinking.
NIST SP 800-207 Zero Trust Architecture explains Zero Trust as an approach that moves away from static, network-based assumptions and focuses on users, assets and resources. It also emphasises that authentication and authorization are discrete functions before a session to an enterprise resource is established.
For HR Fraud Risk, the practical lesson is not that every organisation must implement a full Zero Trust Architecture.
The practical lesson is simpler:
Access should not be granted because a person is “inside”.
Access should be granted because the person has a verified identity, a legitimate role, a current need and an appropriate level of authority.
Onboarding is where these conditions should first be tested.
Typical Role and Access Risk Scenarios
Role and access risks at onboarding can appear in different ways.
1. Excessive initial access
A new joiner receives broader access than required for the actual role.
This may happen because role templates are too broad, access is copied from another user or managers request access “just in case”.
2. Incorrect role assignment
The person is assigned to the wrong role, job family, organisational unit or employment category.
Downstream systems may then provision access based on an inaccurate control assumption.
3. Weak Segregation of Duties checks
Conflicting permissions are granted during onboarding because Segregation of Duties checks are incomplete, manual, bypassed or not connected to HR role data.
4. Unreviewed onboarding exceptions
Urgent access is granted before all standard checks are complete.
The exception is not tracked, reviewed or closed.
5. Contractor access without governance
External users receive employee-like access without equivalent sponsorship, review discipline, end dates or offboarding controls.
6. Approval authority granted too early
The person receives workflow approvals, signing rights, budget authority or release permissions before role, training, delegation or control ownership is clear.
7. Access without accountability
A person receives access, but no one owns the decision, reviews its continued appropriateness or understands the control impact.
8. Sensitive access in high-risk processes
A person receives access to Finance, Payroll, Procurement, HR Master Data, system administration or other High-Risk Process Exposure areas without enhanced review.
Weak onboarding controls can support payroll-related risks, including Ghost Employee scenarios, excessive access to payroll data or unauthorised changes to employee master data.
Red Flags
Role and access Red Flags at onboarding often appear as process shortcuts.
Individually, they may look efficient.
Together, they may indicate a weak access control environment.
Relevant Red Flags include:
- access granted before the employment or engagement is fully approved
- access requests submitted without a clear role or business purpose
- role templates that have not been reviewed for a long time
- access copied from another employee without documented justification
- broad access granted to avoid onboarding delays
- “temporary” access without expiry date
- emergency access not reviewed after activation
- missing Segregation of Duties checks
- Segregation of Duties conflicts approved without documented risk acceptance
- external users without named business owner
- contractors without end dates
- managers approving access they do not understand
- Privileged Access granted during standard onboarding
- access to Finance, Payroll, Procurement or HR systems without enhanced review
- mismatch between HR role, Identity and Access Management role and actual business function
- approval authority active before training or delegation is complete
- user accounts active before devices, contracts or role assignments are fully documented
None of these Red Flags proves fraud.
But each of them should trigger a control question.
Control Questions
A practical Fraud Risk Assessment can start with the onboarding moment.
Role assignment
- Who determines the role used for access provisioning?
- Is the role based on the actual function or on administrative convenience?
- Are role definitions current?
- Are sensitive roles clearly identified?
- Does the assigned role match the employment type, organisational unit and manager?
Access provisioning
- Which systems rely on HR data to create or approve access?
- Which access rights are automatically assigned during onboarding?
- Are access templates reviewed periodically?
- Can managers request access outside standard role profiles?
- Are access requests linked to business purpose and role necessity?
Segregation of Duties
- Are Segregation of Duties checks performed before access is granted?
- Do Segregation of Duties checks cover both system permissions and approval authority?
- Who can approve Segregation of Duties conflicts?
- Are conflict approvals documented and periodically reviewed?
- Are compensating controls defined where conflicts are accepted?
Authority
- When does a new joiner receive approval authority?
- Are approval limits linked to role, seniority, training or delegation rules?
- Can a person approve transactions before their role is fully confirmed?
- Are workflow permissions aligned with formal authority?
- Are manager changes reflected in approval paths?
External users
- Are contractors and vendor users onboarded through a controlled process?
- Does every external user have a named business owner?
- Are access purpose, scope and end date documented?
- Are external users included in access reviews?
- Is there a clear link between contract duration and access duration?
Exceptions
- How are urgent onboarding exceptions approved?
- Are exceptions time-limited?
- Who reviews them after onboarding?
- Are exceptions visible to Internal Controls, Compliance or IT Security?
- Are repeated exceptions analysed for process weakness?
Practical Control Measures
Role and access risk cannot be managed by a single approval.
It requires a chain of Internal Controls across HR, IT, business management, Compliance, Finance and Internal Controls functions.
Treat onboarding as an access control event
Onboarding should be recognised as the point where identity becomes operational capability.
The creation of access should be treated as a control decision, not as a technical follow-up task.
Maintain a role and access catalogue
Roles should be mapped to standard access profiles, approval rights, sensitive permissions and Segregation of Duties considerations.
This catalogue should be reviewed when processes, systems or organisational structures change.
Apply Least Privilege from the start
Initial access should be limited to what the person needs for the role.
Additional access can be granted later based on documented need.
This is usually safer than starting with broad access and trying to reduce it afterwards.
Review role templates periodically
Role templates should not be static.
They should be reviewed for obsolete rights, excessive permissions, Segregation of Duties conflicts and changes in business processes.
Separate request, approval and provisioning
The person requesting access, the person approving access and the person provisioning access should not be the same in sensitive cases.
This is particularly important for Privileged Access and finance-relevant systems.
Control onboarding exceptions
Urgent access may be necessary.
But exceptions should be documented, time-limited, risk-assessed and reviewed after the fact.
An exception without closure is not temporary access. It is unmanaged access.
Integrate Segregation of Duties checks early
Segregation of Duties should be checked before access is granted, not only after transactions occur.
Preventive checks are especially important in Finance, Payroll, Procurement, Master Data Management and system administration.
Define authority separately from access
Access to a system should not automatically imply approval authority.
Approval limits, delegation rights and workflow roles should be assigned and reviewed separately.
Include external users in the same control logic
Contractors and vendor users should not be outside the identity and access governance model.
Their access should be sponsored, scoped, time-limited and reviewable.
Preserve the Audit Trail
The organisation should be able to reconstruct who requested access, who approved it, which role was used, which template was applied, which exceptions were granted and which systems were activated.
Forensic Relevance
When a fraud case involves Access Rights Abuse, Vendor Fraud, Payroll Fraud, Expense Reimbursement Fraud, Procurement Fraud or Data Manipulation, the investigation often starts with the transaction.
Who entered the data?
Who approved the change?
Who released the payment?
Who accessed the system?
Who used the credential?
Those questions are necessary.
But the Employee Lifecycle Fraud Risk Lens adds an earlier question:
Why did this person have this capability in the first place?
Relevant evidence may include:
- HR onboarding records
- role assignment documentation
- access request tickets
- access approval records
- Identity and Access Management provisioning logs
- role template history
- Segregation of Duties check results
- exception approvals
- manager approvals
- workflow configuration
- approval authority matrices
- Privileged Access records
- training and delegation records
- contractor onboarding files
- system activation timestamps
- device issuance records
- access review results
This is especially important where the user acted through valid access.
A transaction may have been entered through a legitimate account.
A workflow may have accepted the approval.
A system may have allowed the change.
An Audit Trail may show a named user.
But the real issue may be upstream: the person should not have received that role, access right or approval authority in the first place.
Why This Matters
Onboarding is often seen as the start of productivity.
From a Fraud Risk perspective, it is also the start of operational capability.
That capability can be appropriate, proportionate and controlled.
Or it can be excessive, inconsistent and poorly governed.
The difference is not always visible at the moment of onboarding.
It may only become visible later, when access is misused, a control is bypassed, a conflict of duties is exploited or an external user remains active beyond the original purpose.
This is why onboarding belongs inside the fraud risk conversation.
Not because every onboarding weakness is fraud.
But because onboarding creates the access, role and authority assumptions that later controls rely on.
Conclusion
Fraud risk does not always start with a transaction.
Sometimes it starts when a legitimate identity is converted into excessive, unclear or poorly governed capability.
The first deep dive in this series focused on identity.
This second deep dive focused on what happens next.
Once the organisation accepts that a person exists here, onboarding determines what that person can do here.
Role assignment, access provisioning and approval authority are therefore not administrative details.
They are control-relevant facts.
If onboarding creates excessive access, unclear authority, weak Segregation of Duties or unmanaged external users, downstream controls may operate on a fragile foundation.
The Employee Lifecycle Fraud Risk Lens helps make this visible.
Before asking whether a transaction was properly approved, organisations should also ask:
Was the role correctly assigned, was access proportionate, and was authority properly controlled from the start?
Further Perspectives
This article is part of the Fraud Risk along the Employee Lifecycle series.
The umbrella article introduced the Employee Lifecycle as a practical lens for identifying Fraud Risk across hiring, onboarding, role changes, incentives, access rights and offboarding.
The first deep dive examined Identity Risk.
This second deep dive focused on onboarding, role assignment and access creation.
The next article will examine the Move phase: how role changes, internal transfers and reorganisations can create control drift, accumulated access and outdated authority.
Related Terms
- Internal Controls
- Fraud Risk Assessment
- Fraud Prevention
- Access Rights Abuse
- Segregation of Duties
- Control Override
- Management Override of Controls
- Override of Approval Limits
- Red Flags
- Audit Trail
- Data Manipulation
- Expense Reimbursement Fraud
- Ghost Employee
- Vendor Fraud
- High-Risk Process Exposure
- Data Protection Law
- GDPR / DSGVO
- Identity Fraud
- Employee Lifecycle Fraud Risk Lens
- Employee Lifecycle
- HR Fraud Risk
- Onboarding
- Identity and Access Management
- Access Rights
- Role-Based Access Control
- Least Privilege
- Privileged Access
- Approval Authority
- Contractor Risk
- Joiner-Mover-Leaver
- HR Master Data
- Data Integrity
- Payroll Fraud
- Procurement Fraud
- Zero Trust