For clients

If your assessment firm uses RedScribe, you may have been given a client portal account. This page explains exactly what you can see and do with it.

Logging in

Client accounts log in through the same page as firm staff, /login/, using your own username and password, or your firm’s configured OAuth provider if they have enabled one. TOTP MFA enrollment happens the same way it does for staff accounts. See Logging in & MFA.

New client accounts are set up through a single-use, twenty four hour emailed link that lets you choose your own password. Nobody at the firm ever sets or sees it, since the account is created with an unusable password on the server side until you complete that setup step yourself.

The dashboard

/portal/ is your landing page after login. It lists every engagement currently visible to you, and shows three summary tiles above the list: total engagement count, total published findings across all of them, and a count of Critical or High severity findings that still need attention (shown in red once that count is above zero). Each engagement row shows its status, reference number, test type, start and end dates, and a row of severity chips summarizing its published findings. If nothing is visible yet, you will simply see “Nothing to show yet” rather than an error.

What determines whether you can see an engagement at all

An engagement only shows up for you if every one of these is true at the same time:

• It belongs to your client company (engagement.client == your client).
• Your client company itself is marked active. A deactivated client company hides every one of its engagements from the portal immediately, even though the engagements themselves are untouched.
• The engagement is not archived.
• The engagement has been explicitly released to the client portal by staff (client_release_approved). Being a client on a project does not mean anything about it is visible the moment work starts. See Engagements for the staff side of releasing and revoking this.

If you try to open an engagement or finding URL directly that fails any of these checks, or one that belongs to a different client company entirely, you get a permission error rather than being redirected somewhere else or shown a blank page. There is no way to enumerate or discover engagements you are not supposed to see by guessing URLs.

What you can see within a released engagement

Only findings that have reached QA Approved in the review workflow are shown, regardless of the engagement’s own release status. A finding still sitting in Draft, Reviewed, or Changes Requested never appears, even after its engagement has been released. This is enforced at the query level (the portal view only ever fetches findings with workflow_status=QA_APPROVED and archived=False), not by hiding a already-fetched row in the template, so there is no draft content that “leaks” through an API response or a cached page.

Within a finding you are allowed to see, only the content sections marked Portal visible in Finding structure are rendered, in that screen’s configured order. A section that exists but is not portal visible (remediation testing notes, for example, which default to staff-only) is simply absent from the page you see, not shown empty or redacted.

Note

Every section value you see is decrypted specifically for this request from the engagement’s own encrypted data, the same per-engagement encryption used everywhere else in RedScribe. See Encryption model.

Nothing else in the portal is actionable besides your own password and MFA settings. There is no way to edit, comment on, or export findings from the client side.

View tracking

The moment you open a finding you are allowed to see, RedScribe records that you viewed it. Technically this is a single row per finding per client user (finding, client_user is a unique pair), so repeat views of the same finding update that same row’s “last viewed” timestamp rather than creating a new row every time. The very first view also sets a “first viewed” timestamp that never changes again after that.

On that finding’s own page, staff can see whether and when you looked at it. This is purely informational. It never changes what you can see or do, and it is the only piece of your portal activity that gets surfaced back to staff outside of ordinary audit logging, which separately records every request your account makes like it does for every other account on the instance.