Incident response and breach notification

What counts as an incident

An incident is any confirmed or suspected event that compromises the confidentiality, integrity, or availability of data that Doc2iXBRL processes, or any user-impacting outage. This includes unauthorized access to customer data, credential exposure, sub-processor compromise, prompt-injection attacks that leak customer data, full or partial service outages, and successful phishing against Doc2iXBRL staff. Everything else, including ordinary bugs and engineering issues, goes through the regular product triage process and is not covered by this procedure.

Who runs the response

Doc2iXBRL uses a single-commander model. The same person declares incidents, runs the response, signs off on closure, and is the named privacy contact for GDPR correspondence.

Incident Commander

Director

Privacy contact

Director

Reporting email

max@doc2ixbrl.com

Six steps for every incident

The same flow runs for every incident, regardless of size. Small incidents move through the steps quickly; larger ones spend more time at containment and assessment. The Director owns the log, the clock, and the close-out.

1. 01

   Detect

   The trigger is any signal that something may be wrong: automated monitoring alerts from Dependabot, Supabase, Vercel, or Fly.io, a user or customer report, a sub-processor notification, a security researcher disclosure, or internal observation. All signals route to max@doc2ixbrl.com.

2. 02

   Declare

   The Director opens a dedicated incident log. That log is the single source of truth for the response: timeline, decisions, and next actions are all recorded there so the audit trail writes itself.

3. 03

   Contain

   Immediate actions stop ongoing damage: revoke compromised credentials, rotate secrets and API keys (Supabase, OpenRouter, Fly.io), disable affected services, block attacker IPs, quarantine affected data, or roll back to a known-good deployment. Containment comes before full root-cause analysis.

4. 04

   Assess

   Determine scope: which data categories were involved, how many users, which systems. Preserve logs, database snapshots, and session data for forensic review. This is the input for the GDPR notification and the customer communication.

5. 05

   Notify

   Regulator notification runs on the 72-hour GDPR clock (see below). Customer notification runs in parallel when user risk is likely. The Director drafts both communications from the log and sends them.

6. 06

   Resolve & review

   The incident closes once the root cause is fixed, containment is verified, and all notifications are sent. Within five business days the Director writes a post-mortem covering timeline, root cause, customer impact, what we learned, and how to prevent or detect it earlier next time. Post-mortems are archived in the internal compliance vault.

Supervisory authority notification

When a personal data breach is likely to result in a risk to the rights and freedoms of natural persons, Doc2iXBRL notifies the Autoriteit Persoonsgegevens (the Dutch Data Protection Authority) within 72 hours of becoming aware of the breach, as required by Article 33 GDPR. The notification includes the nature of the breach, the categories and approximate number of affected data subjects and records, the likely consequences, and the measures we have taken or propose to take. If the 72-hour window cannot be met, the reason for the delay is documented in the incident log and included in the notification.

Article 33 GDPR

72h

Lead supervisory authority

Autoriteit Persoonsgegevens

URL

autoriteitpersoonsgegevens.nl

Telling affected users

When a breach is likely to result in a high risk to the rights and freedoms of affected users, Doc2iXBRL notifies them without undue delay and in clear, plain language. Notification is sent via email to the account contact and surfaced as an in-product notice on next sign-in. The message explains what happened, which of their data was involved, the likely consequences, the steps we have taken to contain and remediate the issue, and a direct contact point for follow-up questions.

Learning from every incident

Every incident, regardless of size, gets a written post-mortem within five business days. Post-mortems cover timeline, root cause, customer impact, action items, and what we learned about how to prevent or detect similar incidents earlier. Action items are tracked to completion.

How to reach us

If you are a customer, partner, security researcher, or member of the public and you suspect a security incident involving Doc2iXBRL, please email the address below. We acknowledge all reports within 24 hours and begin triage immediately. Do not include production credentials or sample personal data in the first message; we will coordinate a secure channel for those details.