Part 3 — Who Has Access to Your Business?
Managing Access Across the Business
Access Extends Beyond the User
Parts 1 and 2 focused primarily on people and accounts: who should have access, how much authority they should receive, how credentials are protected, and how that access should change as responsibilities change. The final part widens that view to the devices, outside organizations, and management processes that surround those accounts.
A business may manage an employee's account correctly and still have company information stored on a personal phone. It may remove a contractor's login while leaving the contractor as the owner of an important online account. It may use strong authentication while having no single person responsible for understanding who has access across the organization.
Access management therefore has to extend beyond the individual username and password. It has to include the devices people use, the outside organizations the business depends on, the people responsible for managing access, and a practical method for periodically reviewing whether the authority inside the business still reflects the business as it exists today.
The Device Can Become Part of the Access
One of the first places that broader view matters is the device itself. Once a phone, laptop, tablet, or home computer is used to receive company email, open customer records, connect to cloud storage, or sign in to business applications, that device becomes another place where business information and access may exist.
For many small businesses, allowing employees to use personal devices is practical. An employee may need to check email away from the office, respond to a customer from a phone, review a schedule from home, or access a shared document while traveling. Remote work can also make the business more flexible and allow employees to remain productive without being physically present in the workplace. None of those arrangements is inherently inappropriate, and for some businesses they may be essential to how work gets done.
The concern begins when the business treats the device as though it is separate from the access being provided through it. Consider what happens when an employee connects a personal phone to company email. The employee may begin receiving messages, attachments, calendar information, contacts, and notifications on a device the business does not own. The employee may also use the phone to authenticate access to other company systems, receive verification codes, or approve multifactor authentication requests. If applications remain signed in, possession of the device itself may provide a pathway into business accounts.
The same concern applies to laptops and home computers. An employee may access a shared cloud folder from a personal computer and download a customer file to work on it. Even if the employee later signs out of the cloud account, the downloaded file may still remain on the computer. A browser may retain usernames, saved passwords, or active sessions. An application may synchronize files locally without the employee realizing how much company information has been copied onto the device.
At that point, removing the employee's username from a business application may address only part of the access problem. The account can be disabled while business information remains somewhere else.
This is why I think device access needs to be considered as part of the larger access conversation rather than as a completely separate technology issue. The business is not simply deciding whether an employee may use a phone or laptop. It is deciding whether a device outside the company's direct control may interact with business accounts, store business information, and potentially remain connected to those resources over time.
North Star's policy materials address this through Bring Your Own Device, Mobile Device Management, and Remote Work policies. A Bring Your Own Device, or BYOD, policy establishes expectations for employees who use personal laptops, phones, or other devices for work, including how those devices should be used and how business information should be protected. Mobile Device Management addresses the management and security of mobile devices used for work and can include capabilities such as controlling applications or remotely wiping information. Remote Work policies establish expectations for employees accessing business systems outside the normal workplace and may include requirements involving secure connections, devices, and other cybersecurity practices.
The reason for those policies becomes easier to understand when we look at what can happen over the life of a device.
Suppose an employee receives company email on a personal phone for three years. During that period, the employee may receive thousands of messages, attachments, customer names, internal discussions, calendar appointments, and other information associated with the business. If the employee leaves the company, disabling the email account prevents future access, but the business should also understand what information may already exist on the phone and whether the device still contains saved credentials, synchronized files, or active sessions.
Now consider what happens when the employee replaces the phone rather than leaves the company. People trade in devices, sell them, hand them down to family members, or place them in a drawer and forget about them. If business information existed on the old device, the business should have some expectation for what happens before that device changes hands.
The same question arises when a device is lost or stolen. If a company laptop disappears, the business may have greater control over what happens next because it owns the equipment and may have already installed tools that allow the device to be locked, located, or wiped. If the missing device is an employee's personal phone, the situation can become more complicated because the device belongs to the employee while some of the information stored on it may belong to the business.
That distinction is one reason policies should be established before the problem occurs. If a business expects to have the ability to remotely remove company information from a personal device, employees should understand that expectation before they connect the device to company systems. If the company requires certain security settings, screen locks, software updates, or approved applications before a personal device can be used for work, those expectations should also be communicated in advance. The employee should not have to discover the rules only after a device is lost or employment ends.
This also raises a practical issue involving the separation of personal and business information. A personally owned device may contain family photographs, personal messages, banking applications, private documents, and other information that has nothing to do with the company. The business therefore needs to think carefully about how much control it expects to exercise over a device it does not own and how business information will be separated from personal information wherever possible.
A BYOD policy defines the conditions under which personal technology may interact with company information and systems, including what the business can reasonably require of a device it does not own.
If the business allows employees to use personal devices but has never discussed what security is expected, what information may be stored locally, what happens when a device is lost, or how company information should be removed when employment ends, then both the employee and the business are left to make those decisions during the incident.
Remote work creates similar considerations. An employee working from home may be using a company laptop on a personal Wi-Fi network, accessing business systems through a browser, printing documents on a home printer, or temporarily saving company information to a local device. The business may be perfectly comfortable with those arrangements, but it should still understand how access works outside the office and what expectations apply when business information leaves the physical workplace.
There is also an important connection between devices and authentication. As we discussed in the previous section, modern authentication increasingly relies on something the user possesses. MFA prompts may arrive on a phone. Authenticator applications may live on that device. Passkeys may be stored on or synchronized through devices. A physical security key may also become part of how an employee proves identity. That means losing a device can affect both access to business information and the employee's ability to authenticate into the systems they legitimately need.
The business should therefore think about device replacement and recovery before they become emergencies. If an employee's phone is lost today and that phone contains the employee's authenticator application or passkeys, how will legitimate access be restored? If the employee leaves, what happens to business credentials associated with that device? If a new phone is issued or purchased, how are the credentials moved or reestablished without accidentally leaving unnecessary access behind?
These are not reasons to avoid modern authentication or personal devices. They are reasons to understand the relationship between the account, the person, and the device being used to access it. For a small business, the answer is not necessarily to ban personal devices or remote work; a blanket prohibition may be unnecessary or impractical. The better approach is to decide deliberately how those devices may interact with company information and systems.
That means understanding what business information may exist on the device, what security expectations apply, what happens if the device is lost or replaced, how access is removed when an employee leaves, and what authority the business has to protect or remove its information from equipment it does not own.
When those questions are answered in advance, policies such as BYOD, Mobile Device Management, and Remote Work stop looking like documents created simply because cybersecurity guidance says the business should have them. They become tools for defining a relationship the business has already chosen to create between its information, its systems, its employees, and the devices used to reach them.
Those expectations are most useful when they are established before something goes wrong. Employees and managers should know how device access is supposed to work before they are dealing with a lost phone, a departure, or a cybersecurity incident.
Contractors and Vendors Count Too
Access discussions can easily become employee discussions because employees are the people business owners see every day. They are the people using the systems, handling customer information, processing transactions, answering email, and working inside the operation. But employees are not the only people who may have meaningful access to the business.
Small businesses increasingly rely on outside professionals to perform work that once might have been handled internally. A website developer may have administrator credentials. An accountant may have access to financial systems. A managed technology provider may be able to connect remotely to company computers. A marketing company may control advertising accounts, social media pages, or email marketing platforms. A payroll provider may handle sensitive employee information. A consultant or contractor may temporarily receive access to shared files, customer records, project information, or other internal systems.
None of those arrangements is unusual. In many cases, they are exactly what allows a small business to operate effectively. A small company may not have the staff, expertise, time, or financial resources to keep every function in-house. Outsourcing can provide access to specialized knowledge and capabilities the business could not reasonably maintain on its own.
Outside access can be entirely appropriate. What the business needs to understand is what has been granted, how much authority comes with it, and whether that access still matches the work being performed.
That distinction matters because outsourcing a function does not eliminate the business's responsibility to understand how that function is being performed. A business owner may hire someone else to manage the website, process payroll, administer software, or support the network, but the access associated with those services still affects the business. The fact that the person performing the work is not on the payroll does not make the access less important.
In some cases, outside providers may have more authority than many employees. A technology provider may have administrator privileges across multiple systems. A website developer may be able to change the site, reset user accounts, or modify security settings. A payroll provider may process highly sensitive employee information. A marketing company may be able to publish content in the company's name, spend advertising dollars, or control accounts that customers associate directly with the business.
That level of authority can be entirely appropriate, but it should not be invisible. The business should understand what the provider needs in order to perform the work, why that access is necessary, and how far it extends. A contractor hired to update the website may need access to the content-management system, but that does not automatically mean the contractor needs access to company email, cloud storage, or financial systems. An accountant may need access to accounting records but not administrative control over unrelated business applications. A technology provider may need broad access to maintain systems, but the owner should still understand what that broad access allows the provider to do.
The same principle applies here as it does with employees: access should follow responsibility. Outside access can be easier to lose sight of because the person or company is not part of the daily operation. A contractor may finish a project and move on. A vendor may stop providing a service. A consulting relationship may end. The business may switch software providers or hire a different company to perform the same function. If nobody reviews the associated permissions, the access may remain long after the business relationship has ended.
That creates the same access-creep problem discussed earlier, but with an added layer of distance. A business owner may remember that a former employee once had access to payroll because that employee worked in the office every day. The owner may be much less likely to remember that a web developer from three years ago still has administrator privileges on the company website.
The same concern applies when vendors create accounts on behalf of the business. A provider may register a domain name, create an advertising account, establish a social media page, configure cloud storage, or create an administrative account during setup. If those accounts are created using the vendor's email address or remain under the vendor's control, the business may eventually discover that it is depending on an outside company not only to provide a service, but also to maintain control of an account the business itself needs.
Ownership and access therefore need to be understood together. The business should know whether the provider is simply using an account owned by the company or whether the provider actually controls the account. It should know who can reset the credentials, who receives recovery messages, who has administrative authority, and what would happen if the relationship ended unexpectedly.
North Star includes third parties within its cybersecurity policy guidance for exactly this reason. A Third Party Policy helps establish how outside vendors, contractors, and partners are expected to handle company data and systems. Its value is in making the relationship clearer by defining expectations around access, security, responsibility, and what happens when the relationship changes.
For a small business, that does not have to become a complex legal exercise every time someone is hired. It may begin with a few practical questions: What does this provider need access to in order to perform the work? What level of authority does that access provide? Who inside the business approved it? Who ultimately owns the account? How long should the access remain active? What happens to the credentials, files, or data when the relationship ends?
Those questions can also reveal where a vendor may have become more deeply embedded in the business than the owner realized. A company may hire a provider for one purpose and gradually rely on that same provider for several others. Over time, the provider may gain access to email, storage, websites, devices, software, and customer information. At some point, the relationship may no longer be a simple vendor arrangement. It may become a significant part of how the business operates.
A vendor becoming deeply embedded in the business is not necessarily a problem, but the owner should understand the extent of that dependence. There is also an important difference between trusting a provider and managing the access given to that provider. A business may have worked with the same accountant, technology company, or marketing firm for many years and have complete confidence in the relationship. The access still needs to be appropriate. Trust does not eliminate the need to understand what the provider can see, change, or control.
This is especially important because the business may know very little about what happens inside the vendor's own organization. The owner may trust the company but not know which employees of that company can access the account, how those permissions are managed, or how quickly access is removed when one of the vendor's employees leaves. The small business may have done everything correctly inside its own organization while still depending on another company's access practices.
That broader dependency is something we will examine later in this series because third-party risk goes beyond access alone. For this discussion, however, the important point is that outside access belongs in the same management conversation as employee access.
If someone outside the payroll can enter the business's systems, view its information, change settings, act in the company's name, or control an account the business depends on, that access should be understood, reviewed, and managed with the same level of attention given to internal users.
Someone Has to Own the Question
Access tends to become unmanaged when responsibility for it is scattered across several people and no one person has a complete view of the environment. In a small business, that is easy to understand because different parts of the access process may naturally fall to different people. The technology provider may create user accounts and reset passwords. The office manager may tell the provider when someone needs access. The owner may approve a new hire or job change. The payroll company may manage access within its own platform. Each person may be doing exactly what they were asked to do, yet no one may be responsible for understanding the full picture.
That gap can develop quietly. A technology provider may know which accounts exist but not know that an employee changed positions last month. The owner may know the employee changed responsibilities but not know which permissions were attached to the former role. An office manager may create new accounts when someone is hired without knowing which of those accounts carry administrative authority. A payroll company may manage payroll access correctly while having no visibility into email, cloud storage, accounting software, or other systems the employee also uses.
No one in that chain necessarily failed to do their job. The gap appears because access management crosses several parts of the business, and permissions can fall between them when nobody is responsible for looking across those parts. One person may understand the employee, another the technology, and another the vendor relationship. Without someone connecting those pieces, the business can assume access is being managed simply because several people are managing parts of it.
Cybersecurity governance begins with making those responsibilities clear. North Star's best-practice guidance emphasizes establishing who has decision authority, who has spending authority, and who is ultimately responsible for the cybersecurity program. Its starter questions also ask whether the organization has decided who is responsible for cybersecurity decisions and who helps inform those decisions. The practical consequence is that responsibility should be assigned rather than assumed.
For a small business, that does not mean creating a new executive position or hiring a dedicated cybersecurity officer. The owner may be the person who ultimately owns the question, or that responsibility may be assigned to a manager who already oversees operations, technology, or administration. What matters is that someone understands that access management belongs within their area of responsibility and that they know who else must be involved when decisions are made.
That person does not need to personally create every account, configure every permission, or troubleshoot every technical issue. In many businesses, those tasks will still be handled by an outside provider, software administrator, or another employee. Ownership of the question means making sure the right conversations happen, that access decisions are documented or understood, and that changes in the business trigger corresponding changes in access.
For example, if an employee moves from one department to another, the person responsible for access does not necessarily need to know how to configure every system. They do need to recognize that the job change should trigger a review. Someone should ask which permissions from the old role are no longer needed, which new permissions should be added, and whether administrative access or other higher-risk privileges are still appropriate.
The same applies when a contractor finishes a project, a vendor relationship changes, or a new system is introduced. Someone should be asking who needs access, who should approve it, what level of authority is appropriate, and when that access should be reviewed again. Without clear ownership, those questions are more likely to be answered inconsistently or not at all.
Clear ownership also helps prevent the common assumption that access is simply “an IT issue.” Technology providers can be essential to implementing controls, but they cannot always make the underlying business decision about who should have access to what. They may know how to create the account, but the owner or manager should still determine whether the person needs the account in the first place and how much authority should come with it.
Vendors and software providers create the same division between technical execution and business authority. A payroll company may control the technical process for adding or removing users within its platform, but the business still has to decide who should be authorized to use it. A cloud provider may offer detailed permission settings, but the business has to decide which employees or contractors should receive those permissions. Technology can enforce the decision, but it cannot make the business judgment for the owner.
Someone therefore has to own the complete question. The responsibility is not simply to know who has a password. It is to make sure the business has a consistent way to understand who has access, why that access exists, what authority it provides, and when it should change.
In a very small business, that responsibility may rest with one person. In a somewhat larger business, several people may contribute to the process. Either approach can work as long as the business knows who is ultimately accountable for making sure the pieces come together.
Access should not belong vaguely to “IT,” “the office,” “the vendor,” or “whoever handles that.” Responsibility can be distributed, but accountability still needs a home. Someone should be responsible for making sure the right questions are asked, the right people are involved, and the access decisions being made in different parts of the organization still fit together as a whole.
What an Access Review Is Really Trying to Accomplish
An access review can sound more intimidating than it needs to be, especially if the phrase makes the business owner imagine a formal cybersecurity audit, a complicated technical assessment, or a lengthy spreadsheet covering every application the company has ever used. For most small businesses, that is not where the process needs to begin. The first objective is simply to understand the access environment that already exists.
A practical review can start with the systems that matter most to the business. Those might include email, accounting, payroll, cloud storage, customer-management software, scheduling systems, banking platforms, the company website, or any other system that would create a meaningful problem if the wrong person had access or if legitimate access could not be managed properly. Starting with the most important systems keeps the review focused on business impact rather than turning it into an exercise in cataloging technology for its own sake.
Once those systems have been identified, the business can begin asking a series of practical questions. Who currently has an account? Which users have administrative authority? What can each person actually do inside the system? Does that person still need those permissions based on their current responsibilities? Are any accounts shared? Are former employees, contractors, or vendors still present? Are there accounts nobody recognizes or understands? Is multifactor authentication enabled where it is available? If someone left the business today, who would know how to remove or transfer that person's access?
Those questions are meant to give the business a clearer picture of what is actually happening today, not to produce a perfect cybersecurity environment. An owner cannot make an intentional decision about permissions the business does not know exist, so understanding the current environment has to come before reducing access, removing accounts, or clarifying responsibilities.
The review should also help connect access to current business responsibilities. If an employee has access to a system because of work performed two years ago, the business should determine whether that access still serves a purpose. If a contractor remains listed as an administrator after a project ended, the business should decide whether the account should remain active. If several people share the same credentials because that was convenient when the system was first introduced, the review creates an opportunity to decide whether that arrangement still makes sense given the importance of the system and the need for accountability.
An access review can also reveal where the business depends too heavily on one person. The owner may discover that only one employee knows how to administer a critical system, that an outside vendor controls the recovery information for an important account, or that the business owner is the only person capable of removing a user or resetting access. Those findings are useful because access management is not only about reducing unnecessary permissions. It is also about making sure the business can continue to manage its own systems when responsibilities change, someone is unavailable, or a relationship with a provider ends.
The review therefore does more than identify risk. It helps the business document how access works, where authority is concentrated, and who is responsible for making changes. That information can make onboarding easier, offboarding more reliable, vendor transitions less disruptive, and incident response more effective because the business already has a better understanding of who controls what.
I would rather see a small business begin with its five most important systems and understand them well than create an enormous inventory of every application the company has ever touched and never complete the exercise. A manageable review that results in better decisions is far more useful than a comprehensive project that becomes so complicated it is abandoned before anything changes.
That practical approach is consistent with the way North Star frames cybersecurity maturity for small businesses. Not every best practice, question, or category will carry the same importance for every company, because the right priorities depend on the business's size, industry, systems, resources, and level of exposure. The business does not need to complete every possible cybersecurity activity simply because it appears on a list; it needs enough understanding to identify where the greatest risk, dependency, or concentration of authority exists and address those areas first.
A good access review should therefore leave the business with more than a list of accounts. It should leave the owner with a clearer understanding of who can enter the systems that matter most, what those people are able to do once they are inside, whether those permissions still reflect current responsibilities, and where changes may be needed. That understanding is what allows the business to move from accidental access to intentional access management.
Where Access Management Begins
Week 1 of this series focused on business continuity by asking owners to think about what the business depends on and what happens when something important suddenly becomes unavailable. That discussion centered on the systems, information, technology, and services that have gradually become part of normal operations.
Access is the other side of that conversation. If a system matters enough that losing it would hurt the business, then the ability to enter that system, change information inside it, control settings, approve actions, or act through it matters as well. A company cannot fully understand the risk surrounding an important system without also understanding who has authority inside it.
Good access management should not make ordinary work difficult simply for the sake of security. Employees need enough authority to perform their work efficiently, contractors need the access required to complete the work they were hired to perform, and owners need technology that supports the business rather than creating unnecessary barriers.
The goal is intentional access: authority that exists for a business reason, is reviewed as that reason changes, and is removed when the reason no longer exists.
Intentional access means the business understands who has access, why that access exists, what authority comes with it, and how that authority should change as responsibilities, employment, contracts, and vendor relationships change. It means access is granted because there is a business reason for it, reviewed because that reason may change, and removed when the reason no longer exists.
That is the management idea running through all three parts of this discussion. Access creates capability by allowing people to perform work, make decisions, serve customers, manage information, and keep the business moving. At the same time, every permission creates some level of exposure because the account, person, device, or vendor holding that permission may eventually become part of a mistake, compromise, or other incident. Good access management is not about eliminating that exposure entirely. It is about making sure the exposure exists for a reason the business understands and accepts.
As you continue your Cybersecurity Awareness Month review, I would encourage you to look at the systems that matter most to your business and ask one practical question:
Who can do what inside my business today, and does every one of those permissions still make sense?
The answer may reveal a former employee whose account was never disabled, a contractor who still has administrative rights after the project ended, a shared account that no longer makes sense, an employee who accumulated permissions from a previous role, or an account nobody clearly remembers creating. It may also confirm that the business already has reasonable controls in place and simply needs a better process for reviewing them regularly.
Either result is useful because the purpose of the exercise is not to prove that something is wrong. It is to make sure the business understands the authority that currently exists inside its systems and has made deliberate decisions about whether that authority is still appropriate.
Finding an outdated permission during a routine review gives the business an opportunity to address it calmly. Discovering the same permission during an incident is very different. At that point, the business may already be trying to determine what happened, who had access, what information was affected, and whether a former employee, vendor, or compromised account still had authority that should have been removed long ago.
America's SBDC and North Star-trained advisors can help small business owners work through these questions from the business side of cybersecurity. That may include discussing access responsibilities, identifying where policies could help, reviewing the way onboarding and offboarding are handled, or helping the owner recognize when additional technical or professional assistance may be appropriate.
Cybersecurity Awareness Month gives us a useful opportunity to review access, but this is not a question that belongs only to October. Businesses change throughout the year. Employees are hired, promoted, and leave. Contractors complete projects. Vendors are replaced. New applications are introduced. Old systems are retired. Responsibilities shift, and technology continues to become more deeply connected to everyday operations.
Access management has to change with the business. The goal is to make sure the authority people hold today still reflects the business that exists today, rather than the business as it looked several years ago when those permissions were first granted.
References
America’s SBDC North Star Cybersecurity Program. (2026). Cybersecurity best practices: North Star FY 2026 supplemental training materials.
America’s SBDC North Star Cybersecurity Program. (2026). Cybersecurity policy definitions: North Star FY 2026 supplemental training materials.
America’s SBDC North Star Cybersecurity Program. (2026). NIST CSF starter questions or suggestions: North Star FY 2026 supplemental training materials.
America’s SBDC North Star Cybersecurity Program. (2026). NIST Cybersecurity Framework 2.0 summary: North Star FY 2026 supplemental training materials.
Pascoe, C., Quinn, S., & Scarfone, K. (2024). The NIST Cybersecurity Framework (CSF) 2.0 (NIST CSWP 29). National Institute of Standards and Technology.
Part 3 — Who Has Access to Your Business? Managing Access Across the Business
By Manzel McGhee Jr., ASBC® | Abilene SBDC
