AI security
Before you write an AI policy, find out where AI already is
Most AI policies we are shown were written before anyone counted. They prohibit things staff do every day and are silent on the tools the organisation has formally bought.
Start with an inventory, and expect three layers. The first is what you sanctioned: the assistants and copilots you licensed. The second is what arrived inside products you already own, where a vendor switched on an AI feature in a release note nobody read. The third is what staff use on their own, usually through a browser and a personal account.
For each entry, record four things: what data goes in, where it is processed, whether it is retained or used for training, and what the tool is able to do on its own. The last one matters most. A chatbot that leaks a paragraph is an incident. An agent with write access to your ticketing system or mailbox is a different class of problem.
Only then write the policy. It will be shorter, it will name real tools, and people will recognise their own work in it, which is the main reason policies get followed.
Identity
MFA is no longer the finish line
For a decade the advice was simple: turn on multi-factor authentication. It was good advice and it still is. It is also no longer sufficient, because attackers adapted.
Two techniques account for most of what we see. In the first, the attacker floods a user with approval prompts until one is accepted out of fatigue. In the second, a proxy site sits between the user and the real login page, lets the user complete MFA honestly, and steals the session token issued afterwards. The password and the second factor were both correct. The attacker simply collects the result.
The response is to move the controls later in the chain. Use phishing-resistant methods such as passkeys or FIDO2 keys for administrators and finance staff first. Bind sessions to managed devices. Shorten token lifetimes for sensitive applications. Alert on impossible travel and on new inbox rules, which are often the first thing an intruder creates.
None of this requires new products in most Microsoft 365 or Google Workspace estates. It requires configuration, and someone accountable for checking it stayed configured.
Assurance
Five questions to ask before you buy a penetration test
Penetration tests vary more in quality than almost any other security purchase, and the price tells you little. These five questions separate the useful from the ceremonial.
Who will do the testing, by name, and what have they tested before? You are buying individual skill. How much of the work is manual? Automated scanning has its place, but logic flaws and chained weaknesses are found by people. What does a finding look like? Ask for a redacted sample: you want reproducible steps, evidence, business impact and a specific fix.
Is retesting included? A test without a retest tells you what was wrong once. And what will you not test? A firm that can state its scope limits clearly has thought about your environment. One that promises everything has not.
A good tester will welcome all five questions. Treat hesitation on any of them as a finding in its own right.
