Pending evidence
Signed order form
Customer-specific commercial terms, support route, retention overrides, and pilot scope.
Owner: Commercial/legal owner
Procurement
Procurement vendor pack for ECCTA defence-file pilots.
Use this page to brief procurement, security, legal, and finance before a 90-day ECCTA Defence File Pilot. It aggregates product baseline facts and keeps missing customer-specific evidence visibly pending.
Vendor baseline
- Product category
- ECCTA defence-file evidence operating layer
- Pilot package
- GBP 2,500 setup + GBP 950/month for 90 days
- Self-serve checkout
- None; qualified pilot request only
- Legal boundary
- Evidence operations, not legal advice or certification
Architecture
A pilot architecture summary for procurement review.
Application
Next.js web app with public buyer pages, authenticated workspace routes, route handlers, and server-side product events.
Data layer
Deterministic local runtime by default; configured pilots can use Postgres, private object storage, and worker jobs.
Evidence model
Source metadata, review decisions, attestations, audit events, and board-pack export metadata are kept separate from legal conclusions.
Data flow
From source file to export evidence.
This is the product data-flow summary for procurement review. It describes local-ready product behavior and deployment checks, not a signed customer architecture schedule.
- 01
Intake
Browser upload slots create tenant-scoped source metadata before extraction.
- 02
Storage
Postgres tracks workspace records and evidence-file metadata; private object storage holds source objects.
- 03
Workers
Durable jobs process documents, recalculate alerts, send reminders, generate board packs, and deliver queued email.
- 04
Review
Named reviewers approve, reject, or request replacement evidence before board-pack gates can clear.
- 05
Export
Board-pack and CSV exports preserve hashes, source registers, blockers, and audit-download evidence.
Procurement sections
Baseline answers, linked to the public trust pages.
These summaries are not signed terms. They point reviewers toward the current public baseline while keeping customer-specific items out of public copy.
Vendor identity
DefenceFile is positioned as an ECCTA failure-to-prevent-fraud evidence operating layer for qualified pilot review, not as a self-serve checkout product.
The public product boundary is unchanged: DefenceFile organises evidence for legal and compliance review, but does not provide legal advice, create privilege, decide scope, decide whether procedures are reasonable, or guarantee that a statutory defence will succeed.
Architecture summary
The application is a Next.js web app with tenant-scoped workspace records, optional Postgres persistence, optional S3-compatible evidence storage, Resend-compatible transactional email, and worker jobs for operational workflows.
Local demo mode can run without configured external providers; production pilot use should name actual providers, regions, support contacts, and transfer posture in signed terms.
Data-flow summary
Buyer source files move from upload slots into tenant-scoped object keys, source-file metadata, scan/extraction state, redacted evidence text, human review, board-pack export records, and audit rows.
Board-pack artifacts can be written to tenant-scoped object storage with metadata persisted in the export repository; if artifact storage is not configured, Postgres exports still return controlled metadata rather than pretending the artifact exists.
Security controls
Current public security copy covers tenant and token boundaries, same-origin mutation protection, hashed public tokens, browser security headers, formula-safe audit exports, and deployment readiness checks.
These controls are product controls. They are not SOC 2, ISO 27001, Cyber Essentials, legal-compliance, or production-customer certification claims unless a signed customer artifact supplies that evidence.
Data residency and retention
Public retention defaults include pilot source evidence for the agreed pilot term plus 30 days, email delivery metadata for 90 days, stale attempt cleanup after the configured retention period, and backup defaults of 35 daily plus 6 monthly copies unless signed terms say otherwise.
Customer-specific deletion, return, legal hold, DPIA, appropriate-policy-document, and support timelines should be agreed before production onboarding.
Worker and backup posture
Postgres pilot readiness checks cover document, alert, attestation-reminder, board-pack, and email workers. Worker commands need tenant and organisation selectors before pilot launch.
Backups cover Postgres tenant/workspace data, jobs, audit events, email outbox, evidence-file metadata, and private evidence objects. The runbook target is daily backups, 35 daily plus 6 monthly retained copies, and a monthly restore test into a disposable environment.
Export and audit evidence model
Review decisions record signed-in reviewer identity, timestamp, notes, status, and immutable audit events. Review and audit exports are formula-safe CSVs for adviser sharing.
Board-pack export records keep status, generated date, source count, blocker reasons, SHA-256, manifest consistency, artifact availability, pack approval state, and audited download/share events.
Subprocessors and DPA
Current public copy names provider categories rather than a final customer schedule: S3-compatible object storage, PostgreSQL database provider, Resend-compatible transactional email, and deployment infrastructure.
The signed DPA and order form should name actual subprocessors, regions, transfer mechanisms, retention, deletion, support, and legal-hold terms for the customer deployment.
Operations posture
Worker, backup, and restore posture.
These are readiness controls from the README and disaster recovery runbook. Customer-specific recovery commitments belong in signed terms.
Worker readiness
/api/health reports document-worker, alert-worker, attestation-reminder-worker, board-pack-worker, and email-worker readiness in Postgres mode.
Backup scope
Backups cover Postgres tenant/workspace data, jobs, audit events, email outbox, evidence-file metadata, and private evidence objects.
Backup cadence
Run application-level backups at least daily, retain 35 daily plus 6 monthly copies, copy backups outside the primary deployment account, and test restore monthly.
Recovery target
The runbook target is 24-hour RPO and 4-hour RTO for restore into an already-provisioned environment, unless customer terms require stronger targets.
Export and audit model
Evidence outputs procurement can inspect.
- Evidence model: Review digest CSV includes evidence id, title, source type, status, reviewer decision, reviewer identity, timestamp, replacement lineage, rework state, and notes.
- Evidence model: Audit CSV includes successful and failed known-user login events, logout, export, download, review, scope, upload, document-processing, and attestation workflow events.
- Evidence model: Board-pack export detail shows generated date, source count, blocker reasons, full SHA-256, manifest consistency, artifact availability, pack approval state, and controlled download boundary.
- Evidence model: Adviser share links are token-scoped, noindex/nofollow, persisted as SHA-256 token hashes, revocable, and represented in audit rows without raw bearer tokens.
Pending evidence
Missing proof stays visibly pending.
Do not substitute local demo evidence for signed customer, deployment, field, or reference evidence.
Pending evidence
Signed DPA and subprocessor schedule
Named providers, regions, transfer posture, deletion/return terms, legal hold, and support contacts.
Owner: Commercial/legal owner
Pending evidence
Production health and field metrics
Deployed HTTPS health evidence, field Core Web Vitals source, and configured email smoke reference.
Owner: Deployment owner
Pending evidence
Customer UAT or reference evidence
Named customer acceptance evidence or approved reference proof before any public customer-proof claim.
Owner: Customer/commercial owner
Pointers
Where procurement should go next.
Pilot walkthrough
First-session agenda, demo-labelled screenshots, buyer inputs, and 90-day outputs.
Security posture
Tenant boundaries, token handling, headers, readiness checks, and audit-export controls.
Security questionnaire
Standard answers for authentication, RLS, token handling, backups, retention, incident posture, and security.txt.
Privacy summary
Controller responsibilities, data categories, lawful-basis notes, retention, and rights handling.
DPA summary
Processing roles, security measures, subprocessors, retention, deletion, and signed-document boundaries.
Support and contact
Use the pilot request route for procurement questions until signed customer support terms name a route.
Source notes
Sourced from committed product runbooks.
This procurement pack synthesises existing product documentation. It does not add new certification, production, customer, or legal claims.
README.md
Security/privacy, retention defaults, worker readiness, board-pack artifact storage, review/export, audit, and backup sections.
docs/disaster-recovery.md
Backup scope, cadence, restore preconditions, restore command, post-restore checks, RPO, and RTO.
docs/security-privacy.md
Tenant-scoped object storage, RLS, token handling, retention, evidence export boundaries, and incident posture.