Security By Hsin, Head of Product 31 August 2026 繁體中文

You should own everything. You don't have to run it.

Yesterday's post argued for custody over trust, and the most common reply was a fair one: "We're six people. We don't have anyone to run a cloud account." That objection deserves a real answer, because the answer is not "then go hire an ops team." It's that owning something and running it are two different jobs, and only one of them has to be yours.

Hiring people to run your machines, scan your cloud, or patch your servers is normal — it's the same shape as hiring an accountant. What went wrong for the teams caught by this leak wasn't that they got help. It's that they handed over ownership along with the work.

What those teams actually lost

Not just keys and data — those can be rotated and, painfully, rebuilt. What they lost was the ability to answer their own questions. What exactly did I have there? Which of my credentials still work? Who touched my database, and when? Every one of those answers lived in someone else's system, and the only way to get one was to wait for an announcement and decide whether to believe it.

That's what it means to have handed over ownership. And notice that it has nothing to do with whether you have engineers. A team of fifty with no ownership is in the same position as a team of three. Ownership isn't a headcount question.

Four things you never hand over

Everything else is negotiable. These four are what "you own it" actually means, and none of them requires an engineer on staff:

1. The account is in your name. The cloud provider's invoice arrives at your company, on an account your company holds. Setting one up takes an afternoon and a credit card. Running it is the hard part — and running it is the part you're allowed to delegate.
2. Your data lives inside that account. Not on a vendor's platform that happens to store it for you. If you can't point at the bucket or the database and say "that one is mine," you don't have it.
3. You know what keys exist. You don't have to understand how they work. You do have to be able to get a list, and to have someone answer for anything on it you don't recognise.
4. You can remove anyone, yourself, today. Including us. Including whoever runs your servers. If removing a vendor's access requires that vendor's cooperation, you don't own the account — you're a guest on it.

Read the fourth one twice. Every bad story in this space ends at the same sentence: "we couldn't do anything but wait."

The work, you should absolutely delegate

Nobody thinks a company is irresponsible for using an accountant. You own the company and the bank account; someone qualified does the books. Nobody suggests you'd be safer doing your own audit.

Infrastructure is the same and we have somehow convinced ourselves it isn't. Running machines, patching them, watching them, scanning them for problems — these are jobs, and jobs can be hired. A six-person company doing its own server maintenance at midnight is not more secure than one that hired someone; it's usually less.

So the answer to "we have nobody to run it" isn't to stay on a platform that owns your stack. It's to own the account and hire the work.

Four tests of a healthy arrangement

Apply these to anyone you hire to touch your infrastructure — a managed-service provider, a contractor, a platform, us:

Can they only read, or can they change things too — and if they can change things, is the boundary written down somewhere you can check?
Does the report come to you first, or do you see the version they chose to send?
Can you end it unilaterally — no ticket, no notice period, no waiting for their business hours?
If they vanished overnight, would your service still be running tomorrow morning?

A vendor who passes all four can be trusted with a great deal of work, because none of it is load-bearing on trust. A vendor who fails the third or fourth isn't a supplier — they're a dependency, and you'll discover the difference on the worst possible day.

A security check-up is the cleanest example of this

Bringing in an outside firm to scan your cloud looks, at first glance, like handing over the keys. Done properly, it's the opposite — and it's worth seeing why, because it's the template for every other arrangement:

They get read-only access, which you created and can delete.
The findings are about your account, and they arrive in your hands.
When it's over, you remove the access and nothing of yours went anywhere.

Expert work, delivered, with ownership never moving. That's the shape to look for. If a vendor's version of the same service requires an administrator key "so we can fix things for you," you've been offered something different wearing the same name.

Here's one finding such a check-up turns up more than any other, and it costs nothing to go look for yourself: credentials that outlived the service they were made for. A contractor's access from a project that ended. A key issued for a migration two years ago. The service was switched off; the key never was. If you have a cloud account, ask whoever runs it for a list of credentials sorted by when they were last used, and ask what the unused ones are still for.

If you decide to move out

For a company with a real service, real customer data, and no IT department, the order that works is roughly this:

1. Open the cloud account yourself, in the company's name. Before you talk to anyone about migrating. This is the single step that decides whether the next arrangement is ownership or tenancy, and it's the easiest step in the whole process.
2. Write down what you actually have. What services run, what data they hold, what they connect to, what's in the configuration besides passwords. Most teams discover here that they have no complete list — which is itself the finding.
3. Then hire the move. A contractor, a managed provider, a platform. Ask them the four tests above before you ask them the price.
4. Delegate the running, in writing, including the boring parts. Especially what happens when something is switched off: who revokes its access, when, and how anyone would know it was done. Left unspecified, that job belongs to nobody — and that's how a shut-down service keeps a live key for two years.

Note what isn't on that list: learning to operate a cloud. You need to own an account, not become an engineer.

An honest reminder: moving costs something

A platform that owns your stack is genuinely easier on day one, and pretending otherwise would be dishonest. Moving out means a migration, a bill you now read yourself, and a relationship to manage. What you get for it is that on the bad day, the questions are answerable — by you, without permission.

And it doesn't have to happen this week. If you're staying where you are for now, the four tests are still worth running against your current platform. Knowing which ones it fails is worth having before you need it.

The short version

You don't have to become a company with an ops team to get your things back. You have to separate two questions: what you own — the account, the data, the keys, and the power to remove anyone — and what you hire someone to do.

A setup nobody really owns isn't safe because nothing has happened to it yet. It just hasn't been picked. And if yours was assembled a few years ago for speed and nobody has looked at it since, it has been quietly accumulating a bill you can't see.

The first step isn't the migration. It's opening the account in your own name — and asking the four questions above of whoever runs things for you today.

Disclosure: we are one of the vendors you might hire for exactly this, so we have a position. The four tests are the ones we'd want used on us — run them on us before you run them on anyone else. The open-source version is Apache 2.0, and the code that would run on your machines is readable by you or anyone you ask.

It's time to look at what you've granted your PaaS.

The four tests above cost nothing — start there. And if you'd rather walk through it with someone — what you've actually granted that platform, and what should come back — we'll do a free check-up consultation with you. No tooling to install, no sales call disguised as one.

Free check-up consultation How we do security & data residency