White-label IT outsourcing: managing confidentiality without slipping up

One wrong email can cost you a client

An Italian IT firm wins a €200k contract to build custom ERP software. Lacking internal capacity, they subcontract development to an external partner. Delivery is on time, code quality is solid.

Then, during a routine code review, the end client opens GitHub and spots commits signed with an @external-partner.it email. Within thirty seconds, the client understands the work was not done in-house. Within a week, they renegotiate the contract, cutting out the original vendor entirely.

This is not a hypothetical. It is a pattern that repeats itself with minor variations: a misconfigured Slack workspace, an accessible Jira board, a forgotten email footer. White-label IT outsourcing only works when confidentiality is managed systematically — not left to individual goodwill.

---

Where confidentiality breaks down: the critical points

1. Code artifacts and metadata

Git is the first place identities leak. Every commit carries a user.name and user.email. If the partner does not configure the repository correctly, their real credentials end up in the commit history.

Operational fix:

# In the white-label project repo, enforce a neutral identity
git config user.name "Dev Team"
git config user.email "dev@end-client.com"

Better still: define a project-level .gitconfig and add a pre-commit hook that blocks pushes if user.email does not match the agreed domain.

#!/bin/sh
# .git/hooks/pre-commit
EMAIL=$(git config user.email)
if [[ "$EMAIL" != *"@agreed-domain.com" ]]; then
  echo "ERROR: Unauthorized Git email ($EMAIL). Set user.email correctly."
  exit 1
fi

2. Written communications

Email is the second leak vector. A thread originating from developer@partner.com that gets accidentally forwarded to the end client exposes everything.

The operational rules are simple but must be formalized:

• The partner uses only email aliases on the primary vendor's domain (e.g., dev@primary-vendor.com).
• No partner communication tool (Slack workspace, Teams tenant) is accessible to the end client.
• All meetings with the end client go through the primary vendor, who acts as the sole point of contact.

3. Technical documentation

Architecture documents, diagrams, and specs often carry watermarks, author names, and metadata. A PDF exported from the partner's Confluence instance will include the organization name in its metadata.

# Example: stripping metadata with PyPDF2 before delivering documents
import PyPDF2

def strip_metadata(input_path, output_path):
    reader = PyPDF2.PdfReader(input_path)
    writer = PyPDF2.PdfWriter()
    for page in reader.pages:
        writer.add_page(page)
    writer.add_metadata({})
    with open(output_path, 'wb') as f:
        writer.write(f)

Document sanitization must be a mandatory step in the delivery checklist — not an optional best practice.

4. Infrastructure and DNS

If the partner manages infrastructure, DNS records, SSL certificates, or container labels can reveal the real identity. A whois on the staging domain or a docker inspect on the image may be enough.

Countermeasures:

• Staging domains must be registered under the primary vendor's name or a neutral entity.
• Docker images must be rebuilt with neutral labels before delivery.
• SSL certificates must be issued on domains controlled by the primary vendor.

5. The NDA: necessary but not sufficient

The NDA is the starting point, not the finish line. A well-drafted NDA for white-label IT outsourcing must cover:

• An explicit definition of "confidential information" (including client names, project details, technologies used).
• A non-solicitation clause preventing direct contact with the end client for a defined period (typically 24–36 months post-project).
• Financial penalties proportional to the contract value — not symbolic amounts.
• An audit clause: the primary vendor has the right to verify the partner's security procedures.

A generic NDA template downloaded from the internet will not cover these points with the specificity required.

---

An air-gap operational model

The structure that works best in multi-partner B2B environments is the air-gap model:

[End client]
      |
[Primary vendor]  ← sole visible interlocutor
      |
  ┌───┴───┐
[Partner A] [Partner B]  ← invisible to the client

Rules for this model:

1. Access segregation: the partner only accesses repositories and environments strictly within their scope. Zero access to the CRM, the client's ticketing tools, or shared Slack channels with the client.
2. Communication proxy: all technical requests from the client pass through an internal project manager at the primary vendor, who translates and delegates. The partner never responds to the client directly.
3. Artifact review: every deliverable — code, documentation, images — is inspected by the primary vendor before reaching the client. The checklist is written down, not memorized.
4. Formalized partner onboarding: before any project starts, the partner receives an operational document specifying the Git identity to use, email domains, permitted and forbidden tools, and delivery procedures. They sign an acceptance letter.

---

Operational take-away

Confidentiality in white-label IT outsourcing is not managed through trust — it is managed through process. Information leaks are almost never intentional; they are the result of missing or unformalized procedures.

Four things to implement immediately:

1. A pre-commit hook that blocks unauthorized Git emails.
2. Mandatory email aliases for all communications directed at the end client.
3. A written artifact sanitization checklist before every delivery.
4. A white-label-specific NDA with a non-solicitation clause and proportional financial penalties.

If any one of these four is missing, the exposure risk is real — regardless of how professional the partner is.

---

Evviva Group operates as a white-label technology partner for agencies and system integrators. If you are building or consolidating your IT outsourcing model, we are open to a conversation.