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.
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.
"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.
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.