Kardu threat model
We publish our threat model because asking for your trust without demonstrating it first would be inconsistent with what we are building. This document describes which assets we protect, which threats we consider relevant and which controls we have implemented.
01. Assets we protect
These are the information assets that Kardu manages on behalf of its clients and that require active protection.
Customer GRC data
Controls, evidence, risk registers, Compliance Score and all compliance program documentation.
Authentication credentials
Passwords (hashed), session tokens, API keys and integration secrets with external tools.
Evidence documents
Files uploaded by the client as control evidence. Their cryptographic integrity is guaranteed.
Integration credentials
OAuth tokens and API keys from integrations with client tools (JIRA, Slack, etc.).
02. Identified threats and controls
For each threat we document its estimated severity and the controls we have implemented to mitigate it.
Unauthorized access
An external or internal attacker gaining access to customer data without authorization. Includes credential stuffing, phishing and privilege escalation.
Controls
- Mandatory MFA
- Least privilege principle
- No direct DB access for employees
- Immutable access logs
Data exfiltration
Unauthorized extraction of GRC data or evidence documents, whether by external attackers or rogue employees.
Controls
- AES-256 encryption at rest
- TLS 1.3 in transit
- No bulk export without audit
- DLP in production environments
Insider threat
A Kardu employee with system access who accesses, modifies or exfiltrates customer data maliciously or negligently.
Controls
- Role-segmented access
- No local production data access
- Quarterly access review
- Immediate offboarding with credential revocation
Supply chain compromise
A Kardu sub-processor suffers a breach that indirectly affects customer data.
Controls
- Signed DPA with each sub-processor
- Published sub-processor list
- Annual sub-processor review
- EU-headquartered sub-processors only
Evidence tampering
Undetected modification of evidence documents after upload, compromising the integrity of the compliance program.
Controls
- SHA-256 hash at upload time
- Immutable cryptographic timestamp
- Non-editable change history
- Integrity verification on every access
Service disruption
DDoS attack or infrastructure failure that prevents system access during an audit or critical compliance period.
Controls
- Redundant infrastructure in Frankfurt
- Daily backups with 30-day retention
- 99.9% availability SLA
- Documented continuity plan
03. Out of scope
These areas fall outside Kardu's direct responsibility, although we manage them contractually where possible.
Physical datacenter security
Responsibility of the infrastructure provider (datacenter SOC 2, ISO 27001 certifications).
End-user devices
The security of the device from which the client accesses Kardu is the client's responsibility.
Third-party integrations
The security of external tools connected to Kardu (JIRA, Slack, etc.) is outside our direct control.
04. Incident notification
In the event of a security incident affecting customer data, Kardu commits to notifying affected customers within a maximum of 72 hours from detection, in compliance with Article 33 of the GDPR. The notification will include the nature of the incident, the data affected, the measures taken and the recommended steps for the client.
Questions about our security
This document is public and is updated with every relevant architecture change. If you have questions, concerns or want to report a vulnerability, write to us directly.