Transformação digital em setores regulados: O que muda

What changes in digital transformation in regulated sectors

The main difference in digital transformation in regulated sectors is that the requirements applying to processes and data have to be considered from the planning stage, not after the systems have been chosen. Depending on the sector and the activity, these requirements may cover compliance, security, access control, traceability, information retention and the ability to demonstrate that obligations are being met. They are not identical in every case: they depend on the legal and supervisory framework of each company and each activity.

All companies have legal obligations, such as those relating to personal data protection or accounting. Sectors such as healthcare, construction, financial services and insurance, or public administration add more specific requirements on what must be recorded, how it is retained and to whom the information must be made available. In these cases, decisions such as where data sits, who can access it and what history is kept can no longer be adjusted freely halfway through the project. The company and its advisers determine what is required of it, and technology solutions should be designed to meet those requirements.

How requirements influence technology decisions

It is worth distinguishing three levels: legal obligations, interpreted by the company with its legal or compliance advisers; good practices, such as periodically reviewing access; and architecture decisions, which put both into practice. If a company has to retain certain records for a defined period, for example, it chooses a system that allows the defined periods and rules to be applied, rather than leaving them in mailboxes or unmanaged shared folders. This logic, often referred to as compliance by design, consists of considering compliance requirements from the design of systems and processes, rather than treating them as later corrections.

The starting point is an inventory of the data the company handles and the requirements associated with it. Assigning each type of data an owner and a reference system avoids situations such as an address corrected in the sales system but not in the invoicing system, where each team ends up working with its own version. This is the idea behind the single source of truth, which we explained in the article on how to build a single source of truth in company systems: a principle of consistency and governance, not the concentration of everything on a single platform. Other platforms may hold copies, as long as it is defined who updates them and which is the reference information in the event of a discrepancy.

Access and retention follow the same logic. Access profiles by role, reviewed from time to time, help avoid administrator permissions being granted just to avoid depending on the technical team. For retention, it is necessary to define how long each type of record is kept, in which system and who archives or deletes it, with periods confirmed by those competent to interpret them. Copies in other systems and in backups can make complete deletion harder, so it helps to know where the information exists.

System integration and information traceability

Integrating systems does not mean replicating all information. Data can be queried at the source, synchronised between systems or transferred from one to another. No approach is better in every case, but all require clear criteria on who accesses the data, how it is updated and how each movement is recorded. Without these criteria, files manually exported from one platform and imported into another, with no record of what was moved, create copies nobody controls. As we noted in the article on why business system integration isn't enough, the technical connection only works well when it has been defined beforehand what circulates and why.

Project documentation records responsibilities, data flows, permissions and relevant decisions, and makes it possible to understand, months later, why the system was organised in a particular way. Audit records are generated by the systems themselves and show who accessed, changed or approved a given record, and when. The level of recording should be proportionate to the risk of the process and the applicable requirements.

The role of teams and technology

Compliance also depends on how systems are used. If a procedure is unclear or the tool is slower than the informal alternative, teams tend to share accounts, send documents by email or keep personal spreadsheets, which takes information out of the system and makes it harder to know who did what. Clear procedures, workflows adjusted to practice and training on the reason for the rules reduce these parallel solutions.

InovaDigital works in digital transformation, system integration and custom software development for companies in various sectors. System integration makes it possible to connect platforms with defined criteria on which data circulates and with what record, and technology organisation defines where each type of data sits and which access profiles are configured.

When the available solutions do not support what the company has defined, custom software development is one of the options to assess, for example to create a validation workflow adapted to the process. Identifying and interpreting the applicable requirements should be ensured by the competent bodies, working together with the teams responsible for the project.

What to consider before moving forward

In a regulated sector, much of the effort of a technology project is decided before any system is installed. If requirements are only considered afterwards, integrations already built have to be revised, information reorganised, permissions corrected and running processes adapted without stopping operations. The sequence we described in the article on where to start organising company technology helps avoid this path: clarify the applicable obligations first and only then choose data, access and connections between systems.

For a manager, the main advantage of considering these requirements during planning is reducing the need for later changes, when systems are already running and processes depend on them.