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

Saudações, caros colegas e webmasters da nossa pérola do Índico!

Como especialista em tecnologia, li com muita atenção o tópico sobre **"Os controlos da ISO 27001 que realmente importam quando conectamos dois sistemas"**. Este é um tema de extrema relevância para a nossa comunidade no **webmastersmz.com**, especialmente agora que o ecossistema digital em Moçambique está a crescer rapidamente, com integrações constantes entre plataformas de e-commerce, gateways de pagamento locais (como M-Pesa, e-Mola, mKesh), bancos e sistemas de faturação.

Quando ligamos o nosso sistema ao de um parceiro ou cliente via API ou VPN, estamos a abrir uma porta. Se não aplicarmos os controlos certos da norma **ISO/IEC 27001:2022**, essa porta pode tornar-se uma vulnerabilidade crítica.

Abaixo, apresento a minha análise técnica sobre os controlos que realmente fazem a diferença nessa integração:

---

### 1. Controlo de Acesso e Identidade (A.5.15, A.5.16 e A.5.18)
Não basta apenas "conectar". É crucial definir **quem** e **o que** está a aceder ao sistema.
*   **Na prática:** Devemos aplicar o princípio do menor privilégio. O sistema integrado deve ter acesso apenas aos dados estritamente necessários para a operação. O uso de protocolos modernos de autenticação e autorização (como OAuth 2.0 e chaves de API rotativas) é obrigatório. Nada de credenciais "hardcoded" no código fonte!

### 2. Criptografia e Proteção de Dados em Trânsito (A.8.24)
A segurança física dos cabos que cruzam o nosso país não está sob o nosso controlo, por isso a segurança lógica é vital.
*   **Na prática:** Toda e qualquer comunicação entre os dois sistemas deve ser feita utilizando protocolos de transporte seguros (como TLS 1.3). Além disso, dados sensíveis (como credenciais ou dados pessoais dos nossos utilizadores) devem ser cifrados antes mesmo do envio, garantindo a confidencialidade caso haja um ataque do tipo *Man-in-the-Middle*.

### 3. Gestão de Relações com Fornecedores e Terceiros (A.5.19 a A.5.23)
Este é um ponto frequentemente negligenciado em Moçambique. Quando nos conectamos a um parceiro, o nível de segurança dele passa a ser o nosso nível de segurança.
*   **Na prática:** É necessário que existam acordos claros (SLAs e NDAs) que definam as responsabilidades de segurança de cada lado. Se o sistema do parceiro for invadido, como seremos notificados? Quais são os limites de responsabilidade? A ISO 27001 exige este alinhamento contratual.

### 4. Monitoria, Registo e Logs (A.8.16)
Se algo falhar ou se ocorrer um acesso indevido, precisamos de saber exatamente o que aconteceu.
*   **Na prática:** Ambos os sistemas devem registar logs detalhados das transações e comunicações (quem acedeu, quando, e o que foi solicitado). Estes logs devem ser guardados num local seguro e monitorizados para detetar anomalias. Sem logs, estamos "cegos" perante um incidente de segurança.

---

### Vamos debater no Fórum webmastersmz.com?

Gostaria de convidar todos os membros do fórum a partilharem as suas experiências:
1. **Como têm lidado com a segurança ao integrar os vossos websites com gateways de pagamento em Moçambique?**
2. **Já tiveram problemas de segurança causados por falhas em sistemas de terceiros que estavam ligados ao vosso?**
3. **Acham que as nossas empresas locais estão preparadas para exigir e cumprir estes controlos da ISO 27001?**

Deixem as vossas opiniões e dúvidas no tópico do fórum. Vamos enriquecer o debate e elevar o nível da segurança da informação no nosso país!

---

Para garantir que os vossos projetos e fóruns rodam sem falhas, convido-vos a conhecer as soluções de alojamento de alta performance da AplicHost em https://aplichost.com. Com servidores robustos e segurança de ponta, é o parceiro ideal para garantir que as vossas integrações funcionem com o máximo de uptime e proteção.

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



Tópico: The ISO 27001 controls that actually matter when you connect two systems
Categoria: Tutoriais | Programação & Tecnologia
Idioma Principal: Português (Conteúdo de Tecnologia)

Descrição do Conteúdo / Informações:
-------------------------------------------------------------------------
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.