INSIGHT DETAIL
How Regulations Are Reshaping Digital Security Architectures The rapid proliferation of cloud, artificial intelligence and blockchain-based services; the diversification of ransomware, phishing and AI-enabled attack vectors; and the increase in cross-border data flows
%201.svg)
July 2, 2026
In the past, systems were simple; today’s digital systems are much more complex.
These systems are built not only around companies’ servers, but also on cloud services, artificial intelligence tools, mobile applications, APIs and blockchain-based systems.
The attack surface is expanding along with these systems.
are among the most important concerns for organisations.
Security must be properly integrated into the system from the very beginning.
This is precisely where regulations come into play.
Regulations and standards such as GDPR, KVKK, DORA, MiCA, PCI DSS and ISO/IEC 27001 not only determine the rules that companies must comply with, but also dictate how their digital systems should be structured.
For years, companies have viewed regulations as a checklist that needs to be ticked off.
Documents were prepared, policies were drafted and, once the audit was completed, the matter was considered closed.
However, this approach is no longer sufficient in today’s threat environment.
More resilient systems must now be built.
The following questions must be answered:
Does a system remain operational during and after an attack?
Which users accessed which data?
How quickly can a security vulnerability be detected?
Is a potential data breach inevitable?
This situation encourages organisations not only to meet legal compliance requirements, but also to build resilient systems.
In traditional security systems, if a user had access to the corporate network, they were considered trustworthy.
However, remote working and cloud systems, the roles of mobile devices changed the rules of security systems.
The Zero Trust approach adheres to the principle of “never trust, always verify”.
In this model, the fact that a user has logged into the system is not considered sufficient on its own. The user’s identity, device and location are continuously verified to determine which resources the user is attempting to access.
For example, if a user needs financial data as part of their role, the system may check the following:
Of course, these controls do not prevent 100 per cent of attacks.
However, they make it more difficult for a compromised account to move freely within the system.
In addition, areas such as access control, authentication and log management are leading to the emergence of new regulations that advance the Zero Trust approach.
By definition, “Security by Design” means integrating security into the software development process from the very beginning.
Conducting a security test after the development of an application has been completed generally means that it is already too late in terms of the process.
In addition, detecting security vulnerabilities during the development process is easier and more cost-efficient.
As a result, automated code scans, security tests, access controls and dependency analyses are being used increasingly in software development processes.
Monitoring the software supply chain is vital, particularly for finance, payment systems and crypto-asset services.
A security vulnerability used by a company’s own software can infiltrate the entire system and weaken it, even if the software itself is secure.
Security responsibility no longer belongs solely to the Security Team.
This process includes everyone involved, from software developers and system administrators to executives, as well as external service providers.
Unlike most of today’s digital systems, Web3 projects operate differently. Instead of relying on central authority, they may consist of smart contracts, blockchain networks, wallets and community-governed structures.
Although this design offers certain advantages, it also brings its own unique security concerns.
Once smart contracts are deployed on blockchain, many attempts to change them fail.
Even a single small error in the code can lead to the loss of a significant amount of assets.
In this area, you will encounter the following risks: reentrancy attacks, authorisation errors, price manipulation and flash loan attacks.
For this reason, smart contracts should be audited by independent teams.
However, this does not mean that the contract is completely flawless. Risks change when the code is updated or when the protocol uses auxiliary systems.
Regulatory authorities are also trying to determine who should be held responsible in this regard. How responsibility should be shared among developers, platform operators, custody service providers and users is still a matter of debate.
Self-custody wallets allow users to retain control of their private keys.
This gives users more control, but it also places a greater responsibility on them.
Losing private keys or recovery phrases may result in being unable to regain access to assets. In addition, when this information falls into the wrong hands, transactions cannot be reversed.
To reduce this risk, hardware wallets store private keys offline. Thanks to secure chips and HSM-like components, this makes it impossible for the keys to be extracted from the device.
Unfortunately, a single device alone cannot provide complete protection; comprehensive security can only be achieved through the combined use of devices.
Fake applications, social engineering attacks and the misuse of misplaced recovery phrases are still among the main risks.
However, expectations regarding the security of centralised crypto exchanges are different.
There is now much stricter scrutiny regarding the percentage of assets held in cold storage, how the custody security system operates, how permissions and access rights are allocated and whether reserves can be audited.
As a result, trends such as proof of reserves, custody insurance and cold wallets are gaining popularity.
However, not all countries regulate these practices in the same way, and none of these measures alone can guarantee that a platform is 100% secure.
Digital services rarely operate within the borders of a single country.
A user’s data may be hosted in another country, processed by a company located elsewhere and also transferred to other service providers.
In this context, organisations need to clearly understand where their data is stored and by whom it is processed.
As stated in regulations such as GDPR and other similar laws, certain security measures may need to be taken when personal data is transferred between different countries.
Companies cannot simply say, “our data is secure”; they must also specify where the data is stored, who accessed it and when, how long it remained there and how the deletion process is carried out.
Methods include data classification, encryption and tokenisation, as well as access logs.
Protecting identity information is one of the fundamental priorities. This is not the case with initiatives such as the eIDAS 2 system or the European Digital Identity Wallet, which will be implemented in Europe and are vital for secure cross-border identity verification.
Rather than inventing new attacks, artificial intelligence is intended to help attackers automate and improve existing attacks.
Today’s artificial intelligence tools, however, can create messages that appear corporate, personalised and still look genuine.
Deepfake voices and videos can also be used in fraud attacks.
Someone may call an employee by imitating the voice of a company’s CEO and persuade them to transfer money.
This is why relying solely on passwords is insufficient.
Passwords must be supported by additional controls such as multi-factor authentication, transaction approval, behavioural analysis and the detection of unusual activities.
It is not possible to release enterprise software without including third-party components.
As we have seen with major vulnerabilities such as Log4Shell, a component containing a single vulnerability may be enough to bring down thousands of companies at the same time.
Similarly, misconfigured Kubernetes privileges or cloud storage buckets that remain accessible over the web may also lead to significant data leakage.
For this reason, it is vital for companies to know exactly which software components they use.
Thanks to a Software Bill of Materials (SBOM), we can identify which components are used within an application.
When a vulnerability emerges, the time required to assess whether it affects the organisation’s systems may be reduced, as organisations can focus only on components in environments that are not managed or hosted internally.
Although SBOMs, automated security scans and regular update processes have become mandatory in some sectors, they have become a (key) part of security practices in others.
Security architecture can never be static, particularly while regulations and threats are constantly evolving.
Most companies need to become aware, at a relatively early stage, of the preferred methods or timelines for new regulations to come into force.
All controls should already have been carried out during the design stage.
This way, there will be no costly changes after the systems have been established.
Automating compliance controls within software development processes is equally important.
Some security rules can be created and, implemented through code, particularly by using approaches such as “Policy as Code”.
The greatest challenge is integrating security into system design: This includes continuously monitoring users while they use the system, detecting malicious activities before they occur and ensuring that the system remains operational even if damage occurs.
Digital security is no longer limited to complying with rules or passing audits. The real issue is building systems that are prepared for threats, able to adapt to change and capable of continuing to operate when a problem occurs. Regulations are pushing companies to move in exactly this direction. Security must not be treated as an additional step, but as an integral part of the system from the very beginning.
Disclaimer
This article is intended for general informational purposes only and does not constitute legal, regulatory, financial or cybersecurity advice. Regulations, technical standards and security practices may vary by jurisdiction and may change over time. Organisations should assess their own risk environment and seek guidance from qualified legal, compliance and cybersecurity professionals when necessary.
