Skip to main content

TrustPages.trustCenter / DPA

TrustPages.dpaTitle

TrustPages.dpaIntro

1. Roles

The customer organization is the data controller for its members’ personal data processed through the SYBA Shield extension and console. SYBA (Syba, Inc. / Syba Europe BV, depending on the account’s billing entity) is the processor, acting only on the controller’s documented instructions — running the product as configured.

2. Subject matter, nature and duration

Processing phishing-relevant signals (URLs, email metadata, screenshots on escalation) to detect and block phishing for the org’s seats, for as long as the subscription is active plus the retention periods on the retention page. The exact fields per tier, their receivers and their retention are enumerated in docs/data-flow-contract.md and summarized at data flow.

3. Categories of data subjects and data

The controller’s employees (seat holders). Account identifiers (work email, name), device check-in counts, reported-phish URLs, and — only when a seat enables the cloud vision tier — a downscaled page screenshot. No categories of special data (Art. 9 GDPR) are processed by design.

4. Sub-processors

SYBA uses the sub-processors listed at subprocessors, rendered directly from the one list this contract is graded against. The controller consents to that list as it stands at the time of signing and to updates SYBA publishes there; material changes affecting an Enterprise contract are notified to the account owner.

5. Security measures

The technical and organizational measures SYBA runs are listed, with the file each one is implemented in, at security.

6. Data subject rights and deletion

SYBA assists the controller in responding to a data subject request. A verified deletion request purges every store enumerated at retention through the account deletion endpoint, revoking the seat and scrubbing audit rows to a hash — never deleting the org’s own billing or last-owner records outright, for the reasons stated on that page.

7. International transfers

Where a sub-processor operates outside the EEA, the transfer relies on that provider’s own Data Processing Addendum incorporating Standard Contractual Clauses. For EU-resident seats, SYBA additionally blocks AI providers with no EU adequacy decision at the routing layer, described on the security page. A signed DPA per sub-processor is an ongoing operational task and is not asserted here as executed for every provider.

TrustPages.dpaRequestTitle

TrustPages.dpaRequestBody