Software companies
How to exclude regulated tenants (BAA, FedRAMP, EU) from a SaaS data license
By SourceX Editorial · Reviewed by Noah Loul ·
Short answer
To exclude regulated tenants from a SaaS data license, build an exclusion register before export: one row per tenant with its flag (BAA, FedRAMP, EU or contract), the reason, the source contract, the systems affected and a verification query. Exclude by tenant ID and by email domain, then prove zero matches in the prepared package before approval.
Key takeaways
- Regulated tenants are excluded by default and stay out unless counsel confirms otherwise.
- Every register row should point to the contract or addendum that justifies the exclusion.
- Tenant identity hides in help desk organizations, CRM accounts, Jira fields, shared Slack channels and email domains, not just the application database.
- A verification query that returns zero matches, run after preparation, is the evidence that the exclusion worked.
- Former customers stay on the register, because ending a contract does not end every obligation in it.
Which tenants belong on an exclusion register?#
Tenants belong on an exclusion register when their contract, or the law that governs their data, adds obligations beyond your standard terms. For most B2B SaaS companies that means customers who signed a business associate agreement, government customers served from a FedRAMP or similar authorized environment, and customers whose data is subject to EU or UK data protection law or a residency commitment.
Add contract-driven exclusions too: customers with a no AI training clause, strict confidentiality addenda or a custom data processing agreement nobody has reviewed. The register tracks obligations, not industries; a hospital system without a BAA and a software customer with one can land in different places.
This is general information, not legal advice. Which laws may apply to each tenant is assessed deal by deal with counsel.
The exclusion register template#
The exclusion register works best as one row per tenant, kept in the same inventory workbook as the rest of the package. These fields make each row checkable by someone who did not build it.
Build the register from contracts, not from memory. Pull every agreement flagged in the CRM or contract system, then ask account managers and implementation leads which customers received commitments in side letters or emails that never reached a structured field.
| Field | What to record | Example entry |
|---|---|---|
| Tenant ID | The identifier used in the application and the warehouse | Internal account key, not the display name |
| Flag | BAA, FedRAMP, EU or UK, residency, no AI clause or other | BAA |
| Reason | One sentence on why the tenant is excluded | Signed business associate agreement covering support data |
| Source contract | Agreement, addendum and clause reference | BAA attached to the master subscription agreement |
| Scope | All records, or named record types only | All records, including tickets and shared channels |
| Systems affected | Every system where the tenant appears | App database, help desk, CRM, Jira, Slack |
| Identifiers to match | Account keys, organization IDs, email domains, channel names | Help desk organization and two email domains |
| Verification query | The check that proves no records remain | Count of exported tickets matching the listed domains |
| Owner and date verified | Who ran the check and when | Data lead, before the Approval step |
Where tenant identity hides outside the application#
Tenant identity hides in every system that touches the customer, and a SaaS data license usually draws more from those systems than from the application database. A processor generally may not license customer content at all without clear contractual rights, so the records at risk are your own: support tickets, implementation notes, engineering issues, shared channels and email.
Mentions are harder to catch than ownership. An engineer's Jira issue may describe a regulated customer's bug in detail without any customer field set, and an incident review may name several affected tenants in one sentence. Search text for customer names and known aliases, and decide with counsel whether a mention alone excludes the record or only requires redacting the name.
- Help desk: organization records, requester email domains and custom fields.
- CRM: account records, opportunity notes and attached order forms.
- Issue tracker: customer fields, labels and ticket links in Jira or Linear.
- Chat: Slack Connect or shared channels named after the customer.
- Email: threads with the customer's domain in sales and customer success inboxes.
- Code: customer names in commit messages, branch names and configuration files.
- Warehouse: usage tables and logs keyed by tenant.
What each flag usually means for the package#
Each flag carries different obligations, and the table summarizes why a SaaS company typically treats it as an exclusion. Counsel confirms the actual position for each contract and each tenant.
Provenance metadata can carry these decisions forward to the buyer. The Data and Trust Alliance's Data Provenance Standards include Use elements for allowed and excluded processing and storage geographies, consent documentation location and license to use, which map naturally onto register fields.
| Flag | Why it usually triggers exclusion | What to check |
|---|---|---|
| BAA | HIPAA may apply to protected health information in tickets, logs or attachments | Which records the BAA covers and its limits on use and disclosure |
| FedRAMP or government | Government data and authorization boundary commitments may limit where data goes | The government contract, data rights clauses and the environment boundary |
| EU or UK | GDPR or UK GDPR may apply, along with transfer and residency commitments | Data processing agreement, transfer terms and hosting region promises |
| Residency elsewhere | The contract promises data stays in a region | The residency addendum and which records it covers |
| No AI training clause | The contract restricts AI use of customer information | Exact wording and whether it reaches vendor-side records |
How to write verification queries that hold up#
A verification query proves the exclusion worked by returning zero matching records from the prepared package. Write it against the export, not the source system, because the export is what the buyer receives.
Keep the queries simple enough for a reviewer to read. A plain count by email domain that returns zero is more convincing than a complex join nobody else can check.
- Match on every identifier in the register: account keys, organization IDs, email domains and channel names.
- Run the query on the raw export and again after de-identification, since pseudonymized fields can hide a match.
- Search free text for customer names and aliases, and review the hits by hand.
- Record the query, the run date, the result and the person who ran it in the register.
- Re-run after any change to scope, date range or source system.
Illustrative: an HR onboarding software company builds its register#
Illustrative: a fictional HR onboarding software company sells to employers across industries. Some hospital customers signed BAAs because onboarding files can include health information, a state agency uses a separate government environment, and EU customers are hosted in an EU region under a data processing agreement.
The CTO pulls flags from contract fields in the CRM and confirms them with counsel. Each regulated tenant gets a row with its help desk organization, email domains, Slack Connect channel names and CRM account key. A verification count runs on the exported Zendesk tickets, Jira issues and Slack messages, first raw and then after de-identification.
The first run finds tickets from a hospital customer filed under a staff member's personal email before the organization was set up in the help desk. Those are traced and removed, and the query is re-run until it returns zero. The register goes into the package documentation, and the CEO approves the scope.
How SourceX approaches tenant exclusions#
SourceX treats the exclusion register as part of the Rights and Preparation steps of the SourceX five-step transaction. Rights review identifies which contracts create exclusions; Preparation applies them and runs the verification queries.
The SourceX Evidence Packet holds the privacy record and release authorization, including the register's verification results, so a buyer can see that exclusions were applied without learning which customers they cover. The supplier approves the final package only after the checks return zero.
Frequently asked questions
Is excluding a tenant enough if other tickets mention them?
Not always. Cross-tenant mentions turn up in shared engineering issues, incident reports and internal chat. Search text for the excluded customer's names and aliases, and either drop those records or redact the mentions, depending on what counsel decides for that flag.
Can we include aggregated metrics that include regulated tenants?
Possibly, but treat it as a separate question. Aggregates may still fall under contract terms or data protection rules, and small groups can be re-identified. Decide with counsel, and if in doubt, compute the aggregates without the regulated tenants.
What about former customers whose BAA or contract has ended?
Keep them on the register. Many obligations, such as confidentiality and limits on using data received during the contract, survive termination. Remove a former customer only when counsel confirms the specific obligations no longer apply to the records in scope.
How often should the register be re-verified?
Re-verify whenever the package changes and before every delivery. New contracts, renewals with new addenda and customers moving into a regulated category all change the register, so tie updates to contract changes recorded in the CRM.
Do we need to tell excluded customers anything?
Usually there is nothing to tell them, because their records are not included. Some companies still prepare a short customer FAQ that explains the program and the exclusion approach, which helps account teams answer questions consistently if a customer asks.
Sources
- The Use group of the Data & Trust Alliance Data Provenance Standards includes elements for confidentiality classification, consent documentation location, privacy-enhancing technologies applied, allowed and excluded processing and storage geographies, license to use, intended data use, and copyright, patent and trademark status. Source
Related resources
See if your company qualifies
A short company assessment. No data uploads are needed.