Cloud security basics checklist

Most cloud incidents come from a short list of avoidable mistakes: too much access, exposed storage, weak sign-in, unpatched software, leaked keys and nobody watching the logs. This checklist covers those basics in plain English. It works for AWS, Microsoft Azure, Google Cloud and the SaaS tools your team uses, and it applies equally to the cloud accounts that hold your AI projects.

Tick what you have in place today, and turn the gaps into a plan. Begin with sections 1 to 3, because they close the most common doors.

Not legal advice. This is general good practice. Your contracts, regulator and insurer may require more.

1. Know what you have

• You have a list of every cloud account, subscription and project, with a named owner for each.
• You know which SaaS and AI tools staff use, including those nobody formally approved (see shadow IT).
• You know where your sensitive data lives, and have classified it (public, internal, confidential, restricted).
• Old test accounts, unused projects and orphaned resources are reviewed and shut down on a schedule.
• You know who your cloud providers are and what they are responsible for compared with you (the shared responsibility model).

2. Sign-in and access

• Multi-factor authentication is on for every user, and phishing-resistant methods (passkeys or security keys) are used for administrators.
• The root or global owner account of every cloud is protected, used only for emergencies, and has no day-to-day use or access keys.
• Everyone has their own account. No shared logins.
• People and services get the least access they need (least privilege). Broad administrator roles are rare, justified and reviewed.
• Access is removed the same day someone leaves or changes role, including SaaS and AI tools.
• Access is reviewed regularly, and unused permissions are removed.
• Single sign-on is used where possible, so there is one place to switch access off.

3. Secrets, keys and tokens

• No passwords, keys or tokens are stored in code, chat, tickets, shared documents or AI prompts.
• Secrets live in a secrets manager or equivalent, not in files and environment variables copied around.
• Long-lived access keys are avoided. Short-lived credentials and roles are used where the platform supports them.
• Repositories are scanned for committed secrets, and a found secret is treated as compromised: revoke and rotate.
• You know how to rotate every key quickly. If a developer machine or a build pipeline is compromised, you can rotate all credentials it could reach. Incidents like the October 2026 LiteLLM package compromise show why: its guidance was to rebuild and rotate every reachable credential.

4. Data and storage

• Storage buckets, databases and file shares are private by default, and public access is blocked at account level where the platform allows.
• Data is encrypted in transit and at rest, and you know who controls the keys.
• Backups are made regularly, stored separately from the live system, and protected from deletion by the same accounts that can delete live data.
• You have tested a restore, not only taken the backup.
• Retention rules exist and data you no longer need is deleted.
• Sensitive data is not copied into test, analytics or AI tools without approval and protection.

5. Network and exposure

• You know every internet-facing service and why it is exposed.
• Management ports (remote desktop, SSH, database ports) are not open to the whole internet.
• Admin access goes through a controlled route (a VPN, a bastion or zero trust access tool) with MFA.
• Default accounts and passwords on devices and services are changed or disabled.
• Outbound traffic is restricted where practical. Microsoft's advice after the LiteLLM compromise included restricted egress to limit where stolen data can be sent.

6. Patching and software supply chain

• Operating systems, containers, applications and libraries are patched on a schedule, and critical or actively exploited issues are fixed urgently.
• You can answer "do we run this software, and where?" within hours when a new critical flaw is announced. The NCSC's advice on the PHP vulnerabilities in October 2026 was to identify PHP everywhere (not only old versions), prioritise internet-facing systems, update, and check for signs of compromise.
• Dependencies are pinned to known versions, and updates are reviewed before they reach production.
• Container images are pulled by digest or from a trusted internal registry, not floating tags.
• Build and deployment pipelines are protected like production, with limited access and protected credentials.

7. Logging, monitoring and alerts

• Cloud audit logs (who did what, and when) are switched on in every account and sent to a place the same admins cannot easily alter.
• Sign-in, permission change, key creation and data export events generate alerts that someone reads.
• Billing and spend alerts are set. Unexpected cost is often the first sign of misuse.
• Logs are kept long enough to investigate. You have decided how long, on purpose.
• You know who gets alerts out of hours and what they do.

8. Configuration and change

• Standard, reviewed configurations are used for new environments rather than ad hoc setups.
• Changes to cloud configuration are made through a controlled process, with a record of who approved them.
• Cloud settings are reviewed regularly against a recognised baseline, and misconfigurations are tracked to closure.
• Infrastructure defined as code is reviewed like any other code.

9. Suppliers and AI services

• Each supplier handling your data has been assessed, and you know where the data is processed.
• Contracts say what happens to your data, how fast you are told about incidents, and how you can leave.
• AI tools connected to your cloud data or accounts have limited, reviewed permissions. See the secure AI adoption checklist and the vendor questionnaire.

10. Be ready for an incident

• There is a written incident plan with contact details that work when email is down.
• You know how to isolate an account, revoke access and preserve evidence.
• You know your obligations to report: for personal data breaches, the ICO's 72-hour rule and, in regulated sectors, other duties.
• You have practised the plan at least once. See the incident response mini-playbook.
• You have signed up for the NCSC's Early Warning service, which is free for UK organisations.

A simple 30-day plan

• Week 1: Make the list of accounts and owners. Turn on MFA everywhere, starting with administrators and email. Secure the root accounts.
• Week 2: Block public storage by default. Review administrator roles. Remove leavers and unused accounts.
• Week 3: Remove secrets from code and chat. Turn on audit logs and billing alerts. Check backups restore.
• Week 4: Patch internet-facing systems. Write down the incident plan and run a short practice. Plan the next quarter.

Optional, from Pyralink. Auditors and customers often ask you to show that controls like these are in place, not just say so. PyraLink™ Prove produces digitally signed, dated evidence records for cloud security compliance that you can verify independently. This checklist works whether or not you use it.