NEXUS Group — Public compliance documentation
Incident Response and Breach Notification
Published incident response policy of NEXUS Group. It defines who is responsible, how incidents are classified and handled, and how marketplaces, sellers and authorities are notified.
- Document
- NX-IR-01
- Version
- 1.0
- Effective date
- Review cycle
- At least annually, and after any material change to the service.
Reporting channel
Security incidents, suspected breaches and vulnerability reports must be sent to gianlucca.florencio@zeroholding.com.br. Reports are acknowledged within 24 hours. Anyone — including marketplace teams, sellers and external researchers — may use this channel.
01Scope
This policy applies to any event that compromises, or may compromise, the confidentiality, integrity or availability of Protected Data or of the production environment: credential exposure, unauthorised access, malware, unexpected data disclosure, loss of a device holding company access, or a marketplace API abuse alert.
02Roles and responsibilities
| Role | Responsibility |
|---|---|
| Incident coordinator | The Privacy Owner / Data Protection Contact coordinates every incident: classification, decisions, communication and closure. Contact: gianlucca.florencio@zeroholding.com.br. |
| Technical responder | The system administrator performs containment, investigation, remediation and evidence collection in the production environment. |
| Notification owner | The incident coordinator issues notifications to marketplaces, sellers and, where legally required, to the supervisory authority and the affected individuals. |
| Reporter | Any person who detects a suspected incident must report it immediately through the security channel, without attempting to investigate it alone. |
03Severity levels
| Level | Definition | Target containment |
|---|---|---|
| S1 — Critical | Confirmed exposure of personal data, confirmed unauthorised access to the production database, or leaked marketplace credentials. | Immediate; containment actions start within 1 hour of confirmation. |
| S2 — High | Credible risk of exposure without confirmation, such as a suspicious authenticated session, or a critical vulnerability exploitable in production. | Within 8 hours. |
| S3 — Medium | Security weakness without evidence of exploitation, such as an outdated dependency with a known vulnerability. | Within 7 days, per the vulnerability remediation deadlines. |
| S4 — Low | Isolated policy deviation with no data at risk. | Next maintenance window. |
04Response phases
| Phase | Actions |
|---|---|
| 1. Detect and report | Log the report with date, time, reporter and observed facts. Acknowledge within 24 hours. |
| 2. Triage and classify | Assign a severity level, identify the systems and data categories involved, and appoint the technical responder. |
| 3. Contain | Revoke or rotate exposed credentials and the session signing secret, invalidate sessions, close the exposed path, and isolate the affected component. Rotate marketplace tokens when they may be involved. |
| 4. Investigate | Determine root cause, entry point, time window, which records were reachable and whether data was actually accessed or exfiltrated. Preserve logs as evidence. |
| 5. Notify | Notify marketplaces, sellers and, where required, authorities and affected individuals, per section 5. |
| 6. Remediate and recover | Deploy the fix, restore from a verified backup if integrity was affected, and confirm the environment is clean before resuming normal operation. |
| 7. Post-incident review | Document timeline, root cause, impact and corrective actions; update this policy, the security policy or the code as needed. Reviews are completed within 10 business days of closure. |
05Breach notification
- A confirmed personal data breach is notified to the affected marketplaces and sellers without undue delay and no later than 24 hours after confirmation.
- A suspected breach still under investigation is communicated as soon as the suspicion is credible, with the facts known at that moment and a commitment to a follow-up update.
- Where the law requires it, the supervisory authority and the affected individuals are notified within the legal deadline.
- Notifications are sent from the privacy channel and, when the marketplace provides a dedicated intake, through that intake as well.
| Field | Content |
|---|---|
| Nature of the incident | What happened, how it was detected and the current status. |
| Data involved | Categories and approximate volume of records and individuals affected. |
| Time window | When the incident started, when it was detected and when it was contained. |
| Likely consequences | Assessment of the risk to the affected individuals and sellers. |
| Measures taken | Containment, remediation and measures to mitigate adverse effects. |
| Contact | Incident coordinator and the gianlucca.florencio@zeroholding.com.br channel for follow-up. |
06Preparedness
- The contact list, credential rotation steps and restore procedure are documented and kept current so a response does not depend on improvisation.
- A response exercise is performed at least annually, walking through an exposed-credential scenario: rotate the session secret, rotate marketplace credentials, restore a backup and draft the notification.
- The result of the exercise, including gaps found and fixes applied, is recorded as evidence.
07Incident history
No reportable incident in the last three years
In the last three years NEXUS Group has had no security breach that led to accidental or unlawful exposure of personal data requiring notification to a governmental or regulatory authority or to a current or former customer, and has received no complaint or notice from a data protection authority, customer or individual regarding the processing of personal data.
Document control
Public URL: https://v2.nexusgroup.app.br/incident-response.
Approved and maintained by the NEXUS Group Privacy Owner. Reviewed at least annually, and after any material change to the service.