OOPUO
Review →
H.02
← Back to hardening
H.02 · Infrastructure

Infrastructure
hardening.

Everything the product sits on: who can reach the cloud account, how code gets to production, where the secrets live, and what happens on the day something has to be restored.

This layer rarely fails gradually. It works exactly as well as it ever did right up until a key leaks, a deploy goes wrong at the wrong hour, or someone needs a backup that turns out never to have been tested. The cost of getting it wrong is not a bug — it is downtime, a bill, or data you cannot get back.

Rules of engagement

Nothing touched without scope.

Infrastructure work runs against live systems, so the boundaries matter more here than anywhere. They are agreed in writing before anything begins.

Written scope
What may be accessed, changed, and restarted — agreed before the first command
Reversible
Changes land behind a rollback path, never as a one-way door
Yours after
Documented so your team runs it without OOPUO. No platform to license

Read-only access first, wherever the work allows it. Elevated access is requested for a named task, used for that task, and handed back.

What gets hardened

Four places it gives.

Cloud access and blast radius

Who and what can reach production, and how far a single compromised credential travels. Shared root logins, missing multi-factor on the accounts that matter, long-lived access keys, service accounts holding far more permission than their job needs, and databases reachable from the open internet because that was the fastest way to make it work.

DeliverableAn access map — every human and machine identity, what it can reach, and what to revoke first.

Deployment and rollback safety

How code reaches production and how fast it can be taken back out. Whether a deploy is reproducible or a laptop ritual, whether the previous version can be restored in minutes, whether database migrations can run backwards, and whether anyone can tell which commit is actually live right now.

DeliverableA deploy and rollback path that a tired person can execute correctly at 2am.

Secrets and environments

Where credentials live and which environments can see them. Keys committed to the repository or pasted into the AI tool that wrote the feature, one set of credentials shared across staging and production, third-party tokens nobody can rotate because nobody knows what would break, and no record of what was exposed when someone leaves.

DeliverableSecrets moved into managed storage, environments genuinely separated, and a rotation procedure that works.

Backups, recovery and observability

Whether you can see a problem and whether you can come back from one. Backups that exist but have never been restored, retention too short to survive a corruption noticed a week late, no alerting on the failures that matter, and logs that either do not exist or capture personal data nobody meant to keep.

DeliverableA restore actually performed and timed, plus alerting on the handful of signals worth waking up for.

How the work is done

Boring on purpose.

  1. 01

    Restore before you trust

    A backup nobody has restored is a belief, not a backup. The first useful thing this work produces is usually a timed restore into a scratch environment — which is also the moment you find out how long an outage would really last.

  2. 02

    Reduce the blast radius before adding tools

    Most infrastructure risk in a small team is not a missing product. It is one credential that can do everything. Narrowing permissions costs nothing per month and removes more risk than most of what gets bought.

  3. 03

    Match the setup to the team that has to run it

    A two-person team does not need the architecture of a fifty-person one, and giving it to them makes things worse. The target is the simplest arrangement that survives the failures you can actually name.

  4. 04

    Leave it documented and owned

    Every change is written down: what it does, why, and how to undo it. If OOPUO disappeared tomorrow, your team keeps operating the system without a gap.

Process

How an engagement runs.

  1. Scope

    A short call, then written authorisation naming the systems in scope, the access level needed, and what is explicitly off limits.

  2. Review

    The infrastructure is examined against the four areas above — read-only wherever the work allows it.

  3. Report

    A prioritised written report: what is exposed, what breaks first, what to change, and what can wait.

  4. Harden

    The fixes implemented against that report, each behind a rollback path, each documented as it lands.

Next

Start with the review.

Send what you are running and what worries you. The other two layers are application hardening and private AI. Once it is hardened, continuous operations is what keeps it that way.