Security & confidentiality

Access follows the sourcing relationship.

Each person sees only what their role and stage allow. These rules are enforced on the server, not just hidden in the interface.

PartyBefore acceptanceDuring responseAfter submission
Matched providerSees briefDoesn’t see identitySees accepted buyer details
BuyerSees own draftSees response statusSees submitted responses
ConsultantSees named scopeSees submitted responsesDoesn’t see unrelated work
Other providersDoesn’t see briefDoesn’t see responsesDoesn’t see messages

Illustrative example.

How it works

Before a provider accepts

Only eligible RFPs

A provider must be approved, assigned to a matching category and not blocked from that RFP.

Buyer identity withheld

The provider receives a redacted RFP without the buyer company or contact details.

Identifying details removed

Providers receive a version of the brief with buyer-identifying and internal working details removed.

No attachments or links

Buyer files, links and live contact details stay locked until acceptance.

How it works

After a provider accepts

The accepted provider can read the buyer's current company and contact block, RFP attachments and links, create its response, and use the private RFP message thread. A declined response is treated as not accepted and does not retain buyer identity access.

How it works

Response confidentiality

PartyWhat they can read
Responding providerIts own draft, submitted response, evidence and buyer conversation
BuyerSubmitted responses to its own RFP; never the provider's unfinished draft
Authorised consultantSubmitted responses only where an accepted client grant covers the RFP
Other providersNo competing response, contact information or message thread
AdministratorsNo participant message threads; those remain isolated to the two sides

How it works

Consultant access stays within scope

Email-bound invitations

The invitation is accepted by the intended email account and expires if unused.

Named scope

Organisation, project and RFP targets are selected before sending and shown in the invitation.

Client ownership

A consultant-created RFP remains owned by the client organisation.

Revocation

Removing access closes the consultant's view of that scope without changing the client record.

How it works

Files and links follow the same rules

RFP and response attachments are private. Downloads use time-limited, permission-checked links. Buyer draft documents remain in an owner-controlled private area.

How it works

Account and role separation

Roles stay distinct

Buyer, provider and consultant workspaces keep their own access context even when one account holds several roles.

Administrator access cannot be self-assigned

Administrative privileges are restricted independently of ordinary account signup and role selection.

No public contact directory

Company names and contacts are never exposed through search or browsing. They appear only after the relevant relationship is confirmed.

How it works

Messages stay between participants

Each RFP thread is readable only by its buyer side and responding provider. Other providers and administrators cannot read participant messages.

How it works

Policies

See the controls in the context of the workflow