Data Retention & Deletion Policy
SimpleSecurity is currently in pre-launch. The operating Swedish company (aktiebolag) is under registration — org.nr [ORG-NR] will be inserted here once registration completes.
1. Principles
SimpleSecurity applies the storage limitation principle under GDPR Article 5(1)(e): personal data is kept only for as long as necessary for the purposes for which it was collected. This policy sets out how long each category of data is retained, on what basis, and how it is deleted.
2. Retention Schedule
| Data category | Examples | Retention | Basis |
|---|---|---|---|
| Account & platform records | User accounts, CMDB asset inventory, monitoring configuration, policies and uploaded documents, compliance records, vendor records, open incidents, and other data entered into the platform. | For the life of the customer relationship; deleted on erasure request or self-service deletion. These are records rather than logs and are never deleted on a timer. | Contract performance; GDPR Art. 5(1)(e), Art. 17. |
| Uptime check history | Per-check status, response time and HTTP status code for each monitored host. | 30 days, auto-expiring via DynamoDB Time-To-Live (TTL). This one is fixed — uptime graphs are drawn over a 30-day span, so it cannot be shortened while uptime monitoring is on. Switching uptime monitoring off reduces it to 1 day. | Storage limitation; operational necessity. |
| Downtime & recovery events | A record of each outage and each recovery, with the alert recipients notified. | Between 90 and 365 days, auto-expiring via TTL. New organisations start at 90 days; you can raise it to 365 in Settings → Data retention. | Storage limitation; service-level accountability. |
| SSL and email-security check results | Certificate issuer/expiry and SPF, DKIM, DMARC and MX record state. | No history is kept. Each check overwrites the previous result, so only the current state exists at any time. | Storage limitation — data minimisation by design. |
| Notification & alert log | In-app notification and alert delivery records. | Between 30 and 90 days, auto-expiring via TTL. New organisations start at 30 days; you can raise it to 90 in Settings → Data retention. | Storage limitation; operational necessity. |
| Vulnerability scan history | Completed vulnerability scan results and findings history. | Between 90 and 365 days, auto-expiring via TTL. New organisations start at 90 days; you can raise it to 365 in Settings → Data retention. | Storage limitation; security trend analysis. |
| Resolved vulnerability findings | CVE findings that have been fixed, with severity and the dates first seen and resolved. | Between 90 and 365 days after resolution. New organisations start at 90 days; you can raise it to 365 in Settings → Data retention. Findings that are still open, accepted as risk, or marked false positive are your live register and never auto-expire. | Storage limitation; remediation accountability. |
| Asset change log | Audit trail of create/update/delete actions on assets, including before/after field values and the acting user. | Between 30 and 90 days, auto-expiring via TTL. New organisations start at 30 days; you can raise it to 90 in Settings → Data retention. | Legitimate interest — accountability and audit. |
| Impact & dependency snapshots | Daily snapshots of your asset dependency map's resilience score (single-point-of-failure analysis), used to draw the resilience trend. | Between 90 and 400 days, auto-expiring via TTL. New organisations start at 90 days; you can raise it to 400 in Settings → Data retention. | Legitimate interest — resilience trend analysis; storage limitation. |
| Auto-enrolment log | Record of which assets were automatically enrolled into which monitoring services, and why. | Between 7 and 90 days, auto-expiring via TTL. New organisations start at 7 days; you can raise it to 90 in Settings → Data retention. | Legitimate interest — accountability. |
| Resolved incidents | Incidents that have been marked resolved or closed. | Between 180 and 730 days, auto-expiring via TTL. New organisations start at 180 days; you can raise it to 730 in Settings → Data retention. Open incidents never expire. | Storage limitation; incident accountability. |
| Employee awareness records | Employee roster entries (name, work email, role) used for security-awareness training and policy acknowledgments. | Active employees are records and never expire on a timer. Records of offboarded employees auto-expire between 90 and 365 days after the employment end date. New organisations start at 90 days; you can raise it to 365 in Settings → Data retention. | Storage limitation; customer's legitimate interest as employer. |
| Training & acknowledgment evidence | Awareness-training completions and scores, and policy read-acknowledgment receipts. | Between 430 days and 3 years, auto-expiring via TTL. New organisations start at 430 days; you can raise it to 3 years in Settings → Data retention. It cannot go below 430 days — the compliance auto-assessment accepts campaigns up to about 425 days old (annual cadence plus a grace window), so evidence must be kept at least that long. | Storage limitation; compliance-evidence accountability (ISO 27001 A.6.3). |
| Deleted asset recovery window | Assets you have deleted, retained briefly so an accidental deletion can be undone. | Between 7 and 90 days, then permanently removed. New organisations start at 7 days; you can raise it to 90 in Settings → Data retention. | Legitimate interest — protecting you from accidental loss. |
| Application logs | AWS CloudWatch logs generated by normal platform operation. | 30 days. | Legitimate interest — debugging and security monitoring. |
| Infrastructure audit logs | AWS CloudTrail records of infrastructure and administrative API actions. | 90 days. | Legitimate interest — security and accountability. |
| Continuous backups | DynamoDB point-in-time recovery (PITR) — continuous, restorable to any second. | Rolling 35-day window. Deleted data ages out of this window within 35 days. | Resilience and disaster recovery. |
| Disaster-recovery snapshots | Encrypted whole-database snapshots held in a separate AWS Backup vault, taken weekly and monthly. | Weekly snapshots are kept 35 days. Monthly snapshots are kept 12 months, so that data loss discovered late — for example ransomware or silent corruption — can still be recovered from. Deleted data can therefore persist in a monthly snapshot for up to 12 months. Snapshots are never used to serve the product, only to restore it, and if we ever restore from one we re-apply every erasure request made in the meantime. | Resilience and disaster recovery; GDPR Art. 32(1)(c). |
| Billing records | Invoices, subscription/billing status records, held by our payment processor. | 7 years from the end of the calendar year in which the financial year ended — not from the invoice date, so in practice up to 8 years. | Swedish Bookkeeping Act (bokföringslagen 1999:1078). |
3. Retention Periods You Control
The periods marked configurable above are defaults, not fixed limits. An organization administrator can shorten any of them under User Management → Data Retention in the dashboard, without contacting us. Periods can only be shortened, never extended beyond our defaults.
Shortening a period applies to data you already hold, not only to data collected afterwards: a nightly job removes anything that falls outside your new window, normally within 24 hours of the change.
Some periods have a lower bound because a feature stops working below it — for example, uptime history shorter than 7 days cannot render the weekly availability graph. Where that applies, the dashboard shows the limit and the reason. If you do not want a service at all, you can switch it off entirely in the same screen, which stops the collection and releases the lower bound.
You can also switch off individual services (uptime monitoring, vulnerability scanning, incident register and others). A service that is switched off stops collecting data immediately, including on our scheduled background checks.
Backups are the practical floor. Data you delete — whether by shortening a retention period, deleting a record, or deleting your whole organization — is removed from our live systems immediately, but remains in encrypted backups until those backups rotate: within 35 days for point-in-time recovery and weekly snapshots, and up to 12 months for monthly disaster-recovery snapshots. A retention period shorter than 35 days therefore governs our live systems; it cannot remove data from backups any sooner. We keep the longer monthly snapshots deliberately, because data loss that is only discovered months later cannot be recovered from a short window. Backups are never used for any purpose other than restoring the service, and if we restore from one we re-apply every erasure request received since that snapshot was taken.
4. Information for Data Protection Officers
Legal basis. You are the controller and determine the legal basis for your own processing. For security monitoring the expected basis is legitimate interest under GDPR Art. 6(1)(f); Recital 49 expressly recognises network and information security as a legitimate interest of a controller.
Third-party data subjects. Some categories contain personal data about people who are not your users and have no SimpleSecurity account: asset and information owners you record, people who report incidents, and the source and destination IP addresses captured on an incident, which may belong to third parties or attackers. Your Art. 14 notice obligations for indirectly collected data may apply.
Free-text fields. Incident narratives, root-cause notes and asset notes are free text. Anything typed into them is stored and retained on that category's schedule, including any special-category data. Consider whether your incident process should constrain what is written there.
Time to complete erasure. Deleting an asset places it in a recovery window (up to 90 days, and 7 days unless you raise it) before permanent removal. It is then gone from live systems and from point-in-time recovery and weekly snapshots within 35 days, and from the last monthly disaster-recovery snapshot within 12 months. The longest path from deletion to complete irreversibility is therefore 455 days — a 90-day recovery window followed by a 365-day monthly snapshot tail. In practice most data is unrecoverable far sooner: the 455-day figure assumes you have raised the recovery window to its maximum and that the deletion happened immediately after a monthly snapshot was taken. Deleting your organization removes records immediately from live systems, with the same backup tail.
What "deleted" means. Rows are hard-deleted. We do not substitute anonymisation for deletion. Backups are encrypted, access-controlled to production standard, and used only for disaster recovery.
Sub-processors. AWS (hosting, eu-north-1 Stockholm), AWS SES (email delivery — note that alert emails quote hostnames and CVE identifiers), and Stripe (payments). See Sub-processors.
Legal hold. If you are required to preserve evidence, an organization admin can enable a legal hold under User Management → Data Retention → Custom. While it is active, all scheduled deletion for your organization is suspended.
Longer periods. Our defaults are maximums. If a regulatory obligation requires you to keep data for longer than a category allows, contact us — extended retention is available on the Aegis plan and is priced per organization.
5. Correspondence With Us
Support tickets and product feedback you send us contain your name, email address and message. These are our records of communicating with you — they are not data we process on your behalf as your processor, and they are therefore not deleted when you delete your organization.
Support tickets are retained for 180 days. Product feedback is retained while it remains relevant to the product. If you want this correspondence erased, email security@simplesecurity.se and we will action it as a data subject request.
6. Deletion on Termination
Organization admins can permanently delete the entire organization (all users, assets, monitors, incidents, policies incl. uploaded documents, vendor records, and settings) self-service from the dashboard, via the "Danger Zone" in User Management → Security, with typed confirmation.
Self-service deletion is the primary and immediate path — it takes effect right away and requires no contact with us. Only if no organization administrator can access the account (for example, lost credentials) is deletion carried out manually on written request to security@simplesecurity.se, actioned within 30 days.
Because SimpleSecurity keeps backups, data deleted from the live system is not necessarily removed from backups immediately. It ages out of the rolling 35-day point-in-time-recovery window and the weekly snapshots within 35 days, and out of the monthly disaster-recovery snapshots within 12 months. Monthly snapshots are retained deliberately, because data loss discovered months after the fact cannot be recovered from a short window; they are held encrypted in a separate vault, are never used to serve the product, and if a restore is ever performed we re-apply every erasure request received since that snapshot was taken. This is the standard treatment of backups under GDPR Art. 17 — erasure is applied to live systems immediately and to backups on their rotation cycle.
7. Data Subject Erasure Requests
If you are an individual whose personal data is processed by a SimpleSecurity customer (for example, an employee listed as an asset owner or contact), and you wish to exercise your erasure or other data subject rights, you can export your data and delete your own account self-service under Account Settings → Privacy & data if you have a platform login. Otherwise, please contact your organization's admin directly, as they control the data. You may also contact us at security@simplesecurity.se and we will route your request accordingly.