Client Portal Security: Logins, Permissions and Protecting Client Data

Client portal security comes down to one promise you make to every customer who logs in: they will see their own information, and nobody else will. A portal is a convenient way to share documents, invoices and updates, but it also gathers a lot of personal and commercial data behind a single login screen. If that screen, or the rules behind it, are weak, the convenience becomes a liability.

The good news is that most portal security problems are well understood and preventable. This guide explains, in plain terms, how logins, permissions, document storage and monitoring should work in a well-built client portal, what the UK regulator expects, and the questions to ask before you trust a supplier with your clients’ data. It reflects the same checklist we work through in our own custom client portal development.

This article is about systems rather than legal advice. If you are unsure about your obligations under UK GDPR, the ICO’s guidance or a data protection specialist is the right place to check.

What a client portal actually has to protect

Before thinking about passwords and encryption, list what is really at stake. A typical client portal holds some mix of:

• Personal data: names, addresses, phone numbers and email addresses, and sometimes more sensitive details such as health information, ID documents or bank details.
• Documents: contracts, reports, certificates, plans, payslips or tax papers that clients would never want a stranger to read.
• Financial records: invoices, balances, payment history and, if you are not careful, payment card details.
• Conversations: messages about jobs, disputes or private circumstances.
• Your own admin tools: the staff side of the portal, where someone with the wrong access could change records or see every client at once.

That last point is easy to overlook. A client portal is not just a window for customers. It is usually a front end to your core business data, so a weakness in it can expose far more than one account. If you are still deciding whether you need one, our guide to what client portals are and when a business needs one covers the basics.

What UK law expects from you

UK GDPR does not give you a fixed list of security features. Instead, it requires “appropriate technical and organisational measures”, judged against the risk to the people whose data you hold. The ICO’s guide to data security sets out what that means in practice, and a few points are directly relevant to portals:

• Your measures must protect the confidentiality, integrity and availability of the data, so clients’ information stays private, accurate and accessible when they need it.
• The ICO recommends encryption if you are storing personal data or transmitting it over the internet.
• You need a process for regularly testing whether your measures work, for example through vulnerability scanning or penetration testing.
• Any supplier that processes data for you, including the company that builds or hosts your portal, must also have appropriate measures in place.

The ICO also points to Cyber Essentials as a good starting point for basic technical controls, while noting that you may need to go further depending on what you process. A portal holding medical notes needs more care than one showing delivery dates.

Logins: the front door of your client portal

Many attacks on online accounts are not clever hacking. They are passwords stolen from other websites being tried on yours, known as credential stuffing. It works because many people reuse passwords. Your login process needs to assume that some clients’ passwords are already in criminal hands.

Sensible password rules

The NCSC’s advice on passwords has moved a long way from the old “eight characters with a symbol, changed every 90 days” approach. For people running systems, it recommends:

• blocking the most common and easily guessed passwords with a deny list, rather than imposing complexity rules;
• not forcing regular password changes, and only asking for a change when there is a sign the password has been compromised;
• allowing long passwords and password managers, with no artificial cap on length;
• throttling or locking out repeated failed attempts, with the NCSC suggesting between 5 and 10 attempts before a lockout.

Passwords must also be stored properly, using a modern, slow hashing method designed for passwords. If a supplier can email a client their existing password, it is not being stored safely.

Two-factor authentication and passkeys

Two-factor authentication adds a second factor, such as a code from an app or a prompt on a trusted phone, so a stolen password is not enough on its own. The NCSC’s guidance on choosing authentication methods for customer-facing services makes several practical points that suit client portals well:

• Offer clients a choice of second factor, so you cover as many people as possible.
• SMS codes are the most widespread and familiar option, but they are not the most secure.
• Do not demand a second factor on every visit. Ask for it on high-impact actions, such as changing a password or account details, and whenever a sign-in looks unusual, such as from a new device.
• Plan for people who lose their phone, because account recovery is where good intentions often fall apart.

Passkeys are now worth serious consideration too. In April 2026, the NCSC announced that passkeys should be the default login option businesses offer consumers, because they are harder to phish and easier to use than passwords. A passkey lets a client sign in with their phone’s fingerprint reader or face unlock, and there is no password for anyone to steal. Offering passkeys alongside a password and second factor is a realistic option for a new portal today.

Account recovery: the side door

A strong login with a weak “forgot password” process is like a good front door lock with the back door left open. Password reset links should work once, expire quickly and never reveal whether an email address has an account. Changes to a client’s email address or phone number should trigger a notification to the old contact details, so a hijacked account does not go unnoticed.

Permissions: making sure clients only see their own data

If logins are the front door, permissions are the locks on every room inside. The OWASP Top 10, a widely used list of web application security risks, ranks broken access control as the number one risk in its 2025 edition, as it was in 2021.

In plain English, broken access control means a logged-in user can reach something they should not. A classic example: a client views an invoice at an address ending in invoice/1041, changes the number to 1042 and sees another client’s invoice. The portal checked that they were logged in, but not that the invoice was theirs. OWASP’s advice for preventing this includes:

• Deny by default. Nothing is visible unless a rule specifically allows it.
• Check ownership on the server, every time. Hiding a button in the browser is not security, because anyone can send requests directly.
• Build the checks once and reuse them across every page, download and API, rather than remembering to add them each time.
• Test access rules automatically, so a future change cannot quietly remove them.

Design roles around real relationships

Most portals need more than “client” and “admin”. Here is an illustrative example of a property management portal:

• A landlord sees their own properties, statements and certificates.
• A tenant sees their tenancy, rent account and repair requests, and nothing about the landlord’s other properties.
• A contractor sees only the jobs assigned to them, with the address and access notes, but no rent or personal financial details.
• Office staff see what their role requires, and only a small number of people can export data or change permissions.

Agreeing roles like these before anything is built saves rework, and it is one reason portals vary so much in price. Our guide to how much a client portal costs in the UK explains how features like multiple user types affect the budget.

Protecting documents and data

Documents are often the most sensitive thing in a client portal, and the easiest to get wrong. A well-built portal handles them like this:

• Encrypted connections everywhere. Every page and download is served over HTTPS, with no exceptions for “unimportant” pages.
• Private storage. Files sit in storage that cannot be reached by guessing a web address. Downloads go through the portal’s permission checks, or use short-lived links that expire after a few minutes.
• Encryption at rest. Databases, file storage and backups are encrypted, so a stolen disk or a misconfigured backup does not hand over readable data.
• Safe uploads. Files clients upload are limited to sensible types and sizes and scanned for malware before staff open them.
• Tested backups. Portal data is backed up to a separate location and restores are tested, as described in our guide to backups and the 3-2-1 rule.

Hold less data in the first place

The safest data is data you never store. If clients pay through the portal, let a specialist payment provider handle the card details rather than your own system. Our CoachSync booking and payments app, for example, takes payments upfront through Stripe and sends confirmation and reminder emails automatically. The same principle applies elsewhere. If you only need the last four digits of an account number to identify it, do not store the whole thing.

Logging and monitoring: knowing when something is wrong

Good client portal security includes knowing what happened, not just trying to stop things happening. A portal should keep an audit trail showing who logged in, from where, and which documents they viewed or downloaded. This helps when a client says “I never saw that letter”, and it is essential if you ever need to investigate a breach.

Logs are only useful if someone reads them or the system raises the alarm. Useful alerts include repeated failed logins against one account, a single user downloading an unusual number of files, and repeated attempts to open records that belong to someone else. OWASP specifically recommends logging access control failures and alerting administrators when they repeat.

It is also worth knowing your reporting duty before you need it. Under UK GDPR, if a personal data breach is likely to put people’s rights at risk, you must tell the ICO without undue delay and, where feasible, within 72 hours of becoming aware of it. If the risk to individuals is high, you must tell them too. A portal with clear logs makes those first 72 hours far less chaotic.

Keeping the portal patched and well run

Security is not something a portal has on launch day and keeps forever. Every portal relies on frameworks, libraries and hosting software that receive regular security fixes. The 2025 OWASP Top 10 widened its old “vulnerable and outdated components” category into “software supply chain failures”, now ranked third, reflecting how often attacks now come through third-party components.

In practice, that means:

• a maintenance arrangement that applies security updates promptly, not once a year;
• automated checks that flag known vulnerabilities in the portal’s components;
• a simple process for removing staff accounts the day someone leaves;
• periodic security testing, especially after major changes.

Many of the same habits apply to your public website, which we cover in our guide to keeping your website secure.

Security that clients will actually use

If a client portal is so awkward to log into that clients give up, they go back to emailing attachments, and your carefully protected documents end up sitting in personal inboxes. Strong security that nobody uses protects nothing.

Some ways to keep client portal security and usability in balance:

• Remember trusted devices, so clients are not asked for a code every time they log in from their own phone.
• For clients who only log in once or twice a year, consider email sign-in links. The NCSC notes these suit services where ease of use matters as much as security, so reserve them for lower-risk portals.
• Explain why you are asking for a second factor during sign-up, in one or two plain sentences.
• Give your team a clear, secure process for helping clients who are locked out, so staff are not tempted to bypass the checks.

Questions to ask a client portal supplier

Whether you are buying an off-the-shelf portal or commissioning a custom one, these questions will tell you a lot about how seriously security is taken:

1. How are passwords stored, and do you block common or breached passwords?
2. Which second factors do you support, and do you support passkeys?
3. How do you make sure one client can never see another client’s records, and how is that tested?
4. Where is our data hosted, and is it encrypted both in transit and at rest?
5. How are uploaded files stored and scanned?
6. What activity is logged, how long are logs kept, and who reviews them?
7. How quickly are security updates applied, and is that included in support costs?
8. Has the portal been independently tested, and can we see a summary of the results?
9. How do we get all of our data out if we leave?
10. Who do we call if we suspect a breach, and how fast will they respond?

A good supplier will answer these clearly and in writing. Vague answers, or “it’s all secure, don’t worry”, are a warning sign.

Client portal security: common questions

Is an off-the-shelf portal more secure than a custom one?

Not automatically. A large product has more people looking for weaknesses, and more people fixing them, but it is also a bigger target and you cannot control how it is configured. A custom client portal can be very secure if it is built on established frameworks, follows OWASP guidance and is maintained properly. What matters is the quality of the build and the ongoing care, not the label.

Should two-factor authentication be compulsory for clients?

It depends on what the portal holds. For financial, legal or health information, making a second factor or passkey compulsory is reasonable. For lower-risk portals, you might make it optional but encouraged, and require it only for sensitive actions such as changing bank details. Staff and administrator accounts should always use a second factor.

What should we do if a client’s account is compromised?

Lock the account, end any active sessions, reset the login and second factor, and use the audit trail to see what was accessed. Then assess whether the incident is a reportable personal data breach. Write this down as a short procedure before you need it.

Does good security make a portal much more expensive?

Building security in from the start adds relatively little. Retrofitting it after launch, or dealing with a breach, costs far more. The main cost drivers are the number of user types and permission rules, any independent testing, and the level of ongoing maintenance you choose.

The bottom line

Client portal security is not about one clever feature. It is a set of sound habits: strong but usable logins, permissions checked on every request, documents stored privately, activity logged and the software kept up to date. Get those right and a portal is far safer than the email attachments it replaces.

If you are planning a portal, or you are not sure the one you have would stand up to scrutiny, tell us what it needs to protect or call us on 01482 212499. We will give you an honest view of where the risks are and what is worth fixing first.