Shared security & privacy ops
for Vault Hire and every tenant.

Three operating principles

• Tenant-only by default. Every dashboard, signal, alert, and audit record is partitioned by tenant_id. A client never sees anyone else's data and never sees Vault Hire's internal controls.
• Co-owned, not delegated. Vault Hire monitors every tenant; tenants monitor themselves. Both can act. Both audit-log their actions. We share the room — we don't hand over the keys.
• Proprietary controls stay with us. The Vault Hire infosec layer (WAF rules, model-version inference register, employee endpoint posture, vendor-management evidence) is visible only to Vault Hire's security and infosec roles, not to any client. Tenants see the output of these controls (e.g. "no anomalies in the last 24h"), never their content.

Layer 1 — Soft warning at registration

The Register page now runs a POST /api/duplicate-check on blur of name/email/DOB. Three signal strengths:

• Blocking — exact email match. We refuse to create a second account; the candidate is sent to sign in.
• Blocking — name + DOB hash collision. Same person, different email — most likely fraud or an honest user who forgot their old credentials.
• Warning — name-only match. Suggests there are other vaults under the same name; informational only (high false-positive rate).

Layer 2 — Hard block at strong-identifier upload

POST /api/vault/identity-hash takes a passport / national-ID / NI / SSN value, hashes it with a per-deployment salt (SHA-256), and rejects the upload with HTTP 409 if any other active candidate already has the same hash. Every blocked attempt creates a duplicate_vault_incidents row visible only to Vault Hire's security team, audit-logged on both candidates' accounts, and notifies all owners in-app.

What this prevents: a fraudster cannot run two vaults under the same identity to share verified references across personas. A confused candidate cannot accidentally fragment their hiring history across multiple accounts.

What we never store: the raw passport / NI / SSN value — only the salted hash. Customers' regulators see one-way hashes only.

What it surfaces

• Live count of concerning events: failed logins, MFA challenges, unusual share-link issuance, off-hours candidate exports, geographic anomalies on recruiter logins.
• WebAuthn / passkey adoption rate per tenant — a leading indicator for phishing resistance.
• Token health: how many vault access links are live, average expiry, revoke-rate.
• Inbound vault-access requests outside of business hours.
• Suspicious patterns flagged by an AI risk model (e.g. a single recruiter requesting access from 80+ candidates in an hour).

What action the tenant can take

• Revoke a session, force-MFA, suspend a user, force-rotate passkeys — all within their tenant only.
• Export the dashboard as a PDF for their own audit reviews.
• Open a ticket directly to Vault Hire infosec via the collaboration space (step 4).

What's in scope

• Incident threads with status (Open → Triaging → Resolved → Lessons Learned).
• Tagged event references — every comment can pin to an event from the dashboard.
• Mandatory dual sign-off on incidents involving candidate data (UK GDPR Art. 33 / 72-hour breach notification clock).
• Lessons-learned cross-publishing: with both sides' approval, an anonymised incident summary goes to the central Lessons dashboard (see step 7).

What it surfaces

• Live DSAR (Article 15) queue, with the candidates' own self-service downloads visible as already-fulfilled.
• Pending rectification (Article 16) and restriction (Article 18) requests.
• Cross-border transfer log — every export of personal data across jurisdictions, with the SCC / adequacy basis recorded.
• AI Act Article 12 inference register filtered to this tenant — every AI call made on behalf of this client's candidates.
• Retention clock: candidates whose data is approaching the tenant's configured retention horizon and will be auto-deleted unless extended.

Why quarantine, not auto-process

• An RTBF request can collide with the tenant's regulatory hold (FCA SYSC 9, six-year reference horizon). The platform must mediate, not auto-honour.
• Vault deletion may need to preserve verified references for other candidates (Sarah's reference of Bob still has value to Bob even if Sarah deletes her vault).
• The DPO needs visibility on cross-tenant implications before acting.

How the quarantine flow works

1. Candidate submits RTBF or vault-deletion → request enters quarantine with a 30-day cool-off (configurable).
2. Affected tenants (anyone who's ever held a share) are notified — they can object with a regulatory basis.
3. Vault Hire's DPO + tenant's DPO must both sign off (or one over-ride with documented basis).
4. On execution, the platform produces a tamper-evident certificate of erasure hash-chained into the candidate's audit log (kept after the vault itself is gone).

What only Vault Hire sees

• Cross-tenant anomaly detection: e.g. the same external IP attempting recruiter-style behaviour across multiple tenants.
• Aggregate adoption of phishing-resistant auth, vault-access-request approval rate, retention clock distribution.
• Internal infosec controls: employee endpoint posture, WAF rule status, vendor risk register, model-version inference register.
• Anonymised Lessons-Learned dashboard (per the Implementation journey).

Tenants never see this dashboard — they're confident their internal posture isn't being benchmarked against their competitors without their explicit consent.

Shipping order

1. Now — duplicate-vault detection (live in preview).
2. Q3 2026 — tenant security dashboard (read-only first; revoke actions in Q3 wave 2).
3. Q3 2026 — privacy dashboard + RTBF quarantine workflow (the legal/regulatory piece must precede the security action piece because deletion is the riskiest operation).
4. Q4 2026 — security & privacy collaboration spaces with incident threading and dual sign-off.
5. Q1 2027 — Vault Hire cross-tenant overlay (depends on the multi-tenant epic).

Dependencies

• Multi-tenant epic (P1 in the existing roadmap) — must land before any cross-tenant view.
• WORM archive integration — for the certificate-of-erasure flow.
• Stripe metering — privacy and security teams are billed differently from recruiter seats.

Five additions worth considering

• Candidate-side trust score. A vault-level "fraud risk" hidden from the candidate, visible to recruiters & Vault Hire security. Calibrated on signals like multi-IP logins, document re-uploads of differing hashes, share-link issuance velocity, and vault-completion-cadence anomalies.
• Adverse-event sharing across tenants. If a candidate is flagged for fraud at one bank (with that bank's explicit consent), the next bank's compliance officer is informed when the same candidate shares with them — without revealing which bank flagged or why. The hashed record is what travels.
• Honeypot share links. Tenants can issue look-real-but-decoy access tokens. Any open = automatic incident (because no legitimate process should ever hit a honeypot).
• Behavioural anomaly model on recruiter usage. A recruiter who's been requesting ≈ 5 vaults/week for a year and suddenly requests 80 in an hour is the most common insider-data-theft signal in this industry. Detect & alert.
• Public transparency report. Annually, Vault Hire publishes an aggregate transparency report: total DSARs honoured, time-to-honour, average pack-completion time, total RTBF processed, total breaches. Helps the platform sell to regulated industries on its own track record.