The short version
- We ask for read-only access. We never ask for permission to change anything in your systems.
- You can shut our access off yourself, from your own system, without asking us.
- Your data is encrypted on the way to us and while it sits with us.
- Every client's records are walled off from every other client's at the database level, and a test proves it on every change.
- Nobody signs in with a password, because we do not have any to steal.
- Section 9 lists what we have not built. We would rather you read that than find it out.
Everything on this page is something we actually do today. Anything we intend to do but have not built is in Section 9, not in the list above.
SECTION 01How we reach your data
We ask for the least access that lets us do the work, which is almost always read-only. That is not a policy we wrote down and hope to follow. It is how the connection instructions are built.
Read-only, by design
When you connect a system, we walk you through adding us the way that system's own permissions intend: as a read-only user, an adviser, an accountant with view access, or a read-only key. Depending on where your data lives, that is Square, Toast, Clover, Lightspeed, Shopify, QuickBooks Online or Desktop, a Google Drive or OneDrive folder, or a file you send us.
- We never request write access. We cannot change, delete, or move anything in your systems, because we never had permission to.
- We ask only for what the work needs. Not every report in the system, the ones the question needs.
- You hold the off switch. Remove the user, revoke the key, or unshare the folder. It works immediately and you never have to ask us.
Keys and sign-ins
Where a system gives us a read-only key, it is stored encrypted and never printed into a log or an error message. We do not want, ask for, or keep your own passwords to anything.
SECTION 02Where it lives
- On the way to us. Everything moves over HTTPS. There is no unencrypted path in or out.
- While it sits with us. Our database and file storage are encrypted at rest by the provider that runs them.
- Where it runs. Our systems are hosted on established cloud infrastructure in the United States, run by providers who hold their own independent security certifications. See Section 9 for what that does and does not mean about us.
SECTION 03Keeping clients apart
This is the risk that actually matters for a company like ours: one client's numbers appearing in another client's answer. So it is the one we built hardest against.
Every table that holds client data has row-level security switched on at the database itself. That means the separation is not a rule our code remembers to follow. It is enforced one layer below the code, so a mistake in our own code cannot reach across it.
104 tables with row-level security enabled, 166 access policies, and a suite of tests written specifically to try to read one client's rows as another. Those tests run on every change before it can ship. A change that broke the wall would not reach production.
Separately, our own analysis work is scoped to one client at a time. We never use one client's raw data to answer another client's question. What we carry between clients is skill, not records.
SECTION 04Who here can see it
- There are no passwords. Everyone signs in through a single-use link sent to their work email. We do not store a password for you or for us, so there is nothing of that kind to leak or reuse.
- We are a small team. Access goes to the people doing your work, and it is removed when someone no longer needs it.
- Everyone is under a confidentiality agreement. Your engagement letter makes that mutual: your information stays secret with us, and our methods stay secret with you.
SECTION 05Who we will send it to
The most likely way a business like ours leaks a client's numbers is not a break-in. It is someone emailing us from an address we do not know, asking for a copy, and getting one. So there are two checks on that path.
- Coming in. We keep a register of the people at your business we know. A message from an address that is not on it is filed and flagged rather than acted on.
- Going out. Before anything is sent, the recipients are checked against the addresses we hold for you. An address we do not have on file stops the send for a person to look at.
Tell us who should be on that list, and tell us when someone leaves. We will ask you to confirm it from time to time.
SECTION 06What we never do
- We never sell or rent your data.
- We never hand your data to anyone else to use for their own purposes or to learn from.
- We never write to, change, or delete anything in your systems.
- We never move money, sign anything, or act on your behalf.
- We never use one client's raw data to answer another client's question.
- We never use your business in our marketing without your written permission.
- We do not accept patient records or health records. If any reach us by accident, we delete them and tell you.
SECTION 07Leaving, and deletion
You can revoke our access to every connected system yourself, at any time, without telling us first.
If you leave and want us to delete what we hold, ask and we will, within 90 days, except anything the law requires us to keep. We confirm in writing when it is done.
Everything we delivered to you is yours to keep and use forever, whether you leave, take the refund, or stay for ten years.
SECTION 08The companies that help us
Like any modern company, we use outside providers to host the database, send email, take payment, and support our own internal operations. They handle your information only to do the job we hired them for, and they are bound by contract to protect it.
Ask, and we will send you the full list of every provider that touches your data, what each one handles, and why. In writing, to anyone who is a client or is considering becoming one. We would rather answer that than publish a list that quietly goes stale.
SECTION 09What we have not built yet
Most security pages list only what a company has. That makes them useless for judging anyone, because everything sounds the same. So here is the other half.
| Thing | Where we stand |
|---|---|
| SOC 2 | We are not SOC 2 certified. Our infrastructure providers are, which covers their layer and not ours. We build to that standard and intend to certify as we grow. |
| Outside penetration test | Not done yet. Planned before we certify. |
| Full access logging | Designed, not built. Today we can see what changed, not a complete record of every read. |
| Two-step sign-in | Not in place. Sign-in is a single-use link to a work email, so the security of that mailbox is doing real work. Keep it locked down. |
| Round-the-clock monitoring | No staffed overnight monitoring. We are a small team in one time zone. |
| Bug bounty | No paid programme. We do want the report. See Section 11. |
| Background checks | Not run today. Everyone is under a confidentiality agreement. |
| Health data | Not supported. We are not set up for it and we do not take healthcare clients. |
If any of these is a requirement for you, tell us before you sign rather than after. We would rather lose the work than be the reason you failed your own review.
SECTION 10When something goes wrong
No system on the internet is perfectly secure, and we are not going to pretend otherwise. If something happens, here is what we do.
- Stop it. Revoke whatever was exposed, pause what needs pausing.
- Work out the scope. What was reachable, for how long, and whose.
- Tell you. If your information was affected, we tell you promptly and tell you what we know, including the parts we do not know yet. We will not wait until the story is tidy.
- Fix the cause, and tell you what we changed so it does not happen again.
We would rather tell you something embarrassing early than something worse late.
SECTION 11Telling us about a problem
If you find a weakness in anything of ours, please tell us instead of using it. Write to data@kixik.tech with SECURITY in the subject line so it gets routed straight through.
We will not pursue anyone who reports something in good faith, does not access or change data that is not theirs, and gives us a fair chance to fix it before telling anyone else.
SECTION 12Contact us
Security questions, a due diligence review, or a request for our provider list. One address, a person reads it.