We have been asked, more than once, which product turned a security programme around. The honest answer is that it was never a product. Three engagements, three organisations of very different sizes, and the same answer each time.
Twenty plants, one small team
A manufacturing group with more than twenty plants ran security the way many groups do: a handful of people at head office covering firewalls, directory services and antivirus for everyone, and sites that were, in practice, independent. The head office team was entirely from one country. The sites were on three continents.
When we arrived as acting CISO, the sites pushed back on almost everything. One site, asked to apply a new set of hardening policies, pointed out that about a third of the settings had been in place there for a decade. It was right. The same site also did not patch its isolated production network, and still had a hundred and fifty office PCs on an operating system that had been out of support for a year. Both things were true, and neither was a technology problem.
The programme’s turning point came after the ransomware attack, when the executive committee had reason to pay attention. The proposal that landed was not a tool. It was a global team: a lead for each technical domain, a security lead at every site with a name and a role, written procedures, and mandatory change control. Eighteen months in, the programme was mapped to a recognised framework and the stated next step was for security decisions to be taken jointly by IT and the business at executive level. A later internal review named the real obstacles the programme had faced: a lack of legitimacy on the sites, no complete asset inventory, and no security without executive backing. Not one of them is fixed by a purchase.
Forty-one open points, mostly ownership
A card-payment processor went into its first 3DS assessment with a mature security management system and came out of the on-site days with forty-one requirements that had open points. Reading them back, the technical findings were few: authentication data kept longer than the standard allows, a content security policy that allowed inline scripts, four people entering a single-entry mantrap on four badges.
The rest were about who owned what. No formal definition of the 3DS environment. Responsibilities with the data-centre provider never written down. A critical-software list that nobody had been asked to keep current. The assessment went from forty-one open points to certification in two months, and almost none of that time was spent on technology. It was spent deciding who was responsible for each document and getting them to sign it.
What a regulator actually reads
A payments company preparing for its banking regulator’s authorisation asked for a full set of information security policies. The temptation, and the template packs on sale, say: forty documents, change the logo, done.
What the regulator reads is different. It reads whether the policy describes something the company will actually do, and whether there is evidence of it being done. The reference policies we compared for that engagement came from three very different organisations: one large policy revised yearly for a decade, a modular set of fifteen documents on an international standard’s structure, and a short one written by a small company to meet exactly the customer requirements it had. The best of them shared one quality. They promised only what their organisation could keep, and said how it would be proved. Patch timelines by severity, with an exception process for when they are missed. A scanning schedule with a rescan after any significant change. Review dates that are kept: one of them had six dated versions in five years, which is itself evidence.
We delivered the modular model: an umbrella policy and a short set of policies and procedures, each with an owner, on an international standard’s structure. The regulator accepted the set without a question. We suspect its bar was not high. That is not a reason to lower yours, because the next reader will be an assessor or a customer, and they will ask.
What people get wrong
They buy products to make up for missing governance. A detection platform does not create a person who is accountable for responding. A policy pack does not create a committee that reads the exceptions.
They treat security as an IT-department topic. The sites that resisted the manufacturing group’s programme were not resisting security. They were resisting instructions from a department that had no legitimacy to give them. The moment the instruction came from the executive committee, with a site security lead who reported upward, the resistance became a conversation.
They write aspirational timelines. A policy that promises a twenty-four hour patch window the organisation has never met once is not ambitious. It is a finding waiting to be written.
A detection platform does not create a person who is accountable for responding.