Incident Response Policy
Itnetic Technologies
Last updated: 31 July 2026
This policy describes how Itnetic detects, handles and communicates security incidents and personal-data breaches. It supports Articles 32–34 GDPR and Section 7 of the Data Processing Addendum.
1. Severity levels
| Level | Meaning | Examples |
|---|---|---|
| SEV-1 | Confirmed compromise, or total loss of service | Unauthorised access to the control plane or database; edge network down across all POPs; customer data exposed to another customer |
| SEV-2 | Serious degradation or a credible security risk | A point of presence down; a vulnerability with a working exploit path against production; mitigation failing for a customer under attack |
| SEV-3 | Limited impact, workaround exists | Single-feature outage; a vulnerability requiring unusual preconditions; elevated error rate |
| SEV-4 | No customer impact | A dependency advisory not reachable in our configuration; a monitoring gap |
A suspected personal-data breach is treated as at least SEV-2 until it is ruled out, regardless of how small it looks.
2. Lifecycle
1 — Detect. From automated alerting (attack detection, error-rate and anomaly alerts on per-host traffic baselines, provider notifications), a vulnerability report received under the Security Policy, or a customer report.
2 — Triage. Assign a severity, start a written timeline, and stop the clock guessing: if it might be a personal-data breach, the 72-hour GDPR clock is treated as already running from the moment of awareness.
3 — Contain. Cut the attack path first, diagnose second. Typical measures: revoke credentials and tokens, revoke sessions, block at the kernel firewall, disable the affected feature, isolate a point of presence, or roll back the release.
4 — Eradicate and recover. Fix the root cause, deploy, verify the fix in production, and confirm the containment measures can be safely lifted.
5 — Notify. See Section 3.
6 — Review. For SEV-1 and SEV-2, a written post-incident review within 10 business days: timeline, root cause, what detection missed, and the concrete changes made. Blameless — the output is a change to the system, not to a person.
3. Notification
To customers
| Severity | Target |
|---|---|
| SEV-1 | Within 4 hours of confirmation, then updates at least every 12 hours until resolved |
| SEV-2 | Within 24 hours of confirmation |
| SEV-3/4 | In the changelog or the next routine communication |
Channel: the account email address, plus status.itnetic.com where the incident affects availability.
Personal-data breaches (Itnetic as controller — your account data)
- To the Czech supervisory authority (ÚOOÚ) without undue delay and, where feasible, within 72 hours of becoming aware, unless the breach is unlikely to result in a risk to individuals.
- To affected individuals without undue delay where the breach is likely to result in a high risk to them.
Personal-data breaches (Itnetic as processor — your visitors' data)
- To the affected customer without undue delay and, where feasible, within 72 hours of becoming aware.
- The customer, as controller, decides on and makes any notification to authorities and data subjects. We supply what we know and assist.
What a notification contains, as far as it is known at the time: the nature of the incident, the categories and approximate volume of data and individuals affected, the likely consequences, the measures taken or proposed, and a contact point. We send an initial notification with partial information rather than delaying for a complete picture.
4. Evidence and records
- Every incident from SEV-3 upward gets a written record: timeline, decisions and their reasons, data affected, and notifications sent.
- Records are retained for 3 years.
- Because request logs are deleted after 30 days (Data Retention Policy), any logs needed as evidence are exported out of the normal retention path at triage time and held under the incident record. Where those logs contain personal data, they are held only for as long as the investigation and any resulting legal claim require.
5. Limits we state openly
- There is no 24/7 human on-call rota. Automated mitigation runs unattended and continuously; human response times are the targets above, not a contractual SLA. Availability commitments, where a Plan has them, are in the SLA.
- The operator is a single person. If a SEV-1 arrives while they are unreachable, the automated defences continue to run but human response starts when they are reached.
6. Contact
Security and incidents: chlibekbusiness@gmail.com (subject [SECURITY]). Machine-readable: https://itnetic.com/.well-known/security.txt.