In-tenant analysis keeps processing inside the customer environment, while vendor-side retention moves the content into a separate trust boundary for a defined period. The first reduces data movement; the second may simplify deployment but increases governance, evidence, and deletion obligations.
What changes when the data stays in your tenant versus moves to the vendor?
In-tenant analysis keeps sensitive content inside the customer-controlled environment, so the customer’s existing access controls, logging, and data-handling policies remain the primary trust anchor. Vendor-side retention creates a second custody layer where the vendor may hold content long enough to support inspection, supportability, or product improvement, but that also means the vendor becomes part of the retention, deletion, and audit chain.
The practical difference is not just where the bytes sit, but who must prove control over them. In-tenant designs tend to minimise cross-boundary data movement, while vendor-side retention usually requires clearer contractual limits, evidence of deletion, and tighter governance over who can access retained material and for how long.
For teams comparing the two, the key question is whether the vendor ever needs durable possession of the sensitive payload or whether analysis can be completed without leaving the customer boundary. If the answer is yes, the model is closer to outsourced retention than local analysis and should be treated accordingly.
Why the trust boundary matters for sensitive data
Once content leaves the tenant, even temporarily, the security posture changes from “customer governs processing in place” to “customer and vendor share responsibility for a retained copy.” That shift affects confidentiality, evidentiary retention, discovery, deletion, and sometimes cross-border or sector-specific obligations. It also changes the blast radius if the vendor environment is compromised or if operational deletion is incomplete.
In-tenant analysis is usually preferred when the sensitive material is regulated, highly confidential, or tightly scoped by internal policy. Vendor-side retention may still be acceptable when the operational benefit is real, but it should be justified by a defined business need and bounded by retention controls that can be verified, not just promised.
Where the retention model is based on a third-party service, a vendor risk review should also ask what the vendor can observe, what it can store, and what it can later reconstruct from logs, caches, or backups. That is the difference between a transient processing path and a durable secondary record.
What to verify before you accept either model
In practice, teams should separate the data-flow decision from the compliance decision. If the content is only analysed in tenant, verify that no copy is staged outside the boundary and that telemetry does not silently reintroduce the payload elsewhere. If the vendor retains data, verify retention duration, purpose limitation, deletion timing, access scope, and whether backups or replicas are included in the deletion promise.
- Confirm whether the vendor-side copy is encrypted, searchable, exportable, or accessible to support personnel.
- Check whether retention is optional, configurable, or automatic.
- Require evidence that deletion covers primary storage, indexes, logs, and backups where applicable.
- Document who owns the legal and operational obligations once the vendor holds the content.
If you need a baseline for secure deletion and sanitization controls, NIST SP 800-88 Media Sanitization is the right reference point for thinking about clearing, purging, and destruction of retained material.
Risk and Threat Considerations
Vendor-side retention increases the exposure window because sensitive data is no longer confined to the customer environment. The main risk is not only accidental over-retention, but also secondary access through support workflows, misconfiguration, or compromise of the vendor’s retained datastore.
Failure mechanism: A vendor keeps a retained copy longer than intended, replicates it into logs or backups, or exposes it through an adjacent service path, which expands the set of systems and people that can reach the sensitive content.
Impact: The customer may lose practical control over deletion, face broader disclosure risk, and inherit a harder evidence problem if it later needs to prove what was kept, where it lived, and when it was removed.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AU-9 — Protection of Audit Information | Vendor retention depends on protecting retained evidence and logs from unauthorized access. |
| SC-28 — Protection of Information at Rest | Both models depend on safeguarding sensitive data when it is stored or retained. | |
| MP-6 — Media Sanitization | Vendor-side retention creates a deletion and sanitization obligation for stored content and copies. | |
| Recommendation — Protect retained analysis data and audit records so only approved roles can access them. Encrypt sensitive retained data at rest and manage storage protections accordingly. Sanitize retained data and copies when retention ends or the purpose expires. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | The distinction depends on who can access sensitive data inside or outside the tenant boundary. |
| Recommendation — Define and enforce access rules for any retained sensitive data. | ||
Practitioner Guidance
What to prioritise: Decide first whether the use case actually requires durable vendor retention. If the answer is only “for convenience,” treat that as a weak justification for moving sensitive content outside the tenant.
What to verify: Require a clear retention schedule, a deletion mechanism that covers indexes and backups, and an access model that limits retained data to the smallest support set possible. If the vendor cannot describe deletion evidence in operational terms, the model is too vague for sensitive material.
Decision rule: If the vendor copy would be enough to recreate the sensitive record, treat the arrangement as a retention and governance problem, not just an analysis feature.
Practitioner takeaway: In-tenant analysis is mainly a boundary-preservation choice, while vendor-side retention is a custody-and-proof problem, so the deciding factor should be whether you can verify control, deletion, and access limits after the data leaves your tenant.
Related resources from NHI Mgmt Group
- What is the difference between single-tenant cloud deployment and shared SaaS deployment for security-sensitive data?
- What is the difference between client-side visibility filtering and server-side access control for sensitive API data?
- What is the difference between restricting data broker sales and controlling vendor access to sensitive personal data?
- What is the difference between attack surface management and NHI governance?