At some point in 2004, someone handed me a pen and said I was now responsible for writing the national cryptographic algorithms standard for the NHS. I don't mean they asked politely and I agreed. I mean the actual pen was passed across a table, and I became the person whose words would govern what cryptographic systems could be used to protect patient records across England. It was one of the stranger things that has happened to me, and I've thought about it more than I might expect.

Connecting for Health was the programme to digitise NHS patient records — eventually all of them, for a population of sixty million people. One of the largest public sector IT programmes in the world at that point. The question of which cryptographic algorithms would be approved for the whole system needed a written answer. What encrypts a patient record? What signs a transaction? What was permitted and what wasn't?

That document was part of my work to write.

Here's the thing about standards that doesn't get discussed much: **standards are commitments.** You are writing something that will outlive you. You are writing something that other people will read as a binding constraint, not as a suggestion. Every word matters because every word will be interpreted by implementers, auditors, procurement committees — people you'll never meet, solving problems you can't predict.

The source material was mainly NIST Special Publications: SP 800-57 on key management, algorithm recommendations, guidance on key lengths and cipher suites. Painstaking documents, not light reading. But translating that into a UK public sector standard that actual systems could implement required being clear about the reasoning, not just the conclusion. You couldn't say "use AES-256." You had to say why. What's the threat model? What's the minimum acceptable key length for a record that might need to be confidential fifty years from now? What happens when the algorithm landscape shifts?

A colleague, Hargreaves, worked on it with me. He had policy background; I had technical depth. We argued productively about the difference between what was theoretically correct and what was deployable in NHS systems running on hardware that was, charitably, not recent. That tension — between the ideal and the implementable — is the actual interesting problem in standards work, and it doesn't resolve cleanly.

What I remember most is the weight of writing a sentence. Not weight in a dramatic sense. The weight of precision. If you wrote "SHALL" versus "SHOULD", that difference had a defined technical meaning and would be read that way. Every word went in deliberately. Editing it was like editing code: find ambiguity, resolve it, check that the resolution didn't introduce new ambiguity elsewhere.

The standard covered patient records. Prescriptions, referrals, clinical staff authentication, data integrity. Sixty million people, not abstract to me. I co-authored one document in a programme with hundreds, but it mattered. I was given the pen. I wrote carefully.

Standards work is invisible. The document exists, it shaped what got built, but you don't see the effect. Somewhere a system encrypted a patient record using an algorithm I specified. Somewhere an implementer made a decision about key length based on a sentence I spent an afternoon getting exactly right. I'll never know those specifics. That's how standards work.

There's a particular satisfaction in having done something useful that doesn't require visibility. I've had noisier, higher-profile roles. This was neither. Just careful work on something that needed to be done carefully, for people who wouldn't know it had been done at all.

That seems like the right way for it to have gone.