1. Definitions
- Security event: something worth checking (a failed-login spike, a vulnerability report, an alert, a supplier notice).
- Security incident: a confirmed or likely compromise of confidentiality, integrity or availability.
- Personal data breach: a security incident involving personal data.
2. Roles and contacts
The Founder is the incident lead and handles every step below. Contacts:
| Who | How |
|---|---|
| Reporting a vulnerability or incident | The address in /.well-known/security.txt, or contato@semantiqwall.com |
| ANPD (Brazil's data protection authority) | Incident communication form on gov.br/anpd |
| Brazilian police (cybercrime) | Civil Police of Goiás cybercrime unit, or the Federal Police for federal matters |
| US authorities, when US users are affected | FBI IC3 (ic3.gov); state attorneys general where a state law requires |
| CERT.br (coordination, optional) | cert@cert.br |
| Hosting provider (Hostinger) | Provider panel and support |
| Other suppliers | See policy 09 |
The contact list is reviewed at least once a year and recorded in the security register. From the first hire, a backup incident lead is named.
3. Severity levels
| Level | Examples | Start work |
|---|---|---|
| Critical | Confirmed access to customer data by an unauthorized party; audit chain broken; production keys leaked; active exploitation | Immediately, and within 4 hours at most |
| High | Exploitable vulnerability in production without evidence of exploitation; service down; loss of data without leak | Within 24 hours |
| Medium | Vulnerability with limited impact; partial degradation; incident at a supplier with possible impact | Within 3 business days |
| Low | Event with no customer impact | Within 10 business days |
4. Response steps
- Detect and record. Open an incident record in the security register: time detected (UTC), source, what is known.
- Triage. Confirm whether it is an incident, set the severity, identify affected organizations and data (the audit log and database show which organizations and records are involved).
- Preserve evidence before changing anything, when it does not delay containment of a critical incident (section 6).
- Contain. Examples: revoke keys (policy 02), block IPs in the firewall, disable an affected feature or integration, put the site in maintenance mode, remove a compromised SSH key.
- Eradicate and recover. Fix the cause through the normal change process or an emergency change (policy 03); restore from backup if needed (policy 06); verify the audit chain.
- Notify (section 5).
- Close and review (section 7).
5. Notification
Customers. We notify affected customer organizations (their owner, by e-mail) without undue delay and no later than 72 hours after confirming an incident that affects their data or their use of the service. The notice says what happened, what data and period are affected, what we have done and what the customer should do. Updates follow until closure.
Public advisories. For critical or high vulnerabilities that affected customers, we publish an advisory on the /security page after the fix, with the weakness type (CWE), what was affected, since when and what customers need to do, and a CVE identifier when applicable - as committed on that page.
Brazil - LGPD. When a personal data breach may create relevant risk or damage to data subjects, we notify the ANPD and the affected data subjects within 3 business days of becoming aware of it (ANPD Resolution CD/ANPD No. 15/2024). We do not rely on the longer deadlines available to small processing agents. When SemantiqWall acts as processor for a customer, we notify the customer (the controller) so the customer can notify, and we help with the information needed.
United States. When personal information of US residents is involved, we follow the breach laws of the states concerned: notice to affected individuals, and to state regulators where required, without unreasonable delay and within the shortest deadline that applies (several states set 30 to 60 days).
Suppliers. Incidents reported by a subprocessor (policy 09) are assessed like our own, and the same notification rules apply when customer data is affected.
6. Evidence and forensics basics
- Before changing a compromised system when possible: take a Hostinger snapshot of the VPS if available; copy relevant logs (Caddy, application, auth and fail2ban logs, system journal) and a database dump to a secure location off the server; record SHA-256 hashes of the copies.
- Export the relevant audit-log range and run the audit-chain verification; keep the output.
- Keep a timeline with UTC timestamps of every action taken.
- Evidence is kept for at least 5 years or longer if a legal matter requires it, with access limited to the Founder and, when needed, lawyers or authorities.
- Customer requests for e-discovery or forensic data about their own organization are answered with an export of their audit log and decisions.
7. Post-incident review
Within 10 business days of closing a critical or high incident: a written, blameless review with timeline, root cause, what worked, what did not, and corrective actions with owners and dates, tracked in the register.
8. Metrics and records
The register keeps every incident record. For each: time to detect, time to contain, time to resolve and time to notify. Once a year, the Founder reviews all incidents together to look for patterns and root causes. To date, no security incident has been recorded.
9. Testing this plan
This plan is tested at least once a year with a tabletop exercise (for example: leaked database password; audit chain broken; supplier breach), recorded in the register with lessons learned. First exercise: owner Founder, target 2027-03-31.