InfraInbox v0.1 is in development. The self-hosted release and the Cloud beta open on the same day. Sign up for Cloud

InfraInbox
Sign up

Data Processing Agreement

Version 1.0 · Effective 2026-10-05Română

This Data Processing Agreement (“DPA”) meets Article 28(3) of the General Data Protection Regulation (EU) 2016/679 (“GDPR”). It is part of the InfraInbox Cloud Terms of Service (“Terms”) and applies when a customer uses InfraInbox Cloud for a business or organisation. A customer accepts it by accepting the Terms.

Parties

  • The Customer: the business or organisation that uses the InfraInbox Cloud workspace, as controller.
  • INNOVA SOFTWARE S.R.L., Romania, CUI 45402130, Trade Register J30/1284/2021, as processor (“we”, “us”). Contact: contact@innovasoftware.ro.

1. Scope and roles

1.1. Customer Personal Data means personal data in what the Customer’s workspaces receive, store or send in InfraInbox Cloud: events, incidents, raw payloads, heartbeat data, notification content, and the recipient details and credentials set in destinations. We process it only on the Customer’s behalf. Annex I describes the processing.

1.2. We are controller, not processor, for account data (users’ identity, sign-in, sessions, paired devices, the audit log), for security and abuse-prevention data, and for push-delivery data handled by our relay. Our Privacy Policy covers that data; this DPA does not.

1.3. Destinations are the Customer’s choice. Telegram, Slack, Discord, webhooks and other destinations the Customer configures receive what the Customer routes to them, under their own terms with the Customer. They are recipients chosen by the Customer, not our sub-processors.

1.4. If this DPA and the Terms conflict on data protection, this DPA prevails.

2. Instructions (Art. 28(3)(a))

2.1. We process Customer Personal Data only on the Customer’s documented instructions. The Terms, this DPA and the Customer’s own settings in the dashboard and API (sources, rules, routing, destinations, retention, exports and deletions) are those instructions.

2.2. We may process Customer Personal Data otherwise only where EU or Romanian law requires it. We will tell the Customer first unless that law forbids it.

2.3. We will tell the Customer promptly if, in our opinion, an instruction infringes data-protection law (Art. 28(3), second subparagraph).

3. Confidentiality (Art. 28(3)(b))

Everyone we authorise to access Customer Personal Data is bound by confidentiality, by contract or by law, and has access only as far as operating, securing or supporting the service needs.

4. Security (Art. 28(3)(c), Art. 32)

4.1. We apply the technical and organisational measures in Annex II.

4.2. We may change them, provided the overall level of protection does not fall.

5. Sub-processors (Art. 28(2) and (4))

5.1. General authorisation. The Customer authorises the sub-processors listed on our sub-processors page on the date it accepts this DPA.

5.2. Notice of changes. Before a new sub-processor starts processing Customer Personal Data, we update the list with the date and the change, and email every workspace owner at least 30 days in advance.

5.3. Objection. The Customer may object on reasonable data-protection grounds, by email to contact@innovasoftware.ro, within those 30 days. We will try to resolve it, for example by not using the new sub-processor for that Customer. If we cannot, the Customer may close the affected workspaces or end the Terms before the change takes effect, without penalty.

5.4. Urgent replacement. If a sub-processor must be replaced at short notice to protect security or keep the service running, we notify the Customer as soon as possible, and the right to object in 5.3 still applies.

5.5. Flow-down and liability. Each sub-processor is bound by a written contract with data-protection obligations equivalent to this DPA. We remain fully liable to the Customer for each sub-processor’s performance (Art. 28(4)).

5.6. Our push relay (push.infrainbox.app) is our own infrastructure, run by us on our hosting provider; it is not a separate sub-processor.

6. Assistance (Art. 28(3)(e) and (f))

6.1. Data-subject requests. The service lets the Customer handle most requests itself: export a workspace as JSON, delete a workspace, and shorten retention. If a data subject sends us a request about Customer Personal Data, we pass it to the Customer without undue delay and do not answer it ourselves, except to say we have forwarded it.

6.2. Security, impact assessments, prior consultation. We help the Customer meet Arts. 32–36 GDPR with the information we have, including this DPA, Annex II and the sub-processor list.

7. Personal data breaches (Art. 28(3)(f), Art. 33(2))

7.1. We notify the Customer of a personal data breach affecting Customer Personal Data without undue delay, and within 48 hours of becoming aware of it, by email to the workspace owners.

7.2. The notice gives what Art. 33(3) GDPR asks for, as far as we know it then, and we add to it as we learn more.

7.3. We take reasonable steps to contain the breach and limit its effects. Telling the Customer is not an admission of fault.

8. Transfers outside the EEA (Art. 28(3)(a), Chapter V)

8.1. Customer Personal Data is stored and backed up in Germany.

8.2. Push to iPhones. The only processing of Customer Personal Data outside the EEA is the delivery of push notifications to iPhones, which only Apple’s push service (Apple Inc., US) can do.

  • Each notification is end-to-end encrypted (RFC 8291) with keys that exist only on the recipient’s phone. Our relay and Apple receive ciphertext they cannot read. For Apple this content is not personal data (CJEU, C-413/23 P, EDPS v SRB, 4 September 2025), and the encryption is the supplementary measure the EDPB recommends for data that passes through a third country without being readable there (Recommendations 01/2020).
  • The push token and delivery metadata that reach Apple belong to the user’s own device registration, which we handle as controller, with the user’s explicit consent in the app (Privacy Policy §5).
  • The Customer instructs this processing by using the built-in InfraInbox Push destination, and can stop it by disabling that destination.

8.3. Any other transfer happens only after notice under clause 5, and only under an adequacy decision (Art. 45), including the EU–US Data Privacy Framework for certified recipients, or the standard contractual clauses (Commission Implementing Decision (EU) 2021/914, Module 3) with any supplementary measures needed.

8.4. If the Data Privacy Framework is invalidated (appeal C-703/25 P is pending), we put standard contractual clauses in place for any recipient that relied on it, or stop the transfer.

9. Information and audits (Art. 28(3)(h))

9.1. On request, we provide what the Customer needs to show compliance with Art. 28: this DPA, Annex II, the sub-processor list, and a written answer to a reasonable security questionnaire once a year.

9.2. We hold no security certification or third-party audit report.

9.3. Audits. If 9.1 is not enough, the Customer, or an independent auditor bound by confidentiality, may audit our compliance with this DPA on 30 days’ written notice, at most once a year unless a breach or a supervisory authority requires more, during business hours, without access to other customers’ data, and at the Customer’s cost. Audits of our hosting provider’s data centres go through that provider’s own audit terms.

10. Return and deletion (Art. 28(3)(g))

10.1. Export. The Customer can export each workspace as JSON at any time. Only an owner can, after confirming their identity.

10.2. Deletion. When a workspace is deleted, or closed because its only owner deleted their account, its Customer Personal Data is deleted at the next hourly clean-up, and at the latest within 30 days; backup copies age out within 35 days. We keep no copy unless EU or Romanian law requires us to.

11. Duration, liability, law

11.1. This DPA lasts as long as we process Customer Personal Data.

11.2. Liability follows the Terms. Article 82 GDPR governs liability towards data subjects.

11.3. This DPA is governed by Romanian law. The competent courts for INNOVA SOFTWARE S.R.L.’s registered office have jurisdiction.

11.4. We may update this DPA with 30 days’ notice by email. A change may not lower the protection of Customer Personal Data unless the law requires it.

Annex I — Details of the processing
Subject matter Running InfraInbox Cloud for the Customer: receiving infrastructure alerts and turning them into incidents and notifications
Duration The term of the Terms, plus the deletion periods in clause 10
Nature Receiving (HTTPS API, webhooks, heartbeats); parsing and redacting; storing; grouping into incidents; evaluating the Customer’s rules; delivering to the Customer’s destinations and paired phones; exporting and deleting on request
Purpose Providing the service as the Customer configures it. No other purpose
Data subjects The Customer’s staff and contractors; users of the Customer’s systems; anyone named in the alerts the Customer’s tools send
Personal data Whatever the Customer’s tools put in alerts, typically hostnames, IP addresses, usernames, email addresses, names in alert text, job and backup details. Also destination recipient details (chat IDs, webhook URLs) and destination credentials
Special categories None intended. The Customer must not send special-category data (Art. 9) or criminal-offence data (Art. 10)
Retention Unless the Customer sets shorter periods: events 30 days; incidents 90 days after resolution (open incidents are kept); delivery records 30 days; raw payloads the last 20 per source for 7 days, at most 64 KB each; heartbeat pings the last 100 per check plus 90 days of daily summaries; idempotency keys at least 24 hours. Enforced by an hourly purge
Sub-processors The sub-processors page, section A

Annex II — Technical and organisational measures (Art. 32)

1. Encryption

  • All traffic uses TLS 1.2 or later. HSTS is set for one year.
  • Stored credentials (destination tokens and passwords, two-factor secrets) are encrypted with AES-256-GCM. Each secret has its own data key, wrapped by a master key kept outside the database in a file readable only by the service, with an offline copy held by the company. The ciphertext is bound to its workspace, table, row and field.
  • Push notifications are end-to-end encrypted (RFC 8291) for the recipient’s phone. The relay and Apple see only ciphertext.
  • Backups are encrypted at rest (AES-256) by the hosting provider.

2. Access control: users

  • Passwords: 15 to 256 characters, checked against a blocklist and against the user’s own name and email; hashed with Argon2id.
  • Two-factor authentication: TOTP with a replay guard, required for every workspace owner. Ten single-use recovery codes, stored hashed.
  • Sessions: __Host- cookies that are Secure, HttpOnly and SameSite=Strict, ending after 7 days unused or 30 days in total; tokens stored only as hashes.
  • Re-authentication: a password or second factor proved in the last 10 minutes is required before a workspace export or deletion, account deletion, an email change, member changes and two-factor changes.
  • Sign-in throttling: per IP address, and per account and IP, with exponential back-off after 5 failures. Sign-up is rate-limited per IP address.
  • Phones: 15-minute access tokens and rotating refresh tokens; reusing a refresh token revokes the whole token family; all tokens stored hashed.
  • Ingest keys: shown once, stored only as SHA-256 hashes. A replaced key stops working after 24 hours.

3. Separation between customers

  • Every query is scoped to a workspace in the application; the workspace comes from the credential, never from the request.
  • As a backstop, PostgreSQL row-level security is enabled and forced on every table that holds workspace data. The application’s database login cannot bypass it.

4. Web application security

  • Cross-site request forgery protection (Fetch Metadata and Origin checks) and no cross-origin API access.
  • Content Security Policy with nonces and Trusted Types; frame-ancestors 'none'; Referrer-Policy: no-referrer; API responses are not cached.

5. Minimisation

  • Raw payloads: authorisation headers, cookies and credential-like fields are removed before storage; payloads are cut to 64 KB and kept 7 days; requests without a valid key are never stored.
  • Logs: secrets, tokens and alert content are never written to service logs. Logs are kept 14 days (relay: 7 days).
  • Audit log: IP addresses are shortened after 90 days.
  • No third-party observability: no external analytics, crash-reporting or monitoring service receives data.

6. Accountability

  • An append-only audit log records sign-ins and failures, key, rule, destination and member changes, pairing, device revocation, exports, deletions and retention changes, with actor, time, IP and outcome. The application can add entries but not change or delete them. Entries are kept for 1 year.

7. Availability and resilience

  • A daily automatic backup of the whole server, kept 72 hours locally and 30 days in a separate data-centre building in Germany.
  • Daily quotas and rate limits per workspace protect the service from overload and abuse.

8. Organisation

  • Production access is limited to named people using personal SSH keys; the hosting account uses two-factor authentication.
  • A written breach procedure covers the 72-hour notice to the supervisory authority (ANSPDCP) and this DPA’s 48-hour notice to customers.
  • A written contract meeting Art. 28 GDPR is in place with every sub-processor.

9. Deletion

  • Retention purges run hourly in small batches.
  • Deleting an account erases its personal data at once; deleted workspaces are removed within 30 days; backup copies age out within 35 days.

Version 1.0, effective 5 October 2026.