Data privacy and regulatory compliance in low-code platforms

Concerns around data privacy and regulatory compliance shouldn’t derail the adoption of low-code platforms. Here’s how to ensure low code doesn’t equal high risk.

The adoption of no-code and low-code technologies is soaring. Gartner predicts that by 2025 70% of new enterprise applications will be created in low-code development environments, up from just 25% in 2020. This growth accompanies an acute shortage of professional software developers in the wake of the coronavirus pandemic. At the same time, businesses and non-profit organizations alike face constant pressure to innovate rapidly.

No-code and low-code technologies present a way to close that gap, since they allow almost anyone to become a software developer. As co-founder and CEO of GitHub Chris Wanstrath famously said back in 2017, the future of coding is no coding at all.

However, while the value of low-code is undeniable, we cannot afford to lose sight of one of the biggest barriers to its adoption – data privacy and security. Low code doesn’t necessarily mean low risk. After all, allowing more people in the enterprise to get involved in development can naturally lead to creating new vulnerabilities, such as lack of oversight and visibility.

Adopting low-code software development is especially challenging for enterprises which have relied on in-house development for decades. As is the case with any transformation, the risks of something going wrong are ever-present, and adopting low-code platforms is no exception. On the other hand, the costliest words in business are ‘we’ve always done it this way’. That’s why digital transformation must always approach privacy, security, and regulatory compliance by design and default. Here’s what that means in the context of low-code development.

What are the security and privacy challenges of low code?

User experience is one of the core concepts underpinning any digital transformation. In much the same way as cloud computing has come to redefine knowledge work, low code has come to redefine software development by lowering the barriers to entry and making it accessible to a broader range of people. However, accessibility inherently comes at the cost of expanding the potential attack surface, thus putting your organization at greater risk of data breaches or leaks and failures to meet the increasingly rigorous demands of regulatory compliance.

The opportunities that come with democratizing software development are enormous. At the same time, the greater reach also means there’s an increased risk of low-code applications being developed outside the rules and guidelines put forth by the IT department. This so-called shadow IT may result in the development of software solutions that don’t meet the standards of data privacy, security, and compliance. Admittedly, some low-code platforms give IT leaders insufficient visibility into where their data lives and how it’s protected.

In traditional software development scenarios, IT departments work closely with data privacy officers and legal teams to serve as gatekeepers between classified resources and business users. It’s their responsibility to decide which users are allowed to access which data and how. For example, low code might allow sales and marketing teams to add important functionality to their customer relationship management (CRM) software, or even create a new CRM from scratch. Low code makes this possible by using visual building blocks rather than writing lines of code. However, CRM systems also hold a wealth of personally identifiable client information that’s subject to stringent privacy regulations like GDPR and CCPA.

Another challenge of adopting low-code platforms is the fact that the vast majority of them rely on third-party integrations. This is also one of the biggest benefits of using an API-centric low-code platform, since it allows you to integrate your new software solutions with your existing tech stack. At the same time, the way that data is exchanged between different digital services may not always meet your organization’s compliance requirements. API vulnerabilities are a common cause of data leaks and breaches, and they must be addressed proactively.

Building a privacy and security model for low code

Low-code platforms are diverse. Some of the easiest platforms to use don’t require any coding at all, but they also tend to be completely closed source, giving administrators minimal control over privacy and compliance. Other platforms, like Corteza, might be more complex, but they are also entirely open source and provide practically limitless opportunities to accommodate a much broader range of use cases.

When establishing a suitable security and privacy model for your low code applications, you first need to understand the various layers in the tech stack. Here’s a quick summary:

• The first layer is the infrastructure. This is the underlying infrastructure upon which your low-code development platform (LCDP) operates. This includes the servers, operating systems, hypervisors, and networks. Most closed-source LCDPs run off infrastructure provided by the vendor, and while there’s not necessarily anything wrong with that, it may mean there will be limitations as to how you can apply the privacy and compliance policies that are important to your use case.
• The second layer is the platform itself. This includes things like business logic, visual components used to build the low-code application, custom widgets, connectors, and APIs. It also includes ancillary services and other resources that the environment uses, such as SaaS instances, storage buckets, IoT devices, and other third-party resources. This is the layer that your citizen developers will directly interact with.
• The third and final layer is the data itself. When developing low-code applications, it’s wise to use a sandbox environment and use anonymized or open-source data sets for thoroughly testing the application for any potential vulnerabilities. It’s also essential to test any database connectors and APIs themselves, before using them in a production environment.

Introducing security and privacy by design and default

Adopting low-code development practices is rapidly becoming a necessity. It’s a key driver of innovation at a time when organizations across all industries need to become more agile and scalable. Where most use cases are concerned, information privacy and security leaders can’t afford to say no. Instead, they need to explore ways to implement low-code safely and in ways that doesn’t increase risk.

Of course, data privacy and security depend significantly on the low-code platform you decide to implement. It’s essential to have the foundation in place for applying the privacy and security policies that matter to your organization.

Many platforms are entirely closed source, in which case the privacy and security features and functions that are available to you will be limited to those provided by the vendor. Open-source alternatives, however, provide greater control and ownership, which is especially important in cases where data sovereignty and privacy are top priorities.

When implementing a new low-code platform in your organization, you must take privacy and security into consideration from the outset. Policies should be clearly defined ahead of time and integrated into your entire tech stack right from the outset. Privacy and security should be taken into account throughout the entire engineering process, just as they should in traditional software development.

In low-code development, there shouldn’t be any reason to grant any individual or third-party access to any data that they don’t explicitly need to perform their roles. As such, it’s essential that you have a way to abstract the actual development process from the underlying database. For example, citizen developers who are building a new component for your CRM don’t need access to real customer data during the development and testing phases. Instead, they can use anonymized data where necessary, and build and test apps in a logically isolated sandbox environment. Only once the new app or component has been thoroughly tested and audited for potential security and privacy risks should it be allowed to pull data from databases in production.

Corteza addresses this challenge with the Data Access Layer, which expands the platform’s capabilities to store and read data from both primary and external databases. This makes it possible to isolate code from the presentation and business layers, thereby allowing users to build functions or interfaces in secure environments without having to grant access to sensitive data.

Maintaining visibility and control over your data assets

One of the most common fears that data privacy and security leaders have when implementing low-code platforms is losing visibility and control. The widespread belief is, that allowing more people to develop software directly translates into a rise of shadow IT and a reduced ability to adhere to organization-wide privacy and compliance policies.

The concerns are understandable, but they are also widely misunderstood. Just like any other type of software, low-code applications may contain design flaws and vulnerabilities. On the other hand, an organization-wide adoption of a low-code platform can actually standardize the way you apply privacy and security functions.

For this to happen, privacy and security leaders must retain complete visibility over their data and which low-code apps and services have access to it. The first thing is to ensure you know exactly where your data is stored. Closed-source platforms typically provide fewer options as to where you can physically store your data and which controls you can apply to protect it. An open-source environment, by contrast, gives you the freedom to specify an exact data storage location, whether in a public or private cloud or an in-house data center. For example, thanks to Corteza’s enhanced privacy controls, system administrators will now be prompted to choose a storage location whenever configuring a new data module. They can then apply an existing data-protection policy or create a new one for that module.

When implementing low code in your organization, it’s vital that you can maintain control over your data assets before you allow citizen developers to create apps and services that will have access to those assets in production environments. With the ability to apply policies to specific data sets, administrators can maintain ownership and control of their data, abstracting it from the software frontend, as well as the development process itself.

Ensuring compliance with subject access requests

Regulations like the General Data Protection Regulation (GDPR) and the California Consumer Privacy Act (CCPA) are at the cutting edge of data privacy legislation. They’ve also proven a significant burden to implement. One of the reasons for this is that the regulations, like others modelled after them, grant individuals the legal right to access their personal data and, at their discretion, request its deletion. Privacy laws call this a subject access request (SAR). GDPR, for example, gives organizations up to 30 calendar days to comply with an SAR.

Complying with SARs and data erasure requests is, of course, much easier and quicker if you know exactly where your data is and you have full control over it. However, that’s often easier said than done in today’s typically disparate and complex IT environments. When you’re using a low-code software development stack without the necessary governance, meeting the needs of compliance can be even more challenging, since sensitive data can easily end up outside the control of the IT department.

To address this challenge, software teams must ensure that their applications and databases are logically separated and that neither applications nor users have the ability to access, move, or modify data that isn’t explicitly required for their roles. At the same time, a unified data privacy console should allow privacy officers to easily respond to requests to remove, change, or download personal data – regardless of which applications are used to access it. In other words, the data itself should exist and be governable independently of the infrastructure and software layers of the technology stack.

Driving an organization-wide cultural change

Security, privacy, and compliance are primarily human challenges rather than technical ones. This is why upholding the highest standards first and foremost requires a cultural change. In the case of low-code adoption, that means establishing a robust citizen development program in which all business apps are built on an IT-approved platform. This gives privacy and security leaders the visibility and control they need to monitor and maintain those standards.

Ultimately, when it comes to implementing an organization-wide low-code environment, many enterprise-grade platforms offer the foundational elements necessary to match or exceed the security and privacy offered by a traditional development environment. By building a low-code culture, in which security, privacy, and compliance are placed front and center, adopting low code technologies doesn’t have to mean increasing risk – but the precise opposite.

Planet Crust is the principle supporter and developer of the Corteza low-code platform. Our new privacy features greatly expand the platform’s capabilities to give administrators greater control and visibility over their data and the underlying tech stack. Try Corteza on-premises or in the cloud today.