What Your Clients Actually See in the Portal

A client login is not a smaller version of your portal. It is a different portal, and what it can read is decided by the row-level security policies in your database rather than by hiding buttons. This guide is what a client user sees, so you can answer that question on a call without guessing.

Their engagements

A client sees every engagement you run for their organisation, whatever its status: booked, being tested, in QA or delivered, with its dates, its status and its lead tester. The findings and the report come later, as you release them.

When an engagement needs credentials or authorisation details before testing, their dashboard says so, with how soon testing begins, a Submit credentials button and I sent them another way. What they submit goes to your database through a form on the engagement, for your testers to collect.

Findings

A client reads a finding only once it is switched to visible: the Client Visible switch on each finding, or Show to client for a selection. Until then your database does not hand it to their login at all, so a finding a tester is still writing never reaches them. Delivering the report releases the report and its written sections, your internal notes excepted; each finding’s visibility stays your call.

Until a finding is shown to them, its screenshots carry a Fig mark rather than a figure number on your pages too, so writing or adding a finding never moves the numbers the client already reads. Once it is shown, it takes its place in the report’s order.

Anything they have not opened yet is marked new. They can select findings and mark them read or unread, and request a retest on anything eligible. A retest request is a request: it lands with you and changes nothing about the finding until a tester acts on it.

Marking read is per person, not per company. One client user clearing their list does not clear a colleague’s.

Documents

The reports you have delivered, as downloads, and the letter of attestation where Settings, Attestation sets its visibility to Enabled (Internal Only, the default, keeps it to your team). Nothing appears here automatically; a document reaches a client when you deliver it.

Checklists you share

A checklist or runbook marked Visible to clients shows on the phases it is attached to, with its progress and each item’s tick, which the client can read but not change. Anything not marked that way stays internal. Checklists and runbooks covers the switch.

What they cannot see

This is the part worth being precise about, because it is what a security questionnaire asks.

• Other clients. Every read is filtered by the client the user belongs to, in policies on your database, not in the application.
• Findings not switched to visible, including anything a tester is still drafting.
• Your internal comments, the QA review, checklists not shared with them, and the Library.
• Your other users beyond the lead tester named on their own engagement.
• Anything about your firm’s own account and subscription.

Giving somebody access

Clients, then the client, then Add User under Portal Users, with their name and email address. They receive an invitation, sign in and enrol a second factor under the same policy as everybody else. You can change that address later, and both the old and the new mailbox are told when you do, because re-pointing a sign-in address is the shape of an account takeover and the old address is the only one that would notice.

A client user is never offered as a lead tester and does not count against your internal user limit. Should a client login later be made a member of staff, it takes one of your plan’s places like any colleague, and your database refuses the change if the plan has none left.

The client portal is the delivery end of penetration testing as a service, under your own brand; Security explains the policies that keep one client’s data from another.