The first time someone showed me Make.com, I dismissed it immediately.
"That's for techies," I thought. "Nobody in Finance or Legal is going to figure that out."
I was spectacularly wrong!
A few months later I had become completely obsessed with it. I was automating everything. I built workflows that sent me automatic alerts on Slack. I was connecting tools, moving data between systems, triggering notifications. It felt like a superpower.
And then someone sat down next to me and showed me that they could impersonate me on Slack!
Because I had used my personal credentials to authenticate one of my workflows, I had quietly introduced a risk that I hadn't even thought about. I was the shadow IT problem.
Me!
The Information Security Governance Manager!
That was quite a light-bulb moment that changed how I think about process automation entirely.
Here's what's happening in your organisation right now, whether you know about it or not.
Someone in the Legal team has a repetitive task that takes them an hour every week. They asked IT for a solution six months ago and nothing happened. So they Googled it, found N8N or Zapier, watched a fifteen minute tutorial, and built something themselves. It works perfectly. They're proud of it. They haven't told anyone.
Someone in Finance is automatically pulling data from three different systems into a spreadsheet using a Zapier workflow they set up on a Sunday afternoon. It's been running for eight months. It touches your CRM, your accounting software, and a shared drive full of sensitive documents.
Someone in HR has connected your HRIS system to a third party tool using an API key they generated themselves, because they needed a report that the vendor didn't provide out of the box.
None of these people are malicious. None of them are trying to bypass security. They had a problem, nobody solved it for them, so they solved it themselves.
But from a security perspective, each of those workflows is an undocumented connection between your systems and the outside world. Data is moving through integrations you didn't approve, authenticated with credentials you don't control, to destinations you haven't assessed.
And you have no idea it's happening.
This is the shadow IT problem that nobody is talking about.
We spent years worrying about employees using Dropbox to share files or installing unauthorised software on their laptops. Those risks still exist, but they're relatively visible. Your endpoint tools flag unauthorised software. Your DLP solution catches sensitive files going to consumer cloud storage.
Process automation is different. It's invisible by design. It looks like productivity. It lives in the cloud, it runs in the background, and it leaves almost no footprint in the places most security teams are looking.
The tools that make this possible, Make, Zapier, n8n, Pipedream, have been deliberately built so that non-technical users can create sophisticated integrations without writing a single line of code.
That's what makes them powerful.
It's also what makes them a governance nightmare.
Because you don't need to be a developer to connect your company's CRM to an external system. You just need fifteen minutes and a free account.
The risk isn't the automation itself. It's the invisibility.
When a well-meaning employee builds a workflow using their own credentials, those credentials don't get rotated when they leave the company. The workflow keeps running. The access remains. Nobody knows to revoke it because nobody knew it existed.
When sensitive data passes through a third party automation platform, it's subject to that platform's security controls and data residency policies, not yours. Did your Legal team's workflow just send contract data through servers in a jurisdiction your organisation hasn't approved? Possibly. Does anyone know? Almost certainly not.
When an automation breaks, which they do, the employee who built it is the only person who understands how to fix it. If they're on leave, or they've left the company, you have an undocumented production process with no owner and no documentation.
When an employee generates their own API key to authenticate a workflow, that key doesn't appear in any inventory. It isn't scoped to minimum permissions. It isn't stored in a secrets manager. It will keep working long after the person who created it has moved on.
So what should a security manager actually do about this?
The first thing is to resist the instinct to ban it. Blanket prohibition doesn't work and it never has. If the tools are useful enough that your own employees are building with them in their spare time, blocking them just drives the behaviour further underground and removes any chance of visibility.
The more useful question is: why are your people building these workflows themselves? What problem were they trying to solve that the organisation failed to solve for them?
The second thing is to get visibility. Your firewall and proxy logs will show outbound traffic to automation platforms. Your DNS logs will show queries to webhook and API domains. Your finance team's expense reports will show SaaS subscriptions that nobody in security approved. The evidence is already there. Most security teams just aren't looking for it.
The third thing is to create a path to legitimacy. If employees are going to build automations regardless, give them a way to do it that doesn't introduce unmanaged risk. An approved set of tools. A simple process for registering workflows. Guidance on credential management. A way to say "yes, with guardrails" rather than just "no."
Because the alternative is what's already happening. Dozens of undocumented workflows running in the background of your organisation, built by well-meaning people who just wanted to solve a problem, authenticated with credentials nobody is managing, moving data through systems nobody has assessed.
I know, because I was one of them.
To make this practical, here's a controls cheat sheet you can use as a starting point for governing process automation in your organisation.
Process Automation Governance: Controls Cheat Sheet
A practical reference for governing process automation tools in an organisation.
Policy and governance
Acceptable use policy — define which automation tools are approved, what data can flow through them, and what requires security sign-off before use.
Workflow registration process — employees must register new workflows before they go live, not after. Make the process simple or nobody will use it.
Approved tools list — maintain a short list of pre-assessed platforms. Anything not on the list requires a formal request.
Workflow ownership — every registered workflow must have a named owner who is responsible for it and reviews it periodically.
Identity and access
No personal credentials — workflows must never authenticate using an employee's personal login. If that person leaves, access remains until someone thinks to revoke it.
Service accounts only — dedicated service accounts scoped to the minimum permissions the workflow actually needs.
Offboarding checks — include automation workflow access in the employee offboarding checklist. Deactivate service accounts tied to departing employees.
Regular access reviews — review workflow authentication on a defined cycle, at least annually.
API key management
Never hardcode keys — API keys must not be embedded directly in a workflow or stored in plain text in a shared document, spreadsheet, or chat message.
Store in a secrets manager — all API keys used in workflows must be stored in an approved secrets manager or password vault.
Minimum scope — keys should be scoped to the minimum permissions required. A key that can read data should not also be able to write or delete it.
Rotation and revocation — rotate keys on a regular cycle and revoke immediately when an employee leaves or a workflow is decommissioned.
Key inventory — maintain a log of all API keys in use, which workflow they belong to, and who is responsible for them.
Data governance
Data classification first — employees must understand what classification the data carries before connecting it to an automation platform.
Restricted data requires approval — confidential, sensitive, or regulated data flowing through a third party platform needs explicit security sign-off.
Data residency — confirm where the automation platform stores and processes data. Ensure it meets your jurisdictional and regulatory requirements.
Retention and deletion — understand whether the platform retains a copy of data that passes through it, and for how long.
Vendor assessment
Assess before approving — automation platforms should go through your standard third party risk assessment before being added to the approved tools list.
Data processing agreements — ensure a DPA is in place with any platform that processes personal data on your behalf.
Check their certifications — look for ISO 27001 certification or SOC 2 reports. And verify them. Don't just take their word for it.
Periodic re-assessment — vendor risk doesn't stand still. Review approved platforms on a defined cycle.
Visibility and detection
Firewall and proxy log reviews — search for outbound traffic to known automation platforms. High frequency traffic to webhook domains is a reliable indicator of a live workflow.
DNS log hunting — filter for queries containing keywords like webhook, api, or connect.
Expense audits — search company expense claims for SaaS subscriptions under $50. If Finance is paying for it, Security should know about it.
Self-reporting mechanism — give employees a simple, blame-free way to declare existing workflows. Amnesty gets you further than enforcement.
Security awareness
Communicate what's allowed — employees should know which tools are approved and which require a conversation with security before use.
Make the path easy — if the approval process is complicated, people will skip it. A simple form or a Slack message to the security team is enough to start.
No blame culture — employees who built workflows before a policy existed should be able to come forward without fear of consequences. You want disclosure, not concealment.
Include in onboarding — new employees should be told about the automation policy from day one, before they start building things.
Closing
I eventually rebuilt my Slack workflow properly. Service account. Correct permissions. Documented. Approved.
It took about an hour. The risk it removed had been sitting there for months.
That's usually how it goes. The fix is rarely the hard part. Finding it is.