Keep one column private (like pay or notes) in a shared list

Short answer: SharePoint has no column-level permissions. Move the private column to a second list with its own permissions and link the two lists with a lookup. Hiding a column in a view or a form changes what people see by default, but it does not stop them from reaching the data. If the data is very sensitive, keep it out of SharePoint.

The problem

You have a shared list. Maybe it is an Employees list that your whole team reads. One column does not belong in front of everyone. It could be pay, a performance note, a medical note or a private comment. You want most people to see the list and only a few people to see that one column.

It is a fair thing to want. SharePoint does not offer it as a setting. Microsoft's page on permission levels says the permissions scopes run from the broadest level down to "the narrowest level (a single item in a list)." A column is not one of those levels. A Microsoft Q&A answer says it plainly: "SharePoint does not have user permissions for specific columns within a list." That answer suggests hiding the column, or customizing the form with Power Apps. Both of those change what the screen shows. Neither one is a lock.

Why hiding a column is not security

A view is a display choice. Permissions are the lock. If a person can read the list, they can read every item in it, and the list gives them the whole item. Hiding a column in one view only removes it from that view.

Here is how the data can still reach people:

They can open another view that shows the column, or create their own view. Microsoft lists "Create, change, and delete personal views of lists" in the Edit and Contribute levels.
They can open an item and look at its details.
They can export the list to Excel and read the column there.
A list form made in Power Apps can hide a field on screen. The Microsoft Q&A answer notes that people might still change fields through the Edit in grid view option unless you turn that off. That makes a form a screen layer, not a lock.

If the hidden value would hurt someone when it is read, do not rely on a hidden column. Ask one question: "If a curious coworker went looking, could they find it?" If the answer is yes, move the data.

For the same point about filtered views, see "Let each person see only their own items in a SharePoint list".

Decide first: four choices

Use this list to pick a path before you build anything.

The column is only clutter, not private. Hide it in the default view. This is a tidy-up choice. Say so to your team. Nothing is protected.
The column is private, but the whole list can have limited readers. Give the whole list its own permissions. Only the right people open it. This is simple. It works when the people who need the column are the same people who need the list.
The column is private, but the rest of the list is open to many. Put the private column in a second list with its own permissions. Link it to the first list. This is the safe pattern for most cases.
The data is very sensitive, such as full pay records or health information. Ask your admin or security team before you use a list at all. A system built for that data may be a better fit.

The rest of this guide covers choice 3, because it is the one people get wrong.

The safe pattern: a second list with its own permissions

The idea is simple. Two lists, two sets of readers.

List one holds the public fields. Many people can read it.
List two holds the private fields. A small group can read it.
A shared key joins them. That key can be a lookup column, or the same name in the Title column.

Because the private data lives in a different list, a reader of list one has nothing private to find. No view, export or form in list one contains it.

What you should see: two lists in the site contents. Employees opens for everyone. Pay opens only for the HR group, and anyone else sees an access message.

Microsoft's help page on stopping inheritance describes how to give a list its own permissions. In short: Settings, then List settings, then Permissions for this list, then Stop Inheriting Permissions. Then grant access to only the people or groups you choose. Exact names may differ on your screen. Microsoft says it highly recommends "using the built-in SharePoint groups for communication sites and managing team site permissions through the associated Microsoft 365 group." Its help page also says: "While it's not recommended, breaking inheritance and setting item level permissions is a supported scenario within reasonable use." Keep the number of lists and items with their own permissions small.

Direction of the link matters. Put the lookup column in the private list, and point it at the public list. That way the private list says "this pay row belongs to that employee." The public list never needs to point at anything private. If you did it the other way, you would be showing private list data inside the public list, and that defeats the point. Test any lookup with a plain account before you trust it.

For lookups that show blank or too few fields, see "SharePoint lookup column shows blank or too few fields".

Worked example: Employees and Pay

You keep a team list. Everyone in the company can read it. A small group in HR also needs a pay column.

The public list: Employees

Title: the employee name. Keep one column that names the row.
Department: a Choice column.
Start date: a Date column.
Manager: a Person column.

Everyone who should find a coworker can read this list.

The private list: Pay

Title: the same employee name, typed the same way. Keep Title as your row name.
Employee: a lookup column that points to the Title column of the Employees list.
Pay rate: a Number column.
Pay type: a Choice column with numbered values: 1 Hourly, 2 Salary, 3 Contract.
Notes: a Multiple lines of text column.

Permissions on Pay:

The Pay list stops inheriting permissions from the site.
Only the HR group has access.
Everyone else, including most managers, has no access to the list.

What a regular employee sees: the Employees list, with no pay. If they type the address of the Pay list, they should be asked for access or be blocked. Test this with a plain account.

What HR sees: both lists. In Pay, the Employee column shows the name from the Employees list, so a row is easy to match.

Steps to set it up

Build the Employees list first. Add only the fields everyone may read. Rename Title if you want, for example to "Employee."
Create the Pay list on the same site. Microsoft says: "Lookup columns should be created and used within the same site."
In Pay, add a column and choose Lookup. Pick Employees as the source list and its Title column as the shown column. Microsoft's help page on lookup columns describes these choices. Exact names may differ on your screen.
Add Pay rate, Pay type and Notes to Pay. Number the Choice values: 1 Hourly, 2 Salary, 3 Contract.
Open the settings for the Pay list and go to its permissions page. Stop inheriting permissions.
Remove the groups that should not see pay. Grant access to the HR group only. Use a group, not a list of single names, so a new person in HR needs one change.
Add one row for yourself, or a test person, in Pay.
Test with a plain account that is not in HR. Open the Employees list: it should work. Open the Pay list: access should be blocked.
Test with an HR account. Confirm the Pay rows show.
Check the site owners. Owners and others with high permission can often still reach everything. Decide who holds those roles, and keep the number small.
Write down who is in the HR group. Review it every few months.

Limits to know

Microsoft's SharePoint limits page gives numbers for unique permissions. Microsoft says: "The supported limit of unique permissions for items in a list or library is 50,000. However, the recommended general limit is 5,000." Giving one list its own permissions, as in this guide, is far below that. The numbers matter if you were thinking of giving each row its own permissions instead. That means a lot of upkeep. Splitting the data into a second list is easier to manage than setting permissions row by row.

The same page says that when a list, library or folder holds more than 100,000 items, you cannot break permissions inheritance on the list, library or folder itself. A pay list for a small team will not get near that. A very large list might.

Lookup columns have a limit too. Microsoft's help page says: "You have exceeded the List View Lookup Threshold, which by default is twelve lookup columns." Two lists with one lookup is nowhere near it.

Making a column read-only for some people

The Microsoft Q&A answer suggests customizing the list form with Power Apps if you want to change what people can do on screen. That is a form setting, not a permission. The same answer says people might still change fields through the Edit in grid view option unless you turn that off. Use this only for tidiness. For data that must stay locked, use the second list.

What to avoid

Do not hide a column in a view and call it private. Views are not security.
Do not rely on a hidden field in a custom form alone. People can reach the data another way.
Do not put private data in a lookup that shows it inside the public list. Point the private list at the public one, not the reverse.
Do not copy the private column into an Excel file on a shared drive. That moves the problem.
Do not give everyone Edit on the site and hope. Check what each group can open.
Do not skip the plain-account test. It is the only test that proves a lock works.
Do not use this for data that law or contract tells you to protect without checking with your admin or security team first.

Honest limits

This guide uses what SharePoint does today. Microsoft's permission levels page lists no column level now. Check the current help pages before you rely on this guide. Names and menus change, so use the help pages in the sources for the exact steps.

A second list takes more work to keep tidy. You have two lists to update when a person joins or leaves. For a short list of people, that is fine. For a long one, ask whether a different system should hold pay data.

A training list has the same shape if you keep private scores in one place and the roster in another. See "How to set up a training record in SharePoint".

When to get help

You can build all of this yourself in Microsoft 365. If you would rather have it built and tested for your team, I do that. A tracker like this is a fixed price: $5,000 for one, built in 2 weeks. See "What a SharePoint tracker costs to build". Bring one example of the problem to a free call.

Tell me what's still manual

I am Al Davies. I run 250 High Street LLC and build SharePoint trackers and Power Automate flows for operations teams. I work remotely. The first call is free, and I will not try to sell you anything.

See trackers I built: Tools I built

FAQ

Can I set permissions on one column in a SharePoint list?

No. Microsoft's permission levels page says the narrowest level for permissions is "a single item in a list." You can hide a column, but hiding is not security.

Can I set SharePoint list field permissions?

Not on a field. Permissions can go down to a single item, not to one column. For a private field, use a second list with its own permissions.

Can I make a column read-only for some people?

Not with permissions. A Microsoft Q&A answer suggests customizing the form with Power Apps, and says people might still change fields through the Edit in grid view option unless you turn that off.

Can SharePoint list permissions follow a column value?

Not as a setting. Permissions attach to the site, list, or item, so a value in a column does not change who can open the row.

If I hide a column in the view, who can still see it?

Anyone who can read the list. They can open another view, open the item, or export the list. A hidden column only changes the default screen.