Engineering teams want control. The rest of the business wants a tool today, not in the Q3 roadmap. Both positions are reasonable, and both are now under more pressure than before.

Finance can build a reconciliation dashboard in an afternoon with an AI coding assistant. Marketing can wire together a lead router in Zapier. Operations can publish an internal portal from a low-code platform without raising a ticket. The skills barrier that used to protect Engineering’s gatekeeping role has gone, and saying no no longer stops anything. It moves the work somewhere you cannot see it.

That does not mean Engineering has no role. It means the role changes. Engineering should set the rules and build the road, not sit at the junction approving every vehicle.

Why both sides are right

Engineering’s worry is legitimate. Someone will be paged when a tool nobody told them about breaks. Someone will answer the auditor when customer data turns up in a spreadsheet with a public share link. Someone will find out during due diligence that the pricing calculator the sales team relies on lives on one person’s laptop.

The worry is right. The usual remedy, a queue where Engineering approves each request, is not. It cannot keep up with the number of people who can now build, so it either stalls the business or gets bypassed.

The business’s frustration is legitimate too. A request that waits six months for an engineering slot is slower than the problem it was meant to solve. People who see a faster route will take it.

The usual outcome of an unresolved argument is shadow IT. Engineering says no, the business builds it anyway, and Engineering finds out when it fails. I have seen this in scale-ups and in PE-backed groups. The fix is not a stricter ban. It is a clear set of rules that says what anyone can build, what they must build on, and what Engineering has to look at first.

Seven steps to success

1. Set a baseline everyone builds from

Give every builder, technical or not, the same starting point. Without one, each tool looks and behaves differently, and Engineering ends up maintaining a dozen interpretations of “a form with a table”.

  • A brand and style guide, with real colours, fonts and tone, not a PDF nobody can find.
  • UI and UX standards: a design system or component library, form patterns, error messages, accessibility minimums.
  • Starter templates and repositories that already include logging, authentication and the standard footer.
  • A short written definition of what “done” means for an internal tool, covering documentation, an owner and a support route.

A baseline also saves time. Builders stop reinventing the login page, and Engineering stops reviewing it.

2. Set the security parameters before anyone builds

Decide the non-negotiables up front and publish them. People follow a rule they can read before they start far more often than one they discover after they ship. Examples:

  • Tools are reachable only over the corporate VPN or a zero-trust access proxy, never on a public URL.
  • Every tool signs users in through single sign-on with Google Workspace, Microsoft 365 or an equivalent identity provider, with MFA enforced. No local usernames and passwords.
  • Access follows least privilege, and leavers lose access through the identity provider without anyone raising a ticket.
  • Secrets and API keys live in a secrets manager, never in code, prompts or spreadsheets.
  • Data classification decides what a tool may touch. Customer personal data and financial data stay out of any tool that has not been reviewed.
  • An approved list of AI tools and models, with a rule on what company data may be pasted into them.

Engineering writes these rules once, with input from the business, and then enforces them in the platform instead of by reviewing each tool. The identity provider enforces SSO and MFA, the network layer enforces VPN-only access, and a scanner catches secrets in code. A rule that blocks the legitimate use case gets worked around, so ask the builders what they need before you publish it.

3. Register every tool and service in your ISMS or software portfolio

If it is not on the list, it does not exist as far as risk, support and audit are concerned. Add every tool and service to your Information Security Management System (ISMS) asset register or your software and product portfolio. For each entry record:

  • Who owns it and who the backup owner is.
  • What it does and which business process depends on it.
  • What data it holds or touches, and its classification.
  • How users sign in and who has access.
  • Where it runs and what it connects to.
  • The date of the next review, and what happens when the owner leaves.

If you work towards ISO 27001 or SOC 2, this register is also evidence an auditor will ask for. It is the same list a buyer will ask for in technical due diligence.

4. Sort tools into risk tiers

Not every tool needs the same scrutiny. A three-tier model keeps Engineering’s time for the cases that matter:

  • Tier 1, personal or team productivity. No customer data, no integrations into core systems. The builder follows the baseline and registers the tool. Engineering does not review it.
  • Tier 2, business process tools. Internal data, connections to other systems, or many users. The builder completes a self-service checklist and goes ahead. Engineering looks only when an answer flags a risk, and replies within an agreed time, such as two working days.
  • Tier 3, customer-facing or system-of-record. Customer data, money movement, or something the business cannot run without. Engineering gets involved here because the cost of failure is high, and it works with the builder through the normal delivery process.

The tier boundaries answer most of the control argument. Engineering steps in where the risk is high and stays out of the way where it is low. Most tools land in Tier 1 or 2, so most tools ship without waiting for anyone.

5. Build a paved road

Rules alone do not help someone with a deadline. Give people an approved, easy place to build: a sanctioned low-code platform, a sandbox environment, a hosting option that already has SSO, logging and backups configured. When the compliant route is also the fastest route, most of the shadow IT disappears without a fight.

6. Make Engineering a platform team, not a gatekeeper

This is the cultural step, and the one most often skipped. Engineering does not approve every request. It provides the platform, the templates, the checklist and the training, and it answers questions quickly. The test is whether a business user can ship a compliant tool without opening a ticket. Measure Engineering on how quickly the business can ship, and on how many tools run on the paved road, not on how many requests it blocked. An engineering team that is asked for permission on every tool has built a gate, whatever it calls it. Some teams run a regular drop-in session where builders bring work in progress. It costs an hour a week and finds problems while they are cheap to fix.

7. Review, hand over and retire

Tools outlive the people who build them. Put a review date on every register entry and check it. When the owner changes teams or leaves, reassign the tool or retire it. Tools that start in Tier 1 and grow into Tier 2 or 3 should move up a tier, with the review that comes with it. Shutting down an unused tool removes an attack surface and a maintenance cost.

What the business gets and what Engineering keeps

The business gets speed: a clear route for building its own tools, with answers in days, not quarters. Engineering keeps what it needs: authentication, data handling, visibility and a say in anything that becomes critical. It does not keep a veto over everything else. Neither side gets everything it wanted, which is usually a sign that the compromise is set about right.

Where to start

Do not wait for a perfect policy. In the next month:

  1. Run a discovery exercise. Ask every team what they have built or bought, and check your identity provider and expense reports for tools nobody mentioned.
  2. Publish the security parameters in one page.
  3. Create the register and populate it with what you found.
  4. Name an owner in Engineering for the paved road.

If you want help setting this up, or you are preparing for a raise, sale or audit and want to know what the portfolio looks like from the outside, get in touch.