Legal
Data Processing Agreement
In one paragraph
Your company is the controller of the candidate marks your team creates. We are the processor: we store them and give them back to your team, and we do nothing else with them. This document is the Article 28 agreement that says so, and it applies automatically to every customer — you do not have to ask us to sign anything.
1. Parties and scope
Controller: the company that holds the licence. Processor: Renato Vieira Pimpão, Portugal. This agreement covers the personal data processed by Outreach Guard on the controller's instructions, and takes effect when the account is created.
2. Subject matter, duration, nature and purpose
- Subject matter: recording that a candidate has been contacted by the controller's staff, and showing that fact across the controller's licensed PCs.
- Duration: for as long as the account exists. Marks are deleted earlier, automatically, at the end of the controller's chosen expiry window (default 180 days).
- Nature and purpose: storage and retrieval. No profiling, no automated decisions, no enrichment, no analysis beyond counting.
3. Categories of data and data subjects
| Data subjects | Personal data |
|---|---|
| Candidates contacted by the controller's staff | A one-way HMAC-SHA256 hash of the profile reference, computed in the recruiter's browser with a key belonging to the controller. No name, no profile URL, no headline, no message content, no CV, no profile content of any kind. The hash is pseudonymous data: we cannot reverse it, and it only becomes linkable to a person by someone who holds the controller's key and the original reference. |
| The controller's staff (recruiters) | The name each person typed when installing the extension, the label of their PC, a random device id, timestamps of contacts, and per-day contact counts. |
| The controller's administrator | Name of the company, email address, password hash, sign-in IP and user agent. |
No special categories of data (Art. 9) are processed, and none should be sent to us. There is nowhere in the product to type free text about a person.
4. Our obligations as processor
- We process personal data only on the controller's documented instructions, which are these terms and the use of the product itself. If the law forces us to do otherwise, we tell the controller first, unless the law forbids that too.
- Everyone with access is bound by confidentiality.
- We keep the technical and organisational measures listed in section 7.
- We assist the controller with data subject requests, with security incidents, and with impact assessments, as far as the nature of the processing allows.
- On termination we delete everything, including backups, within 30 days — or return it first, if the controller asks before the account is deleted.
- We make available the information needed to demonstrate compliance, and accept audits by the controller or an auditor it appoints, once per year with reasonable notice, or after a security incident.
5. Sub-processors
The controller gives general authorisation for the sub-processors below. We impose the same obligations on them and stay responsible for what they do. If we add or replace one, we announce it on this page at least 30 days beforehand, and the controller may object and terminate if it disagrees.
| Sub-processor | Purpose | Location |
|---|---|---|
| Hetzner Online GmbH | Server hosting and database storage | Falkenstein, Germany (EU) |
| Stripe Payments Europe, Ltd. | Subscription billing and payment data | Ireland (EU), with onward transfers to Stripe, Inc. (USA) under its own safeguards |
6. International transfers
The service and its database run in the European Union (Germany). The only transfer outside the EU is by Stripe, which may process billing data in the United States under its own safeguards (Standard Contractual Clauses and the EU–US Data Privacy Framework). Candidate marks are never transferred outside the EU.
7. Technical and organisational measures (Art. 32)
- Data minimisation by design: the profile reference is hashed in the browser before transmission. The plaintext reference never reaches us, so a breach of our database exposes no candidate identities.
- Per-tenant key separation: each organisation hashes with its own key, so the same candidate produces different values for different customers and records cannot be correlated across them.
- Encryption in transit: HTTPS everywhere, HSTS enabled.
- Access control: every API call is authenticated by licence key plus device id; every query is scoped to one organisation; the database file is readable only by the service account.
- Authentication: scrypt password hashing, signed HttpOnly session cookies, CSRF tokens on every state-changing form, rate limiting and lockout on repeated failures.
- Automatic deletion: marks past the expiry window are physically deleted, and the security log is deleted after 30 days.
- Backups: the database is backed up before each deployment, on the same EU server, and old copies are rotated.
8. Personal data breaches
We notify the controller without undue delay and at the latest within 48 hours of becoming aware of a breach affecting its data, with what we know: what happened, which data, the likely consequences, and what we are doing about it. Notifying the supervisory authority is the controller's call, since the controller is the one who holds the relationship with the data subjects.
9. Data subject requests
Requests from candidates go to the controller, not to us — we cannot identify a person from a hash. The controller can satisfy an erasure request itself, from the dashboard, by clearing the marks. If a candidate contacts us directly, we forward the request to the controller and tell the candidate we have done so.