Calendar Integration Security: Questions to Ask

Your calendar is more sensitive than it looks

Connecting a calendar to a scheduling tool takes a few seconds. The consent screen appears, someone clicks "Allow", and the tool starts showing availability.

What was just shared is often more than anyone intended. A work calendar contains meeting titles like "Acquisition discussion — Project Falcon", attendee lists that reveal who is talking to whom, dial-in codes, attached documents, and notes in event descriptions. For a sales team it may contain every customer and prospect conversation. For an executive it may contain the most confidential information in the company.

None of this means you should avoid scheduling tools. It means the connection deserves the same review as any other system that touches sensitive data. These are the questions worth asking — of any vendor, including us.

What access is the tool asking for

The first question is the most concrete: what permissions does the integration request, and does it need all of them?

Calendar platforms offer different levels of access, and a well-designed tool asks for the least it needs:

• Free/busy only. The tool can see when you are busy but not what the events are. This is enough to offer available slots. Google Calendar offers a dedicated free/busy scope, and Microsoft 365 offers read access to basic event information that excludes bodies and attendee details.
• Read events. The tool can see event titles, descriptions, attendees, and locations. Useful for some features, and a meaningful step up in exposure.
• Read and write events. Needed if the tool creates calendar entries for confirmed meetings. Ask whether it can write without reading everything.
• Access to other people's calendars. Some integrations request organisation-wide access through an administrator. This is powerful and occasionally necessary; it should be a deliberate decision by your IT team, not a side effect of one person connecting their account.

Ask the vendor to explain in plain language why each permission is needed. "It makes setup easier" is not a strong answer for read access to every event in your organisation.

It is also worth knowing that Google classifies calendar scopes as sensitive and requires apps requesting them to complete an OAuth verification process. A vendor that has done this can tell you so; one that shows an "unverified app" warning has not.

What is stored, and for how long

Reading a calendar and storing a calendar are very different things.

Questions to ask:

• Does the tool store event details, or only compute availability on demand? Some tools copy your calendar into their database to make things faster. That copy is now another place your data lives.
• If data is stored, is it encrypted at rest and in transit? Expect a clear yes to both.
• How long is it retained? Is there a retention limit, or is everything kept indefinitely?
• Where is it stored? Which country or region, and does that matter for your regulatory obligations?
• Is any of it used for anything else? Product analytics, model training, benchmarking. The answer should be written in the contract, not only in a blog post. If the tool has AI features, there are more questions to ask about those.

Who can see what

Once a calendar is connected, think about everyone who might see its contents:

• Other users in the scheduling tool. Can a colleague see your event titles, or only your availability? Can a manager see their team's full calendars? Is that configurable?
• External bookers. When a prospect opens your booking page, they should see open slots — never event titles or who you are meeting. Check this yourself on a test account.
• The vendor's staff. Who at the vendor can access customer data, under what circumstances, and is that access logged?
• Sub-processors. Which third parties does the vendor use for hosting, email, analytics, or support, and do they receive calendar data?

Certifications and what they actually mean

Vendors often answer security questions with a list of badges. They are useful, but it helps to know what each one does and does not tell you.

• SOC 2 Type I means an auditor reviewed the design of the vendor's controls at a point in time.
• SOC 2 Type II means an auditor tested whether those controls actually operated over a period, typically several months to a year. Type II is the more meaningful of the two.
• ISO/IEC 27001 certifies that the vendor runs an information security management system that meets the standard.
• A GDPR-compliant data processing agreement matters if you handle personal data of people in the EU or UK, and your legal team will likely want to review it.

Ask for the report itself, under NDA if necessary, rather than accepting a logo on a website. Check its date and scope — a certification that covers the vendor's marketing website but not the product is not much use.

A young vendor may not have certifications yet. That is not automatically disqualifying, but it shifts the burden onto clear written answers to the other questions here.

What happens when someone leaves

Calendar connections tend to outlive the people who created them.

• When an employee leaves, how is their calendar connection revoked? Is it automatic when their account is deactivated in your identity provider, or does someone have to remember?
• Does the tool support single sign-on and automated user provisioning, so access follows your own directory?
• Can an administrator see every connected calendar and revoke any of them?
• When you stop using the vendor, what happens to your data? Is it deleted, and can they confirm that in writing?

The question list

Copy these into your vendor evaluation:

1. Which calendar permissions do you request, and why is each one needed?
2. Can the integration work with free/busy access only?
3. Do you store event details, or compute availability on demand?
4. How long do you retain calendar data, where is it stored, and is it encrypted?
5. Is calendar data used for any purpose other than providing the service to us?
6. What can other users, external bookers, and your own staff see?
7. Which sub-processors receive calendar data?
8. Which security certifications do you hold, and can we see the reports?
9. How is access revoked when an employee leaves, and do you support SSO?
10. What happens to our data when the contract ends?

A vendor who answers all ten clearly and in writing is one you can reasonably trust with your calendar. A vendor who is vague on more than one or two deserves a closer look.

CallShark's calendar integrations are planned and not yet built. When they are, every question on this list applies to us too. The product is temporarily down.