Cyber Security — Frequently Asked Questions

Where to start#

We have no security team. What do we do first?#

In this order, because it reflects how organisations are actually compromised:

1. Multi-factor authentication everywhere it is available, starting with email and anything with administrative rights.
2. Know what you have — systems, domains, cloud accounts, who has access to each. You cannot protect an inventory you do not have.
3. Patch what faces the internet, on a schedule someone owns.
4. Backups that have been restored from, kept where an attacker with your credentials cannot delete them.
5. Remove access when people leave, reliably, with a checklist.

None of this is sophisticated. Most incidents at small and mid-sized organisations involve a stolen password, an unpatched internet-facing system, or a mistake — not a novel technique.

Isn't security expensive?#

The expensive part is usually tooling nobody has time to run. The list above is mostly configuration and discipline, and it removes more risk per pound than any product you can buy in the first year.

Buy tools when you have someone who will read their output. An alert stream nobody watches is a cost with no control attached.

Identity and access#

Is MFA really that important?#

Yes — it remains the single highest-value control available to most organisations, because password reuse and phishing are how attackers most commonly get in.

Not all factors are equal: app-based codes are far better than SMS, and hardware keys or passkeys are better again because they resist phishing outright. If you can only protect a few accounts properly, protect email and administrator accounts first — email is the reset path to everything else.

How should we handle joiners, movers and leavers?#

As a checklist with an owner, tied to whatever HR system says someone has left. Access that outlives employment is common, quiet, and hard to explain afterwards.

The "movers" case is the one that gets missed: people change roles and accumulate permissions from both. Review access periodically and remove what is no longer used.

Where do we put secrets?#

In a secrets manager, referenced at runtime by an identity — not in code, not in a repository, not in a shared document, not in environment files distributed by hand. Rotate them, and confirm the rotation works without a redeploy.

If a secret has ever been committed to version control, treat it as compromised and rotate it. Removing it from the current files does not remove it from history.

Everyday risks#

What about phishing?#

Assume someone will click, because eventually someone will. Training reduces the rate and does not reach zero.

Design so a click is not catastrophic: phishing-resistant MFA, no standing administrative rights, alerting on unusual sign-ins, and a route for staff to report a mistake without fear. The last one matters more than it looks — the difference between a contained incident and a serious one is often how quickly someone admits what happened.

How do we handle third parties and vendors?#

Know who has access to what, and to which data. Ask for evidence rather than assurances — a current certification, a recent test summary, their breach notification commitment.

Then plan for their failure: what breaks if this vendor is compromised, and would you find out from them or from the news? Supply chain incidents affect organisations that did nothing wrong themselves.

Do we need a penetration test?#

It is useful once the basics are in place. A test run before you have patching, MFA and access control will produce a report that says exactly that, at consultancy rates.

Understand what a test tells you: that a skilled person, in a bounded window, with a defined scope, found these issues. It is a snapshot, not a certificate. What you do with the findings matters more than the findings.

Is cyber insurance worth it?#

It can be, particularly for incident response support you would otherwise have to find under pressure. Read the conditions carefully — policies increasingly require specific controls to be in place, and a claim is a poor time to discover you did not meet one.

When something happens#

What do we do in the first hour?#

Name an incident lead. Start a written timeline with timestamps. Preserve evidence before you change anything you can preserve. Decide on containment consciously, accepting the trade-off, and write down who approved it.

Do not rebuild the affected system immediately — that destroys the evidence you need to work out what happened and whether it is still happening. And do not communicate a scope you have not confirmed; the first number always circulates.

When do we have to tell someone?#

Sooner than most teams expect, and the clock usually starts at awareness rather than at resolution. Under GDPR, personal data breaches are notifiable to the supervisory authority within 72 hours of becoming aware, subject to specific exceptions, and affected individuals must be told when the risk to them is high. Other regimes and contracts impose their own deadlines.

Confirm which apply to you with counsel before you need them, and keep the deadlines written where the incident lead will find them. This is general information, not legal advice.

What does a good post-incident review look like?#

Blameless, written within a week, and productive of specific actions with owners and dates. Root cause is a condition, not a person — "an engineer clicked a link" is not a root cause; "any clicked link led directly to an account without phishing-resistant MFA" is.

Aim for at least one action each in prevention, detection and response. Reviews that only produce prevention items quietly assume the next incident will look like this one.

How do we know if we are getting better?#

Measure a few honest things over time: how long between an attacker's earliest activity and your detection, how long from detection to containment, what fraction of internet-facing systems are patched within your own target, how many accounts lack MFA, and when you last restored from a backup successfully.

Those five numbers describe your security posture more accurately than any maturity score.

Back to Cyber Security