Customer Portal Security and UK GDPR: A Checklist for Your IT and Compliance Team

A customer portal is not a brochure with a login. It is a system your customers run themselves, reading and writing data that sits in your CRM and connected systems. That makes it a real piece of infrastructure, and it puts your IT and compliance team squarely in the approval path. The moment external users can see account data, raise requests or download documents, you have created an internet-facing surface that holds personal data and is governed by UK GDPR.

This checklist is written for the people who have to sign off on that. It is deliberately practical: the controls a mid-market B2B operator should expect from a portal before it goes live, and the questions to put to whoever is building it. If you want the wider strategic picture first, start with our pillar on customer portals for mid-market B2B. If your portal will hold regulated client data, also read the deeper treatment in secure client portals for financial services.

Authentication: who is allowed in

Authentication is the front door, and weak authentication undermines every other control. Set the bar here first.

• Single sign-on (SSO) where it fits. If your customers are businesses with their own identity provider, support SAML or OIDC so their IT controls the login and offboarding. For consumer-style or mixed audiences, a hardened email-and-password flow with sensible defaults is reasonable.
• Multi-factor authentication (MFA). Available for every user, enforced for any account that can see sensitive data or perform privileged actions.
• Sane session handling. Short-lived sessions, secure and HttpOnly cookies, idle timeout, and a working logout that actually invalidates the session server-side.
• Credential hygiene. Passwords stored as salted hashes (never reversible), rate limiting and lockout on the login endpoint, and a password-reset flow that does not leak whether an account exists.

Authorisation: who can do what, on whose data

Authentication proves identity; authorisation decides what that identity is allowed to touch. For a portal this is the control that goes wrong most often, because external users frequently share the same screens but must never see each other's records.

• Least privilege by default. A user starts with the minimum access needed and is granted more explicitly, not the reverse.
• Tenant and record isolation. Every read and write must be scoped to the user's own account or organisation. Enforce this on the server for each request, never by hiding a button or filtering in the browser.
• Defined roles. Admin, standard user and read-only as a minimum, mapped to clear permissions on objects, fields, notifications and integrations.
• Insecure direct object reference (IDOR) checks. Changing an ID in a URL or API call must not expose another customer's data. This is the single most common portal vulnerability, so insist it is tested.

Encryption: data in transit and at rest

• In transit. TLS everywhere, modern cipher suites, HSTS, and a redirect from any plain-HTTP request.
• At rest. Encrypted databases and storage, with documented key management. You should be able to ask where the keys live and who can access them.
• Secrets. API keys and integration credentials held in a secrets manager, not in source code or config files, and rotatable without a rebuild.

Audit logging and monitoring

If you cannot reconstruct who did what and when, you cannot answer a security question, satisfy an auditor, or respond properly to an incident.

• Authentication events. Logins, failures, MFA challenges, password resets and lockouts.
• Data access and changes. A record of who viewed or modified sensitive records, with timestamps and the acting user.
• Tamper resistance and retention. Logs that ordinary users cannot edit, retained for a defined period that matches your policy.
• Alerting. Notification on suspicious patterns such as repeated failed logins or unusual data export volumes.

Data minimisation and the CRM as source of truth

UK GDPR expects you to collect and expose only what you need. A portal that mirrors your entire CRM to external users is both a compliance risk and a maintenance burden. The cleaner pattern is to keep the CRM as the single source of truth and let the portal surface a defined slice of it through a controlled integration.

• Show only the fields a customer needs to see. Map portal fields deliberately rather than exposing objects wholesale.
• Avoid duplicating personal data into a separate store that then drifts out of sync. We cover the underlying plumbing in our work on data engineering and integrations.
• Define retention. Know how long portal-side data is kept and how it is purged when an account closes.

UK GDPR: lawful basis, subject rights and residency

This is the section your compliance lead cares about most. None of it is exotic, but it must be designed in rather than bolted on.

• Lawful basis. Be clear on why you process the personal data in the portal. For a customer portal this is usually contract performance or legitimate interests; document the decision.
• Data subject rights. You must be able to action access, rectification and erasure requests. A portal that lets users view and correct their own details often helps here, but you still need a route to fulfil erasure across the CRM and the portal.
• Data residency. Know where the data is hosted. If UK or EU residency matters to your customers or sector, confirm the hosting region and document any international transfers and their safeguards.
• Processor relationships. Whoever hosts or builds the portal is likely a processor. You need a data processing agreement and a clear record of sub-processors.

Testing, hardening and ongoing assurance

• Penetration testing. An independent test before launch, covering authentication, authorisation, IDOR and the integration endpoints, with findings remediated and re-checked.
• Dependency and patch management. Known-vulnerability scanning on libraries and a process for applying security updates after launch.
• Backups and recovery. Tested backups and a stated recovery objective, so an incident does not become data loss.
• Incident response. A defined path for breach detection, containment and the 72-hour notification obligation under UK GDPR.

How this looks on a productised build

Security questions often stall portal projects because the answers depend on architecture decisions no one has made yet. A productised approach helps here: a SpotDev customer portal is built on established foundations and proven journey patterns, which means the authentication, authorisation, encryption and audit-logging behaviours are decided up front rather than reinvented per project. It is fixed-price from £15,000 and launched in 30 days from signing, integrated with your existing systems and keeping the CRM as the source of truth. That depends on a fixed scope and prompt access to your systems, and it gives your IT and compliance team a known shape to review against, not a blank sheet.

Not sure whether your current setup is fit to expose to external users? A SpotDev diagnostic is a sensible first step. And if you are still weighing your options, our guide to build versus buy for a customer portal walks through the trade-offs, including the security and control implications of each route.

The checklist, in one place

• SSO or hardened auth, MFA enforced for sensitive accounts, secure session handling
• Least privilege, server-side record isolation, defined roles, IDOR testing
• TLS in transit, encryption at rest, secrets in a manager
• Audit logs for auth and data events, tamper-resistant, retained and alerted on
• Data minimisation, CRM as source of truth, defined retention
• Lawful basis documented, subject rights actionable, residency confirmed, DPA in place
• Independent pen test, patch management, tested backups, incident response plan

Work through it with whoever is building your portal. If they can answer every line clearly, you have a partner who treats security as a design input rather than an afterthought.

Frequently asked questions

Does a customer portal need to be UK GDPR compliant?

Yes. If the portal holds or exposes personal data about identifiable people, it falls under UK GDPR. That means you need a documented lawful basis for the processing, the ability to action access, rectification and erasure requests, clarity on where the data is hosted, and a data processing agreement with anyone who builds or hosts it. These obligations should be designed in from the start, not added after launch.

What is the most common security flaw in customer portals?

Broken authorisation, usually in the form of insecure direct object reference (IDOR). This is where changing an ID in a URL or API request lets one user see another user's data. Because portal users often share the same screens but must only ever see their own records, isolation has to be enforced on the server for every request. Insist that authentication, authorisation and IDOR are covered by an independent penetration test before go-live.

Should a customer portal store its own copy of customer data?

As little as possible. The cleaner pattern is to keep your CRM as the single source of truth and let the portal surface a defined slice of it through a controlled integration, rather than duplicating personal data into a separate store that drifts out of sync. This supports data minimisation under UK GDPR and reduces the amount of data you have to secure, retain and eventually purge.

Can our IT team review a portal's security before we commit?

They should. A productised build helps because the security architecture, including authentication, authorisation, encryption and audit logging, is decided on established foundations rather than reinvented per project, so there is a known shape to review against. Ask for documentation on encryption in transit and at rest, role and permission model, audit logging, hosting region, and the results of independent penetration testing.

What audit logging should a customer portal provide?

At a minimum it should log authentication events such as logins, failures and password resets, and data events such as who viewed or changed sensitive records, each with a timestamp and the acting user. Logs should be tamper-resistant so ordinary users cannot edit them, retained for a defined period, and monitored so suspicious patterns like repeated failed logins or unusual export volumes trigger an alert.