Trust & data handling
Data & Security
DNA_CHECKS is built around minimal retention, isolated processing and a defined lifecycle for uploaded DNA and generated reports.
The service is intentionally account-free for the beta and keeps the raw DNA file only for the processing workflow needed to generate the requested report.
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 retained only for the period needed to validate the file, run the requested analysis and complete the report job, with a storage-lifecycle fallback if immediate cleanup does not occur.
DNA lifecycle
From upload to deletion
The 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 uploaded over HTTPS to restricted temporary object storage.
Each report job uses its own job identifier and temporary local working directory.
An outbound-only local worker retrieves the authorised job and runs the DNA_CHECKS engine.
The raw upload and local working copy are removed after successful processing, and terminal processing failures also trigger raw-file cleanup.
The upload-storage lifecycle provides a second deletion path, with raw-upload objects configured to expire within one day.
Technical controls
Controls used by the beta architecture
The processing path is deliberately separated from the public website and uses limited-purpose credentials, temporary files and metadata-only operational logging.
Encrypted transportDNA and reports must not travel over unencrypted connections.+
The public website, API, upload path and report-delivery path use HTTPS. Raw DNA and generated reports 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 use restricted credentials and short-lived authorised access rather than public object URLs or broad project-wide permissions.
Outbound-only local workerThe processing computer should not be exposed as a public inbound service.+
The local worker polls outward for authorised jobs, retrieves one job, runs the DNA_CHECKS pipeline and returns the generated report. The processing computer is not exposed through a public inbound tunnel.
No genetic content in logsOperational logs should contain job metadata, not genotypes or findings.+
Operational logs use job IDs, timestamps, statuses and error categories. The worker is designed not to write genotype rows, report findings or report contents into ordinary logs.
No backup or sync of the processing directoryTemporary genetic files should not silently persist elsewhere.+
The temporary processing directory is intended to remain outside consumer cloud-sync workflows so deletion of working DNA copies is meaningful. Abandoned per-job folders are also removed when the worker starts.
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.
Delivered through a temporary report link rather than indefinite public hosting. The normal report-delivery window is approximately seven days, with storage fallback cleanup shortly afterwards.
Used for report-ready and essential job communication. Emails contain a delivery link rather than attaching the genetic report itself.
Limited to what is needed for payment, processing, support, security, delivery and auditability.
Questions about personal data, deletion or data-protection rights can be sent to [email protected].
Ongoing safeguards
Security is treated as an operational process
The controls above reduce exposure, but no online service can claim zero risk. DNA_CHECKS therefore keeps security, retention and cross-user isolation as explicit areas for testing and review.
The beta includes tested raw-file cleanup, isolated per-job processing, failure/refund handling, short-lived report delivery and metadata-only worker logging. Formal privacy and compliance documentation, processor review and cross-user QA remain part of the pre-launch compliance and QA gates.