Table of contents
- Scope
- Security program
- What we do not claim
- Reporting a vulnerability
- Incident response
- Notification timelines
- Incident register
- Backups and restore testing
- Business continuity
- Contact
1. Scope
1.1 This page applies to all SonhoLab products. That includes the website, central registration, the control panel, the business Systems, the AI agents, the free tools and the consumer apps.
1.2 It describes the security measures of L. M. PEREZ MONTANA (SonhoLab), CNPJ 61.620.014/0001-00, Rua Fausto Cabral, 871, Casa A, Vicente Pinzon, Fortaleza-CE, 60181-227, Brazil.
1.3 For business customers, the binding security commitments are in the Data Processing Addendum (DPA), Annex II. This page summarizes them and adds the process details. If this page and the DPA differ, the DPA prevails for Customer Personal Data.
2. Security program
2.1 Hosting. The products are hosted by Hetzner Online GmbH on servers in Helsinki, Finland (EU). Email runs on SonhoLab's own mail server on the same infrastructure. SonhoLab operates equipment in Brazil that stores the encrypted off-site backup copy (Section 8). Subprocessors and International Transfers lists every provider.
2.2 Encryption in transit. All connections to our products use TLS.
2.3 Encrypted off-site backups. Off-site backups are encrypted on the server before they leave it (Section 8).
2.4 Restricted access. Only named SonhoLab personnel who need access to production systems have it. Access to production servers requires personal SSH keys; password login is disabled. Administrative web panels use single-use sign-in links sent to named SonhoLab email addresses.
2.5 Separation between organizations. Each organization's data is logically isolated. Every database query carries the organization's identifier. Database row-level security adds a second layer. It is being rolled out System by System. Business customers can ask for the current status of their System. Inventory already has database row-level security in production.
2.6 Rate limiting. The products use rate limiting to slow down password guessing and other abuse.
2.7 Access logs. We keep access logs for 6 months, as Brazil's Marco Civil da Internet (Art. 15) requires. We keep them up to 12 months when a security investigation needs them. They are stored confidentially and access to them is restricted.
2.8 Secrets. Passwords, API keys and other secrets are kept outside source code.
2.9 Malware response. Our incident response process covers malware on servers or on equipment used to operate the products (Section 5).
2.10 Confidentiality of personnel. Everyone with access to personal data is bound by a written duty of confidentiality.
2.11 Suppliers. Subprocessors are bound by written data protection terms. SonhoLab's own AI account is used only for its website chat and support desk and is contractually barred from training on the data. AI features of the Systems run on each customer's own AI key, which SonhoLab stores outside source code, with access restricted to SonhoLab personnel.
2.12 Annual review. We review these measures at least once a year and after any significant incident. We update this page when they change.
3. What we do not claim
3.1 No certifications. SonhoLab does not hold SOC 2, ISO 27001 or any other security certification or third-party attestation. We do not claim to be "certified", "audited" or "compliant with" any security standard.
3.2 No guarantee. No system is completely secure. We cannot guarantee that an incident will never happen. We commit to the measures on this page and to responding as described below.
3.3 Not a HIPAA business associate. We are not a HIPAA business associate unless a separate business associate agreement is signed. We do not offer one by default.
4. Reporting a vulnerability
4.1 Where to write. Send vulnerability reports to security@sonholab.com, with the subject "Security report". This contact is also published in our security.txt file at https://sonholab.com/.well-known/security.txt.
4.2 What to include. Please include:
- the product and URL, app version or endpoint affected;
- a description of the issue and its possible impact;
- the steps to reproduce it; and
- how we can contact you.
4.3 What we do. We will acknowledge your report within 5 business days. We will assess it, keep you informed, and tell you when it is fixed. We will credit you if you wish, unless you prefer to stay anonymous.
4.4 Rules for good-faith research. Please:
- test only against your own accounts or data you are authorized to use;
- stop and report as soon as you can see data that is not yours. Do not copy, keep or share it;
- not degrade service for other users (no denial-of-service, spam or load testing);
- not use social engineering, phishing or physical attacks against our people or suppliers;
- not test our suppliers' systems (for example, Hetzner or Stripe). Report to them directly; and
- give us reasonable time to fix the issue before you disclose it publicly.
4.5 Safe harbor. If you follow these rules, we will not take legal action against you for your research, and we will not ask authorities to do so. This does not bind third parties, and it cannot authorize anything the law forbids.
4.6 No bounty. We do not run a paid bug bounty program.
4.7 Mobile apps (EU Cyber Resilience Act). This page is also the coordinated vulnerability disclosure policy and the single point of contact for vulnerabilities in the mobile apps SonhoLab places on the EU market.
5. Incident response
We handle security incidents in six phases.
| Phase | What happens |
|---|---|
| 1. Detect and report | Incidents come from monitoring, alerts, logs, supplier notices, users, customers and researchers. Anyone at SonhoLab who suspects an incident reports it at once. |
| 2. Triage | We confirm whether it is an incident, estimate its severity, and check whether personal data is affected. The notification clock for customers starts when we confirm a personal data breach. |
| 3. Contain | We stop the harm. For example: isolate systems, revoke credentials, rotate secrets, block access, remove malware. We preserve evidence where possible. |
| 4. Assess | We establish what happened, which data and people are affected, the likely consequences, and whether the data was encrypted. This decides who must be notified (Section 6). |
| 5. Notify | We notify affected business customers, authorities and individuals within the deadlines in Section 6. Where facts are still missing, we notify in phases. |
| 6. Recover and learn | We restore service, from backups if needed, and verify the fix. Within a reasonable time we review the root cause and update our measures. The incident register records the outcome. |
Malware. If malware is found on a server or on equipment used to operate the products, we treat it as an incident. We isolate the affected equipment, check whether data or credentials were exposed, rotate what may have been exposed, and restore from a known clean state.
Customer data. For data we process for a business customer, the customer is the controller. It decides whether to notify authorities and individuals. We give it the facts and the help it needs (DPA, Section 11).
6. Notification timelines
The clock for each deadline starts as the law or contract says. For business customers it starts when we confirm the breach. For the ANPD it starts when we learn that personal data was affected. For EU and UK authorities it starts when we become aware of the breach.
| Audience | When SonhoLab notifies | Deadline | Legal source |
|---|---|---|---|
| Business customers (controllers of the data in their System) | Any personal data breach affecting their Customer Personal Data | Without undue delay: target 48 hours, maximum 72 hours after confirmation, with updates in phases | DPA, Section 11; GDPR Art. 33(2); LGPD Art. 39 |
| ANPD (Brazil), where SonhoLab is controller | Incidents that may cause relevant risk or damage to data subjects | 3 business days; supplementary information within 20 business days | LGPD Art. 48; Res. CD/ANPD 15/2024 |
| Data subjects in Brazil, where SonhoLab is controller | Same threshold as for the ANPD | 3 business days, in clear language | LGPD Art. 48; Res. CD/ANPD 15/2024 |
| EU supervisory authority, where SonhoLab is controller | Breaches unless unlikely to result in a risk | Without undue delay and, where feasible, within 72 hours; reasons for any delay | GDPR Art. 33 |
| UK Information Commissioner, where SonhoLab is controller | Breaches unless unlikely to result in a risk | Without undue delay and, where feasible, within 72 hours | UK GDPR Art. 33 |
| Individuals in the EU and UK, where SonhoLab is controller | Breaches likely to result in a high risk | Without undue delay | GDPR Art. 34; UK GDPR Art. 34 |
| US residents and state regulators, where SonhoLab is the data owner or licensee | Breaches of personal information covered by the resident's state law | As each state's law requires. Many states set fixed deadlines (often 30 to 60 days) and require notice to the state attorney general above a threshold of residents | State breach notification laws |
| ENISA and the designated national CSIRT (EU Cyber Resilience Act) | Actively exploited vulnerabilities and severe incidents affecting the security of SonhoLab's mobile apps on the EU market | Early warning within 24 hours; notification within 72 hours; final report within the Act's deadline | Regulation (EU) 2024/2847, Art. 14 |
| Users of an affected mobile app (Cyber Resilience Act) | Same events as for ENISA, where users need to act | Without undue delay, with the steps they can take | Regulation (EU) 2024/2847, Art. 14 |
Where a business customer is the controller, notices to authorities and individuals are the customer's decision. The customer's own deadlines apply. For example, the 3-business-day ANPD deadline applies to the customer as controller. Our 48-to-72-hour notice to the customer is designed to leave it time to meet them. Product addenda may add contract-specific timelines, for example for schools in the Children and Student Data Addendum (Verita).
Content of a notice. As far as known: what happened and when; the categories and approximate number of people and records affected; the likely consequences; the measures taken or proposed, including how affected people can protect themselves; whether the data was encrypted; and a contact point.
7. Incident register
7.1 We record every security incident involving personal data in an internal register, whether or not it had to be notified.
7.2 Each entry records the facts, the effects, the data and people affected, the assessment of risk, the decision on notification and the reasons for it, and the corrective measures.
7.3 We keep the register for 5 years (Res. CD/ANPD 15/2024; GDPR Art. 33(5)). We make it available to supervisory authorities on request. Business customers may ask for the entries that concern their data.
8. Backups and restore testing
8.1 What we keep. Hetzner makes automated server backups in Finland (EU). Database backups are kept up to 14 days on the server side and up to 14 days in the off-site copy, on equipment operated by SonhoLab in Brazil. Brazil and the EU recognize each other as adequate.
8.2 Encryption. The off-site copy is encrypted on the server before it leaves it. It is stored only in encrypted form. We check that each off-site copy is not empty and we are alerted if a copy fails.
8.3 Expiry. Backups expire on this schedule. Data you deleted, or data deleted at the end of a contract, disappears from backups when they expire, so within 30 days at most. Until then, backups are used only to restore service after an incident.
8.4 Restore testing. We test restoring from backups every 3 months and after significant changes to the backup process. We record each test.
8.5 No published recovery targets. We do not currently publish recovery point or recovery time objectives. Business customers should keep their own exports of data they cannot afford to lose. Export is available on all plans.
9. Business continuity
9.1 Main dependency. The products run on Hetzner's infrastructure in Finland. A major outage there affects our products. In that case we restore from our encrypted off-site backup copy onto replacement infrastructure.
9.2 Suppliers. If a subprocessor becomes unavailable or must be replaced, we may switch temporarily to an alternative or suspend the affected feature. For example, an AI feature or a payment method. Replacing a subprocessor follows the notice rules in Subprocessors and International Transfers.
9.3 Customer AI providers. AI features run on each customer's own AI provider. If that provider is unavailable, or the customer's key is invalid or exhausted, those features stop until the provider or key works again. The rest of the System keeps working. Hades, which is not offered to the public, is covered by its own Addendum.
9.4 Communication. During a significant outage we inform affected business customers by email and keep them updated until service is restored.
9.5 Exit. Business customers can export their data at any time and leave with at most 2 months' notice (DPA, Section 18). They do not depend on SonhoLab continuing to operate to get their data out.
10. Contact
- Vulnerability reports and security questions: security@sonholab.com (subject "Security report").
- Encarregado (DPO) and privacy questions: contacto@sonholab.com.
- EU representative: SonhoLab is appointing a representative in the European Union (Ireland). Until the appointment is published, EU residents can contact contacto@sonholab.com. UK representative: none; we do not currently direct our services to the United Kingdom.
Related documents: Data Processing Addendum (DPA); Subprocessors and International Transfers; Data Retention Schedule; Privacy Policy; Your Privacy Rights and How to Exercise Them.
Version 0.9.0 (preliminary) · Effective 26 September 2026 · © L. M. PEREZ MONTANA (SonhoLab), CNPJ 61.620.014/0001-00. This version is under legal review; we will notify material changes as described in these documents.