ISO 27001:2022, and What Certification Actually Changed Here

In July we wrote that we run our information-security program to the ISO 27001 framework, that we’d passed every audit in the process, and that we were waiting on the certificate itself. Perry Johnson Registrars issued it on 24 July 2026, against the 2022 revision of the standard, with this scope:

Operation and management of secure, highly available Web3 infrastructure systems. This includes providing node services to partners, with a focus on the Chainlink ecosystem.

Several other Chainlink node operators have announced the same thing over the past months, which is a good sign for the network and something we’d rather see more of than less. It does mean a certificate on its own no longer tells anyone very much. So instead of a badge and a press release, here is what the process actually surfaced for a team whose entire job is running nodes.

Five years of runbooks, then a framework to test them against

We didn’t rebuild the company to pass an audit. LinkRiver has been operating Chainlink infrastructure since 2021, and most of what an ISMS asks for already existed under different names: the on-call rotation and the monitoring discipline behind it, key handling, change control on node upgrades, the reasoning behind running on dedicated bare metal. Five years of production incidents write those procedures whether or not anyone is auditing you. What the certification did was give them a common vocabulary, a documented owner, and a review cycle.

That said, treating the framework as pure paperwork would undersell it. Working through the standard put topics on the table that we hadn’t examined with the same rigour, and several procedures came out genuinely hardened rather than merely written down. Business continuity was the clearest example. Building out continuity plans scenario by scenario forced us to weight them by what a given failure would mean for the Chainlink products sitting on top of our infrastructure, which is a different exercise from generic disaster recovery. A plan that treats every service as equally critical is a plan nobody can execute at three in the morning. Ranking them against product significance produced something an engineer can act on under pressure, and that came out of the process, not before it.

What the standard looks like when the asset is a node

ISO 27001 is deliberately industry-agnostic, which is its strength as a framework and the reason the certificate alone is uninformative. Every certified organisation works from the same Annex A control set. The document worth talking about is the Statement of Applicability, because that’s where a generic standard meets a specific threat model, and ours is shaped by the fact that we run oracle infrastructure for financial applications.

Supply chain dominates it. A node’s data path and its build path both run through code and services we don’t own: blockchain client software and endpoint dependencies, the crypto tooling the industry shares, and the ordinary developer toolchain underneath all of it. Package registries have turned into an active attack surface over the past two years, and the compromises that made the news reached packages depended on by more or less everyone. That risk doesn’t respect the boundary of our own infrastructure, so the controls around it can’t stop at our perimeter either. Dependency provenance, build isolation, and knowing quickly when something upstream has been touched matter more here than another firewall rule.

Social engineering is the other half, and it has changed shape. The economics of a convincing pretext collapsed once AI could generate one at volume, in fluent language, with real context scraped from public sources. Voice and video are no longer a reliable second factor for confirming that a person is who they claim to be. For an operator, the exposure grows with every integration: each new chain, data vendor, bridge, or partner adds people to talk to, channels to talk on, and one more plausible story an attacker can borrow. Controls that assume an attacker sounds wrong are obsolete. What holds up is procedural, boring and unglamorous. Out-of-band verification for anything touching keys or funds, no exceptions for urgency, and a culture where slowing down a senior person to confirm a request is expected rather than awkward.

The rest of the scope follows the same logic: signing key custody and rotation, wallet handling, privileged access on a small team, physical and vendor controls on the hardware, and the upgrade and rollback path for node software. None of it is exotic. It’s the same class of question a custodian answers, applied to the jobs a node operator does in this stack.

On the 2022 revision

Worth one line, because the two versions look identical as a logo. Our certificate is against ISO/IEC 27001:2022, the current revision, not the legacy 2013 edition. The 2022 control set is the one that treats cloud services, threat intelligence, ICT continuity, and configuration management as named controls, and those happen to describe a fair amount of what running node infrastructure involves.

The audit ends, the program doesn’t

Certification runs on a three-year cycle with surveillance audits in between, so the certificate is revocable and gets re-tested on a schedule. That’s the formal answer. The practical one is that the value of a framework shows up in how an organisation behaves on an ordinary Tuesday, not in how it performs for an auditor.

The supply-chain incidents in the npm ecosystem over the past year, including the wave that touched packages as widely used as axios, gave us that test without asking for it. What we cared about afterwards wasn’t whether we’d been exposed, it was whether the machinery worked end to end, and it did: detection, triage, an accurate scoping decision, and communication reaching the stakeholders who needed it while the picture was still incomplete. Every event of that kind also feeds a structured improvement track, so the outcome is a concrete change to a control or a procedure rather than a post-mortem document nobody reads twice. Continual improvement is a clause in the standard. Treating it as a habit instead of a clause is the part that decides whether any of this was worth doing.

Training sits in the same category. An ISMS that lives in a folder protects nothing. The people making judgement calls under time pressure, about a strange request or an unfamiliar dependency, are the control that actually fires.

Why more of this is good for Chainlink

The certificate is the visible part, and it’s genuinely useful to have something external to point at when an institution asks. The value is in running the organisation this way, which is invisible from the outside and much harder to fake.

The direction of travel is clear enough. Chainlink Labs is ISO 27001 certified, regulated finance is settling onto CCIP, CRE, and networks like Canton, and the standards those institutions already live by are reaching the infrastructure layer underneath them. Security in a decentralized oracle network is a property of the operator set, not of any one member. Every operator that raises its own floor raises the floor of every network it participates in, which is why we’re glad to see peers doing the same thing we are.

LinkRiver has helped secure Chainlink’s networks since 2021. The certificate says a third party checked. The work is what it was before, done to a standard we can now show.