Govern Offshore Delivery With Real Accountability

Which legal entity answers for the work when the team sits abroad

Cross-border delivery governance usually breaks at a contract boundary before it breaks at a technical one. A buyer in one country signs with a provider in another, the people doing the work may sit in a third location, and each side quietly assumes the other entity carries the hard decisions. Before anyone discusses sprint rhythm or status dashboards, the buyer should be able to say three things plainly: which legal entity is accountable for the outcome, which entity employs or engages the individuals doing the work, and which entity issues the invoices. When those answers point at different companies, the arrangement can still work, but the governance document has to explain each seam between them rather than leave the reader to infer it.

Buyers often focus on day-to-day productivity and overlook the paper trail that decides what happens when something goes wrong. A missed release, a data incident or a dispute over ownership of code is resolved by the contract and by the records kept during delivery. Governance is therefore partly a legal design task and partly an operating task. The operating side is what this page covers: who decides, who is told, what evidence exists, and how the buyer gets a clear answer when a decision is contested.

Contracting questions to put to any provider before signature

These questions are not hostile. A provider that runs an accountable operation can usually answer them in one conversation, and the quality of the answers tells the buyer more than a capability deck. Ask them in writing and keep the answers with the contract file.

• Which legal entity signs the master agreement, which entity signs each statement of work, and whether the same company employs the people named in the team plan.
• Whether any part of the work is subcontracted, to whom, in which location, and whether the buyer must approve each subcontractor before it touches project material.
• Where code, documentation, test data and logs are stored, which countries those stores sit in, and which entity controls the cloud accounts that hold them.
• Who owns the intellectual property created during the engagement, when that ownership transfers, and what happens to the provider's own tools and frameworks that are embedded in the deliverable.
• Which governing law and dispute route applies, and whether the buyer can pursue the entity that actually employed the individual who caused a problem.
• What liability and insurance cover the provider carries for data loss, confidentiality breach and professional error, and whether those limits match the value of the work at risk.

A useful test is whether the provider can name the entity responsible for each of these questions without consulting three internal departments. Whatever a provider says about itself, including what Oblytech says on its about page, should be held against what the contract actually binds. If the answer needs several calls and a follow-up email, the buyer should expect the same delay during a live incident.

Accountable roles on both sides of the border

Most governance documents list roles but do not say who can overrule whom. For a cross-border team, each role needs a named person, a defined authority and a stated limit. The buyer usually needs an executive sponsor who can release budget, a product owner who decides priority within the agreed scope, and a technical authority who approves design and architecture changes. The provider needs a delivery lead who owns the plan and staffing, an engagement manager who owns the commercial and contractual relationship, and a technical lead who can say no to a design the buyer's architects would reject. Security and data owners sit on both sides and should have a direct line to each other rather than routing everything through the commercial channel.

The question that matters most is what each named person cannot decide alone. A delivery lead can usually re-sequence work inside an approved backlog. A delivery lead should not be able to add a new data source, extend access to a production system or change the acceptance criteria without the buyer's named authority agreeing in writing. Writing these limits down prevents the common pattern in which a remote team makes a reasonable decision that the buyer later discovers was outside its authority.

Service ownership after go-live needs its own name, and the ServiceNow support and maintenance page describes one way to keep that ownership with a support team. Engagements that end at release often leave the buyer with an unowned system. The buyer should name who will own incidents, minor changes and the operational backlog from the first day of production, and whether that owner is the buyer's own team, a support arrangement with the provider or a combination of both.

Reporting a non-technical sponsor can actually use

Status reporting across borders tends to produce either too much detail to read or too little to act on. A useful report answers four questions in the same order each time: what changed against the agreed scope, what is blocked and by whom, what defects or access exceptions are open and how old they are, and which decisions the buyer must make before the next period. Burn-down charts and hours logged are weaker evidence than these items, because they show activity rather than progress toward acceptance.

The age of an open decision is one of the most revealing measures. A decision that has waited several review cycles usually means the buyer's authority is unclear, the provider has stopped asking, or the two sides have different views of what was agreed. Governance should make old decisions visible in every report until they close. The same applies to access exceptions. A temporary grant that was approved for a specific task and never withdrawn is a control gap, and a report should show it as one.

Reporting cadence should match the decision speed the buyer needs. Weekly delivery reviews suit many teams, with a short monthly steering conversation for the sponsor. The overlap window between the two offices determines how much of this can happen live. If the working hours barely overlap, the buyer should agree a written update standard and a single escalation window instead of relying on ad hoc calls.

Change control that keeps scope honest across distance

Change control is where distributed teams most often drift. A request arrives in a chat thread, the provider starts work because the request seems small, and three weeks later the buyer discovers the sprint carried a different scope from the one it approved. A workable process records every change request in one system of record, states its effect on scope, cost, timing and risk, and assigns an approver who holds the authority to accept that effect. The approver should be someone on the buyer side who can say yes to the commercial consequence, not only the person who asked for the change.

Emergency changes need a separate, faster path that still leaves a record. The usual pattern is a named person who can authorize a production fix at any hour, a rule that the fix is documented within a defined period afterward, and a review that decides whether the fix stays as permanent work or is rolled back and rebuilt. Without that path, teams either wait for a meeting that cannot happen in time or make fixes that nobody records.

Acceptance that works when the reviewers are in different time zones

Acceptance criteria should be written before work starts, not after the first build appears. Each deliverable needs a definition of done that a reviewer can test without asking the author what was meant. Evidence might include test results, a demonstration against agreed data, a configuration record, a runbook, or a signed decision log. The buyer should also decide in advance who can accept, who can reject, and what happens to partial acceptance when only some criteria pass. For platform releases, the ServiceNow implementation page describes the scope of an implementation, which is the point at which these acceptance conditions should be written down.

Cross-border acceptance fails when the review depends on a live walkthrough that only one time zone can attend. Agree in advance which acceptance steps can be asynchronous, what written evidence the reviewer receives, how long a reviewer has to respond, and how a disputed rejection is escalated. These are small operating details, but they decide whether acceptance takes days or stalls for a month.

Data, intellectual property and confidentiality controls

Access control is the area where cross-border arrangements most need explicit rules. The buyer should know which data classes the team will touch, whether any production data is permitted in non-production environments, and whether masked or synthetic data is used instead. Individuals should have named accounts, least-privilege roles and no shared logins. Access should be granted for a stated purpose, reviewed on a fixed schedule and removed promptly when a person leaves the team. Where the work touches AI tooling, the AI governance controls page lists approved use, data access and human oversight among the controls to set. The contract should say what the provider must do to revoke access and how quickly, without leaving the detail to goodwill.

Confidentiality works best when it reaches individuals, not only the company. A provider should be able to explain how its staff sign confidentiality and acceptable-use undertakings, what happens to those undertakings when someone changes project, and how devices used for the work are managed. The buyer should also ask what happens to project material at the end of the engagement: which copies are returned, which are destroyed, and how destruction is confirmed in writing.

Intellectual property needs to be checked at three levels. The first is ownership of the code, documentation and configuration produced for the buyer. The second is the license status of any third-party component or internal accelerator used in the deliverable. The third is whether the buyer can continue the work with another provider without relying on the original team's private tools. Each of these questions is easier to answer at the start than during a dispute.

Governance models compared for cross-border delivery

No single model fits every buyer. The table below describes three common arrangements and the governance cost each one carries. It is a practice comparison, not a ranking, and the right choice depends on how stable the scope is and how much the buyer wants to direct day-to-day work.

Scope stability decides much of this choice. Buyers comparing a stable engagement with a standing team can read the offshore delivery operating model page and the dedicated ServiceNow delivery teams page side by side before choosing. A stable, well-described outcome suits a fixed arrangement. Work that changes each month needs a backlog owner on the buyer side who can make priority calls quickly, because a provider cannot guess which of several competing requests matters most.

Where cross-border governance usually fails

Three failure patterns recur. The first is a decision vacuum: the provider waits for an answer, the buyer assumes the provider is progressing, and nothing moves for weeks. The second is access creep, where temporary permissions become permanent because nobody owns their removal. The third is a continuity gap, where knowledge sits with one or two people and an absence stalls the work. Each pattern is visible in the reporting described above, which is why the reporting should be designed around them rather than around activity.

A governance document should therefore name the person who tracks open decisions, the person who reviews access each period, and the person who keeps the handover records current. Assigning these tasks is cheap compared with rebuilding a system after its original team has rotated away.

Frequently asked questions about delivery governance

Should the buyer require named individuals in the team?

Naming key roles, such as the technical lead and the security reviewer, is reasonable and common. Naming every engineer is harder to sustain, because staff change. A sensible compromise is to name the critical roles, require notice and a handover period before any named role changes, and give the buyer a right to object to a replacement for documented reasons.

Who should hold the source code and cloud accounts?

The buyer should usually own the repositories and cloud accounts from the start, with the provider holding delegated access. This keeps continuity intact if the relationship ends. If the provider insists on owning the accounts, the contract should provide a transfer mechanism that is tested before it is needed.

How often should governance meetings run?

A weekly working review and a monthly sponsor review suit most engagements. Increase the frequency during the first release, during a major change, or when open decisions are ageing. Reduce it only when the reports show the work is stable and decisions close on time.

What should the buyer do first if governance is already weak?

Start with the decision log and the access register. Listing open decisions and active access grants usually exposes the biggest risks within a single working session. Fix those two items before redesigning the wider reporting pack.

Next step for a cross-border delivery decision

If you are weighing an offshore arrangement and want the contracting, accountability and control questions settled for your own organization, the practical starting point is a clear list of the scope, the people who would decide on each side and the data the team would touch. Start a conversation about your delivery governance questions, and bring the draft contract or the current governance document if one exists.