The article
Your cloud account was set up by your first developer, who has since left. More people have been given access since then, nobody is sure which storage is public, and a client has just asked how your data is encrypted. Cloud and cybersecurity consulting answers those questions: we review your accounts and architecture, set the rules for access, networks and data, and plan the security of what you build next.
I have been building software for 18 years. Since 2017 my team has delivered 150+ projects, and its 70+ specialists are engineers, designers, QA, DevOps and managers. The cloud is where information security and our DevOps work meet. Our cloud security advice is planned with engineers who run clouds every day, so every rule we write is one we know how to set up.
Cloud and cybersecurity consulting: the short version
| What | How it works |
|---|---|
| For whom | Companies moving to the cloud or growing in it |
| Clouds | AWS, Azure and Google Cloud, and setups that mix them with servers of your own |
| What we review | Accounts and access; networks and what is open to the internet; where sensitive data lives and how it is encrypted; logging, alerts and backups; the pipelines that ship your code |
| What you get | The gaps ranked, the rules for access, networks and data, and a plan for what you build next |
| After the advice | Our DevOps engineers carry out the plan, or your team does and we check the result |
| Price | The first call and the rough estimate are free; the review is estimated before it starts |
What the provider secures, and what is yours
The provider secures the infrastructure; almost everything you configure on top of it is yours. AWS, for example, says it protects the infrastructure that runs its services, while the customer's share depends on the services chosen. On a virtual server, that share is the operating system and its patches, the software you install and the firewall settings; on storage and database services, it is your data, its encryption options and the permissions you grant.
| Layer | Who secures it |
|---|---|
| Data centers, hardware and the provider's own network | The provider |
| The operating systems of your virtual servers, and their updates | You |
| Firewall and network rules | You |
| Who can sign in, and what each person may do | You |
| Your data: where it lives, how it is encrypted, who may read it | You |
| Your application, its code and its keys | You |
In October 2026 I read three cloud and security consulting pages that rank on Google's first page. None of them mentions this split, and only one mentions multi-factor sign-in. Three pages are a small sample, but the split is the first thing a business moving into the cloud should understand.
Your cloud, from accounts to data
Cloud and cybersecurity consulting covers five areas, from who can sign in to how your code reaches production:
- Account structure, and who can reach what. Production kept apart from testing, personal sign-ins with two-factor instead of shared logins, roles instead of long-lived keys, and the owner account locked away.
- Networks, firewalls and what is open to the internet. Databases, admin panels and remote access closed to the world and reachable only through a private connection.
- Where sensitive data lives and how it is encrypted. A map of every place that holds personal or financial data, encryption where data is stored and on the way, and no storage open to everyone.
- Logging, alerts and backups. Logs that are on and kept, alerts that someone reads, and backups in a separate account that have actually been restored.
- The pipelines that ship your code. Who can deploy, where the pipeline keeps its secrets, and whether a stolen laptop can reach production.
Least access, by design
Least access means that every person and every service gets only the rights its job needs, for only as long as it needs them. In practice it comes down to three habits:
- People sign in as themselves and get roles, not copies of a shared key.
- Servers and pipelines get short-lived credentials that expire on their own, instead of keys that live for years in a file.
- Every change of rights is logged, so a review can see who gave what to whom.
The payoff comes on a bad day: a stolen laptop or a leaked key opens one narrow door, not the whole building.
What you open to the internet gets found fast
Assume that anything new on the internet will be probed within hours, not when it becomes famous. When we launched the site of Muzychko Vocal School, a bot tried its admin page 102 times a minute, an hour after the site's certificate was issued. It had found the new domain in public certificate logs, where issued certificates are listed for anyone to read. We moved the admin to a secret path.
The same logs list the new subdomains a company secures, including test servers and staging copies nobody meant to show. So a cloud review should start from the outside: list what answers from the internet, then read the settings behind it.
Self-check: ten things to look at in your cloud this week
Forward this table to whoever runs your cloud. Each row is one check, where to look, and what to do if it fails:
| Check | Where to look | If it fails |
|---|---|---|
| Two-factor sign-in on every account that can change production | The user list in your provider's identity console | Turn it on, starting with the admins |
| One person, one account | People against accounts | Personal accounts with roles; no shared passwords |
| Nobody who left still has access | The user list against your staff list | Remove them today; connect sign-in to your company directory |
| The owner account is not used day to day | Its last sign-in date (AWS calls it root) | Lock it with two-factor and keep it for emergencies |
| No keys in the code | A search of the repository for key patterns | Replace the key, then keep the new one in a vault |
| No storage open to everyone | The provider's public access settings | Close it; share through the app instead |
| Databases and admin panels closed to the internet | Network rules that accept traffic from anywhere | Close them; reach them through a private connection |
| Logs are on and kept | The audit log settings | Turn them on and set how long they are kept |
| A backup was restored this quarter | The date of the last restore test | Restore one now and time it |
| A spending alert exists | Billing settings | Set one: a sudden jump can mean someone else is using your keys |
Where these settings live in AWS, Azure and Google Cloud
The same checks have different names in each cloud. If you are not sure where to look, start here:
| What | AWS | Azure | Google Cloud |
|---|---|---|---|
| Sign-in and roles | IAM and IAM Identity Center | Microsoft Entra ID | Cloud IAM |
| Who changed what | CloudTrail | The activity log in Azure Monitor | Cloud Audit Logs |
| Keys and secrets | KMS and Secrets Manager | Key Vault | Cloud KMS and Secret Manager |
If your only cloud is email and files in Microsoft 365 or Google Workspace, the same basics apply: two-factor sign-in, no shared accounts, nobody who left still inside. Cybersecurity for small business covers them.
From advice to a secured cloud
Our DevOps engineers can carry out the plan, or your team can, with us checking the result. If you want the cloud kept secure month after month, that is cloud security services or managed cloud services. If you are about to move, security belongs in the plan of the cloud migration, before the first resource is created. If you mix a cloud with servers of your own, one set of rules for access, backups and updates should cover both, as in hybrid cloud management.
Many breaches start in the app rather than in the cloud settings: a key left in the code, a library nobody updated. Our developers and DevOps engineers close those gaps on both sides, and in the custom software we build, access rules, secrets and encryption are planned in discovery, before the first line of code.
How the review goes
- A free first call about what you run and what worries you. If you need an NDA, we sign it before you share details; on weekdays from 9 am to 6 pm Miami time, we reply to a new request within 30 minutes.
- Read-only access to the accounts in scope, plus any diagram or list of systems you have. If none exists, that is the first finding.
- From the outside in: what answers from the internet first, then the settings behind it, area by area.
- Findings and rules: the gaps ranked by risk, and the rules for access, networks and data written down.
- A call to walk through it, then the fixes, by our engineers or yours, and a check of the result.
Compliance in the cloud
HIPAA, PCI DSS, SOC 2 and GDPR all ask things of your cloud setup. Which services you may use for regulated data, and in which region it has to stay, is a question for your compliance advisor. Once you have the answer, we set up accounts, access, encryption, logging and backups to match and keep the evidence: that is cloud compliance.
What the review costs
Every cloud review is estimated before work starts, and the first call and the rough estimate are free. The price depends on:
- how many accounts, subscriptions or projects you have, and on how many clouds;
- how many environments: production, testing, development;
- whether servers of your own are part of the setup;
- whether you also want a penetration test of the cloud accounts and their settings;
- whether our engineers also make the fixes.
If you are not sure the cloud is your weakest point, a security assessment looks at the whole company first. The rest of what we advise on is under cybersecurity consulting.
Tell us about your cloud. We reply with what we would review first and a rough estimate, free.
