Security questionnaire answers for ECCTA pilot review.

Configured pilot workspaces use signed `defencefile_session` cookies for authenticated routes. The cookie is HttpOnly, SameSite=Lax, path-scoped to `/`, and forced Secure when Postgres pilot persistence is configured.

Authenticated API contexts carry tenant, organisation, user, and role metadata. Mutating browser requests reject cross-origin submissions before workspace mutations are accepted.

Production pilot readiness requires generated session secrets and named pilot users with allowed roles; short or placeholder secrets keep `/api/health` from reporting ready.

The product is designed to keep original source files in private tenant-scoped object storage while the application database stores metadata, processing state, hashes, and redacted extracted text.

Postgres pilot readiness requires S3-compatible evidence storage configuration before source evidence is accepted for a configured deployment.

Provider, region, transfer, and storage-encryption details are customer-specific deployment evidence and should be named in signed DPA or order-form artifacts.

Tenant-owned Postgres tables include `tenant_id`, enable and force row level security, and use tenant-isolation policies tied to the current tenant context.

Repository adapters set tenant context before tenant-owned reads and mutations. The security gate checks migrations for missing forced row-level-security coverage.

This is implementation evidence, not customer acceptance evidence; a deployed pilot still needs its database migration and health proof attached.

Zero-login attestation links and adviser-share links are scoped, expiring, and stored as HMAC or SHA-256 token hashes rather than raw bearer tokens.

Repeated invalid public-token attempts are rate-limited by token and source buckets; Postgres attempt rows store purpose, token hash, source hash, attempts, and lockout timestamps.

Audit CSV and telemetry paths are designed to avoid raw public bearer tokens and raw source addresses.

The local backup runbook covers Postgres dump creation, evidence-object sync, restore confirmation, object-before-Postgres restore ordering, and manifest output.

Postgres readiness requires backup directory, evidence bucket, and verified backup tooling before relying on pilot backup and restore runbooks.

Production backup restore success remains external field evidence; local command wiring does not prove cloud IAM, provider snapshots, restore latency, or customer acceptance.

Pilot defaults retain source evidence for the agreed pilot term plus 30 days, email delivery metadata for 90 days, stale attempt rows after `ATTEMPT_CLEANUP_RETENTION_DAYS`, and backups for 35 daily plus 6 monthly copies unless signed terms say otherwise.

Redacted evidence text, audit events, and export metadata follow workspace retention through the pilot term and any agreed legal hold.

Final deletion, return, legal-hold, DPIA, appropriate-policy-document, support, and subprocessor terms belong in signed customer documents.

The runbook lists containment, evidence preservation, secret rotation, tenant scoping, restore decision, and customer notification steps.

The public `/.well-known/security.txt` route points vulnerability reporters to the pilot request route and this questionnaire until a signed customer support route is agreed.

No public bounty, response-time service level, penetration-test report, or third-party certificate is claimed here.

Global headers include a content security policy with frame and object restrictions, frame denial, MIME sniffing protection, strict-origin referrers, HSTS, and a restrictive browser permissions policy.

The header configuration is covered by an automated test and by the `security:check` gate.