The IT project for why you don’t need one

• HECVAT — the Higher Education Community Vendor Assessment Toolkit, built by EDUCAUSE, Internet2 and REN-ISAC in 2016 and used by 240-plus institutions. Its current version runs to 321 questions; even the old "Lite" screening version was 62. It exists because every department used to write its own questionnaire, producing inconsistent reviews and vendor fatigue.
• The NCSC Cloud Security Principles — 14 principles covering data in transit, asset protection, separation between customers, supply chain, identity and authentication, and audit. The reference point for UK public-sector and university cloud assessments.

Reading across UK and US institutional policies alongside those frameworks, the same five gates come up every time:

1. What class of data is involved? Personal, special-category, or regulated (HIPAA, FERPA, PCI).
2. How many people, and which groups? Most policies scope themselves to groups rather than individuals.
3. How do people sign in? SSO and multi-factor authentication, frequently mandatory.
4. Where does the data live, and who else touches it? Region, sub-processors, supply chain.
5. What does it cost? Which decides whether Procurement and a tender threshold are involved.

• Nothing to connect. No SSO, no directory sync, no calendar integration, no API into your systems, no webhooks, no browser extension, no installed software. There is no integration surface, so the supply-chain, interface-protection and separation questions have nothing to describe.
• Almost nothing to hold. A name, a work email address, a role, and the times a room was booked. No special-category data, no regulated data, no institutional records, and no meeting content — there is no field for a subject, so the confidential thing the review is protecting was never collected.

Send the questionnaire and most sections come back not applicable — not as an evasion, but because the risk surface each one measures does not exist. That is what "no IT project" means in practice: not that the review is skipped, but that there is very little left for it to find.

• The only personal data is a name and a work email address. Plus a role, and an end date if someone is on a guest pass. That is the complete list.
• No special-category data. No health, biometric, genetic, racial, political, religious, union or orientation data — there are no fields for any of it.
• No institutional data is connected, imported or accessed. Nothing is synced from your directory, your calendar or your files.
• No meeting content of any kind. No subject, title, description or attendee list — not "we don't display it", but no column in the database to put it in.
• A privacy impact assessment, if your policy triggers one on any personal data, has a very short scope: two fields and a room booking.

What does this software do?

Books meeting rooms in a shared building. An administrator creates the rooms and invites the people allowed to use them; those people book from a phone or laptop. Bookings that nobody checks into are released automatically so the room goes back into circulation.

Supplier contact

Andres Urena — legal at meetcolega dot com. You will get an answer from the person who wrote the code.

Is there a demo?

Yes — ask and you will be given a working building with sample rooms, rather than a video. There is nothing to install to try it.

Approximate cost, and the licensing structure

A flat monthly fee per building — deliberately not per seat, so adding people never triggers a headcount conversation or a licence true-up. Pilots are free and time-limited by agreement.

Minimum term, auto-renewal, enterprise licence?

No minimum term, no auto-renewal clause, no separate enterprise tier. Billing is by invoice; no card details are ever entered into the product.

Does the supplier support MFA and/or SSO?

Neither, and the reason matters. Colega has no passwords at all. Signing in means entering your email address and clicking a single-use link that expires in 15 minutes. There is no password to reuse, phish or breach, and no credential database to steal.

The practical consequence for a policy that mandates MFA: the authentication factor is your own mailbox, which is already behind your MFA. Colega does not weaken that control — it delegates to it and adds nothing of its own to compromise.

If your policy requires MFA as a literal product feature rather than as an outcome, Colega will not satisfy it today. Say so early and we will tell you honestly whether SSO for a single-tenant building is on the roadmap rather than pretending the box is ticked.

Which authentication platform?

None — no Duo, Entra ID, Google or other identity provider is contacted. Nothing is registered in your tenant, and no admin consent is ever requested.

Login URL

meetings.meetcolega.com/signin

Which user groups?

Whoever the building's administrator invites — tenants, staff, students, visitors, external members. Access comes from being on a building's member list, never from what an email address ends in, so no domain is trusted and none is required.

Approximate number of users

The size of one building's member list. For a typical incubator or serviced office that is tens, not hundreds; the answer to a "fewer than 50 / more than 50" question is usually fewer, per building.

Administrator accounts

As few as one. Reception normally holds it. A shared mailbox works as an administrator account if that is how your building already operates.

Personal data held	Name, email address, role. An end date if the person is on a time-limited guest pass. Nothing else.
Special-category data	None. No health, biometric, genetic, racial, political, religious, trade union or sexual orientation data — there are no fields for it.
Meeting content	None. No subject, description, agenda or attendee list exists in the schema. Every booking reads as "Name's meeting" to everyone, including administrators and including us.
Payment data	None. Billing is invoiced; no card is ever entered.
Tracking	One essential session cookie. No advertising, no fingerprinting, no page-level analytics, no consent banner required.

• The database is pinned to the EU. Not "currently hosted there" — it was created with a Cloudflare D1 jurisdiction of eu, which constrains where it may run and store data. That constraint can only be set when a database is created, so it is a property of this database rather than a setting someone could change later.
• Read replication is switched off, so there are no copies of the database in other regions.
• Platform: Cloudflare Workers and Cloudflare D1, served over TLS with HSTS enforced.
• Sub-processors: Cloudflare (hosting and database), Resend (transactional email), PostHog EU (anonymous product analytics, EU region). That is the complete list.

Data retention	Bookings are kept while the building is a customer. There is no secondary use, no profiling and no resale, because there is nothing worth profiling.
Export and exit	A full CSV export of members, rooms and bookings on request. No lock-in.
Deletion	Complete deletion of a site and every record in it within 30 days of a request, normally the same week.
DPA	Send us yours and we will work through it; we will not insist you sign ours instead. For a service holding a name, an email address and a room booking, it is usually a short conversation.
Integrations	None, by design. No calendar, no directory, no SSO, no webhooks, no API into your systems. Calendar information travels one way only, outward: an emailed invitation file and an optional read-only feed a member can subscribe to.
Access by us	Support access to operate the service. Even with it, meeting subjects cannot be read — they do not exist.
Incident response	One named person, contactable directly, who will tell you what happened and when. No ticket queue.

The technical detail behind these answers is on the security page.

1. The problem, in current-process terms. Not "we lack a system" but the steps people take today — the form, the email to reception, the check for availability, the second form when the time changes. Count them.
2. Who it affects. The people booking rooms and the person fielding the requests. Name the reception time it consumes.
3. What the tool does about it. Self-service booking, and rooms that release themselves when nobody turns up.
4. Why this one. Nothing to connect, nothing to install, no tenant access, no per-seat licensing — so no IT project and no procurement threshold.
5. Cost and term. Flat per building; free for a pilot; no minimum term.
6. What happens if it doesn't work. Export the data, stop paying, go back to the spreadsheet. The reversal cost is the strongest argument a small purchase has.

If it helps, send us your institution's template and you will get it back filled in, with the claims above stated in your own house language.

• No MFA or SSO as a product feature. Covered above. If your policy reads literally, this is the line it will catch on.
• Colega is not itself Cyber Essentials certified. The underlying platform is Cloudflare; the application layer is a one-person operation and says so.
• No formal accessibility audit, and no VPAT. The product is plain semantic HTML with no custom widgets, which tends to score well, but it has not been tested against WCAG 2.2 AA by anyone qualified. If your process requires a completed VPAT or the HECVAT accessibility section, that is a genuine gap today. Send us what your audit finds and it gets fixed.
• No contractual uptime SLA. It runs on Cloudflare's global network and there is no server to fall over, but that is an architecture, not a guarantee.
• No ISO 27001 or SOC 2. Those are the right questions to ask a large vendor. This is a small tool that holds a name, an email and a room booking.