Data Processing Agreement

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, with one exception: a small number of our staff may review calls to check and improve the agent, which section 1 explains.
• We use the sub-processors listed in Annex III and give you 30 days' notice before adding or replacing one, so you can object. We do not yet hold a signed data-protection contract with all of them - section 6 says where we stand.
• 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 delete your organisation or your account, or ask us to, we delete or return your callers' data at your choice, within 30 days. Ending your subscription does not by itself delete it - section 10 explains.

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.

Special-category and criminal-offence data. SwiftGuard has no field for special categories of personal data (Art 9) or for data relating to criminal convictions and offences (Art 10), and is not built to handle them as such. We ask you not to enter such data into the free-text fields yourself, and not to instruct us to process it.

We have to be straight about the limit of that request, because a previous version of this agreement put the whole risk on you and that was not fair. The notes on a caller record, and the transcript of a call, are written by our voice agent from what the caller said - they are not typed by you - and they are not filtered. A caller may volunteer anything, and in this trade they routinely volunteer something about their health or their household in the course of explaining a job. More than that: our agent is asked to note how urgent a job is, including where someone in the household is vulnerable, and to note a job as urgent where a caller describes a gas smell, a suspected gas leak, a carbon monoxide alarm, or symptoms such as headache, dizziness or nausea - because getting an engineer to that address quickly is the point of the service. So this is not only something we tolerate; in that narrow respect it is something the agent is designed to record. That content is written from what the caller said and is not filtered, and it arises from how our service works rather than from anything you did, so we do not treat it as your risk alone. What we ask of you is what you can actually control: what you type, and what you instruct us to do. What we owe you is to say plainly that we have no special-category detection or redaction in place today (see Annex II), and to protect whatever the agent records with the measures in Annex II.

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. It is our obligation to 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).

Stated plainly, because you are entitled to know where we stand rather than to be reassured: we do not yet hold a signed data-protection agreement with every sub-processor listed in Annex III. We are putting them in place. Until one is signed, the protection for that sub-processor rests on that provider's own published terms and on our own liability to you under this section - not on a contract we can send you. On request at [email protected] we will tell you which sub-processors we hold a signed agreement with and which we do not. Our liability to you for each sub-processor's performance is the same either way.

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 owners and administrators of your SwiftGuard account. Please keep those addresses current, because that is where these notices go. Within the notice 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.

One matter of record, because that promise is about notice before a change rather than after it. Our voice platform changed on 19 July 2026, and the Annex III below describes the arrangement as it has stood since that date. Notice of that change was first published on this page in August 2026 - after it took effect, not 30 days before it. We would rather say so than present a corrected Annex III as though the notice period had run. If you would have objected to any sub-processor named in Annex III, the route in this section is open to you now, and we will treat an objection made within 30 days of this revision taking effect as if it had been made in time.

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). We send the caller's audio to our voice platform's European endpoint on every call, and that platform's own terms govern where it processes the audio from there. The short summary of each finished call is written by Mistral, whose contracting entity is inside the EEA; we use it on its standard interface and have not independently verified the region in which it processes the transcript. Speaking back goes to that same European endpoint, except in a language for which we have configured a voice from a provider outside the EEA - Annex III names any such provider, and no language is configured to one today. Some of our sub-processors process caller data outside the European Economic Area ("EEA"), mainly in the United States: the language-model step that decides what the agent says, the telephony that carries and records the call, and our hosting and edge network - see the locations in Annex III. You instruct and authorise these transfers as part of this DPA.

The language-model step happens on every call, not occasionally. Deciding what the agent says next is what makes the agent work, so on every single call the words spoken during that call - together with the details the agent looks up from your caller's own record while the call is in progress, such as the time and short service description of a booking they already have - are sent to a language-model provider in the United States. This is not an exceptional route or a fallback; it is the ordinary path of every conversation. We would rather you read that here than infer it from a table.

What safeguard actually covers a transfer. We have to be accurate about this, and it follows from section 6: we do not yet hold signed data-protection clauses of our own with every provider. Until we do, the safeguard for a transfer is whatever that provider's own published data-protection terms give us, and where those terms incorporate the EU Standard Contractual Clauses (Commission Implementing Decision (EU) 2021/914) those clauses are the safeguard for that transfer. Where a provider states that it is self-certified under the EU-US Data Privacy Framework, we additionally rely on that statement; we have not independently verified any provider's current certification status, and we will not tell you we have. Where the Standard Contractual Clauses do apply to a transfer, they continue to apply if an adequacy decision such as the Data Privacy Framework is suspended or invalidated. You can ask us at [email protected] which safeguard we hold for any sub-processor we engage directly, and we will send you a copy where one exists and tell you plainly where one does not, rather than leaving you waiting.

Assessing a transfer. For each transfer outside the EEA we are working through an assessment of whether the safeguard we rely on is adequate in practice for that provider and that destination, taking account of the law it is subject to, and we keep each assessment in writing. We do not hold a completed assessment for every sub-processor yet. We will make each completed assessment available to you on request, and where you ask for one we have not finished, we will tell you so plainly rather than leaving you waiting.

Demands from public authorities. If a public authority makes a legally binding demand for caller data, we will notify you before we disclose anything, unless the law forbids us from telling you - in which case we will ask the authority to lift that restriction and keep a record of the demand so we can tell you as soon as we are allowed. We will disclose no more than the demand requires.

When a safeguard stops working. If a safeguard for a transfer stops being adequate and we cannot put an alternative in place, we will suspend that transfer. Where a transfer cannot be suspended without stopping part of the service, we will tell you promptly so that you can decide, and you may terminate the affected part of the service under section 6.

One category needs stating honestly. The language-model step is engaged by our voice platform, not by us (see Annex III), so the transfer safeguards for it are the ones our voice platform holds with those providers rather than ones we hold ourselves. We remain fully liable to you for that processing under section 6, and we will tell you what our voice platform has told us about its safeguards - but we cannot send you a copy of a contract we are not a party to.

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 safeguards we hold, so we cannot produce them for you as we can where we contract with a provider directly, and unlike the sub-processors in Annex III this is not a provider we engage at all. 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 and/or delete it and delete existing copies, unless EU or Member State law requires us to keep it (Art 28(3)(g) GDPR). Being clear about what starts that, because it matters: ending or cancelling your subscription does not by itself delete your callers' records. Deletion runs when you delete your organisation or your account in the dashboard, or when you ask us at [email protected] - and you can ask at any time, not only at the end. We will complete deletion of the structured caller records within 30 days of that request; 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 telephony provider, which holds the audio, to delete every call recording behind them. Two limits on that sentence, both stated rather than glossed over. Recordings from calls answered before our voice platform changed in July 2026 were held by our previous provider; that instruction does not reach them, and they are subject to that provider's own retention. And the address lookup cache described in Annex I is not tied to your organisation, so it is not emptied when you leave; each entry expires on its own, 30 days after it was last written.

Separately from account deletion, we delete call recordings 90 days after the call. This covers the recordings our telephony provider holds, which are those of calls answered since our voice platform changed in July 2026; recordings from before that date sit with our previous provider under its own retention, as described above. We should be precise about how, because it matters if it fails: that deletion is performed by a scheduled job of ours, not by an expiry setting at the provider - our telephony provider does not delete recordings by itself. If that job cannot delete a particular recording, the failure is recorded for a SwiftGuard engineer to act on; a failure that stops the job from running at all is recorded only in our operational logs.

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, a caller locked out after repeated failed checks, and a caller let into their record by proving their phone number with a code we texted them - 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 recorded against your organisation, and the entry is marked as redacted. What remains of a redacted entry is the event, the date it happened, and our own internal identifiers for your organisation, for the account that acted and for the record the event concerned - never a name, a phone number, an address or anything said on a call - and the redacted entries then age out on the same 180-day schedule. That redaction does not reach every entry, and the paragraph below says which ones it misses. 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.

There is one gap in that redaction and we would rather tell you than let you assume otherwise. Entries about the account itself rather than about your callers - signing in and out, a failed sign-in, a lockout, creating the account, a two-factor challenge, trusting a browser, linking a Google account, a password reset and email verification - are recorded against the email address that was used, not against your organisation, and our redaction works organisation by organisation, so it does not reach them. Those entries hold an email address, and most hold an IP address and browser or device details. They age out on the same 180-day schedule. The same is true of the entries that record what our own staff did.

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:

• Annex I of this agreement, together with the sub-processor list in Annex III, is our record of the processing we carry out on your behalf (Art 30(2) GDPR). We keep it current, and we will provide it to you or to a supervisory authority on request.
• 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. Sections 4 (confidentiality), 9 (international transfers), 11 (audit and information) and 13 (liability) also survive, for as long as we still hold any caller data or any security-log entry relating to you.

15. Changes to this agreement

We may update this DPA to reflect changes in the service, our sub-processors, or the law. Each version carries the date of the revision it belongs to, and earlier versions stay available; for changes that reduce your rights or our obligations we will give you prior notice on the terms set out in section 15 of our Terms of Service, 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

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 that serves a request - anything that returns caller data to a person - 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. A small number of internal maintenance sweeps run across all organisations at once, for example the scheduled job that deletes call recordings once they reach 90 days; those act on records but return caller data to nobody.
• 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. Qualifications on that code, so it is not overstated: you may mark a browser as trusted, which skips the code on that browser for 14 days at a time, and changing the password or the email address on the account cancels the trusted browsers on it; if you sign in with Google instead, Google's own sign-in stands in place of both the password and the code; and following a verification link we email you - when you first create the account, or when you change the email address on it - signs that browser in directly, because the link arrives in the same inbox the code would. Sessions are database-backed and can be revoked by us; a session expires 7 days after it was last used. 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 are recorded in an append-only application log retained for 180 days. It covers account events (sign-in, sign-out, failed sign-ins, lockouts, password resets, email verification, and billing security events) and caller-facing events: a one-time code texted to a caller; a caller identity check that failed, and a caller locked out after repeated failed checks; a caller let into their record by proving their phone number with a code we texted them; a caller's phone number being confirmed; and a caller record changed by a caller or created, changed or deleted from the dashboard. Succeeding at the postcode-and-house-number check writes no entry. Our internal administration console cannot be reached in the production service at all, so no entry recording a member of our staff opening one of its pages is ever written there; where a member of our staff reaches the underlying systems it is by credential, and the honesty note below says what does and does not govern that. The log never contains passwords, tokens or other secrets. It does contain email addresses, IP addresses, browser or device details, and - where the event concerns a caller - that caller's phone number; section 10 explains what happens to those when you leave.
• 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. Deleting your account is confirmed through a verification link we email you; deleting an organisation is confirmed by typing its name. Either 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 would rather understate these measures than overstate them, so: 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; our operational logs redact secrets but may contain limited personal data such as email, phone or IP addresses; we have no special-category detection or redaction on the notes and transcripts our agent writes (section 3); and the staff review described in section 1 is not yet governed by a separate access control or access log - our internal administration console is a development-only surface that is not reachable in production and does not surface call recordings or transcripts at all, and we will not open that access until the log that records who opened which call is in place.

Annex III - Sub-processors

We engage the following sub-processors to process caller data on our behalf. Deepgram is our voice platform: it listens to the caller, decides what the agent says, and speaks the reply. Its listening runs on Deepgram's European endpoint, so the caller's words are turned into text inside the EEA. Twilio provides the phone numbers the calls arrive on, carries the audio, and is where the call recording is stored - the voice platform does not hold it.

The speaking half of the call needs stating separately, because it is configurable per language. By default the agent speaks with Deepgram's own voices, on that same European endpoint. For a particular language we may instead configure a voice from a provider outside the EEA, where its voice is materially better for that language than the European option; the provider we have in view is ElevenLabs, a speech provider in the United States. Where such a voice is configured, the text of the agent's replies in that language is sent to that provider to be turned into speech; where it is not, no caller data reaches it at all. ElevenLabs is listed below so that you know the possibility exists and can object under section 6 before it does; we will not configure a voice in a language before this revision takes effect, and any other provider we came to use for this would be added to this Annex under the same 30 days' notice.

One step in the middle is worth stating precisely, because it is the one that leaves the EEA on every call and because it is not a direct relationship of ours. To work out what to say next - which it must do on every call, and many times within one - Deepgram passes the conversation to a large language model at Google, falling back to OpenAI if Google is unavailable. We hold no account and send no key of our own for that step: Deepgram routes it and pays for it under its own contracts, so Google and OpenAI are Deepgram's sub-processors rather than ours, engaged by Deepgram to deliver the service we buy from it. We list them all the same, because your callers' words reach them and you are entitled to know where. Separately and directly on our own key, Mistral writes the short summary of each finished call from its transcript.

Where a row above names a provider by its product or brand name, the contracting party is the company that provides it. On request at [email protected] we will tell you the exact legal entity we contract with for any row, and what safeguard we hold for it - see section 6 on where those agreements stand and section 9 on what a safeguard rests on until they are signed.

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 sets out how our sub-processors are bound) 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 where we contract with a provider directly; 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.