Data Handling
This page details how FileSafety handles your files from upload to deletion, what data is stored, and the encryption methods used at every stage.
File lifecycle
Section titled “File lifecycle”Every file uploaded to FileSafety follows a strict lifecycle with immediate deletion after scanning:
T+0s File uploaded to encrypted file storage (AES-256)T+1-5s File queued for scanningT+5-20s Malware detection and content analysis runT+15-30s Scan results written to the databaseT+15-30s Webhook delivered to your endpointT+15-30s File immediately deleted from storageT+24h Failsafe lifecycle policy removes any remaining filesTimeline details
Section titled “Timeline details”| Time | Event | Data state |
|---|---|---|
| Upload | File stored in encrypted file storage | Encrypted at rest (AES-256), encrypted in transit (TLS 1.3) |
| +1-5 seconds | Scan message queued | File remains in encrypted storage |
| +5-20 seconds | Malware detection and content analysis run | File processed in isolated compute |
| +15-30 seconds | Scan complete | Results stored in database; webhook delivered; file deleted |
| +24 hours | Failsafe | S3 lifecycle policy as safety net for any files not already deleted |
Files are deleted immediately after scanning completes. The 24-hour S3 lifecycle policy serves as a failsafe to guarantee no files persist beyond that window.
Encryption
Section titled “Encryption”At rest
Section titled “At rest”All files are encrypted at rest using AES-256 server-side encryption. Encryption is applied automatically when the file is written to storage — there is no unencrypted window.
| Data | Encryption |
|---|---|
| Uploaded files | AES-256 |
| Scan results | AES-256 |
In transit
Section titled “In transit”All data in transit is encrypted with TLS 1.3:
| Path | Protocol |
|---|---|
| Client to API endpoint | TLS 1.3 |
| Client to presigned URL upload | TLS 1.3 |
| Internal service communication | TLS via private endpoints |
| Webhook delivery to your endpoint | HTTPS (TLS) |
Older TLS versions (1.0, 1.1, 1.2) are not accepted for API requests.
What data is stored
Section titled “What data is stored”During the scan (deleted immediately after)
Section titled “During the scan (deleted immediately after)”| Data | Storage | Retention |
|---|---|---|
| File binary content | Encrypted file storage | Deleted immediately after scan (24h failsafe) |
After the scan (retained for 30 days)
Section titled “After the scan (retained for 30 days)”| Data | Storage | Retention |
|---|---|---|
| Scan ID | Database | 30 days |
| Verdict (clean/infected/nsfw/mixed/failed) | Database | 30 days |
| Virus scan result (engine, clean flag, signature) | Database | 30 days |
| NSFW scan result (clean flag, categories, confidence) | Database | 30 days |
| File cryptographic hash | Database | 30 days |
| Scan completion timestamp | Database | 30 days |
| User-provided metadata | Database | 30 days |
What is NOT stored
Section titled “What is NOT stored”| Data | Stored? |
|---|---|
| File content (after scan) | No — deleted immediately after scanning |
| File name | No |
| IP addresses of uploaders | No |
| File content in application logs | No |
| Raw NSFW analysis output | No — only the verdict, categories, and confidence are stored |
No content logging
Section titled “No content logging”FileSafety does not log file content at any stage of processing. Application logs contain:
- Scan IDs
- Status transitions
- Error messages (without file content)
- Timing information
File bytes are never written to stdout or any logging pipeline.
Metadata handling
Section titled “Metadata handling”The metadata field you provide when submitting a scan is stored alongside the scan results in the database. This data:
- Is encrypted at rest
- Is returned in scan poll responses and webhook payloads
- Is retained for 30 days with the scan record
- Is limited to 4 KB maximum
- Is under your control — you decide what to include
Do not include sensitive information (passwords, tokens, PII) in the metadata field. While it is encrypted at rest, it is returned in API responses and webhook payloads.
Presigned URL security
Section titled “Presigned URL security”When using the presigned URL flow:
- The presigned URL is scoped to a single object in encrypted file storage
- The URL expires after 15 minutes
- Only the
PUTmethod is allowed — the URL cannot be used to read or list other objects - The URL is signed with temporary credentials, not long-lived keys
API key storage
Section titled “API key storage”API keys are hashed using a cryptographic hash before being stored for request authentication. The plaintext key is:
- Generated server-side and returned to you once at creation time
- Temporarily stored only for one-time reveal flows (then cleared)
- Not recoverable — if lost, you must regenerate
Data deletion
Section titled “Data deletion”Automatic (file content)
Section titled “Automatic (file content)”Files are deleted immediately after scanning completes. A 24-hour S3 lifecycle policy remains as a failsafe to ensure no files persist beyond that window. This is automatic and cannot be extended or shortened.
On request
Section titled “On request”Contact support to request deletion of specific scan records. This removes the verdict, hash, and metadata associated with a scan.
On account deletion
Section titled “On account deletion”When you delete your account, a 30-day grace period begins during which you can reactivate your account. After the grace period:
- All scan records are permanently removed from the database
- Any remaining files are deleted from storage
- Your API key hash is removed
- Billing data is retained by Stripe per their data retention policies
See also
Section titled “See also”- Security Overview — Architecture and network isolation
- Compliance — GDPR, SOC 2, and DPA information