Data Retention & Privacy Reference
What data the Secuno platform collects, how it is secured, how long it is retained, and how to manage, export, and delete it.
This document is maintained in English. Dit document wordt in het Engels bijgehouden.
Data Collection Overview
Secuno collects security-relevant telemetry from enrolled Windows and Linux devices via the Secuno Agent. The fields below describe the Windows agent; the Linux agent collects the equivalent inventory. All collection is scoped to security configuration, compliance state, and vulnerability exposure. No personal files, browsing history, email, or communications content is ever collected.
Data Categories Collected
| Category | Examples | Purpose |
|---|---|---|
| Device identity | Hostname, IP address, MAC address, hardware serial, OS version | Asset inventory and device identification |
| Security configuration | AV state, BitLocker status, firewall profiles, Defender exclusions, Defender sub-protection states (realtime, behaviour monitoring, IOAV, script scan, archive scan, cloud protection, network IPS, cloud reporting level), GPO policy overrides, tamper protection state | Compliance scoring and risk detection |
| Defender scan recency | Quick scan age (days), full scan age (days), last quick scan date, last full scan date, signature age (days), last signature update timestamp | Compliance scoring: ensures devices are actively scanned and definitions are current |
| Defender threat detections | Threat events reported by Windows Defender at inventory time (detection names, timestamps, and detection states) | Threat detection and automated risk creation |
| Installed software | Name, version, vendor, install date | CVE correlation and patch assessment |
| Patch level | Installed Windows KBs and their status | Patch compliance tracking |
| Network exposure | Open and listening TCP/UDP ports | Network risk assessment |
| Local accounts | Account name, enabled state, last logon, SID. No passwords collected | Access control risk detection |
| Startup items | Name, command, registry/folder location | Persistence detection |
| Scheduled tasks | Name, path, run-as account, status, schedule | Persistence and privilege detection |
| Shared folders | Name, path, type | Data exposure risk assessment |
| Browser extensions | Extension ID, name, version, browser, profile | Shadow IT and malicious extension detection |
| Logged-on users | Username, domain, session state (heartbeat snapshot only) | Active session monitoring |
| Running processes | PID, name, parent PID, thread count | Anomaly and persistence detection |
File contents, email or calendar data, browser history, keystrokes, screen captures, clipboard contents, or personal documents. Only security-relevant configuration metadata is collected.
Device & Inventory Data
Device data submitted in two modes: Inventory (every hour, with a full sweep daily at 03:00 and on agent startup); Change events (differential updates within minutes of detecting a change, e.g. new software installed, firewall disabled, new local admin added).
Inventory Storage Details
| Field | Category | Storage format | Update frequency |
|---|---|---|---|
| Hostname, IP, MAC, public IP | Device identity | Indexed database columns | Every heartbeat (5 min) |
| OS details (name, version, build) | Device identity | Indexed columns | Every inventory cycle |
| Hardware (manufacturer, model, serial, BIOS) | Device identity | Indexed columns | Every inventory cycle |
| Domain / Entra join info | Device identity | Indexed columns | Every inventory cycle |
| Security (AV, BitLocker, firewall) | Security configuration | JSON blob | Every heartbeat + inventory |
| Defender exclusions | Security configuration | JSON blob | Every inventory cycle |
| Defender sub-protection states | Security configuration | JSON blob (compact string diff) | Every heartbeat + inventory; change event emitted per changed component |
| Defender scan recency | Security configuration | JSON blob | Every inventory cycle |
| Defender threat detections | Security configuration | JSON array | Every heartbeat + inventory |
| Tamper protection state | Security configuration | Boolean field (within security JSON blob) | Every heartbeat + inventory |
| Installed software | Software inventory | JSON array | Every inventory cycle |
| Installed KBs (patches) | Patch level | JSON array | Every inventory cycle |
| Open ports | Network exposure | JSON array | Every inventory cycle |
| Startup items | Persistence | JSON array | Every inventory cycle |
| Scheduled tasks | Persistence | JSON array | Every inventory cycle |
| Local users & groups | Access control | JSON arrays | Every inventory cycle |
| Shared folders | Data exposure | JSON array | Every inventory cycle |
| Browser extensions | Shadow IT | Relational rows, fully replaced each inventory | Every inventory cycle |
| Network adapters | Network | JSON array | Every inventory cycle |
| Running processes | Process monitoring | JSON array | Every inventory cycle |
| Logged-on users | Session monitoring | JSON array (current snapshot) | Every heartbeat |
Change Events
Every detected change is stored as a DeviceChangeEvent record containing: the change category (e.g. software, security_av, local_admin), change type (added/removed/modified), old value, new value, and detection timestamp. Change events drive automated risk creation and populate the device change history timeline.
Change event records are kept for a configurable retention window (between 7 and 3,650 days, 365 days by default) and older records are removed by a nightly job. Removal is a permanent delete; no archive copy is kept.
User & Identity Data
PII Stored Per User
| Field | Required? | Notes |
|---|---|---|
| Email address | Yes | Unique identifier and login credential |
| First name | Yes | Displayed in the platform UI |
| Last name | Yes | Displayed in the platform UI |
| Work phone | No | Optional contact field |
| Personal phone | No | Optional contact field |
| Job title | No | Optional profile field |
| Last login timestamp | Auto | Updated on every successful login |
| Password changed timestamp | Auto | Recorded on every password change |
Credential Security
| Credential | Storage method |
|---|---|
| Passwords | Stored as a salted one-way hash. Plaintext is never stored. |
| 2FA TOTP seed | Encrypted in the database |
| Security keys and passkeys (FIDO2) | Public key credential only. The private key stays on the security key or device. |
| Single sign-on (Entra ID, Google) | The provider verifies the credentials. No provider token ever appears in a URL. |
| Enrollment tokens | SHA-256 hash only. The raw token is discarded after creation |
| Device signing keys | Ed25519 public key only. The private key never leaves the device |
| JWT secrets | Held in the server configuration only, never persisted to the database |
Session Controls
| Control | Value |
|---|---|
| Access token lifetime | 15 minutes |
| Refresh token lifetime | 8 hours |
| Inactivity timeout | 30 minutes by default (platform-wide setting) |
| Sign out everywhere | Ends every session a user holds on its next request |
| Account lockout threshold | 5 failed login attempts |
Session activity is enforced server-side. Every authenticated request resets the activity window to the configured inactivity timeout. On logout or timeout expiry the session state is immediately cleared. No residual session state is retained beyond the active window.
Risk Acceptance Records
When a user accepts a risk through the platform's risk acceptance workflow, the following user-linked fields are written to the risk record and retained as part of it:
| Field | Content | Required? |
|---|---|---|
acceptedBy | User ID of the accepting user | Yes |
acceptanceJustification | Free-text business justification statement | Yes |
compensatingControls | Free-text description of any compensating controls in place | No |
acceptanceExpiresAt | Date the acceptance expires; risk is automatically reopened after this date | No |
acceptanceReviewedAt | Timestamp of last acceptance review | Auto |
Risk acceptance records are retained indefinitely as part of the risk record until the risk or its parent client is deleted. When an acceptance expires, the risk is automatically returned to OPEN status and the acceptance fields are cleared.
Geolocation Data
When a user logs in or performs a significant action, Secuno records the user's IP address and resolves an approximate geolocation (country, city, region, and ISP). This data is stored in the audit log alongside the action record and is used for security monitoring and compliance evidence. Geolocation accuracy is typically city-level for broadband connections and less precise for mobile or VPN connections.
Audit & Event Logs
Secuno maintains a comprehensive audit log covering 70 action types. Every audit record captures: who performed the action (user ID), what changed (event type + before/after field values), when it occurred (UTC timestamp), and where (IP address, user agent, and geolocation).
Audit Log Retention
Audit logs are kept for a configurable retention window (between 7 and 3,650 days, 365 days by default); older entries are removed by a nightly job, and the log can be exported in CSV or JSON at any time. Platform administrators see the full log. Staff administrators and partners see only entries about the clients they are assigned to or manage. When support staff act on a user's behalf, every action is recorded as the administrator acting on behalf of that user.
This provides a tamper-evident history for compliance purposes while keeping retention aligned with the storage-limitation principle (e.g. GDPR Article 5(1)(e)). If your organisation requires a different retention window, contact your Secuno administrator to arrange it.
The audit log supports ISO 27001 A.12.4 (logging and monitoring), SOC 2 CC6 and CC7 (logical access and system operations), and serves as admissible evidence for incident chain-of-custody requirements.
Data Isolation & Multi-Tenancy
Secuno is a multi-tenant platform. Every data record (devices, risks, reports, tickets, users, audit logs) carries a client identifier that scopes it to a single organisation. Isolation is checked by the application and enforced underneath it by the database itself: a query that omits its tenant filter returns nothing, and a record cannot be written for another tenant.
Access Scope by Role
| Role | Data access scope |
|---|---|
GLOBAL_ADMIN / ADMIN | All clients and all data across the platform |
SECUNO_ADMIN | Only clients explicitly assigned to that administrator |
PARTNER_ADMIN / PARTNER_USER | Their own client plus all sub-clients linked to their partner organisation |
CLIENT_SUPER_USER / CLIENT_USER | Their own client only |
No client can query, view, or modify data belonging to another client. There is no shared index or cross-client query path in the application, and the database refuses one if it is ever attempted.
Partner Hierarchy
Partners (MSSPs and resellers) are modelled as a top-level client with a set of sub-clients. A PARTNER_ADMIN can access all sub-client data but cannot access clients outside their partner hierarchy, so managed service providers can operate on behalf of multiple customers without data co-mingling.
Cascade Deletion
A client that holds data is removed through offboarding. An export produces one JSON document of everything the client owns, with secrets stripped. A preview counts what a purge would destroy without destroying it. The purge itself cascade-deletes all associated data (devices, change events, risks, reports, tickets, tasks, scan requests, support requests, notifications, scheduled reports and stored integration credentials). It is available to the Global Admin role only, requires typing the client's name, and refuses an active client or a partner that still has linked clients.
Communication & Storage Security
Transport Security
All communication encrypted using TLS 1.3. HSTS enforced with one-year max-age including subdomains and preload eligibility. Unencrypted HTTP not accepted.
Agent Request Signing (Ed25519)
Every request signed using Ed25519. This guarantees:
- Originates from an enrolled device, not a spoofed or rogue source
- Has not been tampered with in transit: the request body SHA3-256 hash is included in the signature
- Cannot be replayed: timestamps validated within a ±5-minute window; nonces prevent exact replay attacks
Signed Request Headers
| Header | Purpose |
|---|---|
X-Secuno-Device-Id | The enrolled device's unique identifier |
X-Secuno-Client-Id | The client (organisation) ID |
X-Secuno-Timestamp | Unix timestamp (ms), must be within ±5 minutes of server time |
X-Secuno-Nonce | Random value that prevents exact replay attacks |
X-Secuno-Body-Hash | SHA3-256 hash of the raw request body |
X-Secuno-Signature | Ed25519 signature over the canonical header string |
Agent Private Key Storage
Ed25519 private key generated on device during enrollment, stored using Windows DPAPI (Data Protection API). DPAPI encrypts the key using credentials derived from the Windows user account and machine identity. Private key never leaves the device and is never transmitted to Secuno. Only the corresponding 32-byte public key is stored server-side.
Enrollment Token Security
32-byte cryptographically random values. Only SHA-256 hash stored in database. The raw token is returned once at creation, then discarded. Tokens support configurable maxUses and expiresAt.
Agent Installation Directory Hardening
The installer applies strict Windows ACL rules to the agent's local data directory. It is granted full control to SYSTEM and Administrators only; standard users are explicitly denied read, execute, write, and delete access. Inheritance is disabled.
File Uploads
Ticket attachments and risk evidence are restricted to an allowlist of document, image and data types. Risk evidence is limited to 50 MB per file and 10 files per risk; ticket attachments to 20 MB per file. Uploaded files are kept on persistent storage that survives platform updates, and a download never exposes where the file is stored.
Local AI Processing
Two AI-powered enrichment tasks run on the platform's own local AI (SECAI): CVE risk enrichment generates structured analysis covering overview, root cause, attack chain, impact, affected versions, and remediation. Agent change risk classification assigns a risk level (Critical, High, Medium, or Low) with a reason when no deterministic scoring pattern matches.
All AI inference runs within the platform's own servers. No data is transmitted to external AI services or cloud-based LLM APIs.
EPSS Exploit Probability Scoring
Fetches EPSS scores from FIRST.org API (api.first.org/data/v1/epss) daily. CVE identifiers submitted in batches of up to 100 to retrieve exploit probability scores and percentile rankings. EPSS scores stored on CVE records and used to adjust risk priority scoring; a significant spike (≥ 0.3 increase to ≥ 0.7) automatically escalates linked open risks to CRITICAL.
Only CVE identifiers are transmitted to FIRST.org. No personal data, software inventory, device identifiers, or any organisation-specific data is included in these requests.
Retention Policies
The following table summarises the current retention behaviour for each data category in the Secuno platform.
| Data category | Retention period | Deleted when |
|---|---|---|
| Device inventory (latest snapshot) | Indefinite | Device is hard-deleted |
| Device change events | Configurable, 7 to 3,650 days (default 365) | Nightly after the retention window, or device is hard-deleted |
| Browser extension records | Replaced on each full inventory | Device is hard-deleted |
| Risks & findings | Indefinite | Manually deleted, or parent client deleted |
| Audit log | Configurable, 7 to 3,650 days (default 365) | Nightly after the retention window; individual entries cannot be deleted via the application |
| Reports (metadata + data snapshot) | Indefinite | Manually deleted, or parent client deleted |
| Notifications | Configurable, 7 to 3,650 days (default 365) | Nightly after the retention window, or user is hard-deleted (cascade) |
| Sessions (JWT) | Access: 15 min · Refresh: 8 h | Token expiry or explicit logout |
| Session activity state | Inactivity timeout window (default 30 min, configurable) | Expires on inactivity or deleted immediately on logout |
| Enrollment tokens | Until expiry or max-uses reached | Manually revoked, expired, or max uses hit |
| Device credentials (public key) | Until revoked | Device revoked or device hard-deleted |
| File attachments and risk evidence | Indefinite, on persistent storage | Manually deleted, or parent client purged |
| Tickets & comments | Indefinite | Manually deleted, or parent client deleted |
| Risk acceptance records | Indefinite (as part of risk record) | Risk deleted or parent client deleted; acceptance fields cleared on expiry when risk is reopened |
| AI enrichment metadata | Indefinite (stored with the risk record) | Risk deleted or parent client deleted |
| Learned CVE aliases | Indefinite | Stored as a platform setting; cleared only by manual administrator action |
| User PII | Until user is hard-deleted | Removed by an authorised administrator through the user deletion control |
Audit logs, device change events, notifications, usage metrics and setting change history are pruned nightly after their retention window. Pruning is a permanent delete with no archive copy. All other data accumulates until explicitly deleted or until the parent client, device or user is deleted. Organisations with regulatory data minimisation requirements (e.g. GDPR Article 5(1)(e)) should contact Secuno to discuss the retention configuration.
Data Deletion
All deletes in Secuno are hard (permanent) deletes. There is no recycle bin or soft-delete mechanism. Once deleted, records cannot be recovered through the application.
Device: Revocation vs. Hard Delete
| Operation | Effect | Data retained? |
|---|---|---|
| Revoke device | Invalidates the agent's Ed25519 signing key. Device can no longer submit data. Status set to revoked. | Yes. All inventory, change events, credentials, and risks are retained |
| Hard delete device | Removes the device and all associated records permanently. | No. Inventory, change events, browser extensions, and credentials are deleted |
User Deletion
Hard-deleting a user (available to authorised administrators) removes the user record, sessions, and notifications. Risk notes and ticket comments are retained but the user reference is cleared. Audit log entries retain the user ID for compliance traceability.
Deactivation sets the user to inactive (cannot log in) without deleting any data. This is the recommended approach when offboarding team members while preserving the audit history.
Deletion Role Requirements
| Delete operation | Minimum role required |
|---|---|
| Delete device | ADMIN / SECUNO_ADMIN / GLOBAL_ADMIN |
| Revoke device | ADMIN / SECUNO_ADMIN / GLOBAL_ADMIN |
| Delete user | GLOBAL_ADMIN / ADMIN |
| Delete report | ADMIN / SECUNO_ADMIN / GLOBAL_ADMIN |
| Delete enrollment token | ADMIN / SECUNO_ADMIN / GLOBAL_ADMIN |
| Delete client (all data) | GLOBAL_ADMIN |
Data Export
Secuno supports structured data export through the Reports system. Exports are scoped to your client and require an authorised user role.
Export Formats
| Format | How to access | Contents |
|---|---|---|
| Download from the Reports system | Formatted report with risk tables, summary, and recommendations. Cap of 50 detail rows. | |
| CSV | Download from the Reports system | Flat spreadsheet: ID, Title, Severity, Status, Category, CVSS Score, Created At. Suitable for Excel, Power BI, or SIEM import. |
| JSON | Download from the Reports system | Full structured payload including all risk fields, affected assets, linked CVEs, and report metadata. |
Generating an Export
From the Reports system, generate a report by choosing a report type (for example a risk summary), a title, the client scope, and a start and end date. Once the report is ready, download it in your chosen format (PDF, CSV, or JSON).
Configure a Scheduled Report to automatically generate and email exports on a recurring cadence (weekly, monthly, etc.) in PDF, CSV, or JSON format without manual steps.
Compliance Considerations
GDPR Mapping
| GDPR Principle | Secuno position |
|---|---|
| Lawful basis | Processing is typically based on legitimate interest in IT security or, for employees, contractual obligation. Document your lawful basis in your DPA. |
| Data minimisation | Only security-relevant telemetry is collected. No personal files, communications, or browsing data. Review the collected fields table (Section 01) and disable optional categories if not needed for your use case. |
| Storage limitation | Audit logs, change events and notifications are pruned nightly after a configurable retention window (365 days by default). Establish a housekeeping schedule for other historical data if your policy requires time-bounded retention. |
| Right to erasure | User records and device records can be hard-deleted by an authorised administrator through the platform's deletion controls, and a whole client can be purged at offboarding. Audit log entries referencing deleted users retain the user ID for compliance integrity. |
| Data portability | Risk data is exportable as JSON (including AI enrichment metadata). Device inventory is accessible per device, and an aggregated software inventory view is available. A whole-client export as one JSON document, secrets stripped, is available to platform administrators. |
| Security of processing | TLS 1.3, Ed25519 request signing, bcrypt passwords, DPAPI key storage, RBAC, and client-level data isolation enforced by the database are all in place. |
ISO 27001 / SOC 2 Evidence
| Control | Secuno evidence |
|---|---|
| ISO 27001 A.9: Access control | Every login, failed login, 2FA change, and role change logged with IP and geolocation |
| ISO 27001 A.12.4: Logging and monitoring | 70 action types logged with before/after state, user ID, and timestamp |
| ISO 27001 A.16: Incident management | Full risk lifecycle (created → assigned → resolved) audited with timestamps |
| SOC 2 CC6: Logical access | Session controls, account lockout, 2FA, and RBAC enforcement |
| SOC 2 CC7: System operations | Continuous device change event monitoring with automated risk creation |
Data Processing Agreement
Organisations subject to GDPR or similar regulations should establish a Data Processing Agreement (DPA) with Secuno before deploying the agent to end-user devices. The DPA should address: categories of personal data processed, sub-processors used, data retention periods, and deletion procedures.
For most corporate IT environments, device telemetry (device identifiers, software inventory, security configuration) relates to corporate-owned assets and is processed under the organisation's legitimate interest in information security, not as personal data processing. However, local user account names, logged-on user session data, and risk acceptance justification text (which may name individuals) may constitute personal data in some jurisdictions and should be reviewed with your Data Protection Officer.
Secuno contacts FIRST.org's public EPSS API daily to retrieve exploit probability scores for known CVEs. Only standard CVE identifiers are transmitted. No personal data, device data, or organisation-specific information is involved. If your security policy restricts all outbound API calls, this integration can be disabled by your Secuno administrator.