Security and procurement teams usually ask us the same questions. We answer them up front below, describing the practices we use in projects and on the platform where we run client systems. We share configuration details as part of the project, after an NDA is signed.
Deployments and supply chain
Every change reaches production through the repository and an automated pipeline, not through manual logins to a server. Container images are built in CI and cryptographically signed, and the cluster rejects any image without a valid signature. We update dependencies automatically and scan them for known vulnerabilities.
Secrets (API keys, database passwords) are kept in a secrets manager, never in the repository or in configuration files. Test and production environments have separate secrets.
Infrastructure and business continuity
We run systems on Kubernetes in data centres in the European Union, or in the client's own infrastructure if the contract says so. Public traffic passes through an attack protection layer, and admin panels are reachable only from a private network. Applications are isolated from one another, and network traffic between them is blocked by default.
Backups are taken in several layers, including continuous change capture for databases, and are stored outside the main environment. We test restores automatically every week, because a backup nobody has restored is only an assumption. Monitoring measures availability against agreed targets (SLOs) and raises alerts when they are missed.
Personal data and GDPR
We design around data minimisation: a system stores only the data needed for its purpose. Where possible we use pseudonymisation, and special category data, such as health data, stays in the source system. Isolation of different clients' data is enforced at the database level, not only in application code.
Only people who need access to production data have it, and measurements on live databases are run in read-only mode. We help prepare the record of processing activities and a data protection impact assessment (DPIA) when a project requires one.
AI deployments
We use language models through providers' APIs in a mode where submitted data is not used to train models. When a project requires it, we choose models and processing regions so that data stays within the European Economic Area.
The AI assistants we build have prompt injection filters in front of the model, a check of responses before they are sent, and a separation of data from instructions. Numbers and prices come from source data, not from the model's memory. Before each release we run a suite of quality and attack tests, and sensitive cases are passed to a human. We take AI Act requirements into account from the analysis stage.
Access and people
Sign-in to internal tools and panels goes through SSO. We grant the minimum permissions needed, and revoke them immediately when the engagement ends, including those of suppliers and subcontractors. The repository, documentation and system access belong to the client throughout the project.
NDA and data processing agreement
We sign an NDA before discussing project details. When we process personal data on the client's behalf, we conclude a data processing agreement (DPA) tailored to the project. We send templates of both documents on request.
Reporting vulnerabilities
If you find a vulnerability in a system we built or run, or on this website, write to [email protected]. We will acknowledge the report within two working days and tell you how we are fixing it. Please do not disclose the vulnerability publicly until it has been fixed. Contact details are also in the security.txt file.
This website
The koritsu.io website does not use tracking cookies or third-party advertising scripts. It sends security headers (including Content Security Policy and HSTS), and the contact form has bot protection and a submission limit. How form data is processed is described in the privacy policy.