1. Purpose

The User Onboarding & Authentication Procedure defines the process for securely onboarding new users and providing them with appropriate access to organizational systems, applications, information, cloud environments, and other resources.

The procedure ensures that:

• User identities are properly verified.
• Business roles and access requirements are established.
• Access is approved before provisioning.
• Authentication is securely configured.
• MFA is enabled where required.
• Users receive only the access necessary for their responsibilities.
• Security responsibilities are communicated.
• Onboarding activities are recorded and traceable.

Core Principle

Verify → Define Role → Assess Access → Approve → Create Identity → Configure Authentication → Provision Access → Verify → Record

---

2. Scope

This procedure applies to:

• Employees
• Contractors
• Consultants
• Interns
• Temporary personnel
• Third-party personnel
• Privileged users
• Other authorized users

It covers access to:

• Identity Provider/SSO
• Email
• SaaS applications
• AWS/Azure/GCP
• Source-code repositories
• CI/CD platforms
• Databases
• VPN
• Business applications
• Security platforms
• Customer environments
• Corporate devices
• File-sharing platforms
• Collaboration tools
• Physical facilities where applicable

---

3. Definitions

Term	Definition
User	Individual authorized to access organizational resources
Identity	Unique representation of a user in an authentication system
Authentication	Process of verifying a user’s identity
Authorization	Process of determining what an authenticated user may access
MFA	Multi-factor authentication
SSO	Single Sign-On
System Owner	Person responsible for a system/application
Data Owner	Person responsible for information/data
Sponsor	Internal person responsible for a contractor or third party
Privileged User	User with elevated administrative or sensitive access

---

4. User Onboarding Lifecycle

The standard onboarding lifecycle is:

HR/Contract Notification

→ Identity Verification

→ Role Definition

→ Access Requirement Identification

→ Risk Assessment Where Required

→ Access Approval

→ Identity Creation

→ Authentication Configuration

→ MFA Enrollment

→ Access Provisioning

→ Security Awareness

→ Access Verification

→ Asset Assignment

→ Record Completion

---

5. Onboarding Request

A formal onboarding request should be initiated before organizational access is provided.

The request should include, where applicable:

• User name
• Employee/contractor ID
• Department
• Job role
• Manager
• Employment/engagement type
• Start date
• End date for temporary personnel
• Business purpose
• Required systems
• Required information
• Required access level
• Privileged access requirement
• Customer-system access
• Cloud access
• Source-code access
• Contract/SOW for external users
• Required approvals

---

6. User Identity Verification

The organization should verify the identity of the person before creating an organizational identity.

For employees, verification may be performed through the approved HR onboarding process.

For contractors and third parties, verification should consider:

• Individual identity
• Organization
• Contract/SOW
• Internal sponsor
• Engagement period
• Business purpose
• Required systems
• Required access

The level of verification should be proportionate to the risk.

---

7. Role Definition

The user’s role should be established before access is provisioned.

Examples include:

• Software Developer
• DevOps Engineer
• IT Administrator
• Security Analyst
• HR User
• Finance User
• Customer Support
• Sales User
• Auditor
• Contractor
• AWS Administrator

The role should be used to determine the user’s baseline access requirements.

---

8. Access Requirement Assessment

Before providing access, determine:

• What systems does the user need?
• What information does the user need?
• What actions must the user perform?
• What access level is required?
• Does the user need customer data?
• Does the user need personal data?
• Does the user need production access?
• Does the user need privileged access?
• Does the user need customer-system access?
• Is the access temporary?

Access should be based on business need, not convenience.

---

9. Least Privilege

Users should receive only the minimum access necessary to perform their approved responsibilities.

For example:

A software developer requiring access to deploy application code does not automatically require unrestricted access to the production database.

Access should be:

• Role-based where practical
• Need-to-know
• Least privilege
• Environment-specific
• Time-limited where appropriate

---

10. Access Approval

Access should be approved before provisioning.

A typical approval flow is:

Manager/Business Owner

→ System Owner

→ Data Owner/Security where required

→ Authorized Approver

Additional approval may be required for:

• Production access
• Privileged access
• Customer-system access
• Restricted information
• Security systems
• Database administration
• Cloud administration

---

11. Identity Creation

After approval:

1. Create the user’s unique identity.
2. Use the organization’s approved identity-management system.
3. Assign appropriate groups/roles.
4. Record the identity.
5. Configure authentication.
6. Provision approved access.

Where practical, centralized identity management and SSO should be used.

---

12. Unique User Accounts

Each user should have an individually attributable identity wherever technically possible.

Users must not:

• Share accounts.
• Use another person’s credentials.
• Use another employee’s administrative account.
• Share administrator passwords.

Where a shared or generic account is technically unavoidable, it should be:

• Risk assessed.
• Approved.
• Controlled.
• Monitored where practical.
• Periodically reviewed.

---

13. Authentication Configuration

Authentication should be configured according to the organization’s Authentication & Password Policy.

Depending on system risk, authentication may include:

• Password
• SSO
• MFA
• Passkey
• Security key
• Certificate
• Other approved mechanisms

Higher-risk systems should receive stronger authentication protection.

---

14. Multi-Factor Authentication

MFA should be enabled where required by:

• Organizational policy
• Risk assessment
• System sensitivity
• Privileged access requirements
• Customer requirements
• Contractual requirements
• Regulatory requirements

MFA should receive particular attention for:

• Email
• Identity providers
• Cloud administration
• Privileged accounts
• Remote access
• Security systems
• Production environments
• Sensitive SaaS applications

---

15. Initial Authentication Setup

Initial authentication should be completed through an approved secure process.

The user should:

1. Receive secure account activation instructions.
2. Establish their authentication credential.
3. Enroll MFA where required.
4. Confirm successful authentication.
5. Report any authentication problem.

Initial passwords or activation information must not be sent through insecure channels.

---

16. Password Requirements

Password requirements are defined by the organization’s Authentication & Password Policy.

During onboarding:

• Users must create or establish their own credentials where practical.
• Passwords must not be shared.
• Passwords must not be stored in unsecured documents.
• Approved password-management mechanisms should be used.
• Temporary credentials should be securely handled.
• Authentication controls must not be bypassed.

---

17. MFA Enrollment Verification

The onboarding administrator should verify that:

• MFA is enabled where required.
• The MFA factor belongs to the correct user.
• The user can successfully authenticate.
• Recovery mechanisms are appropriately configured.
• Unnecessary authentication factors are not retained.

Actual MFA secrets, recovery codes, or private keys must not be stored in onboarding records.

---

18. SSO Configuration

Where SSO is available:

• Create the identity in the approved Identity Provider.
• Assign appropriate groups/roles.
• Enable MFA where required.
• Configure application access.
• Verify authentication.
• Record the configuration.

Example:

User → Identity Provider → MFA → SSO → Approved Applications

---

19. Application Access Provisioning

Application access should be provisioned only after approval.

Examples:

• Microsoft 365
• GitHub
• Jira
• CRM
• HR platform
• Customer-support platform
• Security platform

Access should correspond to the user’s approved role.

---

20. AWS User Onboarding

For AWS environments, human users should preferably authenticate through the organization’s approved identity provider and receive appropriate AWS roles.

Example:

User

→ SSO

→ MFA

→ AWS Identity Center / Approved Identity Mechanism

→ AWS Role

→ Required Resources

Long-lived access credentials for human users should be avoided where practical.

---

21. AWS Production Access

Production access should receive additional assessment.

Before granting production access, confirm:

• Business need
• Required resources
• Required permissions
• Environment
• Approval
• MFA
• Logging
• Monitoring
• Review/expiry requirement

Privileged production access should follow the Privileged Identity Management Procedure.

---

22. Source-Code Repository Access

For developers:

• Repository access must be approved.
• Access should be based on project responsibility.
• MFA should be enabled where required.
• Write permissions should be restricted.
• Administrative permissions should be limited.
• Production deployment permissions should be separately controlled where appropriate.

SSH keys and repository tokens must be securely managed.

---

23. CI/CD Access

CI/CD access should be assigned according to role.

Role	Example Access
Developer	Build/test/development
Senior Developer	Project development
DevOps	Deployment administration
Security	Security configuration/review
Release Manager	Release approval
Administrator	Restricted administrative access

Production deployment privileges should receive appropriate approval and control.

---

24. Database Access

Database access should be based on actual responsibilities.

Examples:

• Application → Application database role
• Developer → Development database
• DBA → Approved production administration
• Support → Limited/read-only access where required

Developers should not automatically receive unrestricted production database access.

---

25. Privileged User Onboarding

Before granting privileged access:

1. Identify the business requirement.
2. Define the required privilege.
3. Assess risk.
4. Obtain approval.
5. Create/enable the privileged identity.
6. Configure MFA/strong authentication.
7. Apply least privilege.
8. Configure monitoring where appropriate.
9. Record the access.
10. Schedule periodic review.

---

26. Contractor Onboarding

For contractors:

Contract/SOW

→ Identity Verification

→ Sponsor

→ Access Requirement

→ Risk Assessment

→ Approval

→ Identity Creation

→ MFA

→ Access Provisioning

→ Expiry/Review

Contractor access should have a defined end date where practical.

---

27. Third-Party User Onboarding

For third-party personnel:

• Verify organization and individual.
• Identify internal sponsor.
• Confirm contract/SOW.
• Confirm confidentiality requirements.
• Determine required systems and information.
• Assess security risk where required.
• Obtain approval.
• Create an individual identity.
• Enable MFA where required.
• Set expiry where appropriate.
• Record the identity and access.

Refer to the Third-Party Access Procedure.

---

28. Temporary Access

Temporary access should have:

• Defined purpose
• Start date
• Expiry date
• Owner
• Approval
• Defined permissions
• Review requirement

Temporary access should be automatically disabled or manually revoked when the approved period ends.

---

29. Customer-System Access

If the user requires access to a customer environment:

• Confirm authorization.
• Define business purpose.
• Limit access.
• Use individual authentication.
• Enable MFA where required.
• Avoid shared credentials.
• Monitor/log where appropriate.
• Remove access when the assignment ends.

Customer contractual requirements should also be considered.

---

30. Security Awareness During Onboarding

New users should receive appropriate security awareness training.

Topics may include:

• Password security
• MFA
• Phishing
• Social engineering
• Information classification
• Data handling
• Incident reporting
• Acceptable use
• Remote working
• AI security
• Secure information transfer
• Customer information protection

Additional training should be provided to high-risk roles where required.

---

31. Policy Acknowledgement

Users should acknowledge applicable organizational policies where required.

These may include:

• Information Security Policy
• Acceptable Use Policy
• Employee IT Usage Policy
• Information Classification Policy
• Data Handling Guidelines
• AI Acceptable Use Policy
• Remote Working Policy
• Other applicable security policies

Acknowledgement should be recorded.

---

32. Asset Assignment

Where organizational assets are provided, they should be formally assigned.

Examples:

• Laptop
• Mobile phone
• Security key
• Access card
• Monitor
• Other IT equipment

Asset assignment should be recorded in the appropriate asset-management records.

---

33. Onboarding Verification

Before closing the onboarding activity, verify:

• Identity created correctly.
• Correct user associated with identity.
• Authentication works.
• MFA works where required.
• Approved applications are accessible.
• Unapproved applications are not accessible.
• Privileged access is correctly configured.
• Production access is appropriately restricted.
• Device security is configured.
• Security training is completed/assigned.
• Policies are acknowledged where required.
• Asset records are updated.
• Identity Register is updated.

---

34. User Onboarding Record

The onboarding record may contain:

Field	Description
Onboarding ID	Unique reference
User Name	User
User ID	Organizational identity
Employee/Contractor ID	Reference
Department	Department
Job Role	Role
Manager/Sponsor	Responsible person
Start Date	Start date
End Date	If applicable
Employment Type	Employee/Contractor/etc.
Systems	Required systems
Access Level	Approved level
Privileged Access	Yes/No
MFA	Enabled/Not Required
Approvals	Approval references
Security Training	Status
Policy Acknowledgement	Status
Asset Assignment	Reference
Verification	Status
Completed By	Administrator
Completion Date	Date
Exceptions	If applicable

---

35. Authentication Verification Record

The onboarding record should capture verification status rather than sensitive authentication information.

Check	Status
Identity verified	Completed
Account created	Completed
SSO configured	Completed
MFA enabled	Completed
Password setup	Completed
Email access	Verified
SaaS access	Verified
AWS access	Verified
Privileged access	Not Applicable
Security training	Completed
Policy acknowledgement	Completed

Do not record:

• Passwords
• MFA secrets
• Recovery codes
• Private keys
• API keys
• Access tokens

---

36. Failed Onboarding

If authentication or provisioning fails:

• Do not bypass security controls.
• Record the issue.
• Escalate to IT/IAM.
• Re-verify the user if necessary.
• Correct the configuration.
• Re-test authentication/access.
• Record completion.

Temporary unrestricted access should not be granted merely to overcome provisioning delays.

---

37. Emergency Onboarding

Emergency access may be required during:

• Critical incidents
• Major outages
• Production failures
• Security incidents
• Business-critical situations

Emergency access should:

• Be authorized.
• Be limited to the required resources.
• Use strong authentication where possible.
• Be monitored where practical.
• Be time-limited.
• Be reviewed after use.
• Be documented.

---

38. High-Risk Role Onboarding

Additional controls may be appropriate for:

• Cloud administrators
• System administrators
• Database administrators
• Security personnel
• DevOps engineers
• Finance administrators
• Production administrators
• Personnel with sensitive customer-data access

Additional controls may include:

• Enhanced identity verification
• Additional approval
• Dedicated privileged identity
• Stronger MFA
• Role-specific security training
• Additional monitoring
• More frequent access review

---

39. Authentication Troubleshooting

If a user cannot authenticate:

1. Verify the user’s identity.
2. Confirm account status.
3. Check MFA status.
4. Check authentication configuration.
5. Check account lockout/throttling.
6. Review relevant logs.
7. Reset/reconfigure authentication through the approved process.
8. Confirm successful authentication.
9. Record the resolution where appropriate.

Support personnel must never request or record the user’s password.

---

40. Onboarding Security Incidents

Potential onboarding security incidents should be reported.

Examples:

• Identity created for the wrong person.
• Wrong access assigned.
• MFA registered to the wrong device.
• Credentials disclosed.
• Privileged access granted incorrectly.
• Customer access granted without authorization.
• Production access incorrectly configured.

Response:

Report → Contain → Correct → Assess → Verify → Record

---

41. Startup-Friendly Onboarding Workflow

A startup can implement a simple process:

Step 1 — Request

HR/Manager provides user and role information.

Step 2 — Verify

Confirm identity and employment/engagement.

Step 3 — Define Access

Identify required applications, systems, data, and environments.

Step 4 — Approve

Manager and relevant system/data owners approve.

Step 5 — Create Identity

Create the account in the approved identity provider.

Step 6 — Authenticate

Configure SSO/password and MFA.

Step 7 — Provision

Provide only approved access.

Step 8 — Secure

Issue secure device and provide security awareness.

Step 9 — Verify

Test authentication and access.

Step 10 — Record

Update identity, access, and asset records.

---

42. AWS SaaS Startup Example

A 40-person SaaS company hires a software developer.

Role

Software Developer

Required Access

• Microsoft 365
• GitHub
• Jira
• Development AWS account
• Development database

Not Required

• AWS production administrator
• Production database administrator
• Security-platform administrator

Process

HR

→ Identity verified

→ Manager approves role

→ Identity created

→ MFA enabled

→ SSO configured

→ GitHub access

→ Jira access

→ AWS development role

→ Laptop assigned

→ Security training

→ Access verified

→ Identity Register updated

This demonstrates role-based and least-privilege onboarding.

---

43. Roles and Responsibilities

Role	Responsibility
HR/People	Notify onboarding and provide verified user information
Manager	Define role and business access requirements
System Owner	Approve system access
Data Owner	Approve sensitive information access where required
IT/IAM	Create identity and configure authentication
Security/ISMS	Define security requirements and review high-risk access
Cloud Team	Provision cloud access
Application Owner	Provision application access
Asset Owner/IT	Assign organizational assets
User	Protect credentials and follow security requirements
Internal Audit	Independently verify onboarding controls

---

44. Evidence

Potential evidence includes:

• Onboarding requests
• HR onboarding records
• Identity verification records
• Access approvals
• User Access Requests
• Identity Register
• IAM/SSO configuration
• MFA enrollment records
• Application access records
• AWS IAM/Identity Center records
• Privileged Access Register
• Asset Handover Form
• Security training records
• Policy acknowledgements
• Access verification records
• Exception records
• Onboarding completion records

Passwords, MFA secrets, recovery codes, private keys, API keys, and other authentication secrets must never be retained as onboarding evidence.

---

45. Metrics

The organization may monitor:

• Number of users onboarded
• Percentage onboarded through the approved process
• MFA enrollment rate
• Onboarding exceptions
• Incorrect access assignments
• Onboarding-related security incidents
• Average onboarding completion time
• Number of privileged users onboarded
• Contractor accounts with defined expiry
• Incomplete onboarding records

Metrics should be used to identify control weaknesses and improvement opportunities.

---

46. Exceptions

Exceptions should be:

• Documented
• Risk assessed
• Approved
• Assigned to an owner
• Time-limited where practical
• Periodically reviewed

Examples:

• Legacy application does not support MFA.
• Customer system requires a different authentication mechanism.
• Temporary emergency access is required.

Compensating controls should be considered for higher-risk exceptions.

---

47. Relationship with Other ISMS Documents

This procedure connects with:

• Identity Management Policy
• Authentication & Password Policy
• User Account Management Procedure
• Identity Register
• Identity Review Checklist
• Joiner-Mover-Leaver Procedure
• Access Control Policy
• User Access Request
• Access Control Matrix
• Privileged Identity Management Procedure
• Privileged Access Register
• Contractor Account Procedure
• Third-Party Access Procedure
• Access Review Report
• Access Revocation Checklist
• IT Asset Handover Form
• Asset Ownership Register
• Information Classification Policy
• Security Awareness Training
• Acceptable Use Policy
• Employee IT Usage Policy
• Incident Response Plan

Control Chain

User Verification

→ Role Definition

→ Access Requirement

→ Approval

→ Identity Creation

→ Authentication

→ MFA

→ Access Provisioning

→ Verification

→ Review

→ Evidence

---

48. ISO 27001 Connection

This procedure supports applicable ISO/IEC 27001 requirements and controls relating to:

• Identity management
• Authentication information
• Access rights
• Access control
• Secure authentication
• Privileged access
• Personnel responsibilities
• Asset management
• Security awareness
• Supplier and third-party access

The specific controls applicable to the organization should be determined through the organization’s risk assessment and Statement of Applicability (SoA).

---

49. Quick Audit Checklist

User

• Identity verified
• Employment/engagement confirmed
• Role defined
• Manager/sponsor identified

Access

• Business need documented
• Access requirements identified
• Access approved
• Least privilege applied
• Sensitive access separately approved
• Privileged access separately controlled

Authentication

• Unique identity created
• SSO configured where appropriate
• Password configured securely
• MFA enabled where required
• Authentication verified

Security

• Security awareness completed/assigned
• Applicable policies acknowledged
• Device secured
• Data-handling requirements communicated

Records

• Identity Register updated
• Access records updated
• Privileged Access Register updated where applicable
• Asset Register updated
• Onboarding record completed
• Evidence retained

---

50. Final Audit Trail

For a newly onboarded user, the organization should be able to demonstrate:

Who is the user?

→ Was the identity verified?

→ What is the user’s role?

→ What access does the role require?

→ Who approved the access?

→ Was the identity created correctly?

→ How is the user authenticated?

→ Is MFA enabled where required?

→ Was only necessary access provided?

→ Was privileged access separately assessed?

→ Was security awareness completed?

→ Was access verified?

→ Were identity, access, and asset records updated?

→ Can the organization prove the onboarding was completed correctly?

Final Principle

A user should not receive access simply because they have joined the organization. The organization should verify who they are, understand what they need, obtain appropriate approval, establish secure authentication, provide only the necessary access, verify the configuration, and retain evidence of the complete onboarding process.