Security
Security starts before the first line of code.
Security in a business system means controlling who has access, how information moves and how important actions can be verified. This page explains in management-friendly language how protection is built into design, development and operation.
A business system may contain customer information, contracts, operations and internal processes. Security is therefore not a feature added at the end. We design it together with access, data, infrastructure and the way the system will be used.
01
Access only where it is needed
A project does not imply general access to your company. We define which people and components need access for a specific task and limit permissions to that purpose. We remove access when it is no longer needed. For development and testing, we prefer test, anonymised or synthetic data when appropriate.
02
Data is a responsibility, not raw working material
We clarify what information is required, where it flows and who needs to see it. We do not use a client's data in other projects or for purposes other than those agreed with that client, and we do not copy it unnecessarily between environments. Environment separation, minimisation and retention rules depend on the project.
03
Protection in multiple layers
We do not rely on one password or a single control. Protection is designed across identity and access, application, infrastructure, data, backups and monitoring. The concrete measures depend on the risks and requirements of the system being built.
04
We need to understand what happened
For important actions we design traceability: who or what system initiated an operation, when it happened and what result it produced. This supports incident investigation, change verification and accountability. Logging depth is adapted to the project's data and purpose. If an incident affects a client's data, we inform the client without undue delay.
05
AI receives only permitted information and actions
Using AI should not mean sending company information to a model without control. We define which data may be used, what must be removed, replaced, anonymised or synthesised and which actions an assistant may perform. An external AI provider receives client data only with the client's agreement. Operations affecting customers, documents or systems keep boundaries and approval points proportionate to risk.
06
Checks before production
Important changes pass through checks before reaching production. We use automated controls and review to identify errors, vulnerabilities, problematic dependencies and accidental secret exposure. The exact checks depend on the technology and risk of the project.
07
Continuity and recovery
Security also includes the ability to recover from an error, a bad change or an outage. We establish what must be backed up, how quickly it needs to be restored and the steps required for recovery. A backup is useful only when the restoration process is known and can be tested.
08
What we do not promise
We do not describe a system as impossible to attack and we do not claim certifications or compliance levels that a project has not obtained. We prefer to explain which controls exist, why they exist and their limits. Legal, contractual and industry-specific requirements are evaluated separately for each project. The specific measures for each project are set out in the contract.