Evaluate a client portal by checking who can see and change each client's information, how access is granted and removed, and how the provider handles data and recovery. Use test accounts and ask for evidence behind security statements. A policy, feature label or planned safeguard is different from an implemented and tested control.
A client portal can bring files, conversations and engagement information into one place. That also makes access boundaries and operating responsibility part of the buying decision.
This guide gives agency owners questions to ask a provider and demonstrations to request. It does not certify a product or substitute for the technical review appropriate to the information an agency handles.
- Inventory informationIdentify data, files, activity and connected services.
- Test access boundariesCheck client and staff accounts separately.
- Request evidenceDistinguish statements, demonstrations and current evidence.
- Assess recovery ownershipTest exports and clarify interruption responsibilities.
This guide evaluates questions and demonstrations; it does not certify a product.
What information will the platform hold?
Begin with an inventory. Identify the client information, files and activity the workflow will use. Include connected services that receive information when an action runs.
Describe who needs access and for what purpose. A person reviewing design files may not need billing information or internal account notes. A subcontractor may need access to one engagement without receiving a wider client list.
Keep the inventory tied to the actual use case. A generic questionnaire is less useful if nobody has identified the data and actions being evaluated.
How are login and client-data access different?
Authentication and authorization answer different questions. A valid login does not by itself establish which client's records an account can view or change.
- AuthenticationEstablish which account is signing in.
- AuthorizationEstablish which records and actions it can access.
- Client test accountsCompare separate clients' files and actions.
- Staff test rolesInspect responsibility-specific permissions and changes.
A valid login alone does not establish client-record boundaries.
Ask the provider to demonstrate test accounts representing separate clients and different staff responsibilities. Inspect the files and actions each account can access, including the way permissions change when ownership or membership changes.
OWASP's authorization guidance recommends limiting access to what a user needs, checking permissions and testing those controls. Those principles support the evaluation questions here; they do not verify a vendor's implementation.
What should we ask about staff permissions?
Write down the actions each role needs. Viewing a client record, editing a project, exporting a list and deleting information may require different decisions.
Check administrative access separately. Identify who can grant permissions, connect services and change settings. Confirm the authentication options available in the version or plan you are considering.
Ask how access changes are recorded and reviewed. If the agency needs to investigate an inappropriate change, it should understand what information the provider can supply and who handles the request.
What happens when somebody leaves?
Demonstrate offboarding with a test account. Check staff access, client invitations and connected accounts. A former staff member should not retain access through an overlooked connection or shared account arrangement.
Agree on the agency's responsibilities as well as the provider's. Someone must know when membership changes and carry out the approved procedure.
Keep access records understandable. The next authorized administrator should be able to identify what was granted, why it was needed and how it can be removed.
Which evidence supports the provider's statements?
Separate current controls, tested controls and planned work. Ask what a demonstration establishes and what further evidence is available for the relevant use case.
- Provider statementTreat policy language as a commitment description.
- Demonstrated controlAsk what a demonstration actually establishes.
- Current evidenceCheck service scope, period and relevant limitations.
- Planned workKeep future safeguards separate from current controls.
Company-level claims may not apply to every product or feature.
If a provider names an audit or certification, ask what service it covers and whether the evidence is current. Avoid assuming that a company-level statement applies to every product, environment or feature.
Read policies as statements of the provider's commitments and descriptions. They are not independent proof that every stated control has been implemented or tested.
How can the agency recover and export its work?
Ask about exports and the information they include. Test a representative sample where practical, including relationships and activity the team needs to continue delivery.
- Export sampleTest needed relationships and activity information.
- Backup coverageAsk what restoration responsibility covers.
- Recovery testingRequest available evidence of testing.
- Service interruptionClarify how client work keeps moving.
Exports and backups answer separate recovery questions.
Discuss backups and restoration separately from exports. Ask who is responsible, what is covered and how recovery is tested. Clarify how the agency would keep client work moving during a service interruption.
For an early-stage or beta platform, assess that responsibility before putting an important workflow into it. Review the provider's actual terms instead of assuming the availability of a mature production service.
What should we ask about AI and connected services?
Identify the information supplied to any AI feature and the service receiving it. Ask which settings and agreements apply to that use, and what remains subject to human review.
Keep account access and client data out of demonstrations unless the participants are authorized to use them. Sanitized samples can help assess the workflow before live information is involved.
When the platform sends information to another service, ask who manages that connection and how it is removed. The portal's own access settings do not explain every downstream use of the data.
Who handles problems after implementation?
Name the contact for an access problem, a failed workflow and a security concern. Ask how the agency reports the issue and what information the contact needs to act.
| Area | Evidence or demonstration to request |
|---|---|
| Client boundaries | Separate client test accounts with appropriate record visibility |
| Staff roles | Available actions for the agency's intended responsibilities |
| Offboarding | Access removal, including relevant connections |
| Data handling | Current policies and a clear description of involved services |
| Recovery | Documented responsibilities and available evidence of recovery testing |
| Product claims | Current status, scope and evidence behind named controls |
Keep unresolved questions visible in the buying decision. A useful evaluation can end with a narrower pilot or a decision to retain the current system.
What should we verify about ScaleAxis OS?
ScaleAxis OS is offered in beta. Its terms caution against relying on the beta for revenue-critical operations without independent backup and recovery procedures. Its privacy policy describes data handling and safeguards; those descriptions need appropriate implementation evidence for your evaluation.
Ask ScaleAxis for current evidence about the controls relevant to your agency. If you are assessing a workflow, use the operations audit to discuss the work and request the information needed for the product or implementation decision.
Questions and answers
Does having a login prove that a portal separates client data?
No. Authentication identifies the account, while authorization determines what that account can access. Test different client and staff roles and ask how the platform enforces those boundaries.
What should we ask about a security certification?
Ask for the current evidence, the service and period it covers, and any relevant limitations. A named certification or audit in marketing copy does not establish that the specific product and use case are covered.
Should clients and staff have the same permissions?
Permissions should follow the work each person needs to do. Define client visibility separately from staff responsibilities, then test the actual accounts and offboarding process.
Does this checklist verify ScaleAxis OS security?
No. It is a vendor-evaluation guide. ScaleAxis OS is in beta; review its current terms and privacy policy, and request implementation evidence for the controls relevant to your agency. This article asserts no audit or certification.