---

The on and off boarding process for users is an important consideration for any IT system. A sound on and off boarding process ensures that users can only access what they need to access, the user is authenticated and access can be revoked as required. The on boarding process ensures that users are authenticated and 'Principle Of Least access Privilege' (POLP) is applied (POLP works by allowing only enough access to perform the role / required task).

The registration / approval process can be segregated by permissions and roles to maintain system (and data) access integrity. System permissions ensure duties are segregated throughout the system and data access. Additionally, when a user has been added, a 2nd step of authentication can be included as required. The off boarding process ensures that data privacy and integrity is maintained - Users should be denied access to the system as soon as their access is no longer relevant.

The prime on and off boarding process and features align with the ISO 27002 Code of Practice (clause 9 'Access Control'), providing effective security practices;

Code of Practice Clause	Sub-Clause	PRiME controls
A.9.1 Business requirements of access control	A.9.1.1 Access control policy	Documented in the finao confluence space System Admin vs Admin vs Module Admin POLP Off-boarding process
	A.9.1.2 Access to networks and network services	N/A
A.9.2 User access management	A.9.2.1 User registration and de-registration	User registration workflow (on-boarding) Admin assigns role (according to POLP) Form history and system logs Off-boarding process (including inactive and deactivated user management)
	A.9.2.2 User access provisioning	Access rights per role is periodically reviewed Role and associated access is documented Only System Admin can assign 'high risk' roles (privileged accounts)
	A.9.2.3 Management of privileged access rights	Only System Admin can assign privileged accounts System Admin vs Admin vs Module Admin Role access is periodically reviewed
	A.9.2.4 Management of secret authentication information of users	Password policy (10 characters using alpha numerics and special characters) Code sent by text for authentication / authorisation
	A.9.2.5 Review of user access rights	Roles and access rights per role is periodically reviewed
	A.9.2.6 Removal or adjustment of access rights	Off-boarding process (including inactive and deactivated user management)
A.9.3 User responsibilities	A.9.3.1 Use of secret authentication information	On-boarding process can include acknowledgement of ISP / terms of use etc
A.9.4 System and application access control	A.9.4.1 Information access restriction	Documented in the finao confluence space System Admin vs Admin vs Module Admin POLP
	A.9.4.2 Secure log on procedures	Username and password (10 characters using alpha numerics and special characters) 2-factor authentication enabled
	A.9.4.3 Password management system	Password policy (10 characters using alpha numerics and special characters) No passwords sent to users Password storage is separated from other data / application
	A.9.4.4 Use of privileges utility programs	Controlled internally in finao using POLP 2-factor authentication enabled All access is logged
	A.9.4.5 Access control to program source code

 

On-boarding process

• Register user
• Approve user
• User receives email to set password
• User receives text for authentication

Off-boarding process

• If an email has been bounced to a user then Admin is notified - This may indicate that their work email has been terminated
• Inactive users are moved to the Inactive tab (after 30 days of inactivity)
• After a further period of being in the Inactive tab, the user is deactivated
• The period of inactivity / deactivation can be set in the Admin console to suit an organisation's specific needs