Client Portal Requirements Checklist: Who Sees What, What Updates, and How Access Ends

Write access as role, record and action rows

Start the access section with a simple table: one row per role, record type and action. For example, a client contact can view their own project updates and upload documents, but cannot view another client's records or edit an approved invoice. A coordinator can edit records for assigned clients only. An administrator can manage user accounts. Keep the wording concrete enough that two readers would make the same decision.

OWASP describes authorization as verifying that a requested action or service is approved for a specific entity, and notes it is distinct from authentication, which verifies identity. A user who has been authenticated is often not authorized to access every resource or perform every action technically possible in a system. [4]

OWASP recommends enumerating the types of users accessing the system, the resources exposed, and the operations such as read, write and update that might be performed on those resources, then determining for every combination what operations a user must be able to perform. [4]

Decide who owns each update

For every record type in the portal, name the role that creates it, the role that updates it, and the role that confirms it is current. A status field might be updated by the delivery team, while a contact detail is updated by the client. Write down what the portal should show when an update is late or missing, such as a last-updated note or an owner prompt.

OWASP recommends creating tests that validate the permissions mapped out in the design phase are being correctly enforced, and reviewing permissions periodically after deployment for privilege creep, so that user privileges do not exceed those originally defined plus any formally approved changes. [4]

Plan offboarding before launch

Write the offboarding steps for each role: who requests removal, who approves it, what happens to records the person owned, and how quickly access ends. Include temporary access for auditors or contractors with an end date. Test the removal path on a test account in an isolated non-production environment so the process is demonstrated rather than assumed.

OWASP recommends enforcing least privileges, assigning users only the minimum privileges necessary to complete their job, and applying that principle both horizontally and vertically. It also notes that it is easier to grant users additional permissions than to take away permissions they previously had. [4]

Use deny-by-default as the starting position

Write into the brief that a new role starts with no access until a specific permission is justified and recorded. Ask the delivery team to show where that default is configured, and note any place where a framework default is being relied on instead of an explicit setting.

OWASP recommends that an application be configured to deny access by default, because logic errors and other mistakes relating to access control may happen when access requirements are complex, and one should not rely entirely on explicitly defined rules for matching all possible requests. [4]

Test access with negative checks, not just positive ones

For each role, write at least one negative test: a record the role should not see and an action the role should not perform. Run these checks in an isolated non-production environment before launch, and record the result. If a check fails, treat it as an open item with an owner and a date rather than a note for later.

OWASP recommends validating permissions correctly on every request, regardless of whether the request was initiated by a script, server-side, or any other source, and notes that even a single missed access control check can jeopardize the confidentiality or integrity of a resource. [4]

Keep the access section short enough to review

A portal brief does not need a long security chapter. We recommend keeping it to a few pages covering roles, records, actions, update owners, offboarding and negative tests, which is usually enough to start a productive conversation. Circulate the draft to one person from each role and ask them to mark anything unclear or missing before design begins.

SistemaHub builds custom web applications for Philippine businesses, including client portals described as customer records, follow-ups, communication logs and pipelines. [5]