Security isn’t something we add at the end of development. It’s part of how we design every system: from how we handle code and credentials to how data is processed, access is configured, and what reaches production is controlled.
Not all projects carry the same risks. An informational site, an internal automation, and software that handles confidential information require different levels of attention.
That’s why we define the technical measures based on the architecture, the data involved, the integrations used, and the context in which the system will operate.
Security proportionate to the project
Our goal isn’t to add complexity, but to protect every project appropriately.
Before developing, we analyse what information will pass through the system, where it will be processed, which services will be able to access it, and which points will require more attention.
From this analysis come the technical choices: access management, environment separation, credential protection, input validation, logging, backup, and checks before release.
The more critical the system, the more controls are needed.
Protected code and controlled development
The code is kept in private, versioned repositories, with access limited to the people involved in the project.
Passwords, tokens, API keys, and other credentials are kept separate from the code and managed through dedicated tools.
When necessary, we separate the development, testing, and production environments to verify changes and new features before they reach the system used by users.
The change history also keeps the work traceable over time and makes it possible to identify more easily what has changed and to act in a controlled way when needed.
Access limited to what’s needed
We follow a simple principle: each person should only be able to access what they genuinely need.
So we limit unnecessary authorisations and privileges and avoid, where possible, sharing accounts.
Access to the main services is protected with multi-factor authentication where available and appropriate, and reviewed when people, responsibilities, or operational needs change.
Reducing unnecessary access helps reduce the system’s attack surface.
We only process the data we need
We design systems trying to collect, store and use only the information necessary for them to function.
For data in transit we use encrypted connections in the components and services that support them and, for stored data, we assess the encryption-at-rest capabilities available and appropriate to the chosen infrastructure.
Access is limited according to actual operational needs. When the project requires it, we also define which information should be retained, for how long, and which can instead be deleted, anonymised, or excluded from the process entirely.
The same principle applies when the system communicates with APIs, cloud services, or other external components: before integrating a service we analyse which data genuinely needs to reach it and try to avoid unnecessary transfers.
The question isn’t only “can we use this data?”, but also “does the system genuinely need it?”.
Where your data lives
In modern software, knowing where the main database sits is not necessarily enough to understand where all the information is stored, processed or transmitted.
Over their lifecycle, data can pass through storage, backups, replicas, processing queues, logging and monitoring systems, authentication services, APIs, communication platforms and AI components.
That’s why, when the location or control of information is a requirement, we consider the architecture as a whole.
Requirements come first. Technical choices come after.
The client knows their own process, the nature of the information handled, internal policies and any contractual or regulatory constraints.
Our job is to translate those requirements into architecture.
Providers, regions, storage systems and processing methods are then defined considering elements such as:
- the nature and sensitivity of the data;
- geographic requirements;
- internal policies;
- applicable contractual or regulatory constraints;
- operational needs;
- availability and service continuity;
- performance;
- the cost and long-term sustainability of the solution.
When a requirement calls for specific legal or regulatory expertise, the technical decisions are built around the constraints indicated by the client or by the relevant professionals.
The architecture implements the requirements. It doesn’t invent them.
The database region is only one part
If certain data must remain in your country, in the European Union or in another geographic area, we can design the system around that constraint.
But checking only the database region may not be enough.
The other components that can hold, duplicate or receive information should also be considered:
- databases;
- object storage;
- backups and replicas;
- logging and monitoring;
- authentication services;
- APIs and integrations;
- AI services.
Each can have different configurations, regions, retention periods and conditions.
That’s why we distinguish between where a single component is located and the overall path data takes through the system.
This does not mean that all data has to reside in the same environment. Depending on the requirements, databases, documents, storage, backups or other components can be distributed across different infrastructures, keeping access, responsibilities and data flows between the various parts of the system clearly defined.
Residency and sovereignty are not synonyms
Data can be physically stored in Europe without that fact, on its own, describing the full level of control over the infrastructure.
When a project involves sovereignty or particular confidentiality requirements, other elements can become relevant too:
- who runs the service;
- which jurisdiction it is subject to;
- who controls identity and access;
- how encryption keys are managed;
- which components depend on third-party providers;
- how far data and services can be migrated to another infrastructure.
Sovereignty is therefore not treated as a binary label.
It is a broader assessment that depends on the requirements and on the concrete architecture of the project.
External services are part of the architecture too
A system rarely operates entirely on its own.
It may rely on cloud providers, authentication services, monitoring tools, payment gateways, communication platforms, APIs, AI services or other technology suppliers.
When one of these components can receive or process the project’s information, it enters the data perimeter.
Before adopting it, we consider, as far as relevant:
- what function it performs;
- what information it receives;
- where that information is processed;
- which configurations it offers;
- which retention policies it applies;
- which further services it depends on.
When possible and useful to the project, we also limit the amount of information transmitted to external services.
The goal is not to build systems with no dependencies at any cost.
It is to know which dependencies exist and what role they play in processing the information.
When AI enters, another data flow appears
Integrating an AI model doesn’t necessarily mean granting it access to the organisation’s entire archive.
The system can be designed to retrieve the context relevant to the specific task and send the AI service only what the intended processing needs, avoiding indiscriminate access and unnecessary transfers.
The principle, however, doesn’t stop at the payload sent to the model.
Before integrating an AI service, we also consider, based on the project’s requirements:
- where processing takes place;
- which retention policies apply;
- which data-related configurations are available;
- which infrastructures and providers take part in the service;
- which deployment options are possible.
The answers are not the same for every model.
They depend on the provider, the product used, the contract and the selected configuration.
That’s why we don’t generically describe a model as “private” or “secure” without considering how it is actually used.
Not every project requires the same level of control
A system that uses public information does not necessarily require the same measures as software that processes financial documentation, confidential information, intellectual property or data subject to specific organisational or regulatory constraints.
Depending on the context, we can therefore consider different levels of control.
Regional cloud
The application and data are placed in geographic regions selected from those offered by the provider.
It is a suitable solution for many projects when the services used, the configurations and the requirements are compatible.
The region, however, is verified on the relevant components and not automatically treated as a property of the whole system.
Local or national infrastructure
When certain components must remain in a specific country, infrastructures consistent with that requirement can be used.
Here too we consider the other services that might receive, process or duplicate part of the information.
AI services with residency or sovereignty requirements
Some AI services offer specific options regarding where processing takes place, data retention, infrastructure isolation or operational control.
The actual characteristics vary from provider to provider and are therefore verified on the concrete service, avoiding the use of the “sovereign” label as a generic guarantee.
Self-hosting and dedicated infrastructure
Applications, services or models can be run on dedicated infrastructures or ones under more direct control.
This can increase control over the runtime environment and reduce some external dependencies, but it also shifts greater operational responsibility onto whoever manages the infrastructure.
On-premise and isolated environments
For particularly restrictive needs, and when technically compatible with the project, some components can be installed directly on the organisation’s own infrastructure.
It is also possible to design environments with strongly limited external communication or, in specific cases, none at all.
Greater isolation does not automatically mean greater security.
Patching, monitoring, backups, operational continuity, access control and team expertise remain necessary regardless of where the system runs.
There is no universal ranking
Public cloud, regional cloud, dedicated infrastructure, self-hosting and on-premise are different tools.
More isolation can mean more control, but also more maintenance, greater operational complexity and greater responsibility.
Managed services, on the other hand, can offer significant advantages in terms of updates, resilience, scalability and operational management.
That’s why we don’t choose an architecture because it looks more sophisticated or more reassuring on paper.
We assess data, process, requirements, dependencies and risk. Then we design the level of control that is actually needed.
A responsible use of artificial intelligence
The security of an AI system doesn’t depend only on where the model runs or on what information it can process. It also depends on what the model is authorised to do.
That’s why AI is placed within a system made up of permissions, application rules, validations, and controls.
Not all actions should have the same level of autonomy.
Analysing a document, classifying information, or preparing an email draft can have very different consequences from modifying important data, sending a communication, approving a request, or performing an action that is hard to undo.
For the most relevant or irreversible steps we can therefore introduce additional checks, operational limits, or human confirmation before execution.
In the most sensitive processes we also design the system so that it can handle missing information, uncertain results, errors, and exceptions without being forced to produce an answer or complete an action at all costs.
Autonomy is calibrated to the risk of the process.
Using AI responsibly therefore means defining its perimeter: what information it can process, which tools it can use, which actions it can perform autonomously, and which must instead be validated.
The model is a component of the architecture. Control stays in the system we build around it.
Testing, review and checks before release
Before a solution is actually used, we verify the most important parts of the system.
The checks vary by project and can include automated tests, integration verification, input validation, error handling, permission control, environment configuration, and code review.
For the most complex systems we can complement the internal work with independent technical reviews as well.
The goal isn’t only to verify that a feature operates under the expected conditions, but also to check how it behaves when something doesn’t go as it should: unexpected input, unavailable integrations, insufficient permissions, incomplete data, or unforeseen conditions.
A reliable system shouldn’t only know how to work. It should also know how to fail in a controlled way.
Logging, monitoring and backups
When the project requires it, we implement logging and monitoring to identify errors, anomalies, and unexpected behaviour, while at the same time trying not to collect unnecessary information.
For systems that store important data, we also define backup strategies consistent with the infrastructure used and the criticality of the information handled.
The presence of redundant storage, a NAS or a replica is not automatically considered equivalent to a backup and recovery strategy. The project also has to account for what must be recoverable and for recovery procedures consistent with the criticality of the system.
In more complex custom software, however, the work doesn’t necessarily end with release.
Tests and checks make it possible to verify the system before publication, but some aspects only emerge once the software enters daily work: edge cases, operational exceptions, unexpected behaviour, or steps that can be further refined.
That’s why, depending on the complexity of the project, we can define a period of monitoring and stabilisation in real use.
We observe how the system behaves, analyse what emerges, and gather feedback from the people who use it in the field. This lets us act on the points that need corrections or refinements and further adapt the solution to the real process it was built for.
Before, during and after release
Before development
We analyse the system, the data involved, the integrations, and the points that require more attention. From the start we define measures appropriate to the complexity and risk of the project.
During development
We work with private repositories, controlled access, credentials separated from the code, and distinct environments when needed. Tests and checks accompany development progressively.
Before release
We check the critical parts of the system, the production environment configurations, and the behaviour of the main integrations before real use.
After release
For the most complex software we can plan a period of observation proportionate to the project. It’s the moment when the system meets users, volumes, exceptions, and the dynamics of daily work that can’t always be fully reproduced during testing.
We monitor what happens, analyse any anomalies, and gather feedback from those who actually use the solution, acting on the points that emerge from real use.
When a maintenance service is in place, the work can continue over time through monitoring, updates, and interventions on new needs.
What happens to your data at the end of the project
The end of a project is also part of managing data.
When a collaboration ends or a system is decommissioned, we define, based on the architecture, the services used, and the project agreements, what should be handed over, retained, or removed.
Where provided for, data can be exported in a format usable by the client, and operational copies under our control can be deleted once the activities they were needed for are complete.
Access, technical accounts, credentials, and authorisations are also considered during the closing phase, to prevent them from remaining active without a real operational need.
Deletion, however, doesn’t necessarily mean that every copy disappears at the same instant. Some infrastructures may temporarily retain information within automated backups or disaster recovery systems until the normal rotation provided by the service.
That’s why the actual timing and methods of deletion also depend on the architecture and the providers involved, and are considered during design when they represent a relevant requirement.
The goal is to keep control over the data even when the system is no longer in use.
Security is a continuous process
No software can be considered immune to vulnerabilities.
Technologies, dependencies, infrastructure, and attack methods evolve over time.
The context in which the software operates can change too. Volumes, integrations, team structure and requirements can make it appropriate to reassess architectural choices that were adequate at an earlier stage of the project.
Even a carefully designed system may require updates, checks, and subsequent interventions.
That’s why we prefer to talk about method, controls, and responsibility rather than making absolute promises.
Our work consists of reducing avoidable risks, limiting access, protecting information, and building systems that can be controlled, verified, and maintained over time.
Less unnecessary data. Less superfluous access. More control over what matters.
This is the principle with which we approach security in every project.