SOC 2 and Your Data: How We Keep Client Information Locked Down
What SOC 2 actually covers, how we keep your data out of the models we build, and why most companies still get the basics wrong.
Author -
Remzo Hotić
Published -
Every AI deployment touches the data a company most needs to protect: customer records, contracts, pricing, support conversations. The question is not whether that data will be used, but how far it travels and who can reach it.
Security is not a feature we add at the end. It is the shape of everything we build.
What SOC 2 covers, in plain terms
SOC 2 is an audit standard from the AICPA. An independent auditor checks that a company actually runs the controls it claims to run, across five areas: security, availability, processing integrity, confidentiality and privacy. It is not a certificate you buy. It is evidence, gathered over months, that the controls hold up in daily practice.
For a client that means one thing: you do not have to take our word for it. Access reviews, change management, incident response, vendor checks and encryption are all documented and tested by someone who is not us.
Where AI projects usually leak
IBM's Cost of a Data Breach Report 2025, run by the Ponemon Institute across 600 breached organisations, puts numbers on the problem:
13% of organisations reported a breach of an AI model or application in the past year.
97% of those had no AI access controls in place when it happened.
63% of breached organisations had no AI governance policy, or were still writing one.
1 in 5 breaches involved shadow AI, tools staff adopted without approval, adding about USD 670,000 to the cost of a breach.
The pattern is consistent. Companies that build AI on their own rarely fail on the model. They fail on the plumbing around it: who can query it, what it is allowed to see, and what leaves the building inside a prompt.
How we keep your data out of the model
Our systems answer from your approved content and nothing else. Getting there takes four deliberate steps:
Minimise first. We inventory every source before connecting it and leave out what the process does not need. Fewer fields, smaller blast radius.
Pseudonymise on the way in. Names, emails, account numbers and free-text identifiers are replaced with tokens before any text reaches a model. The mapping stays in your environment.
Isolate per client. Each client runs in its own environment with its own keys, its own knowledge base and its own audit log. No shared indexes, no cross-tenant retrieval.
Keep it in the EU. Data is stored and processed inside the European Union, on infrastructure covered by the same controls the audit looks at.
What that looks like day to day
Least privilege: every integration gets the narrowest permission that still does the job, and permissions are reviewed on a schedule.
Encryption everywhere: in transit and at rest, with keys you can revoke.
No training on your data: the models we use do not learn from your prompts or documents, and that is written into the contracts with the providers.
Logged and reviewable: every query and every change is recorded, so an auditor, or you, can trace what happened and when.
Compliance you can hand to your own auditor
SOC 2 sits alongside ISO 27001, GDPR and the EU AI Act in how we work. The AI Act's transparency duties (Article 50) and the AI literacy requirement (Article 4) are built into every rollout: disclosures where AI is used, and documented training for the people using it.
When your security team or your auditor asks for evidence, we hand over the report, the policies and the logs. No slide decks, no promises.
The bottom line
AI only pays off when people trust it with real data. That trust is earned in the boring places: access lists, key rotation, retention rules, an incident plan that has been rehearsed. We would rather be measured on those than on a demo.
If you want to see how this applies to your own systems, the readiness assessment covers it in two weeks, with a written plan you keep either way.
More Insights
