What Your IT Team Actually Has to Provide for an Automation Program

The short answer: your IT team has to provide four things a vendor cannot create for itself — non-production environments that look like production, service identities with scoped permissions in each system the automation touches, a data access path that legal and security have already blessed, and a named person who can make decisions about all three. Everything else — build, testing, monitoring, documentation, runbooks — can sit with the vendor if you want it to. Those four cannot, because they all require someone inside your tenant with the authority to grant something.

The time cost is lumpier than people expect. The initial setup is usually a handful of working sessions: an architecture conversation, an identity and access session, a security questionnaire, and an environment walkthrough. After that, IT's involvement drops to something close to background noise — approving changes, rotating credentials, and getting looped in when an upstream system changes. The programs that stall are almost never stalled on engineering. They stall because nobody inside IT was given the authority to say yes to a service account, or because the security review started after the build instead of before it.

Environments: the single most common blocker

Automation touches systems in sequence, and you cannot responsibly test that sequence against live data. So the first ask is a non-production environment for every system in the chain — ERP, ticketing, document store, CRM, whatever the workflow crosses.

The honest problem is that most organizations have a sandbox for one or two systems and nothing for the rest. A full ERP sandbox exists; the vendor portal that feeds it does not. This is where programs quietly lose weeks, because the gap is discovered during build rather than during scoping.

What actually works:

• Inventory the environments before the statement of work is signed, not after. For each system in scope: is there a non-prod instance, is its data representative, and who refreshes it?
• Accept read-only production access as a fallback for systems with no sandbox, paired with a hard rule that writes only ever go to non-prod until go-live. This is a legitimate pattern and security teams generally accept it when the boundary is explicit.
• Decide who owns sandbox refreshes. A stale sandbox produces automation that works beautifully against data shapes that no longer exist.
• Get one environment that approximates production load if the process is high volume. Logic that works on ten records and logic that works on tens of thousands are not the same logic.

If you cannot produce a usable test environment for a system and cannot get read access either, that system is not ready to be automated. Say so early and scope around it rather than building on hope.

Identity and access: service accounts, not borrowed logins

Every automation needs to authenticate as something. The wrong answer — and it is extremely common — is running the automation under a named employee's credentials. It breaks when they leave, it makes the audit trail meaningless, and it puts a human's MFA in the middle of an unattended process.

What IT needs to provide:

• A dedicated service identity per system, with permissions scoped to exactly the operations the workflow performs. Not an admin role "to get moving" that nobody ever narrows afterward.
• An authentication method that works unattended — OAuth client credentials, certificate-based auth, a managed identity. If a system only supports interactive MFA, flag it early; there are workarounds, but they need designing, not improvising.
• A credential store and a rotation policy. Decide where secrets live, who can read them, and what happens on rotation day. An automation that dies silently every ninety days is a support ticket generator.
• Network path decisions. Allowlisted IPs, VPN, private endpoints, or a broker inside your perimeter. This is usually the longest-lead item because it crosses teams.
• A decision on where the automation runs — your cloud tenant, your on-prem infrastructure, or the vendor's environment. That single choice determines most of what the security review will ask about.

Scoping permissions properly is more work upfront than granting broad access, and it is worth every hour. It is also the part security review will examine hardest, so doing it correctly the first time removes a later round trip. Our own posture and the controls we work within are documented on our security page, which is usually the first thing we hand a security team.

Data: shape, quality and the legal path

Automation is only as good as the data it reads. IT's job here is not to clean the data — that is usually the business owner's problem — but to provide honest access to it and an honest description of it.

• Representative samples, including the ugly cases. Clean examples produce automation that only handles clean examples. We want the malformed invoices, the records with three addresses, the tickets where someone pasted an email thread into a single field.
• Volume and shape data: how many records per day, what the peaks look like, how many variants of each document type exist in practice.
• A classification decision. Does the workflow touch PII, PHI, payment data, or regulated records? This determines processing location, retention, redaction and logging rules — and it needs answering before design, not after.
• The legal path for data leaving your tenant, if any leaves at all. A DPA, a vendor risk assessment, sometimes a privacy impact assessment. These run on legal's calendar, not engineering's, so start them in parallel with scoping.

For document-heavy workflows this matters more than anything else. The realistic accuracy ceiling on document and data extraction is set almost entirely by how varied and how legible the source material is, and you cannot know that from a description — only from a sample set.

Security review: run it in parallel, not at the end

The pattern that wastes the most time is sequential: scope, build, then submit for security review and discover the architecture is unacceptable. Security review should start the week the design does.

Expect to run some combination of: a vendor risk questionnaire, an architecture and data-flow review, a review of authentication and secrets handling, logging and audit requirements, and — depending on your industry and the system's criticality — a penetration test or code review.

What IT can do to compress it:

• Name the security reviewer at kickoff and put them in the design session. An architecture designed with the reviewer in the room almost never fails review.
• Send the questionnaire before the build starts. Vendors with real programs answer these routinely.
• State your non-negotiables upfront: data residency, no data leaving the tenant, specific logging retention, approved model providers. These are cheap to design around and expensive to retrofit.
• Agree what triggers a re-review. A new system in scope probably does. A prompt change or a new exception rule probably does not. Write it down or every change becomes a negotiation.

Change management: the part that decides whether it survives

An automation is not a project that ends. It is a piece of production software sitting on top of systems that change without asking it. IT owns the interface between the two.

• Put automations in your CMDB or service catalog with a named owner and an escalation path. If it is invisible to your operations team, it will be broken by the first upgrade.
• Add automation dependencies to upstream change review. The most common cause of breakage is a routine change to a source system that nobody realized had a consumer.
• Decide where alerts land — your monitoring stack, the vendor's, or both — and who is on the hook at 2am, if anyone. Many back-office automations can safely wait until morning. Decide that deliberately.
• Agree on a deployment path. Whose pipeline, whose approval gates, what rollback looks like.
• Define the human fallback. If the automation is down for a day, what do people do? Every automation needs an answer, and "the team just does it manually" is a perfectly good one if the team still remembers how.

What stays with IT versus what the vendor should carry

Area	IT provides	Vendor carries
Environments	Sandbox instances, refresh cadence, network access	Deployment, configuration, environment parity checks
Identity	Service accounts, permission grants, credential store	Secure credential handling, rotation-safe implementation
Data	Samples, classification, legal approvals	Handling, retention compliance, extraction logic
Security	Requirements, reviewer time, sign-off	Questionnaires, architecture docs, evidence, remediation
Operations	Catalog entry, change review inclusion, escalation path	Monitoring, alerting, fixes, runbooks

The line we hold: IT grants and decides; the vendor builds and runs. If a vendor is asking your team to write integration code, debug their exceptions, or maintain their infrastructure, the operating model is wrong. We describe how we split this in practice in how we work.

When the answer is "don't automate this yet"

Some processes are not ready, and starting anyway costs more than waiting. Push back when:

• The process is actively being redesigned. Automating a workflow that changes in two quarters means building it twice. Wait for the redesign, then automate the result.
• The source system is being replaced. Integrations built against a system on its way out are throwaway work. Sequence the automation after the migration.
• Nobody can describe the current process end to end. If three people give three different accounts of how exceptions are handled, the process needs documenting before it needs automating.
• The only access path is screen scraping a UI with no stable identifiers and no API roadmap. It can be done, and it breaks constantly. Worth it for genuinely high-volume work; rarely worth it otherwise.
• The data quality is poor and unowned. Automation applied to bad data produces bad outcomes faster. Fix the source or accept a heavy exception path.
• IT has no capacity for the setup sessions in the next quarter. Starting a build you cannot support is a good way to end up with an unowned system. Better to wait and do it properly.

None of these are permanent no's. They are sequencing problems. The failure mode is treating them as details to sort out during delivery, when they are actually the determinants of whether delivery works at all. If you are weighing which process to start with, our value calculator is a reasonable way to compare candidates on effort and return before committing IT time, and our process automation practice page covers the shape of the work itself.

Getting through procurement without losing a quarter

Procurement delay is nearly always parallelizable work being run in series. Start the vendor risk assessment, the DPA, and the security questionnaire the same week scoping starts — none of them depend on the design being final. Confirm who signs off on a new service account and who signs off on data leaving the tenant; these are often different people, and neither is usually the project sponsor. Scope the first phase narrowly enough that it clears review as a single bounded system rather than a platform commitment, and keep the environment inventory in front of the group as a live checklist with named owners and dates. Every item on it is a hard dependency, and the ones without a name next to them are the ones that will slip.

If you want a concrete list for your own environment rather than a general one, we will walk your specific systems, access model and review process and tell you what we would need, what we would not ask for, and where we think you should wait. Talk to us and we will scope it with your IT team in the room from the start.

Questions we get asked about this