Data Processing Agreement (archived 14 July 2026)

This document has not been reviewed by a lawyer. Questions? Email [email protected].

This is an archived version from 14 July 2026, kept for reference. It is not the version that applies now. Read the current version

It was in force from 14 July 2026 until 7 September 2026.

This Data Processing Agreement ("DPA") governs how SwiftGuard AI processes the personal data of your callers on your behalf when you use SwiftGuard. It gives effect to Article 28 of the EU General Data Protection Regulation ("GDPR"). It forms part of, and is incorporated into, our Terms of Service (the "Agreement"), and you accept it electronically when you create an account. Where this DPA and the Terms conflict on the processing of caller data, this DPA prevails. A countersigned copy is available on request at [email protected].

In short

For the personal data of your callers, you are the controller and we are your processor. We process it only to provide the service and only on your instructions.
We use vetted sub-processors (listed in Annex III) and give you 30 days' notice before adding or replacing one, so you can object.
We protect the data with the technical and organisational measures in Annex II, keep our staff under confidentiality, and help you meet your GDPR duties.
If a breach affects your callers' data, we tell you without undue delay and in any event within 48 hours of becoming aware of it.
When you leave, we delete or return your callers' data at your choice, within 30 days.

1. Parties, roles and precedence

This DPA is between you, the business that holds a SwiftGuard account (the "Controller", "you"), and SwiftGuard AI, the registered name of a Dutch sole proprietorship (eenmanszaak) run by Daan van den Bergh, registered with the Netherlands Chamber of Commerce (KvK) under number 75538288, at Ensahlaan 25, 3723 HT Bilthoven, The Netherlands (the "Processor", "we", "us").

We act as your processor only for the personal data of your callers described in Annex I. For your own account, security and billing data we are a separate controller; that processing is governed by our Privacy Policy, not this DPA. With one exception, we do not process caller data for our own purposes: a small number of our staff may listen to call recordings and read transcripts in order to check and improve how the voice agent handles calls. For that limited purpose we determine the purpose ourselves, so we act as a controller for it and are responsible for it accordingly (Art 28(10) GDPR), on the basis of our legitimate interest in making the agent accurate and safe. Our Privacy Policy explains it and tells callers how to object. Outside that exception, if we ever determined the purposes and means of processing caller data, we would likewise be a controller for that processing.

That exception is limited to reviewing and improving the agent. We do not use caller data to train AI models, and we do not use it for any other purpose of our own.

2. Definitions

"Caller data" means the personal data of your callers that we process on your behalf, as set out in Annex I. "Data subject", "personal data", "processing", "controller", "processor", "sub-processor" and "personal data breach" have the meanings given in the GDPR. "Callers" means the people who telephone your business and speak with the agent, and other individuals whose data appears in the caller records you keep in SwiftGuard.

3. Scope and your documented instructions

We process caller data only on your documented instructions, including on transfers to a third country, unless EU or Member State law requires otherwise - in which case we will tell you of that legal requirement before processing, unless the law prohibits it on important grounds of public interest (Art 28(3)(a) GDPR).

Your documented instructions are: this DPA and the Agreement; the way you configure and use SwiftGuard (including how you set up call answering, recording and the caller records you create and keep); and any further written instructions you give us. You confirm that these instructions are lawful, that you have a valid legal basis for the caller data you ask us to process, and that you are responsible for telling callers they are speaking with an automated assistant and, where required, that the call is recorded, and for obtaining any consent the law of each country you take calls in requires.

No special-category or criminal-offence data. SwiftGuard is not designed to process special categories of personal data (Art 9) or data relating to criminal convictions and offences (Art 10). You must not enter such data into free-text fields (for example the notes on a caller record) or instruct us to process it, and you do so at your own risk.

4. Confidentiality

We ensure that everyone authorised to process caller data - our staff and any contractors - is bound by an appropriate duty of confidentiality, whether by contract or by statute, and that access is granted only on a need-to-know basis (Art 28(3)(b) GDPR).

5. Security

Taking into account the state of the art, the costs of implementation and the nature, scope, context and purposes of processing, as well as the risks to your callers, we implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk, as required by Article 32 GDPR. Those measures are described in Annex II. We may update them from time to time provided the overall level of security is not reduced.

6. Sub-processors

You give us general written authorisation to engage the sub-processors listed in Annex III to help us provide the service. We impose on each sub-processor, by written contract, the same data-protection obligations as those set out in this DPA, and we remain fully liable to you for the performance of each sub-processor's obligations (Art 28(2), (4) GDPR).

Before we add or replace a sub-processor, we will give you at least 30 days' advance notice by updating Annex III on this page and by emailing the contact you nominate for such notices. Within that period you may object on reasonable data-protection grounds. We will work with you in good faith to address your objection; if we cannot, you may terminate the affected part of the service.

7. Assisting you with data-subject requests

Taking into account the nature of the processing, we assist you by appropriate technical and organisational measures, insofar as this is possible, to respond to requests from your callers to exercise their GDPR rights - access, rectification, erasure, restriction, portability and objection (Art 28(3)(e) GDPR). Because you are the controller of caller data, if a caller contacts us directly we will not respond to the substance of the request but will forward it to you without undue delay and help you respond. Our help with routine requests is included in the service; for manifestly unfounded, excessive or repetitive requests we may charge a reasonable fee.

8. Assisting you with security, breach notification and DPIAs

Taking into account the nature of processing and the information available to us, we assist you in ensuring compliance with your obligations under Articles 32 to 36 GDPR (Art 28(3)(f)). In particular, if we become aware of a personal data breach affecting caller data, we will notify you without undue delay and in any event within 48 hours of becoming aware of it. Our notice will describe, to the extent known, the nature of the breach (including the categories and approximate number of data subjects and records concerned), its likely consequences, and the measures we have taken or propose to take; where the full picture is not yet available, we will provide information in phases. We will cooperate with you and take reasonable steps to mitigate the breach, and we will assist you with data protection impact assessments and any prior consultation with a supervisory authority.

9. International transfers

We store the core database that holds your callers' records in the European Union (Frankfurt). Some of our sub-processors process caller data outside the European Economic Area ("EEA"), mainly in the United States - see the locations in Annex III. For those transfers we rely on the EU Standard Contractual Clauses (Commission Implementing Decision (EU) 2021/914, using the processor-to-processor module) as the primary safeguard, and, where a sub-processor is self-certified, additionally on the EU-US Data Privacy Framework. If an adequacy decision such as the Data Privacy Framework is suspended or invalidated, the Standard Contractual Clauses continue to apply to that transfer. You instruct and authorise these transfers as part of this DPA. You can request a copy of the safeguards for any sub-processor at [email protected].

One transfer sits outside the above. If you connect a Google Calendar (see Annex III-A), the booking data we write travels to Google's infrastructure, including in the United States, under your own agreement with Google and Google's own safeguards - not under Standard Contractual Clauses we hold, and so it is the one transfer for which we cannot send you a copy of the safeguards. You instruct that transfer by connecting the calendar, and you end it by disconnecting the calendar or revoking our access in your Google account.

10. Deletion or return at the end of the service

On termination of the Agreement, or at any time on your request, we will - at your choice - return the caller data to you in a structured, commonly-used and machine-readable format (which we may provide as a data export) and/or delete it and delete existing copies, unless EU or Member State law requires us to keep it (Art 28(3)(g) GDPR). We will complete deletion of the structured caller records within 30 days of termination; any residual copies in platform backups are removed on the backup platform's normal rotation cycle. When you delete your account, we delete your callers' records held in the service - transcripts and summaries included - and at the same time instruct our voice platform to delete every call recording behind them. We have also configured that platform to delete recordings 90 days after the call in any event. On request, we will confirm deletion in writing.

One limit, stated plainly: appointments we have written into a calendar you connected (see Annex III-A) are in your own Google account, not ours. We delete the stored token and, where we still can, ask Google to revoke our access - but we do not delete the appointments themselves - they are yours, and your business needs them. If you want them gone, delete them in your calendar.

One record we keep rather than delete, and we keep it with the personal data taken out of it: our security event log. It records what happened to your account - sign-ins and failed sign-ins, lockouts, one-time codes texted to a caller, failed identity checks on a caller's record - and it is kept for 180 days from the event. When your account is deleted we do not delete those entries; we redact them. The caller's phone number, and any email address, IP address and browser or device details, are removed from every entry belonging to you, and the entry is marked as redacted. The event and the date it happened remain; nothing that identifies a person does, and the redacted entries then age out on the same 180-day schedule. We do it this way for two reasons: a security trail that is destroyed whenever an account is deleted is not a security trail - it must still be able to show whether your business was under attack at the moment it was closed - and the caller behind such an entry, who is a customer of yours and not of ours, has no business remaining in our database once you are gone.

11. Audit and information

We make available to you all information necessary to demonstrate our compliance with Article 28 GDPR, and we allow for and contribute to audits, including inspections, conducted by you or an auditor you mandate (Art 28(3)(h) GDPR). In practice:

For routine assurance, we will provide documented information about our measures, respond to a reasonable security questionnaire, and share any third-party audit reports or certifications we then hold.
Where that is not sufficient, or after a personal data breach or an indication of non-compliance, you (or an independent auditor you mandate who is not our competitor) may inspect our processing, on at least 30 days' written notice, at most once a year absent good cause, during business hours, subject to confidentiality, and without access to any other customer's data. Each party bears its own costs.

12. Infringing instructions

We will immediately inform you if, in our opinion, an instruction infringes the GDPR or other EU or Member State data protection law. We may suspend the affected processing until the instruction is confirmed, changed or withdrawn (Art 28(3), final subparagraph).

13. Liability

Each party's liability under this DPA is subject to the limitations and exclusions of liability in the Agreement. Nothing in this DPA limits any liability that cannot be limited under applicable law, and nothing limits the rights of data subjects to compensation under Article 82 GDPR, under which each of us is liable only for the processing for which we are responsible.

14. Term

This DPA takes effect when you accept the Agreement and continues for as long as we process caller data on your behalf, after which the deletion or return obligations in section 10 survive until performed.

15. Changes to this agreement

We may update this DPA to reflect changes in the service, our sub-processors, or the law. We will change the "Last updated" date above; for changes that reduce your rights or our obligations we will give you reasonable prior notice, and for sub-processor changes we follow the 30-day notice process in section 6.

16. Contact

Data protection and DPA requests: [email protected] · SwiftGuard AI, Ensahlaan 25, 3723 HT Bilthoven, The Netherlands. We have not appointed a Data Protection Officer, as our current processing does not require one.

Annex I - Description of the processing


Subject matter	Our provision of the SwiftGuard voice-agent platform to you, and the processing of your callers' personal data needed to run it.
Duration	The term of the Agreement, plus the deletion or return window in section 10.
Nature and purpose	Answering and handling inbound telephone calls to your business; recording and transcribing calls; conversational AI processing to understand and respond to the caller; capturing and storing caller and job details; asking a caller for the postcode and house number held on their record, checking whether their phone number can receive a text message, and texting them a one-time code, to check they are who they say they are before we look up their record, create a record for them, or change one of their bookings; scheduling appointments; and making records of calls and callers available to you - all to provide the service on your instructions. Separately, and for our own purpose rather than on your instructions, our staff may review call recordings and transcripts to check and improve how the voice agent handles calls (see section 1); we act as a controller for that limited processing.
Types of personal data	Caller phone number (in E.164 format), name, optional email address, service addresses, a relationship label you assign (for example lead, active or inactive), and free-text notes about the job; the postcode and house number the caller states as their identity check, which we store separately from their service addresses because they answer "who are you" rather than "where does the van go"; whether the caller's number is a mobile that can receive a text, the one-time code we text to it when the caller's number has to be confirmed, and the date on which that number was confirmed; and the call itself - the audio recording, which is held by our voice platform (we keep no copy of the audio), together with the written transcript and an AI-written summary of the call, which we do store in our own database. The free-text notes are written by the voice agent from what the caller said and are not filtered, so they can contain any personal data the caller mentioned - including, in practice, details about their home and household. The transcript, likewise, contains whatever the caller said. See section 3 on special-category data.
Categories of data subjects	Your callers - your customers, prospective customers, and other individuals who telephone your business or whose details you record in SwiftGuard.
Controller obligations and rights	You determine the purposes and means of processing caller data and are responsible for a lawful basis and for caller notices and consents (section 3). You hold the rights to give instructions and to authorise or object to sub-processors, to receive assistance, to audit, and to require deletion or return, as set out in this DPA.
Frequency	Continuous, for the duration of the Agreement.
Retention	A one-time code is never stored in a readable form, expires within five minutes, and is deleted the moment it is used. To stop the same number being texted over and over, and to stop the postcode-and-house-number check being guessed at, we count those attempts against the caller's phone number; that counter contains the number itself, is deleted automatically within two days of the last attempt, and deliberately outlives the caller's own record - without it, deleting a record would buy a fresh set of text messages and a fresh set of guesses. Structured caller records are kept until you delete them or close your account - you control how long they are kept. Call recordings, transcripts and summaries are retained for 90 days and then deleted automatically: the recording by our voice platform, which holds it on our behalf, and the transcript and summary by us. Our security event log is retained for 180 days from the event, including where the event concerns a caller (a code we texted them, a failed identity check on their record); on termination it is not deleted but redacted - the caller's phone number, and any email address, IP address and browser or device details, are removed from every entry belonging to you, leaving the event and its date and nothing that identifies a person (section 10). On termination, the caller data we hold is deleted or returned under section 10 - with the one exception set out there and in Annex III-A: appointments already written into a calendar you connected stay in your own calendar, under your control.

Annex II - Technical and organisational measures

We apply the following measures to protect caller data (Article 32 GDPR). We list only measures actually in place; we will add to them as the service matures.

Encryption in transit and at rest. Personal data is encrypted in transit using TLS (HTTPS at the network edge and TLS connections to the database). It is encrypted at rest using the storage-level encryption of our database provider (MongoDB Atlas).
Tenant isolation. Every caller record is scoped to your organisation and every read and write is filtered by your organisation identifier in our data-access layer, backed by a per-tenant uniqueness constraint in the database, so one customer's data is not accessible to another.
Access control and authentication. Access to accounts requires a verified email, a password of at least 8 characters stored only as a one-way hash (scrypt), and a one-time code sent by email at sign-in; staff accounts require a password of at least 12 characters. Sessions are database-backed and revocable with a 7-day expiry; accounts are locked after repeated failed sign-ins; sign-in and other sensitive endpoints are rate-limited; session cookies are HTTP-only and secure. Access is on a least-privilege basis.
Security logging. Security-relevant actions (sign-in, sign-out, failed sign-ins, lockouts, password resets, email verification, and billing security events) are recorded in an append-only application log retained for 180 days. The log never contains passwords, tokens or other secrets.
Secrets management. Credentials and API keys are held in a single validated configuration source, kept out of client-side code, redacted from logs, and scoped to least privilege where the provider supports restricted keys. Secrets are not hard-coded in our code.
Resilience and backups. The database runs on a managed, replicated cluster (MongoDB Atlas), and we use the database platform's managed backups on our production plan.
Deletion and data lifecycle. Account deletion is confirmed through an emailed verification link and cascades to remove caller data across the service; transient security data expires automatically on a timer; caller data is deleted on request.
Testing and review. We carry out periodic internal security reviews of the codebase.
Organisational measures. Personnel and contractors with access are bound to confidentiality (section 4) and access is granted on a need-to-know basis.

Honesty note for reviewers: we do not currently apply application-level field encryption to stored caller data (only provider storage-level encryption at rest); our security log is append-only by application design but is not cryptographically tamper-proof; and our operational logs redact secrets but may contain limited personal data such as email, phone or IP addresses. This is stated so the measures are not overstated.

Annex III - Sub-processors

We engage the following sub-processors to process caller data on our behalf. ElevenLabs is our voice platform: it answers the call, listens, speaks, writes the transcript and holds the recording. To understand the caller it passes the conversation to OpenAI's language model, using a key we hold with OpenAI - so OpenAI is reached through the voice platform rather than called by us directly. Twilio provides the phone numbers the calls arrive on.

Sub-processor	Purpose	Caller data processed	Location / transfer safeguard
ElevenLabs	Voice platform - answers, records and transcribes calls, speaks to the caller, and stores the recording	Call audio, transcripts, phone numbers and details spoken on the call	United States - EU SCCs (and EU-US Data Privacy Framework where certified). Configured to delete call recordings after 90 days. Its model-training terms for business customers are set by a data processing agreement we have not yet signed - see section 10 of our Privacy Policy
OpenAI	Language model - understands the caller and decides what the agent says (reached by the voice platform, using our key)	What is said on the call, as it happens	United States - EU SCCs (and DPF where certified). OpenAI states that API data is not used to train its models unless the customer opts in; we have not opted in
Twilio	Telephony - call connectivity and phone numbering, and checking whether a phone number can receive a text message	Caller phone numbers and call audio in transport	United States (with EU telephony) - EU SCCs (and DPF where certified)
GatewayAPI	Text messages - sends the one-time code that verifies a caller's phone number is really theirs, before we create a record for them or change one of their bookings	The caller's phone number and the one-time code texted to it - no name, address, transcript or other call content	European Union (GatewayAPI ApS, Denmark) - within the EEA, sent via its EU host, so no transfer outside the EEA
HERE Technologies	Address lookup - turns the address a caller gives (or you type) into a precise street address and location, so the job is booked at the right door	The address text itself (street, house number, postcode, city) - no name, phone number, transcript or other call content	European Union (HERE Global B.V., the Netherlands) - EU SCCs for any processing outside the EEA
MongoDB Atlas	Database hosting - stores structured caller records	All stored caller personal data	European Union (Frankfurt, eu-central-1) - within the EEA
Railway	Application hosting - runs the service that processes caller data	Caller data in transit and in use	European Union or United States - EU SCCs where outside the EEA
Cloudflare	Edge network, CDN and security (WAF)	Traffic and IP addresses, including caller data in transit	Global edge network - EU SCCs (and DPF where certified)

Our payment provider (Stripe) and transactional-email provider (Resend) process your own account and billing data, where we act as controller - not your callers' data - so they are covered by our Privacy Policy rather than this DPA.

Annex III-A - Integrations you connect

Google Calendar. If - and only if - you choose to connect a calendar, we read your busy times (so the agent offers only slots you are free), write each confirmed appointment into your calendar, and remove the event again if the appointment is cancelled. This is not a sub-processor we engage: it is your own Google account, and you hold your own agreement with Google. We reach it with a refresh token that you grant us and can withdraw at any time. Section 6 above (which binds our sub-processors by written contract) therefore does not apply to Google: Google acts under your agreement with Google, not under this DPA, and by connecting the calendar you instruct us to disclose the booking data below to it.

The access you grant: Google asks you to allow two permissions - to see your calendar, and to create and change events on it. That is what the connection can technically do, and it is broader than what we use it for. What we actually do with it: read which calendar it is and its timezone (once, when you connect), read your free/busy times so the agent only offers slots you are free, create the appointments the agent books, and delete an event again when its appointment is cancelled or when we have to clean up an event we created in error. You can review or withdraw the permissions at any time in your Google account.

What we write into the event: the appointment time, the job address, and the free-text service description and notes taken on the call. There is no field for the caller's name, phone number or email, and we send none - but the address itself identifies the caller, and the description and notes are written by the voice agent from what the caller said. The agent is asked to record the urgency and any other detail about the job, and that text is not filtered before it reaches Google, so it can contain identifying and sometimes sensitive information about the caller and their home.

Where it goes: Google processes this data on its own global infrastructure, including in the United States, under your agreement with Google and Google's own transfer safeguards - not under safeguards we hold. Google states that Google LLC is certified under the EU-US Data Privacy Framework and that it relies on the EU Standard Contractual Clauses where a transfer is not covered by an adequacy decision. Because the calendar is yours, we cannot produce transfer safeguards for Google on request as we can for the sub-processors in Annex III; you can review Google's terms in your own Google account.

When it ends: if you disconnect the calendar or delete your SwiftGuard account, we delete the stored token and, where we still can, ask Google to revoke our access - you can also revoke it yourself at any time in your Google account, which is the certain way. Appointments we have already written stay in your calendar. We deliberately do not delete them - they are yours, and your business needs them - so if you want them gone, delete them in your calendar.

This Data Processing Agreement is a code-verified draft pending legal review; it is not legal advice. A qualified lawyer must review it before it is treated as final.