DEV Community: Juan Cantón Rodríguez

The ISO 27001 controls that actually matter when you connect two systems

Juan Cantón Rodríguez — Sun, 12 Jul 2026 08:14:37 +0000

I build integrations for a living: ecommerce to ERP, CRM to invoicing, and lately ERPs to AI agents. Every one of them has the same quiet security problem, and most "ISO 27001 for developers" content misses it because it stays at the policy level.

Here is the thing nobody says out loud: integrating two systems means taking data out of the place where it lived protected and moving it across a network you do not control. Names, tax IDs, amounts, addresses, emails. That journey is the attack surface. Not the database. The trip.

You do not need to be ISO 27001 certified to care about this. Certification is a formal audit that makes sense when a client demands it. Applying the controls is what actually protects the data, and you can do it on the next integration you ship. So let me map the ISO 27001:2022 Annex A controls that land directly on integration work, in plain terms, with what I actually do for each one.

The controls, translated to integration reality

A.8.24 Use of cryptography. Data in transit goes over a network you do not own. In the clear, anyone on the path reads it. Rule: TLS 1.2+ end to end on every call, no plain HTTP between services, ever. Any intermediate copy (queue, staging, cache) is encrypted at rest.

A.5.17 Authentication information. The API key is the key to the house. Whoever holds it, gets in. So: keys in a secret manager, never in code or in the browser bundle, rotated on a schedule and on any suspicion of a leak. One credential per integration so you can revoke it in isolation.

A.5.15 / A.5.16 Access control and identity management. The temptation is to reuse the admin key because "it works with everything". If it leaks, the whole ERP leaks with it. Real least privilege instead: each flow gets a credential scoped to exactly what it needs. Read-only if it only reads. Scope is a decision, not a default.

A.5.14 Information transfer. A lazy integration drags a full record from one system to another "just in case". Every extra field is one more thing that can leak. Move only the fields the destination genuinely needs, and write down the data flow (what leaves, where to, on what legal basis).

A.8.15 / A.8.16 Logging and monitoring. Without traces, an integration is a black box. You cannot tell if an invoice was duplicated, if a webhook failed silently, or if someone is probing your credentials. Every sync leaves a queryable, tamper-evident record, and anomalies fire alerts: spikes in auth failures, stuck queues, retries that never resolve.

A.5.19 / A.5.21 Suppliers and ICT supply chain. This one flips the mirror. When I connect your systems, I become a supplier that touches your data. And behind me sits the hosting, the iPaaS, the payment gateway. All of them are in scope. That means a written data processing agreement and a real look at the sub-processors and where the data is hosted.

A.8.12 / A.5.34 Data leakage prevention and PII protection. The place personal data leaks most often by accident is not the database. It is the logs. A full payload dumped into a log line exposes tax IDs, emails and addresses to anyone with log access. Log just enough to debug, with sensitive fields masked.

A.8.10 / A.8.11 Information deletion and data masking. Integrations leave copies behind: queues, test environments, backups. Real customer data living in places nobody looks at again. Define retention per flow, delete for real when due, and work with masked or synthetic data outside production.

The two questions I always get

"Is n8n / Zapier / Make secure under ISO 27001?" The tool alone does not give you control. The control is in how you use it, and the biggest variable is where the data lives. A cloud iPaaS puts that third party into your supply chain and routes your data through their infra. Self-hosted n8n keeps the data on your own server, which massively simplifies scope. (I maintain an open-source n8n node for Holded, MIT, precisely so people can automate without shipping their data to one more vendor.)

"What about AI agents and MCP?" New actor, same controls. When you connect an agent (say via MCP, the protocol that lets an assistant read and act on external systems with typed permissions), you are giving a model access to real data. Scoped read-only credentials when reading is enough, traceability of every action, minimisation of what the model sees, and control over which provider that data reaches. The framework does not change just because the caller is a model.

The honest footer

I am not going to tell you I am ISO 27001 certified, because I am not, and saying so without an accredited body's badge would be a lie. What I will tell you is that these controls are cheap to apply if you build them in from the start and expensive to retrofit after a leak. The certification is the paperwork. The controls are the actual security.

Full version, with the framework reference table (93 controls, 4 themes, the 2013 to 2022 transition that closed in October 2025): francodesystems.com/en/blog/iso-27001-integrations.

If you handle other people's data through integrations, which controls have bitten you in production? Curious to compare notes in the comments.

I didn't write my n8n node's 323 operations. I scraped the docs and generated them.

Juan Cantón Rodríguez — Tue, 07 Jul 2026 08:24:16 +0000

Last month my n8n community node for Holded — the ERP used by 100,000+ Spanish SMEs — got the verified badge and became the only Holded integration on n8n.io.
A
It covers 42 resources and 323 operations of the Holded API v2, plus a trigger node for 58 webhook events.

Here's the part that matters: I hand-wrote almost none of it. This is the story of shipping a huge API surface as a solo dev by treating the node as a compiler target instead of a codebase.

Why bother with a node for a Spanish ERP?

Spanish SMEs are migrating to n8n from Make and Zapier for a very unglamorous reason: per-operation pricing. The moment you automate invoicing properly — say, an ecommerce store pushing 1,000+ orders a month into accounting — a per-task bill stops making sense. Self-hosting also plays well with GDPR anxiety.

The blocker was that n8n had zero Holded connectivity. Everyone was gluing HTTP Request nodes to a quirky API. That's the gap.

The math that forbids hand-writing

Holded's API v2 is big: invoices, contacts, products, stock, CRM funnels, projects, payroll, remittances… When I mapped it, I got 591 endpoints across 42 resources.

An n8n node describes every operation declaratively: resource options, operation options, every parameter with its type, defaults, and displayOptions controlling when it appears in the UI. Written by hand, that's maybe 60–80 lines per operation. Times 323.

That's a ~25,000-line file I would have to maintain by hand every time Holded touches their API. No.

The pipeline: scrape → spec → generate

So the repo has a spec/ folder that most n8n nodes don't:

spec/
├── scrape-v2.py        # scrapes the official API docs
├── v2-endpoints.json   # 72,000 lines: every endpoint, param, type
└── gen-v2.py           # 888 lines that write the node for me

scrape-v2.py walks Holded's API reference and dumps every endpoint — path, method, params, body schema — into v2-endpoints.json (~72k lines of structured truth).
gen-v2.py compiles that spec into V2Generated.ts: 22,000 lines of n8n property descriptors — every resource, operation, and field, with correct displayOptions wiring.
A 173-line dispatcher routes (resource, operation) pairs to generic HTTP execution. The actual .node.ts shell is 355 lines.

The generated file opens with the only comment that matters:

// AUTO-GENERATED by spec/gen-v2.py from spec/v2-endpoints.json.
// Do not edit by hand — regenerate with `python3 spec/gen-v2.py`.

When Holded changes their API, I re-scrape, re-generate, diff, release. Maintenance went from "career" to "afternoon".

What codegen can't do (and what I still wrote by hand)

Generation gets you coverage. It does not get you good UX. Three things stayed human:

The Contact resource is fully handwritten. It's the resource everyone touches first, and the generated version was technically correct but clumsy — search deserves first-class email / vatNumber / phone fields, not a generic filter collection. High-traffic paths earn hand-polish; the long tail stays generated.
Naming and grouping. A dropdown with 42 resources is only usable if names match what users see in Holded's UI, not what the API paths say.
n8n's lint rules. eslint-plugin-n8n-nodes-base has strong opinions (alphabetized options, description formats, casing). The generator had to learn them — fixing lint output in the generator instead of in the generated file is the whole trick of this approach.

Getting the "verified" badge

n8n's verification reviews your code before the node becomes installable on n8n Cloud (community nodes otherwise need self-hosting). What it costs you: strict linting, no runtime dependencies, real docs, and review iterations measured in days-to-weeks.

What you get: distribution. Verified nodes show up in the in-app node panel for every n8n Cloud user, plus a public integration page. For a niche B2B tool, that's the difference between "GitHub repo with 12 stars" and "discoverable by every n8n user who types your product's name".

Takeaways if you're building a big-API node

If the API has >50 operations, don't type them. Generate them. A one-day scraper plus a one-week generator beats months of typing and years of drift.
Spec first. The intermediate JSON is the asset — the TS is disposable output. I can regenerate for a future n8n API version, or even for a different platform, from the same spec.
Hand-write the top 10% by traffic. Generated long tail, polished hot paths.
Teach the generator the linter's opinions. Never fix generated files by hand, not even once.
Webhooks are half the value. The trigger node (18 objects / 58 events: invoice.create, stock.update, …) is what turns an ERP from "destination" into "event source".

Try it

n8n: Settings → Community Nodes → @francodesystems-npm/n8n-nodes-holded (or find "Holded" directly on n8n Cloud)
Repo: github.com/francodesystems/n8n-nodes-holded (MIT)
Docs, coverage matrix and use cases: francodesystems.com/open-source/n8n-nodes-holded
If you're migrating between Holded API v1 and v2, I wrote up the 8 traps that will actually bite you (Spanish).

Ready-to-import workflow templates (Shopify → invoices, Stripe → paid invoices, overdue-invoice chasing…) are landing on my n8n creator profile — I'll update this post with the links as they're approved.

Questions about the codegen pipeline or the verification process — ask away in the comments. 🇪🇸