Trust & data handling
Data & Security
DNA_CHECKS is being designed around minimal retention, isolated processing and a clear DNA-file lifecycle.
Live DNA uploads are not enabled yet. This page describes the security model that must be verified before the public beta accepts real genetic data.
Security model
Keep the sensitive part small
The public website does not need to hold a permanent copy of a user's genome. The beta architecture separates the public interface from the temporary DNA-processing workflow.
Core principle
Process what is needed, retain as little as possible.
Raw DNA is intended to exist only for the period needed to validate the file, run the requested analysis and complete the report job.
DNA lifecycle
From upload to deletion
The intended beta workflow gives the raw file a defined lifecycle rather than treating it as a permanent user asset.
Basic checks are performed before a processing job is accepted.
The raw file is transmitted over an encrypted connection to temporary processing storage.
Each report job uses its own working directory and job identifier.
The existing DNA_CHECKS engine generates the requested report.
The raw DNA file and temporary working copy are removed after successful processing.
Storage lifecycle rules provide a second deletion path if immediate cleanup fails.
Technical controls
Controls required before launch
These are engineering requirements for the live beta rather than claims about infrastructure that is not connected yet.
Encrypted transportDNA and reports must not travel over unencrypted connections.+
The upload, worker retrieval and report-return paths will use encrypted transport. Sensitive files should not be transmitted through ordinary email.
Restricted temporary storageOnly the processing components that need a file should be able to access it.+
Temporary upload and report-delivery storage will use restricted credentials and limited-purpose access rather than broad project-wide permissions.
Outbound-only local workerThe processing computer should not be exposed as a public inbound service.+
The intended worker polls outward for authorised jobs, retrieves one job, runs the existing DNA_CHECKS pipeline and returns the generated report. No public tunnel into the local processing machine is required.
No genetic content in logsOperational logs should contain job metadata, not genotypes or findings.+
Logs should use job IDs, timestamps, statuses and error categories. Raw genotype lines, clinical findings and report contents should not be written into ordinary operational logs.
No backup or sync of the processing directoryTemporary genetic files should not silently persist elsewhere.+
The worker's temporary DNA-processing directory should be excluded from cloud sync and routine backup systems so deletion is meaningful.
Reports & metadata
The report is sensitive too
Deleting the raw input does not make the resulting report non-sensitive. A report can contain clinically relevant, ancestry-related and other personal genetic information.
Temporary secure delivery rather than indefinite public hosting.
Used for report-ready and essential job communication; the report itself should not be sent as an ordinary email attachment.
Limited to what is needed for payment, processing, support, security and auditability.
A clear privacy request and complaint channel must be available before live processing begins.
Launch gate
Security work that must be completed before real uploads
Genetic data receives enhanced protection under UK data protection law, so the live service should not be enabled just because the front end is ready.
DNA_CHECKS should complete and document a data protection impact assessment, verify the final controller/contact details, confirm processor contracts and data locations, test deletion and failure handling, and run cross-user isolation tests.