A customer portal development brief should specify who may access each record and action, how accounts are created and removed, how documents are protected and how those rules will be verified. Sign-in is only the beginning. The more important question is what a signed-in user is allowed to do.
For a business sharing invoices, project files or service requests with multiple customers, these requirements affect architecture and delivery effort. Putting them into the brief makes proposals more comparable and gives the buyer something concrete to accept before launch.
Start with a role and relationship inventory
List the people who use the portal and the organizations they represent. A hypothetical professional-services portal might include a customer administrator, customer employee, internal account manager and support operator.
Define their permitted actions in ordinary language. A customer employee may view assigned projects; a customer administrator may invite colleagues within that customer organization; an internal account manager may work with assigned accounts. Record exceptions and who can approve them.
Do not assume that every account belongs to exactly one organization. Consultants, group companies and delegated administrators may need more complex relationships. Clarify these cases early because a later workaround can weaken the original access model.
Require record-level authorization
The application should check whether a user may perform the requested action on the specific record. Hiding an interface button does not establish that the underlying operation is protected.
OWASP's object-level authorization guidance identifies the risk of retrieving or modifying another user's object by changing an identifier. Translate that risk into acceptance tests using your own portal records.
For the hypothetical portal, ask the supplier to demonstrate that changing a project reference does not reveal another customer's files. Repeat the check through search, exports, notifications and document downloads, not just the main project screen.
If background processing or support tooling accesses many customer accounts, include those paths in the review. Tenant boundaries need to remain meaningful outside the visible customer interface.
Specify the account lifecycle
Account security involves more than registration. Define the complete lifecycle from invitation to removal, including changes in employment, customer ownership and support responsibility.
The requirements list should answer:
- ▸Who is allowed to invite a user, and to which organization?
- ▸How does the system verify that the invitation reached the intended recipient?
- ▸When does an unused invitation expire?
- ▸What happens when a user changes role or leaves the organization?
- ▸Which sessions or credentials must be revoked after access is removed?
- ▸Who can recover an account, and how is that decision verified?
- ▸Which privileged accounts require stronger authentication?
Ask for evidence that revocation reaches the relevant application paths. Removing a user from a menu should not leave an active token or a separately shared document link with unintended access.
Treat documents and exports as application data
Document delivery can create a second access system beside the portal. Specify whether links require authentication, how long temporary download links remain valid and what happens after the underlying permission changes.
Define upload limits, allowed file types, malware-handling requirements and who can publish a document to customers. The appropriate controls depend on the workflow; an internal document library and a public submission portal do not have identical exposure.
Exports deserve particular attention. A report should reflect the requester's permitted records and fields, including during background generation. State how completed exports are stored, retrieved and deleted. Avoid making sensitive files permanently available simply because generating them took time.
Agree a verification scope
Use the OWASP Application Security Verification Standard as one input for specifying relevant technical checks. Name the version, applicable requirements, expected evidence and who reviews any exclusions. This turns a general security promise into a defined verification activity.
Request both successful and denied-action tests. A demonstration should cover legitimate access as well as another customer's identifier, an expired session, a revoked role and an unauthorized administrative action.
Separate internal testing from any independent assessment you require. Define whether remediation and retesting are included in the engagement. Avoid implying that a single test proves the portal will remain free of vulnerabilities after future changes.
Make audit trails useful to the business
Decide which events need an audit record, such as invitations, role changes, exports and access to particularly sensitive documents. Specify the actor, action, target, time and result needed for investigation.
Logs also contain information that needs protection. Decide who can inspect them, how long they are retained and what must be excluded or masked. A detailed record of every request is not automatically a better audit trail if it stores unnecessary sensitive content.
Define how an account owner can report suspected misuse and who investigates. Where a support operator can access customer data, establish an approved reason, appropriate controls and a record of that access.
Include privacy and operating questions
Identify the categories of personal data, expected retention and approved environments. Map cloud providers, subprocessors and support access. Canadian buyers can use the Office of the Privacy Commissioner's outsourcing guidance as a starting point for accountability questions under PIPEDA; other applicable requirements still need review.
Specify monitoring, backup recovery, dependency maintenance and incident escalation. Decide who is responsible after acceptance and which changes require a fresh security review. The maintenance agreement guide helps turn those decisions into operating obligations.
Accept the portal as a business system
Review the evidence against the actual customer workflows and access model. Record open issues with owners and decisions. Complete account and documentation handover before moving to ongoing support.
For a new portal, attach these requirements to your first-release scope. For an existing one, use them to commission a focused assessment before adding more sensitive workflows.
Explore software engineering services and share the portal users, records and access relationships. Those details help establish a useful scope for development or review.