Stop Giving New Employees Everything On Day One

Least Privilege Access: How to Reduce Security Risk During Employee Onboarding

Give IT to Me Straight — Dazzee IT

Edward:
Welcome to Give IT to Me Straight, the podcast from Dazzee IT.

Each week, we break down technology, cybersecurity, AI, and business IT into practical insights you can actually use.

Now, here’s your host, Shane.

What Is Least Privilege Access?

Shane:
Hey guys, and welcome back to another edition of Give IT to Me Straight, where we dive into real-world questions and technology issues we hear from our clients and prospects, with the goal of helping you get some of this information in advance.

Most of the time, we focus pretty heavily on technology itself, especially cybersecurity and best practices. But one thing that sometimes gets overlooked is the human aspect of technology.

That leads us to today’s topic: least privilege access.

You may or may not have heard that term before, but it essentially refers to how you provision access to your tools, applications, and data.

Before getting into the technology itself, I want to talk about how least privilege relates to your team—especially when you're adding new employees or moving existing employees into new roles.

Why Is Least Privilege Important During Employee Onboarding?

Shane:
When it comes to onboarding new staff, we often see organizations rush through the process of giving people access to technology.

I would encourage you to systematize this and create a defined process around it.

Organizations can spend months trying to find the right person—someone who fits the culture, understands the organization, and works well with the team.

After spending all that time finding somebody, there’s often pressure to get them productive as quickly as possible.

That’s where things can go wrong.

Before you even reach the hiring phase, think carefully about the position you're hiring for and ask:

What tools will this person need?

What technologies will they use?

What data will they be able to see?

Will they have access to anything financial?

Remember, this is still a new person coming into your organization.

You have their résumé. You have some history. You've had conversations with them. But you don't completely know how they operate yet.

When you're providing access to your applications, data, and financial information, there needs to be a process for mapping that access out.

Should New Employees Receive Full Access on Day One?

Shane:
We recommend looking at access through a crawl, walk, run methodology.

Start slowly.

Make sure the employee understands what they're doing and understands the ramifications of the access they've been given.

Then build trust over time.

In the crawl phase, they receive the minimum level of access necessary to begin doing their job safely.

In the walk phase, you've built some trust, understand how they work, and have greater confidence in how they handle the data available to them. At that point, you may open up additional permissions.

Eventually, you reach the run phase. You've worked with the person for a significant amount of time, trust them, and feel comfortable providing the broader access their position requires.

Unfortunately, we see many organizations jump straight to the run phase.

They think, “This job needs access to all of this, so let’s give them everything on day one so they can get started.”

That might seem efficient, but it can dramatically increase the organization’s exposure if something goes wrong.

And that problem might happen immediately—or years down the road.

How Granular Should Employee Permissions Be?

Shane:
Knowing which applications somebody needs is only the first step.

You also need to ask what they need access to inside those applications.

What type of data do they need?

What granular permission controls does the application give you?

How does that data interact with the employee’s daily responsibilities?

Ideally, that discussion should begin whenever you're defining a position and preparing to hire someone for it.

The objective is to ask:

What is the safest amount of access we can provide while still allowing this person to perform their job?

Start there.

Then expand access as necessary and as trust develops.

How Does Least Privilege Help With Compliance Requirements?

Shane:
Another major consideration is compliance.

Ask yourself whether the data you're giving somebody access to falls under any compliance requirements.

You could unknowingly expose your organization to compliance risk—or potentially even fines—by giving somebody access they shouldn't have.

For example, organizations working in the federal contracting space may deal with Controlled Unclassified Information, or CUI, governed by requirements such as CMMC.

You have to control and document who has access to that information and consistently follow your established process.

The same principle applies to a city or another organization working with Criminal Justice Information Services, or CJIS, requirements.

Compliance frameworks generally require organizations to understand:

• Who has access to sensitive data
• How that access is controlled
• How permissions are documented
• How access is maintained and reviewed over time

That makes having a defined access-control process extremely important.

How Does Least Privilege Reduce the “Blast Radius” of a Security Incident?

Shane:
Start by creating an inventory and determining the least amount of privilege an employee needs on day one.

Doing that limits the potential blast radius if something bad happens.

And remember, the employee doesn't necessarily have to do something malicious.

People make mistakes.

If somebody has been given more permissions than they need, an accidental action could destroy data, overwrite information, or cause other problems that would not have been possible with properly restricted permissions.

There is also the opposite scenario: an employee becomes upset or disgruntled and intentionally causes damage.

Least privilege helps protect against both situations.

How Can Excessive CRM Access Put Sales Data at Risk?

Shane:
We see a good example of this in sales.

Suppose a salesperson is working from a CRM containing prospects, customers, and pipeline information.

You want to make sure the information available to that salesperson cannot simply be exported without some level of approval or oversight.

We frequently see organizations hire quickly, give someone complete access to the database, and put very few controls in place.

Then that salesperson leaves—and takes the sales pipeline with them.

Now another organization potentially has access to prospect information, customer data, and work that your company spent time and money building.

That’s why the question shouldn't simply be:

“Does this employee need CRM access?”

It should also be:

“Exactly what should this employee be able to view, change, download, or export within the CRM?”

Why Should Financial Access Be Especially Restricted?

Shane:
Financial access is probably one of the areas that concerns us the most.

Most people understand that you should restrict direct access to things such as bank accounts and credit cards.

What people don't always think about is how financial information connects to the other applications they're provisioning.

Do those applications expose financial information?

Could somebody use one of those tools to reach something they otherwise wouldn't have access to?

You need to map those connections.

If someone leaves the organization and intentionally tries to cause harm, you're no longer talking only about access to company data.

They might have access to actual dollars.

We've seen situations where individuals leave organizations and intentionally take data, cause financial damage, or even attempt to delete information simply to create havoc.

Much of that risk can be mitigated by establishing a least-privilege model before the employee ever starts and expanding access gradually as appropriate.

How Do You Build a Least Privilege Access Process?

Shane:
If you don't have a process today, start with an inventory.

Step 1: Inventory Your Applications

Document every software application each position needs to access.

Don't just think about the employee.

Think about the role.

That way, the process becomes repeatable whenever somebody new enters that position.

Step 2: Document Available Permission Levels

Next, identify the permission and access levels available inside each application.

Some applications offer highly granular controls.

Others don't.

If an application doesn't allow you to restrict access as much as you'd like, you may have to ask:

Should this employee receive access today, or should someone else perform this function until additional trust has been established?

Step 3: Map Permissions to Daily Workflows

Once you understand the applications and permission levels, map them to the employee's day-to-day workflows.

What does the person actually need to do?

What access is required for each task?

Sometimes you won't discover that a particular workflow requires an additional permission until you actually walk through the process.

That's okay.

The important thing is to have a controlled process for adding access rather than giving everything upfront.

Step 4: Document Every Access Change

You should be able to look across your organization and clearly understand:

• What each role can access
• When that access was granted
• Who granted it
• Why the access was necessary

That gives you a much clearer picture of risk throughout the organization.

How Does AI Increase the Risk of Excessive Data Access?

Shane:
If you follow these practices, you can significantly reduce your exposure to data loss, destruction, unwanted disclosure, and even the loss of trade secrets.

And now, in the age of AI, this becomes even more important.

An employee with unnecessary access may potentially be able to take large amounts of company information and upload it into an AI platform.

That can exponentially increase the risk to your organization if somebody acts maliciously—or simply doesn't understand what should and shouldn't be shared.

Controlling access at the source reduces how much sensitive information an individual can expose in the first place.

What Should a Secure Employee Onboarding Process Include?

Shane:
Ideally, access management should become part of your hiring process from the moment a job is posted until the employee is fully onboarded.

For every role, you should know:

• What applications the person needs
• What information they should be able to access
• What level of permission they should receive
• Who needs to approve or provision that access
• How those activities are coordinated
• How permission changes are documented
• When additional access should be considered

Don't treat technology access as an afterthought once somebody has already been hired.

Build it directly into your onboarding process.

What Is the Best Way to Implement Least Privilege Access?

Shane:
Hopefully this gives you a good starting point.

A lot of organizations don't have a detailed process like this in place today.

Start by inventorying your applications, understanding their permission levels, mapping access to specific job responsibilities, and documenting changes over time.

Most importantly, resist the temptation to give a new employee everything they could possibly need on day one.

Start with the least privilege necessary.

Then use that crawl, walk, run approach as the employee gains experience and trust.

If you have questions or would like help putting together a roadmap, reach out. We're happy to share what we've seen work in terms of best practices, provide guidance, or recommend tools that can help.

Again, thank you for tuning in to Give IT to Me Straight.

I look forward to catching up with you on the next edition.