Applying the Cloud Security Principles in practice: a case study

Content reviewed 08/01/2025.
The NCSC's Cloud Security Principles provide a systematic approach to determining whether a cloud service is a good match for your particular security needs.
One of our development teams recently had exactly this problem, and used the principles to resolve it. I thought a walk though of this process would be a good way to demonstrate the Principles 'in action'.
The back story
One of our development teams had been asked to take a prototype project and iterate it into a more robust state.
During prototyping, a self-installed instance of the no-SQL database MongoDB had been set up, but the team didn't want to continue managing and looking after it. So we investigated various options for a hosted database and eventually selected MongoDB Atlas hosted on AWS as our preferred supplier.
However, before we could go ahead with this choice, we needed to ensure that the service met our security requirements. How could we do this? Enter the Cloud Security Principles.
Gaining confidence
We've talked before about how we go about gaining confidence in cloud services, but the first question we should be asking is 'what are our security needs and how much confidence do we need?'
The data set we needed to store consisted of results collected by the Web Check project. This was data anyone could gather with a low-to-moderate level of sophistication. Given this, we felt that the biggest risk we faced from any possible compromise, was reputational.
Obviously, our reputation matters to us, so we needed to do more than scan the marketing materials, but a full assessment seemed disproportionate. So, we constrained ourselves to evaluating the service using the information we could gather from the MongoDB Atlas website.
Answering specific principles
Some of the Principles were easier to deal with than others.
For example, Principle 3, which talks about separation between users, was fairly straightforward. The MongoDB Atlas FAQ explains that on Amazon Web Services (AWS) this is done by putting each customer's data in its own database instance, separated by AWS Virtual Private Clouds (VPCs).
We're already comfortable with VPCs as a separation between customers, so the next question was whether each Atlas customer's data is placed in a different VPC. Mongo asserts that this is the case and that different customers' data is not placed in any shared storage. This was all good, Atlas is suitable for our use on this front.
Some Principles required a little more work. Principle 1, for example.
Principle 1 talks about the protection of data in transit. Having searched around a bit, we managed to find that MongoDB uses Transport Layer Security (TLS) to protect all connections to the server and between database nodes (although it refers to TLS by its predecessor's name - SSL).
The MongoDB website doesn't go into great detail about how TLS is configured, which is understandable as this will change over time. But, we did some work to identify which configurations were available and compared what we found with our stance on using TLS to protect data. This is the same position we take when we assess public sector websites in Web Check. The available configurations were broadly in line with our expectations, so we were happy that we had a good position on Principle 1 as well.
Delving a little deeper
While reading through the MongoDB Atlas FAQs, we found a whitepaper entitled, "MongoDB Atlas: Security Controls". This paper went into great detail on how the MongoDB team approaches security, along with specific assertions about their setup and the technologies they use.
While these technologies and architectural choices address specific points in the Cloud Security Principles, they also address a deeper point - the MongoDB team puts a lot of thought into security and is happy to talk about their approach publicly.
This makes us much happier about using the service, as we feel security will continue to be considered throughout the lifetime of the product and improved in response to new discoveries. It also reassures us that they will have taken sensible precautions and will react constructively to security issues.
Making their position on security a matter of public record also means that the company can be held to those standards. The reputational damage incurred would be considerable if their published claims were later proven to be false.
Confidence gained
If more confidence had been necessary, because our data was more sensitive, for example, we might have contacted the vendor to discuss a few important details. Things like, how their admins access customer to data, or how data is encrypted at rest.
But, having reviewed the material we found on the MongoDB Atlas website, we felt comfortable that the service was a good fit for the data we were storing. It may not be ideal for other uses, but we had made an informed, evidence-backed decision, thanks to the Cloud Security Principles.
Hopefully this has been a useful example of applying the Cloud Security Principles.
Jamie H
Senior Cloud Security Researcher


