Before You Give a Vendor Access to Your Accounts, Ask These Questions

Small businesses and nonprofits often rely on outside help to get things done.

Outside help could include:

• A website designer who needs access to your website

• An IT provider who needs access to email, devices, or cloud storage

• A bookkeeper who needs access to accounting software

• A marketing consultant who needs access to social media accounts

• A fundraising platform, payment processor, payroll company, or software vendor that needs access to sensitive information

That access may be reasonable and even necessary. But it shouldn't be automatic. Before you give a vendor, consultant, contractor, or outside support person access to one of your accounts, you should slow down and ask a few practical questions.

• Who needs access?

• What do they need to do?

• How will they sign in?

• Can their access be limited?

• Who will remove the access when the work is done?

• What information will they be able to see, change, download, or delete?

You're asking these questions not because you don't trust the vendor. You're asking because you need to protect your organization from avoidable risk. Even a trustworthy vendor can unintentionally create risk if access is shared too broadly, passwords are handled casually, admin rights are given too quickly, or no one keeps track of who can get into important accounts or data.

Vendor access is normal, but it should be intentional

Outside vendors often help small organizations get important work done.

That might include:

• Setting up a website

• Managing email or cloud storage

• Supporting accounting or payroll software

• Helping with social media or advertising

• Maintaining a donor, customer, or client database

• Troubleshooting devices or networks

• Processing payments

• Installing or managing software

The problem isn't that vendors need access. The problem is giving access without thinking through what that access allows them to do.

Some accounts are low risk. Others are very sensitive. Access to an email account, payment system, payroll platform, donor database, file storage account, website administrator account, or accounting system can expose money, private information, business records, employee data, client data, or donor information.

That doesn't mean you shouldn't give access to any vendor. It means the access you give should match the job being done.

For example:

• A vendor helping with your website may not need access to your email.

• A marketing consultant may not need administrator rights to all of your social media accounts.

• A software support person may not need permanent access after the issue is fixed.

• A contractor helping with files may not need access to every folder in your organization.

The safest approach is this: Give vendors only the access they need to do the work, but no more than that. And access should be revoked when the work is done.

Question 1: What account or system do they actually need access to?

Before granting access, ask the vendor to explain exactly what they need. And consider it a red flag if they say they need access to “everything.”

For example:

• Do they need access to your website?

• Your email system?

• Your social media account?

• Your accounting software?

• Your payment processor?

• Your donor or customer database?

• Your shared files?

• Your computer or network?

• Your domain name or hosting account?

This matters because granting access may allow someone to do more than you realize.

For example:

• Access to your domain name account may allow someone to change where your website or email points.

• Access to your website admin account may allow someone to change pages, collect form submissions, install plugins, or create new users.

• Access to your accounting software may reveal banking details, invoices, payroll records, customer information, or vendor payment information.

• Access to your business computer systems may allow someone to change security settings, give access to others, install software, or affect how your devices and network operate.

Before you say yes, make sure you understand exactly what the vendor is asking to access and why. A good vendor should be able to explain this in plain language. If they can't explain what they need and why they need it, that's a clear warning sign and a reason to pause.

Question 2: What level of access do they need?

Not all access is the same. Some accounts have different roles, such as viewer, editor, manager, billing user, administrator, or owner. Those roles matter.

For example:

• A vendor may only need to view information but not change it.

• They may need to edit one part of a system but not manage all settings.

• They may need to upload files but not delete files.

• They may need to help with a website page, but not control users, billing, domain settings, or security settings.

Be careful with administrator access. It often allows someone to make major changes. Depending on the system, an administrator may be able to create new users, remove other users, change passwords, turn security settings on or off, connect new apps, export information, delete records, or change payment details. Sometimes admin access is necessary. But it shouldn't be the default.

Before giving a vendor administrator access, ask:

• Is admin access truly needed?

• Is there a lower level of access that would work?

• Can access be limited to one project, folder, account, or function?

• Can the work be completed through a supervised support session instead?

• Can access be removed immediately after the task is complete?

The goal is not to make the vendor’s job impossible. The goal is to avoid handing over more control than the work requires.

Question 3: Who will actually be using the access?

When a vendor asks for access, it's easy to think of “the vendor” as one person. But that may not be true.

For example:

• A vendor could be a company with several employees.

• A consultant may use subcontractors.

• A software provider may route support requests to different technicians.

• A marketing agency may have several people working on your account.

• An IT provider may have a team of support staff.

Before granting access, specifically ask:

• Will one named person use this access?

• Will multiple people use it?

• Will subcontractors or outside partners have access?

• Will anyone outside your company, or outside the United States, have access?

• How do you control access within your own company?

• What happens if one of your employees or subcontractors leaves?

This doesn't need to be confrontational. It's a basic business question. If you're responsible for protecting customer, client, donor, employee, financial, or operational information, you should know who can get to it.

Whenever possible, avoid giving one shared username and password to a vendor team. Shared accounts make it harder to know who did what. They also make it harder to remove access for one person without disrupting everyone else. A better approach is to create an individual account for each named user, with each account limited to the minimum access needed to get the job done.

Question 4: How will they sign in?

Before giving a vendor access, ask how they will actually sign in. Will they use their own account? Or are they asking to use your organization’s username and password? That difference matters.

Whenever possible, avoid letting a vendor sign in with the same account your business or nonprofit uses. If the vendor uses your account, it becomes harder to know who did what, harder to limit what they can access, and harder to remove their access later without changing the password.

A safer approach is to create a separate user account for the vendor whenever the system allows it. Ideally, use the system’s built-in invitation process so the vendor can set up their own password. That way, the vendor has their own login. You can control what they can access. You can turn their access off later without changing your own password. You may also be able to see what actions were taken under that account.

Try to avoid sending passwords by email, text message, or chat. A password may sit in someone’s inbox. It may be forwarded. It may be saved in a place you don't control. If you must share a temporary password, require the vendor to change it after signing in.

You should also use multifactor authentication, often called MFA, whenever it's available. This security feature adds another step when someone signs in. For important accounts, MFA should be turned on for both your team and any outside users who have access.

Be cautious if a vendor asks you to turn off MFA, share your one-time code, approve a login you don't recognize, or let them use your personal login instead of their own. That may be convenient, but it weakens the protection around the account.

If a vendor needs remote access to a device, be careful there too. Remote access can be useful for IT support, but it should be handled intentionally. You should know who is connecting, when they're connecting, what they're doing, when the session ends, and whether the vendor can reconnect later without your approval.

Question 5: Can the access be limited or temporary?

Vendor access doesn't always need to be permanent. Sometimes a vendor only needs access for a setup, repair, migration, training session, website change, software issue, or short-term project. Once that work is done, the access may no longer be needed. So before granting access, ask whether it can be temporary.

For example:

• Can access be granted only during the project?

• Can it be removed after setup is complete?

• Can the vendor be invited only to a specific folder?

• Can they be given access to one account instead of all accounts?

• Can they be given access for a limited time?

• Can someone review the access after 30, 60, or 90 days?

This is especially important for small organizations, because access often accumulates quietly over time.

For example:

• A website contractor from three years ago may still have admin rights.

• A former marketing consultant may still be able to access social media accounts.

• A software support person may still have a login.

• A volunteer who helped with donor records may still have access to a shared drive.

No one meant for that to happen. It just did. That's why temporary access is helpful. If access is needed for a short job, remove it when the job is finished.

Question 6: What information can they see, change, export, or delete?

Before giving access, think about what the vendor will be able to do once they're inside. This is about more than whether they can sign in. It's about what the access allows them to see or do.

• Can they see private information?

• Can they download files?

• Can they change payment details?

• Can they add users?

• Can they delete records?

• Can they view employee information?

• Can they access donor, client, customer, patient, member, or other sensitive data?

This question matters because “access” can mean much more than simply logging in.

For example:

• Access to email may reveal contracts, invoices, passwords, attachments, private conversations, and payment instructions.

• Access to cloud storage may reveal tax records, HR files, client files, donor lists, board materials, or internal documents.

• Access to accounting software may reveal bank details, vendor payments, payroll information, invoices, and financial reports.

• Access to a donor database may reveal names, addresses, giving history, notes, and contact information.

• Access to a website may allow someone to change public pages, forms, plugins, users, or settings.

• Access to social media may allow someone to post publicly, respond to messages, change page settings, or remove other users.

The more sensitive the information, the more careful the access decision should be. This doesn't mean the vendor should never have access. It just means you should understand the exposure before you grant it.

Question 7: What happens when the work is done?

One of the most overlooked parts of vendor access is the ending. Many organizations are careful when they start a project, but less careful when the project ends. Before giving access, you should decide how it will be removed later.

You should ask:

• Who is responsible for removing the vendor’s access?

• When will access be removed?

• Will passwords need to be changed?

• Will shared folders need to be closed?

• Will connected apps need to be disconnected?

• Will payment methods or billing contacts need to be updated?

• Will the vendor return, delete, or confirm deletion of any downloaded files?

• Will your business or nonprofit, not the vendor, keep ownership and control of the account, domain, website, files, and data?

That last question is important. Your business or nonprofit should understand who owns and controls the accounts and assets involved. A vendor may help build your website, manage ads, configure software, or set up a tool, but your organization should never be locked out of its own accounts.

For example, your organization should know who controls:

• Website administrator access

• Domain name registration

• Website hosting

• Social media pages

• Advertising accounts

• Email administrator access

• Cloud storage administration

• Accounting software ownership

• Payment processor access

• Donor or customer database administration

When the work ends, your organization should still be able to operate without depending on a former vendor’s login.

Warning signs to watch for

Be careful if a vendor:

• Asks for your organization’s password instead of using their own account

• Wants full administrator access without explaining why

• Refuses to use multifactor authentication

• Tells you to turn off security settings

• Asks you to approve sign-ins you do not recognize

• Uses pressure, urgency, or annoyance to get around your process

• Cannot explain who will use the access

• Wants access to unrelated systems

• Says access cannot be limited, even when the system allows it

• Insists on owning accounts that should belong to your organization

• Avoids putting access expectations in writing

• Keeps access after the work is complete

One warning sign doesn't always mean something bad is happening. But it does mean you should slow down and ask more questions. A trustworthy vendor shouldn't be offended by reasonable access controls. In fact, they should understand why these questions matter.

What you can do

You don't need a complicated vendor security program to make better access decisions. Just start with a few simple habits.

• Create separate accounts for vendors whenever possible.

• Avoid sharing your organization’s regular login.

• Use the lowest level of access that allows the vendor to do the work.

• Turn on multifactor authentication for important accounts.

• Keep a simple list of outside users who have access to key systems.

• Write down what each vendor can access and why.

• Review vendor access on a regular schedule, such as quarterly or twice a year.

• Remove access when the work is done.

• Change passwords if a shared password was used.

• Avoid sending passwords through email, text, or chat.

• Make sure your organization, not the vendor, owns critical accounts such as your domain name, website, email, social media pages, payment tools, and key business systems.

For small organizations, even a basic access list can make a big difference. It doesn't need to be fancy.

A simple spreadsheet can help you track:

• Vendor name

• Contact person

• System or account accessed

• Level of access

• Reason for access

• Date access was granted

• Expected end date

• Person responsible for reviewing or removing access

The important part is having a way to see who has access before something goes wrong.

Final takeaway

Vendor access is part of running a modern small business or nonprofit. The goal isn't to block every vendor, slow down every project, or make people jump through unnecessary hoops. The goal is to be thoughtful before handing someone access to accounts, systems, money, data, or public-facing tools.

Before granting access, ask exactly what the vendor needs, why they need it, who will use it, how they will sign in, what they can see or change, and when the access can be removed.

Use separate accounts when possible. Limit access when you can. Turn on multifactor authentication. Keep track of who has access. Remove access when the work is done.

A little structure up front can prevent a lot of confusion later. Vendor access should help your organization get work done. It shouldn't quietly become an open door.