Risk analysis and recommendations

Meanwhile the actual exposure sits somewhere less interesting. An accounting system on a machine that has not been updated in two years. Ten people sharing one administrator password. A supplier with permanent access to your environment that nobody has reviewed since the integration was built.

A risk analysis puts those things in one place and in order. It is not a comfortable document to read, and it is considerably cheaper than finding out empirically.

An online shop loses money by the hour when it is down, so availability dominates. A law firm might survive a day of downtime without much harm but would be seriously damaged by a leak of client documents, so confidentiality dominates. A manufacturer with production systems on the network has a physical safety dimension the other two do not. A company that processes personal data at scale carries a legal exposure that changes the calculation again.

So we start with the business, not with the network. What you sell, what stops if something breaks, which data would hurt most if it appeared publicly, and which obligations you carry towards your customers. The technical inventory comes after, because it is only interpretable once you know what matters.

Along the way this typically surfaces things nobody had written down. Which systems the invoicing process actually depends on. That one spreadsheet that half of operations is built around, sitting on a laptop.

The scenarios that actually deserve modelling are ordinary. An employee opens an attachment and ransomware encrypts the file server. A mailbox is compromised and used to send a payment-detail change to your customers. A laptop is stolen from a car with the disk unencrypted. A supplier is breached and their access to your systems is used. A database is deleted by mistake during a routine change and the backup turns out to be incomplete.

For each one, the useful exercise is walking through the hours after it happens. Who notices, and how long does that take. What stops working. What it costs per day. Which existing safeguard would hold and which would turn out to be theoretical. That walkthrough is usually where the priority list writes itself, because the gaps become obvious in a way that no severity score conveys.

That ratio produces some unglamorous winners. Testing that your backups restore. Removing accounts belonging to people who left. Turning on multi-factor authentication for email and admin consoles. Patching the internet-facing systems. None of it is interesting, all of it is cheap, and together it eliminates most of the realistic scenarios.

The expensive items go further down, and some of them should stay undone. A company of thirty people does not need a round-the-clock security operations centre. Saying so is part of the job. We would rather you spend the budget on the three things that move your risk than on a programme that looks thorough and leaves the file server unpatched.

You will also see recommendations we expect you to decline. That is fine, as long as the decision is deliberate. An accepted risk that someone chose knowingly is a normal part of running a business. An accepted risk nobody knew about is the problem.

That last part matters more than it sounds. Most companies cannot describe their own exposure in a sentence, which makes every security conversation a negotiation between vague anxiety and vague reassurance. Replacing that with a specific list is the point of the exercise.