Software development policy

On this page

1. 1. Introduction to Software Development in the Company
2. 2. Technological Architecture and Company Stack
3. 3. Software Development Process (SDLC)
4. 4. Environment Management
5. 5. Application Security (AppSec)
6. 6. Source Code Control
7. 7. CI/CD Pipelines
8. 8. Testing and Quality Assurance
9. 9. Data Management and Privacy
10. 10. Deployment and Release to Production
11. 11. Monitoring and Logging
12. 12. Incident Management and Business Continuity
13. 13. Management of Dependencies and External Libraries
14. 14. Software Documentation
15. 15. Software Maintenance and Updates
16. 16. Access Control and Operational Security
17. 17. Management of Third Parties and Suppliers
18. 18. Training and Security Culture
19. 19. Versioning and Release Policies
20. 20. Life Cycle of Patches and Hotfixes
21. 21. Technical summary of the chapters and tools used

Document of the management system of dotenv s.r.l., drawn up by the management system manager (RSGI) and approved by Management. Version 1, first issued 9 December 2025. Normative references: ISO/IEC 27001, ISO/IEC 27002, ISO 9001.

1. Introduction to Software Development in the Company

Software development is one of the central and strategic activities of dotenv s.r.l., not only as a technical skill but as a genuine industrial process, governed by standards, methodologies, controls and shared responsibilities. In a technological context that is constantly evolving, the company recognises the importance of adopting a development model that combines quality, information security, operational efficiency and the ability to adapt to customers’ needs.

dotenv works with an approach oriented towards continuity and improvability, founded on practices that are established at international level and applied every day in its projects. Security is not treated as an accessory element but as a prerequisite intrinsic to every technical decision, from the very first stages of analysis and design. With this in mind, the principle of Security by Design accompanies every component of the process, together with the intention to guarantee reliability, robust code and a high level of maintainability over time.

The organisation of technical work is based on a model that brings together Agile methodologies and DevSecOps practices, integrating development, security and operations in a continuous flow. The various technical roles (developers, DevOps, QA, UX designers, product managers and security officers) collaborate within an ecosystem that is structured yet flexible, where each role contributes directly to the final quality of the software. Technical Management ensures constant supervision, updates the standards, introduces new technologies and promotes a software engineering culture oriented towards transparency, sharing and methodological rigour.

This culture translates into the definition of procedures, tools and guidelines that accompany every stage of development: from requirements gathering to architectural design; from writing the code, to automated verification, through to release into production and the monitoring that follows. Every project therefore becomes the result of a set of structured, repeatable and documented technical practices, which allow the company to ensure not only that the software works correctly, but also that the data processed is protected and that the main ISO/IEC 27001 security standards are complied with.

This document, “Software development policy”, therefore serves as the single reference for all development activities, defining processes, responsibilities, criteria and controls. It supports technical staff in maintaining uniform and correct behaviour, reducing the risk of errors and encouraging a consistent, repeatable approach to the creation of digital products. In addition, the manual forms an integral part of the company’s Information Security Management System (ISMS) and is constantly updated to reflect the evolution of technologies and of the internal organisational models.

2. Technological Architecture and Company Stack

The technological architecture adopted by dotenv s.r.l. is the structural core on which all the software projects carried out by the company are founded. It is not a set of tools chosen at random, but a technical ecosystem designed to be consistent, stable, secure and easily scalable. The technologies used are selected on the basis of their maturity, reliability, adoption in the industry and ability to fit into an operating model based on automated pipelines, segregated environments and continuous control processes.

Over time, the company has consolidated a technology stack that favours modern languages and frameworks, such as JavaScript/TypeScript, Node.js, Next.js, Python, PHP/JAVA and cloud-native technologies, capable of guaranteeing speed of development, ease of maintenance and the ability to respond to different application scenarios, from traditional web systems to specialised microservices, through to Artificial Intelligence components. The choice of these technologies allows the teams to work with familiar, standardised tools, reducing operational complexity and encouraging collaboration between the various departments.

The architecture of the systems follows a modular approach and, where possible, one oriented towards microservices. This makes it possible to separate responsibilities, distribute the load, manage independent updates and proceed with releases that are more frequent and have less impact. In other contexts, where the customer’s needs require centralised management, a structured monolithic architecture is adopted, still shaped by good practices of logical separation and code readability.

Integration with third-party tools takes place through documented and versioned APIs, developed according to uniform guidelines that guarantee compatibility over time and the security of the data exchanged. Every communication between services is protected, traced and subject to automatic checks. Data storage also meets criteria of security and reliability: preference is given to established relational databases and to secure, replicated cloud storage systems, while the management of sensitive information is entrusted to secret management and encryption mechanisms.

The architectural model is never static: it evolves over time to incorporate new technologies, methodologies and patterns. However, this evolution takes place in a controlled manner and always after technical evaluation and approval by Management. Any introduction of new tools is accompanied by a risk analysis, by an assessment of compatibility with the rest of the ecosystem and by precise planning of the impact on projects in progress.

The presence of a consistent infrastructure and of a shared set of technologies allows dotenv to maintain a high level of quality, to reduce operational risk and to guarantee customers robust and secure solutions. The entire technological framework is also designed to support the CI/CD pipelines, the monitoring processes and the incident management logic, which form the basis of the DevSecOps operating model adopted by the company.

3. Software Development Process (SDLC)

The software development process adopted by dotenv s.r.l. is a structured organisational model, designed to guarantee quality, security, consistency and operational continuity in all projects. It is not merely a sequence of technical steps, but a methodological ecosystem based on the integration of analysis, design, development, security, testing and monitoring. Every project goes through a defined, iterative and controlled life cycle, in which technical objectives, functional requirements and operational constraints are constantly balanced.

The entire SDLC is designed to reduce the risk of errors to a minimum, to ensure a shared understanding of the activities and to guarantee that every release is reliable, secure and compliant with company standards. Collaboration between different roles (Product Manager, UX Designer, developers, DevOps, QA, Security Officer and Technical Management) is essential: each role contributes to a specific stage, but all the activities are linked together in a smooth, continuous process.

3.1 Analysis and definition of requirements

Every project begins with a stage of in-depth analysis, aimed at understanding the customer’s objectives, the operational context, the technical constraints and the expected value of the product. This stage does not stop at collecting requests, but aims to turn them into clear, verifiable and measurable requirements. The team carefully assesses the nature of the data processed, the information flows, the usage scenarios, the impact of the features requested and any integrations with third-party systems.

Particular attention is devoted to non-functional requirements: performance, scalability, service availability, security requirements, auditability and regulatory compliance. All these elements help to build a complete picture that guides the architectural choices and the way the work is set up.

At the end of the analysis stage, the company produces shared and approved documentation, which is the official reference for the rest of the project and drastically reduces the possibility of misunderstandings in the subsequent stages.

3.2 User experience (UX) design and UI prototyping

UX/UI design is one of the most strategic stages of the development process. In this stage the product takes shape in a form that can be explored and verified, even before the code is written. dotenv regards prototyping as a fundamental engineering tool, capable of preventing errors and guaranteeing a shared vision between the technical team, stakeholders and the customer.

The starting point is the definition of the main user flows, which describe how the end user will interact with the application. These flows are represented through diagrams and navigation maps that make any logical issues or superfluous steps immediately identifiable.

Next, the UX team develops low-fidelity wireframes, focused on the structure of the information and on the most effective modes of interaction. This stage is characterised by frequent discussion with the technical contacts and with the customer, helping needs to emerge that were not immediately visible during the analysis.

When the structure of the product is consolidated, the team moves on to the creation of high-fidelity prototypes, built in Figma and compliant with the company design system. These prototypes are not mere static mockups, but dynamic, navigable representations of the final interface. They make it possible:

• to validate the user experience before development;
• to identify inconsistent or sub-optimal elements promptly;
• to provide the development team with a clear, complete and unambiguous guide;
• to significantly reduce development times and the risk of rework;
• to anticipate any technical complexities or additional requirements.

The prototyping stage may include usability tests, conducted on a sample of real users or stakeholders, in order to refine the interactions and improve the overall experience.

The final prototype, once approved by Technical Management and by the customer, becomes the official reference document for the development team and forms an integral part of the overall design.

3.3 Technical and architectural design

Once the prototyping stage is complete, the technical team defines the architecture of the system, selecting the patterns, technologies and components best suited to the project. The design considers:

• the overall structure of the application;
• the logic of the microservices or internal modules;
• the management of data flows;
• application and infrastructure security;
• the requirements for integration with external services;
• scalability and resilience;
• the environment configuration plan.

The output is clear, validated architectural documentation, which accompanies development through all its stages.

3.4 Development and writing of the code

The development stage follows principles of quality and security that are deeply rooted in the company culture. Developers work in dedicated branches, adopting the company Git Flow, and produce code that is readable, documented and compliant with the internal guidelines.

Every change is integrated through a Pull Request, subject to review by at least one other member of the team. This approach guarantees stylistic uniformity, knowledge sharing and early detection of any vulnerabilities or anomalies.

In parallel, a series of automatic checks (static analysis, security scans, linting, preliminary tests) helps to maintain a high level of reliability before integration into the main branch of the code.

3.5 Testing, validation and quality control

Testing is an essential component of the process. It is not a final activity, but a set of checks distributed throughout the whole of development. The tests include:

• unit tests on the individual components,
• integration tests between related modules,
• end-to-end tests that validate the user flows,
• regression tests conducted by automating significant scenarios,
• performance and load tests in the projects that require them.

The QA team supervises the entire process, supports the developers and coordinates the User Acceptance Testing activities, carried out in an environment that faithfully replicates production but without the use of real data.

3.6 Deployment and release to the environments

The software is released exclusively through CI/CD pipelines that automate the building, verification and distribution of the application. This approach drastically reduces human error and guarantees repeatability, traceability and security in every release.

Each environment (local development, test, UAT, production) has defined rules and specific levels of control. Access to the environments is restricted and monitored, and the promotion of the software from one to the next is conditional on passing technical and functional checks.

The move to production takes place only after formal approval by the technical and functional managers.

3.7 Post-release monitoring, maintenance and support

After release, the application is constantly monitored through dashboards, metrics and alerting systems. The team checks the stability of the system, identifies any anomalies and intervenes promptly to correct problems or optimise performance.

Maintenance may be:

• corrective, to resolve bugs or operational errors;
• adaptive, to respond to new customer needs;
• evolutionary, to introduce new features;
• preventive, to improve the robustness and security of the application.

Every intervention, regardless of its complexity, follows the standard development cycle and is tracked through the company tools.

3.8 Continuous improvement

dotenv regards its SDLC as an organism in constant evolution. The company periodically carries out retrospectives, internal audits, training sessions and post-incident analyses. These activities aim to constantly improve the quality of the software, optimise the processes and consolidate a technical culture oriented towards responsibility, transparency and professional growth.

4. Environment Management

Environment management is a fundamental component of the operating model of dotenv s.r.l. and is one of the main tools for guaranteeing security, quality and continuity of service. A software environment is not simply a set of servers or containers inside which the code is run: it is a defined, regulated and controlled context, designed to host specific activities of the software life cycle.

The correct separation of environments makes it possible to prevent critical errors, reduce the possibility of operational incidents and safeguard the integrity of the data processed. Each environment, from local development to production, answers to distinctive rules, has different objectives and uses data and configurations calibrated for its purposes. This structure allows the company to operate with methodological rigour, minimising risks and guaranteeing a high level of reliability.

4.1 General principles

dotenv adopts a number of cardinal principles in environment management:

Segregation of duties: each environment hosts exclusively the activities for which it was designed. No overlap between development, test and production is permitted.

Security and access control: access to each environment is limited to authorised roles. Enablement takes place through controlled and recorded procedures.

Zero real data in test environments: no environment other than production may contain sensitive or personal data or data coming from real systems. Data security is a constraint that cannot be waived.

Release automation: the promotion of the software from one environment to another takes place exclusively through CI/CD pipelines, avoiding untracked manual interventions.

Infrastructure consistency: the higher environments (TEST, UAT and PROD) must reflect, as far as possible, homogeneous configurations and behaviours, so as to allow reliable and predictable tests.

4.2 Local development environment (DEV-LOCAL)

The local development environment is the individual working space of the programmers. Each developer works on an isolated copy of the project, runs preliminary tests, experiments with technical solutions and prepares the changes that will then be integrated into the main code.

In this context:

• the data used is synthetic or artificially generated;
• configurations are supplied through separate files, local secrets or environment variables;
• any errors or malfunctions have no impact on the shared environments;
• the supporting tools include Docker, local libraries, API simulations and mock services.

The local environment is the first level of code quality: here the developers verify the correctness of the flows, compatibility with the defined architecture, adherence to the style and the stability of the basic features.

4.3 Test environment (TEST)

The test environment is the place where the software is run after passing through the CI/CD pipeline, in a state that is still preliminary but already integrated with all the main modules.

This environment has two fundamental objectives:

• to verify the technical stability of the system,
• to allow the QA team to run the automated and manual tests.

In the TEST environment:

• only fictitious data or synthetic datasets are used;
• logging and debugging tools useful to the developers are enabled;
• the environment is accessible only to the technical team;
• releases take place frequently and continuously.

Any errors that emerge in this environment can be corrected quickly, thanks to the close integration with the automated pipelines and to the collaboration between QA and developers.

4.4 User Acceptance Testing environment (UAT)

The UAT environment faithfully replicates the production configuration, but without ever containing real data. Its function is to allow the customer or the internal contacts to verify that the software fully meets the agreed requirements and that the features work exactly as intended.

The UAT stage is crucial for:

• validating the user flows in a realistic context,

• anticipating any changes before going into production,

• verifying performance, edge-case behaviours and consistency of the interfaces,

• guaranteeing that the software is ready for the final release.

Access to this environment is limited to selected stakeholders. Every change subsequent to validation requires a new formal approval.

4.5 Production environment (PRODUCTION)

The production environment is the point of arrival of the development path. Here the software is run and used by end users. It is therefore the most protected and most closely monitored environment, and is subject to strict operating policies.

Main characteristics:

• it hosts exclusively real data, processed in compliance with the regulations in force;
• no manual interventions on the files, the servers or the code are permitted;
• every release takes place through a CI/CD pipeline and requires formal approval;
• the monitoring and alerting systems are active 24/7;
• logs are managed according to the criteria of the ISMS, with particular attention to data confidentiality.

The stability of production is a shared responsibility, but one supervised in particular by the DevOps department and by Technical Management.

4.6 Configurations, secrets and environment variables

Each environment uses its own configurations, adapted to its objectives and protected according to security policies. Credentials, API keys, tokens and all sensitive elements are kept in secure secret management systems and are never placed in the source code or in the repositories.

Periodic rotation of secrets, separation by environment and access control guarantee the protection of critical information at every stage of the process.

4.7 Logging, auditing and monitoring

Each environment is equipped with logging systems calibrated according to its purpose:

• in the first environments, more extensive logs useful for debugging are kept;
• in UAT and PROD, sensitive data is filtered out and formats consistent with the ISMS policies are adopted.

Continuous monitoring makes it possible to quickly identify anomalies, performance degradation or unexpected behaviours. Significant events are recorded for subsequent analysis, contributing to continuous improvement processes and to any incident response activities.

4.8 Software promotion and version control

The passage of a version of the software from one environment to the next follows a rigorous path:

• TEST → UAT takes place only after the QA checks have been passed;
• UAT → PRODUCTION requires the approval of the customer (or of the PM) and of the technical manager;
• no environment may be skipped;
• no deploy may take place outside the authorised pipeline.

This model guarantees complete traceability, predictable behaviour and a significant reduction in operational risks.

5. Application Security (AppSec)

Application security is a central element of the way in which dotenv s.r.l. conceives and builds its software projects. In a digital context in which applications talk to external systems, process sensitive data and operate in distributed environments, the protection of the software cannot be considered an after-the-fact activity, nor a simple technical step to be carried out at the end of development. On the contrary, it is a cross-cutting discipline that accompanies every stage of the software life cycle, from the initial design through to maintenance in production.

The approach adopted by the company is founded on the principles of Secure by Design and Secure by Default, according to which every application must be born with a secure structure, reducing the attack surfaces as far as possible and providing adequate controls at each critical point of the system. This means that security is not entrusted to a single role, but is a responsibility shared between developers, architects, DevOps, QA and security roles. Each one contributes, through their daily work, to building an application ecosystem that is robust, reliable and resilient.

5.1 General principles

In developing new features, dotenv’s engineers work from the assumption that no data is intrinsically trustworthy and that every software component must be designed taking into account the possibility of improper or malicious use. The application logic is organised into separate modules that are easy to control; the flows are analysed to identify possible points of weakness; the features are designed with the minimum level of exposure necessary. This approach makes it possible to significantly reduce the risk of attacks and incidents linked to the software.

5.2 Vulnerability prevention according to OWASP

The main reference for vulnerability prevention is the OWASP guidelines, in particular the Top 10, which summarises the most frequent risk categories in the modern application landscape. Developers are trained to recognise the mechanisms that generate common vulnerabilities, such as injection, improper session management, unintentional exposure of sensitive information or incorrect configuration of the environments. Knowledge of these cases allows the team to anticipate problems and to build solutions that avoid introducing known risks, reducing dependence on external controls and making the software more solid from its foundations.

5.3 API security

Since a large part of modern applications communicates through APIs, their protection is considered a priority. Every API is designed with an adequate level of authentication and authorisation, favouring

secure techniques such as the use of structured tokens or server-side sessions. Payloads are carefully validated, communications take place exclusively through encrypted protocols and every interaction is recorded so as to allow audits and subsequent analysis. Documenting the APIs through OpenAPI specifications also guarantees clarity and uniformity, reducing ambiguity during development and integration with third-party systems.

5.4 Dependencies and external libraries

An increasingly critical aspect of application security concerns the use of components developed by third parties. Although these tools speed up the work and make it possible to introduce advanced features efficiently, they are also a possible source of vulnerabilities. For this reason, every project is monitored through automatic analysis tools that identify obsolete or potentially compromised versions, suggesting updates or more secure alternatives. The team intervenes promptly when new public vulnerabilities emerge, making sure that critical dependencies are kept in optimal condition.

5.5 Management of sensitive data and secrets

The protection of sensitive data is one of the cornerstones of dotenv’s operating model. All confidential information (keys, tokens, passwords, certificates) is kept through secret management systems that prevent unauthorised access and guarantee its traceability. No sensitive data is ever placed in the source code, in the repositories or in unprotected files. Environment variables vary according to the execution context and are accessible only to authorised identities. Likewise, user data is encrypted both in transit and at rest, ensuring an adequate level of protection regardless of the infrastructure used.

5.6 Authentication, authorisation and session management

The systems that manage users and permissions are designed with mechanisms that are robust and resistant to the most widespread attacks. Sessions are protected with techniques that prevent theft or manipulation; passwords, where present, are stored with secure hashing algorithms; access attempts are monitored; and permissions are assigned following a rigorous model of roles and responsibilities. Every change to the authentication system is subject to in-depth checks to guarantee that any changes do not compromise the existing security.

5.7 Automatic checks and code review

Security does not depend exclusively on the good practice of the developers, but also on the integration of automatic tools that make it possible to identify errors or vulnerabilities promptly. The continuous integration pipelines include static code analysis checks, dependency scans, checks on container images and compliance checks, alongside which there is manual review through Pull Requests. This double level, automatic and human, makes it possible to quickly identify anomalies, design errors or unintended behaviours before they can reach the test or production environments.

5.8 Logging, monitoring and incident management

The ability to identify a problem promptly is as fundamental as prevention. For this reason, every application is monitored in production through a centralised system that analyses significant events, errors, response times, sudden variations in traffic and suspicious access attempts. The alerts generated by the system are handled by the DevOps team and by the Security Officer, who analyse the nature of the anomaly and intervene quickly when necessary. In the event of an incident, the company follows a structured procedure that includes the collection of evidence, the assessment of the impact, internal communication and the definition of corrective measures.

5.9 Security culture

Maturity in application security is not achieved only through tools and procedures, but through the evolution of the internal culture. Technical staff regularly take part in training and refresher sessions, with the aim of maintaining a high level of awareness of emerging risks and of industry best practices. Security thus becomes a daily habit, a lens through which every technical choice is assessed.

6. Source Code Control

Source code control is one of the fundamental elements that guarantee the quality, security and traceability of the software developed by dotenv s.r.l. Over time, the code has become not only the result of technical work, but a genuine company asset that must be protected, governed and preserved through structured processes. For this reason, the company has defined a versioning management model that favours rigour, transparency and collaboration between the members of the team.

Every project lives inside dedicated repositories, which are not simply file archives, but tools that narrate the evolution of the software. Every commit, every branch, every pull request is a piece of the project’s history, making it possible at any time to reconstruct technical decisions, identify regressions or analyse critical issues. This traceability is essential not only for the developers, but also for management, security and internal audits.

The operating flow adopted by dotenv provides for every contribution to be developed in isolated branches, and then integrated into the main branch through a controlled and approved process. The Pull Request is the centre of this dynamic: a moment of discussion, review and collective verification. Code review is not a formal obligation, but a professional ritual that helps to guarantee the quality, security and homogeneity of the software. The ability to read and comment on other people’s code, in a constructive spirit and with technical care, is one of the pillars of the team’s maturity.

Alongside this model, in a complementary way, there is the practice of pair programming, introduced by dotenv as a tool to improve the quality of the code and encourage greater uniformity of technical solutions. Pair programming is not intended as a daily obligation, but as a method to be used at times when the complexity of the problem, the criticality of the feature or the need to transfer internal knowledge make direct collaboration useful. Two developers working side by side, alternating the roles of driver and navigator, can identify more elegant solutions, prevent conceptual errors, reduce debugging times and improve the architectural consistency of the project. In addition, pair programming encourages alignment between members with different skills, reduces information silos and speeds up the onboarding of new resources into the team. In this sense, it is not only a development technique, but an investment in the collective growth of the group.

In parallel, dotenv is introducing in an increasingly structured way the use of static code checkers, tools able to analyse changes automatically even before they are run. These checks, integrated into the development pipelines, identify suspicious patterns, known vulnerabilities, incorrect references, potentially dangerous behaviours and deviations from company standards. Their presence does not reduce the value of manual review, but strengthens it: while human feedback identifies conceptual, architectural or stylistic problems, static analysis makes it possible to intercept subtle errors and vulnerabilities that are difficult to detect at a glance.

The entire source code control ecosystem (structured repositories, branching processes, mandatory pull requests, code review, pair programming and static checkers) creates a development environment in which quality, security and collaboration are not occasional results, but direct consequences of an established methodology. This system allows dotenv to guarantee software that is reliable, consistent and ready to grow over time, reducing risks and consolidating an operating model that is mature, modern and sustainable.

7. CI/CD Pipelines

Continuous Integration and Continuous Delivery pipelines are one of the most characteristic and strategic elements of the development model adopted by dotenv s.r.l. Over the years, the company has come to understand that the quality of software cannot depend exclusively on the ability of individual developers, but must be supported by automatic, repeatable and reliable processes, able to identify errors before they can reach the most delicate environments.

The CI/CD pipelines are therefore an invisible but essential infrastructure, whose task is to accompany every change to the code through a series of verifications, checks and automated steps that guarantee its stability and its compliance with company standards. Every commit, every pull request and every release passes through this structured system, which acts as a continuous filter protecting the quality of the software.

Continuous Integration is the first level of this process. Every time a developer introduces a change, the pipeline rebuilds the project from scratch, runs the automated tests, starts the static checkers and verifies that the code complies with the quality and security rules defined internally. This makes it possible to identify conflicts, regressions and problematic dependencies at an early stage, drastically reducing the cost of errors and guaranteeing a constant level of stability across the whole of the source code. Frequent integration of the work prevents the project from fragmenting into unaligned subsystems and promotes greater consistency between the members of the team.

Continuous Delivery comes in at the next stage, when the code has already passed all the preliminary checks. At this point, the pipeline takes care of preparing the software for distribution to the higher environments, automatically managing the creation of the packages, the application of the necessary configurations and the orchestration of the steps towards the test, UAT and finally production environments. The process is completely free of manual interventions and guarantees that every release is repeatable, tracked and compliant with the security rules laid down by the ISMS. The pipeline thus becomes an extension of the DevOps team, automating activities that in the past would have required time, attention and specialised resources.

What most characterises dotenv’s model is the close integration of the pipelines with security. The whole system is designed in compliance with DevSecOps principles: static code analysis, dependency checking, scanning of container images and verification of infrastructure configurations become an integral part of the process. In this way, potential vulnerabilities or incorrect configurations are identified well in advance, preventing them from reaching the most delicate environments or compromising the security of the entire system. The pipeline thus takes on the role of a constant, attentive and rigorous guardian, watching over the correctness of the end-to-end process.

A further advantage of the CI/CD model adopted is its ability to encourage speed without sacrificing quality. Each team can release new features frequently, knowing that every step is

supported by reliable checks and by automatic mechanisms that reduce the risk of failures. This allows the company to respond quickly to customers’ needs, to experiment with greater confidence and to maintain a competitive pace of development.

Finally, the pipeline also performs a function of implicit documentation: every stage of the process, from the build to the distribution, leaves a trace in the logging and auditing systems. This makes it possible to trace back to the origin of any problems, to monitor the performance of the process itself and to improve it over time. The company can analyse trends, identify bottlenecks, measure the average quality of the releases and adopt corrective actions based on real data, thereby strengthening the continuous improvement model.

Taken as a whole, the CI/CD pipeline is much more than a set of scripts or technical configurations: it is a genuine operational pillar, which embodies the principles of quality, security and reliability on which the software developed by dotenv is based. Thanks to it, every project can evolve in an orderly, predictable and secure way, supporting a modern vision of software development that values collaboration, automation and shared responsibility.

8. Testing and Quality Assurance

Testing is a central and indispensable stage of the life cycle of the software developed by dotenv s.r.l. and is conceived not as a final check, but as a genuine continuous process that accompanies the entire course of the project. The company regards quality control not as a task assigned exclusively to a dedicated function, but as a commitment shared between all the roles involved in development. Every developer, every designer and every member of the DevOps team contributes, directly or indirectly, to guaranteeing that the software is reliable, stable, secure and consistent with the customer’s expectations.

The discipline of testing therefore has a dual nature: on the one hand it verifies the correctness of the technical behaviour of the application, on the other it becomes a tool that makes it possible to maintain the integrity of the design over time. In a complex and constantly evolving context, in which new features are introduced frequently and the systems must guarantee ever higher levels of reliability, testing plays the role of a preventive protection mechanism, capable of promptly identifying anomalies, regressions or inconsistencies.

Software development at dotenv provides for verification activities to begin from the earliest stages. While the developers build new features, they produce at the same time unit tests and integration tests that make it possible to validate the correctness of the individual modules and of their aggregate behaviour. This practice makes it possible to intercept errors very early, when they are often less costly to correct than in the more advanced stages of the project. In addition, the continuous running of these tests through the integration pipeline guarantees that every change is assessed in the light of the wider context of the application.

Alongside the tests produced by the developers, the team dedicated to Quality Assurance plays a complementary and fundamental role. QA does not stop at verifying that the software works correctly, but takes care of assessing the overall quality of the user experience, consistency with the requirements, the stability of the behaviours and adherence to internal standards. This additional perspective makes it possible to complement the technical view with a more functional dimension, focused on the value for the end user. The work of QA starts from the design of test scenarios and test cases that derive from the flows defined during UX/UI prototyping and continues with systematic activities of manual and automated validation.

A particularly delicate part of this process concerns end-to-end testing, which has the task of reproducing the user’s experience across the entire system. These checks include complete paths, interactions with several components and the running of complex scenarios that make it possible to observe the behaviour of the application in conditions similar to real ones. The objective is not only to guarantee that the

software responds correctly to expected inputs, but also to verify its resilience, its ability to react to error conditions and the consistency of its interface.

To these activities are added regression tests, which are fundamental for preserving the stability of the application over time. Every new feature inevitably introduces changes to the existing code and can affect elements that are not directly related. For this reason, the company maintains and enriches a set of automated tests that are run continuously at every release, ensuring that nothing that was working is compromised. This set of checks is a sort of living archive of the quality of the software.

Particular attention is also given to performance tests, used in projects that require high scalability or that must guarantee particularly short response times. These analyses make it possible to identify bottlenecks, inefficiencies or anomalous behaviours under load, offering valuable indications for infrastructure optimisations or improvements in the application logic. Likewise, in specific cases resilience tests and security tests are conducted, adding further levels of assurance on the overall solidity of the system.

Testing reaches its most significant moment in the User Acceptance Testing (UAT) environment, where the application is examined by real users or by the customer’s stakeholders. In this context, QA has the task of preparing a verification scenario consistent with the expected behaviour of the product and of accompanying the validation process, making sure that all the features reflect expectations and that the application is fully ready for production. The UAT stage is not a simple green light, but a moment of real discussion, in which considerations linked to usability, to the clarity of the flows and to the overall perception of the experience also emerge.

Finally, the entire testing process is supported by the principle of continuous improvement. The tests, like the procedures that govern them, are reviewed periodically to guarantee that they remain relevant, effective and in line with the technological evolution of the company. Every incident, every unexpected behaviour and every edge case identified over time is turned into a new test case or into an expansion of the existing ones, progressively enriching the organisation’s body of knowledge.

The overall result is a mature Quality Assurance system, capable of accompanying software development with technical rigour and functional sensitivity, ensuring products that are reliable and able to adapt over time to the needs of customers and to the complexity of the application contexts.

9. Data Management and Privacy

For dotenv s.r.l., data management and the protection of privacy are a founding element of its organisational model. Every application developed by the company processes information that can take on different levels of sensitivity and confidentiality, up to and including personal data, data subject to regulatory obligations or customers’ strategic information. For this reason, data protection is not a technical appendix, but a structural value that runs through every stage of the software life cycle, from the initial design through to the decommissioning of the systems.

The company philosophy is based on the principle of privacy by design, according to which data protection must be integrated from the birth of a project, and not applied later as an accessory measure. This entails a preliminary assessment of the nature of the data processed, of the associated risks and of the measures necessary to reduce the exposure of the information to a minimum. The design of the information flows considers from the outset how the data must be collected, stored, transformed, transmitted and finally deleted, ensuring an adequate level of security at every step.

One of the cardinal principles followed by the company is that of minimisation: only the data that is really necessary for the intended features to be carried out is collected, and every non-essential piece of information is

excluded or anonymised. This attention is reflected not only in the design of the interfaces and of the databases, but also in the APIs, in the logging systems and in the ways in which the data passes through the various environments. In no case do environments other than production contain real data; when necessary, synthetic datasets or masking techniques are used that eliminate any possibility of recognising the users.

The security of data in transit and at rest is a further fundamental principle. All sensitive communications take place through encrypted protocols, and the information stored in databases, in file systems or in cloud services is protected by robust encryption mechanisms. The management of keys and secrets is entrusted to secure secret management systems, which prevent unauthorised access and guarantee precise control over who can view or use critical credentials. No key is placed in the source code or in the repositories, and access to secrets is strictly regulated on the basis of roles and operational responsibilities.

The processing of personal data is also approached with rigorous care. Every project is assessed in the light of the obligations imposed by the GDPR, verifying the legal basis of the processing, the nature of the information processed, the need for notifications to the customer and any additional measures required for special categories of data. In the most complex cases, a data protection impact assessment (DPIA) may be conducted, in order to analyse the risks in advance and establish the most appropriate countermeasures. The team involved in development receives clear instructions on how to process the data, while the technical documentation reports all the measures implemented to guarantee compliance and security.

An essential part of data protection concerns the ways in which data is tracked and observed over time. Logging and monitoring activities too, although necessary to guarantee stability and visibility over the operation of the systems, must respect the privacy of the users. Logs are therefore built so as to avoid the inclusion of unnecessary personal information and are subject to retention policies that are limited and consistent with the operational purposes. Every access to the logs and to sensitive data is monitored and recorded, helping to guarantee transparency and accountability.

No less important is the final stage of the data life cycle. When a project ends, or when specific information is no longer necessary, the company applies secure deletion procedures, ensuring that no residual copy remains accessible in the production systems or in the support environments. The deletion of data is not considered an automatic act, but a delicate activity that requires method, supervision and verification.

The entire data management and privacy system is based on an attentive and aware internal culture. Every member of the team is made aware of the importance of data protection and is trained periodically on best practices, on emerging threats and on the responsibilities linked to information security. This widespread attention, combined with solid technical procedures and with an approach oriented towards transparency, allows dotenv to guarantee its customers an approach that is reliable and compliant with the regulations in force.

Data protection is therefore not only a regulatory requirement, but a constant commitment that accompanies every project and that is one of the fundamental pillars of the way in which the company develops software.

10. Deployment and Release to Production

Deployment and release to production are the most delicate moment of the entire life cycle of the software developed by dotenv s.r.l. After weeks or months of analysis, design, development, verifications and checks, the product must move from the controlled context of the internal environments to the operational reality of the end users. This step requires method, rigour and careful management of risks, since any anomaly introduced at this stage can have a significant impact on the continuity of the service, on the security of the data and on the overall perception of the system.

dotenv has chosen to adopt a highly automated release model, in which every operation necessary for the publication of the software is orchestrated through CI/CD pipelines. This approach eliminates the possibility of manual errors, guarantees the repeatability of the process and ensures that every release is carried out exactly in the manner laid down by the system. The pipeline thus becomes the single, reliable control point through which every version of the software passes before reaching production.

The release process begins long before the actual deploy. When a new feature or a fix is considered ready, the code has already been subjected to an articulated set of checks: static analysis, dependency checks, unit tests, integration tests and end-to-end tests. Only after passing these preliminary stages can it be put forward for publication. The move to the UAT environment makes it possible to obtain further confirmation from the customer’s stakeholders, who verify the real behaviour of the features in a context close to production but without real data.

Once formal approval has been obtained, the deployment process proceeds towards the production environment following a controlled sequence. The software is packaged, configured with the parameters specific to the environment and distributed through automated mechanisms that ensure uniformity between versions. The pipeline also carries out a series of final checks, verifying that the resources necessary for execution are available, that the connected services respond correctly and that there are no unresolved dependencies.

The management of the infrastructure plays an equally central role. Whether the system is run on dedicated servers, distributed containers or cloud services, the objective remains the same: to guarantee that the release takes place in an environment that is stable, isolated and correctly configured. Every infrastructure change follows the same rigour as the application code and is applied through Infrastructure as Code procedures, which make it possible to keep the environments synchronised and to rebuild them quickly if needed.

During and after deployment, dotenv activates careful monitoring of the behaviour of the application. The first minutes after publication are considered particularly critical and are analysed with care, observing metrics such as response times, resource consumption, error frequency and access trends. In the event of an anomaly, the team can intervene quickly thanks to the traceability offered by the pipeline and to the automatic or semi-automatic rollback functions, which make it possible to restore the previous version in a very short time.

The release procedure is not only a set of technical operations, but a shared responsibility that requires coordination between developers, QA, DevOps and Technical Management. Each role contributes to guaranteeing that what reaches production is not only functional, but stable, secure and consistent with the company’s operating standards. The internal culture itself, shaped by transparency and continuous improvement, provides for every release to be analysed retrospectively in order to identify opportunities for optimisation and to prevent any critical issues from being repeated.

The result of this structured approach is a deployment process that is reliable, controlled and sustainable, which allows dotenv to maintain a rapid pace of development without compromising the stability of the service. Release to production thus becomes a measured and conscious act, supported by advanced automation and by solid technical discipline, thanks to which the software can be brought to end users with confidence and predictability.

11. Monitoring and Logging

Monitoring and logging are two fundamental components of the operating model of dotenv s.r.l., since they make it possible to observe the real behaviour of the applications, to prevent problems before they can affect users and to guarantee a constant level of reliability over time. In a modern software

context, characterised by distributed architectures, interconnected services and heterogeneous environments, visibility over internal operations is an indispensable requirement for ensuring stability, security and continuity of service.

Monitoring is not limited to the simple collection of technical metrics, but is a broader and more systematic approach to understanding the state of health of the system. Every application is observed through a set of indicators that describe its ability to respond to users, to handle the load, to preserve the integrity of the data and to meet the expected performance. The technical team uses centralised tools able to collect this information in real time and to return a clear and immediate view of how the system is performing. This visibility is fundamental for anticipating potential problems, avoiding service interruptions and maintaining a high level of operational quality.

Logging plays an equally central role. Every application generates events, errors, warnings and operational information which, if appropriately collected and organised, are a valuable source for both diagnostics and security. Logs are not only an archive of technical messages, but a knowledge base that makes it possible to reconstruct precisely what happens inside the system, facilitating the analysis of anomalies, the resolution of problems and the understanding of unexpected behaviours. The company attaches great importance to the structure, clarity and consistency of the logs, so that they can be used effectively even after some time has passed.

The management of logs does, however, require great care, in particular when they may contain information that is sensitive or accidentally traceable to users. dotenv therefore applies rigorous criteria to avoid the recording of unnecessary personal data, and defines clear rules on the retention and processing of, and access to, such information. Logs are filtered, anonymised where appropriate and kept for a period commensurate with their operational usefulness, avoiding improper accumulation or non-compliant processing. This attention makes it possible to respect the principle of minimisation and to align fully with the requirements of the GDPR and of the regulations in force.

The monitoring system is closely integrated with the alerting mechanisms, which make it possible to intercept anomalous situations in real time and to notify the technical teams of them promptly. The operation of an application is not in fact constant over time: it can be influenced by load conditions, user behaviours, infrastructure variations or external events. Alerts make it possible to react immediately to unforeseen errors, significant slowdowns, anomalous increases in traffic or conditions that are potentially risky for the integrity of the data. The objective is not only to resolve the incident quickly, but also to prevent it from recurring.

Monitoring takes on a particularly high value in the stages following releases, when the system is observed with greater attention to verify that the changes introduced have not altered the expected behaviour. This practice, often called “post-release observation”, makes it possible to quickly identify subtle regressions, unforeseen impacts or unexpected interactions between components. The team can thus intervene promptly, adopting corrective solutions or, when necessary, restoring the previous version of the software.

A further benefit of monitoring and logging lies in their contribution to continuous improvement processes. The data collected over time makes it possible to identify recurring patterns, weak points in the infrastructure, inefficiencies in the application flows or problematic user behaviours. This knowledge becomes a valuable element for guiding strategic optimisations, improving the quality of the software and planning the evolution of the systems with a perspective based on concrete evidence rather than on assumptions.

Finally, monitoring and logging play a crucial role in the field of IT security. The ability to detect suspicious accesses, anomalous behaviours or intrusion attempts is an essential component of the company’s defence model. The integration of the monitoring systems with behavioural analysis tools and with structured incident response processes makes it possible to deal with security events promptly and effectively, reducing risks and protecting the customers’ information assets.

Taken together, monitoring and logging are not simple technical features, but genuine pillars of dotenv’s operational reliability. They make it possible to maintain the stability of the service, to continuously improve the quality of the software and to guarantee an application ecosystem that is secure, transparent and constantly evolving.

12. Incident Management and Business Continuity

Incident management and the guarantee of business continuity are essential elements of the organisational model of dotenv s.r.l., since they are the mechanism through which the company ensures that its services remain reliable, secure and available even in the presence of unforeseen events or anomalies. Every software system, regardless of its robustness, is inevitably exposed to risks: application errors, infrastructure malfunctions, interruptions of external services, cyber attacks or simply unexpected behaviours can compromise normal operations. For this reason, dotenv has built a structured model that makes it possible to identify incidents promptly, to contain them and to bring the system back to full functionality in the shortest possible time.

Incident management begins with the ability to recognise incidents. Thanks to the monitoring, logging and alerting systems described in the previous chapter, the company has a constant, real-time view of the behaviour of its services. Every deviation from the expected metrics, every recurring error or every anomalous peak in traffic may be a signal to be analysed. The objective is not to react impulsively, but to activate an orderly process, based on clear roles and defined responsibilities. The technical team assesses the nature of the anomaly, its severity, the impact on users and the risk of it evolving, and decides accordingly whether to activate the formal incident management procedure.

When an incident is confirmed, an operating flow comes into play whose task is to contain the impact quickly and to restore normal operations. The roles involved collaborate in a coordinated way, sharing information, evidence and hypotheses. Internal communication becomes fundamental to avoid delays or unaligned interventions. The main objective is to re-establish the availability of the service in the shortest possible time, while preserving the integrity of the data and the security of the environment. In some cases, it may be necessary to apply rollback procedures to a previous version of the application; in others, a surgical intervention is made on specific configurations or components.

A central aspect of dotenv’s model concerns the documentation of incidents. Every significant event is recorded, described and analysed after resolution, not only to reconstruct what happened but also to identify the root causes that allowed it to occur. This process, known as post-incident review, makes it possible to turn every critical issue into an opportunity for improvement. The company pays particular attention to distinguishing between symptoms and causes, assessing whether it is necessary to modify procedures, strengthen controls, introduce new tests or improve the architecture of the system itself. The objective is not to attribute blame, but to build a context that is more resilient over time.

Business continuity is the natural completion of incident management. It is a broader concept, which is not limited to reacting to unforeseen events, but concerns the company’s ability to ensure that essential services can continue to operate even in the presence of adverse scenarios. dotenv plans and structures its technological solutions so as to guarantee redundancy, scalability and recoverability. Critical systems are designed so that they can be restored quickly in the event of malfunctions, through regular backups, replication techniques, infrastructure snapshots and automation tools that make it possible to rebuild environments or applications with precision and speed.

Organisational aspects also play an important role in business continuity. Technical staff are trained to handle emergency situations and to understand which interventions require absolute priority. Communications to customers, when necessary, are carefully assessed and managed in a transparent and professional way, avoiding alarmism but offering information that is clear and appropriate to the context.

The model adopted by dotenv recognises that continuity is never guaranteed once and for all, but requires constant commitment. The procedures are reviewed periodically, the tools updated, and the monitoring systems enriched on the basis of the experience gained. Every incident handled, every anomalous behaviour detected and every piece of customer feedback helps to make the entire ecosystem more stable, more secure and more mature.

In this sense, incident management and business continuity are not only obligations laid down by security standards, but are an integral part of the company’s technical culture. dotenv regards this discipline as a strategic investment, useful for protecting not only the applications developed, but also the trust of its customers and the perceived quality of the services it offers.

13. Management of Dependencies and External Libraries

The management of dependencies and external libraries is one of the most delicate aspects of modern development, since a significant part of software is no longer built entirely inside the company, but derives from components coming from open source ecosystems or from third-party suppliers. Over the years this evolution has made it possible to speed up development times, integrate advanced features and benefit from the collective work of global communities. However, it also introduces a series of risks that must be addressed with awareness, method and discipline.

dotenv s.r.l. regards every external dependency as a component which, although not developed internally, becomes an integral part of its product and, consequently, of its level of responsibility. Every library used within a project has implications that are not only technical but also legal, operational and security-related. For this reason its adoption is never a casual act, but the result of a considered process that carefully assesses the reliability of the source, the quality of the maintenance, compatibility with the architecture of the system and the impact that a possible vulnerability in it could have on the entire project.

The process begins with a preliminary assessment of the dependency. Before introducing a library, the developers verify its maturity, the presence of an active community, the frequency of updates and the reputation of the project. The objective is not to automatically favour the most popular components, but to choose those that are truly sustainable over time, that offer guarantees of stability and that do not force the platform to tie itself to technologies that are hard to control. This stage of preventive assessment is a form of long-term protection, since it makes it possible to avoid choices that could generate significant problems in the subsequent stages of the life cycle.

Once a dependency has been introduced, controlling it becomes a permanent responsibility. The presence of external libraries makes the application sensitive to vulnerabilities that do not depend on the code written by the company, but that can nevertheless compromise the security of the entire ecosystem. For this reason dotenv integrates automatic analysis tools into its process, placed inside the CI/CD pipelines and capable of identifying obsolete versions, abandoned libraries, insecure dependencies or components with known vulnerabilities published in the international security databases. These checks are not run as a one-off, but are part of the daily integration flow, so as to guarantee that any problems emerge promptly.

Alongside the technical component, the management of dependencies also involves an assessment of licences. Every library introduces a legal relationship, explicit or implicit, with the project from which it derives. It is therefore necessary to verify that the conditions of use are compatible with the customer’s objectives and with the

distribution model of the product. dotenv pays particular attention to avoiding libraries that impose incompatible limitations, overly restrictive clauses or obligations to open the code. This sensitivity makes it possible to protect both the company and the customers who will receive the final product.

The maintenance of dependencies is a continuous process and does not end with their introduction. Libraries must be updated over time, balancing two needs: on the one hand the need to keep the software secure and aligned with the most recent standards, on the other the importance of avoiding ill-considered updates that could generate regressions or incompatibilities. The decision to update a dependency is therefore assessed considering the state of the project, the criticality of the vulnerabilities detected, the stability of the new versions and the expected impact on the existing features. This approach avoids impulsive interventions and makes it possible to operate with awareness and continuity.

Finally, dotenv regards the management of dependencies as a cultural aspect, as well as a technical one. The development team is encouraged to understand in depth the libraries it introduces, avoiding “plug and play” approaches and favouring solutions that are really necessary and well integrated with the architecture. The guiding principle is that of parsimony: use what is needed, and only what is needed, with full responsibility towards the quality and security of the product.

As a whole, the management of dependencies and external libraries therefore takes the form of an articulated activity that requires rigour, constant attention and technical maturity. Thanks to this approach, dotenv is able to offer software that not only meets the functional requirements, but complies with high standards of security, sustainability and reliability, reducing the risk that an external component becomes a point of fragility for the entire system.

14. Software Documentation

Software documentation is one of the most essential components of the life cycle of the projects developed by dotenv s.r.l., since it guarantees continuity, transferability of knowledge, transparency in the processes and reduction of operational risk. Software without clear and up-to-date documentation becomes, over time, difficult to maintain, to evolve and to understand, especially in contexts in which several teams, suppliers or departments contribute to the same digital ecosystem. For this reason, documentation is not considered a secondary or optional activity, but a strategic tool that accompanies every stage of development.

The production of documentation begins from the earliest stages of the project, during requirements gathering and architectural design, and continues during the development and release of the features. This incremental approach makes it possible to reflect in the document not only what the system must do, but also how it was designed and why certain technical decisions were taken. Documentation is therefore not limited to a static description of the system, but appears as a structured account of the evolution of the project, useful both to the development team and to the customer’s technical contacts.

A particularly important component of documentation concerns APIs, today a central element of most modern software systems. dotenv regards API documentation not simply as a technical attachment, but as a formal contract between the application and the systems that will have to talk to it. The clarity of this contract is fundamental for avoiding ambiguity, incompatibility or integration errors, and guarantees that every service exposed is interpreted in a single way, leaving no room for subjective interpretations.

For this reason, the company systematically adopts the OpenAPI standards (in their implementation commonly called Swagger), which make it possible to describe in a detailed and readable way all the characteristics of the APIs: available endpoints, input parameters, data formats, response codes, exported models and relationships between resources. The use of Swagger does not have a purely documentary function; it is instead a genuine operational tool that guides development, allows the backend and frontend teams

to work in a coordinated way and encourages integration with external systems. Documentation thus becomes a living element that is always up to date, since it derives directly from the code and is versioned together with it.

Thanks to Swagger, the entire integration system benefits from greater predictability. Technical partners can understand how the APIs work without needing access to the code or continuous discussions with the developers; testers can build verification cases consistent with the specifications; backend designers can identify compatibilities and dependencies more simply; and automatic tools can generate clients, validators or simulators starting from the specification. The adoption of the OpenAPI standard is therefore an essential element for guaranteeing quality, security and speed in development.

Alongside the API documentation, general technical documentation of the software is maintained, which describes the architectural structure, the information flows, the internal dependencies, the main configurations and the critical aspects of the system. The purpose of this documentation is to offer an overview of the application and to support long-term maintenance. The language used is clear and oriented towards understanding, avoiding superfluous technicalities, but including all the elements necessary for a new member of the team to be able to understand the system quickly.

A further dimension is represented by operational documentation, which describes procedures, scripts, environment configurations, deploy steps and expected behaviours in the various contexts. This type of documentation is particularly useful to the DevOps teams and guarantees that the management of the infrastructure is repeatable, verifiable and consistent with the security model adopted.

Documentation is always kept in the same repositories as the code, or in spaces closely linked to them, so as to guarantee that it evolves in step with the software. Every significant change to the system entails an update of the documentation, and every release to production requires verification that all the relevant documents are aligned with the current version of the product.

Finally, dotenv regards documentation as a shared responsibility. Every developer contributes, updating what concerns their own area of intervention and thereby making the company’s information assets consistent and accessible. It is not a formality, but a strategic investment that allows projects to remain solid and maintainable over time, regardless of changes in personnel, technological evolutions or expansions of the product.

Thanks to this approach, software documentation is not a static artefact, but a dynamic, living element that is fundamental to the success of every project. It guarantees operational continuity, technical clarity, quality of future developments and, above all, reliability for the customers who will use and integrate the solutions developed by the company.

15. Software Maintenance and Updates

Software maintenance is a fundamental activity for guaranteeing that the applications developed by dotenv s.r.l. remain reliable, secure and aligned with the customer’s needs over time. In a technological ecosystem that is constantly evolving, where new vulnerabilities emerge daily and operational needs can change rapidly, software is never a static product. On the contrary, it is an organism that requires constant care, scheduled updates and selective interventions to preserve its performance and its integrity.

dotenv approaches maintenance as a structured process, which is not limited to solving problems or introducing new features, but includes a set of activities aimed at preserving the overall health of the system. Every intervention, even the apparently simplest one, is placed within the standard development cycle, following the same procedures of analysis, verification, integration and release applied to

ordinary development. This approach guarantees that nothing is introduced into production without passing through the usual technical, quality and security checks.

Corrective maintenance comes into play when an application shows unexpected behaviour or a malfunction. In these cases, the objective is to quickly restore the correct operation of the system, reducing the impact on users to a minimum. Every problem is carefully analysed to understand its origin and to prevent it from recurring in the future. The resolution is not limited to a superficial intervention, but is accompanied by a review of the parts involved, by any additional tests and, when necessary, by the introduction of preventive or improvement measures.

Alongside corrective maintenance, great importance attaches to evolutionary maintenance, dedicated to introducing new features, improvements to the interface, optimisations of the flows or extensions of the existing architecture. This type of intervention allows the software to grow together with the customer’s needs, keeping the value of the application alive and guaranteeing its ability to fit into contexts that are continually changing. Every evolution is analysed in terms of impact, cost, risk and operational benefits, so as to guarantee a consistent and sustainable path.

There is then a form of maintenance that is quieter but just as important: preventive maintenance. This includes all the activities that aim to improve the stability of the system in the long term, such as the periodic review of dependencies, the updating of libraries, the resolution of technical warnings, the removal of obsolete code and the restructuring of parts of the application that over time can become complex or difficult to maintain. The objective is to avoid the accumulation of technical debt, a phenomenon which, if not addressed promptly, can compromise the quality of the software and make its maintenance increasingly burdensome.

Another crucial component of maintenance concerns security. New vulnerabilities are discovered regularly, both in external libraries and in the frameworks used. dotenv constantly monitors the threat landscape and promptly updates the components involved, assessing the urgency of the interventions and adopting all the measures necessary to reduce the risk of compromise. Security is not a one-off event, but a constant responsibility that requires attention and discipline.

Every update, regardless of its nature, is subjected to the same checks as the initial stages of development: static analysis, unit tests, regression tests, compatibility checks and security checks. This guarantees that every change introduced into the software is consistent with the existing architecture and does not compromise the features already validated. Updates are always released through CI/CD pipelines, ensuring traceability, repeatability and compliance with the security procedures of the ISMS.

Maintenance does not concern only the code, but also the documentation. Every significant change to the software entails an update of the technical documents, of the API specifications or of the operating procedures, so that all the parts remain aligned with the current version of the system. Documentation is considered an integral part of the application, and keeping it up to date is essential to avoid confusion, errors or misunderstandings in the subsequent stages.

Finally, dotenv conceives maintenance as a collaborative process. Customers are involved in the planning of the interventions, especially as regards evolutionary changes, and are informed transparently about the changes, the expected impacts and the release timescales. This collaboration makes it possible to manage expectations, prevent misunderstandings and ensure that the software continues to respond to real operational needs.

Thanks to this structured, quality-oriented approach, maintenance and updates become an integral part of the value of the software itself. The result is a product that is always aligned with the best technical practices, stable, secure and able to evolve over time together with the needs of customers and the dynamics of the market.

16. Access Control and Operational Security

Access control and operational security are two central elements of the technical governance model adopted by dotenv s.r.l., fundamental for protecting the confidentiality, integrity and availability of the information processed in the company’s systems and in the projects developed for customers. The very nature of the activities carried out (software development, management of environments, interaction with sensitive data and integration with third-party systems) requires a rigorous and continuous approach, one that is not limited to formal procedures, but is internalised by every member of the team as part of their own professional responsibility.

The cardinal principle applied by the company is that of least privilege: every person, service or process has access exclusively to the resources strictly necessary for carrying out its activities. This approach reduces the risk of incidents, limits the effects of any compromise and guarantees greater traceability of events. Access is configured on the basis of roles, responsibilities and specific operational needs, avoiding generalised approaches or superfluous concessions. Every exception is justified, reasoned and temporary.

The management of identities and permissions takes place through centralised tools that make it possible to constantly control and verify who has access to what. Unused accounts are removed or deactivated regularly, while access requests are assessed by the technical manager before being approved. The revocation of access follows clear procedures, especially following changes of role, completion of specific activities or the end of a working relationship. This attention guarantees that the system remains orderly and that situations of unnecessary exposure are not created.

In addition to personal access, a significant part of the work concerns the management of the credentials and secrets used by the systems themselves. API keys, certificates, authentication tokens and other critical information are kept through secret management tools that protect their confidentiality and control their distribution. This information is never included in the source code, in the repositories or in insecure channels. The periodic rotation of keys and the generation of dedicated credentials for each environment help to reduce the risk of compromise and to keep the level of security high over time.

Operational security does not concern only access, but also the way in which staff operate on the systems every day. Every technical intervention (from the deploy of an application to the modification of a configuration, from the handling of a log to the resolution of an incident) must follow defined procedures, which guarantee consistency, traceability and verifiability. The most sensitive activities are recorded, so that it is always possible to reconstruct events or analyse unexpected behaviours. This approach does not arise from a need for control, but from the desire to maintain a context that is orderly, secure and transparent.

An element of great importance also concerns the separation of environments. No developer operates directly on the production environment and no manual activity is carried out outside the automated pipelines. This model drastically reduces the risk of errors, guarantees the integrity of the most critical environment and confirms the centrality of automation as a security tool. Likewise, the development and test environments never contain real data, protecting the privacy of users and reducing the risk of accidental exposure.

Operational security also extends to the management of devices, workstations and communication channels. Every member of the team is responsible for the correct use of their own equipment, which must comply with the update, protection and encryption policies laid down by the company. Communications concerning sensitive data or confidential information take place exclusively through channels that are protected and compliant with the security standards adopted.

dotenv also devotes particular attention to the continuous training of staff. Security cannot be guaranteed exclusively by automated tools or by documented procedures, but requires constant growth in individual awareness. For this reason, the company promotes a culture in which every member of staff understands the value of information, the risk represented by emerging threats and

the importance of their own daily actions. The procedures are explained clearly, regulatory updates are shared and incidents, when they occur, become moments of collective learning.

Taken as a whole, the access control system and the operational security adopted by dotenv are not a set of constraints, but an essential element for guaranteeing the quality of the projects, the protection of the data and the reliability of the services provided. This model allows the company to operate with discipline, responsibility and continuity, ensuring that every activity (from development to release, from maintenance to support) takes place in a context that is secure, orderly and fully compliant with international security standards.

17. Management of Third Parties and Suppliers

The management of third parties and suppliers is a strategic element for dotenv s.r.l., since a significant part of the modern technological ecosystem is based on the integration of external services, platforms and components. Whether they are cloud providers, SaaS services, monitoring tools, open source libraries or partners involved in specific stages of the project, every external entity that interacts with the company’s systems or data introduces a potential point of risk. For this reason, dotenv has adopted an approach that is prudent, structured and based on the continuous assessment of the security and reliability of every external party.

The fundamental principle that guides the company is that the final responsibility for the protection of the software and of the data always remains internal, even when some components or functions are contracted out to or integrated by third parties. dotenv does not delegate security, but governs it, making sure that every collaboration takes place in compliance with the technical, organisational and regulatory standards laid down by its security model. Before involving a supplier, the company carefully assesses its level of maturity, its commercial reliability, the quality of the certifications it holds and the adequacy of the protection measures adopted. This preliminary stage is not a formal act, but a concrete tool for preventing future problems.

The choice of a third party is therefore based on criteria that go beyond the mere cost of the service or the apparent effectiveness of the technology. The company assesses how the data will be processed, what responsibilities the supplier assumes in the event of an incident, how updates and vulnerabilities are managed, what level of support is guaranteed and what business continuity policies have been adopted. In particular, for cloud services or for infrastructures that host sensitive data, great attention is paid to the physical location of the data, to the encryption mechanisms, to the access controls and to the presence of independent audits.

Once a supplier has been selected, the relationship does not end with the signing of the contract. dotenv adopts a model of continuous monitoring, verifying over time that the service remains compliant with expectations and with the security standards required. Any significant changes in the supplier’s platform, in its operating procedures or in its corporate structure are analysed to understand the impact on the level of risk. This dynamic approach makes it possible to intervene promptly in the event that a service is no longer adequate, avoiding exposing customers to indirect vulnerabilities.

The management of open source dependencies, dealt with in a dedicated chapter, is an integral part of this vision. Publicly distributed projects too, while offering enormous value, are third parties to all intents and purposes. Their reliability is carefully assessed, and the company applies automatic checks to verify that they do not contain known vulnerabilities. The same principle is extended to the SaaS services used internally, to authentication providers, to analysis tools and to the infrastructure components adopted for the management of projects.

An important role is also played by contractual agreements. Every supplier involved in sensitive activities must sign clear commitments on security, data protection and liability in the event of an incident. When necessary, specific SLAs, confidentiality clauses, incident notification procedures

and minimum required security measures are defined. This contractual attention guarantees that collaboration with third parties is governed not only by trust, but also by a formal framework that protects the company and its customers.

dotenv regards the management of third parties not as a regulatory obligation, but as an essential element of its reliability strategy. The technical team, the administrative department and management collaborate so that every supplier is assessed over time, maintaining an up-to-date register of the active services, of the responsibilities assigned and of the results of the periodic checks. When a supplier no longer meets the standards required, the company is ready to replace it, preventing unnecessary exposure and protecting the value of the projects carried out.

In this way, the supply chain does not become a vulnerability, but a controlled resource. Security is no longer limited to the boundaries of the company, but also extends to the ecosystem of partners and tools that contribute to the delivery of the projects, guaranteeing that every link in the chain is robust enough to bear the shared responsibilities.

18. Training and Security Culture

For dotenv s.r.l., training and security culture are an indispensable element of its organisational model. Technology evolves rapidly, cyber risks change even faster and the reliability of a system does not depend only on the procedures or tools adopted, but above all on the awareness and preparation of the people who work inside the company every day. For this reason, security is not perceived as a set of formal obligations, but as a shared value and an integral part of the professional identity of the team.

Security culture arises first of all from a mental attitude: recognising that every action, even the simplest, can have an impact on the protection of data, on the stability of the software or on the prevention of incidents. Opening a suspicious file, using a weak password, sharing information improperly or underestimating a technical warning can be an entry point for threats which, if neglected, can spread through the entire company ecosystem. Awareness of these risks must not result in paralysis or fear, but in professional behaviour that is attentive, responsible and accustomed to considering security as a natural part of one’s work.

dotenv invests constantly in the training of technical and non-technical staff, through periodic activities that include updates on developments in the industry, analysis of real cases, in-depth sessions on emerging vulnerabilities, internal exercises and moments of discussion between teams. Training is not perceived as an isolated event, but as a continuous process that accompanies people’s entire working path. Every member of the team, regardless of role, must be put in a position to recognise a risk, to prevent it and, when necessary, to report it promptly to the internal contacts.

A significant part of the training path concerns secure software development. Developers are made aware of secure coding practices, of the most common vulnerabilities described in OWASP, of the correct ways of managing dependencies and of the need not to rely exclusively on automatic checks. A critical approach is promoted, oriented towards understanding the problems and not towards simple compliance with the rules. Similarly, the DevOps team receives training on hardening techniques, on the secure management of environments, on the protection of the pipelines and on security-oriented monitoring systems.

Security culture also involves administrative and managerial staff, who must be able to recognise risks linked to the management of data, to external communications or to internal procedures. dotenv adopts an inclusive model, in which security is not delegated to a small group of specialists, but is shared by the whole organisation. Every person is an active part of the process and contributes, through their own role, to the protection of the company ecosystem.

A particularly significant aspect concerns the management of errors and incidents. The company promotes a climate in which communication is transparent and non-punitive, so that any critical issues can be reported promptly without fear of personal repercussions. This approach, often called just culture, makes it possible to deal with problems quickly, to understand their root causes and to prevent the same situation from recurring. Security is not in fact built through the fear of error, but through continuous learning and accountability.

Security culture also shows itself in small everyday gestures: care in the management of passwords, verification of sources, the adoption of up-to-date devices, the protection of credentials, the conscious use of communication tools, prudence in handling personal data or sensitive information. All these habits, if practised consistently, create an environment that is more secure than a thousand rules written down and not understood.

Finally, dotenv regards security culture as a genuine competitive advantage. A team that understands, applies and values the principles of IT security is able not only to reduce operational risks, but also to offer customers a concrete guarantee of reliability, competence and professionalism. Security thus becomes a distinctive trait of the company, an element that accompanies every project and that helps to build lasting relationships of trust.

19. Versioning and Release Policies

The structured management of software versions is an indispensable element for guaranteeing continuity, traceability and control throughout the life cycle of the applications developed by dotenv s.r.l. In a context characterised by frequent evolutions, corrective interventions, functional updates and the need to guarantee compatibility over time, versioning cannot be considered a simple technical convention, but a genuine tool for governing the product.

dotenv adopts an approach to versioning that aims to make immediately understandable the state of the software, the type of change introduced and the expected impact on the existing features. Every version tells a story: it can indicate a significant advance, a targeted fix, an incremental improvement or an urgent intervention. The versioning system thus becomes a form of internal and external communication, useful both to the developers and to the QA teams, to the customers and to the future maintainers of the product.

The numbering of versions follows a clear and consistent model, which distinguishes between major changes, minor changes and corrective updates. This structure allows anyone, even without knowing the technical details, to understand the extent of the change immediately. Major versions introduce transformations that are significant or potentially incompatible with the past; minor versions add features without altering the basic architecture; corrective updates resolve bugs or isolated problems, keeping the general experience of the application unchanged.

The version release process is closely integrated with the CI/CD pipeline. No version number is assigned arbitrarily or manually: every release is the result of a series of technical checks, tests, internal approvals and automatic checks that certify the quality and stability of the software. A version exists only if it has been validated, tested and recorded in the company systems. This approach eliminates ambiguity, reduces the risk of confusion and guarantees complete historical traceability of the changes.

When a new version of the software reaches the production environment, it is the point of arrival of an articulated process that involves developers, QA, DevOps and, in some cases, the customers themselves during the UAT stages. Every change has been verified in the context of the previous version, and every regression has been intercepted thanks to the running of the automated and manual tests. The version released is not only a set of lines of code, but a consistent and reliable artefact, built through a rigorous path of control.

Versioning also plays an essential role in the management of support and maintenance. The presence of a clear history of the versions makes it possible to quickly identify the context of a reported problem, to understand whether a behaviour is linked to a recent modification or to a pre-existing feature, and to intervene promptly. Versions therefore become an operational tool, useful for talking to customers, planning future updates and organising corrective activities with greater precision.

It is important to underline that the versioning policy concerns not only the application code, but also the related assets, such as the technical documentation, the Swagger files of the APIs, the database migration scripts and the environment configurations. Every element that contributes to the operation of the system must be consistent with the version released, avoiding discrepancies that could generate problems that are not immediately evident.

Transparency is another central value of the model adopted by the company. Every version published is accompanied by a clear description of the changes introduced, of the problems resolved and of any operational recommendations. This communication allows the customer to understand not only what has changed, but also why, creating a more mature and collaborative relationship. The management of versions thus becomes a tool of trust, through which the company demonstrates order, professionalism and responsibility.

As a whole, the system of versioning and release policies adopted by dotenv guarantees that every change to the software is controlled, certified and fully traceable. This approach allows the company to maintain a high pace of development without compromising quality, offering customers a product that is always up to date, stable and consistent. The version of the software is not simply a number: it is the testimony of a disciplined process and of the intention to offer a product that is secure, reliable and transparent.

20. Life Cycle of Patches and Hotfixes

The management of patches and hotfixes is one of the most delicate aspects of the software life cycle, since it concerns prompt interventions on critical components, often in contexts of urgency or of high operational risk. dotenv s.r.l. regards the ability to intervene quickly, without compromising the general stability of the system, as an essential element of its technical reliability. However, speed can never become a synonym for improvisation: it is necessary to maintain rigour, traceability and consistency even when working under pressure.

Patches are corrective interventions that are not urgent but nevertheless necessary, used to resolve specific problems, improve stability or correct unexpected behaviours. Hotfixes, on the other hand, are a narrower and more critical category, reserved for situations that require immediate resolution, such as malfunctions that affect users in production, significant security vulnerabilities or service interruptions. Both cases require a clear and structured process, capable of guaranteeing speed without sacrificing quality.

The life cycle of patches and hotfixes begins with the identification of the problem. Thanks to the monitoring systems, to reports from users and to the activities of the technical team, an anomaly can be identified quickly. The next stage consists of assessing the severity of the problem, which determines whether the intervention should follow the ordinary maintenance flow or whether it should be treated as an urgent hotfix. This stage is fundamental for avoiding rework or hasty interventions that could generate further complications.

Once the priority has been defined, the intervention is approached in a targeted way. Patches follow the usual development and pipeline, with the tests, static code analysis, regression checks and approval through pull request. Hotfixes, while adopting the same technical principles, provide for an acceleration of the process. The team involved concentrates exclusively on the problem to be solved, avoiding any change

that is not necessary. The objective is to intervene surgically, reducing the impact on the system to a minimum and guaranteeing an immediate resolution of the main problem.

Despite the urgent nature of hotfixes, the quality of the process must never be compromised. Even in the most critical situations, essential tests, security checks and compatibility checks are carried out. The intervention cannot be considered complete until it has been validated in the staging environment, even if that validation takes place much more quickly than for ordinary releases. This attention guarantees that the remedy does not introduce further vulnerabilities or regressions, preserving the stability of the production environment.

Once the patch or the hotfix has been applied, the change is immediately recorded in the versioning system. Every urgent intervention must be traceable, documented and associated with a specific version, even if it is a minimal increment. This guarantees complete visibility of the changes applied and allows developers, testers and customers to understand precisely which part of the software has been changed and for what reason. Without this traceability, the long-term management of the system would be extremely complex.

After the immediate resolution, the company goes through a consolidation stage. Hotfixes are integrated into the main development branch, preventing the creation of “parallel branches” that are difficult to manage over time. The post-intervention analysis makes it possible to assess not only the technical cause of the problem, but also any improvements to be made to the process, to the tests or to the overall architecture. This stage is essential to prevent the same critical issue from recurring and to turn the urgent intervention into an opportunity for technical growth.

Finally, communication with the customer is a fundamental element of the life cycle of patches and hotfixes. Every intervention, especially if urgent, is communicated clearly, explaining the origin of the problem, the solution adopted and the impact on the features of the application. This transparency consolidates trust and allows customers to understand the seriousness with which dotenv deals with even the most critical situations.

Taken as a whole, the life cycle of patches and hotfixes adopted by dotenv combines speed and rigour, offering a model of intervention capable of guaranteeing security, quality and business continuity even in the most delicate conditions. It is a resilient system, built to respond effectively to unforeseen events without losing the methodological consistency that characterises the entire software development process.

21. Technical summary of the chapters and tools used

This chapter brings together in a single view the chapters of the document, associating them with the software tools and technologies that support the processes described. The table acts as an operational technical index, useful for audits, onboarding of new resources and periodic compliance checks.

Chapter	Title	Tools and technologies
1	General overview of the development process	Git, GitHub/GitLab, Dev/Test/UAT/Prod environments, CI/CD
2	Requirements gathering and initial analysis	Odoo, Sharepoint, workshop tools
3	Architectural design	UML diagrams (Draw.io), cloud models
4	UX/UI prototyping	Figma, Adobe, internal UI libraries, design systems
5	Software development	IDE (VS Code, JetBrains), linters, formatter, static checks
6	Source code control	Git, Git Flow, Pull Request, Pair Programming, Sonar / static checks
7	CI/CD pipelines	GitHub Actions / Bitbucket CI, Docker, CI artefacts, test automation
8	Testing and software quality	Jest, Pest, PHPUnit, Cypress, E2E tests, mock servers
9	Data management and privacy	Secret Manager, encryption, databases with auditing
10	Deployment and release	Docker, Kubernetes (where provided for), CI/CD orchestrators, IaC (Terraform/Ansible)
11	Monitoring and logging	Prometheus, Grafana, Sentry, alerting systems
12	Incident management	ticketing (Odoo), post-mortem template
13	Dependency management	private registries
14	Software documentation	OpenAPI/Swagger, Markdown, Odoo
15	Maintenance and updates	Git versioning, CI/CD pipelines, regression checks
16	Access control and operational security	IAM provider, 2FA, Secret Manager, VPN
17	Third-party management	Vendor list, SLA contracts, supplier audit tools
18	Training and security culture	e-learning platforms, internal workshops, technical documentation
19	Versioning and release	Semantic Versioning, Git tags, automated changelogs
20	Life cycle of patches and hotfixes	Dedicated Git workflows, fast CI pipelines, immediate alerting

Note on operational consistency

The tools mentioned are not only a set of technological equipment, but the structural elements through which dotenv guarantees:

• full traceability;
• operational security;
• software quality;
• continuous compliance with ISO/IEC 27001.

This table therefore serves as a technical map of the manual, useful for inspections, onboarding, audits and periodic review of the ISMS.