Cloud Security: What Your Provider Protects and What Still Belongs to You

01

The cloud invoice can hide an ownership gap

Imagine an established service business relies on a customer portal. Customers upload documents, staff review cases and managers use the system to see what needs attention.

The portal runs on a well-known cloud platform. The provider operates large data centres, maintains the physical servers and offers security controls that would be difficult for the business to build alone. On paper, the hosting looks reassuring.

Then the original developer leaves.

Nobody is quite sure who owns the main cloud account. Two people share an administrator login. Backups appear to run, but nobody has restored one recently. Security alerts go to an old email address. The application contains customer data, yet the business cannot explain which supplier staff can access it or what would happen during a serious incident.

The cloud platform may still be secure. The application operation is not under control.

This is the most useful place to begin with cloud security. It is not a product you buy once. It is the continuing job of deciding who protects each layer, configuring that layer properly and checking that the controls still work.

02

Cloud security protects more than the server

Cloud security covers the policies, controls, technology and day-to-day work used to protect cloud applications, data and infrastructure.

The supplied Check Point overview describes familiar concerns including identity and access, network controls, workload protection, data security, monitoring and governance. Those areas matter, but a business does not need to buy every category of security product before it can improve its position.

A clearer starting point is the National Cyber Security Centre's shared responsibility model. The cloud provider protects the parts of the service it operates. The customer protects the choices, configurations, accounts, data and application responsibilities that remain in its control.

That boundary moves according to the service being used. A provider may patch the physical host while your team still patches the virtual server. A managed platform may operate the server and database software while your team remains responsible for the application code, permissions and data. A software service may take on most of the technical stack while your business still decides who can log in, what information may be stored and how exports or deleted accounts are handled.

The useful question is not, "Is the cloud secure?" It is, "Which parts are ours, and can we prove they are being managed?"

03

Shared responsibility changes with the service model

Cloud services usually sit somewhere across infrastructure as a service, platform as a service and software as a service. The labels are less important than the responsibility they leave with you.

The exact boundary varies between services, so do not treat the table as a contract. Record the real arrangement for each important system.

The NCSC recommends delegating as much security responsibility as practical to a trusted provider. It also recommends software as a service where a suitable product exists and generally prefers platform services over raw infrastructure for application hosting. A provider operating a service at scale can often patch, monitor and defend its own components more consistently than a small application team.

That does not make the most managed option automatically right. It can add supplier dependence, data-location questions and limits on how the application works. The decision should compare those constraints with the operational burden your business is genuinely equipped to carry.

For the customer portal, moving from a self-managed virtual server to a managed application platform could transfer operating-system patching and some database work to the provider. The business would still own the code, user access, secrets, data handling, logs and response plan.

04

Identity is the first practical boundary

Most cloud environments have two kinds of identity. People use accounts to administer services, and applications use service identities or credentials to connect to databases, storage and other systems.

Both need clear ownership.

Give each administrator a named account. Protect privileged access with multi-factor authentication. Avoid shared root or global administrator logins. Grant the minimum permissions needed for the job and review them when somebody changes role, a supplier finishes work or an integration is retired.

Service identities deserve the same care. A key copied into source code, a deployment script or a forgotten spreadsheet can outlive the person who created it. Keep secrets in an appropriate managed store, restrict what each identity can do and define how credentials are rotated without breaking production.

Return to the portal. The first improvement is not a new firewall. It is recovering control of the main account, creating named administrator access, removing the shared login, checking supplier privileges and moving alerts to an address the business owns.

That work is not glamorous. It is also the difference between having security features and being able to operate them.

05

Data protection includes recovery

Encryption is important, but data protection does not end when storage and network traffic are encrypted.

The business needs to know what data the application holds, why it is needed, where it is stored, which countries and legal jurisdictions are involved, who can access it and how long it should be retained. Logs, backups, exports and generated files count as data too. They are easy to forget because they sit outside the main database.

Recovery needs its own attention. A cloud provider may protect the availability of its storage service while your team remains responsible for configuring backups, retaining the right versions and restoring the application correctly. A snapshot that has never been restored is an optimistic file, not a tested recovery plan.

Define the recovery point the business can accept, which is how much recent data could be lost. Define the recovery time it can accept, which is how long the service can be unavailable. Then test a restore that includes the database, uploaded files, configuration, credentials and the steps needed to bring the application back safely.

For the portal, a successful test should produce more than a green backup status. It should show that a named person can restore a usable copy, verify the important records and explain how the live service would be recovered.

06

Secure configuration and code must survive change

Many cloud security problems are not failures of the data centre. They are ordinary configuration and software problems given an internet connection.

A storage bucket can be exposed too widely. A database can accept traffic from places that never need it. An old test environment can contain production data. A dependency can remain unpatched. A deployment credential can have far more permission than the release process requires.

Good defaults help, but applications change. Security controls need to survive new developers, new integrations and frequent deployments.

Keep important configuration in version-controlled deployment code where practical. Separate production from development and test environments. Scan dependencies and apply updates through a controlled release process. Keep secrets out of the repository. Review public network routes, storage permissions and service identities as part of normal change work rather than waiting for an annual security exercise.

Automated checks are useful when they stop a known bad configuration reaching production. They do not replace review. A tool can confirm that a storage service blocks public access. It cannot decide whether the application should store that category of customer document in the first place.

The portal team should be able to trace a production change to an approved release, see which configuration changed and roll back safely when the result is wrong.

07

Monitoring turns controls into evidence

A control that nobody watches can fail quietly.

Useful cloud monitoring brings together application health, administrator actions, authentication events, configuration changes, unusual data access and provider alerts. It should help the team answer three questions: what happened, when did it happen and who or what performed the action?

Collecting every possible log is not the same as monitoring. Start with events linked to real risk. Alert when a privileged account is created, multi-factor authentication is removed, a storage policy becomes public, repeated login failures appear, backups fail or the application suddenly generates unusual errors.

Every important alert needs an owner and a response. If the portal reports a suspicious administrator login at 2am, who receives it? What can that person check? Who can suspend access? How is the event recorded? When must customers or regulators be involved?

The NCSC cloud principles expect providers to supply useful audit information and security alerts. Your business still needs to enable the relevant logs, retain them for an appropriate period and act on what they show.

08

Know what suppliers can access

Cloud applications often involve more than the business and the main platform provider. A managed service provider, development company, monitoring service, email supplier and backup product may all hold access or process data.

List the suppliers that can reach the environment or receive its information. Record the purpose, permission level, named owner, contract route and removal process for each one. High-level administrator access should be rare, time-limited where possible and auditable.

The NCSC advises applying least privilege to managed service providers and retaining visibility of their actions. It also notes that an incident may require cooperation from the supplier, which makes response expectations and contact routes worth agreeing before they are needed.

Do not add several cloud providers simply because a multi-cloud diagram looks resilient. More suppliers can create more accounts, policies, network routes, bills and gaps between teams. Use another provider when it solves a defined availability, legal or commercial need, not as decoration on an architecture slide.

For the portal, the supplier review may reveal that a former developer still has broad access while the business itself cannot reach the billing account. Fixing that ownership problem is more urgent than purchasing another security dashboard.

09

Prepare the response before an incident

Cloud security also includes the work after prevention fails.

Write a short response plan around likely situations: a compromised administrator account, exposed data, malicious change, failed deployment, unavailable provider region or broken backup. Name the business owner, technical contact, supplier contacts and decision route. Keep the plan somewhere available when the main cloud account or application is not.

Test it with a simple exercise. Imagine the customer portal starts returning errors while an administrator account creates a new access key. Ask the team what they would check first, how they would preserve evidence, whether they can restrict access, how they would communicate and which supplier must help.

The exercise will expose missing telephone numbers, unclear permissions and assumptions about backups much faster than another policy document. Update the plan after the test.

An incident plan cannot promise that nothing will go wrong. It gives the business a controlled way to notice, contain, understand and recover when something does.

10

Treat cloud security as recurring operational work

The customer portal did not become risky because cloud hosting was a bad choice. The gap appeared because responsibility moved but ownership was never written down.

A reputable provider can remove a great deal of infrastructure risk and give a small team access to strong security features. Those benefits are real. They work only when the business understands its remaining part of the arrangement.

Start with the important application. Map every layer to a named owner. Recover account control. Review access. Test the backup. Confirm the logs reach somebody. Write down what happens during an incident. Then repeat the review as the system, suppliers and business change.

Cloud security becomes manageable when it stops being an abstract promise from a provider and becomes ordinary operational work your business can see and prove.