Direct answer
A client portal's central risk is who can see what. Almost every serious portal failure comes down to one client seeing another client's records, a former user still having access, or a document link that works for someone it should not. Security for a portal is therefore mostly about identity, boundaries and visibility, designed from the start and checked regularly, rather than a layer added at the end.
This is a design and operations checklist you can use to write requirements, review a proposal or examine an existing portal. It is not a certification, a penetration test or legal advice. Confirm any regulatory or contractual duties with a qualified professional. For the wider build, see client portal development.
Authentication
Authentication answers who is asking. Decide how users prove it and what happens when things go wrong.
- Every user has their own account; shared logins are not allowed, because no action can then be attributed to a person
- Passwords are never stored in readable form, and the sign-up and reset flows do not reveal whether an email address is registered
- Multi-factor sign-in is offered, and considered mandatory for staff and for any user who can see sensitive data
- Password resets and email changes expire quickly and are confirmed through the existing address
- Repeated failed sign-ins are slowed down or locked, and the user is told
- Sessions end after a sensible period of inactivity and can be ended from the account
Roles
Authentication says who someone is; roles say what they may do. Define a small set of roles per client organisation (for example an administrator who manages users, and a standard user who views and acts) and a separate set of internal staff roles. Write down, for each role, which records and actions it has.
The vital rule is that checks happen on the server for every request, not just by hiding buttons on screen. If a user can change a number in a web address and see a different client's record, the interface hiding was cosmetic. The page on roles and permissions in a web application goes deeper on modelling them.
Tenant isolation
Isolation means that data belonging to one client organisation is separated from every other one. Decide how: a client identifier on every record and on every query, rules enforced by the data layer, or fully separate storage for each client. Which is appropriate depends on the sensitivity and the number of clients; the point is that it is a deliberate decision.
- Every query and every file access is scoped to the signed-in user's client organisation
- Search, exports, reports, notifications and background jobs respect the same boundary, not only the main screens
- Internal staff who can see several clients do so through a deliberate, logged mode, not by default
- Test with two test clients and try to reach one from the other, deliberately, before launch and after every significant change
Documents
Documents are often the most sensitive content in a portal and the easiest to leak. Check that files are stored privately, not at public web addresses, and that every download is authorised against the signed-in user, not merely hidden behind an unguessable link.
Where a link is shared for convenience, decide whether it should expire and whether it should require sign-in. Consider what should happen to file names and previews, which can reveal information on their own. Decide which file types and sizes are accepted from users, and whether uploaded files are checked before others can open them. Keep the original owner and upload date of every file.
Logging
Logging is how you find out what happened. At minimum, record sign-ins and failed sign-ins, password and email changes, role or permission changes, document downloads and exports, and any staff view of a client's data. Each entry needs who, what, when and which record.
Two cautions. Do not put passwords, tokens or full personal details into the logs themselves. And decide who reads the logs and how often; records nobody reviews only help after an incident. Clients often ask for a view of their own users' activity, which is a good feature to plan for.
Backups
Agree what is backed up, where copies are kept, who can reach them, and how long they are retained. Backups contain everything the portal contains, so they must be protected as carefully as the live data and must respect any deletion commitments you have made. Test a restore periodically into a separate environment; a backup nobody has restored is unproven.
Offboarding
Offboarding runs in two directions. When a person leaves a client organisation, their access should end promptly, and the client administrator should be able to do this themselves. When a whole client leaves, you need a defined process: export what they are entitled to, disable their users, and delete or retain their data according to what you agreed, confirmed with your own advisers.
Do the same for your own staff and for any vendor with administrative access. Review the list of who can sign in as an administrator on a regular schedule, and remove anyone who no longer needs it. Integration accounts count too; the guide to API credentials and service accounts covers them.
Incident basics
Decide before something happens who is told, who investigates and who speaks to affected clients. A one-page plan is enough to start with.
- A named person who can disable an account, a role or the whole portal quickly
- A way for users to report a problem, and a place where reports are collected
- Knowing how to see who accessed what, using the logs above
- A way to reset all sessions and rotate credentials
- A note of whom you must notify, decided with your legal adviser, not improvised at the time
Using the checklist
Turn each section into requirements before the build, and into checks at acceptance and at regular reviews afterwards. Decide the features the portal needs first; the client portal features priority guide helps sequence them, and each feature should arrive with its access rules. LATYNEX builds portals as custom web applications, remotely and in English, agreeing one scope and one price in writing before work starts. To see how we would apply this to your brief, start with client portal development.
Questions
Does following this checklist make a portal secure or compliant?+
No. It is a design and operations checklist. It does not certify anything, replace independent testing, or address specific legal or regulatory duties, which you should confirm with a qualified adviser.
Is multi-factor sign-in necessary for clients?+
It depends on the sensitivity of what they can see. Offer it to everyone and require it for staff and any user with access to sensitive data.
What is the most common portal security mistake?+
Checking access only in the interface. Every request must be authorised on the server, otherwise one client can reach another's data by changing an address or a request.
Should staff be able to see all client data?+
Only those who need to, through a deliberate mode that is logged. Default access across all clients is a risk in itself.
How often should the checklist be reviewed?+
At acceptance, after any significant change to roles or documents, and on a regular schedule you set. Access lists and logs deserve the most regular attention.