Enterprise Procurement and the Privacy Questionnaire

The 200-question spreadsheet

If you have ever tried to get a software tool approved at a large enterprise, you know the process. Procurement sends a security questionnaire. Sometimes it is a SIG Lite. Sometimes it is a custom spreadsheet with 200 questions about your infrastructure, data handling, compliance certifications, and incident response procedures.

These questionnaires were designed for SaaS platforms that store customer data on their own servers. They ask about data centers, encryption standards, access controls, backup procedures, disaster recovery, and employee background checks. For a traditional cloud application, every one of those questions is relevant.

For manyCalendars, most of them do not apply. And that is not a weakness. It is the entire point.

How manyCalendars answers the hard questions

"Where is customer data stored?" On the user's device, in the browser's local storage. We do not store customer data.

"What is your data residency policy?" Not applicable. We have no servers that hold customer data. The data resides wherever the user's browser runs.

"Describe your encryption at rest." Not applicable. There is no "at rest" on our side. The browser's local storage is governed by the device's own encryption (BitLocker, FileVault, or the organization's disk encryption policy).

"Describe your encryption in transit." manyCalendars does not transmit user data. Calendar data moves from the user's open browser tabs into the extension's local storage. It never crosses a network boundary that we control.

"Do you have SOC 2 Type II certification?" SOC 2 certifies that a company's servers and processes handle data securely. When there are no servers and no data handling, the certification does not apply. We are happy to explain this to your auditor.

"What is your incident response plan for data breaches?" A data breach requires data to breach. We cannot lose what we never had.

Why this makes procurement faster

Enterprise procurement cycles for SaaS tools typically run 4 to 12 weeks. Security review, legal review, vendor risk assessment, compliance mapping. Each step requires documentation from the vendor and review from the buyer's team.

Local-first tools compress this timeline dramatically. When the security review comes back with "N/A" on 80% of the questions, there is less to review. When there is no data processing agreement to negotiate (because no data is processed), legal finishes faster. When the vendor risk is "they never see our data," the risk assessment is straightforward.

We have seen enterprises approve manyCalendars in under a week. Not because they cut corners, but because there was genuinely less to evaluate.

The questions that do apply

Local-first does not mean zero questions. There are still legitimate things for a security team to evaluate:

Extension permissions: What does the extension's manifest request? manyCalendars requests access to specific calendar domains and local storage. It does not request access to all URLs, browsing history, or cookies.

Update mechanism: How are extension updates delivered? Through the Chrome Web Store or Edge Add-ons, which are reviewed by Google and Microsoft respectively. Updates are automatic and cryptographically signed.

Code auditability: Can the extension's code be reviewed? Yes. Browser extensions are distributed as JavaScript, which can be inspected directly. We also publish our permissions and architecture documentation publicly.

Supply chain: What third-party dependencies does the extension use? We maintain a minimal dependency tree specifically to reduce supply chain risk.

These are fair questions. We welcome them. They are also much faster to answer than explaining a multi-region server architecture. If your organization is evaluating manyCalendars, send your questionnaire to us. We will probably finish it before lunch. Or just install it now, since it never touches your company's data anyway.