The article
Who can still get into your cloud who should not? A developer who left last spring, a contractor whose project ended, a key made for a test and never deleted. None of them needs a clever attacker to become a problem: access nobody remembers is access nobody watches.
My team works as a cloud security company inside a software company. The engineers who lock down your cloud sit next to the developers who write code, so a hole gets closed where it actually is, in the settings or in the app. Below: what your cloud provider protects and what is yours, how a review goes, a self-check you can run this week, and the part of security we leave to others.
Cloud security with us, in short
| What | How it works |
|---|---|
| Starts with | A review of your accounts, roles, networks, storage and the code that talks to them |
| You get | A list of what is open, what is outdated and what to fix first, in plain words |
| Fixes | Our DevOps engineers and developers, or your own team working from our list; either way, we can check the result |
| Clouds | AWS, Azure and Google Cloud, setups that mix them and servers of your own |
| Upkeep | Updates, access reviews and log checks as your software and your team change |
| Price | An individual estimate after a first look; the first call and a rough estimate are free |
What your cloud provider protects, and what is yours
AWS, Azure and Google Cloud protect their data centers, their hardware and the services they run. What happens inside your account is yours: who can sign in and with what rights, which storage is open to the internet, where keys and passwords live, what gets updated and who reads the logs. The providers call this shared responsibility.
A cloud security services provider works on your side of that line. It does not replace the provider's protection; it makes sure your half is done and stays done while people join, leave and change things.
Cloud security services, layer by layer
- Access. Each person and each service gets only the rights it needs, so one stolen password opens one door, not all of them.
- Two-factor sign-in on every account that matters, starting with the account owner's.
- Secrets in a vault, not in the code, in a settings file or in a chat thread.
- Networks closed to everything that has no business there: a database should never answer the whole internet.
- Encryption of data where it is stored and on the way.
- Updates for servers, containers and the libraries your code uses.
Each layer is simple on its own. The work is keeping all six true while the team, the code and the cloud keep changing.
Where it starts: a review before anything changes
- Review. We go through accounts, roles, networks, storage and the code that talks to them. Nothing changes while we look.
- Findings. What is open, what is outdated and what to fix first, in plain words that a non-engineer can follow.
- Fixes. We close the gaps in the cloud and in the app, each change reviewed by an engineer, or your team works from our list and we check the result.
- Upkeep. Updates, access reviews and log checks as your software and your team change.
Your part is to give us access to read the setup and the code, name the person who decides what gets fixed first, and tell us who has joined or left lately. The review works even if someone else built your software, because we read it the same way.
Why your cloud security company should know the code
Many breaches start in the app, not only in the console: a key left in the code, a storage bucket open to everyone, a library nobody updated. A team that only manages servers can close the bucket. It cannot take the key out of the code, replace it and make sure the app still starts afterwards. Our developers and DevOps engineers close those gaps together, on both sides.
In the software we build ourselves, access rules, secrets and encryption are planned in discovery, before the first line of code.
A self-check you can run this week
In October 2026 I read five cloud security pages from companies Google showed me for these searches. None of them says what happens to access when a person leaves the team, only one mentions two-factor sign-in, and none names a price. Five pages are a small sample, so read it as a reason to check your own setup, not as a statistic. Here is the check; forward it to whoever holds the keys to your cloud.
| Question | A good answer | Why it matters |
|---|---|---|
| Who has owner or admin rights? | A short list of names you recognize | Every admin is a way in |
| Is two-factor sign-in on for everyone, the account owner first? | Yes, with no exceptions "for now" | A password alone is one phishing email away from a stranger |
| Did access end the day each person or contractor left? | Yes, from a written list | Former staff and old contractors keep working keys |
| Are there keys nobody can explain? | No: every key has an owner and gets replaced on a schedule | Old keys leak through old laptops and old repositories |
| Is any storage open to everyone on the internet? | Only what is meant to be public, such as site images | One open bucket can publish your customers' files |
| Where do passwords and keys live? | In a vault | Code, settings files and chats get copied and shared |
| Which ports and services answer the internet? | Only those that must, each with a reason | Anything left open gets probed |
| Is data encrypted where it is stored and on the way? | Yes, both | A copied disk or an intercepted connection reveals nothing |
| When were servers, containers and libraries last updated? | Recently, on a schedule | Known holes are the first ones attacked |
| Are sign-ins and admin changes logged, with alerts to a person? | Yes, and that person is named | A break-in nobody sees keeps going |
| Can someone who breaks into the main account delete the backups? | No: the copies sit in a separate account | Ransomware goes after the copies too |
Any "no" or "I don't know" in your answers is where a review starts.
Compliance: what we set up, and who signs
If your data falls under HIPAA, PCI DSS, SOC 2 or GDPR, the cloud settings are part of the answer: access, encryption, logging, backups and the evidence that they stay that way. That part is engineering, and we do it. The other part is not ours. Reports and certificates such as SOC 2 or ISO 27001 come from independent auditors or assessors, never from us, and the legal reading of the rules comes from your counsel or compliance advisor.
So we do not promise that a setup "is compliant". We prepare the technical side and the evidence those people will ask for; more on that under cloud compliance.
Our work: systems that hold sensitive data
- RxPhoto keeps clinics' before-and-after photos, forms and notes in one record per patient, built for HIPAA work. We worked on the backend, the web front end and the API behind the mobile app. The hard part: photos go straight into the patient's record on a secure cloud portal, and an audit log lets a practice administrator show who opened which record and when.
- Tarot Fans is an app we built for clients and tarot experts, and it moves money in both directions: clients top up and pay by the minute, experts earn and withdraw. The hard part: the wallet keeps every balance and transaction straight, with Stripe underneath, while live video, calls and chat run at the same time. The app is live on Google Play.
Clients rate our work 5.0 on Clutch from 26 verified reviews, as of September 2026, and not one review is bad.
What the price depends on
Every engagement starts with a look, because the price follows what we find:
- How many accounts, projects and environments you run, and in how many clouds.
- How many services and how much code touch sensitive data.
- Whether we make the fixes or your team does, with us checking the result.
- The rules your data falls under.
- How much upkeep you want after the fixes.
The first call and a rough estimate are free. Before you talk to any cloud security services company, run the self-check above: it makes the first call shorter and the estimate sharper. If the review shows that your setup needs ongoing care rather than a one-off fix, that is managed cloud, with security as one part of it.
What stays yours
The findings, the fixes and the settings live in your account and your code repository, not in ours. Every access and service is written down, so a new engineer starts fast and anyone who leaves the project leaves a clear list of what to revoke. That list is also your answer to the third row of the self-check.
What a review does not cover
A review closes today's gaps; it does not watch tomorrow. For that, there is cyber security monitoring, and for a test that tries your defenses the way an attacker would, penetration testing. Keep the backups out of reach as well: cloud backup puts the copies in a separate account. The rest of our cloud work is on cloud services.
Ask for a review of your cloud: we check the setup and send you a list of what to fix first. We answer new requests within 30 minutes on weekdays, 9:00-18:00 Miami time.
