Govern employee-built automations without slowing teams

Signs this is happening in your business

What this is costing you a year

How to govern employee-built automations this quarter

Treat every employee-built automation as a tiny production service: register it, run a short risk checklist, move credentials into the company secrets store, assign a named owner with a one-page runbook, add basic monitoring, and schedule a 90-day pilot review. Apply only the controls needed to prevent data leaks and single-person failure.

I prefer a short, enforced path over a long policy document. You should be able to register and classify every visible automation in a week and complete initial reviews in a month.

• Register everything: spreadsheets, macros, connector flows, agent sequences, chat prompts.
• Classify risk by data involved and business impact, not by the tool used.
• Apply practical controls for credentials and external services, rotate keys and ban shared logins.
• Assign ownership, require a two-step handover, and schedule a 90-day pilot review.

How to discover and register existing automations

Start with a rapid survey that produces a single register: name, builder, users, credentials location, data touched, and pilot status. Run interviews with team leads, host one-hour inventory drop-ins, and ask IT for shared accounts and service keys. Consolidate duplicates into the register before you start security work.

• Registration form fields: name, purpose, owner, tool, trigger, outputs, users impacted, data sensitivity (low/medium/high), credentials location, runbook link, pilot end date.
• Who fills it: the automation owner (the builder), countersigned by their manager.
• Deadline: existing automations registered within one month; new ones require registration before production use.

A simple risk-classification and approval matrix

Classify automations on two axes: data sensitivity (low/medium/high) and business impact (convenience/operational/critical). Use a 3×3 mental map and map cells to approval levels: self-approve, operations review, or security plus IT sign-off. Decide on approvals by the data touched and what stops if the flow fails.

• Data sensitivity: Low (internal notes), Medium (customer contact details), High (payment or regulated data).
• Business impact: Convenience (saves minutes), Operational (affects workflows), Critical (billing, SLAs).
• Approval mapping: Low+Convenience = self-approve; Medium+Operational = ops review; High+Critical = security and IT approval before production.

Shadow automations are unpaid headcount that drains margin.

Practical controls for credentials and data handling

Put service credentials and integration keys in the company secrets store; forbid personal long-lived keys and shared logins. Rotate keys on role change or annually and use single sign-on where available. Ban sending raw customer or regulated data to public models; require redaction templates or company-hosted models and log every external transfer.

• Secrets rule: no long-lived personal keys in automations. Use centrally issued keys and rotate annually or on role change.
• Shared accounts rule: forbid shared team logins. Use delegated access or service accounts with an owner and audit trail.
• External models: forbid sending raw customer data to public models; use company-hosted models or sanitized inputs.
• Storage: any file export with customer data must go to company storage with access controls; never to personal drives.

Requirements to avoid single-person failure

Every automation must have a named owner, a backup, a one-page runbook, versioned documentation, and a handover before role changes. If only one person knows how to run or fix the flow, require a two-week shadow period where a peer can run it manually; suspend the automation if handover does not happen.

• Owner record: name, backup owner, and manager sign-off.
• Runbook minimum: purpose, trigger, acceptance test, common failures and fixes, where credentials live, retirement checklist.
• Handover rule: departing or moving employees must complete handover within 10 working days or the automation is suspended.
• Version docs: store runbooks in the company docs system with version history and a 'last tested' date.

Monitoring, auditability and incident response for automations

Add simple monitoring: daily usage counts, failure alerts, and a business-owner contact that receives pages when a key automation fails. Retain trigger and outcome logs for at least three months unless regulation requires longer. Tie failures into incident response so tickets, pages and post-incident notes feed back into the runbook.

• Monitoring: daily usage metric, weekly error rate, and a pager for critical failures.
• Logs: retain trigger and outcome logs for at least three months; redact sensitive fields where required.
• Incident flow: automation failure → ticket created → owner paged → owner triages within agreed SLA → post-mortem appended to runbook.

Banning citizen automations kills the team-level fixes that stop recurring work.

A light operating model: roles, cadences and templates

Run governance with three lightweight roles: automation owner (builds and operates), automation steward (ops/security contact), and governance coordinator (keeps the register and runs reviews). Meet monthly for new registrations and quarterly for risky automations. Use one-page templates for registration, risk checklist, and acceptance tests so compliance is fast.

• Roles: Owner (team), Steward (ops/security), Coordinator (rotating ops person).
• Cadence: weekly discovery/triage emails for new items, monthly governance meeting, 90-day pilot reviews.
• Templates to use: registration form, risk checklist, acceptance test, retirement form.
• If you need help running this as a short engagement, see Services and examples in Portfolio and case studies.

Where time and money go

Most wasted hours come from three places: re-keying data between systems, manual reconciliation work, and ad-hoc exports to vendors. Measure hours spent on each task in the register, then target the highest-cost items first. That gives you the quickest return on governance effort.

• Re-keying customer data drains hours and creates errors.
• Manual reconciliation consumes multiple people tracking mismatches.
• Ad-hoc exports create audit work and risk.

Why this fails in practice and how to stop it

Governance fails when it is designed to stop work rather than to make work safe. Long approval pipelines push teams to automate in shadow, which triggers a crisis freeze later. Make registration the unblocker: registered automations run; unregistered ones are suspended after two warnings to flip incentives toward compliance.

• Failure sequence: long policy → low compliance → shadow automations → crisis freeze.
• Fix: short mandatory registration, quick risk triage within 48 hours, and clear consequence: unregistered automation suspended after two warnings.
• Make the governance coordinator the person teams go to for help; do not make security the first touchpoint.

Ownership without documentation converts efficiency into outage risk.

How to run a 90-day pilot review and retire orphaned automations

Every new automation enters a 90-day pilot: the owner sets a measurable acceptance test and a stakeholder signs the test. At 90 days the governance coordinator checks usage against the test and either promotes to steady-state, requires changes, or retires the automation by disabling triggers, revoking keys, and archiving documentation.

• Pilot requirements: registration, acceptance test with a measurable metric, owner, and a 90-day review date.
• Promotion criteria: acceptance test met and no unresolved security issues.
• Retirement steps: disable trigger, revoke keys, archive runbook, update register with retirement reason.

Templates and checklists you can copy tomorrow

Use three one-page templates: registration form, risk checklist, and acceptance test. They must be short enough to fill in under five minutes and mandatory before production use. Below are the minimum fields I require to stop shadow automations and give you the detail needed to secure and manage flows.

• Registration form: name, owner, backup owner, purpose, trigger, outputs, data sensitivity, credentials location, pilot end date, linked runbook.
• Risk checklist: data sensitivity level, business impact level, external transfers, presence of company secrets, need for security review.
• Acceptance test: what success looks like, how to run the test, expected frequency, rollback step.

Next step: map your automations this week

Run a single-week plan: announce the inventory, hold drop-ins, collect registrations, and classify the top five highest-risk automations. By the end of the week you will have rotated keys, named owners, and triaged unresolved incidents — concrete wins that build momentum for governance.

• Week plan: Day 1—announce inventory and send registration form link; Days 2–4—drop-in sessions and manager follow-ups; Day 5—consolidate register and classify five riskiest items.

Where businesses waste the most time

1. Re-keying customer dataWastes hours each week and causes transcription errorsCreate a direct connection between the two systems so fields copy automatically without replacing existing softwareA person still checks: A person spot-checks a sample of records weekly
2. Manual reconciliationMultiple people spend time matching rows and tracking down mismatchesAutomate the match and present only exceptions for human review while keeping current toolsA person still checks: Someone investigates the flagged exceptions
3. Ad-hoc exports to external servicesUncontrolled transfers create audit and compliance riskRequire registration and a short approval for any export; store exports in company-controlled folders without replacing softwareA person still checks: An owner approves each scheduled export and checks logs monthly

How this compares with what you already run

Operational area	The manual way	The automated way	Annual business impact
Customer onboarding	Staff copy/paste between systems	Trigger populates fields automatically	Fewer onboarding hours and faster revenue
Invoice reconciliation	Two people check spreadsheets weekly	Match and flag mismatches automatically	Lower processing cost and fewer billing errors
Support routing	Agents assign cases manually	Rules route and prioritize tickets	Reduced resolution time and less overtime pay
Report generation	One person exports and emails reports	Scheduled generation and distribution	Staff time reclaimed for higher-value work
Data exports to vendors	Manual uploads and emails	Controlled export with logging and approval	Reduced data leakage risk and audit exposure

What the end-to-end workflow looks like

The metrics that tell you it worked

Metric	What it tells you
Number of registered automations	Counts automations in the register; a rising number with no owners is a red flag
Automations with named backup owner	Share of automations with both an owner and a backup; measures single-person failure risk
Daily error rate across automations	Failed runs per day; a leading indicator of reliability issues
90-day pilot success rate	Share of pilots that meet their acceptance test and are promoted; measures build quality
Number of credential rotations completed	How often service keys are rotated per policy; measures secrets hygiene
Unregistered automation suspensions	Count of automations suspended for failing to register; shows governance enforcement
Incidents with no documented runbook	Incidents where the owner had no runbook; highlights documentation gaps

When this is the wrong move

The mistakes that cost the most

• Overcentralising controlSecurity creates a long approval pipeline; teams bypass it and automation goes underground, leaving security blind and velocity harmed.
• No discovery effortAssume there are few automations; months later find dozens of unowned flows, leading to emergency revocations and angry stakeholders.
• Shared secrets and shared loginsTeams use the same team login or put keys in spreadsheets; a single departure or leaked file exposes multiple automations and customer data.
• No lifecycle rulesPilots never close; old connectors and unused keys accumulate, increasing audit risk and maintenance burden.

Frequently asked questions