Client portal access perimeter

The client portal moves an agreed work contour outside the internal team: a client sees published requests, documents, comments, and available actions. It is not a ready legal-delivery service and does not prove that an organisation met a particular requirement.

The access route

1. Define the client, project or request and the internal owner.
2. Create a separate external user account through an invitation.
3. Check the document, version, comments, and recipient company before publishing.
4. Give the client only the needed action: view, comment, or approve.
5. Check the portal as the external participant and remove unintended visibility.
6. Revoke the invitation or perimeter link when the work ends.
7. Record the internal decision and reason for changing access.

Owner checks

• the external participant is linked to the correct company and request;
• the published document has no internal notes or another client’s data;
• the client sees the expected status, file, and next step;
• internal tasks, service settings, and other companies remain hidden;
• the invitation and external channel can be revoked;
• the result is checked after the policy change, not only after saving it.

Boundary of the claim

The portal supports working interaction: viewing, commenting, and approving published material. Do not call approval a qualified signature. Protected delivery to a verified requester, DSAR status, an anonymous channel, and provable deletion need separate confirmed processes.

Visual review

Capture the portal only with a synthetic client perimeter. Never publish real invitations, tokens, addresses, names, documents, or links. A screenshot shows one reviewed visible contour; it does not replace an ACL test, role check, or configuration review. Arabic RTL frames remain behind the private evidence gate until separately accepted.

Related pages

• Operational compliance workflows
• Data-subject request workflow
• Client portal
• Extranet for staff
• Access and roles
• Documents