💡: it's possible to listen to this article! Find the audio at the bottom of the page 🎧
This injunction may come as a surprise, but in the banking industry it is a well-known one:
"know your customer", or KYC for short.
This procedure enables banks to identify their customers'identity in order to comply with current regulations.
Given the current environment, the bank must limit its exposure to risks caused by its customers.
Banks are required to collect information relating to the legal entity and the individual, such asidentity, source of funds, political links, etc.
The higher the risk, the more thorough the monitoring and checks.
Once the operation is complete, a file is kept to prove compliance.
So far, everyone agrees that it's normal for a bank to know its customers, but let's go a step further: KYC, yes and why? Why do we need to know our customers?
This question may make you smile, but you'll see that it's not all that naive.
Know your customer in the banking sector
The "Know your customer" procedure stems from the European directive on combating money laundering and the financing of terrorism.
KYC was set up to assess the risk of a commercial relationship with each customer. This procedure is therefore a must in the banking sector, and if banks fail to comply with it, they expose themselves to sanctions.
To answer my question, why do you need to know your customers?
- to avoid financing terrorism
- to avoid participating in money laundering
indirectly :
- to comply with the United States
What if KYC were a mandatory procedure for companies?
Yes, it makes a lot of sense when you look at the application and reasons for this procedure in the banking sector, and it's perfectly transposable to all companies.
Know your user (KYU) in IT
Everything we've just said can be transposed from the banking sector to the IT department:
- Due to the current cyberattack environment, companies need to limit their exposure to risks caused by their users. 💡
- Companies are required to collect information relating to individuals, such as identity and contractual information.
- The higher the risk, the greater the checks that need to be carried out, such as past employment if the person works in a sensitive sector, or is in a management position or with administrator access.
- All this needs to be reviewed regularly.
Why get to know your users?
- to avoid the risk of cyber-attack (by the employee or as part of an external attack)
- to track user lifecycles
- to apply the rule of least privilege
That's why we're perplexed. It's an obligation that's totally justified in banking, but not at all in the corporate world, even though the risks in both cases are enormous.
Banks have few errors due to this procedure, but for companies, it's a different story... attacks using loopholes around users are extremely frequent.
What is a user?
Back to the basic: a user must be seen as a physical person who has a contractual link with the company, and not as a computer account.
One person = one user
A user can have several accounts. So one account ≠ one user.
An account is a digital representation of the user in the information system.
⚠️ Don't confuse Active Directory with HR truth!
These are the contracts that bind a user to the company.
⚠️ if a user has no contractual relationship, then he or she is not required to have access to the company's IS.
Now that this has been clarified, let's take a look at the complexities of applying KYU in IT.
Why is getting to know your users so complicated?
To get to know your users well, you need a number of pieces of information, such as :
- contractual information
- contract start and end dates (the end date is linked to the contract and therefore often unknown when the employee arrives)
- operational information, such as the accounts required and the accesses the user must have
This data is imperative for creating accounts for this new user. The settings for each account can only be made if the previous information has been refined.
Thus, a matrix for converting collaborators into accounts can be seen as follows:
The downside is that in reality, things get more complicated.
Would you like to receive our white paper on identity and access management?
Information is scattered over several sources
Where to find administrative information for employees?
The payroll tool is a good source of information for finding employees, except for trainees, for example, who are less than 2 months old, as they are not included in the tool. The same applies to external service providers, who are not included in the payroll tool.
In some cases, the business ERP system can be used to list service providers and temporary workers.
Alternatively, a file managed by the manager(s) can be found, but only if it is up to date.
Employees can also be found on a leave tracking database, but here again, this only concerns permanent and fixed-term contracts.
HRIS is (still) often late 🫣
HRIS is always late, and for a good reason: payroll arrives at the end of the month, and the user is not entered until the 20th!
The user has no prior existence. As a result, you can't anticipate the arrival of a new employee. To counter this problem, HR often has an Excel file for new arrivals.
By bringing together the payroll tool + the file, we manage to have a fairly accurate repository.
A multi-contract user
Sometimes, a user can hold several contracts within the same company. This can be the case, for example, with firefighters, who can be both volunteer firefighters and secretaries. In this case, there are two contracts, but only one person. One user but several accesses.
We also find another situation with a user who accumulates different contracts. He arrives as an intern, then finishes his internship with an offer of a fixed-term contract. The budget is there and so are the skills, so we convert him to a permanent contract.
So we have one person and three contracts. One user, but a growing number of accesses.
And last but not least, our hero, who accumulates several contracts at the same time and has contiguous contracts. 💪
User movements every day
We're going to create an Excel file to track all these movements (arrivals, internal mobility and departures).
How do we proceed? We take all the available information (Excel files for HR, managers, HRIS and the user directory), and put it to good use to create a single user repository and find out who is present, with which contract, which applications and which accesses.
Except that in the meantime there have been changes, new users, changes in departure or arrival dates, changes in service 🤯
Not all information available
Try as we might, the information doesn't exist anywhere, so it's impossible to invent it.
If there's no follow-up for service providers and trainees, it won't be possible to have a centralized repository.
Service contracts are often managed directly by managers, and often on a just-in-time basis, which makes it very difficult to keep a common file that is properly maintained.
How can you get to know your users better?
At this point, we come to the conclusion that to get to know our users better, we need two things:
- austerity
- a unique user repository
List
Let's list the different types of collaborators that may be present in a company and where we can find reliable information to count them:
- internal collaborators: HR department (HRIS or Excel file)
- trainees: HR department (not HRIS, so probably Excel file)
- temporary workers: managers
List
Then, back to our basic KYU request, what information do I need to identify them properly in my IS?
Be meticulous in your approach. If you're aiming for the 'you can never be too careful' approach, you run the risk of wasting everyone's time. Categorizing every item, finding all the information, the risk of demotivation if there's too much information to fill in will compromise your work and your repository may quickly fall by the wayside.
If you don't have enough information, you're on the hunt, and once again, nobody wins.
Automate
You know as well as I do that any manual action is coupled with a risk of error, forgetfulness and laziness. It's a mental burden, an effort and a major risk of error.
Once you've identified all your sources, you need to automate their import so that you have just one file.
Treat
At that point, you have a raw, unprocessed file with duplicates, homonyms and specificities.
The good news is that there's a solution that lets you do all these things: it's called IAM, or Identity and Access Management. As the name suggests, it manages user identities and accesses.
At Youzer, we've taken into account all these specificities of contracts, different sources and even the absence of a source, to help you with your procedures so that you only have one file of your own, which will be your unique user repository.
How does it work? Youzer retrieves information from your HRIS and transcribes it to create accounts. An ultra-customizable form enables you to centralize and standardize the arrival information of employees who do not appear in the HRIS. All this information is centralized within Youzer, so you can work on a reliable user base in real time.
Youzer is your know-your-user!
In conclusion, it's possible to know your users and have a clean file manually, but this implies a great deal of rigor and, despite everything, the risk of errors.
It's not something you can just do whenever you like, as it will take up a lot of your human resources.
The benefits of automating this action are reliable results and considerable time savings. Your user file is always up to date.
