Client Portal Requirements Checklist: 40 Questions Across Users, Permissions, Documents and Billing

Broken access control is the most common serious flaw in web applications: OWASP's Top 10:2025 found some form of it in 100% of the applications tested, across 1.84 million recorded occurrences. A client portal is an access control system with a login screen on the front, so most of the questions that decide whether it works are about who can see what.

This checklist gives you 40 questions in six sections, each with the public standard or vendor document to check the answers against. Copy them into a sheet, answer them with the people who will run the portal, and hand the sheet to whoever quotes the build.

How to use this checklist

Answer the questions in order, because earlier answers change later ones. Write one line per answer, plus the name of the person who gave it. "Not sure" is a valid answer; it becomes a discovery task rather than an assumption buried in a quote.

If you are still deciding whether a portal is worth building, our post Client Portal Adoption Statistics 2026 covers usage rates and ticket deflection. This page assumes the decision is made.

Users, sign-in and sessions

• 1. How many client organisations will use the portal in year one, and how many in year three?
• 2. How many people per client organisation log in, and do they come and go often (staff turnover, project teams)?
• 3. Who creates accounts: your staff, a client admin who invites colleagues, or self sign-up with approval?
• 4. Which sign-in methods are required: email and password, magic link, Google or Microsoft single sign-on, or a client's own identity provider?
• 5. Is multi-factor authentication required for everyone, for admins only, or optional?
• 6. How long should a session last before the portal logs someone out, and does that differ for staff and clients?
• 7. Does anyone need to act on behalf of a client (a staff member viewing the portal as the client sees it), and is that logged?

Passwords. If you keep passwords, NIST's SP 800-63B-4, published in August 2025, says single-factor passwords must be at least 15 characters, and verifiers must not impose composition rules or force periodic changes. Older specs asking for "one capital, one number, change every 90 days" are now out of date.

Sessions. OWASP's Session Management Cheat Sheet notes common idle timeouts of 2 to 5 minutes for high-value applications and 15 to 30 minutes for low-risk ones. Pick a number and write it down.

Accessible login. WCAG 2.2 added success criterion 3.3.8, Accessible Authentication (Minimum), at level AA: no login step may require a cognitive function test, such as remembering a password, unless an alternative or an assisting mechanism is available.

Roles and permissions

Spend time here. The failures OWASP describes under broken access control are the ones portals are prone to: viewing someone else's account by changing an ID in a URL, and API endpoints with missing access controls.

• 8. List every role. For most portals that means at least client admin, client member, staff member and staff admin.
• 9. For each role, what can it see, create, edit, approve and delete? Write it as a grid, one row per role and one column per object.
• 10. Can one person belong to more than one client organisation (an accountant at three companies, a consultant on two projects)?
• 11. Are permissions set per organisation, per project or per document?
• 12. Who can change a person's role, and does that change need approval or a log entry?
• 13. What should a former employee of a client see the day after they leave? Who removes them?
• 14. Must one client's data be separated from another's at the database level, or is application-level filtering acceptable?

Deny by default. OWASP's Authorization Cheat Sheet recommends enforcing least privilege, denying by default and validating permissions on every request. Question 9 is where that starts: anything not written in the grid is denied.

Tenant isolation. OWASP's Multi-Tenant Security Cheat Sheet recommends testing the authorisation matrix for each tenant-scoped table, proving that cross-tenant operations are denied and same-tenant operations succeed. Supabase's documentation puts it bluntly: a table in an exposed schema without row level security is readable and writable by any role with a grant on it. Whatever the stack, the answer to question 14 should name the mechanism and how it is tested.

Documents and files

Documents are usually why a portal exists: contracts, reports, statements, deliverables, and the files clients send back. OWASP's File Upload Cheat Sheet is the reference here. It recommends an allowlist of permitted file types, validating type rather than trusting the Content-Type header, renaming files, size limits, uploads only by authorised users, storage outside the web root, and antivirus or sandbox scanning where available.

• 15. Which document types flow each way: you to the client, the client to you, or both?
• 16. Which file types and sizes are allowed? Write the allowlist.
• 17. Do uploaded files need malware scanning before anyone opens them?
• 18. Do documents have versions, and must old versions stay visible?
• 19. Do any documents need signing, approving or acknowledging inside the portal?
• 20. How long is each document type kept, and what happens to it when a client leaves?
• 21. Can files be shared by link outside the portal, and if so, do links expire?

Question 19 often grows scope. Recording an "approve" click is small; a legally binding electronic signature is usually a separate third-party integration.

Messages, requests and notifications

A portal that only displays information tends to push the real conversation back into email. Gartner's survey of 5,728 customers, reported in 2024, found only 14% of service issues were fully resolved in self-service. The questions below decide whether clients can finish a task in the portal or have to leave it.

• 22. What can a client request in the portal (a change, a document, a meeting, support), and who receives each request?
• 23. Do requests need statuses, owners and due dates, or is a message thread enough?
• 24. Which events send an email or other notification, and can clients switch each one off?
• 25. Must messages sync with an existing helpdesk, CRM or shared inbox?
• 26. What does a client see when nobody has replied, and what is the promised response time?

Answer question 24 with a list of events, each with a default and an off switch.

Billing and payments

• 27. Does the portal show invoices only, or take payments too?
• 28. Which payment methods are needed: card, bank transfer, direct debit, or invoice terms?
• 29. Are there subscriptions, retainers or usage charges, or only one-off invoices?
• 30. Where are invoices created today (accounting software, a billing platform, by hand), and which system is the source of truth?
• 31. Can clients update their own billing details, download receipts and change plans?
• 32. Which currencies and tax rules apply?
• 33. Who can see invoices inside a client organisation: everyone, or only billing contacts?

Stripe's security guide states that a business handling card data directly when accepting payments "might be required to meet more than 300 security controls in PCI DSS". Stripe's customer portal, configured in its Dashboard or through its API, lets customers update billing information, payment methods and subscription status. That is a vendor describing its own product, so check it against your requirements. Question 33 is a permissions question, so add invoices to the grid from question 9.

Data, privacy, audit and handover

• 34. Which actions must be logged: sign-ins, failed sign-ins, permission changes, downloads, deletions?
• 35. Who can read the logs, and how long are they kept?
• 36. Can a client export all of their data, in what format, and how quickly?
• 37. When a client asks for deletion, what is deleted, what is kept for legal reasons, and how are backups handled?
• 38. Where must data be hosted (EU, UK, US), and which sub-processors are acceptable?
• 39. Which existing systems must connect on day one, and which can wait for a second phase?
• 40. Who owns the code, the hosting accounts and the domain after launch, and who maintains it?

Logging. OWASP's Logging Cheat Sheet lists authentication successes and failures, authorisation failures, and user administration actions such as adding or deleting users and changing privileges among the events to record. Those map directly to question 34.

Deadlines. GDPR Article 15 gives people the right to a copy of their personal data, and Article 12 requires a response without undue delay and within one month, extendable by two further months for complex cases. For EU or UK users, question 36 needs a working answer at launch. OWASP's multi-tenant guidance adds that a documented retention and deletion policy should cover caches, replicas, exports and backups, which is the detail question 37 is asking for.

What this means for your portal brief

The 40 answers are the brief. A team quoting without them is guessing, usually at the cheapest reading of each question.

Answer it with the people who will run the portal, mark every "not sure" as a discovery task with an owner, and keep the permission grid from question 9 up to date, because every later change will touch it.

We build applications like this in Next.js, and we would start any portal project by working through these questions with the client before quoting. Our web apps service page explains how we scope it.