Cybersecurity in data projects: How to build security in from day one (Part 1)

Cybersecurity in a data project shouldn't start two weeks before go-live.

Whether you're migrating legacy data, building a cloud platform or introducing new analytics capabilities, security needs to be designed into the project from day one. Securing a data project after it's built is much harder than building it securely in the first place.

But you are probably wondering why I am writing a blog on Cybersecurity. I am Fran (the IT and Cybersecurity person at Binary10) super passionate about this topic and oh I have literally done a Masters in Cybersecurity. In this two-part series, I’m sharing some of the practical things organisations can do to make cybersecurity part of their data projects from the very beginning.

Why cybersecurity matters in data projects:

Data projects often bring together exactly the things that need protecting: valuable data, multiple systems, different users and changing levels of access.

The risk comes when access, data and systems change faster than the security controls around them. During a data project, this could mean:

1. Sensitive data being accessible to more people than necessary

2. Temporary privileged access remaining in place for too long

3. Production data being copied into less secure test environments

4. Third parties retaining access after their work has finished

5. Data being moved through temporary files or staging locations that haven't been adequately protected

The answer isn't to make data projects slower. It's to build security around how the project actually works, from the beginning.

So, where do you start? 

Building cybersecurity into a data project doesn’t come down to one security check or control. It means building security into the decisions made throughout the project, from initial planning and access through to migration, go-live and what happens afterwards. Here are the key areas to focus on.

1. Start with security during project planning.

Make security an early convo!

The best time to think about cybersecurity is before a data project starts taking shape. Whether the project involves migration, integration, data quality, cloud transformation or analytics, decisions about architecture, systems, access and how data will be used are often made early.

Bringing security into the planning stage means potential risks can be identified while there is still time to design around them, rather than trying to retrofit controls later.

Late can become expensive.

If security requirements are identified too late, teams may discover that the solution they've designed doesn't provide the right level of protection. That could mean revisiting access permissions, changing how sensitive data is handled, redesigning integrations or introducing additional controls later in the project.

The result can be additional complexity, cost and disruption that could have been avoided by considering cybersecurity from the start.

Questions to ask before the project.

Before work on the data project begins, bring the right people together and ask:

• What data are we working with, and is any of it personal, confidential or commercially sensitive?

• Where is the data now, and how will the project change where or how it is stored, accessed or used?

• Who needs access, and what level of access do they actually need?

• Which systems and data sources will be involved?

• Will suppliers or other third parties need access?

• Are there regulatory, security or contractual requirements we need to account for?

• What would happen if the data was exposed, changed, lost or unavailable?

• What happens to temporary access, files and environments when the project ends?

  
  

You don't necessarily need every answer on day one. The important thing is that cybersecurity becomes part of the data project from day one.

2. Understand your data before you work with it.

Can you protect the data?

You can't protect data effectively if you don't know what you have. Understanding your data early helps you establish what needs protecting, who should have access to it and what security controls are appropriate.

Poor visibility creates risk!

Without that understanding, sensitive or unnecessary data can easily become part of a project without the right controls around it. Teams may also inherit outdated permissions, retain information for longer than necessary or expose data to people and systems that don't need it.

Start with the data that matters.

Start with data discovery and classification. Build a clear picture of what information the project will use, where it lives, who owns it, who currently has access and how sensitive it is.

From there, classify the data according to its needs. Personal, financial, commercially sensitive or confidential information may require additional controls such as restricted access, encryption, masking or monitoring.

And if your data project involves moving information between systems, take the opportunity to ask whether everything actually needs to move. Reducing unnecessary data can reduce unnecessary risk.

3. Apply least privilege throughout the data project.

Give the access they need, not they could need!

Data projects often require people to access systems, environments and information they wouldn’t normally use day to day. Depending on the project, developers, data engineers, consultants or suppliers may need temporary or elevated access to get the work done.

That access may be necessary, but the principle should be simple: people should only have access to the data and systems they need, for as long as they need it.

Temporary access sticks around!

When a project is moving quickly, granting broader access can feel like the easiest option. The problem comes when temporary permissions are never reviewed or removed. Someone who needed privileged access during one stage of a data project may not need the same access later. If those permissions remain in place, they can create unnecessary security risk long after the original requirement has disappeared.

Make access change with the project.

Apply the principle of least privilege throughout the data project lifecycle. Use role-based access where appropriate, separate administrative and standard accounts, protect privileged access with stronger authentication, and use temporary permissions rather than permanent access wherever possible.

Crucially, don't treat access as a one-off decision. Review permissions as roles, systems and project requirements change, and remove access when it is no longer needed.

How we approach it at Binary10:

Least privilege isn't simply something we recommend to clients. Our Information Security Policy requires access to client data hosted in its managed environments to be restricted to authorised personnel on a least-privilege basis. Binary10's security material also includes MFA and role-based access during delivery, followed by removing access when it is no longer required.

4. Protect development and test environments.

Test doesn't mean less sensitive.

Development and test environments are essential to many data projects, but they don't always receive the same security attention as production systems.

The challenge is that the data inside them can be just as sensitive. Teams may use realistic datasets to test integrations, validate data quality, develop new solutions or check how systems behave before go-live. If that involves production data, the same personal, confidential or commercially sensitive information may now exist in another environment.

What could go wrong?

A test environment can create additional risk if production data is copied across but the security controls don't follow it. For example, more people may have access to the environment, permissions may be broader, or copies of sensitive data could remain after testing has finished. A database doesn't become less sensitive simply because it's labelled “test”.

Focus on 4 things!

Where possible, use synthetic or appropriately anonymised data in development and test environments. If production data is genuinely required, focus on four things:

• Limit access: Only give access to the people who genuinely need it, and review those permissions as the data project progresses.

• Protect the data: Apply appropriate authentication, encryption and security controls based on the sensitivity of the information.

• Keep visibility: Use logging and monitoring so activity within the environment can be tracked and unusual behaviour identified.

• Plan for the end: Know when test data is no longer required and have a clear process for removing it and any temporary access.

So, we say protect the data based on what it contains, not whether the environment is called production, development or test!

5. Protect data as it moves through the project.

Follow the data too.

Data rarely stays in one place during a data project. It may move between systems, applications and environments, be accessed by different teams, or be transformed and processed as part of the work.

That can happen during data integration, migration, cloud transformation, analytics, data quality work or system modernisation.

The gaps between system matter too.

The biggest risk isn't necessarily the final system. It's often what happens to the data between the starting point and the end result.

Sensitive information could pass through temporary storage or staging areas. Copies could be created and forgotten. Access could become broader as more systems and people become involved. And if data is being transformed or transferred, its integrity also needs to be protected so teams can trust that it hasn't been lost, corrupted or unexpectedly changed.

Map the data journey!

Instead of treating data security as something attached to individual systems, follow the data through the project.

Where is it coming from?

Understand the source, sensitivity and existing controls.

↓

Where is it going?

Know which systems, applications or environments will receive or process it.

↓

Who or what touches it along the way?

Consider users, service accounts, integrations, APIs, third parties and project tooling.

↓

How is it protected?

Apply appropriate access controls, encryption, monitoring and secure configuration throughout the journey.

↓

What gets left behind?

Review temporary copies, staging data, credentials and project resources when they are no longer required.

If the project specifically involves data migration, this also means protecting data during extraction, transformation, transfer and loading, and validating the result afterwards. Binary10's migration approach includes technical ETL and reconciliation as part of determining whether migration has been successful.

Five key areas to get it right and security doesn't stop there.

Building cybersecurity into a data project starts with getting the foundations right: understanding your data, controlling access, protecting different environments and thinking about security wherever that data goes.

But there is more to consider as the project progresses.

In Part 2, we'll cover six more areas that can help keep data projects secure, from cloud environments and third-party access to monitoring, governance and what happens after go-live.

Article by:

Francisca Esan

Follow me on LinkedIn

FAQs:

1. What is cybersecurity?

Cybersecurity is the practice of protecting data, systems, networks and technology from unauthorised access, disruption, damage or cyber threats. For organisations, this includes protecting both the technology they use and the information they hold.

2. What does “security by design” mean?

Security by design means considering security from the earliest stages of designing a system, service or data project, rather than adding security controls after it has already been built. The aim is to make security part of how the solution works from the outset.

3. What is the principle of least privilege?

The principle of least privilege means giving users, applications and systems only the level of access they need to perform their required tasks. Access should also be reviewed and removed when it is no longer needed.