Know-how
The most effective protection for appointment data is not to pass it on in the first place, and for a calendar that is meant to prevent double bookings, start and end are enough.
When the protection of calendar data is discussed, it is mostly about the how, that is encryption, access rights, server locations and passwords. These are important questions, but they all presuppose that the data already lies somewhere, and they overlook a possibility that is simpler and more effective than any protective measure, namely not having the data in the first place.
This principle is called data minimization, and it is no invention of data protection officers but a sober look at what is necessary for a purpose. Anyone who keeps several client calendars can apply it to a single question, namely what one calendar needs to know about the appointment in the other so that nobody books into your time there.
The answer has nothing to do with your client, the topic and the participants, and that is why it is worth looking closely, once, at why an anonymous block is enough and why it protects more than some calendar shares.
Data minimization starts with an order that in everyday work often runs the other way round, because the purpose comes first and only afterwards is it decided which data is needed for it. The General Data Protection Regulation has laid this down as the principle of data minimization, under which personal data must be adequate, relevant and limited to what is necessary, and in Article 25 it requires systems to be designed from the outset so that only the data necessary for each specific purpose is processed.
Transferred to calendars, the purpose of an entry in the second or third calendar is clearly defined, because it is meant to prevent an appointment from falling into a time you have already given away. That is a question of availability and not of content, and the necessary data shrinks to the start and end of the period.
An appointment looks harmless as long as you look at it on its own, but calendars tell stories in context. The title names the project, the participant list the counterpart, the location the site and the frequency of appointments the intensity of a collaboration, and whoever collects this information over weeks can read off quite precisely what a company is working on and with whom.
An example makes this tangible. If a calendar that a client can see shows an appointment on three Wednesdays in a row from ten to twelve with the name of a project that the client knows and that is not theirs, nobody needs to read the participant list to know that you work for a competitor. The title alone gives it away, and at that moment it has long left the job it was meant for, because it was supposed to serve you and now serves someone who should not read it.
For consultants this is not only a data protection topic but also a contract topic, because many framework agreements treat not only the content of the work but the very fact of the collaboration as confidential. If an appointment of one client shows up in the calendar of another, that can therefore already be a breach of a confidentiality agreement, and not only in the event of a data leak but at the moment the entry lies there.
The usual counter-proposal is to share calendars in such a way that only “free” and “busy” are visible, and indeed Outlook and Google offer such an availability share. It has two catches, though. The first is that both sides have to play along, because every calendar that is meant to see your availability needs access to another calendar, and this is exactly the access that companies almost never give to external specialists.
The second catch is quieter, because the level of the share is a setting that can be changed, for instance by an administrator who sets the default share to more detail, or by you yourself if you pick the wrong option in a hurry. A share therefore protects only as long as the setting is right, whereas a block that never contained the details cannot be set wrongly in the first place.
The principle can be put into a few questions that you can ask yourself before every transfer of appointment data, and the answers turn out surprisingly clear once you have said them out loud.
With availability information almost nothing is left after the first question, and the second and the third settle themselves, because there is no content that could be lost or misused.
The greatest advantage of minimization shows where the risk otherwise lies, namely in loss, misuse and disclosure requests. A record that does not exist cannot be stolen, does not have to be deleted and shows up in no answer to an inquiry, and it also causes no effort for contracts, audits and evidence that otherwise come with its processing.
How little a block contains can be listed quickly: a label, namely “Blocked”, plus start and end, an identifier of its own, the marking as busy and the Butler as sender, but neither the name of your client nor any trace of the original appointment. Because the block carries an identifier of its own, the Butler can follow it when the appointment is postponed or cancelled, and because nothing else is inside it, there is nothing that could be changed or sent along by mistake.
Calendar Butler is built on this principle. It reads an invitation once, takes date and time from it and creates a neutral block in the other calendars that is simply called “Blocked”. Appointment content, participants and locations are neither transmitted nor stored in the process, and this is not a protective layer added afterwards but the consequence of the decision not to process them at all.
The obvious objection is that a block without context is impractical because later you no longer know what the time was reserved for. That is true for a calendar that serves as a memory, and that is why your own calendar keeps all the details, because that is where they belong. The other calendars serve a different purpose, they are meant to protect your time, and for this purpose the missing context is not a gap but exactly the desired property.
Not even a block is entirely free of information, though, because it shows that you are unavailable at a certain time. That is the minimum information every calendar needs, and it cannot be reduced any further without missing the purpose.
What is never stored can never leak.
Calendar Butler
In the end, data minimization is less a technique than an attitude that can be carried over to other areas, and it is worth checking where in your working day you hand over more than the purpose demands, just because it is easier to send everything along than to think about what is needed.
Calendar Butler reserves your appointments in every client calendar and keeps your data protected.
Try free for 30 days
Calendar Butler