Privacy and GDPR
What personal data InnerWarden processes, how long it keeps it, and the CLI commands for honouring GDPR data-subject requests, all on your host.
Privacy and GDPR
For: compliance and privacy reviewers who need to know what personal data InnerWarden touches, how long it keeps it, and how to honour a data-subject request.
InnerWarden is a security tool, so it does process personal data: an attacker's IP, a username from a failed login, a command a process ran. It does that to protect the server, and it does it entirely on your host. There is no cloud component, and InnerWarden never phones home. The only data that leaves the box is what you explicitly switch on.
This page is the canonical home for two things the rest of the docs point back to: the data-retention schedule and the GDPR export and erase commands. ISO 27001 Mapping and Customer Security Pack link here rather than repeating them.
What personal data it processes
| Category | Examples | Where it comes from | Why | Kept for |
|---|---|---|---|---|
| IP addresses | Source IPs of SSH connections, HTTP requests, scans | auth log, nginx, eBPF, journald | Detection, blocking, enrichment | 7 days (events), 30 days (incidents) |
| Usernames | SSH login attempts, sudo commands, system users | auth log, exec audit, journald | Privilege-abuse detection, correlation | 7 days (events), 30 days (incidents) |
| Shell commands | Commands run via bash, sudo, cron | exec audit (opt-in), eBPF execve | Reverse-shell detection, execution guard | 7 days (events) |
| User agents | HTTP client strings | nginx access logs | Bot and scanner detection | 7 days (events) |
| SSH public keys | Key fingerprints from auth | auth log | Key-injection detection | 7 days (events) |
| Process metadata | PID, parent PID, exe path, arguments | eBPF, /proc | Process-tree and kill-chain analysis | 7 days (events) |
| Network connections | Destination IP, port, protocol | eBPF connect hook | C2 and exfiltration detection | 7 days (events) |
| Container IDs | Docker names and IDs | Docker events, cgroup id | Container-escape detection | 7 days (events) |
| Operator identity | Unix username of the admin taking an action | CLI commands, dashboard login | Admin-action audit trail | 90 days (admin actions) |
Data minimisation built in
- Shell-command auditing is opt-in. It does not run until you explicitly turn it on.
- Private and internal IPs are filtered out of incident generation, so loopback and RFC 1918 ranges do not raise alerts.
- Event detail is capped in size, so an event cannot become a dumping ground for arbitrary payloads.
- Forensic snapshots redact secrets, stripping environment variables whose names look like keys, secrets, tokens, or passwords.
- AI prompts are sanitised. When triage routes to an AI provider, it receives a cleaned incident summary, not raw logs. The AI never sees full shell commands, passwords, or private keys.
What leaves the box, and only if you ask
Every integration below is off by default. Nothing leaves the host unless you configure it. The keys to turn each one on live in Configuration.
| Destination | What it sends | Why | Turned on via |
|---|---|---|---|
| AbuseIPDB | Attacker IP plus attack category | Community threat-intel reporting | config abuseipdb |
| Cloudflare | Attacker IP | Edge-level WAF blocking | config cloudflare |
| AI provider | Sanitised incident summary | Triage recommendation | config ai |
| GeoIP | Attacker IP | Country and ISP enrichment | enrichment config |
| CrowdSec | Attacker IP | Community reputation check | enrichment config |
| Telegram | Incident summary, no raw PII | Operator alerts | config telegram |
| Slack / Discord | Incident summary, no raw PII | Operator alerts | config slack / config discord |
| Webhook | Incident JSON | Integration with your own systems | config webhook |
| Mesh peers | Block signals (signed) | Collaborative defence | config mesh |
The one network connection you may see from a default install is the release-update check. There is no telemetry channel reporting your installations back to the project.
The data-retention schedule
This is the single canonical schedule. Every retention period is configurable in the [data] section of the agent config; the data-retention pass runs on the agent's slow loop and permanently deletes files older than the configured threshold. Enforcement is automatic; no manual cleanup is needed.
| Data type | File pattern | Default retention | Config key |
|---|---|---|---|
| Raw events | events-YYYY-MM-DD.jsonl | 7 days | [data] events_keep_days |
| Incidents | incidents-YYYY-MM-DD.jsonl | 30 days | [data] incidents_keep_days |
| Decisions (audit trail) | decisions-YYYY-MM-DD.jsonl | 90 days | [data] decisions_keep_days |
| Admin actions (audit trail) | admin-actions-YYYY-MM-DD.jsonl | 90 days | tracks decisions_keep_days |
| Telemetry | telemetry-YYYY-MM-DD.jsonl | 14 days | [data] telemetry_keep_days |
| Reports | trial-report-YYYY-MM-DD.* | 30 days | [data] reports_keep_days |
| Forensic snapshots | forensics-*.json | 30 days | tracks incidents_keep_days |
| Daily narratives | summary-YYYY-MM-DD.md | 7 days | [narrative] keep_days |
For ISO 27001 A.18.1 (see ISO 27001 Mapping), keep decisions at 90 days or more. The file shapes themselves are documented in Data Formats; the full key reference is in Configuration.
A minimisation-leaning baseline you can drop into the config:
[data]
events_keep_days = 7 # keep raw events short
incidents_keep_days = 30
decisions_keep_days = 90 # audit trail; adjust to your regulation
Honouring data-subject rights
InnerWarden ships CLI commands that cover the common GDPR rights. These are the canonical commands; if a flag has changed, run innerwarden system gdpr --help.
Right of access (export)
Pull every record that references an IP address or username:
innerwarden system gdpr export --entity 203.0.113.10
innerwarden system gdpr export --entity john --output /tmp/john-data.jsonl
This scans all the data files (events, incidents, decisions, admin actions, telemetry) and writes the matching records to stdout or the file you name, in JSONL.
Right to erasure
Remove every record that references an entity:
innerwarden system gdpr erase --entity 203.0.113.10
innerwarden system gdpr erase --entity john --yes # skip the confirmation prompt
This rewrites the JSONL files without the matching records. The hash-chained files (decisions, admin actions) are recomputed afterwards so the audit chain stays intact (the chain mechanics are in ISO 27001 Mapping). The erasure itself is written to the admin-actions audit trail, recording who ran it and which entity was erased.
Right to rectification
There is no in-place edit. Correct a record by exporting it, erasing the original, and letting corrected data flow back through the normal pipeline.
Right to restrict processing
Add an entity to the trust set so it is excluded from autonomous triage and response:
innerwarden trust add --ip 203.0.113.10 --reason "data-subject restriction"
innerwarden trust add --user john --reason "data-subject restriction"
Note that trust means monitor-only: the entity is still observed and logged, but not auto-blocked. The full trust model and the never-blind workflow around it are in Safe Observe and Allowlist.
Legal basis
InnerWarden processes personal data under legitimate interest (GDPR Article 6(1)(f)) to:
- protect systems from unauthorised access,
- detect and respond to security incidents,
- maintain audit trails for compliance and forensics,
- share threat intelligence with community databases, only when you configure it.
The processing is proportionate: only security-relevant data is collected, retention is bounded and automatic, and data subjects can exercise their rights through the commands above.
Audit-trail integrity
Decision and admin-action logs are hash-chained with SHA-256: each entry carries the hash of the previous one, so any modification of a historical record breaks the chain and is detectable. This protects the integrity of the audit trail for compliance and forensic purposes. The verification mechanics and how to check the chain are owned by ISO 27001 Mapping.
Deployment notes for a privacy-conscious setup
- Keep third-party integrations off unless you need them; each one is a data-egress decision.
- Enable shell-command auditing only with documented consent.
- Review the trust set periodically.
- Run an export before retention cleanup if you have a reason to keep longer-term records elsewhere.
- Record your processing activities in your organisation's Record of Processing Activities (ROPA).
Data Processing Agreement
Because InnerWarden runs entirely on your infrastructure with no cloud component, the scope of any DPA is limited to the third-party integrations you choose to enable. For a formal DPA, see the contact in Customer Security Pack.
Related
- ISO 27001 Mapping: the control mapping and the audit-trail verification mechanics.
- Configuration: the
[data]retention keys and every integration's on switch. - Data Formats: the on-disk shapes of the events, incidents, and decisions files.
- Safe Observe and Allowlist: the trust model behind restrict-processing.
- Customer Security Pack: the wider compliance and contact picture.
- Trust and Safety Invariants: the default-local-only guarantee.