Security
Accolgo runs on trust and transparency. A new starter’s manager sees their check-in answers as part of how the product works, and the starter knows that from the first email: it is disclosed, not secret. That visibility is the whole point, it is what lets a manager spot someone struggling and have a conversation in time.
The one deliberate exception is the private word. If a starter asks to speak with someone senior instead of their manager, that request is walled off in the database itself: the manager is never told it was raised and cannot reach it through the app, an export, or a direct query. Here is how both halves are built.
Row-level security on every table, zero anonymous table access, and organisation scoping enforced again in the application layer. One organisation can never see another.
Check-in links are randomly generated, single-use tokens that expire after 14 days. A guessed or shared URL opens nothing.
Managers see their own team. The owner and head of people see their organisation. Platform operators see activation metadata only, never check-in content.
A private word with someone senior reaches only the head of people. A manager cannot read it through the app, an export, or a direct query. This is enforced at the database itself.
Encryption in transit everywhere and at rest at the database provider. Secrets live in environment configuration, never in code or the repository.
Migrations are numbered, reviewed and applied with explicit grants, each checked against prior revocations. Error monitoring is tagged per organisation, with an append-only email delivery log.
The detail, and reporting a concern
The full security policy, our data processing terms and our retention schedule set this out in detail and are linked below. If you believe you have found a vulnerability, email dermot@clickonic.co. We acknowledge reports promptly, do not pursue good-faith researchers, and ask that you avoid accessing other people’s data while demonstrating an issue.