Security by Design: how to build a secure and scalable data platform

What is Security by Design?

Security by Design is both a technical principle and a way of working. You design identity, access, network paths, data classification, logging, and incident and change management as a single, integrated whole. This prevents security from being added later as a collection of exceptions. The result is not only more secure, but also more transparent, easier to audit and simpler to scale up.

Why user behaviour is part of Security by Design

Without a solid foundation, a secure data platform cannot be built. The effectiveness of security measures depends on how people interact with them. Even a robust design will fail if users primarily view security as an obstacle. User mindset is therefore often the number one showstopper. If exceptions become the norm, accounts are shared or updates are deliberately delayed, the architecture loses its effectiveness. Make secure behaviour the easiest route: provide clear roles, fast but controllable access, and understandable guidelines. On top of this foundation, there are three interrelated pillars for a secure data platform.

The 3 pillars of a secure data platform

The core: a secure data platform rests on three interrelated pillars: Identity & Access Management, networking, and incident & change management. If one pillar is missing, blind spots arise that the other measures cannot fully compensate for.

Scalable access management with IAM and RBAC

• IAM and RBAC: Identity & Access Management (IAM) determines who has access to which parts of the data platform. Role-Based Access Control (RBAC) links that access to roles, so that permissions can be managed in a scalable, consistent and auditable manner.
• Least privilege: This means that every user, application or automated process is granted only the minimum permissions required to perform a task – no more and no longer than necessary. For example, a data analyst may be able to read and analyse datasets, but cannot manipulate the data. By separating responsibilities, you also prevent a single person from independently requesting, approving and implementing a sensitive change.

  To implement least privilege in practice, you can use Role-Based Access Control (RBAC). First, define personas based on job functions or responsibilities and assign them to roles. Define a clear scope and the minimum required actions for each role, separate read, write and administration rights where necessary, and avoid conflicting roles. Then assign users to these roles via groups, rather than linking permissions directly to individual accounts. This creates a manageable model: from user to group, from group to role, and from role to permissions. This makes changes relating to new hires, job changes and departures manageable and verifiable, whilst periodic reviews prevent roles from becoming too broad without anyone noticing.

  In larger organisations, it is impractical to manage groups manually. Where possible, use dynamic security groups, where users are automatically added based on reliable characteristics, such as their role or department. Then define these groups, roles and assignments as Infrastructure as Code (IaC), for example using Terraform. This ensures that changes are reproducible, verifiable through a review process and consistent across environments.

  Scale makes all the difference. In a well-designed access model, fewer security groups are generally required than there are users, as multiple users with the same role or responsibility are linked to the same roles and groups. If, on the other hand, there are as many or more groups than users, this is a sign that the model has become unnecessarily complex and that RBAC and least privilege may not be properly configured. It is not a hard and fast rule, but it is a good reason to review roles, exceptions and direct assignments. Nevertheless, a good role model only determines which data a person can access; sometimes protection within a dataset is also required.




• Data masking: Hides sensitive fields from users who do need the underlying dataset but do not need to see the sensitive values. Whilst RBAC primarily determines which data someone can access, masking can, for example, prevent an analyst from seeing a national insurance number. Only roles that genuinely require this information are shown the original value. This means you do not need to create a separate dataset for every target group, whilst at the same time limiting the exposure of sensitive data.

  A scalable access model brings these elements together: clear roles based on the principle of least privilege, users linked to those roles via manageable groups, and masking for sensitive data that not everyone needs to see. With consistent naming conventions, clear ownership, automatic provisioning, periodic access reviews and a controlled deletion process, this model remains manageable even as the platform grows. You should therefore design the access structure not just for the first hundred users, but for the scale and complexity the platform may reach in a few years’ time.

Reduce the attack surface with Zero Trust and network segmentation

Network segmentation divides an infrastructure into separate zones and only permits traffic between those zones when there is an explicit functional reason for doing so. This reduces the attack surface and limits the potential impact of an incident.

Networking determines how systems, users and data sources can technically communicate with one another. For example, a service may be publicly accessible, accessible only via a corporate network, or exclusively via a virtual private network (VPN) connection. In doing so, you must consider not only incoming traffic but also outgoing traffic. Which external services is a platform permitted to access, and how do you prevent data from leaving the platform via an uncontrolled route?

This is how networking differs from Identity & Access Management: IAM verifies who an identity is and what actions it is permitted to perform, whilst networking determines whether that identity can technically reach a service. The two are therefore not alternatives, but complementary layers: IAM restricts rights within the platform, whilst networking controls the access paths leading to it.

You should therefore combine Zero Trust principles with network segmentation, private connections and an explicit separation between development, test and production environments. According to NIST SP 800-207 on Zero Trust Architecture, no implicit trust is granted based solely on a system’s network position or ownership. This prevents a compromised account or system from moving freely throughout the entire platform, thereby limiting the impact of an incident. Conversely, strong authorisation prevents technical network access from automatically granting access to data. Together, networking and IAM thus reduce the attack surface and the potential impact of errors and incidents.

A secure network must also be transparent and easy to manage. Define network rules and routes centrally, so that changes are implemented in a controlled manner and environments continue to operate as intended. In addition, keep track of which connections are being made, which requests are being blocked and who is changing settings. This makes it easier to spot anomalous traffic and unauthorised access.

What does Security by Design have to do with NIS2 and the AI Act?

Security by Design can contribute to demonstrable risk management, appropriate security measures, governance and management throughout the entire lifecycle. This aligns with topics covered in the official NIS2 Directive, including control measures and incident reporting. For AI systems, the same approach relates to the risk-based governance and control that are central to the consolidated European AI Act. Exactly which obligations apply depends on the organisation, sector, role and type of system. ‘Security by Design’ supports compliance but does not replace a legal scope definition or a separate assessment against all applicable requirements.

Security by Design checklist for your data platform

Use this Security by Design checklist to verify that the key security principles have been incorporated into the architecture and management of your data platform.