Can my staff see each other's certificates?

You give your staff a portal where each person can see their own certificates and upload new ones. The question you should be able to answer is simple: can a member of staff open it and see everyone else’s, including the reasons a manager rejected them?

In the compliance system we audited, the honest answer was “not today, but only because of a habit”. And separately, a role meant only to let people read the list of certificate types could see every named person’s compliance record.

This article records what we found and what we recommended. Most of it has not been changed.

What was actually going on

The portal has five permissions of its own: read your own profile, edit it, read your own certificates, upload a certificate, see your own training. Every portal screen checks the right one. The check works.

It does nothing about the word “own”. A permission answers “may this user do this kind of thing”. It cannot answer “to which person’s records”, because it was never told which records the request is about. That second question is answered in each of the eight portal handlers by the same eight lines, copied, which find the staff record linked to the signed-in user and limit the search to it. All eight are correct today.

The ninth is the risk. Somebody adds a summary or an export, gives it the right permission and writes the search, and forgets the limit, because nothing in the shape of the code reminds them. That screen would return the whole organisation’s certificates to any member of staff, and it would pass review, because its permission has “own” in its name. The safe version and the unsafe version look identical.

There is a second problem from the opposite direction. The screen that lists every employee’s certificate records, with names, expiry dates, verification outcomes and rejection reasons, is protected by the permission to view the certification catalogue, which is the list of course types the organisation recognises. A read-only role given that permission so it could see what a certificate means therefore also sees every named person’s compliance record. There is no separate permission for staff certificates, so there is no way to grant one without the other.

A third shows up on the dashboard, protected by the permission to view organisation settings. That permission has quietly become a flag meaning “this is a back-office user”, and it is relied on in four places. The day somebody asks for a role that can see the dashboard but not the settings, that takes a coordinated change across all four.

Last, administrators are given every permission, including the five portal ones, but administrators have no staff records. So the portal link appears for them, they click it, and they get an error.

What is still open

None of this has been fixed as described here. What we recommended is this.

The check for “whose records” should be a gate of its own, running before the screen, which finds the signed-in person’s staff record, attaches it to the request and refuses the request outright if there is none. Then a screen cannot run without knowing whose records it is working on, and forgetting becomes a missing piece, not a missing rule.

Each permission should protect one thing, so that reading staff certificates has its own. And the administrator’s grant should list what administrators are for, not “everything”, because “everything” includes every permission that will ever be added.

The one piece that was right: the portal permission for adding a certificate is called upload, not write, deliberately. Staff can create a submission and change it while it is pending, and cannot touch it once a manager has verified it, and the screen refuses the edit with a specific error. The name says what is meant and the screen enforces it.

What it did not fix

The error administrators saw was handled by a setting that hides the portal link for them. That treats the symptom far from the cause, which is a grant that says “all permissions” when it means “all administrative ones”.

And the eight copies are still eight copies. Turning them into a gate is a small change, but it touches the file that serves every self-service screen, which is the file you least want to get wrong. It is scheduled and has not happened. Until it does, the protection on those screens is that eight people got eight lines right.

The pattern, for anyone running a staff portal

Write down each permission your system has, and read its name aloud. Then list every screen it protects. If any screen is something the name would not have led you to expect, you have found a permission doing two jobs.

And ask who can see whose records, not only who can do what. Try it: sign in as an ordinary member of staff and look for anyone else’s name.

Where this ends up

The certificates in question are the ones Sazinga Comply tracks, with issue date, expiry and the evidence that closes each obligation. A portal that lets staff see their own is only worth having if the word “own” is enforced somewhere other than a search each screen writes for itself.