Security statement

1.Where your data lives

Akollo runs in our cloud or on-premise, inside your own data centre, with the same product in both. On-premise, your data stays inside your network and your teams decide when to upgrade.

Every page, list, export and API response contains only the data of the organisation you are working in. A record from another organisation is reported exactly as if it did not exist.

2.Encryption and secrets

Connections to the product and to its integrations are encrypted in transit. Credentials for connected systems, AI provider keys and similar secrets are stored encrypted as soon as they are saved and are never shown again, not even to administrators. API keys, webhook signing secrets and connector tokens are shown once, can be replaced at any time, and the old value stops working after a short, stated grace period or at once.

3.Signing in

People sign in the way their organisation provides, including single sign-on with your directory. Each person can protect their account with two-step verification through an authenticator app, backup codes and, where enabled, passkeys, and can review and remove trusted devices.

Directory provisioning never grants access or disables accounts on its own: each joiner, mover or leaver change runs as a case, and changes that would create an administrator or disable many accounts at once wait for an approver.

4.Who can see and change what

Access comes from roles and permission sets built from a fixed list of actions. Field policies decide whether a sensitive field, such as a national ID number or a cost rate, is hidden, masked, read-only or editable; when several apply, the strictest wins, for administrators too. “Explain access” shows where each of a person's permissions comes from.

Sensitive changes need a second person: granting administrative rights, loosening a field policy, publishing a regulated workflow, approving a time correction, a budget or rate change above its threshold, or a contractor's renewal. Nobody approves their own request. Contractor access always has a sponsor and an end date of at most 180 days, and access reviews let managers confirm or remove access on a schedule.

5.Audit records and support access

Changes to privileges and configuration are written to the audit log, which administrators can read and filter. Many actions also require a written reason that is kept with the change.

When Akollo support opens a session in your organisation, a visible banner says so. A support session can only read the pages it is allowed to see; it cannot create, change, approve or delete anything, and sensitive fields stay hidden.

6.Outbound connections

Integrations reach only the external hosts your installation's administrators have allowed, further narrowed by each connector's own settings. When no list has been set up, connectors cannot reach any external host. Directory connectors can only read and list.

7.AI and personal data

Akollo AI works with each person's own permissions and never widens access. An administrator decides who may use it, which models answer and the highest data classification a cloud model may receive. Data classified as restricted is answered only by a model running inside your organisation; if there is none, the request is refused rather than sent elsewhere.

E-mail addresses, phone numbers, IBANs, card numbers and national ID numbers are masked before a model sees them. AI requests are logged with who asked, which feature, when and the outcome, not the content. An emergency stop switches every AI request off at once.

8.Certifications and what is planned

Akollo does not currently hold an independent security certification. We plan to pursue one; until we announce it, please do not read anything on this website as a certification claim.

To help your own compliance work, Akollo is preparing a control register that maps product controls to ISO/IEC 27001:2022 Annex A, the BDDK information systems regulation and KVKK requirements. That register is a mapping, not a certification. Forwarding security events to your SIEM and a governance overview for security and data protection officers are also planned and described in the documentation as such.

9.Reporting a vulnerability

If you believe you have found a security vulnerability in Akollo or akollo.com, please write to [email protected] with a description, the steps to reproduce it and its likely impact. We will acknowledge your report, keep you informed while we investigate and fix it, and credit you if you wish.

• Test only against your own account or organisation, and stop as soon as you can show the issue.
• Do not access, change or delete other people's data, and do not degrade the service for others.
• Give us a reasonable time to fix the issue before you share it publicly.
• We will not take legal action against research carried out in good faith within these rules.