Security and service commitments
Security and service commitments
This page explains, in straightforward terms, how Kwilo approaches access control, data handling and day-to-day service security. It is meant to be clear, not overblown.
Access and account control
Kwilo is built around signed-in access, with permissions and controls intended to stop people seeing or changing data they do not need. In simple terms, access should be limited to the people who actually need it to do the job.
Service security basics
- The service should be delivered over HTTPS.
- Sign-in and session handling should support secure access to the app.
- Logs and audit-style records may be used to investigate problems, support users and keep track of what happened.
- Security fixes, maintenance and other updates should be applied as part of running the service properly.
Data handling expectations
Data stored in Kwilo should be limited to what is actually needed for the job, the workflow, support or a legal requirement. Users should avoid uploading sensitive information they do not need to keep there.
Support and incident handling
If there is a serious service or security issue, the right approach is to deal with it quickly, contain it, investigate it and explain clearly what happened and what changed afterwards. This trust centre is one of the places where that kind of public explanation can live.
What we are not claiming here
- We are not claiming that security incidents can never happen.
- We are not saying software removes the need for sensible internal controls or proper professional advice.
- We are not saying AI output or records should be accepted without review.
Shared responsibility
Security is partly our job and partly the customer's. Businesses using Kwilo should manage access carefully, review permissions, protect devices and make sure the right people are checking important financial or legal information.