What a counterparty sees

A counterparty link grants the recipient one-time access to a single declaration form for a single named individual at a single named firm. It grants no access to the firm’s dashboard, register, other declarations, gap-analysis results, or any other counterparty’s submission.

• The name of the firm that issued the declaration (sender).
• The name of the individual the declaration concerns (in most cases, themselves).
• The declaration text — a plain-English statement of what they are confirming, with a link to the underlying Section 250 statutory text.
• The submission form: confirm / decline / request clarification, plus a signature field and a free-text comment box.
• A submission confirmation page with the timestamp and a downloadable receipt PDF.

• The firm’s dashboard, gap-analysis results, or classification reasoning for any individual including themselves.
• Any other declaration sent by the firm — their own or any other counterparty’s.
• Other counterparties’ identities, status, or submission timestamps.
• The firm’s SM&CR register, FCA-register import, or any uploaded data.
• The board summary, CEO memo, board resolution, board slides, weekly briefing, maturity score, or any AI-generated content.
• Any other firm’s data. Tenant isolation is enforced at the database layer via PostgreSQL Row-Level Security — a counterparty link is scoped to one firm’s firm_id only.

A counterparty link is a URL containing a single-use, unguessable token generated with crypto.randomUUID(). The token is stored server-side on the counterparty request row; when the link is opened, CoverProof looks up that row, checks its expiry and cancellation state, then scopes every follow-on query to the linked firm.

• Single-use. The token id is recorded in the consumed_tokenstable on first use. A replay attempt (same token, second request after submission) returns a generic “already submitted” page with no firm data.
• Time-bounded. Every link has an expiry — the default declaration link expires 30 days from send. An expired link returns a generic “link expired” page.
• Forgery-resistant. The token is not a client-supplied payload and it does not encode firm or recipient data. A counterparty would need to guess an existing 128-bit UUID token that is still live, unsubmitted, and unexpired.
• Tenant-scoped. Every server query made on behalf of a counterparty link runs inside a tenant context set from the token’s firm_id. Row-Level Security policies enforce that no row outside that firm_id can be read.
• No session. The link does not create a login session. The counterparty cannot navigate to /dashboard or any other firm-facing route.

A counterparty could forward their link to a colleague before submitting. We do not treat this as a confidentiality breach because the link only grants access to a declaration form for that specific individual at that specific firm — both names already known to the original recipient.

The integrity guarantee is that whoever submits the form is identified by the submission itself (signature field, free-text confirmation, IP address logged server-side, submission timestamp). A forwarded-and-submitted-by-someone-else case is detectable in the audit trail and is the responsibility of the recipient to control.

Every counterparty interaction is recorded server-side for inclusion in the firm’s board evidence pack:

• Email send: timestamp, delivery confirmation.
• Link open: first-open timestamp, originating IP.
• Submission: timestamp, IP address, signature, comment text.
• Expiry or non-response: a row in the audit log for each automated reminder sent.

• Security controls — encryption, auth, tenant isolation.
• Methodology — how classifications and evidence packs are produced.
• Trust Centre overview