If you work in state, local government, or higher education (SLED) technology, you’ve heard it a hundred times: “We can’t use offshore resources.“
But the question nobody seems to ask is “Why not?”
We are finding that in most cases (not all!), the person saying “no” can’t actually answer that question. It’s become the easy button… the safe answer that avoids conversation and shuts down options. And while everyone’s hitting that button, it’s clear that critical systems stay unmodernized, security vulnerabilities persist, and budgets that could fund transformation get spent maintaining the status quo.
Related Read: SLED Cybersecurity at an Inflection Point: Insights from the IDC MarketScape
It’s time for a more informed conversation: Let’s Start with What You Actually Can’t Do
There ARE legitimate restrictions on offshore resources in certain contexts:
- ITAR (International Traffic in Arms Regulations): If you’re building weapons systems or handling defense articles, offshore resources are genuinely restricted. But let’s be honest…most SLED organizations aren’t building arms.
- Specific FedRAMP requirements: Certain federal compliance scenarios have workforce restrictions. If you’re working on classified systems or specific federal contracts with these requirements, those restrictions are real.
- Direct access to certain data classifications: If offshore teams need hands-on access to CJIS data, specific PII classifications, or other restricted information, that’s a valid constraint.
But here’s what’s critical… these restrictions apply to specific work streams, not entire projects. And they’re far more limited than most people realize.
One More Consideration: The Collaboration Tradeoff
Yes, you may definitely lose some spontaneous whiteboard sessions and hallway conversations with offshore teams. That’s real. But for technical execution work, modern asynchronous collaboration tools have largely closed that gap. The question is whether that tradeoff justifies ruling out entire delivery models…especially when most transformation work involves far more heads-down development than collaborative ideation.
The Confusion That’s Costing You
Most “offshore prohibitions” in SLED stem from confusing two completely different things: Data residency requirements ≠ Workforce location requirements
Your data might need to stay in specific geographic locations or cloud regions. Of course that’s a real requirement. But that doesn’t mean the people building your systems or writing your code need to be in those locations.
Also, something I hesitate to share publicly is that it’s VERY likely that your agency or institution is already using offshore resources, and you just don’t realize it.
- That Dell storage array housing your CJIS data? Dell’s engineers who maintain that hardware aren’t US-based or CJIS-badged. Yet, they work on the hardware, not the data.
- Your major SaaS platforms? Absolutely have offshore development teams.
- AWS, Azure, Google Cloud? They are all global engineering organizations.
- That “American technology company” you’re proud to partner with? I’d recommend you check their org chart.
The difference isn’t whether offshore resources are involved…it’s how the work is structured and where the data lives. These vendors [are supposed to] maintain compliance through rigorous certification processes, segregated environments, workforce screening, and jurisdictional controls – proving that global teams and government compliance frameworks aren’t mutually exclusive when properly structured.
A Better Analogy Than “We Can’t”
Think about building a research facility for a major university:
You might hire architects and engineers from around the world to design the blueprints, plan the infrastructure, and engineer the systems. But you keep the actual sensitive experiments and hazardous materials locked in a central vault that only vetted local personnel can access.
The same principle applies to technology projects:
- Offshore teams: Architecture, development, testing, documentation, non-sensitive technical work
- Onshore teams: Strategic oversight, stakeholder management, sensitive data access, constituent-facing work
- The data: Stays exactly where your compliance requirements say it must stay
The Real Question Your Procurement Team Isn’t Asking
When someone in purchasing says “we just don’t do offshore,” here’s what’s usually happening:
- They don’t actually know if there’s a real restriction
- They haven’t checked with legal about your specific project
- They’re repeating institutional lore, not policy
- Honestly, it’s the easy button…saying “yes” requires doing homework
So what if you challenge them with specific questions:
- “Which statute or regulation prohibits offshore resources for THIS project?”
- “Is it the data or the workforce that must be domestic?”
- “Have we distinguished between building the system and accessing the data?”
- “What specific compliance framework applies, and what does it actually say about workforce location?”
I’ve noticed most can’t answer these questions because they haven’t truly investigated.
What’s Actually Happening in the Market
While your procurement team or others are saying “we can’t,” here’s the reality:
Your peer institutions are doing it:
- Major state agencies are using hybrid delivery models
- Research universities leverage offshore resources for non-sensitive development
- Local governments work with providers using follow-the-sun delivery
- Federal agencies use offshore resources for unclassified work regularly
My former employer, AWS, is now requiring it for economic viability:
- Recent ACDC (Accelerate to Cloud from Data Centers) deals are structured with offshore resources as a requirement to hit competitive pricing
- AWS isn’t suggesting this approach…they’re building deals around it
- For nonprofit branches and cost-sensitive projects, offshore resources are becoming the path to affordability
The Strategic Benefits Beyond Cost
Even though competitive pricing often drives the initial conversation, the strategic advantages of well-structured offshore models go beyond budget:
- Follow-the-sun development cycles: For those that have been part of a project like this, it is a true game-changer… You submit requirements at end of day, development happens overnight, and you review deliverables in the morning. This compresses timelines without adding onshore overtime costs.
- Access to specialized talent: The domestic market for niche skills (legacy system migration, specific cloud certifications, emerging AI frameworks) is constrained. A global talent pool gives you access to expertise that simply doesn’t exist at scale domestically.
- Faster turnaround on time-sensitive work: What if you desperately need to scale a team for a federal funding deadline? Well, offshore models let you add specialized resources in weeks, not months.
Your Budgets are Getting Tighter… So Structure This Right
When done properly, offshore resource models for SLED look like this:
Clear separation of concerns:
- Onshore solution architects and project leads maintain strategic oversight
- Offshore teams handle technical execution on non-sensitive components
- Data stays in compliant locations with appropriate access controls
- Security and audit frameworks meet or exceed your requirements
Specific examples of appropriate use:
- Building new constituent-facing applications and user experiences
- Cloud migration planning and execution (infrastructure work)
- Application modernization (refactoring legacy systems)
- Testing and quality assurance (QA) with anonymized or dummy data
What stays onshore:
- Direct access to systems containing sensitive citizen/student data
- Production environment administration
- Stakeholder-facing work and change management
- Compliance validation and audit activities
The Bottom Line: Once One Agency Does It, Others Follow
This is how SLED has always worked. Nobody wants to be first, but once the biggest agency in a region successfully uses a hybrid offshore model, suddenly it’s acceptable.
Your competitive advantage isn’t being the last hold-out. It’s being the organization that makes informed decisions based on actual requirements rather than institutional lore.
The question isn’t whether you CAN use offshore resources…in most cases, you really can. The question is whether you’re willing to do the work to understand your actual constraints, structure the engagement appropriately, and give your projects the best chance of success.
Because right now, the easy button isn’t keeping you safe. It’s keeping you stuck.
