Information Security Policy
Guidelines to protect the confidentiality, integrity, availability and traceability of HABORA's information.
- Version
- 1.0
- Published on
- July 1, 2026
- Last updated
- July 1, 2026
- Next scheduled review
- July 1, 2027
1. Purpose
This Policy establishes guidelines to protect the confidentiality, integrity, availability, authenticity and traceability of the information processed by HABORA.
2. Principles
HABORA's architecture must observe least privilege, per-company segregation, access denied by default, security by design, privacy by design, proportionate monitoring, audit logs and risk management.
3. Scope
It applies to the platform, database, documents, infrastructure, integrations, APIs, AI, backups, users, employees, suppliers and processes related to HABORA.
4. Access control
Access to data must consider company, user, group, property, module and permitted action. Users must not access data outside the company, properties and authorized permissions.
5. Identification and authentication
Each user must have individual credentials. Passwords must not be shared or stored in plain text. The platform may adopt MFA, tokens, confirmation email and other mechanisms.
6. Password recovery and reset
Password recovery is performed exclusively via a secure link sent to the user's registered email, using the platform's native authentication mechanism (Better Auth) integrated with the transactional email provider (Resend). HABORA never sends the password by email nor displays the existing password.
Each request generates a unique, temporary, single-use token. The raw token is never stored in the database: only its hash (SHA-256) is kept. The reset link automatically expires in 30 minutes and is invalidated immediately after the first successful use.
For security, the platform adopts a neutral response: it never reveals whether a given email has a registered account. Invalid, expired or already-used tokens always return the same generic message, instructing the user to request a new link.
Upon completing the reset, all of the user's other active sessions are revoked, requiring a new login with the new password. The entire flow is audited immutably (request, email sending without exposing the token, attempt with an invalid token, attempt with an expired token, failure and completed reset), without recording sensitive data such as token or password; the email is recorded only as a hash for correlation purposes.
7. Data security
Data must be segregated by company, protected against improper access, preserved against unauthorized alteration and subject to logs for relevant events.
8. Encryption
Whenever applicable, HABORA shall use encryption in transit, credential protection, secure storage of secrets and encryption at rest for sensitive data as technically feasible.
9. Documents
Documents must have access control, a link to property and company, an upload record, versioning where available, change logs and restriction to authorized users.
10. Backups and continuity
Backup and recovery routines must protect service continuity. Restoration shall depend on technical feasibility, backup integrity and the priority of the incident.
11. Logs and monitoring
HABORA may record logins, invalid attempts, changes, permissions, documents, reports, AI usage, financial events, ESG, alerts, integrations and incidents.
12. Incidents
Incidents shall be assessed, contained, investigated and handled according to risk. Communications to customers, data subjects and authorities shall occur when necessary or required.
13. User responsibilities
Users must protect credentials, not share access, review permissions, report suspicions, use the platform in good faith and follow the Terms of Use.
Contact
Questions, legal requests, privacy requests, formal communications and requests related to this policy should be sent to juridico@haborahub.com.br.
Updates
This policy may be revised to reflect legal, regulatory, technical, commercial or operational changes. The current version will remain available in the HABORA Compliance area. Material changes may require new acceptance by users, where applicable.